WAMPS 2011
VII Workshop Anual do MPS
Campinas-SP, 24 a 28 de outubro de 2011
4
WAMPS 2011
FICHA CATALOGRÁFICA ELABORADA PELO
Sistemas de Bibliotecas da UNICAMP / Setor de Catalogação
Bibliotecária: Priscila Gomes Cruz
W892a
Workshop Anual do MPS, 7., Campinas, SP, 2011.
Anais do VII WAMPS 2011, realizado em Campinas, de 24
a 28 de Outubro de 2011; organizadores: Tayana Uchôa
Conte, Gleison dos Santos Souza, Ana Regina Cavalcanti
da Rocha. — Campinas, SP : Associação para Promoção
da Excelência do Software Brasileiro - SOFTEX, 2011.
184 p.
1. Software – Congressos. 2. Programas de computador
– Congressos.
I. Conte, Tayana Uchôa. II. Souza, Gleison dos Santos.
III. Rocha, Ana Regina Cavalcanti da.
IV. Título.
CDD – 001.6425
- 001.642
ISBN 978-85-99334-31-7
Índices para Catálogo Sistemático
1.
2.
Software - Congressos - 001.6425
Programas de computador – Congressos - 001.642
WAMPS 2011
5
SOFTEX - Associação para Promoção da Excelência do Software Brasileiro
Criada em dezembro de 1996, a Sociedade SOFTEX, ou simplesmente SOFTEX, é uma Organização
da Sociedade Civil de Interesse Público (OSCIP) sediada em Campinas, SP, Brasil.
A SOFTEX é responsável pela gestão do Programa Prioritário em Informática do Governo Federal para
Promoção da Excelência do Software Brasileiro, o Programa SOFTEX.
Missão da SOFTEX
Ampliar a competitividade das empresas brasileiras de software e serviços de TI e a sua participação
nos mercados nacional e internacional, promovendo o desenvolvimento do Brasil.
O Sistema SOFTEX, por sua vez, tem abrangência nacional. É formado pela Sociedade SOFTEX e
por agentes regionais, aos quais se vinculam mais de 1.600 empresas com atividades em software e
serviços de TI.
Presidente da SOFTEX
Rubén Delgado
Vice-Presidente Executivo da SOFTEX
Arnaldo Bacha de Almeida
Diretoria Executiva da SOFTEX
Descartes de Souza Teixeira – Assessor de Planejamento e Gestão
Djalma Petit – Diretor de Mercado
Ephrain Guilherme Neitzke – Controladoria
John Lemos Forman – Diretor de Capacitação e Inovação
José Antonio Antonioni – Diretor de Qualidade e Competitividade
Dentre as atividades da SOFTEX no âmbito da Diretoria de Qualidade e Competitividade, pelos
resultados alcançados desde dezembro de 2003, destaca-se o Programa MPS.BR – Melhoria de
Processo do Software Brasileiro.
Programa MPS.BR – Melhoria de Processo do Software Brasileiro
Kival Chaves Weber – Coordenador Executivo
Nelson Henrique de Oliveira Franco – Gerente de Operações
André Luis Chamelet Sotovia
Cleide Gonçalves da Silva
Elidiane Teixeira Barroso
6
WAMPS 2011
Sumário
9
Apresentação
Organização do WAMPS 2011
11
Programação do WAMPS 2011
12
1 – Palestrantes convidados
1.1 – “Perspectivas para Ciência, Tecnologia e Inovação no Brasil 2010-2020”. Jorge
Audy (PUC-RS)
16
1.2 – “The cloud paradigm: Are you tuned for the lyrics?”. Fernando Brito e Abreu,
Instituto Universitário de Lisboa (ISCTE-IUL) & CITI/FCT/UNL
20
1.3 – “iMPS – Rodada 4: Variação de Desempenho nas Empresas que Adotaram o Modelo
MPS de 2008 a 2011”. Guilherme Horta Travassos (COPPE/UFRJ)
26
1.4 – “Consultores e Consultoria. Uma visão Crítica”. Carlos Barbieri (CCOMP.MG/
FUMSOFT)
38
1.5 – “Como verificar se a empresa está pronta para avaliação inicial”. Cristina Machado
(CELEPAR / QUALITYFOCUS)
42
2 – Artigos técnicos selecionados
2.1 – “A metodologia P3 no Gerenciamento de Portfólio de Projetos”, Heber Nascimento,
Jandira Palma e Rafael Soares Parente (Universidade Estadual de Londrina)
44
2.2 – “Implantação do Nível F do MR-MPS Combinando Características do Processo
Unificado com Práticas SCRUM”, Tatiane Silva, Rogério Magela, Gleison Santos, Natália
Chaves Lessa Schots, Ana Regina Rocha (Athenas Software, Unirio, COPPE/UFRJ)
54
2.3 – “Definição de um processo de Engenharia de Requisitos para software embarcado
na indústria automotiva baseada em uma Arquitetura de Processos de Software”, Luiz
Carlos Ribeiro Junior, Cristiane Ramos, Maylon Felix Brito, Rejane Costa (Universidade
de Brasília)
62
2.4 – “Lições Aprendidas com o Processo de Aquisição – MPS”, Danilo Scalet, Edmeia
Leonor Pereira Andrade, João Felipe Santos Condack (Companhia de Informática do
Paraná – CELEPAR, EMBRAPA, PrimeUp)
74
2.5 – “Lições Aprendidas em Implementações de Melhoria de Processos em Organizações
com Diferentes Características”, Natália Chaves Lessa Schots, Gleison Santos, Cristina
Cerdeiral, Mylene Cabral, Reinaldo Cabral, Marcelo Schots, Elaine Nunes e Ana Regina
Rocha (COPPE/UFRJ, Unirio)
84
WAMPS 2011
7
2.6 – “MPS.BR Nível D – A Experiência em Implantar o Modelo na Área de Governo
Municipal”, Márcio Fernando Corrêa Ricardo, Patrícia Gonçalves de Oliveira, Daniela
Fumes da Luz, Gilson Teberga Fernandes (IMA S/A)
94
2.7 – “Relato da Experiência do Processo de Institucionalização do Modelo CMMI na
Dataprev”, Rosana Osorio, Guilherme Motta (DATAPREV)
104
2.8 – “Experiência de Implantação de Melhoria de Processos de Software em um
Laboratório de Pesquisa”, Fabiana Mendes, Jackeline Almeida, Egio Junior (Universidade
Federal do Mato Grosso, Universidade Federal de Goiás )
114
2.9 – “Revisão sistemática sobre a comunicação dentro do processo de desenvolvimento
de software”, Taciano Moraes, Juliano Oliveira, Adriana Silveira de Souza (Universidade
Federal de Goiás – PUC GOIÁS – Estratégia Tecnologia da Informação)
124
3 – Artigos selecionados sobre ferramentas
3.1 – “Apoio à Medição em um ADS Centrado em Processos”, Talita Ribeiro, Luciana
Nascimento, Liken Lima, Carla Lima Reis, Rodrigo Reis (UFPA)
136
3.2 – “Controlle: Ferramenta de Apoio à Gerência de Requisitos”, Fernando Nascimento,
Marcus Teixeira, Marcello Thiry, Alessandra Zoucas (Khor Tecnologia da Informação,
Incremental Tecnologia)
146
3.3 – “Portal EduES 2.0: Uma Ferramenta para Apoiar a Gerência de Reutilização no
Domínio de Educação em Engenharia de Software”, Hudson Borges, Rafael Santo,
Rodrigo Santos, Heitor Costa, Claudia Werner (Federal University of Lavras, COPPE /
UFRJ)
156
3.4 – ”Aderência do IBM Rational Team Concert ao MR-MPS – Uma análise com ênfase
em gerência de configuração”, João Felipe Santos Condack (PrimeUp)
166
3.5 – “Apoio aos Processos de Gerência de Requisitos e Verificação e Validação em
um Ambiente Integrado”, Giselle Almeida, Michelle Neto, Bruno Ramos, Jonnathan
Carvalho, Mara Barcelos, Simone Vasconcelos (Instituto Federal Fluminense)
176
8
WAMPS 2011
Apresentação
É com grande satisfação que, em nome do Comitê de Programa e da Comissão Organizadora,
saudamos os participantes do VII Workshop Anual do MPS (WAMPS 2011). O WAMPS é um evento
anual, realizado pela SOFTEX, que tem por objetivo reunir os representantes da Indústria, Governo,
Academia, Equipe Técnica do Modelo (ETM), Fórum de Credenciamento e Controle (FCC), BID e países
latino-americanos envolvidos e interessados no aprimoramento de processos de software por meio
tanto do Modelo MPS quanto do Programa MPS.BR – Melhoria de Processo do Software Brasileiro.
Desde a edição de 2009, o Workshop Anual do MPS passou a promover, de forma integrada, os eventos
anteriormente executados e representados pelos Workshop de II – Instituições Implementadoras MPS,
Workshop de IA – Instituições Avaliadoras MPS, Workshop de IOGE – Instituições Organizadoras de
Grupos de Empresas MPS e Workshop de Empresas MPS.
A integração que resultou no Workshop Anual do MPS teve êxito em seu objetivo de aproveitar
as experiências, aumentar a sinergia entre os grupos e tirar proveito da maturidade adquirida ao
longo de sete anos de trabalho intenso. 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.
Com o apoio da SBC (Sociedade Brasileira de Computação), o WAMPS promove uma chamada de
artigos técnicos sobre resultados obtidos com experiências na utilização do Modelo MPS, relatos
de métodos e/ou técnicas para melhoria de processo de software que possam ser empregados no
contexto do Modelo MPS e estudos experimentais relatando resultados sobre melhoria de processo
de software no contexto do Modelo MPS. No WAMPS 2011 serão apresentados nove artigos técnicos
selecionados por um Comitê de Programa composto por pesquisadores e profissionais especialistas
no Modelo MPS.
Além da Seção de Artigos Técnicos, o WAMPS promove desde 2010 a Sessão de Ferramentas, cujo
objetivo é proporcionar um fórum para intercâmbio de experiências e de soluções automatizadas para
apoiar a implementação e avaliação do MR-MPS em suas mais diversas necessidades e manifestações.
Participam da Sessão de Ferramentas empresas que desenvolveram e/ou adaptaram ferramentas para
apoio aos processos do MPS, bem como membros da comunidade acadêmica, que com pesquisas
e/ou elaboração de ferramentas de apoio à implementação e/ou avaliação MPS. Esta seção é uma
oportunidade de apresentar e divulgar seus produtos para os participantes do WAMPS. A Sessão de
Ferramentas permite tanto apresentações de artigos quanto demonstrações práticas das ferramentas
selecionadas. No WAMPS 2011 serão apresentados cinco artigos e demonstradas quatro outras
ferramentas selecionadas.
Além das Seções de Artigos Técnicos e Ferramentas, a programação do WAMPS 2011 conta com
quatro mini-cursos técnicos, ministrados por Implementadores e/ou Avaliadores do MPS especialistas
nos temas:
• “Como conduzir um processo de Planejamento Estratégico”, ministrado por Francisco
Vasconcellos (II e IA Estratégia);
WAMPS 2011
9
• “Medição e Definição de Indicadores”, ministrado pela Dra. Monalessa Barcellos (UFES);
• “Implementação do Nível E do MR-MPS”, ministrado pelo Dr. Mariano Montoni (II e IA Promove
Soluções);
• “Como Escrever um Relato de Experiência”, ministrado pelo Dr. Gleison Santos (UNIRIO/II e IA
COPPE UFRJ),
O WAMPS 2011 conta com a presença de um palestrante nacional e um internacional convidados:
o prof. Jorge Audy (PUCRS), abordando “Perspectivas para Ciência, Tecnologia e Inovação no Brasil
2010-2020” e o prof. Fernando Brito e Abreu (Instituto Universitário de Lisboa (ISCTE-IUL) & CITI/FCT/
UNL), apresentando a palestra “The cloud paradigm: Are you tuned for the lyrics?”.
Além dos palestrantes convidados, o WAMPS 2011 inclui palestras específicas sobre o Modelo MPS
e o Programa MPS.BR: “iMPS – Rodada 4: Variação de Desempenho nas Empresas que Adotaram o
Modelo MPS de 2008 a 2011”, apresentada pelo professor Guilherme Horta Travassos (COPPE UFRJ);
“Consultores e Consultoria: uma visão crítica”, por Carlos Barbieri (II e IA FUMSOFT); “Como verificar
se a empresa está pronta para avaliação inicial”, por Cristina Machado (II e IA QUALITYFOCUS).
Durante o período do workshop, a programação do WAMPS 2011 compreende: cursos oficiais;
reunião do CGP – Conselho de Gestão do Programa MPS.BR; reunião de Coordenadores de II, IA e
IOGE; reunião do Projeto RELAIS – Rede Latino Americana da Indústria de Software sobre “Aquisição
de Software” entre SOFTEX e representantes da Colômbia, México e Peru.
Na quinta e sexta, após o encerramento do workshop, estão programados um curso oficial C4 –
Melhoria do Processo de Aquisição de Software, ministrado por Danilo Scalet (CELEPAR) e Edmeia
Leonor Pereira de Andrade (EMBRAPA), e uma palestra sobre o “Processo de Contratação de Serviços
de TI para Organizações Públicas”, por Edmeia Leonor Pereira de Andrade (EMBRAPA).
Gostaríamos de agradecer a todos que contribuíram para a realização deste evento. Somos imensamente
gratos aos palestrantes convidados, aos professores de mini-cursos, aos membros e revisores do
Comitê de Programa e a todos os autores que submeteram trabalhos. Todo o nosso reconhecimento
vai também para Nelson Franco e sua equipe, cujo empenho tornou este evento possível.
Desejamos a todos um ótimo workshop!
Campinas, outubro de 2011
Tayana Conte (UFAM)
Coordenadora científica do WAMPS 2011 – VII Workshop Anual do MPS
Gleison Santos (UNIRIO)
Coordenador da Sessão de Ferramentas do WAMPS 2011 - VII Workshop Anual do MPS
José Antonio Antonioni (SOFTEX)
Kival Weber (SOFTEX/MPS.BR)
Nelson Franco (SOFTEX)
Ana Regina Rocha (COPPE/UFRJ)
Coordenação Geral do WAMPS 2011 – VII Workshop Anual do MPS
10
WAMPS 2011
Organização do WAMPS 2011
Coordenação Geral
José Antonio Antonioni (SOFTEX)
Kival Weber (SOFTEX/MPS.BR)
Ana Regina Rocha (COPPE/UFRJ)
Nelson Franco (SOFTEX)
Coordenação Científica
Tayana Conte (UFAM)
Coordenação Científica da Sessão de
Ferramentas
Gleison Santos (UNIRIO)
Comitê de Avaliação da Trilha Artigos Técnicos
Adriano Albuquerque (UNIFOR)
Alexandre Vasconcelos (UFPE)
Ana Zabeu (ASR Consultoria)
Ana Liddy Magalhaes (UFMG / QualityFocus)
Ana Regina Rocha (COPPE/UFRJ)
Andrea Barreto (COPPE/UFRJ)
Carla Lima Reis (UFPA)
Carlos Barbieri (FUMSOFT)
Carlos Alberto Marques Pietrobon (UFOP / PUC-Minas)
Christiane Gresse von Wangenheim (UFSC)
Clenio Salviano (CTI – Centro de Tecnologia da
Informação Renato Archer)
Danilo Scalet (CELEPAR)
Edmeia Leonor Pereira Andrade (EMBRAPA)
Fabio Campos (UCB)
Felipe Soria (CITS)
Francisco Vasconcellos (Estratégia)
Gleison Santos (UNIRIO)
Guilherme Horta Travassos (COPPE/UFRJ)
João Santos Condack (PrimeUp)
Juliano Oliveira (UFG)
Leonardo Murta (UFF)
Luiz Carlos Ribeiro Junior (UnB)
Marcello Thiry (UNIVALI)
Marcelo Yamaguti (PUCRS)
Marcos Kalinowski (Kali Software)
Mariano Montoni (ProMove Soluções)
Monalessa Barcellos (UFES)
Odisnei Galarraga (Software Process Consultoria)
Rafael Prikladnicki (PUCRS)
Reinaldo Cabral (COPPE/UFRJ)
Renato Machado (QualityFocus)
Renato Volpe (ASR Consultoria)
Ricardo Falbo (UFES)
Rodrigo Reis (UFPA)
Sandro Ronaldo Bezerra Oliveira (UFPA)
Sheila Reinehr (PUCPR)
Revisores Externos da Trilha Artigos Técnicos
Luiz Leandro Fortaleza (UFAM)
Comitê de Avaliação da Trilha de Ferramentas
Adler Diniz de Souza (COPPE/UFRJ)
Ahilton Barreto (COPPE/UFRJ)
Alexandre Vasconcelos (UFPE)
Ana Liddy Magalhaes (UFMG / QualityFocus)
Ana Paula Bacelo (PUCRS)
Analia Ferreira (ProMove Soluções)
Andrea Barreto (COPPE/UFRJ)
Andreia Malucelli (PUCPR)
Carla Lima Reis (UFPA)
Clenio Salviano (CTI – Centro de Tecnologia da
Informação Renato Archer)
Cristiane Ramos (UnB)
David Zanetti (ProMove Soluções)
Fabio Campos (UCB)
Francisco Vasconcellos (Estratégia)
Marcello Thiry (UNIVALI)
Marcos Kalinowski (Kali Software)
Mariano Montoni (ProMove Soluções)
Monalessa Barcellos (UFES)
Reinaldo Cabral (COPPE/UFRJ)
Renato Volpe (ASR Consultoria)
Rodrigo Reis (UFPA)
Rosângela Mendonça (Universidade do Estado de
Minas Gerais)
Sandro Ronaldo Bezerra Oliveira (UFPA)
Sarah Kohan (Fundação Carlos Alberto Vanzolini)
Tayana Conte (UFAM)
Revisores Externos da Trilha de Ferramentas
Marcelo Schots (COPPE/UFRJ)
Mylene Cabral (COPPE/UFRJ)
Natália Chaves Lessa Schots (COPPE/UFRJ)
WAMPS 2011
11
Programação do WAMPS 2011
WAMPS 2011 - VII WORKSHOP ANUAL DO MPS – 24 a 28 de outubro de 2011
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: Tayana Conte (UFAM)
Coordenação Científica da Sessão de Ferramentas: Gleison Santos (UNIRIO)
2ª feira - 24 de outubro de 2011
8:30-9:00
Curso “Implementação nível E”
(Mariano Montoni)
9:00-9:30
Curso “Como escrever um relato de experiência”
(Gleison Santos)
9:30-10:00
10:00-10:30
Intervalo
Exposição de Ferramentas
10:30-11:00
11:00-11:30
11:30-12:00
Continuidade do Curso “Implementação nível E”
(Mariano Montoni)
12:00-12:30
12:30-14:00
Continuidade do
Curso “Como
escrever um relato de
experiência”
(Gleison Santos)
Almoço
Exposição de Ferramentas
Exposição de Ferramentas
Exposição de Ferramentas
Exposição de Ferramentas
Exposição de Ferramentas
14:00-14:30
Artigo aceito 1: “A metodologia P3 no Gerenciamento de Portfólio de Projetos”, Heber Nascimento,
Jandira Palma e Rafael Soares Parente (Universidade Estadual de Londrina)
14:30-15:00
Artigo aceito 2: “Apoio aos Processos de Gerência de Requisitos e Verificação e Validação em um
Ambiente Integrado”, Autores: Giselle T. de Almeida, Michelle M. F. Neto, Bruno A. Ramos,
Jonnathan dos S. Carvalho, Mara R. dos S. Barcelos, Simone V. Silva, Aline P. V. de Vasconcelos
(Instituto Federal Fluminense)
15:00-15:30
Artigo aceito 3: “Apoio à Medição em um ADS Centrado em Processos”, Talita Ribeiro,
Luciana Nascimento, Liken Lima, Carla Lima Reis, Rodrigo Reis (UFPA)
15:30-16:00
Intervalo
Exposição de Ferramentas
16:00-16:30
Artigo aceito 4: “Definição de um processo de Engenharia de Requisitos
para software embarcado na indústria automotiva baseada em uma
Arquitetura de Processos de Software”, Luiz Carlos Ribeiro Junior, Cristiane
Ramos, Maylon Felix Brito, Rejane Costa (Universidade de Brasília)
Exposição de Ferramentas
16:30-17:00
Artigo aceito 5: “Controlle: Ferramenta de Apoio à Gerência de
Requisitos”, Fernando Nascimento, Marcus Teixeira, Marcello Thiry,
Alessandra Zoucas (Khor Tecnologia da Informação, Incremental Tecnologia)
Exposição de Ferramentas
17:00-17:30
Artigo aceito 6: “Lições Aprendidas com o Processo de Aquisição - MPS”,
Danilo Scalet, Edmeia Leonor Pereira Andrade, João Felipe Santos Condack
(Companhia de Informática do Paraná - CELEPAR, EMBRAPA, PrimeUp)
Exposição de Ferramentas
17:30-18:00
18:00-18:30
Palestra de Carlos Barbieri (CCOMP.MG / FUMSOFT):
“Consultores e Consultoria. Uma visão crítica”
18:30-20:00
Abertura do WAMPS e Entrega de Placas MPS.BR
20:00-00:00
Festa de Abertura
12
WAMPS 2011
Programação do WAMPS 2011
3ª feira - 25 de outubro de 2011
8:30-9:00
9:00-9:30
Curso “Como conduzir um processo de Planejamento
Estratégico” (Francisco Vasconcellos)
9:30-10:00
10:00-10:30
Intervalo
Exposição de Ferramentas
10:30-11:00
11:00-11:30
11:30-12:00
Exposição de Ferramentas
Continuidade do Curso
“Como conduzir um processo
de Planejamento Estratégico”
(Francisco Vasconcellos)
12:00-12:30
12:30-14:00
Prova para
Avaliadores MPS
8:30 as 12:30
(sem intervalo)
Exposição de Ferramentas
Reu CGP Conselho de
Gestão do
Programa MPS.BR
(9:00-12:00)
Exposição de Ferramentas
Exposição de Ferramentas
Almoço
Almoço
Exposição de Ferramentas
14:00-14:30
14:30-15:00
Palestrante Nacional: Jorge Audi (PUCRS)
“Perspectivas para Ciência, Tecnologia e Inovação no Brasil 2010-2020”
15:00-15:30
15:30-16:00
Intervalo
Exposição de Ferramentas
16:00-16:30
Artigo aceito 7: “Lições Aprendidas em Implementações
de Melhoria de Processos em Organizações com Diferentes
Características”, Natália Chaves Lessa Schots, Gleison Santos,
Cristina Cerdeiral, Mylene Cabral, Reinaldo Cabral, Marcelo
Schots, Elaine Nunes e Ana Regina Rocha (COPPE/UFRJ, Unirio)
Exposição de Ferramentas
16:30-17:00
Artigo aceito 8: “MPS.BR Nível D – A Experiência em Implantar
o Modelo na Área de Governo Municipal”, Márcio Fernando
Corrêa Ricardo, Patrícia Gonçalves de Oliveira, Daniela Fumes da
Luz, Gilson Teberga Fernandes (IMA S/A)
Exposição de Ferramentas
17:00-17:30
Artigo aceito 9: “Relato da Experiência do Processo de
Institucionalização do Modelo CMMI na Dataprev”,
Rosana Osorio, Guilherme Motta (DATAPREV)
Exposição de Ferramentas
17:30-18:00
18:00-18:30
18:30-19:00
19:00-20:00
Palestra de Guilherme Horta Travassos (UFRJ/COPPE) - “iMPS – Rodada 4: Variação de Desempenho nas
Empresas que Adotaram o Modelo MPS de 2008 a 2011”
Reunião Coordenadores de II, de IA e IOGE
WAMPS 2011
13
4ª feira - 26 de outubro de 2011
8:00–8:30
8:30–9:00
9:00–9:30
9:30–10:00
Palestra de Cristina Machado
(CELEPAR / QUALITYFOCUS):
“Como verificar se a empresa está pronta
para avaliação inicial”
10:00-10:30
Curso “Medição e Definição de Indicadores”
(Monalessa Barcellos)
Intervalo
10:30-11:00
Artigo aceito 10: “Experiência de
Implantação de Melhoria de Processos
de Software em um Laboratório de
Pesquisa”, Fabiana Mendes, Jackeline
Almeida , Egio Junior (Universidade
Federal do Mato Grosso, Universidade
Federal de Goiás )
11:00-11:30
Artigo aceito 11: “Portal EduES 2.0: Uma
Ferramenta para Apoiar a Gerência de
Reutilização no Domínio de Educação
em Engenharia de Software”, Hudson
Borges, Rafael Santo, Rodrigo Santos,
Heitor Costa, Claudia Werner (Federal
University of Lavras, COPPE / UFRJ)
11:30-12:00
Artigo aceito 12: “Aderência do IBM
Rational Team Concert ao MR-MPS Uma análise com ênfase em gerência
de configuração”, João Felipe Santos
Condack (PrimeUp)
12:00-12:30
14:00-14:30
Exposição de Ferramentas
Continuação do Curso
“Medição e Definição
de Indicadores”
(Monalessa Barcellos)
Exposição de Ferramentas
Almoço
Exposição de Ferramentas
Palestrante Internacional:
Fernando Brito e Abreu, Instituto Universitário de Lisboa (ISCTE-IUL) & CITI/FCT/UNL
“The cloud paradigm: Are you tuned for the lyrics?”
14:30-15:00
15:00-15:30
15:30-16:00
Intervalo
16:00-16:30
Artigo aceito 13: “Revisão sistemática sobre a comunicação dentro
do processo de desenvolvimento de software”, Taciano Moraes,
Juliano Oliveira, Adriana Silveira de Souza (Universidade Federal de
Goiás - PUC GOIÁS - Estratégia Tecnologia da Informação)
16:30-17:00
Artigo aceito 14: “Implantação do Nível F do MR-MPS Combinando
Características do Processo Unificado com Práticas SCRUM”,
Tatiane Silva , Rogério Magela, Gleison Santos, Natália Chaves Lessa
Schots, Ana Regina Rocha (Athenas Software, Unirio, COPPE/UFRJ)
17:00-17:30
Encerramento do WAMPS 2011
14
Exposição de Ferramentas
Exposição de Ferramentas
Almoço
12:30-14:00
Exposição de Ferramentas
WAMPS 2011
Exposição de Ferramentas
“Reunião RELAIS
- Aquisição
de Software
entre SOFTEX e
representantes da
Colômbia, México
e Peru”
Exposição de
Ferramentas
Exposição de
Ferramentas
Programação do WAMPS 2011
5ª feira - 27 de outubro de 2011
8:30-10:00
“Curso de Melhoria do Processo de Aquisição de Software (C4-MPS.BR)”
10:00-10:30
Intervalo
10:30-12:30
Continuidade do “Curso de Melhoria do Processo de Aquisição de Software (C4-MPS.BR)”
12:30-14:00
Almoço
14:00-15:30
Continuidade do “Curso de Melhoria do Processo de Aquisição de Software (C4-MPS.BR)”
15:30-16:00
Intervalo
16:00-17:30
Continuidade do “Curso de Melhoria do Processo de Aquisição de Software (C4-MPS.BR)”
17:30-18:30
Palestra Edmeia Leonor Pereira de Andrade (EMBRAPA) “Processo de Contratação de Serviços de TI para Organizações Públicas”
6ª feira - 28 de outubro de 2011
8:30-10:00
Continuidade do “Curso de Melhoria do Processo de Aquisição de Software (C4-MPS.BR)”
10:00-10:30
Intervalo
10:30-12:30
Continuidade do “Curso de Melhoria do Processo de Aquisição de Software (C4-MPS.BR)”
12:30-14:00
Almoço
14:00-15:30
Continuidade do “Curso de Melhoria do Processo de Aquisição de Software (C4-MPS.BR)”
15:30-16:00
Intervalo
16:00-20:00
Continuidade do “Curso de Melhoria do Processo de Aquisição de Software (C4-MPS.BR)”
WAMPS 2011
15
Palestrantes convidados
Perspectivas para Ciência, Tecnologia e Inovação
no Brasil 2010-2020
Jorge Audy, Dr.
[email protected]
Pró-Reitor de Pesquisa e Pós-Graduação da PUCRS
A década de 2000 apresentou indiscutíveis avanços na área de Educação Superior em nosso
país, em especial no tocante ao aumento do número de alunos no ensino superior, avanços nas
regulamentações do CNE (Conselho Nacional de Educação), crescimento sem precedentes das IES
públicas federais, criação dos IFETs (Instituições Federais de Educação Tecnológica), crescimento da
pós-graduação e da pesquisa brasileria, consolidação do papel das boas IES comunitárias no país,
ampliação do ensino à distância (EAD), dentre outros aspectos relevantes. Por outro lado, ampliou-se
o problema da extrema judicialização dos processos envolvendo as áreas de ensino e pesquisa, seja
pelos marcos legais instáveis ou incompletos, seja pela postura das áreas de controle dos níveis de
governo e das principais agências de fomento.
Para a próxima década temos enormes desafios a superar, na definição de um novo sistema de
avaliação na educação superior brasileira, tendo por base a qualidade e relevância, a expansão do
acesso com qualidade e inclusão, políticas afirmativas consequentes e alinhadas com as demandas da
comunidade, redefinição do modelo de Educação Superior brasileiro, em função do esgotamento do
modelo atual, a ampliação das vagas nas IES públicas, a redefinição da tipologia de IES no país, com
a incorporação do conceito de IES comunitária, como instituição pública não estatal, a atuação das
instituições chamadas de no SNES (Sistema Nacional de Educação Superior) e o papel da inovação
no desenvolvimento nacional, dentre outros aspectos relevantes.
Nestes primeiros anos da década temos importantes esforços do Governo Brasileiro e do SNES como
um todo no sentido de identificar os temas e debater os principais desafios para os próximos anos.
A discussão do PNE 2011-2020 (Plano Nacional de Educação) em desenvolvimento no Congresso
Nacional, o recentemente elaborado Livro Azul, como resultado da IV Conferência Nacional de Ciência,
Tecnologia e Inovação realizada pelo MCT e pelo CGEE no ano de 2010, o documento Brasil 2022,
elaborado pela Secretaria de Assuntos Estratégicos da Presidência da Republica, bem como o PNPG
2011-2020 (Plano Nacional de Pós-Graduação) elaborado pela Capes e diversos estudos e eventos
organizados pelo CGEE, CNE, FOPROP, dentre outras entidades representativas da área de Educação
Superior sugerem a construção de consenso que poderá trazer bons frutos para o SNES como um todo.
No nível internacional, o Comunicado da Conferência Mundial de Educação Superior, organizada
pela UNESCO e realizada em Paris, analisou as conquistas e desafios da ES no mundo na década de
2000 e apontou os caminhos e desafios a serem vencidos na década de 2010, tendo por tema a nova
dinâmica da educação superior e da pesquisa para a mudança e o desenvolvimento da sociedade.
Este documento deverá ser o principal balisador das ações dos países membros da UNESCO para esta
década, sendo que o Brasil foi um dos principais protagonistas nesta Conferência.
16
WAMPS 2011
Perspectivas para Ciência, Tecnologia e Inovação no Brasil 2010-2020
Dentre as reflexões centrais em desenvolvimento podemos destacar as seguintes:
1. Discussão profunda e revisão do modelo atual de Educação Superior, considerando sua
repercussão tanto no setor público como privado, reforçando o papel fundamental das IES
públicas para se atingir as metas e os indicadores de qualidade estabelecidas no PNE, bem
como reconhecendo as experiências das IES comunitárias sem fins lucrativos, de caráter público
não estatal, que podem atuar de forma complementar e alinhada com as IES públicas estatais,
com alta qualidade e fundamentais para o desenvolvimetno de suas regiões e para o país;
2. Compreensão dos impactos e do papel da emergência da terceira missão da Universidade,
expandindo seu foco tradicional no ensino e na pesquisa e agregando à sua missão a
atuação direta no processo de desenvolvimento da sociedade, por meio da inovação e do
empreendedorismo;
3. Compreensão das mudanças na sociedade, com a passagem de uma sociedade industrial
que se organizou como uma sociedade do trabalho, para a sociedade moderna, que está
se organizando como uma sociedade do conhecimento. Neste sentido, deve-se resignificar a
Universidade para a geração de conhecimentos aplicáveis, as organizações para sua função
social e o Estado para articular os atores envolvidos, no contexto do modelo da Tripla Hélice.
Dentre os desafios, podemos destacar os seguintes:
1. Definição dos principais desafios na área de ensino, com foco na demanda por novas
metodologias de ensino e novas abordagens pedagógicas, no contexto das novas tecnologias
aplicadas à área de educação, do resgate dos trabalhadores que estudam a noite, que requerem
novas abordagens de ensino e que forme profissionais com empregabilidade, a questão da
ampliação do acesso com qualidade, dentre outros.
2. Definição dos principais desafios na área de pesquisa, com foco no entendimento da área de
pesquisa como o fundamento para a construção de uma instituição de educação superior de
qualidade e relevante para a sociedade, a questão da pesquisa em rede e do compartilhamento
de recursos, dentre outros.
3. Definição dos principais desafios na área de extensão, com foco na definição do seu papel, a
atuação junto às comunidades e os mecanismos mais adequados para a necessária transferência
de conhecimentos gerados pelo ensino e pela pesquisa para a sociedade, dentre outros.
4. Definição dos grandes desafios comuns das áreas de ensino, pesquisa e extensão, com foco na
internacionalização, na interdisciplinariedade, na interação entre ensino, pesquisa e extensão,
na articulação entre a Educação Básica e a Educação Superior e nos enormes desafios nas áreas
de licenciaturas e engenharias para o desenvolvimento do país (seja na educação fundamental
– licenciaturas ou no desenvolvimento econômico - engenharias e áreas tecnológicas) e o
processo de judicialização da educação superior.
Finalmente, podemos destacar as recomendações do Livro Azul, resultante da IV Conferencia
Nacional de C,T&I, que identificou na inovação e na sustentabilidade os principais imperativos
para um desenvolvimento brasileiro sustentável na próxima década. Entendendo desenvolvimento
sustentável como um processo de transformação e mudança, em contínuo aperfeiçoamento,
envolvendo múltiplas dimensões – econômica, social, ambiental e política. Caracteriza-se como um
WAMPS 2011
17
Palestrantes convidados
processo essencialmente dinâmico, que apresenta ênfases diversas no tempo e pode trilhar caminhos
diferenciados segundo as escolhas de sociedades histórica e geograficamente forjadas. No atual
contexto histórico, a inovação emerge como uma das contribuições mais determinantes na busca de
um desenvolvimento sustentável efetivo em suas múltiplas dimensões.
Para construção desta sociedade alicerçada em um processo de desenvolvimento sustentável, o Brasil
precisa de uma revolução na sua educação, o que pressupõe uma política de Estado continuada,
que envolva os diversos níveis de governo e a atuação articulada dos diversos atores da sociedade,
visando o aprimoramento do sistema nacional de educação brasileiro em seu conjunto, para fazer
frente aos enormes desafios que o desenvolvimento econômico e social apresenta no contexto da
Sociedade do Conhecimento na qual vivemos.
Jorge Luis Nicolas Audy
Possui Graduação em Análise de Sistemas de Informação pela PUCRS (1983), Mestrado na área
de Sistemas de Informação pela UFRGS (1990), Especialização em Gestão de Artes e Tecologias
Multimídia pela PUC Rio de Janeiro e IBM (1992) e Doutorado na área de Sistemas de Informação
pela UFRGS (2001). Atualmente é Professor Titular da Faculdade de Informática e do Programa de
Pós-Graduação em Ciência da Computação e Pró-Reitor de Pesquisa e Pós-Graduação da PUCRS.
Tem atuação como docente e pesquisador na área de Ciência da Computação, com linhas de
pesquisa em Engenharia de Software, Sistemas de Informação, Desenvolvimento Distribuído de
Software (DDS/GSD), Qualidade de Software e Gerência de Projetos. Tem experiência em Gestão de
Ciência, Tecnologia & Inovação (C,T&I), nas áreas de Inovação Tecnológica, Ambientes de Inovação
(Parques Científicos e Tecnológicos) e Interação Universidade, Empresa & Governo (Transferência de
Conhecimento). Membro do Conselho Superior Deliberativo do CNPq (MCT), do Conselho Estadual
de Ciência e Tecnologia do Estado do Rio Grande do Sul, do Conselho Deliberativo do CGEE (Centro
de Gestão e Estudos Estratégicos do MCT) e do Conselho do Portal de Periódicos da CAPES. Diretor
da ANPROTEC (Associação Nacional das Entidades Promotoras de Empreendimentos Inovadores).
Avaliador do MEC / INEP nas áreas de Ciência da Computação e Institucional e membro da SBC Sociedade Brasileira de Computação, SBPC, AIS - Association for Information Systems, IEEE e ACM.
18
WAMPS 2011
Perspectivas para Ciência, Tecnologia e Inovação no Brasil 2010-2020
WAMPS 2011
19
Palestrantes convidados
The cloud paradigm: Are you tuned for the lyrics?
Fernando Brito e Abreu
DCTI / Instituto Universitário de Lisboa (ISCTE-IUL)
& QUASAR / CITI / FCT / Universidade Nova de Lisboa
Abstract: Major players, business angels and opinion-makers are broadcasting beguiled lyrics on the most
recent IT hype: your software should ascend to the clouds. There are many clouds and the stake is high.
Distractedly, many of us became assiduous users of the cloud, but perhaps due to the legacy systems and
legacy knowledge, IT professionals, mainly those many that work in business information systems for the
long tail, are not as much plunged into producing cloud-based systems for their clients.
This keynote will delve into several aspects of this cloud paradigm, from more generic concerns regarding
security and value for money, to more specific worries that reach software engineers in general. Do we need
a different software development process? Are development techniques and tools mature enough? What
about the role of open-source in the cloud? How do we assess the quality in cloud-based development?
Please stay tuned for more!
Stairway to heaven (Jimmy Page & Robert Plant, Led Zeppelin)
Cloud computing refers to the on-demand provision of computational resources (data and software)
via the Internet, rather than from a local computer. Cloud users can submit a task, such as searching
for a part in the company’s inventory, to the service provider, without possessing the database and
the stock management software in its premises. The client’s computer may contain only a browser
and a minimal operating system. Since the cloud is the underlying delivery mechanism, cloud-based
applications and services may support any type of software application or service in use today.
This on-demand delivery model is being increasingly used in many business applications, including
accounting, collaboration, customer relationship management (CRM), enterprise resource planning
(ERP), invoicing, human resource management (HRM), content management (CM) and service desk
management.
One day I woke up and realized my data and software are indeed ascending to the clouds. Many of
my important documents are in the Dropbox. My slides are on Slideshare. My written messages follow
their way on Gmail and my spoken ones go through Skype. I keep in touch with my peers in LinkedIn
and with my friends on Facebook. I schedule my meetings in Doodle and I do cooperative work
with GoogleDocs. I teach my students to work in software engineering projects using Sourceforge
or GoogleCode. In all cases these are cloud-based services. I hold a private account in all of them,
and someone must be paying for it, since I am not. I am happy to possess the gift of being able to
communicate with that remote and distributed soul of my computer, but sometimes I wonder where
my data physically is and how will I manage if I lose contact with it.
20
WAMPS 2011
The cloud paradigm: Are you tuned for the lyrics?
Could computing data centers used by cloud service providers are usually not open for tours, but
those providers tell us not to be like Thomas, the Jesus disciple, who somehow missed the first
appearance of Jesus after his resurrection. We should have faith that our assets are well protected!
However, it has been pointed out that most cloud providers do not even own and operate the
platforms they provide you service on. Instead, they use shared infrastructures, so cross-pollination
of service provisioning could affect portability, reliability and security. In doubt, I try to keep a copy of
my critical stuff in a large (and cheap) storage at home, but that requires discipline. Who will do that
in a small to medium sized enterprise (SME) that bought the concept of cloud computing as a way of
cutting costs with a local IT infrastructure, and therefore has no dedicated operation staff?
Money (Roger Waters, Pink Floyd)
As a private user I (still) do not pay for those aforementioned cloud services. What will I do if their
providers decide to suspend this “free” lunch? At this point I will hear the unison scream of all
individual cloud users: we are already paying the bill by being bombarded with web advertising
associated with those cloud services! And we are asked to pay if we want to get beyond the basic
service. OK, it is fair, so let us have faith that the “basic” service that hooked millions of us on those
cloud services will keep being provided for free. I cannot live without some essential commodities
such as water, electricity, gas, insurance, cleaning, tv and web assess, but I would not be willing to
pay 10 extra bills, one for each of the aforementioned cloud services I am currently using. However,
we must be aware that, since it is easy to control the access to cloud-based applications, some major
players in the horizontal arena (general-purpose programs addressing the needs of many people) see
the cloud as an opportunity to get rid of their haunting nightmare of software piracy.
There is another economic concern that assaults my spirit. Usually we do investments that are
supposed to pay themselves in the medium to the long run. That is what we expect when buying real
estate, or when a farmer buys seeds and fertilizer, or when the owner of a factory purchases a new
machine for his plant, or even when we pay the fees of a good school for our children. All of these
ventures seek to reach the break-even point, the point in time where the return on investment (ROI)
becomes positive. That logic is the same for those big players that in recent years have invested multibillion dollars in setting up impressive data centers (e.g. Amazon, Google, Microsoft or Salesforce).
Who will guarantee their ROI? Big companies (e.g. telcos, banks, insurance, big wholesalers) will have
their privately held clouds, both because they have the know-how and can afford it, and because
they are very much concerned with securing their assets. SMEs are much more prone to buy the
concept of cloud computing and they represent a large proportion of the whole market in most
countries nowadays. This is the basis of the Long Tail theory. However, note that the ROI rationale is
sold upside down by cloud providers. Pay attention to NIST1 definition of cloud computing:
“Cloud computing is a model for enabling convenient, on-demand network access to a shared pool of
configurable computing resources (e.g., networks, servers, storage, applications, and services) that can
be rapidly provisioned and released with minimal management effort or service provider interaction.”
National Institute of Standards and Technology, an American agency in the Technology Administration that makes measurements and sets standards
as needed by industry or government programs.
1
WAMPS 2011
21
Palestrantes convidados
The message forwarded to SME administrators is the following: cloud computing customers do not
own the physical infrastructure, instead avoiding capital expenditure by renting usage from a thirdparty provider. They consume resources as a service and pay only for resources that they use. Cloud
computing users can avoid capital expenditure (CapEx) on hardware, software, and services when they
pay a provider only for what they use. Consumption is usually billed on a utility (resources consumed,
like electricity) or subscription (time-based, like a newspaper) basis, with little or no upfront cost. The
idea of not having to make an initial investment is tempting for our SME executives. Paying a variable
amount depending on the number of transactions seems fair, because more transactions mean more
business. Sometimes they forget that the volume of data stored will be an ever-increasing portion of
their cloud bill and will not decrease when business will slow down. Perhaps more worrying should
be the argument of the minimal bootstrap effort. What is the cost of reverting that model to a cloudcomputing based approach? One obvious cost will be that of migrating legacy databases required to
keep doing business as usual. And what about migrating to the cloud the customized applications
that are often found in SMEs?
The times they are a-changin’ (Bob Dylan)
A pervasive thought of all SME stakeholders is increasing productivity and that can be achieved if they
cut on labor costs. Most SMEs invested in their computerization in the latter quarter of the twentieth
century. They have some IT staff or external consultants that guarantee the smooth operation and
the evolution of their applications, when requirements change. Cloud computing sounds as a
great opportunity to get rid of those costs and attain a better ROI. Globally, the consequences of
a widespread adoption of cloud computing in the IT labor market for SMEs may seem devastating.
Moreover, we will not need to train as many software engineers as we do today. Maybe I even face
the risk of getting out of business as a computer science professor. I will share with you some reasons
why we should not be scared with this scenario. However, some action will be required, or somebody
will take the cheese away from you.
The first thing we must rationalize is where in the cloud puzzle we can play our role as an IT
professional. Cloud services are provided at three levels of abstraction: infrastructure, platform and
software. Let us have a look at each one of them separately.
Infrastructure-as-a-Service (IaaS) stands for delivering a platform virtualization environment as a
service, along with scalable raw storage and networking capabilities. Rather than purchasing servers,
data-center space or network equipment, clients buy those resources as a fully outsourced service. The
suppliers typically bill such services on a utility computing basis. The amount of resources consumed
(and therefore the cost) will typically reflect the level of activity.
Platform-as-a-service (PaaS) is the most important level of abstraction for software developers in the
cloud since it encompasses the provision of all facilities required to support the complete life cycle
of building and delivering cloud applications / services. Those facilities include tools for application
design, development, testing and deployment, web service integration and marshalling, database
integration (providing persistence, transactions, security and concurrency capabilities), application
versioning, issue tracking and team collaboration. The orchestration and integration of these services
is of utmost importance, since that is how we define and deploy a software process.
22
WAMPS 2011
The cloud paradigm: Are you tuned for the lyrics?
Software-as-a-Service (SaaS) is the on-demand software delivery model in which software and its
associated data are hosted centrally (in the cloud) and are typically accessed by users using a thin
client (usually a web browser). SaaS corresponds to the business / users perspective that we have
already tackled in a previous section, so we will not go any further on this.
In retrospect, IaaS is mostly a matter for systems engineers and networks administrators, while SaaS
is largely an issue for users, marketing staff and business administration staff. Let us then concentrate
on what software engineers should care the most. PaaS enables you to create cloud applications,
without the cost and complexity of buying and managing the underlying software/hardware. In my
talk I will briefly overview the following mainstream PaaS platforms:
• Amazon Web Services (AWS)
• Google App Engine
• Microsoft Windows Azure
• Force.com platform
• IBM SmartCloud platform
Free as a bird (John Lennon, The Beatles) or Hotel California (The Eagles) ?
While the major players are interested in hooking you to their proprietary solutions, therefore
guaranteeing that once you are in their cloud you will never get out, like in Hotel California, the
open source community is fighting back with open solutions. One aspect of this open movement
is the ability for companies to build their own “private clouds”. A private cloud is an infrastructure
operated solely for a single organization, whether managed internally or by a third-party and
hosted internally or externally. Big cloud players are usually not pleased with this concept and the
opinion-makers on their behest argue that with a private cloud, a user company will still have to
buy, build, and manage it, therefore not benefiting from lower up-front capital costs and less handson management. Fortunately, this is not entirely true, due to some important ventures such as the
Eucalyptus open-source project2 that has developed an IaaS solution for private clouds that matches
AWS API specifications. By September 2011 it had allowed to deploy more than 25,000 on-premise
clouds.
On the PaaS side, there are very interesting open-source ventures, as well. In this keynote, I will briefly
go through the following platforms:
• VMware’s Cloud Foundry
• WSO2’s StratosLive
• RedHat’s OpenShift
2
at the University of California at Santa Barbara, home of 5 Nobel laureates.
WAMPS 2011
23
Palestrantes convidados
Good is Good (Sheryl Crow) or Bad (Michael Jackson) ?
We are used to assess software quality according to two perspectives: product quality and process
quality.
The bottom-line will always be striving for good software products. Several software quality models
have been proposed in the literature and industry has reached some consensus with the ISO/IEC 9126
standard that defines software quality characteristics, both on the users’ and developers’ viewpoints.
Taking the users’ viewpoint, the ISO/IEC 9126 Software Quality in Use model proposes four
characteristics: Effectiveness, Productivity, Safety and Satisfaction. In this keynote, I will go through
each of those characteristics to conclude that there are few noticeable distinctions when comparing
to non-cloud-based software products.
Regarding developers’ viewpoint, the ISO/IEC 9126 standard defines a quality model composed of six quality
characteristics: Functionality, Reliability, Usability, Efficiency, Maintainability and Portability. Each characteristic
is subdivided into sub-characteristics and further described by using appropriate external and internal quality
attributes that can be measured by using specified metrics. I will go through each of the aforementioned
characteristics and try to identify the most distinctive ones for cloud-based software. Will we need to extend
this set of characteristics to encompass specific aspects of cloud computing applications?
Last, but not the least, we get to the other software quality perspective: process quality! Product quality
cannot be achieved consistently without a well-defined process. Several process quality assessment
and improvement frameworks, such as SPICE, CMMI or the MPS.Br, have been proposed. These
frameworks rely on the identification of best practices on software development resulting from lessons
learnt for more than two decades. Before assessing the cloud development process, we have to discuss
if the “old” best practices still apply and/or identify other relevant practices that are specific to the
cloud-based software development lifecycle. I believe this is where Software Engineering researchers
still need to dig a lot, mainly by launching action research endeavors in cloud-based projects.
Fernando Brito e Abreu
Fernando Brito e Abreu holds a PhD on Computer Science, a MSc and a BSc on Telecommunications
and Computer Engineering, all from the IST (Lisbon Technical University). He is currently an associate
professor at the Department of Information Sciences and Technologies of the ISCTE-IUL, a public
university in Lisbon, Portugal. He was formerly assistant professor at the Department of Informatics
of the Faculty of Sciences and Technology of the Universidade Nova de Lisboa and in the past he
also lectured at ISEGI/UNL, IST/UTL, ISEG/UTL and in the Portuguese Air Force Academy. He was also
an invited professor at the Département Informatique of the École des Mines de Nantes during a
decade, in the scope of the European master program EMOOSE. In the mentioned universities he has
been responsible and lecturer for courses on software engineering, software architectures, systems
analysis, object-oriented design, object-oriented programming, experimental software engineering
and product and process quality.
As a researcher, first at INESC Lisbon and since 2001 at CITI (Research Center for Informatics and
Information Technologies) at FCT/UNL, he produced over two hundred scientific and technical
24
WAMPS 2011
The cloud paradigm: Are you tuned for the lyrics?
documents. Among the latter are over 20 papers on journals such as: Science of Computer
Programming, Journal of Systems and Software, IEEE Latin America, Object Expert, Computer
Standards & Interfaces, ERCIM News, Personal Computer World, L’Objet, Qualirama, Sistemas de
Informação and Interface. At CITI he leads the QUASAR (QUantitative Approaches in Software
engineering And Reengineering) research team, where around twenty graduations (including 4 PhDs)
were, or are being, concluded under his supervision. QUASAR focuses on quantitative aspects on
software engineering and reengineering. At CITI, he also heads the team-project VALSE (VALidation of
Software Engineering methods, techniques and tools). A selection of his publications and supervised
dissertations can be accessed at the QUASAR or VALSE web sites.
He was the president of CS/03 (Sectorial Committee for Quality in Information and Communication
Technologies) of the Portuguese Institute for Quality, during 8 years. He is now the Portuguese
delegate at IFIP TC2 (Software: Theory and Practice), presided by Bertrand Meyer. He is member of
the editorial board of the Software Quality Professional journal (American Society for Quality) and a
regular reviewer in major international journals, conferences and workshops worldwide, and research
project proposals. He has served in the organization of many scientific meetings as member of the
steering committee, organizing chair, program chair, program committee member, demonstration
chair, keynote or tutorial speaker, panel member or session chair.
In the scope of applied research, he has promoted the celebration of several collaboration protocols,
namely between: (i) INESC and the Portuguese Navy, (ii) CS/03 and itSMF Portugal, (iii) NAV (Portuguese
Air Traffic Management Authority) and FCT/UNL, and (iv) SINFIC and FCT/UNL. Besides the projects
developed in the scope of these protocols, he has participated in several scientific projects funded by
the European Commission, the Portuguese Foundation for Science and Technology, as well as other
academic extension projects in the Portuguese Post Office, Portugal Telecom or the National Republic
Assembly (Portuguese parliament).
His current research interests are centered in the following two research threads, more specifically in
the identified topics:
- Software Engineering / Information Systems thread:
Visualization and assessment of complex software systems; assessment of the impact of technological
migration (e.g. from objects to aspects); reengineering of legacy information systems by applying
refactoring and pattern-based techniques; model-based development; web engineering; experimental
software engineering.
- IT Service Management / Services Science thread:
Assessment of process complexity; ontologies for IT services; incident management forecasting
models; IT service level management; assessment of service-oriented architectures.
In the above-mentioned research threads he has applied several modeling and meta-modeling
techniques, the formalization of quantitative indicators by using a constraints language, data analysis
techniques (e.g. classificatory analysis, regression models, and time series) and tests of hypotheses.
WAMPS 2011
25
Palestrantes convidados
iMPS – Rodada 4:
Variação de Desempenho nas Empresas que
Adotaram o Modelo MPS de 2008 a 2011
Guilherme Horta Travassos1 e Marcos Kalinowski2
COPPE/UFRJ1 - Programa de Engenharia de Sistemas e Computação
Caixa Postal 68511 – CEP 21945-970 – Rio de Janeiro, Brasil
[email protected]
Kali Software2 - Centro Empresarial Mourisco, Praia de Botafogo 501, 1° Andar
Bloco Pão de Açucar – CEP 22250-040 – Rio de Janeiro, Brasil
[email protected]
Resumo. Este artigo apresenta uma descrição dos resultados da quarta rodada do iMPS (informações para
acompanhar e evidenciar variação de desempenho nas empresas que adotaram o Modelo MPS). Neste quarto
ano de coleta de dados, os resultados são apresentados sob quatro perspectivas: caracterização 2011, análise
de variação 2010/2011, análise de variação 2009/2010/2011 e análise de variação 2008/2009/2010/2011. De
forma geral, a satisfação das empresas se mantém alta, com aproximadamente 97% das empresas informando
estar totalmente ou parcialmente satisfeitas com o modelo MPS. Em relação ao retorno de investimento da
adoção do modelo, mais de 50% das empresas informaram ter recuperado nos últimos 12 meses mais do que
o investimento feito na implementação e avaliação do modelo. Os indicadores de variação de desempenho
para as empresas que adotaram o modelo MPS ao longo dos anos indicam que possivelmente empresas que
se mantêm persistentes na utilização das práticas da engenharia de software promovidas pelo modelo MPS
tem sido capazes de lidar com projetos maiores, em maior número e com maior controle.
1. Introdução
O programa MPS.BR representa uma iniciativa concreta para melhorar a capacidade de desenvolvimento
de software nas empresas Brasileiras. Seu objetivo é desenvolver e disseminar um modelo de
referência brasileiro para a melhoria de processos de software (MPS) visando estabelecer e oferecer
para as organizações, incluindo as pequenas e médias empresas, um caminho economicamente
viável que as permita alcançar os benefícios da melhoria de processos e da utilização de boas práticas
da engenharia de software em um intervalo de tempo razoável.
O modelo de referência MPS foi desenvolvido com base em normas internacionais, modelos reconhecidos
pela comunidade, boas práticas da engenharia de software e, principalmente, as necessidades de
negócio da indústria de software brasileira. Em relação a empresas avaliadas, no dia 15 de Setembro
de 2011 chegou-se ao marco de 300 avaliações MPS concluídas e publicadas no site da SOFTEX. Os
resultados destas avaliações estão disponíveis na seção Avaliações em www.softex.br/mpsbr.
A adoção do modelo MPS pelas empresas brasileiras promove o interesse por compreender os
resultados de desempenho obtidos por estas empresas, tais como prazo, produtividade, custo,
qualidade e indicações adicionais sobre evolução e oferecimento dos projetos de software no país
26
WAMPS 2011
iMPS – Rodada 4: Variação de Desempenho nas Empresas que Adotaram o Modelo MPS de 2008 a 2011
e exterior. Com este fim, o projeto iMPS (informações para acompanhar e evidenciar a variação de
desempenho nas empresas que adotaram o modelo MPS) foi iniciado em 2007. O objetivo global
do iMPS é periodicamente executar uma pesquisa de opinião (survey) para acompanhar e evidenciar
resultados de desempenho nas empresas de software que adotaram o modelo MPS. O plano do
estudo iMPS com base nos princípios da Engenharia de Software Experimental, os períodos previstos
para captura dos dados e organização da base histórica e o tratamento dado às ameaças à validade
podem ser encontrados em [Kalinowski et al., 2008]. Os resultados das rodadas anteriores (2008 –
referência inicial, 2009 e 2010) do iMPS estão disponíveis na seção Resultados de Desempenho em
www.softex.br/mpsbr.
Este artigo apresenta uma descrição geral dos resultados da quarta rodada iMPS. Os resultados
serão apresentados sob quatro perspectivas: caracterização 2011, análise de variação 2010/2011,
análise de variação 2009/2010/2011 e análise de variação 2008/2009/2010/2011. O objetivo da
caracterização é delinear o desempenho das empresas que adotaram o MPS em 2011. O das análises
da variação, por sua vez, é observar a variação do desempenho das empresas que adotaram o MPS
e permitir comparação com os resultados obtidos anteriormente. Como previsto no plano do estudo
iMPS, as análises de variação ocorrem apenas entre os dados da própria empresa, ou seja, a empresa
é comparada somente com ela mesma. Dados de desempenho individuais das empresas não são
divulgados e nem fazem sentido ser comparados.
O restante deste artigo está organizado da seguinte maneira. Na seção 2, os resultados da
caracterização 2011 são apresentados. Nas seções 3 a 5, os resultados iniciais das análises de variação
de desempenho das empresas com avaliação MPS vigente nos últimos anos são apresentados. As
considerações finais do artigo são apresentadas na seção 6.
2. Caracterização das empresas em 2011
A análise de caracterização visa delinear o desempenho das empresas que adotaram o modelo MPS em
2011. Assim, apenas dados entre 01/08/2010 e 31/07/2011 foram utilizados nesta análise. No total,
questionários de 133 empresas diferentes (8 iniciando a implementação, 32 em processo de avaliação,
49 avaliadas MPS nível G, 28 avaliadas MPS nível F e 16 avaliadas MPS níveis E-A) foram utilizados.
Tendo em vista a concentração da maioria das empresas nos níveis iniciais de maturidade e o ainda
limitado número de respostas obtidas para as empresas iniciando a implementação, optou-se por
dividir o conjunto de dados para a caracterização nas seguintes 4 categorias: Empresas em Processo
de Avaliaçã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.
Esta dimensão de análise agrega dados de diferentes empresas sendo natural que as medidas
apresentem desvios padrão muito altos. Assim, como previsto e anteriormente utilizado, a mediana
(representando o valor central para a medida) fornece informação mais adequada para a caracterização
das empresas e por isto vai ser novamente utilizada como referência. Entretanto, a média é também
usada durante a preparação dos dados para apoiar o descarte das medidas com valores a mais
de três desvios padrão da média (outliers) até que o conjunto final de dados não contenha mais
medidas nesta situação. Desta forma é possível aproveitar o máximo de respostas e ao mesmo tempo
WAMPS 2011
27
Palestrantes convidados
não influenciar os resultados com dados que possam eventualmente distorcer a mais ou a menos a
análise. Adotando este procedimento 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 previsto a
partir do nível F do MPS. Após o ajuste dos dados, os resultados a seguir foram obtidos para esta
dimensão de análise.
Satisfação com o Modelo MPS. Em relação à satisfação das 133 empresas com o modelo MPS,
64,66% (86 empresas) relataram estar totalmente satisfeitas com o modelo e 32,33% relataram
estar parcialmente satisfeitas. Nenhuma empresa relatou estar insatisfeita e 3,01% (4 empresas)
informaram ainda não conhecer o seu nível de satisfação com o modelo. Este resultado indica que a
grande maioria das empresas está satisfeita com o modelo MPS.
Tamanho dos Projetos. Em relação ao tamanho dos projetos, das 133 empresas consideradas, 46
(34,58%) mencionaram medir o tamanho de seus projetos em Pontos de Função. Outras medidas de
tamanho utilizadas foram Horas, utilizada por 25 empresas (embora esta medida não seja indicada
como uma medida interessante para tamanho de projeto tendo em vista as diferentes interpretações
e abordagens de medição que podem ser
aplicadas) e Pontos de Caso de Uso, utilizada
por 14 empresas.
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 em processo de
avaliação é de 225 Pontos de Função, a mediana
Figura 1. Mediana do tamanho dos projetos.
para as empresas nos níveis E-A é de 268,5.
Existe correlação positiva entre o aumento da mediana e o aumento do nível de maturidade MPS de
+0,53. Um comportamento parecido foi observado na rodada de 2010 (Travassos e Kalinowski, 2010).
Precisão de Estimativa de Prazo. Como muitas empresas informaram que o tempo médio gasto
nos projetos é igual ao prazo dos projetos (ou seja, precisão de estimativa 1), acreditamos que esta
variável seja melhor observada olhando a variação dentro de cada conjunto de empresas.
A Figura 2 ilustra esta variação, através de um boxplot, que destaca os valores máximo, mínimo
e a mediana. Nesta figura é possível observar
que as empresas de níveis de maturidade F e
E-A apresentaram uma menor variação e uma
precisão de estimativa mínima maior (variando
respectivamente entre 0,6 e 1 e entre 0,67
e 1) se comparadas as empresas em nível
de maturidade G. Ou seja, assim como na
caracterização de 2010, de acordo com as
informações coletadas as empresas de maior
maturidade informaram conseguir maior
precisão nas estimativas.
Figura 2. Boxplot da Precisão de Estimativa.
28
WAMPS 2011
iMPS – Rodada 4: Variação de Desempenho nas Empresas que Adotaram o Modelo MPS de 2008 a 2011
Produtividade. A produtividade está sendo observada de forma isolada. É importante lembrar que
a produtividade se mostra naturalmente diferente de acordo com o tipo de projeto e que esta medida
deve ser observada levando em consideração
também outras características, como a
qualidade1 e o custo2. Adicionalmente, o
cálculo da produtividade leva em consideração
outras medidas base que aparentam ser mais
confiáveis para empresas a partir do nível
F, que possuem um processo de medição
institucionalizado. Tendo em vista estas
considerações, a produtividade apresentou
correlação positiva com o aumento do nível
de maturidade do MPS de +0,40. A maior
mediana foi das empresas no nível F. A Figura 3 apresenta as medianas da produtividade dos projetos
das empresas que utilizam Pontos de Função para cada agrupamento utilizado no estudo. Repare
que o comportamento é bastante parecido com os obtidos nas rodadas anteriores iMPS considerando
diferentes grupos de empresas em cada ano.
Tendo apresentado estes resultados da caracterização das 133 empresas em 2011, a seção seguinte
apresentará o que pôde ser observado em relação à variação de desempenho entre 2010 e 2011 das
empresas que adotaram o MPS.
3. Variação de Desempenho das empresas no período 2010/2011
Das 133 empresas participantes da rodada 4 do iMPS, 92 empresas responderam ao questionário
periódico em 2011. Destas, 53 também haviam gentilmente fornecido informações na terceira
rodada, ou seja, no ano de 2010, e 27 empresas deste conjunto já haviam participado das rodadas
anteriores iMPS. Os indicadores de variação de desempenho e as fórmulas de cálculo são os mesmos
definidos no plano do estudo iMPS. Para efeito de comparação, apenas os indicadores planejados que
apresentem nível de confiança => 85% devem ser utilizados, de forma a permitir sua comparação
com as rodadas anteriores do iMPS. Por isso, nem todos os indicadores podem ser considerados
devido a não apresentarem níveis de confiança aceitáveis. Os motivos que levam a esta situação
estão relacionados a empresa não ter fornecido a informação sobre o indicador ou ter evoluído ou
modificado a forma de tratamento do indicador, como por exemplo, usar medidas com unidades
distintas em cada rodada. Entretanto, tendo em vista a importância dos indicadores relacionados à
Produtividade (ver seção 2) e Qualidade (número de defeitos) e considerando que o nível de confiança
destes indicadores está muito próximo do limite mínimo estabelecido, estes também foram incluídos.
A Tabela 1 apresenta os indicadores utilizados para este período de observação.
A qualidade é capturada nos questionários em função do 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.
1
O custo é capturado nos questionários em função de um percentual do faturamento, servindo como base de comparação da empresa com ela
mesma para a análise de variação.
2
WAMPS 2011
29
Palestrantes convidados
Tabela 1. Nível de Confiança nos Indicadores
Indicador
Nível de Confiança (%)
Faturamento
92,17
Mudança de Nível MPS
100,00
Custo Médio dos Projetos
90,56
Tempo Médio Estimado
95,09
Tempo Médio Gasto
95,57
Precisão de Estimativa
95,09
Tamanho Médio dos Projetos
93,38
Número de Clientes no País
96,64
Número de Funcionários
97,28
Número de Projetos no País
97,28
Produtividade
84,31
Qualidade
84,31
Assim como nas rodadas iMPS anteriores, o comportamento dos indicadores foi observado a partir
de distribuições organizadas e relacionadas a 3 faixas de valores categorizando o desempenho das
empresas em cada indicador. Estas faixas representam o percentual relativo de empresas (baseado no
número de respostas válidas) que informaram ter tido aumento, redução ou não sofreram alteração
num determinado indicador. A avaliação do significado do impacto do aumento ou redução depende
do indicador e, em algumas situações, pode ser relacionada com outro indicador. Por exemplo,
espera-se que o Custo Médio dos Projetos reduza ao mesmo tempo em que Produtividade aumenta.
Portanto, neste caso, tanto redução quanto o aumento representam impactos positivos para as
empresas em análise.
Como se pode observar na Figura 4, as empresas que adotaram o modelo informaram ter apresentado,
entre os anos de 2010 e 2011, aumento nos indicadores Faturamento, Número de Clientes, Número
de Projetos no País e Número de Funcionários. O comportamento destes indicadores é coerente
permitindo observar as tendências informadas para os outros indicadores, chamando atenção o
comportamento apresentado por Custo Médio do Projeto, Tempo Médio Gasto e Tamanho Médio
dos Projetos. Se observados em conjunto, estes comportamentos apontam para uma leve dissociação
positiva entre custo, tempo e tamanho. Ou seja, não necessariamente o projeto ser maior leva a mais
tempo ou custo. Consideramos este comportamento positivo e coerente com a idéia associada a
organização e controle dos processos de software.
30
WAMPS 2011
iMPS – Rodada 4: Variação de Desempenho nas Empresas que Adotaram o Modelo MPS de 2008 a 2011
100%
80%
Aumentou
60%
Não Alterou
40%
Reduziu
20%
lid
ad
e
Qu
a
Fa
tu
r
am
en
M
to
ud
an
ça
d
e Ní
Cu
ve
st
l
o M
Te
ed
m
io
po
P
ro
M
j.
éd
io
Es
tim
Te
ad
m
o
po
M
éd
io
Pr
G
ec
as
isã
to
o de
Ta
Es
m
tim
an
at
ho
iva
M
éd
io
d
os
P
No
ro
C
j.
lie
nt
es
n
o Pa
No
ís
Fu
nc
io
ná
No
rio
Pr
s
oj
et
os
n
o Pa
ís
Pr
od
ut
ivi
da
de
0%
Figura 4. Variação de Desempenho das 53 Empresas que Adotaram o MPS e Participaram da Pesquisa
Periódica iMPS em 2010 e 2011
Em relação ao retorno de investimento obtido por estas empresas, 26 empresas haviam fornecido
informações relativas a custos de implementação e avaliação (informações coletadas no contexto do
estudo iMPS durante o processo de avaliação) e a variação do faturamento (informação coletada no
questionário periódico), representando um nível de confiança de 86,0%. Entre estas, 50% informaram
ter aumentado seu faturamento nos últimos 12 meses o suficiente para recuperar completamente
o investimento realizado na implementação e avaliação do MPS (ROI > 100%). Outras 38,46%
informaram ter recuperado parcialmente o investimento realizado.
Considerando que o comportamento descrito anteriormente pode estar sendo influenciado por
empresas presentes nas rodadas anteriores do iMPS, apresentamos abaixo o comportamento de 23
empresas que participaram apenas das rodadas 2010 e 2011 do iMPS. Da mesma maneira, os indicadores
Produtividade e Qualidade não atingiram o nível de confiança previamente estabelecido (75,19% e
80,39% respectivamente), entretanto serão apresentados aqui a título de ilustração e comparação.
100%
80%
Aumentou
60%
Não Alterou
40%
Reduziu
20%
lid
ad
e
Qu
a
Fa
tu
ra
m
en
M
to
ud
an
ça
d
e Ní
Cu
ve
st
l
o M
Te
ed
m
io
po
P
ro
M
j.
éd
io
Es
t
im
Te
ad
m
o
po
M
éd
io
Pr
G
ec
as
isã
to
o de
Ta
Es
m
tim
an
at
ho
iva
M
éd
io
d
os
P
No
ro
C
j.
lie
nt
es
n
o Pa
No
ís
Fu
nc
io
ná
No
rio
Pr
s
oj
et
os
n
o Pa
ís
Pr
od
ut
ivi
da
de
0%
Figura 5. Variação de Desempenho de 23 Empresas que Adotaram o MPS e Participaram da Pesquisa
Periódica iMPS apenas em 2010 e 2011
WAMPS 2011
31
Palestrantes convidados
A sessão seguinte apresenta a análise de variação para empresas que mantiveram avaliações vigentes
do modelo MPS nos últimos três anos (2009/2010/2011).
4. Empresas com questionários periódicos nos anos de 2009, 2010 e
2011
Do conjunto de 92 empresas que responderam ao questionário periódico em 2011, 28 delas já
haviam fornecido informações para os anos passados de 2009 e 2010, sendo que 7 empresas
também participaram da primeira rodada iMPS e serão analisadas em separado (seção 5). Como
esperado, nem todas as questões puderam ser aproveitadas devido à evolução ou modificação da
maneira como alguns indicadores foram tratados pelas empresas. Mesmo assim, foi possível realizar
avaliação deste grupo e identificar aqueles indicadores que apresentavam nível de confiança aceitável
(=> 85%) e compatíveis com as rodadas anteriores do iMPS, conforme mostrado na Tabela 2.
Tabela 2. Nível de Confiança nos Indicadores
Indicador
Mudança de Nível MPS
Nível de Confiança (%)
100
Custo Médio dos Projetos
86,20
Tempo Médio Estimado
91,09
Tempo Médio Gasto
92,92
Precisão de Estimativa
91,09
Tamanho Médio dos Projetos
89,41
Número de Clientes no País
91,09
Número de Funcionários
92,92
Número de Projetos no País
95,12
De forma a fornecer uma maneira isenta para comparação, para cada empresa foi calculada a
inclinação da reta formada pelo conjunto dos 3 pontos (ano, valor) fornecido para cada indicador
por cada uma delas, observando-se a consistência das unidades de medida. A inclinação da reta
indica a tendência de crescimento (valor positivo), redução (valor negativo) ou estabilidade (zero
ou muito próximo de zero) de um determinado indicador. Os resultados foram então usados para
agrupar as empresas de acordo com as categorias previamente definidas, resultando nas distribuições
apresentadas na Figura 6.
32
WAMPS 2011
iMPS – Rodada 4: Variação de Desempenho nas Empresas que Adotaram o Modelo MPS de 2008 a 2011
Neste grupo de 21 empresas e ao longo destes 3 anos, 29% realizou Mudança de nível MPS. Entre
elas, o nível mais baixo é G (7 empresas) e o mais alto C, sendo o nível F mais frequente (9 empresas).
Das empresas consideradas, 67% apresentam tendência à redução no Custo Médio dos Projetos, 77%
apresentam tendência de estabilidade ou aumento no Tempo Médio Estimado e 84% apresentam
tendência de estabilidade ou aumento do Tempo Gasto nos Projetos. Estes comportamentos parecem
indicar uma melhor compreensão e controle por parte das empresas em seus projetos, permitindo
ter maior percepção sobre o problema a ser desenvolvido. O mesmo comportamento pode ser
observado se considerada a tendência apresentada pelo indicador Precisão de Estimativa, onde 89%
das empresas informaram apresentar estabilidade ou melhoria nas estimativas. Das 21 empresas,
83% informaram ter ocorrido estabilidade ou aumento do Número de Clientes, 65% mantiveram
ou aumentaram o Número de Funcionários. Ao se observar o indicador Número de Projetos no País
percebe-se que 53% das empresas apresentaram tendência de redução neste número. Entretanto,
este indicador não pode ser observado isoladamente. Esta redução no Número de Projetos pode
estar sendo compensada pelo aumento no Número de Clientes. Acreditamos que análises adicionais
precisam ser realizadas para tratar estes resultados.
Desempenho 2009-­‐2011 ( 21 empresas)
100%
90%
80%
70%
60%
50%
40%
30%
20%
10%
0%
M
ud
an
ça
d
e Cu
Ni
st
ve
o l M
M
éd
PS
io
d
os
P
Te
ro
m
je
po
to
M
s
éd
io
E
st
im
Te
ad
m
o
po
M
éd
io
Pr
G
ec
as
isã
to
o Ta
de
m
E
an
st
ho
im
M
at
éd
iva
io
d
os
P
ro
je
No
to
s
C
lie
nt
es
n
o Pa
ís
No
Fu
nc
io
ná
No
rio
P
s
ro
je
to
s n
o Pa
ís
Aumentou
Não Alterou
Reduziu
Figura 6. Indicadores de Variação de Desempenho 2009-2011 para 21 empresas
WAMPS 2011
33
Palestrantes convidados
5. Empresas com questionários periódicos nos anos de 2008, 2009,
2010 e 2011
Este subgrupo está composto por 7 empresas que preencheram os questionários de acompanhamento
nos anos de 2008 a 2011. Elas não foram incluídas na análise do grupo anterior (2009-2011). Da
mesma forma, nem todas as informações puderam ser observadas e apenas os indicadores que
apresentaram nível de confiança >= 85% foram considerados. A Tabela 3 apresenta os indicadores e
os níveis de confiança para este conjunto de empresas. As tendências, como calculado para o grupo
anterior, foram extraídas da inclinação da reta formada neste caso pelo conjunto de 4 pontos (ano,
valor) fornecido por cada empresa para o indicador e obedecendo a consistência das unidades de
medida.
Tabela 3. Nível de Confiança nos Indicadores
Indicador
Nível de Confiança (%)
Mudança de Nível MPS
100
Tempo Médio Estimado
100
Tempo Médio Gasto
100
Precisão de Estimativa
100
Número de Clientes no País
85
Número de Funcionários
100
Número de Projetos no País
100
Apesar do número pequeno de empresas que gentilmente preencheram os questionários periódicos
ao longo destes 4 anos é possível observar alguns comportamentos interessantes na Figura 7. Notase que 86% das empresas mudaram de nível MPS ao longo deste período, ou seja, adquiriram mais
maturidade. Neste grupo, o nível mais baixo em 2011 é F (5 empresas) e o mais alto C. Nota-se nos
dados uma evolução positiva e qualitativa nas informações históricas apresentadas e equivalentes ao
nível de maturidade alcançado. Além disso, percebe-se também tendência à estabilidade ou aumento
do Tempo Médio Estimado (85%) e do Tempo Médio Gasto (71%) para os projetos. Alternativamente,
pode-se observar este mesmo comportamento no indicador Precisão de Estimativa, com 72% das
empresas apresentando tendência de estabilidade ou melhoria em suas estimativas. Neste caso, o
indicador Tamanho Médio dos Projetos não atingiu nível de confiança aceitável (76,1%), entretanto
percebe-se que o indicador também apresenta tendência de aumento de tamanho dos projetos para
4 das cinco empresas que puderam ter os dados históricos considerados. Interessante notar que,
para estas empresas, é possível observar tendência no aumento do Número de Clientes (67%), todas
informaram apresentar aumento do Número de Funcionários e 71% delas informaram apresentar
tendência de aumento no Número de Projetos no País. Portanto, de acordo com os dados fornecidos
por estas organizações infere-se que elas podem estar conseguindo lidar com projetos maiores e em
maior número.
34
WAMPS 2011
iMPS – Rodada 4: Variação de Desempenho nas Empresas que Adotaram o Modelo MPS de 2008 a 2011
Desempenho 2008-­‐2011 (7 empresas)
100%
90%
80%
70%
60%
Aumentou
Não Alterou
Reduziu
50%
40%
30%
20%
10%
0%
Mudança de
Nivel MPS
Tempo Médio Tempo Médio
Estimado
Gasto
Precisão de
Estimativa
No Clientes no
No
No Projetos no
País
Funcionários
País
Figura 7. Indicadores de Desempenho 2008-2011 para 7 empresas
6. Considerações Finais
Neste artigo foram apresentados os resultados referentes à caracterização e avaliação da variação do
desempenho das empresas em função da adoção do modelo MPS observados com a inclusão dos
dados coletados em 2011 no contexto da pesquisa iMPS.
Para permitir observar o comportamento das empresas, a avaliação foi realizada a partir de
quatro perspectivas: caracterização em 2011, análise de variação 2010/2011, análise de variação
2009/2010/2011 e análise de variação 2008/2009/2010/2011. Percebe-se, em todos os grupos
observados, que as empresas informaram apresentar tendências favoráveis nos diferentes indicadores
tratados pelo estudo iMPS.
De forma geral, a satisfação das empresas com o modelo MPS é bastante alta, com aproximadamente
97% das empresas se dizendo totalmente ou parcialmente satisfeitas. Em relação ao retorno de
investimento da adoção do modelo, mais de 50% das empresas informaram ter recuperado dentro
dos últimos 12 meses mais do que o investimento feito na implementação e avaliação do modelo.
Em geral percebe-se similaridade de comportamentos entre os grupos de empresas, o que pode ser
percebido comparativamente aos resultados apresentados para as rodadas anteriores do iMPS. Os
indicadores de variação de desempenho para as empresas que adotaram o modelo MPS ao longo dos
anos indicam que possivelmente empresas que se mantêm persistentes na utilização das práticas de
engenharia de software em conformidade com os processos oferecidos pelo modelo MPS tem sido
capazes de lidar com projetos maiores, em maior número e com maior controle. Entretanto, análises
adicionais precisam ser realizadas para se aumentar a confiança na afirmação e explicitar, de forma
mais adequada, os comportamentos observados para os diferentes grupos e níveis de maturidade
apresentados. Os resultados das rodadas anteriores iMPS bem como informações mais abrangentes
e detalhadas sobre esta quarta rodada do estudo no ano de 2011 podem ser encontradas na seção
Resultados de Desempenho disponível em www.softex.br/mpsbr.
WAMPS 2011
35
Palestrantes convidados
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), aos quais agradecemos imensamente
pela contribuição.
Bibliografia
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.
Travassos, G. H. e Kalinowski, M. (2011). iMPS 2010: Desempenho das Empresas que Adotaram
o Modelo MPS de 2008 a 2010. – Campinas, SP: SOFTEX, 2011 (ISBN 978-85-99334-20-11)
(disponível em http://www.softex.br/mpsbr/)
Guilherme Horta Travassos
É doutor em Engenharia de Sistemas e Computação pela COPPE/UFRJ e realizou estágio de pósdoutorado 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. Membro
do corpo editorial do periódico Elsevier - Information and Software Technology. 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
É diretor executivo da Kali Software. Possui doutorado e mestrado em Engenharia de Sistemas
e Computação pela COPPE/UFRJ e bacharelado em Ciência da Computação pelo DCC/UFRJ. É
professor da pós-graduação e-IS Expert do iNCE/UFRJ. Atua como coordenador de publicações,
avaliador líder, implementador e instrutor do MPS.BR. Informações adicionais podem ser obtidas
em www.kalisoftware.com
36
WAMPS 2011
iMPS – Rodada 4: Variação de Desempenho nas Empresas que Adotaram o Modelo MPS de 2008 a 2011
WAMPS 2011
37
Palestrantes convidados
Consultores e Consultoria – Uma visão crítica
Carlos Barbieri
Coordenador da área de Qualidade da Fumsoft – Sociedade Mineira de Software – Belo Horizonte
Síntese: Uma visão crítica, fruto de lições aprendidas ao longo de vários anos como consultor de empresas,
atuando na área de dados e de processos. Objetiva mostrar de forma metafórica, algumas das características
de um consultor, mimetizando posturas de um pediatra, de um obstetra e de um psicólogo.
Você já viu algum livro com título do tipo “Começando a carreira como médico?”, ou “Medicina, o
caminho das pedras?”. Provavelmente não. Mas se você espichar o olho para as referência que lancei
no final desse texto, você verá que há várias publicações que tentam ensinar como ser um consultor.
Pois é: Como ser consultor; Consultoria: o caminho das pedras, Guia de consultoria, etc. A diferença
fundamental está no fato de que não existe um curso superior de Consultoria, da forma como existe
um de Engenharia ou de Medicina. E o porquê disso é até bem óbvio: Você forma um médico,
relativamente capaz, através de 6 anos de faculdade, ou um engenheiro via 5 anos na universidade,
mas você não forma um consultor competente nos anfiteatros de uma escola. Não forma, porque
a construção de um bom consultor passa por outros caminhos e é fruto de um “mix” que envolve
muito mais do que conhecimentos técnicos. Um consultor é uma espécie de amálgama, composto
de ligas de várias naturezas, onde a personalidade, a credibilidade, a comunicação, etc são alguns
dos fatores preponderantes sobre os “saberes” técnicos. Com isso não se está dizendo que um
consultor com ótima comunicação mas sem nenhuma espessura técnica seja capaz de conduzir, com
sucesso, uma empresa a um objetivo definido, como uma certificação em qualidade, por exemplo.
Nem que um consultor com estilo de “orador de botequim” conseguirá sobreviver ao vazio da
sua especialidade. Mas estamos sim, afirmando, que um excelente técnico pode não cumprir, a
contento, seu papel numa consultoria se não tiver alguns desses traços fundamentais de consultor.
Um consultor tem que transmitir “inspiração” para gerar bons exemplos, ser “gregário” para formar
times coesos quando a tônica for o individualismo, ser “persuasivo” para quebrar resistências naturais
quando a cultura tradicional é arranhada e se levanta na defesa do “ontem” e “motivador” para
manter o curso de um projeto “inflight” quando os obstáculos sugerem a aterrisagem. E ele tem
que entender duas palavrinhas em inglês, sonoras, mas verdadeiras: Tem que ser “passionate” e
“trustworthy”. “Passionate” é gostar do que faz, refletindo isso em doses equilibradas de emoção
e de profissionalismo. “Trustworthy” é ser confiável, passar segurança, através de posicionamentos
e gestos, desafio por vezes tão complicado quanto a escrita dessa mesma palavra. O consultor MPS.
BR tem que entender que é um agente externo, normalmente “estranho” ao “habitat” da empresa,
onde, por vezes, encontra uma cultura enraizada, espessa e antiquada e que deve ser mudada para
o alcance dos objetivos de uma implementação. Na sua essência, um grande desafio cultural, como
sabemos. Nesse momento, tão ou mais importante do que ser um profundo conhecedor de Raps e
Reps é o consultor entender que, metaforicamente, tem que ter um pouco de: obstetra, pediatra e
psicólogo.
Do obstetra vem a lição fundamental de que quem concebe o “fruto” do trabalho não é o consultor
e sim a empresa. O consultor tem que saber orientar, avaliar os riscos, ensinar algumas técnicas e
métodos, monitorar parâmetros, acompanhar a sua evolução, auscultar e ajudar na hora na hora do
38
WAMPS 2011
Consultores e Consultoria – Uma visão crítica
“nascimento” do processo. Mas o fruto foi concepção da empresa. O material genético do MPS
deve ser incorporado ao da empresa, traduzido na sua cultura, no seu sucesso, nos seus objetivos
e até nas lições aprendidas com seus fracassos. O consultor, quando muito, ajudou no molde e
introduziu as células mestres da qualidade.
O consultor tem que entender o seu lado pediatra. Ser assim, significa estar disponível nas horas mais
impensáveis, atender celular nos momentos inoportunos, orientar e acalmar a empresa (im) paciente
e por vezes, prescrever um “placebo” temporário, que na reunião seguinte se transformará em algo
definitivo e efetivo. Nunca deixar uma dúvida sem resposta, mesmo que a alternativa seja “Eu estou
numa outra consultoria, mas te ligo em seguida”. A empresa tem que sentir, e cabe ao consultor
transmitir uma viva sensação de parceria que beira a cumplicidade.
Além da personalidade de obstetra e de pediatra, o consultor tem que entender que de todas as
REPS de qualquer processo a ser implementado, a mais difícil é a REP(essoa). O consultor nesse
momento começa a mimetizar o psicólogo ou terapeuta. Na referência Consultoria: o caminho das
pedras, escrito por Dino Carlos Mocsányi, experiente consultor internacional da Coopers & Lybrand é
citada a extrema necessidade manifestada por muitos clientes de pagarem por um “ouvido” paciente
do consultor. “Keep your mouth shut” é um dos “mantras” dos consultores experientes daquela
empresa, segundo ele. Nesse momento, você não está sendo pago para explicar como implementar a
rastreabilidade de requisitos, mas recebendo para ouvir, com um semblante profissional e terapêutico,
digressões, apreensões e fantasmas, muito mais ameaçadores e abstratos do que os resultados do
AMP e DFP. Esse momento, digamos divã, dos consultores, por vezes traz para as empresas, boas
soluções encontradas na engenharia do silencio e da sua própria reflexão induzida.
Os detalhes colocados nos itens anteriores não garantem sucesso sacramentado nem previnem
fracassos certeiros. O mundo de uma empresa e a interação com as pessoas é algo muito mais
complexo do que conseguimos mapear, numa visão metafórica e reducionista. Warren Buffet, o “top
millionaire” do planeta, diz que a idade e a experiência valem mais do que a juventude e entusiasmo.
Não acredito nisso, embora respeite a den$idade de $eu$ argumento$. Tenho testemunhado o
trabalho de consultores e implementadores brilhantes, muitos com a idade dos meus filhos. O que
acredito é que tão importante quanto conhecer os métodos da Engenharia de Software, é aprender
a decifrar a personalidade das empresas e desvendar o “algoritmo” das pessoas. E para isso, ainda
não existe certificação...
Referências
Crocco, L. ,Guttman, E. Consultoria empresarial . Editora Saraiva, 2005.
Mocsányi, D. Consultoria: O caminho das pedras. Trabalhando na era do não emprego. Central de
Negócios-Editora e Marketing, 2003.
Oliveira, D. Manual de Consultoria Empresarial. Editora Atlas,2010.
Weiss, A. Getting start in Consulting. John Wiley & Sons, 2009.
WAMPS 2011
39
Palestrantes convidados
Carlos Barbieri
É engenheiro formado em 1970 pela UFRRJ, tem mestrado em Engenharia de Sensores Remotos
pelo INPE (Instituto de Pesquisas Espaciais, São José dos Campos), obtido em 1974, e curso de
pós-graduação em Informática pelo INPE (1976). Trabalhou na Cemig de 1977 a 2002, onde foi
responsável pelas áreas de Administração de Dados, Bancos de Dados, business intelligence e Apoio
ao Desenvolvimento e Novas Tecnologias. Foi o coordenador geral do projeto “Bug do Milênio” da
empresa e coordenador-executivo do projeto de e-business, se aposentando no cargo de gerente
da assessoria de tecnologia de informática da empresa. Desenvolveu, nessas áreas, trabalhos de
consultoria, treinamento e palestras em Portugal e no Brasil, para várias dezenas de empresas. Foi
articulista do jornal COMPUTERWORLD, onde, por 12 anos, escreveu mais de 200 artigos sobre
tecnologia da informação, além de publicações em diversas outras revistas. É autor dos livros
Modelagem de Dados (1994), BI-Business Intelligence-Modelagem e Tecnologia, (2001), ambos
adotados em diversos cursos de graduação e pós-graduação no Brasil e do recentemente lançado
BI2-Modelagem e Qualidade, pela Elsevier. É professor dos cursos de pós-graduação da FUMEC,
IETEC e PUC-MG, nas áreas de BI, Bancos de Dados e Engenharia de Software. É coordenador do
CCOMP.MG, núcleo de Qualidade da FUMSOFT, responsável pela implantação do MPS.BR em
MG, além de membro da ETM (Equipe Técnica do Modelo MPS) e coordenador nacional da pósgraduação em Engenharia e Qualidade de Software com o modelo MPS da SOFTEX. É implementador
e avaliador-líder MPS.BR, credenciado pela SOFTEX, tendo participado da implementação de MPS.BR
em empresas de diversos níveis (G,F e C) de maturidade.
40
WAMPS 2011
Consultores e Consultoria – Uma visão crítica
WAMPS 2011
41
Palestrantes convidados
Como verificar se a empresa está pronta para a
avaliação
Cristina Ângela Filipak Machado
O momento mais esperado pelas empresas envolvidas com a melhoria de processos é o dia da
avaliação. Nesta hora todos os esforços empreendidos no projeto de melhoria são postos à prova,
sob o olhar de uma equipe externa de avaliação. É um momento de tensão para a empresa, pois,
assim como um estudante em dia de exame, por mais preparada que ela esteja, a incerteza do
resultado a coloca em estado de alerta e insegurança. É também um momento de tensão para a
equipe de implementação que, durante meses, esteve ao lado da empresa, orientando, apoiando e
aconselhando sobre as melhores formas e estratégias de inserção das práticas.
Estas questões acabam se agravando, de certa forma, quando estão envolvidos recursos públicos
aportados para o apoio à melhoria de processos, caso dos grupos de empresa patrocinados com
recursos viabilizados pela SOFTEX. Para estes, além da incerteza do sucesso em si, estão envolvidas
questões contratuais administrativas e financeiras do grupo de empresas, uma vez que os recursos só
são plenamente liberados após a avaliação com sucesso.
A questão que surge, no momento que antecede à avaliação, é comum a todos os envolvidos: como
verificar se a empresa está pronta para a avaliação?
Esta palestra visa discutir os aspectos que envolvem a preparação para a avaliação e a declaração do
marco de 100%. Isto envolve a discussão acerca do conceito do marco de 100% e o que se espera de
todos os envolvidos neste momento; qual a importância e a influência dos atributos de processo no
resultado final da avaliação; qual a relevância de itens requeridos, conforme o nível de maturidade;
e, quais são as responsabilidades de cada um dos envolvidos (IOGE, II, IA e empresa) no processo de
preparação da avaliação.
Público alvo: Implementadores MPS.BR, Avaliadores MPS.BR, Representantes de IOGE, Profissionais
das empresas envolvidas na melhoria de processos.
Cristina Ângela Filipak Machado
Participa do programa MPS.BR desde o seu início, sendo editora do Guia Geral versão 1.0 e 2011, do
Guia de Avaliação do MPS.BR das versões 1.0, 1.1, 2009 e 2011 e do Guia de Implementação Nível F
versão 1.0. Participa também da Equipe Técnica do Modelo do MPS.BR (ETM) na área de Avaliação. É
avaliadora líder experiente da QualityFocus, auditora e observadora no processo de novos avaliadores
líderes. Consultora em melhoria de processos CMMI e MPS.Br. Coordenadora da Comissão de Estudo
de Ciclo de Vida da ABNT, tendo participado diretamente da elaboração das normas internacionais
ISO/IEC 12207 - Definição de Ciclo de Vida de Software, ISO/IEC 15288 - Definição de Ciclo de Vida
de Sistemas e ISO/IEC 90001 – Guia de aplicação da ISO 9000 para Software.
42
WAMPS 2011
Como verificar se a empresa está pronta para a avaliação
Atua como professora em cursos de pós-graduação em Melhoria de Processos da PUC-Paraná, da
Unochapecó e da Universidade Tuiuti do Paraná.
Tem vários trabalhos publicados em âmbito nacional e internacional na área de melhoria de processos
de software.
Analista de Sistemas Mâster da CELEPAR – Companhia de Informática do Paraná desde 1989. Mestre
em Informática Aplicada pela PUCPr na área de Engenharia de Software com ênfase em Gerência
de Risco. Formada em Processamento de Dados pela Universidade Federal do Paraná, possui
especialização em Informática Industrial pelo CEFET Paraná e em Análise de Sistemas no Japão.
WAMPS 2011
43
Artigos técnicos selecionados
A metodologia P3 no Gerenciamento de Portfólio
de Projetos
Heber A. A. Nascimento1, 2, Jandira Guenka Palma1, 2, Rafael Soares Parente1
Departamento de Computação – Universidade Estadual de Londrina (UEL)
CEP 86051-990 – Bloco J – Sala 305A – Londrina – PR – Brasil
1
Guenka Desenvolvimento de Software Ltda.
Londrina – PR – Brasil
2
{heber.nascimento,jandira}@guenka.com.br, [email protected]
Abstract. This paper has the objective to address the context of Project Portfolio Management based on the
level F from Brazilian Improvement Software Process MPS.BR (Melhoria de Processo do Software Brasileiro),
as well as, presenting the developed process of project selection supported by the P³ methodology (Project
Portfolio Planning) to help selecting projects for the portfolio of a small enterprise, already evaluated in the
MPS.BR level F.
Resumo. Este trabalho tem como objetivo apresentar o Gerenciamento de Portfólio de Projetos com base
no nível F da Melhoria de Processo do Software Brasileiro (MPS.BR), bem como, apresentar o processo
desenvolvido de seleção de projetos com apoio da metodologia P3 (Planejamento de Portfólio de Projetos)
para auxiliar na seleção de projetos para compor o portfólio de uma pequena empresa, avaliada e aprovada
no nível F do MPS.BR.
1. Introdução
Atualmente o aumento da concorrência no mercado de projetos/serviços no ramo de Tecnologia
da Informação (TI), requer que as empresas busquem cada vez mais projetos que tragam a melhor
relação custo benefício e para isto os projetos devem estar alinhados aos objetivos organizacionais
e estratégicos da empresa. Porém a definição de tais objetivos nem sempre é realizada de forma
adequada, tendo apenas uma definição subjetiva sobre tais aspectos.
Para resolver tal problema entra em contexto o Gerenciamento de Portfólio de Projetos, ou seja, o
gerenciamento de um conjunto de projetos, onde as informações sobre os projetos são confrontadas
umas com as outras, objetivamente, buscando identificar conflitos e o alinhamento dos projetos com
os objetivos organizacionais e estratégicos da empresa. [MIGUEL 2008]
A seguir é apresentada uma abordagem teórica e prática a respeito do Gerenciamento de Portfólio
de Projetos. Na Seção 2, descreve uma breve definição sobre Gerenciamento de Portfólio de Projetos,
a seguir na Seção 3 apresenta o contexto de gestão de portfólio no escopo do MPS.BR. Na Seção 4
mostra a metodologia P³ (Planejamento de Portfólio de Projetos) e seus principais conceitos. Já na
Seção 6, é disponibilizada algumas das lições aprendidas com o uso da metodologia descrita na Seção
5, e por fim, são apresentadas as conclusões obtidas a partir dos relatos de experiência na Seção 7.
44
WAMPS 2011
A metodologia P3 no Gerenciamento de Portfólio de Projetos
2. Gerenciamento de Portfólio de Projetos
Segundo o Project Management Institute – PMI (2006), o portfólio é uma coleção de projetos,
programas (grupo de projetos relacionados entre si) e outros trabalhos correlatos, agrupados para
facilitar o trabalho de gerenciamento. Um portfólio de projetos (figura 1) pode possuir alguns
itens, onde cada um destes itens é também conhecido como componentes, e estes componentes
(programas, projetos), devem ser totalmente mensuráveis e priorizáveis, para verificar se os mesmos
atendem aos objetivos organizacionais e estratégicos definidos pela organização.
Figura 1. Estrutura de um Portfólio de Projetos.
O gerenciamento de portfólio consiste em duas etapas: primeiramente, avaliar, selecionar e priorizar
componentes com base no alinhamento dos objetivos estratégicos e organizacionais; posteriormente,
avaliar durante o ciclo de vida dos componentes se os mesmos continuam alinhados aos objetivos
pelos quais foram selecionados e aprovados [SOFTEX 2009].
Em outras palavras, o portfólio pode ser compreendido como um filtro, onde somente os componentes
selecionados são contemplados com os investimentos e recursos disponíveis da organização, e
esses componentes devem passar por uma avaliação periódica, para assegurar que seus benefícios
continuam válidos, caso contrário deve-se verificar a melhor opção para substituir tal componente.
Assim, o portfólio deve ser tratado por um processo devidamente estabelecido com base em dados
objetivos e estratégicos a fim de maximizar o sucesso na seleção de projetos. Neste contexto foi
desenvolvido um trabalho bem sucedido da aplicação da metodologia P3 no gerenciamento de
portfólio de projetos em uma pequena empresa.
3. Gerenciamento de Portfólio de Projetos no MPS.BR
O Gerenciamento de Portfólio de Projetos (GPP) no escopo do MPS.BR encontra-se no segundo nível
de maturidade, nível F, e como outros processos, encontram-se definidos em forma de propósitos
e resultados esperados. A seguir temos uma breve descrição dos resultados esperados para este
processo [SOFTEX 2009]:
• GPP1 – As oportunidades de negócio, as necessidades e os investimentos são identificados,
qualificados, priorizados e selecionados;
WAMPS 2011
45
Artigos técnicos selecionados
• GPP2 – Os recursos e orçamentos para cada projeto são identificados e alocados;
• GPP3 – A responsabilidade e autoridade pelo gerenciamento dos projetos são estabelecidas;
• GPP4 – Os conflitos sobre recursos entre projetos são tratados e resolvidos;
• GPP5 – Projetos que atendem aos acordos e requisitos que levaram à sua aprovação são
mantidos, e os que não atendem são redirecionados ou cancelados.
Para alcançar o retorno máximo deste processo, cada um dos resultados esperados apresentados
anteriormente pode ser auxiliado por meio do uso de uma metodologia consistente, o qual será
detalhado a seguir.
4. Metodologia P3
A metodologia P3 destina-se ao gerenciamento de um grupo de projetos que competem pelos mesmos
recursos dentro de uma organização. As atividades desta metodologia incluem busca de novos projetos,
seleção, priorização, controle de balanceamento do portfólio e dos recursos [Esrock 2008].
Algumas técnicas empregadas são: programa de planejamento, para possibilitar o desenvolvimento
de projetos que se alinhem aos objetivos organizacionais e de negócio; um processo de filtragem de
ideias de novos projetos; avaliação de projetos utilizando métodos de auxílio à coleta de pontuação,
o BAR – Benefício (B), Alinhamento (A) e Risco (R); estimativas de riscos utilizando a técnica de Monte
Carlo, técnica de simulação estatística, para estabelecer a justificativa de custo e o planejamento de
recursos por fase facilitando a pró-atividade de identificação e retificação de problemas decorrentes
de recursos. [Esrock 2008]
A metodologia P³ está dividida em três fases, (A) Setup, (B) Busca por projetos e (C) Planejamento.
Cada uma das fases possui um número determinado de atividades, que são divididas em tarefas, as
quais representam a menor divisão de trabalho. A seguir é descrita cada uma das fases, atividades e
tarefas, a fim de propiciar um melhor entendimento da metodologia.
A Fase A (Setup) tem como objetivo criar a infraestrutura necessária para o efetivo gerenciamento
do portfólio de projetos. Esta fase conta com a seguinte atividade:
• Desenvolver infraestrutura de planejamento de portfólio (A.1): criar os meios necessários
para manter o portfólio, através das seguintes tarefas:
ºº Estabelecer um comitê de gerenciamento de portfólio (A.1.1): garantir que a
carteira de projetos seja gerida de forma permanente.
ºº Estabelecer um método de classificação de projetos (A.1.2): cujo objetivo é
fornecer um meio comum para classificar os projetos, visto que estes nunca são criados
de formas iguais.
ºº Criar ativos de processos (A.1.3): cujo objetivo é desenvolver/adquirir processos,
procedimentos, modelos e ferramentas necessário para apoiar e manter a execução da
metodologia P3.
46
WAMPS 2011
A metodologia P3 no Gerenciamento de Portfólio de Projetos
A Fase B (Busca por projetos) tem como objetivo captar e avaliar projetos que tem a possibilidade
de compor o portfólio de projetos de forma contínua. Esta fase é composta pelas seguintes atividades:
• Captar projetos (B.1): consiste em identificá-los por meio de uma sucinta análise, então uma
análise preliminar ocorre e os que passam são encaminhados para o comitê do portfólio de
projetos, esta atividade está subdividida do seguinte modo:
ºº Identificar projetos ad hoc (B.1.1): desenvolver um processo padrão de captura e
avaliação de idéias ad hoc para projetos em potencial.
ºº Identificar projetos pré-planejados (B.1.2): há situações em que um grupo de
projetos relacionados pode ser planejado com antecedência, para satisfazer um objetivo
específico, isto é comum em programas.
ºº Realizar seleção preliminar (B.1.3): nem todas as idéias de projetos vão passar
pelo Comitê, assim procedimentos de revisão devem ocorrer. A necessidade e grau de
formalidade dessas revisões vão variar de organização para organização.
ºº Desenvolver proposta de projeto detalhada (B.1.4): para cada projeto selecionado
(B.1.3) deve ser elaborada uma proposta mais informacional baseada na proposta inicial
que se destinará para a análise do Comitê.
• Determinar utilidade de projeto (B.2): ao passo que a proposta de projeto é submetida, ele
deve ser avaliado para determinar a quantidade de utilidade do projeto. Isto é obtido através
da avaliação da proposta contra a medida padrão de utilidade previamente estabelecidos na
tarefa A.1.2.
ºº Ajuste de risco do desempenho financeiro do projeto (B.2.1): em decorrência do
alto grau de importância atribuído a esta perspectiva e as incertezas que a envolvem o
ajuste de riscos do desempenho financeiro deve ser devidamente analisado.
ºº Análise da pontuação de utilidade (B.2.2): Com base nos ativos de processo criados
na tarefa A.1.3 deve-se calcular a utilidade total do projeto que determina a classificação
deste projeto no portfólio.
A Fase C (Planejamento) busca incluir os projetos classificados e garantir que o portfólio seja viável
no que diz respeito à disponibilidade de recursos e se os projetos que o compõe ainda atendam aos
objetivos pelos quais foram aprovados. Esta fase é realizada periodicamente com base nas seguintes
atividades:
• Seleção de Portfólio (C.1): consiste em selecionar de fato os projetos para inseri-los no
portfólio, neste momento surge um problema caso não existam recursos suficientes para incluir
nos projetos, então um método de otimização se faz necessário para determinar qual dos
projetos realmente deve entrar respeitando suas restrições. Esta atividade está subdividida do
seguinte modo:
ºº Criar lista prévia de projetos do portfólio (C.1.1): de acordo com a pontuação de
utilidade atribuída ao projeto, nem todos os projetos irão compor esta listagem, seja
por falta de informação, uma pontuação de utilidade muito baixa. É importante deixar
documentado os motivos pelos quais levaram os projetos a ficarem fora da lista.
WAMPS 2011
47
Artigos técnicos selecionados
ºº Aperfeiçoar o portfólio (C.1.2): uma prática comum para a escolha dos projetos é
classificá-los por ordem de maior pontuação de utilidade, então se escolhe a partir do
topo até o ponto onde o orçamento e os recursos não são excedidos. Outro meio para
aperfeiçoar o portfólio é a programação matemática que visa maximizar ou minimizar
um assunto objetivo de um conjunto definido de restrições.
ºº Revisar e aprovar o portfólio (C.1.3): o Comitê deve revisar o portfólio para
garantir que as seleções de projetos fazem sentido tanto individualmente como em
grupo. Substituições devem ser feitas, conforme necessário, para chegar a um portfólio
balanceado e alinhado as necessidades da organização.
• Planejar o Portfólio (C.2): deve ser realizado em determinados períodos planejados, pois
deve haver tempo suficiente para permitir que decisões e ações sejam planejadas, sem criar
situações de crise. Além disso, o planejamento deve considerar não apenas projetos individuais,
mas o portfólio como um todo.
ºº Estabelecer o cronograma de portfólio (C.2.1): busca elaborar um plano horizontal
que determina as durações e dependências entre os projetos.
ºº Determinar demanda de recursos (C.2.2): determinar a demanda de recursos para
todos os projetos, isso inclui: necessidade de capital, pessoal, instalações, equipamentos,
etc.
ºº Determinar a oferta de recursos (C.2.3): verificar a disponibilidade e projetar as
alocações dos recursos, considerar os recursos adicionais planejados para estarem
disponíveis em uma determinada fase do projeto.
ºº Conciliar a oferta e a demanda por recursos (C.2.4): nem sempre os recursos
necessários estarão disponíveis, então para manter o portfólio viável deve haver um
planejamento com antecedência para garantir a disponibilidade dos recursos.
Na tabela 1, pode-se verificar a cobertura dos resultados esperados do MPS.BR através das atividades
listadas acima da metodologia P³. Desta forma, verifica-se que todos os resultados esperados são
satisfeitos através da metodologia proposta.
Tabela 1. Cobertura dos resultados esperados pelas tarefas da metodologia P3.
Resultados esperados de GPP (Guia Geral: 2009)
48
WAMPS 2011
Tarefas da metodologia P3
GPP1
B.1.4, B.2.1, B.2.2
GPP2
C.2.2, C.2.3
GPP3
C.2.2, C.2.3
GPP4
C.2.4
GPP5
C.1.2, C.1.3
A metodologia P3 no Gerenciamento de Portfólio de Projetos
5. Desenvolvimento do Processo de Gerenciamento de Portfólio de
Projetos
Este trabalho criou um processo de gerenciamento de portfólio de projetos para uma pequena
empresa de desenvolvimento de software, a criação foi efetuada seguindo a metodologia P3 em uma
empresa de software com nível F do MPS.BR que atendeu aos requisitos de processo e capacidade
do modelo de referencia MR-MPS (Guia Geral:2009) do nível F gerenciável, avaliada no Método de
Avaliação MA-MPS (Guia de Avaliação 2009) em 4 de dezembro de 2010.
Abaixo será apresentado cada passo do processo, assim como, para cada passo foi demonstrado às
atividades implementadas e executadas.
5.1. Fase A – Setup
A primeira atividade (A.1.1) foi executada por meio da seleção dos integrantes do Comitê de
Gerenciamento do Portfólio de Projetos (CGPP), esta seleção conta com um Analista Financeiro
responsável pela análise da Perspectiva Financeira, o Diretor da empresa responsável pela análise da
Perspectiva de Oportunidade de Negócio e um Líder Técnico fica responsável pela análise da Perspectiva
Técnica. Esta seleção foi influenciada pela atividade (A.1.2), pois nesta atividade é que se decidem as
perspectivas a serem avaliadas pelo CGPP. E também o principal motivo desta seleção foi para alcançar
análises mais consistentes, visto que cada um dos selecionados dominam bem a sua área.
A seguir para estabelecer um ranking de projeto (A.1.2) se faz necessário analisar as perspectivas da
empresa e elencar as relevantes para a mesma, atribuindo pesos de importância para cada uma das
perspectivas. Desta forma foram identificadas três perspectivas, como mencionado anteriormente,
são elas: Financeira, Oportunidade de Negócio e Técnica, para cada uma foi atribuído os respectivos
pesos de utilidade: 40, 45 e 15, visto que por uma decisão da Gestão Estratégica o que mais
importaria para a seleção em primeiro lugar seria a Perspectiva de Oportunidade de Negócio, pois
a empresa busca a consolidação do seu negócio; em seguida vem a Perspectiva Financeira, pois a
empresa necessita manter sua infraestrutura e o quadro de colaboradores; e por ultimo foi deixada a
Perspectiva Técnica, não menos importante, mas com um peso menor.
Figura 2. Perspectivas e seus respectivos indicadores.
WAMPS 2011
49
Artigos técnicos selecionados
Para cada perspectiva foi criados alguns indicadores, são por meio destes indicadores que são
realizadas as análises. A Figura 2 mostra os indicadores para cada uma das perspectivas.
Após a definição dos indicadores, é necessário atribuir para cada um dos mesmos a faixa de pontuação
que cada indicador pode receber. Por exemplo, o indicador “1. Conhecimento sobre os requisitos”
da Perspectiva Técnica está distribuído conforme mostrado na Figura 3.
Figura 3. Faixa de pontuação para o indicador Conhecimento sobre os requisitos.
Depois que todos os indicadores estiverem devidamente pontuados (mínimos e máximos definidos) é
necessário calcular o fator de racionalização (FR) de cada uma das perspectivas. Este fator é necessário
para calcular o total de pontos de cada uma das perspectivas e a formula para calcular este fator é
dada da seguinte forma:
O máximo de pontos atingíveis de cada perspectiva é o somatório da pontuação máxima de cada
indicador da perspectiva. Por exemplo, a pontuação máxima do indicador “1. Conhecimento sobre
os requisitos” da Perspectiva Técnica é 10 (figura 3), assim, se houvesse mais três indicadores com
pontuação máxima de 10 o máximo de pontos atingíveis da Perspectiva Técnica seria de 40 pontos.
A Figura 4 mostra o resultado obtido por meio da aplicação da fórmula para cada uma das
perspectivas do processo definido.
Figura 4. Perspectivas e seus respectivos fatores de racionalização.
Para finalizar esta fase foi executada a atividade (A.1.3) que documenta por meio da ferramenta
Confluence (Wiki Corporativa), os procedimentos para seleção de novos membros em caso de
50
WAMPS 2011
A metodologia P3 no Gerenciamento de Portfólio de Projetos
modificação e/ou atualização das perspectivas, as planilhas para realização das análises, as instruções
de trabalho para o correto preenchimento das planilhas e as diretrizes para a realização das análises
e aceitação/rejeição de projetos.
5.2. Fase B – Busca de Novos Projetos
Segundo a metodologia a busca por novos projetos pode ocorrer por meio de dois modos, são eles: (B.1.1)
e (B.1.2) a frente adotada foi a B.1.1 visto que a B.1.2 ainda não é uma frente abordada na empresa no
presente momento. Assim a atividade B.1.1 é conduzida do seguinte modo, o analista de negócio que
fica responsável por coletar as informações iniciais e compor o documento que fornece uma visão inicial
do projeto, este documento contem algumas informações a respeito do projeto solicitado pelo cliente.
Em seguida é feito uma análise preliminar (B.1.3) que determina se o projeto realmente deve ser
enviado ou não para o CGPP. Nesta análise são levados em conta informações gerais a respeito
do cliente e do projeto, caso passe nesta análise, então o projeto é mais bem detalhado (B.1.4),
informações detalhadas dos requisitos, riscos, restrições, prazos, recursos, custo, etc. são coletadas e
devidamente documentadas para que o CGPP possa avaliá-lo.
O passo seguinte consiste em realizar o ajuste do risco financeiro, pois quando se trata de indicadores
financeiros estes são delicados e incertos, então são desenvolvidos alguns cenários (B.2.1) para
possibilitar uma visão mais ampla das possíveis configurações financeiras.
Em seguida realiza-se a atribuição da pontuação para cada um dos indicados (Figura 2) conforme
a análise dos dados obtidos nos passos anteriores, então a pontuação de classificação (B.2.2) para o
projeto é obtida.
5.3. Fase C – Planejamento
É iniciada por meio da formação de uma lista de projetos candidatos (C.1.1) a compor o portfólio.
Para compor esta lista, o projeto deve atender a um determinado limiar, ou seja, se a pontuação do
projeto atingiu uma determinada pontuação ele irá compor a listagem de projetos, caso contrário
não. Quando o projeto não atinge o limiar então é realizada a documentação dos motivos que o
deixou de fora e o projeto é descartado (figura5).
O aperfeiçoamento do portfólio (C.1.2) é realizado na atividade anterior, visto que não é utilizado
outro método para aperfeiçoar o portfólio a não ser a classificação pela pontuação de utilidade e
observações a respeito de restrições do projeto (figura5).
Figura 5. Lista de projetos.
WAMPS 2011
51
Artigos técnicos selecionados
Em seguida ocorre a revisão e aprovação do portfólio (C.1.3) que é realizado por meio de uma
reunião onde o CGPP faz as ultimas ponderações a respeito dos projetos e então os interessados são
comunicados da aprovação do portfólio de projetos.
Após o estabelecimento do portfólio de projetos, deve-se periodicamente rever o portfólio a fim
de verificar se ele atende aos objetivos pelos quais foi aprovado. Para ter uma visão ampla (C.2.1)
de como estão os projetos ao longo do tempo foi desenvolvida uma planilha na qual fornece a
distribuição dos projetos mês a mês.
A demanda de recursos (C.2.2) é minuciosamente estudada para identificar cada um dos recursos
humanos e de infraestrutura, para cada projeto é documentado esta necessidade, isto é realizado
quando informações mais detalhadas a respeito do projeto são colhidas (na tarefa B.1.4).
Com relação à demanda de recursos é verificada a oferta (C.2.3) de recursos disponíveis para os
projetos, esta tarefa também é realizada durante a tarefa B.1.4.
Para controlar a demanda por recursos (C.2.4) é utilizada uma planilha na qual fornece o percentual
de alocação de cada recurso por projeto, quando o recurso está super alocado busca-se realizar
o replanejamento dos projetos a fim de melhor conciliar os recursos, caso contrário busca-se no
mercado por mais recursos.
6. Análise da elaboração e execução do processo de Gerência de
Portfólio de Projetos
Com a elaboração e execução do processo foi possível retirar algumas importantes lições quanto à
metodologia P3 e ao processo de gerência de portfólio de projetos.
1. Inicialmente havia somente uma pessoa responsável pela perspectiva técnica, durante alguns
encontro do CGPP foi evidenciado que não era interessante uma única pessoa responsável por
esta perspectiva, pois não tinha o conhecimento técnico para todos os projetos. Atualmente
os responsáveis pela perspectiva técnica alternam-se de acordo com o conhecimento que cada
um possui.
2. Com a formação do CGPP melhorou a integração das diversas áreas (financeiro, produção,
comercial, qualidade, gerencia de projeto) da empresa, isto levou a melhora da comunicação
e da gestão a respeito dos projetos, permitindo confrontar o planejado versus o executado.
3. Os indicadores muitas vezes não são simples de avaliar, podem deixar espaços para muitas
interpretações, assim dificilmente os primeiros indicadores serão efetivos e eficientes.
4. O processo inicialmente é um tanto burocrático, eleva os custos no inicio e há uma possível
resistência a mudança, mas com o uso contínuo é melhorado os indicadores relacionados às
perspectivas elencadas, servindo como histórico para novos projetos e assertividade na seleção
de projetos e alocação de recursos.
5. Os indicadores que ao invés de qualitativos passa-se a quantitativos.
6. Atualmente há certa dificuldade em controlar as concorrências entre recursos de projetos, pois
este procedimento é realizado de forma manual.
52
WAMPS 2011
A metodologia P3 no Gerenciamento de Portfólio de Projetos
7. Conclusão
Neste trabalho foi apresentado o desenvolvimento de um processo de Gerência de Portfólio de Projetos
no escopo do nível F do MPS.BR (Guia Geral: 2009) em uma pequena empresa de desenvolvimento
de software, para apoiar a seleção e manutenção de projetos do portfólio da empresa.
Com o desenvolvimento do processo com os respectivos procedimentos, ficou evidenciada uma
seleção mais crítica dos projetos para compor o portfólio, pois anteriormente à definição, a aprovação
dos projetos era feita sem critérios definidos (explicitamente) e a decisão era tomada por apenas um
colaborador da empresa, sendo mais suscetível a erro, hoje o projeto é avaliado por 14 critérios bem
definidos e por um comitê multidisciplinar, o qual vem contribuindo para que somente os projetos
alinhados aos objetivos organizacionais e estratégicos da empresa sejam aceitos e desenvolvidos,
contribui para melhorar o fluxo de comunicação entre os vários setores da empresa, como também
tem contribuído diretamente para a empresa consolidar a sua área de atuação no mercado, atingindo
os negócios para os quais foram almejados no planejamento estratégico.
Como verificado na literatura, as principais atividades do processo de Gerência de Portfólio de Projetos
(avaliar, selecionar e priorizar componentes com base no alinhamento dos objetivos estratégicos e
organizacionais) foram devidamente cobertos pelo desenvolvimento do processo de gerência de portfólio
de projetos com base na metodologia P3, satisfazendo os resultados esperados do processo GPP do MPS.BR
nível F (Guia Geral:2009), e para o modelo de 2011 deve-se fazer uma análise para eventuais adaptações.
Referências
Esrock, Y. P. (2008). Project portfolio planning (P3) methodology. In CSC Papers, page 70.
MIGUEL, P. A. C. (2008). Implementação da gestão de portfólio de novos produtos: um estudo de
caso. Produção, 18(2):388–404.
PMI – Project Management Institute (2006). The Standard for Portfolio Management. Project
Management Institute.
Rocha, A. R., de Souza, A. D., Alexandre, D. B., Santos, G., Montoni, M., Cabral, R., and C., T. V. P.
(2008). Gerenciamento de portfólio de projetos com foco na seleção de projetos. WAMPS, 4.
SOFTEX (2009). Guia de Implementação – Parte 2: Fundamentação para Implementação do Nível
F do MR-MPS. SOFTEX.
WAMPS 2011
53
Artigos técnicos selecionados
Implantação do Nível F do MR-MPS Combinando
Características do Processo Unificado com
Práticas SCRUM
Tatiane Silva1, Rogério Magela1, Gleison Santos2, Natália Chaves Lessa Schots3, Ana Regina Rocha3
Athenas Engenharia de Software – Av. Rio Branco, 12, 14º andar, Centro
CEP 20090-000 – Rio de Janeiro – RJ – Brasil
1
Programa de Pós-Graduação em Informática – Universidade Federal do Estado do Rio de Janeiro (UNIRIO)
– Av. Pasteur 458, Urca, CEP 22290-240 – Rio de Janeiro – RJ – Brasil
2
COPPE/UFRJ – Universidade Federal do Rio de Janeiro – Caixa Postal 68511 – CEP 21945-970 – Rio de
Janeiro – Brasil
3
{tatiane, magela}@athenassoftware.com.br, [email protected], {natalia, darocha}@cos.ufrj.br
Abstract. There is no software process model adequate to any organization and during all the time. This
paper presents the evolution of the software de­velopment process of Athenas Software. This process first
version was based on what would become the Unified Process and now have evolved to support SCRUM
agile practices and the MPS.BR Reference Model Level F practices.
Resumo. Não existe um único modelo de processo de software que seja ade­quado a todo o tipo de empresa
nem por todo o tempo. Este artigo apresenta a evolução do processo de desenvolvimento de software da
Athenas Software desde a sua primeira versão baseada no que viria se tornar o Processo Unifi­cado até o
momento atual onde se alinham, também, práticas ágeis do SCRUM e as práticas associadas ao Nível F do
Modelo de Referência do MPS.BR.
1. Introdução
A Athenas Engenharia de Software é uma empresa localizada no Rio de Janeiro com 14 anos de atuação
na área de desenvolvimento de sistemas e soluções de negócio baseadas nos princípios e padrões
da engenharia de software. Desde sua fundação a empresa uti­liza processos de desenvolvimento
de software para construção de seus produtos, basea­dos em elementos do Processo Unificado
[Jacobson et al. 1999]. Estes elementos pos­suem como principal característica a documentação
durante o desenvolvimento do pro­jeto, principalmente na etapa de análise e projeto. Após diversas
evoluções e a necessi­dade de comportar metodologias de modelagem e de componentização, o
processo de desenvolvimento da Athenas, atualmente, é resultante de uma combinação entre os
ele­mentos do Processo Unificado, algumas práticas ágeis (retiradas pontualmente das me­todologias
Scrum [ScrumAlliance 2011] e Exteme Programming (XP) [Beck e Andres 2005] e as exigências do
nível F do MR-MPS [Softex 2011].
Este artigo possui o objetivo de apresentar como o processo da Athenas evoluiu ao longo do
tempo e as melhorias e lições aprendidas identificadas pela empresa durante esta evolução. Na
Seção 2, um breve histórico da evolução do processo de desenvolvi­mento é apresentado, bem como
54
WAMPS 2011
Implantação do Nível F do MR-MPS Combinando Características do Processo Unificado com Práticas SCRUM
algumas características peculiares da empresa. As ca­racterísticas do atual processo e as ferramentas
utilizadas são discutidas nas Seções 3 e 4, respectivamente. Por fim, na Seção 5 são apresentadas
as considerações finais junta­mente com resultados obtidos com a melhoria do processo e algumas
lições aprendidas.
2. Experiências Anteriores com Processos e Metodologias
As soluções providas pela Athenas têm por objetivo auxiliar o desenvolvimento não ape­nas de
sistemas, mas também de soluções personalizadas e inovadoras, que sejam confiá­veis, estáveis,
seguras, escaláveis, dentro dos custos e prazos estipulados. Dentro deste objetivo, a utilização de
um processo de desenvolvimento se fez essencial para que, defi­nidos os fluxos do processo, fosse
possível aplicá-lo repetidas vezes e, por consequência, medir e melhorar este processo.
Desde a sua criação, em 1997, a Athenas utiliza processos de desenvolvimento de software
para construção de seus produtos. O primeiro processo a ser utilizado – Órion – possuía como
base elementos tais como Objectory [Jacobson 1992] e Catalysis [D’Souza e Wills 1999] que,
posteriormente, deram origem ao conhecido Rational Unified Process – RUP [Jacobson et al. 1999].
Sendo assim, o processo de desenvolvi­mento adotado era totalmente baseado em orientação a
objetos e fortemente aderente à abordagem de desenvolvimento baseado em componentes (CBD
– Component Based Development), com a utilização de um framework de desenvolvimento, o AWF
(Athenas Wisdom Framework), desenvolvido internamente pela empresa, que fundamenta todas as
suas construções. Este framework agiliza e isola a aplicação dos princípios e padrões da engenharia
de software, levando os produtos Athenas ao encontro das necessidades es­pecíficas de cada cliente
Em 1999, com o apoio da Sterling Software e Computer Associates, o processo foi lançado em
todo território nacional sob o nome Vincit, sendo um dos primeiros proces­sos de desenvolvimento
genuinamente brasileiro [Fuzion 1999]. Este processo já era, neste momento, utilizado em projetos
de pequeno e médio porte por empresas do ramo de Seguro Saúde e pelo Comando da Aeronáutica.
Em 2000, o Vincit passou a ser chamado de Athenas Process consolidando um pro­cesso tendo
como base o Objectory/RUP, CBD (Component Based Development) e várias abordagens utilizando
as melhores práticas de Engenharia de Software e a experi­ência no uso prático do processo em
seus próprios projetos. Algumas melhorias foram incorpora­das ao processo de desenvolvimento para
atuar em projetos de grande porte, dentro da linha de negócio de terminais portuários. O Athenas
Process passou, assim, a atender equipes maiores e distribuídas dentro do projeto. No decorrer de
sua utilização, a em­presa passou por algumas alterações estruturais e o Athenas Process passou a ser
cha­mado APD – Athenas Processo de Desenvolvimento.
Ao longo do tempo, o APD se tornou pesado e burocrático, muita documentação era utilizada e
não havia o apoio adequado de ferramentas em sua aplicação. Além disso, as tecnologias utilizadas
na empresa mudaram, o próprio framework passou por evolu­ções, as técnicas de modelagem
foram aprofundadas e houve uma preocupação maior em instituir uma equipe responsável pela
definição e manutenção do processo (uma necessi­dade cada vez mais reconhecida nas empresas de
desenvolvimento de software). Surgiram, paralelamente, novas necessidades com relação a prazos
e investimentos realiza­dos em projetos por parte do maior cliente da empresa e a própria equipe
WAMPS 2011
55
Artigos técnicos selecionados
de desen­volvimento passou a interagir mais com a fundamentação da utilização de proces­sos e a
colaborar com críticas que culminaram no mais recente grande projeto de melho­ria de processos,
onde a Athenas alcançou o nível F do MR-MPS [Softex 2011].
No final de 2009, a Athenas começou a aprofundar seus estudos internos no MR-MPS e recebeu o
convite para iniciar a implementação do nível G. Após o primeiro con­tato técnico com a Instituição
Implementadora COPPE/UFRJ, foi apresentado todo o histórico da empresa em desenvolver utilizando
processos e percebeu-se, em conjunto, a oportunidade de almejar o nível F.
A revisão dos processos foi realizada em um prazo de 3 meses e meio e o APD evoluiu assim para sua
versão 4.0. Nas definições e concepções principais desta nova versão do processo, foram incorporados
os resultados esperados do nível F do MR-MPS, alguns resultados esperados do nível E e do nível D,
conceitos adaptados de me­todologias ágeis (principalmente apoiados no SCRUM) e algumas práticas
pontuais do PMBOK [PMI 2008].
Esta evolução do processo de desenvolvimento é apresentada na Figura 1.
Figura 1. Evolução do Processo de Desenvolvimento da Athenas.
3. Características do Processo de Desenvolvimento
O projeto de melhoria de processo de software realizado em 2010, que levou a Athenas ao nível F
do MPS.BR, teve como principais desafios: (i) a adequação do processo exis­tente aos requisitos dos
processos do MR-MPS para o nível F; (ii) a transcrição do APD por meio de uma ferramenta adequada
para representação de processos (no caso, o EPF – Eclipse Process Framework [EPF 2011]); (iii) a
inclusão de práticas ágeis; e (iv) o apoio a boas práticas encontradas no PMBOK [PMI 2008]. Além
disso, uma preocupação constante foi não deixar de lado as principais fundamentações do processo
até então: a utilização de compo­nentização (CBD), a utilização de um framework para geração de
código e para implementação de princípios e padrões da engenharia de software e a forte caracte­
rística de modelagem de componentes através da MDA (Model Drive Architecture).
56
WAMPS 2011
Implantação do Nível F do MR-MPS Combinando Características do Processo Unificado com Práticas SCRUM
Atualmente, o APD possui como fundamentação, além do processo unificado, práti­
cas ágeis
retiradas pontualmente do Scrum e XP, dando suporte às etapas de modela­gem e internalizando as
necessidades específicas para utilização de um framework de negócio na construção de software,
tais como: (i) utilização do conceito de sprints e liberações; (ii) o aumento da comunicação entre
a equipe através da realização de reuni­ões diárias; (iii) prática de reuniões de planejamento e de
controle de finalizações de eta­pas do projeto; e (iv) realização de atividades relacionadas à utilização
do framework como parte da construção. A adoção destas práticas ágeis teve como objetivo tornar
o processo menos burocrático e entregar produtos intermediários, possibilitando maior comunicação
e comprometimento do cliente.
Uma característica peculiar da empresa é o número reduzido de recursos humanos. À medida que
os processos requeridos pelo nível F do MR-MPS foram sendo introduzidos – e, portanto, novos
papéis para desempenhá-los foram necessários –, verificou-se a necessidade de definir e formalizar
criteriosamente os papéis dentro do processo, permitindo identificar claramente as responsabilidades
e limita­ções para cada um. Desta maneira, cada profissional pôde estudar seus papéis no processo
e receber treinamento adequado para desempenhá-los de forma independente e direcio­nada. Para
isso, a formalização do processo em ferramenta específica (o EPF) foi funda­mental. A Athenas foi
avaliada contando com um total de apenas 7 profissionais envolvi­dos nos 4 projetos avaliados. Desde
o diretor da empresa até o profissional desenvolve­dor, todos estiveram atuando em, no mínimo, dois
papéis dentro do processo. Outro fato ocorrido foi a constante troca de papéis no início dos projetos
devido ao número redu­zido de profissionais. Com a formalização do APD e o início da preparação
para a avali­ação surgiram papéis organizacionais, mas o número de pessoas na equipe não pode au­
mentar devido a restrições do planejamento estratégico da empresa.
O APD, em relação às atividades relacionadas a um projeto específico, é um pro­cesso iterativo e
incremental e está dividido em cinco iterações, a saber: Pré-projeto, Projeto, Liberação, Fábrica e
Pós-Projeto. Em cada uma destas iterações, são executadas as fases de Planejamento, Especificação,
Construção, Teste e Qualidade, Implantação e Introspecção, conforme a profundidade necessária em
cada uma das iterações. Por exemplo, a Fase de Planejamento tem uma profundidade/detalhamento
maior (abrangendo um escopo mais amplo) dentro da Iteração de Pré-Projeto do que na Itera­ção
de Fábrica, onde os artefatos de produto são o foco principal. Nesta iteração, por exemplo, o maior
nível de profundidade/detalhamento é referente à Fase de Construção. A Figura 2 apresenta esta
composição do APD de forma gráfica.
A Iteração de Pré-Projeto tem por objetivo evitar que sejam passados ao cliente e à própria diretoria
da Athenas valores de investimento e prazos irreais. Para isso, o foco está nas fases de Planejamento
e Especificação, porém com o aprofundamento necessário apenas para produzir um Plano de
Projeto inicial (com os principais riscos do projeto, um cronograma macro, dentre outros) e um
documento de Especificação de Requisitos (que será detalhado após as atividades de especificação).
A iteração de Pré-projeto é fundamental para que tanto a Athenas quanto o Cliente estejam cientes
do planejamento e, principalmente, dos riscos relacionados ao projeto. Após o fechamento desta
iteração, dá-se início a Iteração de Projeto, onde todas as atividades são aprofundadas e as fases em
foco continuam sendo as de Planejamento e Especificação. As duas primeiras itera­ções ocorrem uma
única vez no projeto.
WAMPS 2011
57
Artigos técnicos selecionados
Figura 2. Composição do processo de desenvolvimento APD.
Após a finalização da iteração de projeto tem-se início a iteração de Liberação, que se assemelha às
Releases do Scrum. Dentro dela as Iterações de Fábrica ocorrerão, assemelhando-se aos Sprints do
Scrum. O produto (software) será efetivamente constru­ído durante as Liberações e Fábricas e dentro
delas as fases em foco oscilarão entre Cons­trução, Teste e Qualidade e Implantação de acordo com
as necessidades e caracte­rísticas de cada projeto.
É necessário salientar que a fase de Introspecção tem o mesmo foco em todas as iterações. É nela que,
obrigatoriamente, são feitas avaliações do processo, monitorações do projeto e coleta e análise das
métricas do projeto e do processo. Desta forma, ga­rante-se a correta visibilidade e acompanhamento
pró-ativo dos projetos.
Após a finalização de todas as liberações necessárias para construir o software, ocorre a Iteração
de Pós-Projeto onde a finalização do projeto será executada, bem como as lições aprendidas serão
identificadas, formalizadas e discutidas entre a equipe e todos os envolvidos no projeto.
O APD possui quatro focos principais em relação a seus objetivos como pro­cesso:
• Foco Gerencial: Com o objetivo de permitir um controle baseado em visibilidade de gestão,
a saber: visibilidade estratégica (por meio da utilização de iterações), visibili­dade gerencial (por
meio das fases) e visibilidade operacional (por meio de suas ativi­dades), unificando conceitos
técnicos a conceitos gerenciais.
• Foco em Projetos: O APD estabelece que durante o ciclo de vida de um software devem
existir n projetos mensuráveis. A execução de vários projetos permite a ob­tenção de indicadores
periodicamente, minimizando riscos, aumentando drastica­mente a qualidade, permitindo que
haja adaptações a novas diretrizes do mercado, gerando resultados visíveis de forma mais
imediata e colhendo mais rapidamente retornos de investimento para a empresa.
Foco em Arquitetura x Componente x Modelagem: Estabelece conceitos determi­nísticos de
obtenção da arquitetura de software através da modelagem. Per­mite ainda derivar os componentes
que compõem a arquitetura de software.
58
WAMPS 2011
Implantação do Nível F do MR-MPS Combinando Características do Processo Unificado com Práticas SCRUM
• Foco em Produção: Uso da Engenharia de Software Aplicada para garantir tecnica­mente a
construção de um software nos melhores prazos e qualidade. O custo é de­rivado do prazo,
e este dependerá das técnicas e do estilo arquitetural adotado (uso conjunto de framework,
ferramentas de apoio e plataforma).
Além do nível F, o APD já apresenta a definição de um processo padrão e um subprocesso específico, o
APO – Athenas Processos Organizacionais. Este subprocesso é responsável pela definição e execução
das atividades organizacionais que dizem res­peito à empresa como um todo e não a projetos
específicos. O APO congrega todas as atividades organizacionais que dizem respeito às áreas de
Garantia da Qualidade, Métri­cas organizacionais e Gerência de Configuração organizacional. O APO
ainda traz as definições de todas as políticas e processos organizacionais, bem como as definições de
todos os papéis existentes no APD.
Anualmente, é feito o planejamento da execução do APO dentro da ferramenta de gerenciamento e,
bimestralmente, ele é executado e seus resultados são apresentados à equipe e à diretoria. Mediante
os resultados obtidos, planos de ação são definidos e passam a ser gerenciados até a sua finalização.
4. Ferramentas Adotadas
A utilização de um processo sem o apoio de ferramentas pode dificultar a disseminação e a execução
do processo por parte da equipe, principalmente em se tra­tando de uma equipe com um número
reduzido de profissionais, onde a agilidade é fun­damental para que os prazos dos projetos não sejam
comprometidos devido à utilização do processo.
Sendo assim, a Athenas utilizou como principal ferramenta de apoio o JIRA [Atlassian 2011],
customizado especificamente para atender ao processo APD. Esta customização foi essen­cial para a
adaptação das atividades de gerenciamento à realidade do processo estabe­lecido. Dentro do contexto
da implementação do MR-MPS, o JIRA apoiou direta­mente em todas as áreas de processo relativas ao
nível F, bem como a organização e ge­renciamento das execuções dos ciclos do APO. Na Athenas, o
conjunto de atividades organizacionais também é gerenciado como um projeto (neste caso, não de
desenvolvi­mento, mas de melhoria de processos). Todas as tarefas a serem executadas nos projetos
são registradas no JIRA e é gerada notificação automática do andamento de todas as tarefas.
A correta comunicação entre os membros da equipe também foi considerada fun­damental. Assim,
como disseminação e entendimento do processo, o EPF foi utilizado para a formalização do APD e
do APO, bem como para o controle dos seus templates de documentação. O ganho percebido por
meio desta formalização foi evidenciado no mo­mento de implantação do processo, já com suas
melhorias introduzidas, dentro dos pro­jetos da empresa. A equipe teve o processo disponível a todo
o momento e isso faci­litou o treinamento, o gerenciamento e a manutenção e posterior evolução
do processo con­forme necessário. Estes fatores também propiciaram atingir alguns itens exigidos a
partir do nível E do MR-MPS, como por exemplo: a definição, controle e evolução de um Pro­cesso
Padrão e o seu uso para derivar o Processo Definido para os projetos. Além disso, foi criado um e-mail
específico para recepção de comentários e sugestões de melhorias propostas para o processo. Todas
as sugestões de melhorias, após análise do Grupo de Processos, são inseridas no JIRA em um projeto
relacionado ao APO.
WAMPS 2011
59
Artigos técnicos selecionados
Além dos controles e gerenciamentos mencionados, o JIRA permitiu a transpa­rência e a visibilidade
dos projetos para toda a equipe, bem como visibilidade das tarefas organizacionais e seus resultados.
Todas as não conformidades dos projetos e da organiza­ção (originadas de avaliações de qualidade
e de gerência de configuração, inspe­ções e monitoração) são acompanhadas na ferramenta até a
sua finalização. A base de dados da ferramenta também foi utilizada como fonte para as métricas
utilizadas pelo processo Medição. Além disso, o JIRA serviu como apoio à utilização de práticas de
metodologia ágil nos projetos como, por exemplo, Kanban (ver Figura 3), versões, gráfi­cos e reuniões
diárias de acompanhamento.
Figura 3. Disposição das tarefas no formato Kanban no JIRA.
Para a customização do JIRA foram utilizados plugins, tais como: (i) TEMPO plugin, para registro e
acompanhamento de horas produtivas em cada tarefa; (ii) JIRA Subversion Plugin, para implementação
da rastreabilidade das tarefas do JIRA até o có­digo fonte; (iii) JIRA Labels Plugin, para realização de
marcação das tarefas com tags que apoiaram desde a rastreabilidade, os filtros necessários para
obter métricas dos pro­jetos; entre vários outros plugins de customização. Grande parte dos plugins
necessá­rios foi obtida de forma gratuita, o que evitou maiores custos no projeto de melho­rias.
No que tange ao desenvolvimento de software propriamente dito, as principais ferramentas de
apoio ao processo foram o Enterprise Architect e o AWF (Athenas Wis­dom Framework), além das
IDEs relacionadas às tecnologias que a empresa atende (C#, JAVA e ActionScript). Os laudos de
garantia da qualidade, auditoria de gerência de configuração e os controles do portfólio de projetos
da organização foram implementa­dos na forma de Planilhas Excel.
5. Considerações Finais
O APD (Athenas Processo de Desenvolvimento) é um processo de desenvolvimento fundamentado
em Engenharia de Software. Seu compromisso primário e fundamental é com o ROI (Retorno de
Investimento) e o uso prático em ambientes de desenvolvimento de software. Sendo assim, orienta-se
60
WAMPS 2011
Implantação do Nível F do MR-MPS Combinando Características do Processo Unificado com Práticas SCRUM
em atender as necessidades da empresa e seu negó­cio, bem como de seus gestores e diretores, e
não unicamente com viés técnico e modis­mos da área. O APD evoluiu por meio de um processo de
melhorias e encontra-se, atualmente, em sua versão 4.0. É um processo relativamente maduro, de
uso prático, alinhado com métodos aprovados pela comunidade de informática, focado nos princí­
pios, padrões e melhores práticas de Engenharia de Software, avaliado como aderente ao nível F no
MR-MPS.
Como lições apreendidas podem-se listar: (i) a definição de processos precisa ser feita de forma
incremental, sendo fundamental definir e executar estes processos, pois somente assim é possível
avaliar o que está adequado e o que pode ser melhorado; (ii) é necessário atender as necessidades da
empresa e alinhar o processo a seus objetivos; e (iii) profissionais mais antigos na empresa podem ter
mais dificuldade e, assim, exigir maior atenção com relação à execução dos processos.
O grande desafio da Athenas Software sempre foi aliar a utilização de um pro­cesso de desenvolvimento
(com todas as suas regras e procedimentos) à necessidade de produzir o retorno adequado, por meio
dos produtos com a qualidade necessária a uma empresa de Engenharia de Software. Atualmente, o
APD cumpre com este objetivo e está sendo continuamente melhorado de forma a ser um dos pilares
para satisfazer as necessidades dos clientes e da própria organização
Referências
Atlassian (2011) “JIRA Issue and Project Tracking”. Disponível em: http://www.atlassian.com/software/
jira/. Acessado em: março/2011
Beck, K.; Andres, C. (2005) “Extreme Programming Explained: Embrace Change”, 2 ed. Upper Saddle
River: Addison-Wesley.
D’Souza, D.F.; Wills, A.C. (1999) “Objects, Components and Frameworks with UML: The Catalysis
Approach”, Reading MA: Addison-Wesley.
EPF (2011) “Eclipse Process Framework Project”. Disponível em: http://www.eclipse.org/epf. Acessado
em: março/2011.
Fuzion (1999) “Metodologia Vincit”, CD-ROM. E-book.
Jacobson, I. (1992) “Object-Oriented Software Engineering: A Use Case Driven Ap­proach”, ACM
Press, Reading, MA.
Jacobson, I.; Booch, G.; Rumbaugh, J. (1999) “Unified Software Development Process”, AddisonWesley.
PMI – Project Management Institute (2008) “A Guide to the Project Management Body of Knowledge
(PMBOK Guide)”, 4ª ed., Newton Square: PMI Publications.
ScrumAlliance (2011) Disponível em: http://www.scrumalliance.org, acessado em março/2011.
Softex (2011) “MPS.BR – Melhoria de Processo do Software Brasileiro, Guia Geral”. Disponível em
http://www.softex.br/mpsbr. Acessado em: setembro/2011.
WAMPS 2011
61
Artigos técnicos selecionados
Definição de um processo de Engenharia
de Requisitos para software embarcado
na indústria automotiva baseada em uma
Arquitetura de Processos de Software
Luiz Carlos M. Ribeiro, Cristiane Soares Ramos, Maylon Felix Brito, Rejane M. C. Figueiredo
Faculdade Gama, Campus Gama – Universidade de Brasília (UnB).
{lcarlos, cristianesramos, rejanecosta}@unb.br, [email protected]
Abstract. In this work is presented a standard process for requirements engineering for embedded software
in the context of the automotive industry. This process was made from a software process architecture, which
is based on the meta-model Software & Systems Process Engineering Meta-Model Specification (SPEM).
This process was defined from the reusing of components of a preexisting process and based on features of
process variability. The resulting process is in accordance with the MR-MPS and Automotive SPICE models.
Resumo. Neste trabalho é apresentado um processo padrão para engenharia de requisitos para software
embarcados no contexto da indústria automotiva, Este processo foi elaborado a partir de uma arquitetura
de componentes de processo de software, que está baseada no meta-modelo Software & Systems Process
Engineering Meta-Model Specification (SPEM). O processo foi definido a partir da reutilização de componentes
de um processo preexistente e utilizando recursos de variabilidade de processo. O processo resultante está
em conformidade com os modelos MR-MPS e Automotive SPICE.
Introdução
A habilidade de desenvolver softwares e eletrônicos de alta qualidade tornou-se um fator crítico
para o sucesso das empresas. Segundo Taurion (2005), no contexto da indústria automotiva, a
diferenciação dos veículos começa a se dar na funcionalidade provida pelos sistemas embarcados
e não mais somente pela mecânica. Esse aspecto leva a mudança na cultura das empresas que
vem substituindo seus componentes mecânicos por componentes mecatrônicos. Embora a utilização
desses sistemas permita às empresas se inserirem no mercado internacional fornecendo respostas
rápidas às necessidades dos seus clientes, também resultam em graves problemas quando os sistemas
embarcados desenvolvidos ou adquiridos não possuem a qualidade esperada.
Na indústria automotiva encontram-se softwares que controlam sistemas de freios inteligentes
(sistemas ABS–Anti-LockSystems), airbags integrados a sistemas de emergência, sistema de injeção
eletrônica, sistema de navegação com utilização de recursos como GPS, entre outros. Sendo assim,
os softwares utilizados nessa indústria devem ser altamente confiáveis, pois controlam e gerenciam
ações críticas no sistema. Defeitos ou falhas nesses softwares podem levar dentre outros fatores a
uma provável perda de vidas humanas e danos ao meio ambiente, ocasionando sensíveis prejuízos à
sociedade e as empresas.
62
WAMPS 2011
Definição de um processo de Engenharia de Requisitos para software embarcado na indústria automotiva baseada em uma Arquitetura
de Processos de Software
Uma das características principais do software embarcado (SE) é o relacionamento com o hardware,
devido a severas limitações quanto ao consumo de potência, tamanho de memória, capacidade de
processamento, dentre outras características físicas [Carro e Wagner, 2009]. Sistemas Embarcados
sofrem estímulos a todo o momento, pois estão inseridos num contexto real, onde múltiplas ações
acontecem simultaneamente. Raramente eles interagem com apenas um único sensor e devem tomar
inúmeras decisões paralelamente. Além disso, Sistemas Embarcados tendem a ter um alto grau de
acoplamento com o hardware, aumentando a complexidade do software.
A demanda por níveis mais altos de confiabilidade pode acarretar em baixo desempenho do software.
Além disso, os custos aumentam significativamente [Sommerville, 2007], pois quanto maior o grau de
confiabilidade exigido de um software, maior a necessidade de prever diferentes cenários possíveis de
execução desse software, o que pode reduzir o desempenho e aumentar a quantidade de memória
exigida, recurso de suma importância e escasso em Sistemas Embarcados. No entanto, segundo
Sommerville (2007), o desenvolvimento de software embarcados (SEs) é visto pelos profissionais
como uma atividade já consolidada e tradicional, e, portanto preferem adotar as técnicas antigas cujo
seus pontos fortes e fracos já são conhecidos ao invés de metodologias e técnicas recentes.
A indústria automotiva passou a procurar o avanço tecnológico estreitando suas relações
com a produção de software, considerando os processos da engenharia de software. Por esse
motivo, representantes da indústria automotiva solicitaram à ISO (International Organization for
Standardization) o desenvolvimento de um framework comum para avaliação dos processos de
produção dos fornecedores de software embarcados para a indústria automotiva. O resultado foi
a publicação do Modelo de Referência de Processo Automotive SPICE [Automotive SIG, 2010a] e
do Modelo de Avaliação de Processo Automotive SPICE [Automotive SIG, 2010b]. A avaliação
dos processos dos fornecedores de software possibilita significativos benefícios para a indústria
automotiva, porém pode também revela a baixa qualidade dos fornecedores de software.
Nesse contexto, este trabalho apresenta a definição de um processo de Engenharia de Requisitos
para software embarcado (SE) da indústria automotiva baseada em uma arquitetura de processos
de software, apoiada por uma análise comparativa entre os processos de Engenharia de Requisitos
do modelo Automotive SPICE [Automotive SIG, 2010] e o MR-MPS [SOFTEX, 2011]. É apresentada
a adaptação, por meio de reuso, de um conjunto de tarefas, papéis, produtos de trabalho e outros
elementos do processo de Requisitos de Software de forma a atender às peculiaridades necessárias
ao desenvolvimento de SEs para a indústria automotiva.
Este artigo está organizado em seções. Na Seção 2 são apresentados conceitos de engenharia de
requisitos e software embarcado; os modelos SPICE Automotive e MR-MPS; e aspectos de reutilização
e arquitetura de processos. Na Seção 3 apresenta-se a proposta de um Processo de Engenharia de
Requisitos para SE definido a partir de um processo padrão de Engenharia de Requisitos. Finalizando,
na Seção 4, apresentam-se a conclusão e trabalhos futuros.
WAMPS 2011
63
Artigos técnicos selecionados
2. Revisão da literatura
Esta seção apresenta os conceitos que foram utilizados para definição do processo padrão de
Engenharia de Requisitos para SE, quais sejam: conceito do processo de engenharia de requisitos e SE
(Seção 2.1); os modelos Automotive SPICE e MR-MPS (Seção 2.2); e reuso e arquitetura de processo
de software (seção 2.3).
2.1. Engenharia de requisitos e Sistemas Embarcados
Problemas em requisitos são uma das principais causas de os projetos falharem. Falhas nas atividades
de entendimento, documentação e gerenciamento de requisitos podem levar a problemas tais
como: sistema que resolve o problema errado, não funciona como esperado, difícil para os usuários
entenderem e utilizarem [Pfleeger, 2004]. Pesquisas apresentam resultados que demonstram que
75% das empresas falham no processo de Engenharia de Requisitos [Hofmann, 2001 apud Damke,
Moraes e Melo, 2008] e que 50% do retrabalho no processo de desenvolvimento ocorre nas atividades
de elicitação, análise e documentação de requisitos [Gastaldo, 2003 apud Damke, Moraes e Melo,
2008]. Estudos mostram que 40% dos problemas em projetos de software estão relacionados a
especificações de requisitos mal feitas e que 66% do total do custo de correção de erros estão na
fase de especificação [Kato, 2004]. Diante desse contexto percebe-se que a Engenharia de Requisitos
é um processo essencial e deve ser executado de maneira eficiente.
Para Marwedel (2003), Sistemas Embarcados são sistemas eletrônicos de processamento de informação
embutidos em produto de forma transparente para o usuário. Algumas de suas características são:
acoplamento ao ambiente físico, ser confiável e eficiente, ser dedicado à aplicação, apresentar
restrições de tempo real e ser reativo (de acordo com a interação com o seu ambiente).
Os princípios da engenharia de software começam a ser empregados como a solução para
desenvolvimento de SEs complexos e críticos. Devido a diversas particularidades que os distinguem
dos demais tipos de softwares como recursos de energia e de memória limitados é preciso uma
adaptação das técnicas, métodos e processos da engenharia de software tradicional para atender
de maneira mais efetiva essas características dos SEs [Damke, Moraes e Melo, 2008]. Uma das áreas
mais frágeis nesse contexto é a engenharia de requisitos, pois suas atividades muitas vezes são
realizadas de maneira falha e em alguns casos nem são realizadas.
2.2. Os modelos Automotive SPICE
No contexto da indústria automotiva, o Automotive SPICE [Automotive SIG, 2010a] foi desenvolvido
com o apoio dos maiores representantes dessa indústria1, como Audi, BMW, Ford, Fiat, Daimler,
Porsche, Volkswagen e Volvo e foi criado em conformidade com a ISO/IEC 15504 [Hoermann et
al, 2008]. Além dos processos definidos na ISO/IEC 15504, o Automotive SPICE conta com alguns
processos novos ou modificados para se adequar às necessidades da indústria automotiva (Hoerman
et al, 2008), como por exemplo, o processo “ENG1.1 – Análise de requisitos do sistema e Design”
que foi dividido em dois processos: “ENG2 – Análise de requisitos do sistema” e “ENG3 – Design de
arquitetura do sistema”. A Figura 1 apresenta a relação entre os processos de engenharia do SPICE e
Automotive SPICE no que diz respeito à Engenharia de Requisitos [Hoermann et al, 2008]:
1
http://www.automotivespice.com/web/Introduction.html (site oficial do Automotive SPICE).
64
WAMPS 2011
Definição de um processo de Engenharia de Requisitos para software embarcado na indústria automotiva baseada em uma Arquitetura
de Processos de Software
Automotive SPICE
SPICE
ENG1 – Análise de requisitos e design de sistema
ENG2 – Análise de requisitos do sistema
ENG3 – Design de arquitetura do sistema
ENG2 – Análise de requisitos de software
ENG4 – Análise de requisitos de software
ENG3 – Design de arquitetura de software
ENG5 – Design de arquitetura de software
ENG4 – Construção de software
ENG6 – Construção de software
ENG5 – Integração de software
ENG7 – Integração de software
ENG6 – Teste de software
ENG8 – Teste de software
ENG7 – Integração e teste de sistema.
ENG9 – Integração de sistema.
ENG10 – Teste de sistema
Figura 1. Relação entre os processos de engenharia do SPICE e Automotive SPICE [Hoermann et al, 2008].
No modelo de referência de processo do Automotive SPICE (Automotive SIG, 2010a) os processos
são descritos em termos de propósitos e resultados. O modelo de avaliação (Automotive SIG, 2010b)
é usado para identificar se o processo alcançou os propósitos e os resultados estabelecidos e verifica
se ele implementa as práticas bases e gera os produtos de trabalho especificados. Os processos
que lidam diretamente com requisitos são “ENG.1 – Elicitação de requisitos”; “ENG.2 – Análise de
requisitos do sistema”; e “ENG.4 – Análise de Requisitos de Software”. O quadro 1 apresenta as
práticas base de cada um desses processos.
2.3. Os modelos Automotive SPICE e MR-MPS
O MPS.BR (Melhoria do Processo de Software Brasileiro) é um programa cujo objetivo é a melhoria
do processo de software brasileiro. Ele tem como foco, não exclusivo, o atendimento à micro,
pequenas e médias empresas [SOFTEX, 2011]. No MR-MPS [SOFTEX, 2011], um dos componentes
do modelo, os processos que tratam da Engenharia de Requisitos são: Gerência de Requisitos (GRE)
e Desenvolvimento de Requisitos (DRE), dos níveis de maturidade G (Parcialmente Gerenciado) e D
(Largamente Definido) respectivamente. Os propósitos desses processos são apresentados no Quadro
2.
Ao comparar os modelos MR-MPS e Automotive SPICE observa-se que, no que diz respeito a
requisitos, uma das principais diferenças entre os modelos é a existência do processo “ENG.2 –
Análise de requisitos do sistema” no Automotive SPICE. Além disso, os critérios de verificação de
requisitos de software e requisitos de sistema devem considerar viabilidade, riscos e testabilidade. Ao
identificar expectativas e restrições do cliente, o ambiente de hardware deve ser analisado.
WAMPS 2011
65
Artigos técnicos selecionados
Quadro 1. Práticas base dos processos ENG1, ENG2 e ENG4.
ENG1 – Elicitação de Requisitos
ENG1.BP1: Obter os requisitos e solicitações do
cliente.
ENG1.BP2: Entender as expectativas do cliente.
ENG1.BP3: Chegar ao acordo sobre os requisitos.
ENG1.BP4: Estabelecer uma linha de base nos
requisitos do cliente.
ENG1.BP5: Gerenciar mudanças nos requisitos do
cliente.
ENG1.BP6: Estabelecer um mecanismo de
comunicação para consulta cliente-fornecedor.
ENG2 – Análise de Requisitos do Sistema
ENG2.BP1: Identificar requisitos de sistema.
ENG2.BP2: Analisar os requisitos de sistema.
ENG2.BP3: Determinar o impacto sobre o ambiente
operacional.
ENG2.BP4: Priorizar e categorizar os requisitos de
sistema
ENG2.BP5: Avaliar e atualizar os requisitos de
sistema.
ENG2.BP6: Assegurar a consistência e rastreabilidade
bilateral de requisitos do cliente para requisitos do
sistema.
ENG2.BP7: Comunicar os requisitos de sistema.
ENG4 – Análise de Requisitos de Software
ENG4.BP1: Identificar requisitos de software .
ENG4.BP2: Analisar os requisitos de software.
ENG4.BP3: Determinar o impacto sobre o ambiente
operacional.
ENG4.BP4: Priorizar e categorizar os requisitos de
software.
ENG4.BP5: Avaliar e atualizar os requisitos de
software.
ENG4.BP6: Assegurar a consistência e rastreabilidade
bilateral de requisitos do sistema para os requisitos
de software.
ENG4.BP7: Assegurar a consistência e a
rastreabilidade bilateral de projeto de sistema de
arquitetura e requisites de software.
ENG4.BP8: Comunicar os requisitos de software.
Quadro 2. Propósito dos processos GRE e DRE.
GRE – Gerência de Requisitos
O propósito do processo Gerência de Requisitos
é gerenciar os requisitos do produto e dos
componentes do produto do projeto e identificar
inconsistências entre os requisitos, os planos do
projeto e os produtos de trabalho do projeto.
DRE – Desenvolvimento de Requisitos
O propósito do processo Desenvolvimento de
Requisitos é definir os requisitos do cliente, do
produto e dos componentes do produto.
Outro fator relevante é que ao definir os requisitos que descrevem a solução do problema, deve-se
considerar que os requisitos de sistema incluem, dentre outros, aspectos de segurança, segurança de
fatores humanos e engenharia (ergonomia). Os requisitos de software (funcionais e não-funcionais),
devem ser estabelecidos com base nos requisitos do sistema e no design de arquitetura do sistema,
mas caso o único componente do sistema seja um software, os requisitos devem ser estabelecidos
baseados nos requisitos do cliente.
66
WAMPS 2011
Definição de um processo de Engenharia de Requisitos para software embarcado na indústria automotiva baseada em uma Arquitetura
de Processos de Software
2.4. Arquitetura de Processos de Software.
Uma Arquitetura de Processos pode ser conceituada como um conjunto de visões representadas
por modelos de processos. Esses modelos representam uma estrutura de processos e dos seus
componentes em termos da sua composição, comportamento e relacionamentos, de acordo com
um domínio e um contexto [Borsoi 2008]. O conjunto de visões determina os níveis de processos de
software definidos, sendo que, desde o processo padrão até o nível de instanciação, os componentes
são descritos em diferentes níveis de abstração. Sendo assim, em uma abordagem top down, quanto
mais baixo o nível, mais específico será o seu conteúdo. Percebe-se então que a organização em
níveis da Arquitetura de Processos permite o reuso de todo o conteúdo do processo padrão.
Segundo Succi et al. (1997), reutilização de processo é definida pela réplica de um conjunto de
ações de um processo já executado em um novo contexto. No entanto, Bayer (1999) afirma que é
necessário que a definição do processo seja feita de forma flexível para que possa ser adaptado a
diferentes situações
Nesse sentido, Ribeiro et al (2011) propõem uma arquitetura de processo organizada em camadas
bastante favorável à reutilização. As camadas dessa arquitetura são assim definidas: (1) Modelos de
referência: “agregam solução aos problemas do ponto de vista do domínio e carregam um conjunto
de conhecimento bastante amadurecido”; (2) Processo padrão ou Processo de Referência:
possui os elementos mínimos de um processo (como por exemplo: atividades; tarefas; entradas;
saídas; papéis; e outros) em conformidade com os modelos de referência adotados; e (3) Processo
em uso: nesta camada estão instâncias do processo padrão e pode possuir dependência com outros
processos ou práticas.
O modelo de processo padrão é baseado no meta-modelo SPEM (Software & Systems Process
Engineering Meta-Model Specification) [OMG 2008], no entanto os autores inseriram outros
elementos para estender a semântica do modelo de processo padrão, como por exemplo, medição
e ferramenta. A seção 3 apresenta uma proposta de processo de engenharia de requisitos para SE
baseada na arquitetura de processo de Ribeiro et al (2011).
3. Engenharia de Requisitos para Sistemas Embarcados
Esta seção apresenta a proposta de um processo padrão de Gestão e Engenharia de Requisitos
em conformidade aos modelos MR-MPS e o Automotive SPICE. Este processo padrão, nomeado
de Engenharia de Requisitos SE (SEs), foi construído a partir do reuso de elementos de um outro
processo padrão de Engenharia de Requisitos de Software de uso geral, aderente ao modelo MRMPS. A Figura 2 apresenta o processo padrão Engenharia de Requisitos SE no contexto geral da
arquitetura de processos.
O Automotive SPICE se difere do MR-MPS em alguns pontos, porém é bastante similar. Desse modo,
foi possível reusar grande parte do processo padrão de Engenharia de Requisitos para compor o
processo padrão Engenharia de Requisitos SE utilizando recursos de variabilidade de processo. A
Figura 3 apresenta o fluxo do processo de Engenharia de Requisitos e suas tarefas.
WAMPS 2011
67
Artigos técnicos selecionados
Figura 2. Arquitetura de processos e processo padrão Engenharia de Requisitos SE.
A principal diferença entre os dois modelos reside do contexto de Engenharia de Sistemas embutido
no Automotive SPICE. Embora no MR-MPS os requisitos do produto possam se referir tanto aos
requisitos de um sistema quanto aos produtos de software que o compõem, o modelo não entra
em detalhes específicos no que tange aos requisitos de sistema. Ao passo que o Automotive SPICE
traz explicitamente as diversas dimensões que os requisitos do sistema podem possuir, entre elas
destacam-se requisitos de segurança, fatores humanos, engenharia (ergonomia) dentre outras.
Figura 3. Processo padrão Engenharia de Requisitos.
68
WAMPS 2011
Definição de um processo de Engenharia de Requisitos para software embarcado na indústria automotiva baseada em uma Arquitetura
de Processos de Software
Por ser um tipo de software bastante acoplado ao ambiente físico, Softwares Embarcados podem
trazer restrições sistêmicas que extrapolam o conceito de software, mas que influem diretamente nos
requisitos do software. A Figura 4 apresenta o processo padrão Engenharia de Requisitos SE e suas
tarefas.
Figura 4. Processo padrão Engenharia de Requisitos SE.
Todas as atividades (Planejar Gestão de Requisitos, Entender o Problema, Identificar Requisitos, Refinar
Requisitos e Gerenciar Requisitos) foram reusadas no processo padrão Engenharia de Requisitos SE.
Entretanto, algumas adaptações foram realizadas (quadros 3 e 4):
Quadro 3. Tarefas incluídas no processo Engenharia de Software SE.
Tarefas incluídas
Justificativa
Identificar Requisitos de Sistema
Tarefa consiste na identificação dos requisitos de sistema.
Atende ao item ENG2.BP1. Identificar Requisitos de Sistema.
Especificar Requisitos de Sistema
Tarefa consiste na especificação dos requisitos de sistema.
Atende ao item ENG2.BP2. Analisar Requisitos de Sistema
WAMPS 2011
69
Artigos técnicos selecionados
Quadro 4. Tarefas adaptadas no processo Engenharia de Software SE.
Tarefas adaptadas
Justificativa
Elaborar Visão
O produto de trabalho resultante desta tarefa foi modificado, passando
de Visão para Visão de Sistema. O novo produto de trabalho é uma
adaptação do produto Visão, contendo além dos aspectos relativos ao
negócio e ao software, aspectos mais amplos sobre o sistema a que
o software está contido, tais como segurança de fatores humanos,
engenharia (ergonomia), interface, operações e manutenção, e restrições
de projeto de engenharia.
Atende ao item ENG2.BP3. Determinar o impacto sobre o ambiente
operacional.
Validar Definição do Sistema
A tarefa Validar Definição de Software foi alterada para Validar Definição
do Sistema, com a inclusão do passo Validar Critérios de Sistema.
Atende aos itens ENG2.BP5. Avaliar e atualizar os requisitos de sistema e
ENG2.BP7. Comunicar os requisitos de sistema.
Validar Requisitos do Sistema
A tarefa Validar Requisitos de Software consiste em realizar a validação dos
requisitos detalhados antes da implementação do software. A tarefa foi
modificada para Validar Requisitos de Sistema, de maneira a incluir critérios
de validação do sistema, além dos critérios específicos do software.
Atende aos itens ENG2.BP5. Avaliar e atualizar os requisitos de sistema e
ENG2.BP7. Comunicar os requisitos de sistema.
Manter Rastreabilidade Itens
Tarefa adaptada para incluir itens de sistema que devem estar relacionados
a requisitos de cliente e software.
Atende aos itens ENG2.BP6. Assegurar a consistência e rastreabilidade
bilateral de requisitos do cliente para requisitos do sistema, ENG4BP6.
Assegurar a consistência e rastreabilidade bilateral de requisitos do sistema
para os requisitos de software e ENG4.BP7. Assegurar a coerência e a
rastreabilidade bilateral de projeto de sistema de arquitetura e requisites de
software.
Priorizar Requisitos
Tarefa adaptada para incluir a priorização de requisitos de sistemas.
Atende ao item ENG2.BP4. Priorizar e categorizar os requisitos de sistema
Alguns produtos de trabalho também foram modificados a partir do processo padrão de Engenharia
de Requisitos, tais como o Visão do Sistema e Atributos de Requisitos e outros produtos de trabalho
foram criados com conteúdo específicos para SEs.
4. Conclusão
Neste artigo foi apresentada uma proposta de processo padrão de engenharia de requisitos aderente
ao MR-MPS. A partir do processo padrão foi gerado um Processo em Uso para engenharia de
requisitos para SE no contexto da indústria automotiva. Com o apoio da ferramenta Eclipse Process
Framework (EPF), que implementa os conceitos do meta-modelo SPEM (Software and Systems
Process Engineering Meta-Model Specification), foram utilizados conceitos de reutilização e os tipos
de variabilidade de processo. As atividades/tarefas específicas para SE estão baseadas no modelo
Automotive SPICE.
70
WAMPS 2011
Definição de um processo de Engenharia de Requisitos para software embarcado na indústria automotiva baseada em uma Arquitetura
de Processos de Software
A construção do processo padrão para Engenharia de Requisitos para Sistemas Embarcados baseado
em reuso de um processo pré-existente foi beneficiada com o aproveitamento de conhecimentos
já embutidos no processo de Engenharia de Requisitos de uso geral, foi mantida a aderência ao
modelo MR-MPS e, consequentemente, houve a redução do esforço que foi empregado em relação
ao desenvolvimento sem o reuso. Embora o processo padrão de Engenharia de Requisitos não tenha
passado por uma avaliação formal, foi avaliado internamente para manter a aderência aos resultados
esperados dos processos GRE e DRE do modelo MR-MPS.
A proposta do Processo em Uso para desenvolvimento de SE para indústria automotiva encontra-se
em fase de desenvolvimento e deverá contemplar não apenas a engenharia de requisitos, mas todos
os processos previstos no modelo Automotive SPICE.
Agradecimentos
Ao Conselho Nacional de Desenvolvimento Científico e Tecnológico (CNPq) pelo auxílio financeiro
concedido pelo edital ProIC 2011.
À Fundação de Apoio a Pesquisa do Distrito Federal (FAP-DF) pelo auxílio financeiro concedido para
participação no evento.
Referências
AUTOMOTIVE SIG. (2010b) “Automotive SPICE Process Assessment Model”. http://www.
automotivespice.com/automotiveSIG_PAM_v25.pdf, Maio.
AUTOMOTIVE SIG. (2010a) “Automotive SPICE Process Reference Model”. http://www.
automotivespice.com/automotiveSIG_PRM_v45.pdf. Maio.
Borsoi, B. T. (2008) “Arquitetura de processo aplicada na integração de fábricas de software”, p. 3761. Tese de Doutorado em Engenharia Elétrica. Universidade de São Paulo, USP, Brasil. Carro, L., Wagner, F. R. (2009) “Metodologias e Técnicas de Engenharia de Software para Sistemas
Embarcados”. In Atualizações em Informática 2009. Rio de Janeiro: Ed PUC-Rio. p. 154-159.
Damke, D. E., Moraes P. F., Melo, C. O. (2008) “Avaliação do processo de Gerenciamento e Engenharia
de Requisitos em MPEs de Sistemas Embarcados: um estudo de caso”. In Simpósio de Excelência
em Gestão e Tecnologia.
Gastaldo, D. L., Midorikawa, E. T. (2003) “Processo de Engenharia de Requisitos Aplicado a Requisitos
Não-Funcionais de Desempenho – Um Estudo de Caso”. In Workshop de Engenharia de Requisitos.
Hoermann, K., Mueller, M., Dittmann, L., Zimmer, J. (2008) “Automotive SPICE in Practice: Surviving
Interpretation and Assessment”. Rocky Nook
Hofmann, H. F., Lehner, F. (2001) “Requirements Engineering as a Success Factor in Software Projects”.
IEEE Software, p. 58–66.
WAMPS 2011
71
Artigos técnicos selecionados
ISO/IEC (2006) ISO/IEC 15504.Information Technology – Process Assessment. Part 1 (2004) –
Concepts and vocabulary; part 2 (2003) – Performing an assessment; part 3 (2004) – Guidance on
performing an assessment; part 4 (2004) – Guidance on use for process improvement and process
capability de-termination; and part 5 (2006) – An exemplar process assessment model.
Kato, M. (2004) “A Especificação de Requisitos no Processo de Desenvolvimento de Software”.
Trabalho de conclusão do curso de Graduação em Ciência da Computação. Universidade Estadual
de Londrina, UEL, Brasil.
Marwedel, P. (2003) “Embedded System Design”. Springer.
OMG. (2008) “Software & Systems Process Engineering Meta-Model Specification”. [S.l.], Abril.
Pfleeger, S. (2004) “Engenharia de Software – Teoria e Prática”, 2a. ed. Prentice Hall.
Ribeiro, L. C. M., Ramos, C. S., Crozara, K., Neri, H., Alves, E., Figueiredo, R. M.C., (2011) “Definição
de Processos de Software baseada em uma Arquitetura de Componentes de Processo”. In Simpósio
Brasileiro de Qualidade de Software, p. 263 – 277.
SOFTEX, Associação para Promoção da Excelência do Software Brasileiro. (2011) “MPS.BR – Guia
Geral”. http://www.softex.br, Agosto.
Sommerville, I. (2007) “Engenharia de Software”. 8. ed. São Paulo: Pearson Addison-Wesley.
Succi, G., Benedicenti, L., Predonzani, P., Vernazza, T. (1997) “Standardizing the Reuse of Software
Process”. In StandardView – Special issue on reuse standards and software. ACM. Volume 5, Issue
2, p. 74-83.
Taurion, C. (2005) “Software Embarcado – A Nova Onda da Informática”. Brasport.
72
WAMPS 2011
Definição de um processo de Engenharia de Requisitos para software embarcado na indústria automotiva baseada em uma Arquitetura
de Processos de Software
WAMPS 2011
73
Artigos técnicos selecionados
Lições Aprendidas com o uso do processo do
Guia de Aquisição – MPS.BR
Danilo Scalet1, Edmeia Leonor Pereira de Andrade2, João Condack3
CELEPAR – Companhia de Informática do Paraná
R Mateus Leme 1561 – CEP 80530-010 – Curitiba – PR – Brasil
1
Empresa Brasileira de Pesquisa Agropecuária
Parque Estação Biológica – PqEB s/nº – AV. W3 Norte (final) – Edifício Sede – 70770-901 – Brasília – DF – Brasil
2
PrimeUp – Instituição de Consultoria de Aquisição
Av. Graça Aranha, 326 sala 91 – CEP 20030-001 – Rio de Janeiro – RJ – Brasil
3
[email protected], [email protected], [email protected]
Abstract. This paper describes the lessons learned when performing acquisition of software and related
services taking into account the MPS Acquisition Guide. It is hoped that these lessons will contribute as
references in developing acquisition projects by public and private organizations.
Resumo. Este trabalho descreve lições aprendidas na aquisição de software e serviços correlatos levando-se
em conta o processo descrito no Guia de Aquisição MPS. Espera-se que estas lições sirvam como referências
no desenvolvimento de projetos de aquisição por organizações públicas e privadas.
1. Introdução
Práticas de gerenciamento ineficazes, falta de habilidade para identificar necessidades de usuários,
definição de requisitos incompleta, seleção de fornecedor e processos de elaboração de contratos
inadequados, procedimentos impróprios para seleção de tecnologia e mudanças em requisitos feitas
sem controle são as principais causas de problemas nas aquisições de Software e Serviços Correlatos
(S&SC) [SEI 2010]. Para atacar estas causas e mitigar o risco de insucesso da aquisição, um processo
como preconizado no Guia de Aquisição [SOFTEX 2009a] e lições aprendidas como as expostas neste
artigo são instrumentos bastante úteis. No caso da incidência de problemas, diversas consequências
são percebidas. [ALVES 2004] apresenta uma lista de problemas que são considerados clássicos
durante o processo de aquisição de S&SC:
• Aumento do custo previsto e de manutenção;
• Descumprimento de cronograma;
• Relação pobre entre cliente e fornecedor;
• Produtos inexequíveis;
• Não atendimento às necessidades, expectativas ou requisitos do usuário;
• Dificuldades de personalização do software;
74
WAMPS 2011
Lições Aprendidas com o uso do processo do Guia de Aquisição – MPS.BR
• Perda de controle ou falta de acompanhamento do projeto;
• Falta de visibilidade dos processos de Subcontratado;
• Excesso de retrabalho;
• Dificuldade na prevenção de defeitos e problemas;
• Baixa disponibilidade de recursos humanos; e
• Alta rotatividade de pessoal.
Este trabalho tem como objetivo descrever as principais lições aprendidas na utilização do processo
de aquisição descrito no Guia de Aquisição [SOFTEX 2009a]. Essas lições foram aprendidas a partir
da experiência dos autores em consultoria para projetos de aquisição de serviços no modelo de
fábrica de software, produtos de software modificáveis, produto de software sob encomenda e
pacotes de software para empresas públicas e organizações da administração direta em âmbitos
estadual e federal. Além do envolvimento nestes projetos, parte destas experiências foram fruto
de situações práticas discutidas com alunos representando instituições públicas e privadas de vários
estados brasileiros durante mais de uma dezena de cursos de aquisição ministrados pelos autores.
A seção 2 apresenta uma breve descrição do processo de aquisição e os critérios de formação
de Consultores de Aquisição (CA) e de Instituições de Consultoria de Aquisição (ICA). A seção 3
apresenta as principais lições aprendidas na aplicação do processo de aquisição. Finalmente, a seção
4 apresenta as conclusões deste trabalho.
2. Processo de aquisição e consultores de aquisição
O Guia de Aquisição MPS.BR descreve, de forma detalhada e com exemplos práticos um processo
para aquisição de Software e Serviços Correlatos (S&SC). Este guia, seguindo as diretrizes do MPS.
BR, está em conformidade com a definição de uma norma internacional, a ISO/IEC 12207 – Processos
do Ciclo de Vida do Software [ISO/IEC 2008] e é consistente com o Modelo de Referência do MPS.
BR (MR-MPS) [SOFTEX 2009b]. Observe-se, no entanto, que instituições que pretendam ser avaliadas
segundo os níveis de maturidade estabelecidos no Guia Geral do MPS.BR [SOFTEX 2009b] deverão
levar em conta a descrição do processo de aquisição conforme consta no Guia Geral.
O processo de aquisição, descrito no Guia de Aquisição, é ajustado para aquisições de produtos de
prateleira comercialmente disponíveis (pacote de software), de produtos de software personalizados
ou de um domínio específico, tanto por instituições privadas como por instituições públicas de
distintos portes.
O processo compreende todo o ciclo de vida de aquisição de S&SC, contemplando as atividades
de preparação da aquisição, seleção do fornecedor, monitoração do contrato e aceitação pelo
cliente (ver Figura 1). São estabelecidas tarefas a serem desenvolvidas nas atividades preliminares
de identificação de necessidades e definição da estratégia da aquisição, na seleção de fornecedores,
no acompanhamento de toda a execução contratual até a aceitação final do S&SC. Também são
definidos produtos de trabalho requeridos e gerados a cada tarefa. Este processo sugere a necessidade
de participação de especialistas em aquisição de S&SC e de diversas outras funções envolvidas.
WAMPS 2011
75
Artigos técnicos selecionados
Preparação da
aquisição
1.
2.
3.
4.
5.
Estabelecer a necessidade
Definir os requisitos
Revisar os requisitos
Desenvolver uma estratégia de aquisição
Definir os critérios de seleção de fornecedores
Seleção do
fornecedor
1.
2.
3.
Avaliar a capacidade dos fornecedores
Selecionar o fornecedor
Preparar e negociar um contrato
Monitoração do
contrato
1.
2.
3.
4.
5.
6.
Estabelecer e manter comunicações
Trocar informação sobre o progresso técnico
Revisar o desempenho do fornecedor
Monitorar a aquisição
Obter acordo quanto às alterações
Acompanhar problemas
Aceitação pelo
cliente
1.
2.
3.
4.
Preparar a aceitação
Avaliar o S&SC entregue
Manter conformidade com o contrato
Aceitar o S&SC
Figura 1. Processo de Aquisição MPS.
O propósito da atividade de preparação da aquisição é estabelecer as necessidades e os requisitos da
aquisição e comunicá-los aos potenciais fornecedores. A execução desta atividade é fundamental para
o estabelecimento da estratégia de condução de todo o processo de aquisição, levando-se em conta
as necessidades e requisitos estabelecidos, bem como as demais variáveis de contexto da aquisição.
O propósito da atividade de seleção do fornecedor é escolher a organização que será responsável pelo
desenvolvimento e entrega do S&SC, em conformidade com os requisitos estabelecidos. A execução
desta atividade busca identificar o fornecedor adequado aos requisitos estabelecidos, levando-se
em conta uma combinação harmoniosa entre resultados a serem obtidos, prazos, recursos e riscos
envolvidos. Como consequência será escolhido o fornecedor que prestará o serviço até o final do
contrato.
O propósito da atividade de monitoração do contrato é acompanhar e garantir o desempenho do
fornecedor mediante os termos do contrato. A execução desta atividade é fundamental para monitorar
o desenvolvimento do S&SC e da relação adquirente-fornecedor durante todo o período do contrato
estabelecido. As avaliações realizadas ao longo do desenvolvimento do contrato permitem identificar
problemas, tomar decisões gerenciais, projetar a qualidade final esperada para o S&SC e minimizar
riscos. Dependendo da abordagem adotada, os resultados de avaliações intermediárias poderão ser
utilizados nas tarefas da atividade de aceitação.
O propósito da atividade de aceitação pelo cliente é aprovar S&SC entregues pelo fornecedor
quando todos os critérios de aceitação estiverem satisfeitos. Nesta atividade são refinados os critérios
de aceitação que foram definidos no plano de projeto e incorporados no pedido de proposta e
no contrato. As avaliações podem ser conduzidas no decorrer do contrato, por uma abordagem
envolvendo múltiplas iterações e entregas de produtos, ou por meio de uma entrega única. Os
S&SC entregues são analisados para identificar a conformidade aos critérios estabelecidos. As tarefas
76
WAMPS 2011
Lições Aprendidas com o uso do processo do Guia de Aquisição – MPS.BR
de avaliação são concebidas de modo a reduzir a interferência com as avaliações executadas pelo
fornecedor e a duplicação de esforços de avaliação. Não havendo aprovação do S&SC e, dependendo
das cláusulas contratuais, podem ser planejados e implementados ajustes para que o produto seja
submetido a uma nova avaliação. Este ciclo ocorre enquanto o produto não é aprovado, ou até que
seja definitivamente rejeitado.
3. Lições Aprendidas
A utilização de um processo de aquisição de S&SC, como o descrito no Guia de Aquisição [SOFTEX
2009a] depende de diversos fatores como, por exemplo, a característica da organização adquirente, o
tipo de S&SC a ser contratado, o porte da contratação, entre outros. As lições aprendidas e relacionadas
a seguir procuram estabelecer uma perspectiva genérica que contemple larga abrangência nos
projetos de aquisição.
3.1. Lição 1: Implantação do processo de aquisição em grandes adquirentes de
S&SC
Organizações, cujo porte e estratégia organizacional exigem que executem com alguma frequência
projetos de aquisição, poderão obter resultados com maior eficácia e eficiência se personalizarem
a implantação do Processo de Aquisição MPS. O processo descrito no Guia de Aquisição [SOFTEX
2009a] é aplicável a múltiplas modalidades de aquisição e diferentes tipos de empresa. Neste sentido,
a descrição do processo é genérica e sua implantação deve levar em conta as características de cada
organização. No caso de organizações adquirentes de maior porte, a personalização do processo é
ainda mais relevante, em função dos ganhos que podem ser obtidos na aplicação do processo em
múltiplos projetos de aquisição.
A personalização do processo de aquisição inclui os seguintes tópicos:
• detalhar o processo padrão a ser adotado: descrever as atividades e tarefas a serem realizadas;
descrever os produtos de trabalho (entradas e saídas) das tarefas; identificar as ferramentas a
serem utilizadas para elaboração das tarefas; e definir as responsabilidades organizacionais para
a realização das tarefas;
• descrever os processos de gestão adotados na organização e aplicáveis no processo de aquisição
como, por exemplo, gestão de requisitos, de comunicações, custos, mudanças, problemas, prazos
e qualidade;
• definir os instrumentos de apoio ao processo, tais como: descrever os métodos, técnicas e ferramentas
aplicáveis nos projetos de aquisição; definir os padrões a serem adotados nos produtos de trabalho
das respectivas tarefas (por exemplo, templates para documentos); e definir e adotar um ciclo de
identificação, avaliação, disseminação, uso e feedback de uso dos instrumentos de apoio;
• identificar as variáveis do contexto organizacional que possam afetar os projetos de aquisição,
podendo vir a ser utilizadas como requisitos e restrições padrão para os projetos, tais como:
outros processos aplicados na organização e que sejam diretamente relacionados ao processo de
aquisição; ambiente de hardware e software utilizado na organização; habilidades e qualificações
WAMPS 2011
77
Artigos técnicos selecionados
das pessoas envolvidas em projetos de aquisição; políticas gerais de contratação de S≻ e
definições estabelecidas no Planejamento Estratégico da organização que possam influenciar os
projetos de aquisição (por exemplo, prioridades);
• identificar as variáveis do contexto regulatório relacionado à organização e que possam afetar os
projetos de aquisição, tais como leis e regulamentos externos e internos que regem o funcionamento
da organização (leis, normas, acórdãos, regulamentos internos, entre outros);
• identificar as variáveis do contexto do mercado ao qual está inserida a organização e que possam
afetar os projetos de aquisição, tais como: S&SC potencialmente de interesse da organização;
potenciais fornecedores e seu histórico de fornecimento à organização; referências e uso de S&SC
por outras organizações; e referências técnicas e comerciais aplicáveis.
3.2. Lição 2: utilização de lições aprendidas como forma de realimentar o
processo
A execução de projetos de aquisição permite um aprendizado organizacional que, sendo
adequadamente tratado, leva ao aprimoramento contínuo do processo de aquisição nas organizações.
Aspectos relacionados à especificação de requisitos, definição de responsabilidades entre as partes
envolvidas, critérios de monitoração do contrato e de aceitação de produtos, forma de gestão do
projeto de aquisição, tipos de artefatos a serem solicitados conforme o tipo de aquisição, entre outros,
são exemplos que devem ser tratados para a evolução do processo de aquisição numa organização.
A compilação e organização das lições aprendidas são trabalhos desenvolvidos em paralelo com
os projetos de aquisição, de modo a identificar os aspectos relevantes e descrever o contexto e as
conclusões obtidas das experiências. O resultado desta análise poderá ser utilizado para atualizar o
processo padrão adotado, modificar os instrumentos de apoio aos projetos, alterar os processos de
gestão utilizados, além de orientar os técnicos da organização que estejam envolvidos em projetos
de aquisição.
3.3. Lição 3: tratamento da aquisição de S&SC como projeto
Quando uma organização define por adquirir S&SC, é importante que entenda que este
empreendimento necessita ser tratado como um projeto como outro qualquer, porém com algumas
peculiaridades. O projeto de aquisição pode ser subdividido em duas partes: a fase de contratação, que
corresponde às atividades de preparação da aquisição e seleção do fornecedor e a fase de execução
do contrato, que corresponde às atividades de monitoração do contrato e aceitação pelo cliente.
A primeira fase da aquisição é realizada tipicamente pela equipe do adquirente, salvo em situações
quando são contratadas organizações para realizar tarefas específicas como, por exemplo, a
especificação de requisitos. Nesta fase, o principal produto gerado é o plano de aquisição, que aborda
todos os aspectos a serem considerados na aquisição, inclusive durante a fase de execução do contrato.
Na segunda fase o projeto de aquisição convive com o projeto detalhado de execução do contrato
pelo fornecedor contratado, levando em conta as definições estabelecidas no plano de aquisição.
Neste caso a gestão do projeto torna-se mais complexa em função da interação entre dois (ou mais)
agentes envolvidos.
78
WAMPS 2011
Lições Aprendidas com o uso do processo do Guia de Aquisição – MPS.BR
3.4. Lição 4: A monitoração do contrato como garantia de qualidade da
aquisição
O Guia de Aquisição MPS [SOFTEX 2009a] aborda a monitoração do contrato por meio de três tarefas:
trocar informações sobre o progresso técnico, revisar o desempenho do fornecedor e monitorar a
aquisição. Estas tarefas objetivam assegurar a qualidade dos resultados do projeto de aquisição,
sob a ótica de atendimento aos requisitos, custos, prazos e riscos envolvidos. As medidas obtidas
no processo de monitoração permitem orientar as ações gerenciais a serem tomadas ao longo da
execução do projeto, visando manter os rumos do projeto e as atividades do fornecedor dentro dos
limites esperados.
O projeto de monitoração, que deve ser descrito no plano de aquisição, deverá levar em conta alguns
aspectos para que seja efetivo para a organização contratante:
• deverá considerar a monitoração de uma situação presente, porém que possibilite uma
análise da perspectiva futura do projeto frente às medidas obtidas no evento da monitoração,
orientando a tomada das ações gerenciais cabíveis;
• deverá ser projetada para permitir a avaliação de diferentes perspectivas, em função das
características do projeto de aquisição. Assim, poderá contemplar monitoração do processo de
desenvolvimento adotado pelo fornecedor (por exemplo, no caso de contratação de uma fábrica
de software), monitoração da qualidade do produto de software [ABNT 2001] (por exemplo, no
caso de contratação de um software sob encomenda) ou monitoração dos resultados parciais
obtidos com o uso de um sistema, medindo-se a qualidade em uso [ABNT 2001];
• deverá, sempre que possível, definir medidas para monitoração que estejam disponíveis
automaticamente a partir do processo de desenvolvimento do fornecedor, reduzindo os
custos e prazos para obtenção destas medidas. É evidente que, quando alguma medida for
imprescindível, deverá ser obtida mesmo que não esteja disponível como parte do processo de
desenvolvimento; e
• a complexidade de análise das medidas deverá ser compatível com a capacidade técnica da
equipe da organização adquirente. Caso a característica do projeto de aquisição exija análises
mais complexas que a capacidade técnica disponível, a organização deverá buscar apoio de
uma terceira-parte ou, em casos extremos, avaliar a viabilidade de efetivamente conduzir o
projeto de aquisição.
3.5. Lição 5: A importância de ferramentas integradas e da integração de
processos sensíveis a toda organização
O processo de aquisição descrito no Guia de Aquisição, bem como suas atividades, não são um
componente isolado dos demais processos de uma organização. A atividade de “Preparação da
aquisição” está intimamente ligada com o planejamento estratégico ou eventualmente tático de
uma unidade organizacional. “Seleção do fornecedor” é uma atividade que reflete procedimentos
de compras que são potencialmente (ou idealmente) padronizadas, sendo apenas particularizadas
eventualmente, dependendo da natureza de produto ou serviço adquirido. Já as atividades de
“Monitoração do contrato” e “Aceitação pelo cliente” podem ser observadas como extensões de
processos de gestão de projetos e de mudanças, neste caso particular, quando o objetivo do projeto
é realizado por um terceiro.
WAMPS 2011
79
Artigos técnicos selecionados
Isto posto, é importante que as ferramentas e os processos utilizados institucionalmente tenham
algum grau, preferencialmente alto, de integração horizontal ou vertical.
A integração horizontal ocorre quando as ferramentas e processos utilizados em uma determinada
atividade de aquisição de S&SC são derivados dos utilizados em atividades semelhantes, porém de
outro setor da organização. Neste caso de integração horizontal, quanto mais semelhantes são os
processos e ferramentas de distintas áreas melhor, sendo o ideal que as ferramentas sejam as mesmas
para facilitar a troca e consolidação de dados institucionais.
A integração vertical trata da relação entre processos e ferramentas de diferentes atividades no
contexto de um fluxo de processos de negócio, como é o caso de um fluxo (ou processo) de aquisição.
Neste caso, quanto menos transformações são necessárias para encadear uma atividade à outra,
mais integrados são os processos e ferramentas.
É relevante perceber o efeito multiplicador que a integração horizontal tem sobre a integração vertical,
facilitando uma estratégia de implantação de processos abrangente (ou pelo menos sensível) a toda
a organização. Percebem-se também as vantagens desta integração global na maior facilidade para
obter dados consolidados e com mais valor agregado, pois trata o processo de negócio do início ao
fim e o mantém compatível com as várias unidades da organização. Obtém-se também a possibilidade
de ganho pelo reúso e pela diminuição do número de ativos – processos e ferramentas – a serem
mantidos. Como desvantagem, a alta integração pode trazer maior dificuldade de substituição de
um destes ativos, caso necessário.
Recomenda-se, assim, que, ao abordar o processo de aquisição em uma instituição, sejam avaliados
os processos e ferramentas de planejamento estratégico, compras e relação com fornecedores
organizacionais, gestão de projetos e gestão de mudanças.
3.6. Lição 6: Entender a diversidade dos envolvidos, sua relação com TI e a forma
com que expressam suas intenções
Ao tratar o processo de aquisição, nota-se que diferentes áreas de uma organização são envolvidas,
como, por exemplo: jurídico, informática e compras. Diferentes níveis técnicos e gerenciais também
se fazem presentes. Soma-se a isto a caracterização de distintos clientes/usuários e fornecedores.
Desta forma, existe uma gama considerável de diferentes atores com suas visões particulares do
processo de aquisição e do S&SC adquiridos.
Entendendo que, para obter êxito em uma aquisição, estes atores terão que se comunicar e que
em um modelo de comunicação a mensagem está tão mais sujeita a ruídos quanto mais diferentes
forem os emissores e receptores da mesma, é importante analisar a diversidade existente de atores
no processo de aquisição. Os artefatos existentes devem passar pelo crivo de seus produtores e
consumidores sob o cuidado de validar se a mensagem a ser passada não corre riscos desnecessários
de ser mal interpretada.
Esta questão de comunicação é especialmente sensível em projetos de aquisição que envolvam
elicitação de requisitos junto a usuários. Neste caso o projeto de aquisição pode apresentar dificuldades
no entendimento e trabalho a priori das características específicas de comunicação daquele público. O
processo de aquisição deve então recomendar e verificar se as fontes de requisitos têm a familiaridade
necessária com o domínio envolvido, bem como com o processo de elicitação de requisitos, além de
características pessoais que permitam boa comunicação de suas intenções.
80
WAMPS 2011
Lições Aprendidas com o uso do processo do Guia de Aquisição – MPS.BR
3.7. Lição 7: Adequar o processo de aquisição às necessidades das organizações
públicas e a legislação brasileira
O processo de aquisição serviu de base para elaboração do Processo de contratação de software e
serviços correlatos para entes governamentais, no escopo de um projeto submetido ao Programa
Brasileiro de Qualidade de Software em 2009, vencedor do prêmio Dorgival Brandão Júnior – 1º lugar.
O processo elaborado integra aspectos técnicos e jurídicos em um único processo e facilita a
comunicação entre as áreas envolvidas nas contratações (TI, jurídica, administrativa, orçamentária
e controle). De acordo com [CRUZ; ANDRADE; FIGUEIREDO 2010], “ao comparar o processo de
Aquisição do MPS.BR com o marco legal, foram identificadas algumas lacunas: i) ausência de clara
vinculação entre a aquisição e as diretrizes estabelecidas no planejamento estratégico de TI; ii)
ausência de identificação clara de papéis relevantes e seus atores, tais como gestor do contrato,
requisitante da contratação, autoridade competente, fiscal do contrato etc.; iii) ausência de previsão
da fase licitatória; iv) menor rigor com a formalização e a motivação do que o exigido pela legislação
para o setor público; v) ênfase na negociação com fornecedores, o que não é possível no setor
público; vi) ausência de rigor formal na fase de gestão do contrato (p.ex. uso da ordem de serviço)”.
4. Conclusão
Este artigo apresentou as principais lições aprendidas na aplicação do Processo de Aquisição, constante
no Guia de Aquisição – MPS. As lições aprendidas apresentadas complementam as informações do
guia, a partir de uma visão prática do uso do processo em projetos de aquisição desenvolvidos para
organizações públicas e privadas.
Este conjunto básico de lições aprendidas é bastante genérico e busca estimular que as organizações
que adquirem S&SC compreendam a importância de identificar e disseminar boas práticas que lhes
permitam obter melhorias expressivas em seus projetos de aquisição.
Referências
[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.
[ALVES 2004] – ALVES, Ângela M; GUERRA, Ana. Aquisição de Produtos e Serviços de Software. Rio
de Janeiro: Elsevier, 2004. 213p.
[CRUZ; ANDRADE; FIGUEIREDO 2010] – CRUZ, Cláudio Silva da Cruz; ANDRADE, Edméia Leonor
Pereira de; FIGUEIREDO, Rejane Maria da Costa. Processo de contratação de software e serviços
correlatos para entes governamentais. Revista Programa Brasileiro da Qualidade e Produtividade
em Software. 1ª Edição, maio de 2010 – Projetos Ciclos 2008 e 2009 – v.1, p. 87-93. ISSN 21780277. Disponível em: <http://www.mct.gov.br/upd_blob/0212/212192.pdf>. Acesso em: 30 set.
2010.
WAMPS 2011
81
Artigos técnicos selecionados
[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.
[SEI 2010] SOFTWARE ENGINEERING INSTITUTE. CMMI for Acquisition (CMMI-ACQ), Version
1.3, Technical Report CMU/SEI-2010-TR-032: Software Engineering Institute, Carnegie Mellon
University. Pittsburgh, PA, 2010.
[SOFTEX 2009a] – ASSOCIAÇÃO PARA PROMOÇÃO DA EXCELÊNCIA DO SOFTWARE BRASILEIRO –
SOFTEX. MPS.BR – Guia de Aquisição: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 Geral:2009, maio 2009. Disponível em: <www.softex.br>.
82
WAMPS 2011
Lições Aprendidas com o uso do processo do Guia de Aquisição – MPS.BR
WAMPS 2011
83
Artigos técnicos selecionados
Lições Aprendidas em Implementações de
Melhoria de Processos em Organizações com
Diferentes Características
Natália Chaves Lessa Schots1, Gleison Santos2, Cristina Cerdeiral1, Mylene Lisbôa Cabral1, Reinaldo Cabral1,
Marcelo Schots1, Elaine Nunes1, Ana Regina Rocha1
COPPE/UFRJ – Universidade Federal do Rio de Janeiro
Caixa Postal 68511 – CEP 21945-970 – Rio de Janeiro – Brasil
1
Programa de Pós-Graduação em Informática – Universidade Federal do Estado do Rio de Janeiro (UNIRIO)
Av. Pasteur 458, Urca, CEP 22290-240 – Rio de Janeiro – RJ
2
[email protected], [email protected],
{cerdeiral,mylene,cabral,schots,elainenunes,darocha}@cos.ufrj.br
Abstract. Two key factors to the success of a software process improvement (SPI) initiative conducted by an
Implementation Institution (II) are the existence of a good strategy and a competent team. However, this is
not enough due to the complex nature of the SPI activities, which demands both technical and organizational
culture knowledge so that such implementation can be suitable and effective. This paper presents the lessons
learned by the COPPE/UFRJ II during SPI implementation in organizations with different characteristics.
Resumo. A existência de uma boa estratégia e de uma equipe competente para a condução de iniciativas de
implantação de melhoria de processos nas organizações por parte de uma Instituição Implementadora (II) são
dois fatores de sucesso importantes. Porém, estes dois fatores não bastam por si só, devido à complexidade
natural das atividades de implementação de melhoria, que demanda tanto o conhecimento técnico como
o da cultura da organização, para que a iniciativa seja adequada e efetiva. Este artigo apresenta as lições
aprendidas da II COPPE/UFRJ ao auxiliar a implementação de melhorias em organizações com características
próprias, adaptando o trabalho da equipe de implementadores de acordo com estas características.
1. Introdução
As organizações de desenvolvimento de software estão cada vez mais preocupadas em adotar
programas de melhoria a fim de obter maior competitividade e garantir sua sobrevivência no mercado.
No entanto, diversos fatores podem dificultar a implantação destes programas de melhoria devido à
complexidade desta atividade. De acordo com Montoni (2010), a implementação de melhorias em
processos de software é um fenômeno sócio-cultural e é dependente de diversos fatores que podem
comprometer seu sucesso. Dentre os fatores de sucesso identificados por este pesquisador está a
adequação da implementação dos processos e procedimentos com as especificidades da empresa. Para
alcançar este fator, os consultores devem possuir conhecimento adequado em engenharia de software,
bem como serem flexíveis para lidar com situações adversas de implementação [Montoni 2010].
Desde 2005 a COPPE/UFRJ implementa o MR-MPS [Softex 2011] e o CMMI-DEV [SEI, 2010] em
micro, pequenas, médias e grandes empresas, no Rio de Janeiro e em outras localidades do país, e
tem obtido expressivos resultados nessas implementações. Ao longo deste período, construiu-se uma
84
WAMPS 2011
Lições Aprendidas em Implementações de Melhoria de Processos em Organizações com Diferentes Características
estratégia para a implementação de iniciativas de melhoria de processos nas organizações [Santos
et al. 2007]. Além disso, as iniciativas de melhoria realizadas em organizações clientes permitiram a
aquisição de um corpo de conhecimento prático sobre melhoria de processos de software.
Sabe-se que a existência de uma estratégia estabelecida e do corpo de conhecimento sobre melhoria
de processos de software é importante, mas isto não garante, por si só, o sucesso das implementações
conduzidas. A implementação de melhorias em processos de software é uma atividade complexa, que
demanda tanto conhecimento técnico como conhecimento sobre a cultura da organização para que
a implementação seja adequada e efetiva. Além disso, como cada organização possui características
muito diferentes, é importante que haja uma adaptação da estratégia utilizada em cada contexto.
Este artigo possui o objetivo de apresentar como a equipe da Instituição Implementadora COPPE/UFRJ
se adaptou ante as diferentes características das organizações nas quais auxiliou a implementação
de melhorias de acordo com diferentes níveis do MR-MPS [Softex 2011] durante o ano de 2010. Na
Seção 2, a Instituição Implementadora COPPE/UFRJ é apresentada, e sua estratégia de implementação
é descrita. As características das organizações e como a estratégia de implementação foi adaptada
para cada uma delas são discutidas na Seção 3 e na Seção 4, respectivamente. Na Seção 5, as
principais lições aprendidas são descritas. Por fim, na Seção 6, são apresentadas as considerações
finais.
2. Estratégia de Implementação da COPPE/UFRJ
A COPPE/UFRJ é uma Instituição Implementadora (II) e Instituição Avaliadora (IA) MPS credenciada
pela SOFTEX desde 2006. A II COPPE tem atuado na implementação de melhoria de processos de
software em micro, pequenas, médias e grandes empresas, localizadas no Rio de Janeiro e em outros
estados do país. Atua também como uma IOGE (Instituição Organizadora de Grupos de Empresas).
Com o objetivo de apoiar a implementação de iniciativas em prol da melhoria de processos em
organizações de software, a II COPPE desenvolveu uma estratégia de implementação fortemente
baseada em conhecimento, denominada SPI-KM [Barreto et al. 2006; Santos et al. 2007]. Essa
estratégia tem demonstrado sua viabilidade e seus benefícios através de muitas avaliações de processo
finalizadas com sucesso nos últimos anos, por exemplo, [Santos et al. 2008; Catunda et al., 2010;
Catunda et al., 2011]. Esta abordagem está sendo aplicada tanto nas implementações em empresas
individuais quanto nas que participam de algum grupo de empresas.
Resumidamente, a estratégia SPI-KM pode ser descrita da seguinte forma [Santos et al. 2007]:
inicialmente, é realizada a seleção do modelo de maturidade e o nível pretendido pela organização,
além de verificação da cultura existente. Depois disso, a iniciativa de melhoria é planejada e um
processo de desenvolvimento de software padrão é definido junto com a organização. Os profissionais
são treinados nos processos a serem executados, tanto de forma teórica, como durante suas
execuções através de mentoring. Ao longo da execução dos processos, ocorre a aquisição e registro
de conhecimento, além da coleta de recomendações de melhoria nos processos, que, posteriormente,
são avaliadas e podem levar a mudanças na definição do processo. Por fim, é realizada a preparação
da organização para a avaliação dos processos, onde todos os participantes tomam conhecimento do
processo de avaliação a ser utilizado e de seus objetivos.
WAMPS 2011
85
Artigos técnicos selecionados
Alguns pontos chave desta estratégia são:
• Definição do processo: um conjunto de processos padrão para a organização é definido de
acordo com o modelo de maturidade a ser adotado, e elementos deste conjunto serão usados
em todos os projetos de software da unidade organizacional;
• Treinamento: os membros da organização são treinados nas práticas que deverão ser utilizadas
durante a execução dos processos e nas ferramentas que serão utilizadas neste contexto;
• Mentoring durante execução dos processos: os consultores da II COPPE/UFRJ acompanham
cada profissional envolvido na melhoria enquanto este realiza alguma atividade do processo;
• Aquisição de conhecimento: envolve a aquisição de conhecimento relacionado às atividades do
processo de forma a permitir que o conhecimento organizacional seja preservado e disseminado
na organização;
• Apoio ferramental: permite que as atividades sejam mais facilmente assimiladas e executadas.
Inicialmente, a estratégia recomendava o uso da Estação Taba; no entanto, com o decorrer do
tempo, a estratégia foi alterada para se adequar às ferramentas que a organização já estava
utilizando.
• Acompanhamento da implementação da melhoria de processos de software: ocorre
regularmente, por exemplo, uma vez por semana, e envolve a discussão com os membros da
organização responsáveis pelos detalhes da iniciativa de melhoria sobre diretivas importantes
para manter a execução dos processos conforme o planejado. Durante estas reuniões,
estratégias de melhoria de processos são definidas para superar dificuldades que podem afetar
o seu sucesso, como, por exemplo, a resistência a mudanças por parte dos participantes.
3. Visão Geral das Organizações
Durante o período de 2009/2010, a II COPPE/UFRJ apoiou a implementação de melhoria em 4
organizações que participaram do grupo de empresas formado no Rio de Janeiro. Em todas estas
organizações, a estratégia de implementação utilizada foi a mesma, respeitando-se porém, as
características, experiência e maturidade de cada uma.
A Organização #1 é dedicada ao desenvolvimento de sistemas e soluções de negócio baseadas
nos princípios e padrões da engenharia de software. Apesar de ser sua primeira experiência na
implantação de processos do MR-MPS, a organização já possuía a cultura de utilização de processos
de desenvolvimento desde a sua criação. Inicialmente, a organização almejava atingir o nível G do
MR-MPS; no entanto, após o primeiro diagnóstico dos consultores, percebeu-se a oportunidade
de implantar o nível F, visto o histórico positivo da organização com respeito aos processos. Uma
característica marcante desta organização era o tamanho reduzido da equipe envolvida nos projetos:
quando foi avaliada, a organização possuía 7 colaboradores. Desta forma, desde o diretor da empresa
até o desenvolvedor, todos estiveram atuando em, no mínimo, dois papéis dentro do processo.
Observou-se também o constante envolvimento e comprometimento da alta direção com a iniciativa
de melhoria.
86
WAMPS 2011
Lições Aprendidas em Implementações de Melhoria de Processos em Organizações com Diferentes Características
A Organização #2 é especializada em consultoria, desenvolvimento de sistemas, infraestrutura,
conectividade e segurança digital. Esta organização já havia participado de uma iniciativa de melhoria
também com o apoio da II COPPE/UFRJ, conquistando o nível G do MR-MPS, no início de 2009.
No final do mesmo ano, iniciaram-se os esforços junto à consultoria para alcançar o nível E. Os
membros da organização envolvidos não podiam dedicar-se integralmente à implementação, devido
ao atendimento externo prestado aos clientes, muitas vezes sendo alocados nas instalações do cliente
durante dias. Além disto, a alta direção levava a empresa a priorizar o atendimento ao cliente em
detrimento da iniciativa de melhoria, o que se tornou um fator complicador.
A Organização #3 desenvolve soluções de Tecnologia da Informação com foco em gestão empresarial.
Apesar de ser a primeira experiência da organização em implementar processos de software, foi
almejado o nível F do MR-MPS devido ao conhecimento de alguns colaboradores em gerência
de projetos, alguns com certificação PMP. Esta organização possui médio porte (com cerca de 90
colaboradores), inicialmente dividida em setores dedicados a diferentes focos de desenvolvimento.
Durante a implementação dos processos, a organização sofreu mudanças na estrutura organizacional,
realocando setores e redefinindo papéis e responsabilidades. Devido a estas mudanças, inicialmente,
a iniciativa de melhoria não estava sendo priorizada; no entanto, depois das mudanças ocorridas, um
representante da alta direção se comprometeu mais com a iniciativa de melhoria e houve um avanço
significativo na implantação dos processos.
A Organização #4 é especializada no desenvolvimento de soluções e projetos de Tecnologia da
Informação que atua em quatro linhas de serviços: sistemas sob medida, infraestrutura, business
intelligence (BI) e alocação de pessoal. Em 2009, quando começou a iniciativa de melhoria de
processos, a empresa já utilizava algumas práticas ágeis da metodologia Scrum [ScrumAlliance 2011]
na execução de seus projetos, e havia a preocupação em manter estas práticas ágeis alinhadas ao
nível F do MR-MPS. A equipe interna, além de ser relativamente pequena, precisava ficar alocada no
cliente com certa frequência, para atender às demandas deste. A alta direção participou ativamente
da iniciativa de melhoria, incentivando e fornecendo os meios necessários para sua realização.
A Tabela 1 apresenta um resumo das características das organizações apresentadas, bem como o
tempo total da implementação de melhoria.
4. Adaptações na Estratégia de Implantação
Conforme apresentado na seção anterior, cada organização possui características peculiares e,
portanto, uma mesma estratégia não poderia ser implantada da mesma forma em todas elas.
Desta forma, a equipe da II COPPE/UFRJ alocada em cada organização adaptou a estratégia SPIKM conforme necessário. Além disto, a forma de intervenção da equipe de consultores também
diferenciou em cada organização, segundo suas necessidades. A seguir, cada implementação será
brevemente apresentada, focando nas principais adaptações realizadas e nos desafios identificados.
WAMPS 2011
87
Artigos técnicos selecionados
Tabela 1. Caracterização das Organizações.
Organização
#1
Organização
#2
Organização
#3
Organização
#4
F
E
F
F
RUP
MR-MPS
Nível G
Nenhuma
Nenhuma
RUP + técnicas
ágeis
Iterativo
Cascata
SCRUM
7
24
96
16
Pessoas internas alocadas integralmente à melhoria
Sim (1)
Não
Sim (1)
Não
Tempo total do início da implementação até avaliação final
10 meses
13 meses
21 meses
18 meses
Nível MR-MPS pretendido
Experiência anterior em processos
Característica do desenvolvimento
Colaboradores envolvidos
4.1. Organização #1
Na Organização #1 havia uma pessoa experiente em processos alocada para a implementação do
nível F. Como a empresa já possuía um processo de desenvolvimento definido, o primeiro passo foi a
revisão deste processo e a verificação do que precisaria ser modificado ou acrescentado para cumprir
com os requisitos do nível F. Nesta etapa, a consultoria teve um papel importante relacionado à
apresentação dos novos conceitos até então desconhecidos pela organização.
No entanto, como a pessoa interna responsável pela implementação já possuía bom conhecimento
de Engenharia de Software e experiência na definição dos processos, a intervenção da consultoria
foi diminuindo com o passar do tempo. Em um dado momento, a consultoria ficou responsável por
revisar alguns artefatos e tirar dúvidas pontuais.
Apesar do número reduzido de colaboradores internos e da possibilidade de alocar consultores
especializados em alguns papéis, a Organização #1 optou por desempenhar todos os papéis
solicitados no nível F, afim de que o conhecimento ficasse internalizado na organização.
Devido ao conhecimento do responsável pela definição de processos em outras ferramentas e ao
desejo da organização em adotar práticas ágeis durante o processo de desenvolvimento, optou-se por
adotar outras ferramentas mais adequadas a estas necessidades. Neste sentido, foram utilizadas as
ferramentas EPF Composer (para a definição e divulgação de processos), JIRA (para o gerenciamento
de tarefas e comunicação entre a equipe) e SVN (para o controle de versões dos documentos e código
gerado).
4.2. Organização #2
Como a Organização #2 já possuía um processo que atendia ao nível G do MR-MPS, a equipe de
consultoria da II COPPE/UFRJ, juntamente com o grupo de processos da organização, revisou este
processo e o adaptou para atender ao nível E.
88
WAMPS 2011
Lições Aprendidas em Implementações de Melhoria de Processos em Organizações com Diferentes Características
As pessoas que executavam papéis-chave na execução dos processos estavam bastante
sobrecarregadas, com pouco tempo para assimilar as atividades dos processos, o que fazia com que
não fossem executados da maneira mais adequada. Para tratar este problema, a II determinou que
a organização teria pelo menos um consultor dentro da organização, de segunda-feira a sexta-feira,
em horário pré-determinado.
Além disto, por este mesmo motivo, inicialmente, algumas atividades como auditorias de Gerência de
Configuração e de Garantia da Qualidade eram realizadas por consultores da II. Posteriormente, estes
consultores ministraram treinamento aos membros da empresa para que estes assumissem a tarefa.
Em relação aos treinamentos, foi definida uma agenda de cursos a serem oferecidos pela II a todos
os membros da organização, envolvidos ou não nos processos, objetivando apresentar conceitos de
Engenharia de Software por meio do detalhamento de cada processo do nível E. Testes aplicados
antes e após o treinamento (pré-testes e pós-testes) revelaram que houve aquisição de conhecimento
por parte dos participantes. Outra estratégia para aquisição de conhecimento foi a realização de
mentoring, principalmente, para os processos Garantia da Qualidade, Gerência de Conhecimento
e Medição. O resultado destas ações foi observado nas avaliações de aderência aos processos, que
demonstrou uma melhoria considerável na execução dos processos.
Inicialmente, houve um pouco de resistência por parte da alta direção em alinhar os objetivos
estratégicos com a definição do processo de Gerência de Portfólio de Projetos. No entanto, ao longo
da implementação, os resultados desta gerência foram compreendidos pela alta direção, que passou
a acompanhar e monitorar de perto a medida definida para este processo.
Esta organização optou por um por um conjunto de ferramentas escolhidas pelo grupo de processos:
EPF Composer (definição de processos), Redmine (comunicação e controle de alterações), Project
Builder (planejamento e gerência de projetos) e SVN (controle de versões). A equipe de consultoria
precisou se familiarizar com as ferramentas para conseguir apoiar a organização em suas atividades,
visto que os executores dos processos também não tinham experiência com elas.
4.3. Organização #3
A Organização #3 passou por várias mudanças em sua estrutura organizacional, sendo que as mais
críticas foram as mudanças de patrocinador do projeto de melhoria, o que implicou adaptações na
estratégia de implementação.
No início, a Organização #3 estava ansiosa para dar início ao projeto de melhoria. Então, em comum
acordo com a II COPPE, as atividades de implementação foram iniciadas antes da oficialização do
início das atividades do grupo de empresas. Na época, a organização possuía uma estrutura de
desenvolvimento descentralizada, e havia projetos em execução em outros estados do país.
No primeiro momento, a estratégia SPI-KM foi aplicada sem muitas adaptações. O treinamento para
a equipe envolvida foi provido; o ambiente para a execução do processo definido foi configurado
na Estação Taba; e o acompanhamento estava sendo realizado sistematicamente conforme o
planejamento do projeto de melhoria.
As primeiras dificuldades surgiram quando a iniciativa precisou do apoio da alta gerência para garantir
a aderência dos projetos ao processo definido e tratar da rotatividade dos responsáveis pela execução
WAMPS 2011
89
Artigos técnicos selecionados
dos processos. Neste momento, soube-se que o patrocinador do projeto estava prestes a deixar a
organização. Na ocasião, a responsabilidade de conduzir o processo de melhoria foi atribuída a uma
pessoa com nível de gerência e com atuação local (anteriormente este papel era exercido por um
integrante da diretoria).
Para facilitar a institucionalização do processo, optou-se por incorporar o apoio à execução das
atividades do processo às ferramentas já existentes na organização (uma para gerenciamento
das solicitações e outra para controle das atividades de desenvolvimento, ambas desenvolvidas
internamente). Diante da decisão, a consultoria analisou as ferramentas para orientar na realização
das mudanças requeridas para atender o processo definido. O desafio foi sugerir mudanças que
demandassem o menor esforço para alteração e que tivessem baixo impacto na forma como as
pessoas interagiam. Assim, a estratégia foi adaptada para que o processo definido fosse introduzido
gradualmente ao ambiente de operação da organização.
Neste segundo momento, outras dificuldades ocorreram, dentre elas: a limitação de recursos
humanos para alteração das ferramentas; e a baixa influência do patrocinador para garantir que
todos os envolvidos colaborassem com a execução do processo. Para tratar a primeira questão,
grande parte das alterações nas ferramentas foi realizada pelo próprio patrocinador em conjunto
com um desenvolvedor. Com relação à segunda questão, foram feitas tentativas de sensibilizar os
demais gerentes, porém a competitividade entre eles impossibilitou a solução.
Diante do cenário, foi necessário atuar junto à alta direção para a solução do problema. Todos
os problemas e suas consequências foram relatados pela consultoria e um conjunto de ações foi
proposta. Diante do exposto, o vice-presidente assumiu a responsabilidade pela condução do projeto,
fez alterações na estrutura organizacional, redefiniu o escopo do projeto para a Fábrica de Software
(local e centralizada) e alocou novos recursos com poder para pôr em prática as ações necessárias.
A consultoria readaptou a estratégia, redefiniu o planejamento do projeto de melhoria e manteve a
constante comunicação com o novo patrocinador, que atuou fortemente até a avaliação final.
4.4. Organização #4
A Organização #4 já utilizava algumas práticas ágeis da metodologia Scrum [ScrumAlliance 2011]
na execução de seus projetos quando iniciou o programa de melhoria da implantação do nível F do
MR-MPS, e desejava implementar processos para organizar melhor o desenvolvimento de software,
permitindo um maior controle e alcançando uma melhor qualidade nos seus produtos, sem perder,
no entanto, a agilidade nos seus projetos.
Em paralelo à execução do projeto piloto da estratégia SPI-KM, a gerên­cia da Fábrica e todos os
coordenadores de projetos (que agem como gerentes dos projetos) fizeram o curso e se tornaram
Certified Scrum Masters, aumen­tando o conhecimento da empresa nesta metodologia ágil. As
oportunidades de melhoria identifica­das na execução do projeto piloto e a capacitação Certified
Scrum Masters gera­ram novas sugestões de alteração no processo padrão mais voltada para as
práticas do Scrum e mais adaptada à realidade da empresa.
Esta organização utilizou ferramentais de apoio mais voltadas para projetos ágeis, como o Redmine
[Redmine 2011], que apoiou atividades dos processos Gerência de Projetos, Gerência de Requisitos,
Garantia da Qualidade, Medição e Gerência de Configuração e por templates elaborados no Microsoft
Office, com o máximo de informações já preenchido.
90
WAMPS 2011
Lições Aprendidas em Implementações de Melhoria de Processos em Organizações com Diferentes Características
Assim como a Organização #2, a Organização #4 alocou consultores da II para executar atividades de
Gerência da Configuração e da Garantia da Qualidade, devido à falta de disponibilidade e o número
reduzido aos membros da organização. Inicialmente, estas atividades eram executadas remotamente
pelos consultores. No entanto, havia dificuldades na comunicação com os membros da organização,
tornando a execução do processo lenta. A solução para esta dificuldade foi alocar os consultores da
II internamente na organização, definindo um horário fixo para que executassem suas atividades.
O principal desafio relacionado à implantação das melhorias de processo necessárias para o alcance
do nível F na organização foi encontrar apoio ferramental ade­quado, que auxiliasse na execução
do processo de desenvolvimento mantendo a agilidade encontrada em metodologias ágeis como o
Scrum. A utilização do Redmine como principal ferramenta de gestão dos projetos (incluindo o projeto
no escopo organizacional), juntamente com a abordagem de mini­mizar a repetição de informações
comuns em cada projeto, permitiu que algumas ativi­dades fossem realizadas rapidamente ou de
forma automatizada.
Além disso, a alta direção e a gerência da Fábrica demonstraram comprometimento e apoio, o que
proporcionou uma discussão bastante proveitosa sobre os objetivos estratégicos que a empresa
almejava alcançar e facilitou a definição e implementação de Gerência de Portfólio de Projetos. A
cultura da empresa e o envolvimento da alta direção também impulsionou o acompanhamento das
medidas definidas para a organização e sua evolução.
5. Lições Aprendidas
As seguintes lições aprendidas foram coletadas durante a implementação neste grupo de empresas:
• Quando a equipe é sobrecarregada e não tem tempo para o entendimento do processo, é
importante que a consultoria dedique mais tempo in loco para acompanhamento da execução
do processo, atividade por atividade. Isto irá evitar que os executores dos processos deixem de
executar ou executem de forma inadequada atividades que não foram bem compreendidas.
• Cursos de introdução aos conceitos de Engenharia de Software que serão utilizados nos
processos podem auxiliar na compreensão das atividades do processo a serem executadas.
• Pré-testes e pós-testes ao longo do treinamento são elementos motivadores para a equipe da
empresa, pois os colaboradores percebem o aumento de conhecimento
• Em situações nas quais a alta direção inicialmente não mostra o envolvimento necessário para
o sucesso do programa de melhoria de processos, é muito importante que a coordenação da II
esteja próxima à alta direção trabalhando por seu envolvimento no processo.
• Ter um cronograma definido para a implementação de melhoria e trabalhar para mantê-lo é
importante, pois faz com que as equipes da II e da empresa trabalhem para alcançar o ritmo
desejado.
• A atuação proativa da II para mitigar a ocorrência dos riscos do projeto de melhoria pode
manter a organização mobilizada em prol do sucesso da iniciativa.
WAMPS 2011
91
Artigos técnicos selecionados
• Compreender as dificuldades da organização para empreender em melhoria e auxiliá-la no
tratamento das questões mais relevantes pode aumentar a credibilidade da II com a organização
e facilitar a continuidade dos trabalhos.
• É importante que a II mobilize a alta direção para discussão dos objetivos estratégicos da
organização e também na definição do processo de Gerência de Portfólio de Projetos.
• Um apoio ferramental adequado pode ser fundamental para a aderência ao processo definido
para os projetos.
• Quando as auditorias de Gerência de Configuração e de Garantia da Qualidade, anteriormente
executadas por um consultor externo, passam a ser realizadas pelos próprios membros da
empresa, estes passam a evitar a ocorrência de situações que, tipicamente, resultavam em não
conformidades. Isto faz com que menos erros ocorram, gerando aumento na qualidade.
• As auditorias de Gerência de Configuração e de Garantia da Qualidade, quando executados
por um consultor externo, devem ser realizadas nas dependências da organização, sempre
que possível, alocando horário fixo, a fim de agilizar a comunicação entre os consultores e os
membros da organização.
• A definição de processos não deve ser realizada durante a reestruturação interna da
organização, uma vez que esta reestruturação pode modificar os objetivos organizacionais e o
foco da iniciativa de melhoria, e o processo precisar ser alterado profundamente, o que poderia
desgastar a equipe responsável pela definição do processo.
• Logo após a definição de uma primeira versão do processo, é necessário executá-lo em, pelo
menos, um projeto para se verificar sua adequabilidade. Só a partir desta execução, melhorias
apropriadas são identificadas.
• A definição do processo não deveria ser realizada exclusivamente por uma pessoa ou grupo;
toda a equipe de desenvolvimento deve ser envolvida durante esta definição, atendendo sempre
que possível suas necessidades. Desta forma, o comprometimento de todos os envolvidos pode
ser obtido mais facilmente.
6. Considerações Finais
Este artigo discutiu a implementação do MR-MPS num grupo de empresas do Rio de Janeiro em 2010
pela II COPPE/UFRJ. Foram apresentadas as principais características destas empresas, incluindo seus
objetivos para o programa de melhoria de processos, caracterização e a estratégia de implementação
em cada uma das empresas. Além disso, foram apresentadas as lições aprendidas a partir da
experiência de implementação de melhoria de processos visando à obtenção dos níveis G, F e E do
MR-MPS. As quatro empresas atingiram o nível pretendido no final de 2010.
O trabalho de implementação de melhoria de processos de software e as ações para solidificar os
ganhos obtidos com a iniciativa conduzida não se limitam ao tempo necessário para a avaliação oficial
dos processos. É necessário apoiar continuamente os esforços realizados e adequar constantemente
os processos à realidade vigente da empresa, e também garantir o apoio constante não apenas da
92
WAMPS 2011
Lições Aprendidas em Implementações de Melhoria de Processos em Organizações com Diferentes Características
alta direção, mas de todos os colaboradores, para que os processos de software existentes continuem
sendo utilizados. Dessa forma, todas as empresas citadas continuam seus esforços para a manutenção
dos ganhos obtidos com a implantação dos processos.
As lições aprendidas relatadas neste trabalho são importantes para a retroalimentação e refinamento
da estratégia adotada pela COPPE/UFRJ. Também se espera que possam contribuir para as estratégias
de outras Instituições Implementadoras MPS ou de empresas que queiram realizar programas de
melhoria de processos de software.
Agradecimentos
Os autores agradecem a todos os colaboradores das empresas do grupo.
Referências
Barreto, A., Montoni, M., Santos, G., Rocha, A. R. (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.
Catunda, E., Nascimento, C., Cerdeiral, C., et al. (2010) “Implementando o nível F do MR-MPS com
práticas da metodologia ágil Scrum”. In: VI Workshop Anual do MPS, v. 1, pp. 78-87, Campinas
– Brasil.
Catunda, E., Nascimento, C., Cerdeiral, C., et al. (2011) “Implementação do Nível F do MR-MPS com
Práticas Ágeis do Scrum em uma Fábrica de Software”. In: X Simpósio Brasileiro de Qualidade de
Software (SBQS’11), Curitiba – Brasil.
Montoni, M. A. (2010) “Uma Investigação sobre os Fatores Críticos de Sucesso em Iniciativas de
Melhoria de Software de Processos”. Tese (Doutorado em Engenharia de Sistemas e Computação)
– Universidade Federal do Rio de Janeiro.
Redmine (2011). In: http://www.redmine.org/. Acessado em: agosto/2011.
Santos, G., Montoni, M., Figueiredo, S., Rocha, A. R. (2007) “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., Katsurayama A. E., et al. (2008) “Aplicação da Estratégia SPI-KM para
Apoiar a Implementação do MPS.BR Níveis G e F em Pequenas e Médias Empresas do Rio de
Janeiro”. In: VII Simpósio Brasileiro de Qualidade de Software (SBQS’08), Florianópolis – Brasil.
SEI, 2010, CMMI® for Development (CMMI-DEV), V1.3, Software Engineering Institute. Disponível
em: http://www.sei.cmu.edu/. Acessado em: agosto/2011.
ScrumAlliance (2011). In: http://www.scrumalliance.org/. Acessado em: agosto/2011.
Softex (2011) “MPS.BR – Melhoria de Processo do Software Brasileiro, Guia Geral”. Disponível em
http://www.softex.br/mpsbr. Acessado em: agosto/2011.
WAMPS 2011
93
Artigos técnicos selecionados
MPS.BR Nível D – A Experiência em Implantar o
Modelo na Área de Governo Municipal
Márcio Fernando Corrêa Ricardo, Andreiwid Sheffer Corrêa
IMA – Informática de Municípios Associados S/A
Rua Ataliba de Camargo de Andrade, 45 – CEP 13.025-290 Campinas – São Paulo – Brasil
[email protected], [email protected]
Abstract. This paper describes the experience of IMA – Informática de Municípios Associados S/A, a public
information technology company, with over 35 years of existence, as being a local authority linked to the
municipality of Campinas, who in December 2007 was positively assessed at Level F and in May 2011 at Level D,
becoming today the only public company to hold this level of maturity.
Resumo. Este artigo descreve a experiência da IMA – Informática de Municípios Associados S/A, empresa
pública municipal de Tecnologia da Informação, com mais de 35 anos de existência, como autarquia municipal
ligada à Prefeitura Municipal de Campinas, que em dezembro de 2007 conquistou a avaliação positiva no
Nível F e em maio de 2011 a avaliação positiva no Nível D, tornando-se hoje a única empresa pública a deter
esse nível de maturidade.
1. Introdução
Esse artigo tem por objetivo apresentar a experiência da IMA na implantação do modelo MPS/BR
Nível D, conforme descrito em MPS/BR1 (2009) e MPS/BR2 (2009), além de mostrar as vantagens
competitivas que uma empresa pública desse porte pode obter com esse nível de maturidade. Nos
itens a seguir vamos destacar a importância da implementação e uso do processo com um forte
apoio do patrocinador e gestor principal da empresa e também sobre a boa aceitação pelas equipes
de desenvolvimento de sistemas.
Em setembro de 2005 a IMA integrou o Grupo 3 de empresas que foram reunidas e incentivadas
pelo núcleo SOFTEX Campinas. Com o financiamento do programa feito pelo BNDES, a capacitação
dessas empresas de TI no modelo MPS/BR possibilitou a realização da definição de seus processos de
desenvolvimento de sistemas e respectivas avaliações oficiais.
Esse grupo era formado por cinco empresas, sendo que duas estavam se preparando para o Nível
G (MPS/BR4, 2009) e três para o Nível F (MPS/BR3, 2009). À época, devido ao seu porte, a IMA
ficou fora do programa de financiamento, logo no momento da avaliação oficial. Isso teve seu lado
positivo, pois a IMA desvinculou-se das datas previstas no cronograma oficial do programa e assim
teve a oportunidade de preparar melhor seu processo para a avaliação oficial.
A primeira avaliação oficial ocorreu em dezembro de 2007, sendo considerada positiva para o Nível
F. Impulsionada pelo sucesso obtido, a direção da empresa imediatamente solicitou a continuidade
dos trabalhos e em janeiro de 2008 iniciou-se o planejamento dos processos para a avaliação oficial
no Nível D, que ocorreu positivamente em maio de 2011.
94
WAMPS 2011
MPS.BR Nível D – A Experiência em Implantar o Modelo na Área de Governo Municipal
2. Maturidade da equipe
No que diz respeito aos processos de melhoria e qualidade de desenvolvimento de software a
experiência da equipe na época era mínima. Estava implantado na empresa, desde o período áureo
dos mainframes, uma metodologia de desenvolvimento de software criada internamente, com
apoio de um consultor externo. À medida que o mainframe era substituído pelos micros e médios
computadores, essa metodologia ficava ultrapassada. Cabe ressaltar que para algumas empresas
públicas, o uso de mainframes hoje, ainda é uma realidade.
Havia necessidade de identificar uma solução urgente para definir e resolver a situação. As tecnologias
utilizadas naquele momento estavam crescendo e em constante mudança. O mercado mostravase indefinido com questões de tecnologia e linguagens de programação ainda em momento de
discussão. Alguma coisa precisava ser feita para melhorar o processo de desenvolvimento de sistemas
da empresa. Mas o que fazer sendo uma empresa pública, sem muitos recursos financeiros disponíveis
e sem fundamentos acadêmicos. Não existiam motivações comerciais, para sustentar possíveis ganhos
como um diferencial competitivo em vendas, uma vez que não existia a área comercial implantada na
empresa, para beneficiar-se dessa qualificação.
Era necessário montar uma estratégia de motivação para apresentar e convencer a alta direção da
empresa, bem como o maior e principal cliente que é o próprio governo municipal de Campinas,
em aceitar os novos processos de trabalho, e tudo isso a custo bem baixo. Como convencer esses
gestores sobre as necessidades, os benefícios, a importância e a urgência da empresa em implantar
um processo para desenvolvimento de projetos de sistemas e garantir bons resultados.
Então, começou-se falar em CMMI (CMMI, 2011). Esse modelo também não era de conhecimento
das equipes. Tratava-se de uma capacitação cara, com reconhecimento internacional, o que não se
aplicava para uma empresa municipal naquele momento. Como justificar esses altos custos junto à
gestão orçamentária. Dúvidas difíceis de resolver e justificar.
Em 2004, bem próximo a uma mudança do governo municipal, e empresa foi convidada pelo SOFTEX
a participar de um evento informativo e assim conheceu o modelo MPS/BR. A equipe ficou interessada
no modelo, mas a empresa não tinha como bancar os custos de capacitação e implementação.
Através de contatos mantido com o SOFTEX, e empresa foi informada sobre o formato de trabalho,
que descrevia a criação dos grupos e com apoio financeiro, para capacitação no modelo e como
resultado final, a implementação dos processos. Assim a IMA integrou-se ao Grupo 3, com o grande
apoio do seu novo e principal gestor, que em 2005 já estava a frente da empresa, devido à mudança
do governo municipal.
3. Abordagem de convencimento
Houve um longo trabalho de convencimento, com abordagens técnicas e comerciais, e ainda com a
possibilidade de executar o projeto com baixo custo de investimentos. Através disso, encontrou-se
o caminho para obter um parecer favorável dos gestores à permanência da empresa no grupo 3 e
autorização para iniciar o desenvolvimento dos processos, hoje conhecido internamente como PDSI
– Processo de Desenvolvimento de Software da IMA.
WAMPS 2011
95
Artigos técnicos selecionados
No início dos trabalhos muitas dúvidas surgiram. As equipes de projetos, competentes e preparadas,
estavam apreensivas e preocupadas com o que estaria por vir. O quanto um processo iria ajudar ou
atrapalhar os trabalhos de desenvolvimento de sistemas.
A equipe designada para a montagem dos processos também estava apreensiva. Foi criado um
grupo de trabalho com dois analistas e posteriormente mais um integrou-se a equipe, totalizando
três analistas. No início a dedicação dessa equipe estava apenas em 8 horas semanais, e mais um
treinamento mensal. Com o desenvolvimento dos trabalhos, as atividades tornaram-se intensas e houve
a necessidade desse grupo passar a se ocupar em tempo integral. Mais um problema para administrar
junto aos gestores da empresa, pois horas de trabalho das pessoas estavam sendo destinadas para um
projeto inovador, na época, dentro de uma empresa pública municipal do porte da IMA.
Em 2005, a empresa tinha pouco mais de 130 funcionários e hoje conta com mais de 530, sendo que
a equipe de desenvolvedores era composta por 18 analistas e hoje a equipe conta com 70. Como
gerenciar hoje uma equipe desse porte, sem um processo de trabalho definido, sem acompanhar
custos e prazos dos projetos, e sem métricas para planejar o futuro.
Pontos Importantes para a abordagem de convencimento dos gestores:
• Empresa buscando a ampliação de sua participação no mercado;
• Busca por um aumento de aporte financeiro através do desenvolvimento de projetos para
outros clientes, fora da administração municipal;
• Fortalecer a imagem da empresa diante da concorrência do mercado e diante de novos clientes;
• Fortalecer a imagem da empresa, com um diferencial de capacidade técnica;
• Vantagem do Programa Cooperativo do SOFTEX, para a implementação do modelo a baixo
custo;
• Melhorar o atendimento aos clientes atuais, dentro da própria administração municipal,
buscando mais assertividade de prazos e custos;
• Melhorar a satisfação dos profissionais da empresa que atuam nas equipes de desenvolvimento
de sistemas, propiciando a eles técnicas e métodos atuais para desenvolvimento de sistemas;
4. Evolução dos processos
Logo após a implantação do Nível F, quando as equipes ainda estavam adaptando-se a nova maneira
de trabalhar e produzir sistemas, quando também comemorava-se a conquista, incentivada pelos
benefícios obtidos, apontou-se a possibilidade de avanço do nível. Nesse momento a empresa não
sabia qual escolher: Nível D ou C (MPS/BR5, 2009).
Então saiu em busca de novos conhecimentos e era grande a vontade de chegar até o Nível C. Porém,
a realidade da empresa, no âmbito público municipal, fez analisar melhor os cenários disponíveis.
O Nível C pareceu muito além de capacidade e necessidade dos projetos desenvolvidos. As equipes
estavam com bastante dificuldade para entender e alcançar os conceitos dos níveis superiores.
96
WAMPS 2011
MPS.BR Nível D – A Experiência em Implantar o Modelo na Área de Governo Municipal
O Nível D estava mais coerente com os propósitos técnicos e comerciais, e então os planos foram
novamente ajustados agora para o Nível D.
Baseado na experiência do Nível F, a equipe conhecedora e já experiente no uso de processos,
não apresentou dificuldades em seguir os novos processos, uma vez que alguns processos sofreram
apenas evolução e melhorias em relação aos anteriores do Nível F. Porém, as mudanças ocorridas
nos processos em função da alteração para o Nível D foram muitas. O processo de Gerência de
Projetos, Gerência de Requisitos e Gerência de Configuração foram os que mais sofreram alterações
e apresentaram um grau de dificuldade maior de entendimento das equipes.
Através de treinamentos cíclicos com as equipes após a cada etapa de processo definida e a adoção
de técnicas de acompanhamento assistido (mentoring) para alguns projetos, foi a solução encontrada
para contornar essas dificuldades. A cada nova versão do processo publicada, mais um treinamento
era realizado. Houve momentos em que alguns treinamentos precisaram ser refeitos para um melhor
entendimento.
Em paralelo a definição dos novos processos, foi desenvolvida internamente uma ferramenta baseada
em software livre, denominada GIPS (Gestão Integrado de Projetos de Software), que ajuda a gerenciar
e registrar tudo que acontece nas várias etapas de desenvolvimento, sincronizando cronogramas,
apontamento de horas, requisitos funcionais, cálculo das estimativas e apontando os desvios de
projetos.
Hoje não existe a intenção de avançar mais níveis, uma vez que os gestores atuais, de comum acordo
com a equipe técnica e comercial, entendem que o Nível D obtido está adequado aos padrões de
trabalho e dos projetos que são solicitados pela administração municipal e demais clientes externos.
Naturalmente que a equipe técnica gostaria de crescer, mas entendeu-se ser possível crescer
aperfeiçoando-se no Nível D, ganhando maturidade nas disciplinas técnicas e produzindo constantes
melhorias de nos processos em uso.
Atualmente está em andamento um novo projeto que visa resolver e atender todas as Solicitações
de Mudança (SMs) até então registradas ao Grupo de Melhoria de Processos de Software (GMP-SW),
bem como as melhorias sugeridas pela equipe de avaliadores oficiais. Um projeto paralelo, também
em andamento, foi criado para evoluir a ferramenta GIPS, tornando-a única e totalmente integrada
à ferramenta de gestão dos projetos de software da empresa.
5. Resultados alcançados
Muitos resultados e benefícios foram alcançados pela implantação do modelo MPS/BR na empresa,
mas nem todos são citados nesse trabalho, porém destacou-se os mais importantes, no sentido de
orientar possíveis empresas públicas que desejam obter algum nível de maturidade:
• Satisfação dos profissionais da empresa, por terem suas funções claramente definidas através
do processo.
• Agilidade dos líderes de projeto, tendo uma maior visibilidade quanto ao progresso dos
projetos.
WAMPS 2011
97
Artigos técnicos selecionados
• Definição das estimativas de projetos mais claras e assertivas, orientando a área relacionamento
da empresa na montagem das propostas comerciais.
• Maior comprometimento do cliente que acompanha o andamento do projeto através das
validações periódicas que ocorrem durante todo o projeto.
• Garantir para o cliente segurança quanto a prazos de entrega e custos envolvidos no projeto.
• Possibilidade de consultar histórico de projetos anteriores, dando maior segurança às equipes
nas estimativas e execução das atividades de projeto.
• A satisfação das áreas não avaliadas da empresa, gerada em conseqüência ao reconhecimento
de suas participações para o sucesso do Nível D. Esta satisfação motivou estas áreas a intensificar
seus esforços na definição e melhoria de seus processos.
• Melhoria dos processos atendendo às Solicitações de Mudanças (SMs) dos projetos.
• Melhoria dos guias do processo, identificando técnicas para ganhar maior celeridade nos
trabalhos do dia-a-dia.
• Calibração das estimativas, garantindo maior assertividade, uma vez que utilizamos métodos
próprios para estimar projetos.
6. Gráficos e indicadores
Os Gráficos 1, 2 e 3 mostrados abaixo representam o grau de maturidade da equipe desde as primeiras
coletas após a avaliação do Nível F e que vem se mantendo até hoje. O percentual de aderência da equipe
ao uso do processo estabelecido pela empresa é de fundamental importância para a manutenção,
estabilidade e continuidade dos processos dentro da área de desenvolvimento de sistemas.
Esse nível de conformidade é obtido através de auditorias feitas pela área da garantia da qualidade, que
analisa uma grande quantidade de itens ao longo das várias etapas do processo de desenvolvimento.
Os gráficos representam a totalidade dos itens do projeto, uma vez que cada fase tem a sua avaliação
distinta.
Gráfico 1. Nível de conformidade do ano de 2009.
98
WAMPS 2011
MPS.BR Nível D – A Experiência em Implantar o Modelo na Área de Governo Municipal
Gráfico 2. Nível de conformidade do ano de 2010.
Gráfico 3. Nível de conformidade do ano de 2011.
As tabelas de detalhamento dos Gráficos 1, 2 e 3 contêm a coluna Itens Avaliados, que refere-se à
quantidade de itens avaliados no mês; a coluna NC, que refere-se à quantidade não conformidades
encontradas; a coluna Aderência, que refere-se ao percentual de Não Conformidades (NCs) em
relação aos Itens Avaliados.
As Tabelas 1 e 2 abaixo demonstram a análise de 16 projetos que tiveram início a partir de setembro
de 2010. Os projetos estão agrupados por faixa de tamanho, expressa em unidades de medida IMA. A
primeira linha das tabelas trata-se dos projetos de pequeno porte (0 a 50 unidades), que representam
33% do total de projetos desenvolvidos. A segunda linha os projetos de médio porte (51 a 100
unidades), que representam 50% do total de projetos desenvolvidos. A terceira linha os projetos de
grande porte (acima de 101 unidades), que representam 17% do total de projetos desenvolvidos.
WAMPS 2011
99
Artigos técnicos selecionados
Tabela 1. Variação das estimativas de projetos – ano 2011.
Média Esforço Média Prazo Média Meses
Metas
Objetivo
Faltam
Redução
822,15
63,81
2,1
30%
575,51
127,15
17,22%
1699,46
135,36
4,5
20%
1359,57
399,46
-4,46%
2597,22
229,84
7,7
10%
2337,50
297,22
-1,43%
Tabela 2. Variação das estimativas de projetos – ano 2010.
Média Esforço Média Prazo Média Meses
Metas
Objetivo
Alvo
993,14
87,41
2,9
30%
695,20
695
1626,90
130,35
4,3
20%
1301,52
1300
2560,62
228,44
7,6
10%
2304,56
2300
Nas Tabelas 1 e 2 as colunas Média Esforço, Média Prazo, Objetivo e Alvo referem-se ao tamanho
do projeto IMA, unidade de estimativas própria da empresa. A coluna Média Meses refere-se à
quantidade de meses estimados para o projeto. A coluna Metas trata do percentual de redução
esperado com a execução das ações de melhorias em andamento.
Nota-se, na primeira linha da Tabela 1, que os projetos de pequeno porte desenvolvidos na IMA
sofreram uma redução de 17% nos esforços estimados entre o ano de 2010 e 2011. Essa informação
é de extrema importância para a empresa, pois mostra que a redução dos prazos dos projetos é um
dos ganhos obtidos com a implantação do MPS/BR Nível D, colaborando assim para um ganho de
produtividade e, do ponto de vista do cliente, um resultado mais rápido envolvendo qualidade e
garantias. À medida que o processo se estabiliza, a equipe obtém mais segurança nos trabalhos e
consegue melhorar as estimativas dos projetos.
Por outro lado, curioso avaliar que os projetos de médio e grande porte tiveram um leve aumento nos
esforços, o que não configura uma tendência, uma vez que estamos iniciando o projeto de melhorias
dos processos e as medidas estão sendo tomadas através das metas de redução.
Podemos notar, ainda, um aumento significativo de itens avaliados entre os anos de 2009 (5386
itens) e 2010 (7178 itens), sem perda na aderência ao modelo, mostrando uma equipe adepta ao uso
dos processos. Ao que tudo indica, o ano de 2011 não será diferente, pois nos primeiros sete meses
já estamos com 6169 itens avaliados.
7. Recomendações para atingir ao MPS/BR Nível D
Com base na experiência da IMA, adquirida ao longo dos mais de cinco anos de trabalho, são
recomendadas algumas ações para facilitar a conquista de uma avaliação positiva do MPS.BR nível D:
• É necessário ter forte apoio da alta direção da empresa;
• O processo de Medição e Análise deve ser bem implementado desde os níveis iniciais do MPS/
BR (no caso da IMA – Nível F);
100 WAMPS 2011
MPS.BR Nível D – A Experiência em Implantar o Modelo na Área de Governo Municipal
• Os objetivos estratégicos, táticos e operacionais devem estar bem definidos, disseminados e
alinhados entre os gestores da empresa e suas equipes de projeto de software;
• Os indicadores e as medições devem estar vinculados aos objetivos estratégicos, táticos e
operacionais definidos pela empresa por sua alta administração;
• O conhecimento elementar de estatística é fundamental para estruturação das análises das
medidas coletadas;
• Apoio de profissionais com experiência em alta maturidade e conhecimento do modelo;
• Equipe interna comprometida com o programa de melhoria de processos;
• Treinamento e consultoria focados em alta maturidade e melhoria de processos;
• Estimular os gestores da organização a desenvolver o hábito de analisar as medidas coletadas.
8. Principais benefícios
Os principais benefícios obtidos com o MPS/BR Nível D foram:
• Aumento da produtividade na execução dos projetos de desenvolvimento de sistemas, não
computados numericamente, pois antes da implantação dos processos não tínhamos nenhum
tipo de medida coletada a não ser apontamento de horas, porém esse aumento sentido e
citado em reuniões de acompanhamento;
• Redução do custo de desenvolvimento através de constante verificação dos processos e
buscando sempre melhorar e otimizar as etapas;
• Através do aprimoramento das atividades de desenvolvimento de sistemas, ficou registrado
em lições aprendidas, as reduções de retrabalho que passaram a ocorrer ao longo do ciclo de
desenvolvimento do projeto;
• Padronização declarada e conhecida por toda a equipe dos processos de trabalho;
• Através do treinamento nos processos, cada novo profissional que é admitido na empresa
rapidamente passa conhecer o processo de trabalho que estará envolvido;
• Aumento da satisfação dos clientes através do cumprimento dos prazos e custos estabelecidos,
registrados em pesquisas de satisfação e e-mails espontâneos enviados para a empresa, bem
como em reuniões de término dos projetos;
• Maior agilidade, controle e capacidade de gerenciamento de projetos;
• Rapidez na identificação de problemas e suas causas reais, bem como as soluções, registrando
e discutindo-as nas lições aprendidas;
• Aumento da qualidade dos projetos entregues, atribuídos através da redução de defeitos (em
torno de 42%, conforme registro das coletas);
WAMPS 2011 101
Artigos técnicos selecionados
• Melhoria contínua dos processos de trabalho, através das análises críticas e grupos de discussões
com propostas de melhorias e solicitações de mudanças;
• Maior competitividade, produzindo um melhor e mais rápido resultado do trabalho a custos e
prazos controlados, e com documentação ampla dos projetos.
9. Principais resultados
Os principais resultados obtidos com a implementação do modelo MPS/BR Nível D:
• Redução de 17% nas estimativas de esforço dos projetos (até o momento);
• Assertividade nas estimativas de prazos e custos próximos a 100%;
• Índice de satisfação dos clientes próximo à 100%.
10. Conclusão
O processo de desenvolvimento de software baseado no modelo MPS/BR Nível D, adotado pela IMA,
fez com que o desempenho da empresa melhorasse como um todo, tornando-a uma empresa mais
produtiva e com mais qualidade em seus produtos de software.
A implantação de projetos utilizando o modelo MPS/BR mudou significativamente a maneira da
organização compreender os seus projetos de software. Além disso, fez com que as decisões tomadas
pela alta e média gestão da empresa pudessem ser alicerçadas em fatos reais e demonstradas pelos
dados obtidos através das medidas coletadas ao longo da execução dos projetos.
A formação de uma base histórica de conhecimento sobre os projetos já desenvolvidos e implantados
é fonte segura de informação a ser utilizada nas estimativas de futuros projetos, melhorando
significativamente a assertividade da empresa na contratação e execução dos projetos de seus clientes.
A evolução dos processos ocorreu de forma gradual e constante. Nas várias fases de conhecimento
e aperfeiçoamento pelo qual as equipes de projetos passaram, garantiram a solidez dos processos
implantados, bem como facilitou a sua utilização.
Interessante citar que as demais áreas da empresa tiveram um olhar diferenciado para processos de
trabalho, antes esquecidos, questionados e tidos como desnecessários, passando à compreende-los
melhor, entender a necessidade de ter processos e querer obter seus próprios processos.
O retorno sobre o investimento não foi tão rápido e somente parte materializou-se de forma
financeira. Hoje, após cinco anos do início dos trabalhos, os resultados ainda podem ser notados.
No entender da empresa, as características da IMA como empresa pública municipal contribuem a
transformação paulatina dos resultados em retorno financeiro. No entanto, podemos afirmar que o
investimento em melhoria de processos de software, resultado da implementação do modelo MPS/
BR Nível F e Nível D, valem muito a pena.
102 WAMPS 2011
MPS.BR Nível D – A Experiência em Implantar o Modelo na Área de Governo Municipal
Referências
MPS/BR1 – ASSOCIAÇÃO PARA PROMOÇÃO DA EXCELÊNCIA DO SOFTWARE BRASILEIRO – SOFTEX.
MPS/BR (2009) “Melhoria do Processo de Software Brasileiro – Guia Geral” (Maio de 2009).
<http://www.softex.br/mpsbr/_guias/default.asp>.
MPS/BR2 – ASSOCIAÇÃO PARA PROMOÇÃO DA EXCELÊNCIA DO SOFTWARE BRASILEIRO – SOFTEX.
MPS/BR (2009) “Melhoria do Processo de Software Brasileiro – Parte 4 – Implementação do Nível
D do MR-MPS” (maio de 2009, atualizado em agosto de 2009). <http://www.softex.br/mpsbr/_
guias/default.asp>.
MPS/BR3 – ASSOCIAÇÃO PARA PROMOÇÃO DA EXCELÊNCIA DO SOFTWARE BRASILEIRO – SOFTEX.
MPS/BR (2009) “Melhoria do Processo de Software Brasileiro – Parte 1 – Implementação do Nível
F do MR-MPS” (maio de 2009, atualizado em agosto de 2009). <http://www.softex.br/mpsbr/_
guias/default.asp>.
MPS/BR4 – ASSOCIAÇÃO PARA PROMOÇÃO DA EXCELÊNCIA DO SOFTWARE BRASILEIRO – SOFTEX.
MPS/BR (2009) “Melhoria do Processo de Software Brasileiro – Parte 2 – Implementação do Nível
G do MR-MPS” (maio de l2009, atualizado em setembro de 2009). l<http://www.softex.br/
mpsbr/_guias/default.asp>.
MPS/BR5 – ASSOCIAÇÃO PARA PROMOÇÃO DA EXCELÊNCIA DO SOFTWARE BRASILEIRO – SOFTEX.
MPS/BR (2009) “Melhoria do Processo de Software Brasileiro – Parte 5 – Implementação do Nível
C do MR-MPS” (maio de 2009). <http://www.softex.br/mpsbr/_guias/default.asp>.
CMMI – Site da SEI – SOFTWARE ENGINEERING INSTITUTE, CARNEGIE MELLON UNIVERSITY (2011)
“CMMI – Capability Maturity Model Integration” (2011). < http://www.sei.cmu.edu/cmmi/>.
WAMPS 2011 103
Artigos técnicos selecionados
Relato da Experiência do Processo de
Institucionalização do Modelo CMMI na
Dataprev
Rosana Fernandes Osório, Guilherme Tavares Motta
Coordenação Geral de Qualidade de Software – DATAPREV – RJ – Brasil
[email protected], [email protected]
Abstract. This paper describes an overview of the “Processo de Institucionalização do Modelo CMMI na
DATAPREV”, which is proposed to add value to the company’s core business, with the implementation of
reference models focused on quality, productivity and maturity in software development.
Resumo. O presente artigo descreve uma síntese do “Processo de Institucionalização do Modelo CMMI na
DATAPREV”, que tem como proposta agregar valor à atividade fim da empresa, com a implementação de
modelos de referência com foco em qualidade, produtividade e maturidade no desenvolvimento de software.
1. Introdução
Na busca pela inovação e boas práticas da engenharia de software, deu-se início ao Projeto CMMIDTP: Institucionalização do Modelo CMMI na DATAPREV. Este projeto teve por foco investir na análise
e avaliação do processo de software em uso na empresa, como forma de identificar os pontos fortes,
fracos e as melhorias requeridas, para tornar o processo de software da DATAPREV aderente aos
objetivos e práticas estabelecidas pelo nível 3 do modelo CMMI DEV 1.2.
Como a obtenção da aderência exigida para o nível 3 do modelo CMMI DEV 1.2 requer que o
processo de software atenda as 18 (dezoito) áreas de processo, nisso envolvendo mais de 300
(trezentas) práticas entre genéricas e específicas, foi requerido da equipe do Projeto CMMI-DTP alto
grau de conhecimento e comprometimento. Cabe destacar que o cenário encontrado pelo projeto
se caracterizava pelo baixo nível de utilização da metodologia de desenvolvimento de sistemas
disponível, na época, na DATAPREV.
O atendimento à necessidade de definição do processo de desenvolvimento e manutenção de
software da DATAPREV (PD-DATAPREV) foi resolvido a partir da integração das disciplinas preconizadas
pela Engenharia de Software e do desenvolvimento do portal PD-DATAPREV. Esse portal dispõe de
interface amigável de modo a facilitar o acesso às informações do processo (ativos de processo).
Dessa forma, o desafio colocado foi plenamente atendido pelo Projeto CMMI-DTP.
104 WAMPS 2011
Relato da Experiência do Processo de Institucionalização do Modelo CMMI na Dataprev
2. Objetivos e Justificativas
O Projeto CMMI-DTP teve como objetivos principais: “Implementar as práticas do modelo CMMI –
DEV 1.2, níveis 2 e 3, na DATAPREV; “Institucionalizar o uso dos processos definidos no PD-DATAPREV;
e Internalizar o conhecimento de implementação do modelo CMMI DEV 1.2 na DATAPREV”.
3. Metodologia de Execução
O Projeto CMMI-DTP foi planejado e executado considerando as fases de Planejamento, Contratação
de Consultoria, Institucionalização, Avaliações Não-Oficiais e Encerramento, conforme a WBS (Work
Breakdown Structure) do projeto apresentado na Figura 1.
Figura 1. WBS – Projeto CMMI-DTP.
Para a fase de “Contratação de Consultoria”, mais especificamente para a execução de atividades
de contratação de uma empresa de consultoria especializada na implementação das práticas de
nível 3 do modelo CMMI DEV 1.2, foi previsto e realizado o prazo de 06 (seis) meses. Esse prazo é
considerado como indispensável ao cumprimento dos trâmites legais de aquisição de serviços.
Já para as fases de “Institucionalização”, “Avaliação Não Oficial” e “Encerramento”, o prazo foi de
24 (vinte e quatro) meses dos quais 90% dedicados às atividades de institucionalização.
Diante do porte e da importância da fase de “Institucionalização” a execução das atividades dessa fase
foram tratadas segundo o fluxo metodológico ilustrado na Figura 2. O referido fluxo foi estruturado
com o propósito de dar maior consistência à execução e ao monitoramento do Projeto CMMI-DTP,
tendo como principal produto os Ativos de Processo.
Merece destaque o fato da definição de “Ativo de Processo” ser bastante ampla, o que permite
que sejam assumidos formatos diferentes, mantendo-se, no entanto, o foco em algo que a
organização considere útil para o atendimento aos objetivos do processo. Como exemplos de ativos
de processo podem ser citados: políticas, processos definidos, lições aprendidas, roteiros (templates)
de documentos, padrões e material de treinamento (CHRISSIS et al., 2006).
WAMPS 2011 105
Artigos técnicos selecionados
Figura 2. Fluxo metodológico aplicado ao Projeto CMMI-DTP.
Cabe destacar que a consistência na condução do projeto CMMI-DTP, obtida com a aplicação do
fluxo metodológico, tornou viável o atendimento a todos os objetivos definidos para o projeto e
constantes no item 2 – Objetivos e Justificativas. No resumo descritivo, apresentado a seguir, podem
ser observadas as atividades atribuídas a cada etapa e consideradas determinantes para o sucesso
alcançado.
3.1. Workshop
Na etapa workshop foram realizadas reuniões de trabalho como principal instrumento de capacitação
e transferência de conhecimento. Nessas reuniões, que sempre precederam uma nova etapa, os
consultores contratados prestavam orientações de como aplicar as boas práticas da engenharia de
software requeridas pelo modelo CMMI DEV 1.2.
Com o conhecimento adquirido a cada workshop, os técnicos envolvidos no desenvolvimento
do Projeto CMMI-DTP passavam a ter maior facilidade na execução de suas atividades. O efeito
cumulativo de informações e conhecimento adquirido logo se traduziu em aumento de satisfação e
produtividade da equipe, merecendo destacar as poucas ocorrências de retrabalho então registradas.
106 WAMPS 2011
Relato da Experiência do Processo de Institucionalização do Modelo CMMI na Dataprev
3.2. Gap Analysis
Nesta etapa foram executadas atividades de levantamento e análise dos ativos de processo em uso
regular na DATAPREV. Esse trabalho possibilitou a identificação dos pontos fortes e fracos dos ativos
de processo, bem como o grau de conformidade do processo existente às práticas de nível 3 do
modelo CMMI DEV 1.2.
As atividades de levantamento foram realizadas pela equipe da DATAPREV, que fez uso das planilhas
PIID (Practice Implementation Indicator Description) próprias ao registro das evidências. As atividades
de análise foram realizadas pela equipe de consultores, tendo por resultado o relatório de achados
contendo os pontos fracos identificados e respectivas recomendações de ações de ajuste e melhoria.
3.3. Planejamento
De fundamental importância ao sucesso do projeto, a etapa de planejamento tratou da elaboração
dos Planos de Ação que explicitam a estratégia definida para estruturação e institucionalização dos
ativos de processo, bem como da execução das avaliações.
A responsabilidade pela elaboração desses planos foi compartilhada entre as equipes do Projeto
CMMI-DTP e da Consultoria, de forma que as ações de implementação (ou correção), os prazos
(cronogramas) de execução e os respectivos responsáveis, fossem estabelecidos em comum acordo e
visando, principalmente, o comprometimento e envolvimento de todos.
3.4. Estruturação
A etapa de estruturação exigiu grande esforço por parte da equipe do Projeto CMMI-DTP, por ter
reunido as atividades de definição, elaboração e correção (ajustes), do conjunto de ativos de processo
necessários ao atendimento às 17 (dezessete) áreas de processo relativas ao nível 3 do Modelo CMMI.
Vale destacar que a área de processo SAM (Acordo com Fornecedores), não foi contemplada no
processo de institucionalização e avaliação.
Como forma tornar viável a execução das atividades dessa etapa e em conformidade ao planejamento
definido, duas ações foram aplicadas. A primeira ação tratou de constituir, entre os técnicos envolvidos
com o Projeto CMMI-DTP, 05 (cinco) grupos de engenharia de processo (EPG). A segunda ação
cuidou de classificar as 17 (dezessete) áreas de processo, por afinidade de assunto, distribuindo-as
em pacotes entre os grupos de processo conforme Tabela 1.
Tabela 1. Grupo de Engenharia de Processo / Pacote de Áreas de Processo.
EPG
Pacotes de Áreas de Processo
1
REQM – Gerência de Requisitos; MA – Medição e Análise; CM – Gerência de Configuração.
2
PPQA – Garantia da Qualidade de Processo e de Produto; VER – Verificação; VAL – Validação.
3
RD – Desenvolvimento de Requisitos; TS – Solução Técnica; PI – Integração de Produtos; DAR –
Análise de Decisão.
4
OPD – Definição do Processo Organizacional; OPF – Foco no Processo Organizacional; OT – Treinamento Organizacional.
5
PP – Planejamento de Projeto; PMC – Monitoramento e Controle de Projeto; RSKM – Gerência de
Riscos; IPM – Gerência Integrada de Produtos.
WAMPS 2011 107
Artigos técnicos selecionados
3.5. Institucionalização
O termo institucionalização pode ser definido como a forma de executar negócios (processos de
trabalho) adotados por uma organização, de forma rotineira, como parte de sua cultura corporativa.
Isso significa dizer, que um processo institucionalizado é aquele em que todos da organização, ou
apenas os diretamente envolvidos, conhecem e têm pleno domínio de “como fazer”.
O início da etapa de institucionalização se deu com o recebimento dos ativos de processo preparados
na etapa de estruturação. Na sequência esses ativos foram aceitos pelos grupos de engenharia de
processo (EPG) na etapa de validação (vide Figura 2).
A primeira atividade da etapa de institucionalização tratou de transmitir orientações aos seus futuros
usuários (equipes de desenvolvimento / manutenção de software), por meio de treinamento ou
mentoria, abrangendo a aplicação e a importância do ativo de processo no contexto do processo de
desenvolvimento de software.
Concluídas as orientações o ativo de processo foi publicado e liberado para ser utilizado (executado)
no fluxo normal do processo de desenvolvimento, ou ainda, dependendo das características do ativo
em questão, sua execução passou a ocorrer de forma controlada em projetos piloto. Na condição de
projeto piloto o ativo de processo passou a ser submetido à avaliações constantes, com o objetivo de
se verificar, na prática, a efetividade de seus resultados e, só então, proceder à sua liberação no fluxo
normal do processo de desenvolvimento.
Cabe mencionar que, mesmo liberado para execução no fluxo normal do processo de desenvolvimento,
o ativo de processo continua sendo monitorado pelo grupo de engenharia de processo (EPG)
responsável. Esse grupo, além do monitoramento com foco na melhoria contínua, acompanha as
equipes de desenvolvimento e manutenção de software até que seja constatada a eficácia de sua
institucionalização. Os resultados apresentados na medição de eficácia poderão gerar ações de
reforço, visando ajustes nos rumos da institucionalização e garantindo vida à semente cultivada pelo
Projeto CMMI-DTP.
3.6. Validação
A etapa de validação conta com a prática de reuniões de aceitação dos ativos de processo recebidos
diretamente da etapa de estruturação, bem como da aceitação daqueles submetidos à etapa de
institucionalização.
A dinâmica dessas reuniões baseia-se na prática do voto. Da votação participam representantes
de todos os grupos de engenharia de processo (EPG), além de técnicos especialistas envolvidos na
estruturação ou na institucionalização do ativo em validação.
A importância dessa etapa está no fato de que as decisões de aceite e liberação dos ativos de processo
são colegiadas e envolvem o grupo de técnicos comprometidos com a qualidade do processo de
desenvolvimento de software da DATAPREV.
108 WAMPS 2011
Relato da Experiência do Processo de Institucionalização do Modelo CMMI na Dataprev
3.7. Avaliação
Nesta etapa foram realizadas duas avaliações compatíveis com o método SCAMPI (Standard CMMI
Assessment Method for Process Improvement – C e B), com o objetivo de mapear a situação atual dos
processos de software da organização (ativos de processo), identificar os pontos fracos, direcionar
o programa de melhoria de processos e internalizar o conhecimento do processo de avaliação de
maturidade na DATAPREV.
A condução dos trabalhos de avaliação ocorreu sob a orientação da empresa de consultoria, que
designou um consultor independente, ou seja, um profissional competente, porém não participante
das atividades de estruturação e institucionalização desenvolvidas até então, para liderar o processo.
3.8. Encerramento
Na etapa de encerramento ocorreram as seguintes atividades: obtenção das aceitações ainda
pendentes; registro dos impactos da adequação de processos; documentação das lições aprendidas;
arquivamento da documentação relevante; fechamento dos contratos de aquisição e formalização
do encerramento do projeto.
4. Resultados Obtidos
A estratégia adotada no Projeto CMMI-DTP estabeleceu entregas parciais de serviços (produtos)
associados aos resultados obtidos que, de forma incremental, incorporaram melhorias ao processo
de desenvolvimento, além de internalizar o conhecimento na DATAPREV (Tabela 2).
Tabela 2. Serviços realizados e respectivos resultados.
Serviço
Resultado
Workshop para orientar a elaboração do Gap Analysis
Aprendizado internalizado
Gap Analysis – avaliação inicial
Relatório de Achados e Planos de Ação
Planejamento para gestão e acompanhamento da implantação de novos processos e melhorias
Planos de ação e descrição das atividades, tarefas
e papéis dos processos implantados
Workshop para orientar a estruturação / institucionalização – Níveis 2 e 3 do modelo CMMI
Aprendizado internalizado
Orientação sobre estruturação das práticas relativas às
áreas de processos
Práticas estruturadas
Reunião de validação da estruturação / institucionalização das práticas
Não conformidades e termos de aceite
Planejamento e execução das correções das não conforPlano de correção das falhas
midades
Institucionalização das práticas relativas às áreas de
processo – Níveis 2 e 3 do modelo CMMI
Diagnósticos da institucionalização
Workshop para orientar as Avaliações
Aprendizado internalizado
Avaliações internas, tendo como base o método SCAMRelatórios de Achados e Planos de Ação
PI C e B, para os Níveis 2 e 3 do modelo CMMI
WAMPS 2011 109
Artigos técnicos selecionados
5. Aplicabilidade dos Resultados
Ao longo do Projeto CMMI-DTP ocorreram 03 (três) avaliações. Os resultados obtidos em cada
uma dessas avaliações evidenciaram a evolução das melhorias implementadas no processo de
desenvolvimento de software da DATAPREV.
Além da evolução das melhorias, pode-se observar também o impacto positivo junto à equipe de
técnicos envolvidos no projeto, tendo em vista o aprendizado e a percepção de melhoria declarada
por todos os participantes.
De modo a explicitar a relevância dos resultados obtidos com o desenvolvimento do Projeto CMMIDTP será apresentada a seguir uma breve descrição de cada uma das avaliações realizadas.
5.1. Primeira Avaliação – Gap Analysis
A primeira avaliação – “Gap Analysis”, realizada em março de 2009, revelou que para o atendimento
às 336 (trezentas e trinta e seis) práticas, entre genéricas e específicas, necessárias ao alcance do Nível
3 do Modelo CMMI – DEV 1.2, seriam necessárias 298 (duzentos e noventa e oito) ações de correção
das não-conformidades identificadas.
Esse resultado demonstrou, portanto, o baixo grau de conformidade do Processo de Desenvolvimento
de Software da DATAPREV, em uso regular, à época, com as práticas de Nível 3 do Modelo CMMI –
DEV 1.2.
5.2. Segunda Avaliação – compatível com SCAMPI C
Realizada em junho de 2010, a segunda avaliação teve por objetivo verificar a evolução na
implementação das melhorias e correção das não-conformidades, ou seja, o quanto a definição do
processo de desenvolvimento de software da DATAPREV havia evoluído em relação ao resultado da
primeira avaliação.
O resultado obtido nesta avaliação demonstrou a evolução da melhoria do processo, tendo em vista
o índice de 75% de redução nas ações de correção das não-conformidades. Isso significa que das
298 (duzentos e noventa e oito) ações de correção, identificadas na primeira avaliação (Gap Analysis),
apenas 76 (setenta e seis) ações continuavam requerendo atenção.
5.3. Terceira Avaliação – compatível com o SCAMPI B
A terceira avaliação teve por objetivo avaliar a evolução das melhorias na definição do processo, bem
como avaliar o grau de institucionalização do processo definido.
No caso da evolução das melhorias na definição do processo, a forma de avaliação foi similar as
avaliações anteriores. Já o grau de institucionalização foi verificado através do acompanhamento
de 04 (quatro) projetos de softwares (Projetos Piloto), observando se os mesmos estavam utilizando
os ativos de processo definidos e, ainda, se a equipe do projeto demonstrava pleno domínio
(conhecimento) do processo de software (PD-DATAPREV).
110 WAMPS 2011
Relato da Experiência do Processo de Institucionalização do Modelo CMMI na Dataprev
Embora esta avaliação tenha sido feita compatível ao método SCAMPI B, algumas adequações se
mostraram necessárias para melhor atender às expectativas das áreas funcionais da DATAPREV
envolvidas com o Projeto CMMI-DTP. As adequações citadas se resumiram aos critérios de avaliação,
definidos como:
• Conformidade – itens que estão em conformidade com o que preconiza o Modelo CMMI
DEV 1.2 e que foram executados em todos os Projetos Piloto.
• Melhoria Requerida – itens cuja definição do processo e templates estão em conformidade
com o que preconiza o modelo CMMI DEV 1.2, mas não evidenciados em, pelo menos, um
dos Projetos Piloto.
• Ponto Fraco – Itens que não foram definidos ou não estão adequados ao que preconiza o
Modelo CMMI DEV 1.2.
O resultado obtido na avaliação da definição do processo revelou que das 336 (trezentos e trinta seis)
práticas, necessárias ao atendimento do Nível 3 do Modelo CMMI – DEV 1.2, apenas 33 (trinta e três)
práticas foram avaliadas como pontos fracos. Isso representa o índice de 90,18% de conformidade
às práticas do modelo CMMI.
A avaliação do grau de institucionalização do processo, no entanto, não contou com resultados
significativos. Nessa avaliação, os 04 (quatro) projetos de software (Projetos Piloto) iniciaram em
momentos diferentes, atendendo versões diferentes da última liberação do PD-DATAPREV (versão
1.1), o que impossibilitou que se avaliasse em igualdade de condições, o nível de conhecimento das
equipes dos projetos.
De todo modo foi possível observar que todos os participantes, das 04 (quatro) equipes de projeto,
demonstraram, ao final do processo, bom nível de conhecimento da versão do PD-DATAPREV por
eles utilizada.
6. Características Inovadoras
O Projeto CMMI-DTP tem sua justificativa pautada na inovação de processo, um tipo de inovação
que se caracteriza pela alteração de processo que provoca uma mudança importante e radical
(DAVENPORT, 1994).
Nessa linha, o Projeto CMMI-DTP promoveu uma mudança radical no processo de desenvolvimento
e manutenção de software da DATAPREV, com destaque a: incorporação da qualidade em todo o
processo, o alinhamento às boas práticas da engenharia de software e o foco na melhoria contínua.
Os resultados iniciais, obtidos com a institucionalização do processo, já geraram depoimentos
positivos por parte dos usuários do processo (equipes de projeto e manutenção) indicando ganhos
de produtividade e facilidade de acesso à informação.
WAMPS 2011 111
Artigos técnicos selecionados
7. Conclusão e Perpectivas Futuras
Os resultados obtidos ao longo do Projeto CMMI-DTP serviram como insumo para incorporação
das melhorias no Processo de Desenvolvimento de Software da DATAPREV, denominado de PDDATAPREV. Com o encerramento do Projeto CMMI-DTP foram contabilizadas 149 (cento e quarenta
e nove) melhorias, o que deu origem à versão 1.1 (Figura 3).
Figura 3. PD-DATAPREV.
Outro aspecto importante que merece registro, trata-se da utilização do modelo MPS-BR (SOFTEX
– MPS-BR, 2009).também como referência na condução do Projeto CMMI-DTP. A abordagem de
conduzir os trabalhos com foco na implementação do modelo CMMI, mas com atenção à aderência
ao Nível C do modelo MPS-BR foi corroborado pelo parecer do Gartner Group, em resposta ao
questionamento realizado pela DATAPREV, quando afirma:
• O MPS-BR foi criado e adaptado para circunstâncias vivenciadas pelas organizações brasileiras
e pode bem ser um ponto de partida para melhoria de processo de software. Porém, não é tão
conhecido fora do Brasil, e assim não poderia prover a credibilidade internacional que viria de
uma certificação de CMMI equivalente.
112 WAMPS 2011
Relato da Experiência do Processo de Institucionalização do Modelo CMMI na Dataprev
• O MPS-BR é suficientemente similar ao CMMI a ponto de que seria interessante começar
com avaliações intermediárias baseadas no MPS-BR e posteriormente realizar as avaliações no
modelo CMMI ou em equivalentes, se houver benefícios genuínos para tal.
• Em organizações que são focadas em melhoria de processo, é comum encontrar aquelas que
implementam vários modelos de qualidade e certificações, tendo em vista que as diferenças nos
projetos poderão requerer abordagens diferentes que uma única metodologia ou certificação
não poderá atender ou não é apropriada.
A expectativa é de que o processo de institucionalização do PD-DATAPREV, agora sob a responsabilidade
das áreas funcionais de qualidade e escritório de projetos, continue a evoluir, tornando-se, no prazo
máximo de 01 (um) ano, o processo padrão de desenvolvimento e manutenção de software em todas
as unidades de organizacionais da DATAPREV.
Nessa linha a Diretoria de Relacionamento Desenvolvimento e Informações da Dataprev – DRD
estabeleceu como estratégia a realização de avaliação baseada no modelo MPS-BR (SOFTEX – MPSBR, 2009), prevista para o primeiro semestre de 2012, como forma de verificar a efetiva evolução e
institucionalização do PD-DATAPREV.
Referências Bibliográficas
Chrissis, M.B; Konrad, M. e Shrum, S. (2006) “Cmmi – Guidelines For Process Integration and Product
Improvement”. Addison Wesley.
Davenport, T.(1994) Reengenharia de Processos. Rio de Janeiro: Editora Campus.
ISO/IEC, 2008, “Systems and software engineering – Software life cycle processes”, The International
Organization for Standardization and the International Electrotechnical Commission, v. ISO/IEC
12207:2008.
SEI, 2006, CMMI for Development (CMMI-DEV), Version 1.2, Technical Report CMU/SEI-2006-TR-008.
Pittsburgh, Software Engineering Institute (SEI), Carnegie Mellon University, 2006.
SEI–Software Engineering Institute. Carnegie Mellon, Disponível em http://www.sei.cmu.edu/. Acesso
em out 2010.
Softex (2009) “MPS.BR – Melhoria de Processo do Software Brasileiro – Guia Geral”, ISBN 978-8599334-15-7, setembro.
WAMPS 2011 113
Artigos técnicos selecionados
Experiência de Implantação de Melhoria de
Processos de Software em um Laboratório de
Pesquisa
Fabiana Freitas Mendes2, Jackeline Neves de Almeida1, Egio Arruda Junior1
Laboratory for Ubiquitous and Pervasive Applications (LUPA) – Instituto de Informática (INF) – Universidade
Federal de Goiás (UFG)
Caixa Postal 131 – 74.001-970 – Goiânia – GO – Brasil
1
Instituto de Computação (IC) – Universidade Federal do Mato Grosso (UFMT)
Av, Fernando Corrêa da Costa, 2367. Bairro Boa Esperança – 78060-900 – Cuiabá – MT – Brasil
2
[email protected], {jackeline.neves, egio.junior}@lupa.inf.ufg.br
Abstract. This paper describes how an initiative to improve software development processes has been led
at LUPA, a research laboratory at UFG. Moreover, it presents some lessons learned during this work. Such
lessons are serving as a basis for planning the next round of process improvements.
Resumo. O presente documento descreve uma iniciativa de melhoria de processos de desenvolvimento
de software do LUPA, um laboratório de pesquisa da UFG. Além disso, são apresentadas lições aprendidas
durante a execução do projeto. Estas lições estão servindo de base para o planejamento do próximo ciclo de
melhoria.
1. Introdução
O LUPA (Laboratory for Ubiquitous and Pervasive Applications) é um laboratório de pesquisa aplicada
que funciona nas dependências do INF (Instituto de Informática) da UFG (Universidade Federal de
Goiás). Ele reúne estudantes e profissionais de computação comprometidos no desenvolvimento de
soluções de geotecnologia através de interfaces ricas para a web e computação distribuída e paralela.
Atualmente, a equipe conta com cerca de 23 pessoas distribuídas em três projetos de desenvolvimento
de software que ocorrem em paralelo a um projeto de Melhoria de Processos de Software (MPS).
Além disso, ainda compõe a equipe, pessoas diretamente envolvidas na manutenção da infraestrutura
necessária para o funcionamento do laboratório.
Cada projeto de desenvolvimento conta com equipes de 5 a 8 integrantes. Já o projeto de MPS
possui uma pessoa dedicada, um representante de cada um dos três projetos e o coordenador do
grupo, totalizando cinco participantes ativos. Participam também, sob demanda, duas pessoas para
manutenção da infraestrutura do projeto.
A peculiaridade de um laboratório de pesquisa é a ausência de um cliente, o desafio pela inovação,
requisitos nebulosos e ausência de base histórica ou dificuldade de utilizá-la quando esta existe, já
que, os desafios tecnológicos de inovação que cada projeto propõe é particular.
114 WAMPS 2011
Experiência de Implantação de Melhoria de Processos de Software em um Laboratório de Pesquisa
Este trabalho tem por objetivo relatar a experiência de implantação de MPS neste ambiente. Apesar
de existirem diversos trabalhos que relatam a implantação de MPS em organizações, por exemplo,
[Mega et al. 2007, Borssatto 2007, Mendes et al. 2010, Ribeiro 2007], foi encontrado, no conjunto de
avaliações vigentes do MPS.BR (Melhoria do Processo de Software Brasileiro) [SOFTEX 2011b], apenas
uma organização que é também um laboratório de pesquisa (COPPE/UFRJ). Trata-se, portanto, de um
tipo de iniciativa pouco explorada no Brasil.
O artigo está estruturado como se segue. A Seção 2 descreve a motivação, o ambiente de execução
da iniciativa de melhoria e as atividades de implantação planejadas e realizadas desde o início da
iniciativa. Na Seção 3 é apresentada uma visão geral do processo criado pelo projeto de melhoria. Já
na Seção 4, os resultados até então obtidos e as lições aprendidas durante o período do projeto são
descritos. Finalmente, a Seção 5 apresenta as considerações finais do trabalho, incluindo os próximos
passos planejados pela iniciativa.
2. Elaboração do Processo de Software
Baseados na hipótese de que a qualidade do processo de software influencia a qualidade dos produtos
[Tyrrell 2000], o LUPA tem investido na melhoria dos seus processos de desenvolvimento de software
desde Março de 2010.
Além da necessidade de melhoria da qualidade dos produtos do LUPA, teve-se como motivação
melhorar a gerência dos recursos e dos projetos, dar maior visibilidade do trabalho desenvolvido pela
equipe e preparar-se para a alta rotatividade dos recursos humanos, situação típica de ambientes de
pesquisas.
Por se tratar de um laboratório de pesquisa, o ambiente de desenvolvimento é diferenciado, pois
tem como foco o desenvolvimento de software voltado para P&D&I (Pesquisa, Desenvolvimento e
Inovação). Além disso, os projetos executados são caracterizados pela falta de conhecimento do
negócio e de um cliente explícito. O escopo dos projetos é instável e, portanto, há grande dificuldade
de estimativa. Assim, incerteza e novidade estão presentes no cotidiano dos projetos desenvolvidos
Para a implantação de MPS neste ambiente foram contratadas duas implementadoras do MPS.BR
e foi escolhido um processo de implantação semelhante ao IDEAL [McFeeley 1996]. A implantação
possuiu seis grandes atividades, conforme ilustra a Figura 1.
As seções seguintes tratam da descrição de como foi conduzida cada uma das fases do fluxograma
presente na Figura 1.
2. 1 Iniciação
A primeira fase foi a iniciação. Neste momento, o coordenador do LUPA foi ouvido em uma entrevista
não estruturada. Foram coletados os principais pontos fracos do modo de trabalho daquele momento,
e portanto, as principais necessidades relacionadas ao processo que seria construído.
Apesar de já terem sido coletadas diversas necessidades de melhoria, ainda era necessário conhecer
um pouco mais o modo de trabalho. Assim, foi necessário realizar um diagnóstico de processos.
WAMPS 2011 115
Artigos técnicos selecionados
Figura 1. Fluxograma de Implantação de Melhorias.
2.2 Diagnóstico
No diagnóstico foram consultados dois colaboradores, sendo um deles o coordenador do LUPA e o
outro um desenvolvedor. O diagnóstico foi realizado por meio de uma entrevista conjunta tendo como
base o nível G do MPS.BR [SOFTEX 2011a], pois segundo a entrevista inicial as principais necessidades
de melhoria concentrava-se nos processos de Gerência de Projeto e Gerência de Requisitos, os dois
processos desse nível.
Nesse momento, cada resultado esperado de cada um dos processos do nível de maturidade G foi
transformado em um tópico de entrevista. Como resultado da atividade, foi elaborado um relatório
de diagnóstico contendo as principais não conformidades com o modelo adotado.
Posteriormente, também foram detectados mais pontos fracos no modo de trabalho do grupo e,
portanto, a necessidade de se preocupar com outros processos além daqueles já previstos no nível
G do MPS.BR: Qualidade (Garantia da Qualidade, Verificação e Validação), Desenvolvimento de
Requisitos, Aquisição e Gerência de Configuração.
Uma vez montada a lista de processos, foi pedido ao grupo que selecionasse aqueles considerados
essenciais e os priorizasse. Entretanto, por não existir conhecimento suficiente para se tomar esta
decisão, foi realizado um conjunto de treinamentos que tinha como objetivo fornecer uma visão
geral sobre cada um dos processos da lista. Dessa forma, esperava-se que a equipe pudesse entender
melhor os problemas do grupo e tomar decisões quanto ao planejamento das melhorias.
2.3 Planejamento
Depois do diagnóstico partiu-se para o planejamento da iniciativa de melhoria. Para tanto, os processos
escolhidos para treinamento foram priorizados, eliminando aqueles de menor prioridade. As áreas
de melhoria escolhidas foram: Gerência de projeto, Desenvolvimento de Requisitos, Gerência de
Configuração, Testes e Comunicação. Além disso, durante o planejamento também foi definida a
ferramenta que seria utilizada para a definição dos processos.
116 WAMPS 2011
Experiência de Implantação de Melhoria de Processos de Software em um Laboratório de Pesquisa
Para a gerência do projeto de MPS, foi criado um cronograma e uma tabela de riscos que serviria
como acompanhamento do projeto. As estimativas foram realizadas utilizando-se uma variação do
método Delphi [Linstone et al. 2002], contando com as opiniões das duas especialistas em MPS e que
também conheciam o ambiente em que a iniciativa ocorreria. No cronograma elaborado, a definição
e implantação dos processos selecionados teria início em junho e término em setembro de 2010.
2.4 Definição dos processos
Finalmente, teve início a definição dos processos. À princípio foi estabelecido um template para a
definição dos processos e posteriormente as duas especialistas em MPS dividiram os esforços desta
atividade.
Devido às características dos projetos de desenvolvimento e da forma de trabalho em andamento no
LUPA, optou-se por utilizar tanto modelos de maturidade de processo (MPS – Melhoria do Processo
de Software Brasileiro – [SOFTEX 2011a] e CMMI – Capability Maturity Model Integration – [SEI
2006]) quanto algumas metodologias de desenvolvimento ágil (SCRUM [Schwaber, 2004] e XP –
eXtreme Programming – [Beck, 1999]).
Em relação ao processo de Gerência de Projetos, adotou-se inicialmente o SCRUMMI [Marçal et al.
2010] o qual foi adaptado durante sua utilização nos projetos.
Entretanto, à medida que os processos iam sendo definidos, novas necessidades foram surgindo o
que acarretou na inclusão de outras áreas de melhoria. Assim, foram definidos, além dos processos
anteriormente listados, os processos de teste, gerência de configuração e práticas que facilitassem a
comunicação através da equipe. Assim, o término da definição de processo que estava prevista para
agosto, foi finalizada apenas em dezembro.
2.5 Treinamento
Após a definição, teve início a atividade de treinamento dos processos de Gerência de projeto,
Desenvolvimento de Requisitos, Gerência de Configuração e Testes. Para tanto, a equipe foi divida
em grupos de interesse, formando assim o público para cada um dos treinamentos. A preocupação
era que pelo menos um colaborador de cada projeto em execução recebesse informações de pelo
menos um processo e trabalhasse como disseminador dele na equipe.
Os treinamentos consistiram na exposição de conceitos fundamentais e apresentação do fluxograma,
e do detalhamento das atividades de cada um dos processos.
Porém, durante estes treinamentos, percebeu-se que os processos ainda não atendiam as necessidades
da equipe e os esforços tiveram que ser concentrados nas adaptações delas. Além disso, a ferramenta
adotada para apoiar a Gerência dos Projetos também não se mostrou adequada às necessidades da
equipe e, por isso, teve que ser trocada imediatamente.
Para realizar a troca da ferramenta foram listados os principais itens esperados de uma ferramenta de
gerência de projeto e itens desejáveis pelo LUPA. Depois de selecionada a ferramenta, foi estabelecido
um cronograma de troca que incluía, além da migração dos dados, um treinamento na ferramenta
escolhida. Cada projeto migrou para a nova ferramenta seguindo um calendário, de tal forma que
nenhum projeto migrasse ao mesmo tempo. O tempo de migração entre um projeto e outro deveria
durar no máximo três semanas.
WAMPS 2011 117
Artigos técnicos selecionados
2.6 Execução dos processos definidos
Depois disso, passou-se para a execução dos processos que foram definidos. Durante a execução foi
realizado mentoring no qual era orientado o que se esperava para cada processo e como deveria ser
preenchido cada template.
Aproveitando a experiência de acompanhamento da implantação de MPS, o grupo de processo
investiu na construção de guias de execução do processo junto com exemplos de cada resultado.
Esses guias eram mais informais e possuíam informações relacionando as atividades e os templates
referentes.
Para cada guia foi realizada uma validação com os líderes dos projetos. A validação consistia na
explicação do fluxograma do processo, detalhando-se cada passo, relacionando com o cotidiano
e verificando a facilidade de entendimento e execução. Dessa forma, foi possível verificar se as
necessidades do laboratório estavam sendo satisfeitas e se a utilização do processo estava acarretando
atrasos no fluxo natural das atividades do laboratório. Se o guia refletisse a realidade do laboratório
e fosse realizável ele era aprovado, caso contrário o guia seria reformulado tendo como insumos as
inconsistências que porventura pudessem ser encontradas.
Após estes ajustes, iniciou-se, ainda na execução dos processos definidos, a avaliação de conformidade
da execução com a definição, como uma Garantia da Qualidade realizada pelo grupo de processos.
A equipe viu esta atividade como uma consultoria do grupo.
A próxima seção irá descrever o ProLUPA (Processo do LUPA) criado durante a execução do Projeto
de Melhoria.
3. Descrição do Processo do LUPA
O ProLUPA usa uma abordagem híbrida de metodologias ágeis de desenvolvimento (Scrum e XP) e
modelos de maturidade (MPS.BR e CMMI) adaptados às necessidades para gerenciamento de projeto
de P&D&I (Pesquisa, Desenvolvimento e Inovação).
A Figura 2 mostra um fluxograma resumido das fases processo desenvolvido.
Figura 2. Fluxograma das Fases do projeto.
118 WAMPS 2011
Experiência de Implantação de Melhoria de Processos de Software em um Laboratório de Pesquisa
Como pode ser visto, o primeiro passo previsto no ProLUPA é identificar as necessidades do
sistema a serem atendidas pelo projeto. Para cada uma destas necessidades é definida uma prioridade
de acordo com valor para o negócio. O valor de negócio varia de 0 a 10, onde 0 significa que a
necessidade não é importante para o negócio e 10 representa aquela que possui a maior significância.
Esse valor é determinado pela influência da necessidade para o sucesso do projeto.
Em seguida é realizado o planejamento da abertura do projeto no qual itens como escopo,
premissas, restrições, riscos preliminares, atores envolvidos são definidos. Esta etapa encerra-se com
a reunião de abertura do projeto com a equipe definida.
A próxima fase consiste no planejamento do projeto com base no objetivo do projeto e a lista de
necessidades. Para cada necessidade identificada são definidas listas de macro atividades para atendêla. Paralelamente são executadas as atividades do processo de Gerência de Configuração: identificar
itens de configuração e definir a estrutura de armazenamento dos produtos do projeto.
Após o planejamento do projeto, inicia-se as atividades executar e monitorar projeto. Na
execução é buscado o alinhamento dos objetivos estratégicos do projeto com os objetivos técnicos
do desenvolvimento. O objetivo do projeto é fragmentado e estruturado em marcos que duram de
um a dois meses.
Depois disso, são definidas as iterações em função dos objetivos definidos (sprints) com duração de
duas semanas. No início de cada sprint é feito o planejamento das atividades a serem desenvolvidas
durante uma reunião com a equipe e, durante o período do sprint, a equipe trabalha no desenvolvimento
destas atividades. Ao final do sprint é realizada uma reunião de fechamento com a equipe para a
validação das atividades desenvolvidas.
A identificação e monitoramento dos riscos são realizados por meio de reuniões com os membros
da equipe. Na abertura e no fechamento dos sprints a equipe do projeto analisa o desempenho do
projeto em relação aos riscos. Também nestas reuniões é analisado o quanto as atividades propostas/
desenvolvidas contribuirão/contribuíram para atingir o objetivo do sprint, do marco e do projeto.
Além disso, diariamente é realizada uma reunião de acompanhamento que dura, em média, 15
minutos. Nestas reuniões discutem-se as atividades dos projetos e as dificuldades encontradas.
O monitoramento também é feito por um conjunto de métricas que visam acompanhar a velocidade
da equipe, o esforço gasto e a relação das atividades planejadas e não planejadas. Através da
análise dos dados obtidos pela aplicação das métricas é possível detectar atrasos no cronograma, a
quantidade de tarefas não planejadas e realizadas no projeto, a falta de alinhamento das atividades
com o objetivo do projeto, a produtividade da equipe, dentre outros. Com estas informações em
mãos, é possível, se necessário, realizar o replanejamento.
O projeto é encerrado quando não existem mais necessidades a serem implementadas e os testes
foram realizados.
Quando um novo membro integra a equipe do projeto são realizados treinamentos nos quais são
apresentados os fluxogramas do ProLUPA.
Para a evolução contínua do ProLUPA são realizadas reuniões mensais com todos os líderes dos
projetos e com o coordenador do laboratório. Nestas reuniões são apresentados os resultados dos
WAMPS 2011 119
Artigos técnicos selecionados
projetos e as experiências vivenciadas no período. Nessas reuniões também são consideradas as
solicitações de melhorias enviadas por e-mail, formulário de avaliação do sprint e os indicadores
gerados durante o período. Através disso, são coletadas oportunidades de melhoria do processo e
discutidas as estratégias para melhorá-lo.
4. Resultados e Lições Aprendidas
Apesar do pouco tempo do projeto de MPS, já foram alcançados diversos resultados:
1. Conscientização da equipe sobre a necessidade de processos definidos e otimizados, e de
planejamento de atividades;
2. Definição e documentação dos processos-chave para o LUPA;
3. Criação de um padrão para a gerência e execução de projetos;
4. Aumento da visibilidade das atividades e esforços dos projetos desenvolvidos no LUPA;
5. Participação da equipe na elaboração do processo;
6. Melhoria na comunicação do time;
7. Criação de um glossário para uniformização dos termos utilizados pela equipe;
8. Aceitação do processo; e
9. Melhoria e evolução contínua do processo.
Esta experiência também gerou diversas lições aprendidas, as quais são apresentadas a seguir, com
algumas discussões.
1. Elaborar versão inicial do processo o mais próximo possível do realizado pela equipe
e evoluí-lo progressivamente à medida que o processo é aceito pela equipe. Quando o
projeto de MPS foi iniciado, o desenvolvimento de software ocorria de forma diferente daquela
proposta pelo processo. Assim, houve resistência na adoção das práticas propostas até que elas
fossem completamente entendidas e discutidas pela equipe. Ao se definir um processo, este
deve soar o mais natural possível, de modo a facilitar o entendimento.
2. Definir o processo de maneira bottom-up. A definição do processo preocupou-se em
desenvolver um fluxograma macro, contendo as principais fases e atividades do processo.
Depois disso, cada atividade foi melhor detalhada e foram criados templates e guias de acordo
com a necessidade. Entretanto, um melhor resultado poderia ter sido atingido se tivesse sido
adotada uma abordagem mais bottom-up, ou seja, primeiro definir os processos que seriam
trabalhados e um fluxograma para mostrar a interação entre eles. Depois formalizar as práticas
da equipe, criando-se guias e templates para elas. E, só então, as atividades seriam criadas.
3. Planejar mais efetivamente o projeto de MPS. Apesar de ter sido realizado o planejamento
do projeto, alguns itens não ficaram claros para toda equipe como o cronograma geral do
projeto, incluindo o processo de implantação e de melhoria. A equipe de MPS deve manter
120 WAMPS 2011
Experiência de Implantação de Melhoria de Processos de Software em um Laboratório de Pesquisa
todos os colaboradores do laboratório trabalhando juntos e alinhados com o cronograma para
uma melhor aceitação.
4. Definir o processo de maneira a envolver melhor a equipe. O processo foi definido
pelos dois membros mais experientes nesta tarefa. Apesar da equipe ter sido consultada antes
e durante a definição, percebeu-se que o envolvimento de mais pessoas na tarefa de definição
teria ajudado, posteriormente, na implantação dos processos. No final, para a aceitação do
processo isso teve de ser realizado.
5. Definir processo tendo apenas um tipo de projeto como foco principal. Atualmente
o LUPA possui projetos de diversas naturezas e o processo foi definido de forma a tentar se
adaptar a qualquer um dos projetos do laboratório. Entretanto, isso acarretou em um processo
que acabava não sendo adequado a nenhum dos projetos. Assim, percebeu-se a necessidade
de definir um processo tendo como fornecedor de requisitos apenas um tipo de projeto,
resultando em um processo mais focado. Logo, os outros projetos devem adaptar o processo
definido de acordo com suas características específicas e detalhar as particularidades no plano
de projeto.
6. Estabelecer e manter a prioridade do projeto de MPS. Durante o período do projeto, houve
muita oscilação da prioridade do projeto de MPS. Não houve um apoio efetivo do patrocinador
ou ele foi dado de maneira muito superficial, pois, na primeira dificuldade, as atividades do
ProLUPA eram deixadas em segundo plano. As atitudes que ajudaram na conscientização
da importância do projeto foram: utilizar página wiki de forma colaborativa, criar guias de
execução do processo, criar exemplos do artefatos, criar momentos para comunicação do time,
ajudar no preenchimento de cada artefato como se fosse uma consultoria, participação do
grupo de processos nas reuniões de abertura e fechamento de sprint fazendo observações a
respeito do planejamento e resultados obtidos.
7. Controlar mudanças na equipe do ProLUPA. Durante a execução do projeto houve a
saída de pessoas chave, o que resultou no “esfriamento” do projeto. Assim, faz-se necessário
o envolvimento de diversas pessoas nas atividades de definição do processos para que o
conhecimento seja disseminado e que a rotatividade não impacte o projeto.
8. Gerenciar a utilização do processo. Houve abandono do processo e utilização de outras
abordagens e templates por parte dos projetos, dificultando a implantação do que foi definido
no ProLUPA. Dessa forma, houve inclusão de documentos que misturaram conceitos e geraram
despadronização da documentação do processo. Para evitar esse cenário o grupo do processo
deve atuar mais próximo da equipe de desenvolvimento e preocupar com a definição e liberação
de templates antes do fluxo do processo.
9. Disseminar conhecimento dos processos e dos conceitos relacionados a eles. A falta
de conhecimento de processos e de alguns conceitos por alguns integrantes, ocasionou diversos
problemas como a mudança prematura do processo e a falta de entendimento da abordagem
de implantação utilizada. A comunicação deve ser mais efetiva incluindo realização de reuniões
com os membros para alinhar ideias, procedimentos, necessidades e costumes. A utilização de
ferramentas mais adequadas, como a wiki, são bastante úteis na comunicação da equipe.
WAMPS 2011 121
Artigos técnicos selecionados
10. Implantar os processos um a um. Dos processos que foram definidos foram escolhidos
apenas três (Gerência de Projeto, Desenvolvimento de Requisitos e Gerência de Configuração)
para serem implantados no período de dois a três meses. Assim, os dois processos restantes,
seriam implantados posteriormente. Entretanto, não foi obtido êxito na execução desta
estratégia devido à falta de prioridade do projeto de melhorias. Os processos devem ser
definidos e implantados um a um, dessa forma há um melhor entendimento, aceitação dos
processos e o impacto das mudanças será menor.
11. Estabelecer projetos menores. Os produtos a serem entregues pelo LUPA possuem uma
complexidade alta, o que resulta em projetos com duração superior a um ano. Implantar
processo em um ambiente de pesquisa com projetos de longa duração mostrou-se inviável
devido à instabilidade dos requisitos e aos desafios tecnológicos. A solução foi estabelecer
projetos menores, com duração média de 3 meses. Estes projetos contemplavam os requisitos
que a equipe possuía maior segurança para trabalhar. Dessa forma, o processo pôde ser
aplicado de um modo mais satisfatório.
5. Considerações Finais
Este trabalho mostrou como foram e estão sendo conduzidas as melhorias de processos no LUPA.
Neste pouco mais de um ano de projeto, foram definidos os processos de Gerência de Projeto,
Desenvolvimento de Requisitos, Gerência de Configuração, Testes, Garantia da Qualidade e itens
relacionados à comunicação da equipe.
Atualmente, o projeto está na fase de implantação de melhoria de processos. O objetivo agora é
dar um foco maior aos processos de Gerência de Configuração, por já se ter uma versão estável e
implantada de Gerência de Projeto e Desenvolvimento de Requisitos.
Como pode ser visto, por se tratar de um laboratório de pesquisa, a implantação de MPS possui
diversas particularidades. A falta de um fornecedor de requisitos, o constante desafio pela inovação
tecnológica e a grande rotatividade da equipe acarretaram em muitas adaptações no processo.
Uma delas foi o alto investimento na melhoria da comunicação interna da equipe para minimizar
as mudanças no grupo. Outra foi a definição de projetos pequenos (com cerca de três meses de
duração) contendo apenas os requisitos que a equipe se sente segura para estimar.
Além disso, para suprir as necessidades advindas das características do ambiente, foi desenvolvido
um processo focado nas características de apenas um projeto. Assim, os demais projetos devem
adaptá-lo segundo as características específicas dele.
Um ponto forte de se trabalhar em um laboratório de pesquisa é a postura questionadora da equipe.
Isso foi impactante na implantação do processo, pois a equipe queria entender antes de aplicar o
processo. Apesar do atraso no cronograma de implantação do processo, o interesse e envolvimento
da equipe foi importante para a evolução e fortalecimento do processo.
Embora falte pouco para a adequação do ProLUPA ao nível G do modelo MPS, uma avaliação oficial
do MPS.BR não faz parte dos objetivos do laboratório no momento. Entretanto, ela contribuiria
para o alcance de um dos objetivos do LUPA que é tornar-se, até 2015, um Instituto de Pesquisa,
122 WAMPS 2011
Experiência de Implantação de Melhoria de Processos de Software em um Laboratório de Pesquisa
Desenvolvimento e Inovação de referência na área de Geoprocessamento e RFID (Radio-Frequency
IDentification).
Um dos fatores que contribuem para a decisão de não se certificar neste momento é a falta de
recursos para custear uma avaliação. Ainda assim, é uma preocupação do coordenador do projeto a
excelência dos seus profissionais e produtos e, por isso, tem-se investido recursos para que esta meta
seja cumprida.
Referências
Borssatto, I. (2007). A Implementação do MPS.BR Nível F na Synos, In: PROQUALITY – Qualidade
na Produção de Software, v. 3, n. 2, pp. 105-110, Novembro.
Beck, K. (1999) Extreme Programming Explained: Embrace Change. Addison-Wesley.
Linstone, H. A. e Turoff, M. (2002). The Delphi Method: Techniques and Applications. Disponível
em: <http://is.njit.edu/pubs/delphibook/delphi-book.pdf>. Acesso em Fevereiro de 2011.
Marçal, A. S. C. e Furtado, M. E. S. (2010). Scrummi: Um processo de gestão ágil baseado no
Scrum e aderente ao CMMI. IX Simpósio Brasileiro de Qualidade de Software, p. 426-439.
McFeeley, B. IDEAL: A User’s Guide for Software Process Improvement. CMU/SEI-96-HB-001
Pittsburgh, 1996. 236p.
Mega, B., Fonseca, K., Boessio, R., et al. (2007). Melhoria de Processos de Software na Drive, In:
PROQUALITY – Qualidade na Produção de Software, v. 3, n. 2, pp. 82-86, Novembro.
Mendes, F. F., Nascimento, H. A. N. D., Fernandes, P. G., Nunes, R. S., Mota, C. C. (2010). Implantação
de Melhoria de Processos em um Setor de Produção de Software de uma Universidade
Federal. IX Simpósio Brasileiro de Qualidade de Software, p. 359-365.
Ribeiro, A.F. (2007). Melhoria de Processos de Software com Base no Nível G do MPS.BR na
Prodemge. In: PROQUALITY – Qualidade na Produção de Software, v. 3, n. 2, pp. 87-90, Novembro.
Schwaber, K. (2004) Agile Project Management with Scrum. Microsoft Press, 2004.
SEI – Software Engineering Institute (2006) CMMI for Development (CMMI-DEV). Version 1.2,
Technical report CMU/SEI-2006-TR-008. Pittsburgh, PA.
SOFTEX, Associação Para Promoção da Excelência do Software Brasileiro (2011). Melhoria de
Processo de Software Brasileiro (MPS.BR): Guia Geral: 2011. Disponível em: <http://www.softex.br/
mpsbr/_guias/default.asp>. Acesso em: Setembro de 2011.
SOFTEX, Associação Para Promoção da Excelência do Software Brasileiro (2011). Avaliações
MA-MPS. Disponível em: <http://www.softex.br/mpsbr/_avaliacoes/ default.asp>. Acesso em
Setembro de 2011.
Tyrrell, S. (2000). The many dimensions of the software process. Crossroads. ACM, New York,
p. 22-26. jun. 2000.
WAMPS 2011 123
Artigos técnicos selecionados
Revisão Sistemática Sobre a Comunicação
Dentro do Processo de Desenvolvimento de
Software
Taciano M. Moraes1, Juliano L. de Oliveira1, Adriana S. de Souza1
Instituto de Informática – Universidade Federal de Goiás (UFG)
Caixa Postal 131, Campus II – 74.001-970 – Goiânia – GO – Brasil
1
{taciano, juliano, adrianasouza}@inf.ufg.br
Abstract. Effective communication has always been of fundamental importance for all kinds of projects. For
software development projects, in particular, communication is a critical success factor. In spite of countless
technologies and methodologies specifically focused on communication in software engineering projects,
the difficulties persist. This paper discusses findings of a Systematic Review that examined research results
published on this subject. These findings help understand how the issue of communication has been handled
in software development projects, and the importance of this issue for both the scientific community and the
software industry.
Resumo. Comunicação efetiva sempre foi de importância fundamental para todas as naturezas de projetos.
Para projetos de desenvolvimento de software, em particular, comunicação é um fator crítico para o sucesso.
Apesar de haver inúmeras tecnologias e metodologias direcionadas especificamente para a comunicação
nos projetos de Engenharia de Software, as dificuldades persistem. Este artigo discute as conclusões de
uma Revisão Sistemática que analisou resultados de pesquisas publicadas sobre esse tema. Essas conclusões
ajudam a compreender como a questão da comunicação tem sido tratada em projetos de desenvolvimento
de software, e a importância dessa questão para a comunidade científica e para a indústria de software.
1. Introdução
O principal atributo para o gerenciamento efetivo de projetos de desenvolvimento de software é a
comunicação [Brooks 1995]. Nesse contexto, a comunicação envolve o intercâmbio completo de
informações decorrente da interação entre os envolvidos no projeto [Project Management Institute
2008]. Falhas de comunicação são as fontes mais frequentemente citadas de conflitos interpessoais
em organizações [Robbins 2005]. Como as pessoas envolvidas em projetos de software precisam
se comunicar continuamente, tanto de forma oral quanto escrita, é natural que problemas na
comunicação sejam uma das principais barreiras para o bom desempenho de um projeto.
A necessidade de comunicação ao longo do projeto por todos os participantes faz com que a eficácia
da comunicação influencie de forma determinante a qualidade dos processos executados e, por
consequência, a qualidade do produto gerado pelo projeto. As dificuldades de comunicação se
agravam, de forma não linear, com o aumento do número de pessoas envolvidas em um projeto.
Este fato influencia um dos axiomas fundamentais da Engenharia de Software que determina que o
esforço (ou seja, a quantidade de pessoas alocadas) e o tempo necessário para executar um projeto
de software não são recursos intercambiáveis [Brooks 1995].
124 WAMPS 2011
Revisão Sistemática Sobre a Comunicação Dentro do Processo de Desenvolvimento de Software
De acordo com [Standish Group 2009], 24% dos projetos de desenvolvimento de software falham
completamente, sendo cancelados ou entregando produtos que nunca serão utilizados. O percentual
de projetos que terminam com desvios no orçamento ou cronograma chega a 44%, e apenas 32%
dos projetos termina com sucesso. Dentre as causas que podem fazer um projeto falhar, uma das que
mais tem influência sobre as outras é a comunicação [Jost 2006].
Esse impacto que a comunicação exerce sobre o resultado de projetos de desenvolvimento de
software motivou a execução de uma Revisão Sistemática (RS) para investigar o estado da arte
nesse assunto. A RS conduzida selecionou e analisou os principais artigos científicos e relatos de
experiência relacionados com a comunicação em projetos de software. Os resultados dessa RS
permitem a identificação de boas práticas relacionadas com a comunicação em projetos de software,
mas também apontam lacunas nas metodologias e indicam armadilhas comuns que dificultam a
comunicação efetiva nos projetos de software.
Tomando como base as três fases do processo de RS proposto por Brereton et al. [2007], este artigo
está assim dividido: a Seção 2 resume o planejamento da RS, descrevendo os principais aspectos do
protocolo estabelecido; a Seção 3 discute a condução da RS no que se refere às execuções das buscas
por referências e à documentação de resultados; a Seção 4 analisa os resultados da RS; a Seção 5
apresenta considerações finais sobre a RS realizada e indica direções para trabalhos futuros.
2. O Protocolo de Revisão Sistemática
A primeira fase do processo de RS realizado envolveu o planejamento do trabalho, iniciando pela
definição do Protocolo de RS, que foi feito com base nos modelos apresentados em [Biolchini et al.
2005; e Kitchenham 2007]. Por meio deste protocolo foi planejado todo o processo de RS, o que
permite que outros pesquisadores repitam este processo, e comparem os resultados obtidos.
A partir dos objetivos da RS, que envolvem a avaliação do estado da arte da comunicação em projetos
de desenvolvimento de software, foram elaboradas três questões de pesquisa primárias (1, 2 e 3)
e duas questões secundárias (a e b):
1. Qual a importância dada à comunicação no processo de desenvolvimento de software?
2. Quais as principais formas de comunicação, e em quais etapas do processo de desenvolvimento
de software elas são utilizadas?
a. Quais boas práticas e dificuldades estão relacionadas a estas formas de comunicação?
3. Quais são as ferramentas, tecnologias, processos e metodologias próprias para o tratamento
da comunicação no processo de desenvolvimento de software?
b. Quais delas são realmente utilizadas na prática, e quais comprovadamente trazem melhorias
à comunicação?
Vale ressaltar o caráter causal da primeira questão, enquanto as outras duas possuem caráter
exploratório. Assim, este trabalho pode ser considerado como uma mescla de Revisão Sistemática
e Estudo de Mapeamento. Entretanto, como não há consenso sobre a real diferença entre estas
nomenclaturas [da Silva et al 2010], foi mantido o primeiro nome, que tem sido mais utilizado pela
comunidade acadêmica.
WAMPS 2011 125
Artigos técnicos selecionados
Existem ainda, outros itens relacionados ao escopo e às especificidades da RS que merecem destaque:
a intervenção é a comunicação dentro do processo de desenvolvimento de software; o controle
foi baseado em uma coleção de artigos publicados sobre este tema na última década; a população
é composta de estudos e pesquisas neste tema; os resultados são um conjunto de dificuldades,
problemas, boas práticas, ferramentas, processos e metodologias específicas a este contexto; e a
aplicação é servir como base para o trabalho de equipes de desenvolvimento de software, e para
estudos e ferramentas focadas nesta área.
De acordo com as estratégias de busca definidas no protocolo de RS, foram consideradas sete fontes
para a pesquisa: ACM Digital Library, IEEEXplore, SpringerLink, CiteSeer, Google Scholar, ScienceDirect
e Scirus. Essas fontes foram selecionadas de acordo com sua importância para a comunidade
internacional e com sua contribuição a este trabalho. Os idiomas considerados foram o Inglês,
língua padrão para publicações internacionais; e o Português, para assegurar que os resultados da RS
contemplem os trabalhos desenvolvidos no Brasil. Foram consideradas nas strings de busca iniciais
as seguintes palavras-chave: Communication {Good Practices, Difficulties, Tools, Skills, Process,
Methodologies, Improvement}; Information Technology; Software {Development, Engineering};
Project Management.
Visando eliminar resultados não desejados, essa string de busca em inglês (e sua versão em português)
foi assim refinada: Title: ((“Software Development” OR “Software Engineering” OR “Requirements
Engineering” OR “Project Management” OR “Information Technology”) AND “Communication”). A
restrição de busca somente no título visa obter artigos cujo foco principal seja a comunicação.
Com relação aos critérios de seleção, o protocolo define a inclusão de resultados que: estão em
um dos idiomas definidos; estão disponíveis integralmente; e contêm no título ou no resumo alguma
relação com o tema da RS (eliminando, por exemplo, artigos que tratam de gerenciamento de
projetos em áreas que não envolvem desenvolvimento de software). Também foi definido que haverá
exclusão de resultados que: não tratam sobre o tema da comunicação; não estão no contexto de
desenvolvimento de software; ou não atingem o critério mínimo de qualidade (nota 7,0) definido no
protocolo. A análise da qualidade é feita através do cálculo da média aritmética das notas (de 0 a
10) atribuídas pelos pesquisadores que conduzem a RS a cada aspecto e assunto abordados na obra.
De acordo com os procedimentos de seleção, o protocolo prevê a realização de pelo menos
duas buscas (em inglês e português) em cada fonte selecionada, utilizando-se a string de busca
estabelecida e sua versão traduzida. Cada busca é documentada, mostrando: data de execução; fonte;
resultados retornados; resultados aprovados pelos critérios de inclusão; e resultados eliminados pelos
critérios de exclusão. Quando um resultado satisfaz a todos os critérios de seleção, ele é avaliado
e, se considerado como estudo primário, passa às etapas de análise da qualidade e extração dos
resultados.
O protocolo prevê uma etapa de extração dos resultados através da elaboração de um relatório
tabular de extração de dados contendo: título, autores, ano de publicação, número de páginas,
palavras-chave, resumo, fonte e uma nota referente à sua qualidade. Após este relatório, é realizada
uma análise crítica discursiva sobre todos os estudos primários, fazendo uma avaliação geral sobre
o resultado obtido.
126 WAMPS 2011
Revisão Sistemática Sobre a Comunicação Dentro do Processo de Desenvolvimento de Software
3. Execução do Protocolo de RS
Uma forma de avaliação do protocolo de RS estabelecido é através de testes de execução [Biolchini
et al. 2005]. Assim, juntamente com a condução do protocolo, foram realizados diversos testes (no
período de 09/06/2010 a 26/08/2010) com diferentes strings de busca. Os resultados desses testes
auxiliaram a adequação do protocolo de RS, considerando as strings com a melhor taxa de retorno
positivo.
Após esse período de iterações e melhorias, as buscas foram concluídas no período de 15/08/2010
a 29/10/2010. As buscas nas fontes ACM, ScienceDirect e CiteSeer transcorreram conforme o
planejado. Nas demais fontes houve restrições e configurações que merecem ser destacadas:
• IEEEXplore – O site apresentou divergências nos resultados pela busca padrão, de forma que só
foi possível a sua utilização através da busca avançada.
• SpringerLink – Grande parte dos resultados eram capítulos de livros, e só estavam disponíveis
para serem comprados.
• Google Scholar e Scirus – Precisaram ser impostas as seguintes restrições: Formato: PDF; Área:
Computação; Ano de publicação: de 1970 a 2010. Foram eliminados os resultados sem estas
informações.
De uma forma geral, o resultado da execução das buscas, tanto em inglês (ING) quanto em português
(PT), pode ser observado na Figura 1.
Figura 1. Resultado geral da execução das buscas.
A busca em inglês retornou 202 resultados (86%), contra 28 (14%) em português. Esses resultados
foram significativamente reduzidos pela seleção preliminar baseada nos critérios de inclusão do
protocolo de RS, conforme mostra a Figura 2.
WAMPS 2011 127
Artigos técnicos selecionados
Figura 2. Seleção dos resultados em inglês e em português.
Como a seleção preliminar verificou apenas os critérios de inclusão, foi feita uma nova iteração
para avaliar os critérios de exclusão definidos no protocolo de RS, levando em consideração os
dados extraídos dos resultados das buscas. Os trabalhos reprovados nos dois primeiros critérios de
exclusão foram eliminados do resultado. Por este motivo, a classificação e a análise final de resultados
contempla apenas 67 resultados, sendo 58 em inglês e 9 em português.
Na etapa de documentação da RS, os resultados selecionados foram lidos e submetidos à análise de
conteúdo pelos pesquisadores envolvidos na RS, realizando-se, então, uma nova seleção para os que
abordavam aspectos ou assuntos pertinentes ao contexto dessa RS. Foram definidos três aspectos
(Organizacional, Individual e Linguístico) e dez assuntos (retirados das questões de pesquisa) que
seriam de interesse. Dessa forma, os resultados da RS foram categorizados conforme o aspecto de
comunicação discutido (Figura 3) e o assunto abordado (Figura 4).
ING
PT
Figura 3. Resultados classificados quanto aos aspectos de comunicação.
128 WAMPS 2011
Revisão Sistemática Sobre a Comunicação Dentro do Processo de Desenvolvimento de Software
Como mostra a Figura 3, apenas um resultado em cada idioma aborda todos os três aspectos da
comunicação. A maioria dos trabalhos trata o aspecto organizacional, uma parcela menor trata
o aspecto individual, e poucos trabalhos abordam o aspecto linguístico da comunicação. Esta
desigualdade é ainda mais acentuada para os resultados em português, devido à pequena quantidade
de resultados obtidos.
Com relação à classificação por assunto, houve uma distribuição relativamente balanceada dos
resultados entre os dez assuntos identificados, nos dois idiomas pesquisados. Em ambos os idiomas
o assunto metodologias foi o menos abordado, enquanto os assuntos modelos ou processos e
formas de comunicação estiveram entre os mais referenciados nos trabalhos analisados.
Figura 4. Resultados classificados quanto aos assuntos abordados.
Vale destacar que muitos trabalhos analisados apresentam indícios de melhoria na comunicação,
seja pelo uso de ferramentas e tecnologias, pelo desenvolvimento de habilidades, pela definição
de modelos ou processos, pela adoção de metodologias, ou pela aplicação de técnicas ou
dinâmicas específicas. No entanto, poucos apresentam evidências concretas (quantitativas e
qualitativas) de aprimoramento na comunicação.
Após as etapas de categorização e avaliação da qualidade, os resultados foram submetidos ao último
critério de exclusão. Dos 67 resultados analisados, 31 obtiveram nota maior que a exigida (7,0), sendo
26 em inglês e 5 em português. De acordo com o protocolo estabelecido, esses resultados foram
considerados estudos primários. A média geral da qualidade foi de 6,48 para os trabalhos em inglês,
e de 7,02 para os trabalhos em português. Levando-se em consideração apenas os selecionados pela
RS, a média dos trabalhos em inglês foi 8,18 e a dos trabalhos em português foi 8,34.
WAMPS 2011 129
Artigos técnicos selecionados
4. Análise dos Resultados
Na fase da revisão, os trabalhos selecionados foram analisados de acordo com as questões propostas
no protocolo de RS. Para diferenciar as referências bibliográficas dos estudos primários, foi utilizada
a seguinte notação: <Ing-X> ou <Pt-X>, onde X é o número identificador que possibilita localizar o
artigo dentre os resultados incluídos na RS, presentes na Tabela B.3 do documento completo da RS
[Moraes et al 2011].
Questão 1: Qual a importância da comunicação no processo de software?
A resposta para esta questão foi obtida através da análise quantitativa de artigos publicados sobre
esse assunto nos últimos trinta anos, conforme mostra a Figura 5. Nesta análise foram considerados
todos os artigos selecionados pela RS, inclusive os com qualidade inferior a 7,0, mas que atenderam
aos demais critérios do protocolo.
Figura 5. Análise quantitativa temporal de assuntos e aspectos dos resultados em inglês.
Apesar de não contemplada neste artigo, a análise quantitativa temporal dos artigos publicados
em português também aponta uma crescente preocupação com este tema. De fato, a quantidade
de publicações triplicou em relação à década passada. Também fica evidente a tendência de focar
apenas o aspecto organizacional da comunicação, o que pode ser considerado uma limitação desses
trabalhos, uma vez que o único artigo que abordou os três aspectos com profundidade foi <Pt-13>.
Questão 2: Quais as principais formas de comunicação, em quais etapas do processo de software
elas são utilizadas, e quais as boas práticas e dificuldades?
Apesar da grande diversidade de formas de comunicação citadas na literatura, é possível classificá-las
com base em três critérios, conforme mostra a Tabela 1.
130 WAMPS 2011
Revisão Sistemática Sobre a Comunicação Dentro do Processo de Desenvolvimento de Software
Tabela 1. Taxonomia e Aplicações das Formas de Comunicação em Projetos.
Critério de Classificação
Quanto ao
Sincronismo
• Síncrona
Indicada para diálogos importantes e urgentes. Ex.: Reuniões (presenciais
ou vídeo-conferências); Instant Messenger; Conversas pessoais.
• Assíncrona
Indicada para recados e afazeres sem restrição de tempo. Ex.: E-mail
estruturado, Voice-mail; Grupos de discussão; Fóruns; SMS.
• Formal
Utilizada no planejamento e organização do projeto, é impessoal e
pouco interativa. Ex.: Especificações de requisitos; Atas de Reuniões;
Cronogramas; Relatórios de progresso; Relatórios de defeitos.
• Informal
Utilizada para motivação e integração da equipe, é pessoal e mais
interativa. Ex.: Discussões em pares; E-mail não estruturado; Esboços de
requisitos e modelos; Telefonemas; Video/áudio conferência informal.
• Verbal
Usada em praticamente todos os casos que envolvem comunicação.
Quanto à
Formalidade
Quanto ao
Código
ou Canal
Indicações de Uso e Exemplos
ºº Oral
Preferível em comunicações de trabalho de caráter não deliberativo.
Ex.: Reuniões técnicas; Palestras; Entrevistas; Apresentações.
ºº Escrita
Indicada para comunicações oficiais e registro de decisões e deliberações.
Ex.: Contratos; Ofícios; Relatórios de auditoria; Registros de Marco.
• Não-Verbal
Importante em acordos e negociações. Ex.: Postura; Tonalidade; Gestos.
Uma boa prática na comunicação formal escrita é o uso de templates, como sugere <Ing-20>. As
dificuldades dessa prática se relacionam ao entendimento (ou a não leitura) dos comentários e à
organização dos documentos. <Ing-26> e <Ing-31> discutem sobre os diferentes tipos de mídias,
quais fatores influenciam em sua escolha e quais são mais recomendadas para cada situação dentro
de um projeto.
Na comunicação com o cliente (especialmente em projetos ágeis), <Ing-27> defende a comunicação
face a face. Caso o cliente esteja indisponível e o assunto seja extenso ou complexo, o preferível
é a videoconferência. Em seguida, o telefone, pelo rápido feedback. O uso de e-mails somente é
recomendado para assuntos já esclarecidos.
Como nenhum dos trabalhos demonstrou a predominância de determinada forma de comunicação
em uma dada etapa do desenvolvimento de software, pode-se concluir que esta relação varia de
acordo com as características do projeto e da organização.
Questão 3: Quais ferramentas, tecnologias, e metodologias apoiam a comunicação? Quais têm sido
utilizadas em projetos e comprovam melhorias na comunicação?
Dentre as várias ferramentas citadas pelo artigo <Ing-58>, vale destacar Object Lens e Coordinator,
que gerenciam a comunicação com uma plataforma sobre o sistema de e-mail; e Grove e Quilt,
que facilitam e gerenciam a edição colaborativa. Para projetos distribuídos os artigos <Ing-173>
e <Ing-9> fazem um apanhado de inúmeras ferramentas, com destaque para VIMEE, TeamSpace,
MILOS e CVW. Também a ferramenta Issue Tracker, segundo <Ing-33> e <Ing-184>, pode apoiar
a comunicação e coordenação eficiente do trabalho. Da mesma forma, Storyboards e Taskboards,
ainda que não digitais, servem como um canal direto de comunicação entre a equipe, como defende
<Ing-139>.
WAMPS 2011 131
Artigos técnicos selecionados
As práticas ágeis defendem o predomínio da comunicação oral face-a-face sobre a documentada.
Com as práticas sugeridas em <Ing-139>, é possível conseguir um maior compartilhamento de
informações entre a equipe, facilitando a agilidade nas mudanças. A única dificuldade relatada
foi no caso de projetos complexos e de grande porte, nos quais se recomenda utilizar adaptações
destas metodologias para equipes extensas e distribuídas. Essas adaptações já estão disponíveis
para métodos como XP, RUP e Scrum, como discute <Ing-80>.
Foram observadas diversas técnicas e dinâmicas para o ensino de habilidades comunicativas, como
Role-Play, Brainstorming, treinamentos de trabalho em equipe, apresentações, escrita de documentos
de gerência de projeto, e especificações de requisitos, com destaque para as propostas de <Ing-8>
e <Ing-11>.
O framework de habilidades para um bom trabalho em equipe proposto em <Ing-42> destaca
habilidades relacionadas à comunicação: redação técnica; condução de entrevistas e reuniões;
apresentações; escuta efetiva; compartilhamento de ideias; liderança; negociação e solução
de conflitos. O trabalho apresentado em <Ing-138> comparou estas e várias outras habilidades,
verificando seus benefícios e seus pontos negativos. Já <Ing-50> discute especificamente as
habilidades comunicativas para líderes, enquanto <Ing-60> confronta as diferentes visões do meio
acadêmico e corporativo, concluindo que, para este último, a habilidade de comunicação é a mais
importante, enquanto que para o outro ela fica apenas em 7º lugar.
A maior parte dos trabalhos revisados foca especificamente a Engenharia de Requisitos dentro dos
projetos de desenvolvimento de software. Por exemplo, <Ing-174> descreve modelos de requisitos
baseadas na análise da comunicação. Já <Ing-54> faz uma análise de padrões de conversação durante
reuniões de levantamento de requisitos. Enquanto esses trabalhos envolvem o aspecto linguístico,
<Ing-41> é voltado para o aspecto organizacional, com a preocupação de modelar um processo
para controlar as alterações ocorridas nos requisitos durante a sua eliciação. Em <Pt-3>, por sua vez,
temos o foco na Gerência de Projetos e na Gestão da Comunicação.
Como mostra a Figura 5, cerca de 20% dos trabalhos revisados discute alguma evidência de melhoria
na comunicação com o uso de suas propostas. Apesar de ainda não serem maioria, observa-se uma
tendência de prover validação para as propostas em artigos mais recentes, refletindo o crescimento e
a disseminação das práticas experimentais qualitativas da Engenharia de Software Experimental.
5. Conclusões
Este artigo discutiu as principais conclusões e descobertas feitas a partir de uma Revisão Sistemática
da literatura conduzida sobre o tema Comunicação em Projetos de Desenvolvimento de Software.
A partir das análises conduzidas nesse trabalho, foram identificados três grandes aspectos da
comunicação em projetos, capazes de abranger qualquer contexto de comunicação durante o
processo de desenvolvimento de software.
O aspecto linguístico visa uma comunicação efetiva quando um mecanismo de re-alimentação
(ou feedback) é inexistente. Por meio da análise de padrões de conversação, e de técnicas como
eliminações de redundâncias e transformações gramaticais, este aspecto busca obter uma
comunicação clara, completa e não ambígua.
132 WAMPS 2011
Revisão Sistemática Sobre a Comunicação Dentro do Processo de Desenvolvimento de Software
Já o aspecto individual se baseia no fato de que as pessoas são o elemento essencial do processo
de comunicação e, portanto, devem ser instruídas a conseguir uma comunicação efetiva. Para isso,
devem ser desenvolvidas as habilidades de leitura, escrita, fala, escuta, bem como a linguagem nãoverbal, incluindo entonação, gesticulação e postura.
Finalmente, o aspecto organizacional demonstra que fatores culturais e sociais influenciam
fortemente a qualidade e a efetividade da comunicação em uma corporação. Esse aspecto fornece
técnicas de coordenação e dinâmicas de grupo que favorecem o crescimento da liderança e a
proximidade da equipe, aumentando a sua coesão.
As conclusões obtidas da revisão sistemática indicam que o estado da arte sobre a questão da
comunicação dentro do processo de desenvolvimento de software ainda se encontra pouco
desenvolvido, que há bastante espaço para crescimento, principalmente no cenário nacional. A análise dos estudos primários indica, em particular, uma carência de resultados nos aspectos
linguístico e individual da comunicação, já que a maior parte dos trabalhos foca apenas no aspecto
organizacional.
Analogamente, há poucas propostas relacionadas aos assuntos metodologias, dinâmicas e habilidades
de comunicação. Tal fato pode indicar uma tendência de pesquisadores e praticantes da Engenharia
de Software em focar os aspectos tecnológicos e organizacionais do desenvolvimento de software,
desconsiderando algumas vezes avanços e contribuições de áreas como a Linguística e a Psicologia.
Embora um percentual significativo dos trabalhos revisados mencione evidências de melhoria em
comunicação dentro de projetos de software, as evidências apresentadas carecem, em geral, de
embasamento experimental. Há, de fato, uma preocupação com a avaliação da efetividade da
comunicação, mas essa avaliação não tem sido realizada de acordo com os princípios de Engenharia
de Software Experimental. Trata-se, portanto, de uma oportunidade para o desenvolvimento de
pesquisas, demonstrando experimentalmente a validade de técnicas, métodos e ferramentas no
apoio à efetividade da comunicação em projetos de software.
Ao detectar estas questões pouco exploradas da comunicação nos projetos de software, a RS realizada
serve como motivação e base para futuras pesquisas, na busca de propostas e soluções para essas
questões. O fato desta Revisão Sistemática ter sido conduzida por apenas três pesquisadores
associados a um mesmo grupo de pesquisa pode representar uma ameaça à validade das conclusões
aqui apresentadas. Portanto, como extensão imediata deste trabalho, poderia ser feita uma reavaliação
do protocolo por outros pesquisadores da comunidade de Engenharia de Software. Isto permitiria
uma maior segurança quanto aos resultados e conclusões apresentadas neste trabalho.
Por limitações de espaço, apenas uma síntese dos principais aspectos da Revisão Sistemática conduzida
foi apresentada neste artigo. O relatório técnico completo com os detalhes do trabalho realizado se
encontra disponível em [Moraes et al. 2011].
WAMPS 2011 133
Artigos técnicos selecionados
Referências
Biolchini, J.; Mian, P. G.; Natali, A. C. C. and Travassos, G. H. (2005) “Systematic Review in Software
Engineering”. Relatório Técnico – COPPE/UFRJ.
Brereton, P.; Kitchenham, B.; Budgen D.; Turner, M.; Khalil, M. (2007) “Lessons from applying the
systematic literature review process within the Software Engineering domain”. The Journal of
Systems and Software, 80, pp. 571–583.
Brooks, Jr. F. (1995) “The mythical man-month: Essays on Software Engineering”, Addison-Wesley,
Anniversary Edition (2nd Edition), 336 p.
Da Silva, F. Q. B.; Santos, A. L. M.; Soares, S. C. B.; França, A. C. C.; Monteiro, C. (2010) “A critical
appraisal of systematic reviews in software engineering from the perspective of the research
questions asked in the reviews” In: Proc. of ACM-IEEE International Symposium on Empirical
Software Engineering and Measurement.
Standish Group (2009) “Chaos Report”. Apud Eveleens, J and Verhoef, C. (2010) “The Rise and Fall
of Chaos Report Figures”. IEEE Software, pp. 30-36, Jan, 2010.
Jost, A. C. (2006) “What We’ve Got Here Is… Failure to Communicate”. Crosstalk – The Journal of
Defense Software Engineering. Vol 19. No 6.
Kitchenham, B. (2007) “Guidelines for performing Systematic Literature Reviews in Software
Engineering”. Keele and Durham University Joint Report. EBSE 2007-001.
Moraes, T. M.; de Souza, A. S.; de Oliveira, J. L. (2011) “Revisão sistemática sobre a comunicação
dentro do processo de desenvolvimento de software”. Relatório Técnico RT-INF_004-11 – Instituto
de Informática/UFG (www.inf.ufg.br).
Project Management Institute (2008) “A Guide to the Project Management Body of Knowledge”
(PMBOK Guide) – Fourth Edition, PMI, 459 p.
Robbins, S. P. (2005) “Comportamento Organizacional”. 11ª ed. Pearson Prentice Hall.
134 WAMPS 2011
Revisão Sistemática Sobre a Comunicação Dentro do Processo de Desenvolvimento de Software
WAMPS 2011 135
Artigos selecionados sobre ferramentas
Apoio à Medição em um ADS Centrado em
Processos
Talita Ribeiro, Luciana Nascimento, Liken Lima, Carla Reis, Rodrigo Q. Reis
Universidade Federal do Pará – UFPA, Faculdade de Computação – FACOMP
Laboratório de Engenharia de Software – LABES
Avenida Augusto Correa, 1 – Guamá, Belém/PA – CEP 66075-110
{talita,liken}@webapsee.com, {luma,clima,quites}@ufpa.br
Abstract. Software process measurement is considered very important for analyze, predict, monitor,
evaluate and improve the outcomes of software project processes. On the other hand, software process
measurement can be too difficult without the proper support for measurement planning, collecting, analysis
and communication of the results. In this paper we present the functionalities offered by a Process-centered
Software Engineering Environment (PSEE) to support measurement activities and its integration with the
projects enacted by such environment.
Resumo. Medição em processos de software é considerada de vital importância para conhecer, analisar,
prever, monitorar, avaliar e melhorar os resultados dos processos utilizados nos projetos de software. Porém,
Medição pode se tornar uma tarefa onerosa e difícil sem o apoio adequado para o planejamento, coleta de
medidas e a análise e comunicação de resultados. Este artigo apresenta o apoio fornecido às atividades de
Medição em um Ambiente de Desenvolvimento de Software (ADS) Centrado em Processos, o que permite
que os resultados da Medição estejam integrados com as demais informações de projetos armazenadas no
ambiente.
1. Introdução
Medição é considerada um dos fatores cruciais para o sucesso nos programas de melhoria de
processos de software, por estar relacionada com o entendimento, controle, monitoração, predição e
avaliação nos projetos de desenvolvimento e manutenção de software [Dyba 2005]. Contudo, muitas
organizações a consideram uma tarefa complexa e de difícil execução, o que ocasiona dificuldade
em qualificá-la como positiva e mesmo de mantê-la no programa de melhoria dos processos de
desenvolvimento de software das organizações [Gopal 2002].
Nesse contexto, é fundamental conhecer os fatores que de alguma forma auxiliam no sucesso não
só dos programas de melhoria de processos, mas também da própria medição. A utilidade das
medidas nas tomadas de decisão e acompanhamento de metas do projeto e da organização, a
automatização da coleta das medidas e a utilização de uma abordagem de medição alinhada aos
objetivos estratégicos da organização são alguns desses [McGarry et al. 2002],[Florac et al. 1999].
Com o intuito de prover auxílio automatizado às atividades de medição, o ambiente WebAPSEE [Lima
Reis 2003] [Sales et al. 2010] oferece funcionalidades que permitem o planejamento da medição
alinhado às metas da organização, e além disso possibilitam a definição de métricas e coleta de
medidas, geração de indicadores gráficos e registro de análises dos resultados, informações de
contexto e lições aprendidas. Tais funcionalidades são apresentadas no decorrer do presente artigo,
136 WAMPS 2011
Apoio à Medição em um ADS Centrado em Processos
que está organizado como segue: a seção 2 apresenta o ambiente WebAPSEE e suas funcionalidades
para apoio à Medição, a seção 3 indica as limitações do trabalho, bem como possibilidades de
melhorias e trabalhos futuros e, por fim, as considerações finais são feitas na seção 4.
2. Apoio à Medição no ambiente WebAPSEE
O WebAPSEE é um Ambiente de Engenharia de Software Centrado em Processos que possibilita,
de forma automatizada, modelar, definir, executar, gerenciar e reutilizar processos de software. O
diferencial da ferramenta, além da visualização gráfica da modelagem do processo, é a possibilidade
de alteração deste em tempo de execução, permitindo que a realidade do processo seja representada
no ambiente.
O WebAPSEE possui em sua arquitetura cliente/servidor três clientes: um com funcionalidades
específicas para a gerência – Manager Console, onde é possível definir, modelar, reutilizar, planejar
e executar processos de software (Figura 1a) – e os outros dois com funcionalidades específicas
para os desenvolvedores – Task Agenda Desktop (Figura 1b) e Task Agenda Web (Figura 1c), onde
os desenvolvedores identificam quais as suas tarefas, recebem e enviam artefatos e dão feedback
ao gerente através de ações de iniciar, pausar e finalizar uma atividade. O ambiente agrupa
também funcionalidades de apoio a diferentes áreas da Engenharia de Software, como Gerência de
Conhecimento [Oliveira et al. 2010], Reutilização de Processos [Carvalho et al. 2011], Gerência de
Projetos e Gerência de Requisitos [Sales et al. 2010].
Figura 1. O WebAPSEE a) Manager Console b) Task Agenda e c) Task Agenda Web.
WAMPS 2011 137
Artigos selecionados sobre ferramentas
As subseções a seguir detalham as funcionalidades do ambiente WebAPSEE que dão suporte ao
processo de medição em projetos de software. Para fins de organização e melhor entendimento, a
descrição das funcionalidades, partes da arquitetura e os exemplos de utilização serão apresentados
em relação a três fases distintas do processo, a saber: Planejamento da Medição; Coleta dos Dados e
Análise e Comunicação dos Resultados (Figura 2).
Figura 2. Fases do processo de medição.
2.1 Apoio ao Planejamento da Medição
A ferramenta permite o planejamento de medição seguindo uma abordagem descrita em [Nascimento
et al. 2007], que é baseada no Goal-driven Software Measurement [Park et al. 1996]. Para tanto
a ferramenta estabelece dois conceitos distintos para o planejamento de medição: o conceito de
Modelo de Plano de Implementação de Medição (MIPModel) e o de Plano de Implementação de
Medição (MIP) de um projeto.
O MIPModel é um plano de medição que pode ser utilizado como base para o planejamento da
medição em vários projetos e contém definições referentes às necessidades de informação da
organização em relação a seus projetos em geral, a saber: i) metas de negócio; ii) metas de
medição, identificadas pelo nome, objeto de medição, propósito, ponto de vista e ambiente; iii)
questões; iv) indicadores e suas respectivas descrições, procedimentos de análise, tipos de alvo
(atividades, artefatos, agentes, grupos de agentes e recursos), formatos (tabela ou gráfico de pizza,
barra ou linha), operações (desvio, listagem ou distribuição) e métricas, definidas como mostra a
Figura 3a); e v) relatórios de resultados. A organização pode definir um ou mais MIPModels de
acordo com seus critérios, como por exemplo por tipo de projeto.
138 WAMPS 2011
Apoio à Medição em um ADS Centrado em Processos
a
b
FIgura 3. Métricas: a) Definição e b) Coleta.
A Figura 4 ilustra um modelo de classes onde se pode identificar como é o relacionamento dos planos
de medição – modelo e de projeto – com as demais entidades do ambiente WebAPSEE. A diferença
entre um MIP e um MIPModel está no fato de que o MIP é relacionado diretamente a um determinado
projeto de software e faz referência a um MIPModel. O MIP contém, portanto, as definições do
MIPModel que o gerou, as quais não podem ser alteradas, embora definições devido a necessidades
de informação específicas do projeto ao qual o MIP se relaciona possam ser adicionadas.
Figura 4. Planejamento da Medição – Modelos de Classes.
WAMPS 2011 139
Artigos selecionados sobre ferramentas
Outra informação definida no MIP e de fundamental importância para interligar o planejamento da
medição ao processo de desenvolvimento é a seleção dos alvos para coleta das medidas e posterior
geração dos indicadores. Tendo definido um indicador, o usuário poderá selecionar alvos específicos
do projeto (de acordo com o seu tipo de alvo definido) para os quais serão coletadas as medidas
das métricas do indicador. Por exemplo, o usuário poderá cadastrar na ferramenta um indicador
de Desvio de Esforço nas Atividades, identificando como tipo de alvo “Atividade” (vide Figura 5a)
e quais atividades ou tipos de atividades do projeto deverão ter suas medidas coletadas na fase de
Coleta dos Dados – Figura 5b.
Ainda na fase de planejamento, pode-se pré-definir, tanto no MIPModel como no MIP, relatórios para
auxiliar a análise e comunicação dos resultados. É possível estabelecer quais indicadores farão parte
do relatório e se deverão ser exibidos para eles o procedimento de análise, a análise realizada, lições
aprendidas e observações de contexto.
a b Figura 5. Indicador: a) Definição e b) Seleção de alvos.
140 WAMPS 2011
Apoio à Medição em um ADS Centrado em Processos
2.2 Apoio à Coleta, Análise e Comunicação dos Resultados
Para coletar as medidas das métricas identificadas no planejamento da medição, o ambiente
permite que o valor, unidade, período mensurado, agente que coletou a informação, data e
informações de contexto da coleta sejam armazenados na base de medidas do ambiente (vide figura
3b). O ambiente permite ainda que possam ser coletados dados de estimativa das métricas definidas,
assim, esses dados podem ser comparados com os valores reais obtidos, utilizados na operação de
desvio disponibilizada nos indicadores.
Para auxiliar a análise dos resultados, a ferramenta gera automaticamente os indicadores definidos
no planejamento da medição. Apesar da disponibilização de diferentes formatos e operações sobre
os dados dos indicadores, caso o usuário necessite criar outros indicadores ele poderá exportar os
dados coletados no formato de planilha eletrônica, não se limitando, portanto, às funcionalidades
da ferramenta.
Feita a análise dos resultados, pode-se então registrar no ambiente a análise em si, lições aprendidas
e possíveis observações de contexto (Figura 6). Todas essas informações, assim como os relatórios de
resultados planejados, podem ser exportadas e poderão ser utilizadas para comunicar os responsáveis
e usuários da medição (tomadores de decisão).
Figura 6. Análise e exportação dos resultados.
WAMPS 2011 141
Artigos selecionados sobre ferramentas
3. Limitações e Trabalhos Futuros
Apesar das contribuições que a ferramenta pode oferecer às diferentes fases do processo de medição,
algumas melhorias na ferramenta estão sendo realizadas e outras estão planejadas para serem
desenvolvidas futuramente.
A ferramenta aqui apresentada possui limitações quanto à definição operacional de métricas e quanto
à coleta de medidas: é possível definir métricas numéricas e sua faixa de valores válidos, porém a
escala não é claramente definida. Devido a essas limitações estão sendo realizadas modificações
na arquitetura e funcionalidades relacionadas com a base de medidas da ferramenta, estando no
momento da escrita desse artigo em fase de projeto. Como exemplo das melhorias, o novo modelo
proposto permite que uma métrica possa ser definida como subjetiva, com escala nominal ou ordinal,
ou pode ser objetiva, com escala intervalar, absoluta ou razão, que por serem quantitativas podem
ser definidas como métricas base ou derivadas.
Outra importante melhoria identificada é a integração do plano de medição com a máquina de
execução do ambiente. Conforme descrito na seção 1.2, após derivar um MIP a partir de um
MIPModel, o responsável pelo planejamento da medição em um determinado projeto pode fazer os
ajustes necessários (sem remover as definições da organização em relação a metas de negócio, de
medição, questões, indicadores, métricas e relatórios) e deve informar quais elementos específicos
do projeto serão medidos (denominados alvos de medição) para que os indicadores possam ser
gerados automaticamente. A partir daí, o responsável pela definição do processo de desenvolvimento
deve modelar no WebAPSEE Manager-Console as atividades de coleta e análise para os alvos da
medição, devendo também designar os recursos humanos (agentes) para as atividades e planejar
o prazo e o esforço. Como trabalho futuro é pretendido o desenvolvimento de mecanismos
para automaticamente verificar e manter a consistência do plano de medição com o processo de
desenvolvimento do projeto, além de possibilitar que medidas possam ser coletadas diretamente
na agenda dos próprios agentes que estejam produzindo/utilizando o elemento alvo da coleta (ex.:
esforço despendido na atividade).
Atualmente estão sendo elaboradas no contexto de trabalhos acadêmicos do Labes-UFPA propostas
que estendem a ferramenta apresentada, seja em relação ao processo de medição ou apoio dado
através dos dados coletados pela medição, como, por exemplo: coleta automática de métricas de
código [Ribeiro et al. 2011], monitoração de riscos [Silva et al. 2011] e gerência quantitativa de
projetos.
142 WAMPS 2011
Apoio à Medição em um ADS Centrado em Processos
4. Considerações Finais
A ferramenta apresentada no artigo possui grande potencial de auxílio ao processo de Medição,
passando desde o planejamento até a coleta, análise e comunicação dos resultados. Por ser um PSEE
com apoio à execução de processos, a ferramenta possui o diferencial de integrar o processo de
medição ao processo de desenvolvimento de software, permitindo a ligação dos alvos da medição
com as entidades reais do processo de desenvolvimento, evitando que informações da medição e do
processo fiquem dispersas em diferentes ferramentas.
Especificamente em relação ao processo de Medição do MR-MPS [SOFTEX 2011] no nível F, a ferramenta
disponibiliza funcionalidades que trazem benefícios ao atendimento de cada um dos resultados
requeridos pelo modelo, como pode ser visto na Tabela 1. Os trabalhos futuros e atualmente em
andamento, descritos na seção anterior, sinalizam a constante evolução do ambiente em relação ao
tema de medição no suporte à melhoria da qualidade nos projetos de desenvolvimento de software.
Tabela 1. Apoio aos Resultados Esperados de Medição – Nível F MR-MPS.
Resultados
Atendimento
MED 1
A ferramenta possibilita o cadastro de metas de negócio e de medição como apoio ao
planejamento da medição, porém ela não prevê em seu escopo o cadastro de necessidades de informação e nem a priorização destas.
MED 2
O apoio oferecido pela ferramenta permite que as métricas a serem selecionadas
estejam sempre de acordo com as metas de negócio e de medição definidas, uma vez
que a seleção das métricas é baseada no modelo GQ(I)M. Não é previsto, no entanto, o
apoio a priorização das métricas.
MED 3
A funcionalidade de definição de métricas permite o cadastro, dentre outras informações, do procedimento de coleta para cada métrica. Em relação ao procedimento de
armazenamento dos dados, embora não explícito, fica subentendido, já que estes serão
armazenados na base de dados do ambiente.
MED 4
No planejamento de cada indicador é possível definir o procedimento de análise deste
e, por conseguinte, das métricas que o compõe.
MED 5
A funcionalidade de coleta de medidas permite que valores de métricas e informações
de contexto destas sejam associados a entidades do processo. Esses dados podem ser
analisados a partir de indicadores ou de relatórios gerados pela ferramenta.
MED 6
Em seu módulo de análise, a ferramenta permite que, para cada indicador gerado,
observações, análises e lições aprendidas possam ser cadastradas.
MED 7
Com a funcionalidade de planejamento e geração de relatórios de resultados, a ferramenta possibilita agrupar informações de planejamento e análise dos dados conforme
as necessidades da gerência, auxiliando assim a comunicação das informações de
medição armazenadas na ferramenta.
A ferramenta apresentada – de licença BSD (Berkeley Software Distribution) –, e seu manual de
instalação podem ser encontrados no link http://labes.ufpa.br/talita/gqimplan.
WAMPS 2011 143
Artigos selecionados sobre ferramentas
Referências
Carvalho, D., Costa, A., Sales, E., Lima, A., Reis, Q.. (2011) “Apoio à Reutilização de Processos
de Software em um Ambiente de Engenharia de Software Centrado em Processos”. Simpósio
Brasileiro de Qualidade de Software – SBQS, Curitiba.
Dyba, Tore. (2005) “An Empirical Investigation of the Key Factors for Success in Software Process
Improvement”, IEEE Transactions on Software Engineering, Vol. 31, No. 5.
Florac, W. A., Carleton, A. D.. (1999) “Measuring the Software Process: Statistical Process Control for
Software Process Improvement”, Addison Wesley.
Gopal, A., Krishnan, M. S., Mukhopadhyay e T., Goldenson, S. R.. (2002) “Measurement Programs
in Software Development – Determinants of Success”. IEEE Transactions on Software Engineering,
Vol. 28, No. 9.
Lima Reis, Carla A.. (2003) “Uma Abordagem Flexível para Execução de Processos de Software
Evolutivos”. Tese de Doutorado. Porto Alegre: PPGCC-UFRGS.
Lima Reis, C. A.; Reis, R. Q.. (2007) “Laboratório de Engenharia de Software e Inteligência Artificial:
Construção do Ambiente WebAPSEE”. ProQualiti – Qualidade na Produção de Software. Vol. 3,
No. 1, junho de 2007. p. 43-48.
McGarry, J., Card, D., Jones, C., Layman, B., Clark, E., Dean, J. e Hall, F.. (2002) “Practical Software
Measurement: Objective Information for Decision Makers”, Addison Wesley.
Nascimento, L. M. A., Reis, R. Q., Costa, A., França, B. B. N.. (2007) “Uma abordagem para Medição
em um Ambiente de Desenvolvimento de Software Centrado em Processos”. In: CLEI – Conferência
Latino Americana de Informática, Costa Rica.
Oliveira, J., Lima, L., Das Dores, S., Sales, E., Andrade, G., Lima Reis, C.. (2010) “WKM: Uma Ferramenta
para Auxiliar a Gerência de Conhecimento Integrada a um ADS Centrado em Processos”, VI
Workshop Anual do MPS.BR, Campinas.
Park, R. E., Goethert, W. B., Florac, W. A.. (1996) “Goal-Driven Software Measurement – A Guidebook”.
Handbook CMU/SEI-96-HB-002, Pittsburgh, Software Engineering Institute, Carnegie Mellon
University. Disponível em: http://www.sei.cmu.edu.
Ribeiro, M. D. S., Reis, R. Q.. (2011) “Interoperabilidade da gerência de artefato de código com a
execução de processo de software para apoiar o processo de medição”. In: IX Workshop de Teses
e Dissertações em Qualidade de Software, Curitiba.
Sales, E., Sales, M., Costa, A., Lima Reis, C., Reis, R.. (2010) “WebAPSEE Pro: Um Ambiente de Apoio
a Gerência de Processos de Software”, VI Workshop Anual do MPS.BR, Campinas.
Silva, A. R. S., Reis, R. Q.. (2011) “Apoio Automatizado para Avaliação de Riscos Baseado em Dados
Estatísticos de Projetos de Desenvolvimento de Software”. In: IX Workshop de Teses e Dissertações
em Qualidade de Software, Curitiba.
SOFTEX – Associação para Promoção da Excelência do Software Brasileiro. MPS.BR – Guia Geral.
Junho 2011. Disponível em: www.softex.br.
144 WAMPS 2011
Apoio à Medição em um ADS Centrado em Processos
WAMPS 2011 145
Artigos selecionados sobre ferramentas
Controlle: Ferramenta de Apoio à Gerência de
Requisitos
Fernando Nascimento1, Marcus Teixeira1, Marcello Thiry2 e Alessandra Zoucas2
Khor Tecnologia da Informação
Rod. SC 401, Km 01 n 600 – Ed. Alfama SL 403, João Paulo
Cep: 88030-911 – Florianópolis – SC – Brasil
{fernando, marcus} @khor.com.br
1
(II-MPS.BR) Incremental Tecnologia em Informática Ltda.
R. Delminda Silveira 740/1002 Agronômica
Cep: 88025-500 – Florianópolis – SC – Brasil
{thiry, zoucas}@incremental.com.br
2
Abstract. Under the Incremental Tecnologia consultancy, an implementing insitution (II-MPS), the Khor Tecnologia da Informação has evaluated the software Controlle adherence over the managing requisite process
over the MR-MPS:2011, level G. On this perspective, this article presents an analysis describing how each
expected result is achieved and evidenced, consolidating the processes and identifying improvement opportunities at the software.
Resumo. A empresa Khor Tecnologia da Informação, sob consultoria dos especialistas da instituição implementadora (II-MPS) Incremental Tecnologia, avaliou a aderência da ferramenta Controlle ao processo de
Gerência de Requisitos do nível G do MR-MPS:2011. Nessa perspectiva, apresenta-se uma análise descrevendo como cada resultado esperado é alcançado e evidenciado, consolidando os processos e identificando
oportunidade de melhorias na ferramenta.
1. Introdução
De acordo com os níveis de maturidade estabelecidos em modelos de referência de processos reconhecidos como o MR-MPS [SOFTEX 2011] e o CMMI-DEV [SEI 2010], a Gerência de Requisitos (GRE) é
um processo que deve ser implementado desde o início de um programa de melhoria de processos.
Isto ressalta a relevância deste processo para a qualidade de software.
Um estudo sobre a continuidade da execução dos processos de software em empresas avaliadas no
MR-MPS destaca que empresas enfrentam dificuldades em manter a rastreabilidade bidirecional entre requisitos e produtos de trabalho [ALMEIDA et al. 2011]. Outro fator discutido sobre o processo
GRE foi que tal dificuldade pode estar associada a pouca disponibilidade de ferramentas automatizadas para garantir a rastreabilidade bidirecional de modo efetivo [ALMEIDA et al. 2011]. O resultado
de outra pesquisa corrobora com a discussão de que para a melhoria de processo de software ser
efetiva é preciso contar com ferramentas que apóiem as atividades previstas nos processos [MENDES
et al. 2010]. Atualmente, a abordagem mais utilizada por empresas que visam executar a rastreabilidade bidirecional ainda é usar aplicativos de planilha eletrônica. Entretanto, algumas empresas
tem buscado abordagens automatizadas para reduzir o esforço empregado na implementação e
continuidade da execução de processos de software como a GRE [MARQUES et al. 2010].
146 WAMPS 2011
Controlle: Ferramenta de Apoio à Gerência de Requisitos
No sentido de apoiar a execução do processo GRE, a ferramenta Controlle foi idealizada. Ela permite
identificar, detalhar, registrar mudanças, organizar e rastrear os requisitos e outros produtos de trabalho produzidos durante o desenvolvimento de um projeto, proporcionando menor esforço e maior
eficiência à equipe do projeto. Este artigo tem por objetivo, apresentar uma avaliação da aderência
das funcionalidades desta ferramenta às práticas do processo GRE do modelo MR-MPS [SOFTEX
2011]. A avaliação da aderência da ferramenta foi realizada pela empresa Khor TI com o apoio da instituição implementadora (II-MPS) Incremental Tecnologia durante as consultorias de implementação
do nível G do modelo. Neste período, novas funcionalidades foram desenvolvidas e oportunidades
de melhoria identificadas visando dar maior suporte aos resultados esperados.
O artigo é organizado da seguinte forma: a seção 2 apresenta as principais funcionalidades, formas
de licenciamento e modos de acesso à ferramenta; a seção 3 descreve como os resultados esperados
podem ser atingidos com o uso da ferramenta e as oportunidades de melhoria; por último a seção 4
apresenta as considerações finais.
2. Principais Funcionalidades do Controlle
O Controlle é uma ferramenta flexível, projetada para adaptar-se ao processo e à metodologia definido
por cada empresa ou projeto, seja ela ágil ou tradicional. É possível definir atributos e configurar os
artefatos que serão produzidos durante o ciclo de vida do projeto, possibilitando o gerenciamento
dos produtos de trabalho.
Através da sua utilização é possível responder as seguintes questões:
• Qual a fonte de um determinado requisito ou mudança?
• Por que o requisito existe?
• Quais outros requisitos estão relacionados a ele?
• Como o requisito se relaciona com o sistema?
• Quais produtos de trabalho são afetados por um determinado requisito ou mudança?
As principais funcionalidades do sistema são:
• Gerenciar e desenvolver requisitos de forma colaborativa, integrando Equipe Técnica, Gerente
de Projetos e Cliente.
• Formar uma base de conhecimento e histórico de informações que será utilizada durante todo
o ciclo de vida do produto ou projeto.
• Gerenciar processo de mudança: solicitação, acompanhamento, análise de impacto e registro
do plano de implementação.
• Manter a rastreabilidade vertical e horizontal entre requisitos e produtos de trabalho, estabelecendo níveis de decomposição e dependência entre os produtos.
• Obter informações sobre o andamento do projeto, mostrando através de gráficos e tabelas a
evolução do desenvolvimento dos requisitos.
WAMPS 2011 147
Artigos selecionados sobre ferramentas
• Controlar versões dos produtos e projetos, identificando os requisitos implementados, bugs
corrigidos e mudanças disponibilizadas em cada versão.
A ferramenta Controlle pode ser licenciada nas seguintes modalidades:
• Licença de uso permanente: nesta modalidade, a licença não expira e o cliente tem a possibilidade de contratar os serviços de suporte e atualização à parte.
• SaaS (Software as a Service): esta modalidade é indicada para clientes que não queiram ou não
tenha condições de manter a aplicação em uma infraestrutura própria. O pagamento pode ser
mensal, semestral ou anual e inclui suporte e atualização;
O valor do licenciamento é calculado através do número de usuários nomeados (com cadastro ativo
no sistema) ou acesso simultâneo. Uma versão de demonstração está disponível pelo link: http://
controlle.khor.com.br (empresa: controlle; usuário: wamps; senha: 28wamps10).
3. Aderência ao Processo de Gerência de Requisitos
3.1. GRE1 – O entendimento dos requisitos é obtido junto aos fornecedores de
requisitos
A Figura 1 apresenta uma parte da tela de cadastro de requisitos, possibilitando a inclusão de
atributos personalizados, imagens, links e arquivos externos, além de identificar também o fornecedor do requisito. Apenas fornecedores previamente cadastrados no projeto podem ser vinculados
aos requisitos.
Figura 1. Registro do Requisito.
148 WAMPS 2011
Controlle: Ferramenta de Apoio à Gerência de Requisitos
Os requisitos identificados devem ser agrupados em uma baseline de requisitos. Uma baseline
identifica o escopo de um projeto, produto, ou até mesmo iterações. Este agrupamento pode ser
feito no registro do requisito ou na tela de cadastro de baseline que é parcialmente apresentada na
Figura 2.
O registro de aceite dos requisitos é obtido diretamente na ferramenta. Basta alterar o status da
baseline para, por exemplo, “Aprovada pelo Fornecedor de Requisitos” e solicitar que o fornecedor
de requisitos registre seu comprometimento com a lista de requisitos definida na baseline. Este
registro gera um log com as informações do usuário autenticado e é uma comprovação que aquele
usuário concorda com a mudança de status. A ferramenta dispõe de um relatório com o histórico
destas informações. O ciclo de vida dos requisitos e de uma baseline pode ser configurado pelo
usuário, adequando-se a realidade de cada empresa ou projeto.
Figura 2. Registro de Baseline.
Para este resultado foi identificado como oportunidade de melhoria disponibilizar um histórico
mostrando as alterações que foram feitas nos requisitos, possibilitando comprovar a evolução do seu
entendimento.
3.2. GRE2 – Os requisitos são avaliados com base em critérios objetivos e um
comprometimento da equipe técnica com estes requisitos é obtido
Neste resultado a equipe técnica irá avaliar os requisitos e, quando aprovado, o status da baseline
deverá ser alterado para “Aprovada pela Equipe Técnica”. Após esta aprovação, todos os integrantes
da equipe deverão registrar seu comprometimento.
A oportunidade de melhoria identificada no GRE1 (histórico de alterações do requisito) também
seria útil para o GRE2, permitindo identificar as modificações que foram feitas em decorrência da
avaliação do requisito. Além disso a ferramenta poderia permitir o cadastro dos critérios de aceitação
de requisitos definidos pela unidade organizacional.
WAMPS 2011 149
Artigos selecionados sobre ferramentas
3.3. GRE3 – A rastreabilidade bidirecional entre os requisitos e os produtos de
trabalho é estabelecida e mantida
A rastreabilidade pode ser mantida de duas maneiras na ferramenta: na própria tela de cadastro
de produto de trabalho apresentada na Figura 3, ou de modo visual, pelo diagrama de produtos
apresentado na Figura 4.
A ferramenta permite relacionar um produto de trabalho a qualquer outro produto: requisitos,
protótipos de tela, casos de uso, classes, tabelas, arquivos de código, ata de reunião, questionário
etc. Além disso, podem ser relacionados produtos de outros projetos. Também é possível definir o
tipo (composição, indireto, dependência, etc.) e a direção do relacionamento.
Figura 3. Produtos Relacionados.
No diagrama os tipos de produto de trabalho (requisito, protótipo de tela, caso de uso, código fonte,
tabela) são apresentados em formas e cores diferentes. Também é possível diferenciar rastreabilidade
horizontal e vertical, visualizar informações detalhadas dos produtos e navegar entre eles. Estas
funcionalidades auxiliam na análise de impacto e também na identificação de novos relacionamentos.
Figura 4. Diagrama – Rastreabilidade Visual.
150 WAMPS 2011
Controlle: Ferramenta de Apoio à Gerência de Requisitos
3.4. GRE4 – Revisões em planos e produtos de trabalho do projeto são realizadas
visando a identificar e corrigir inconsistências em relação aos requisitos
Para apoiar o atendimento desta prática, a equipe pode, durante as revisões, utilizar um checklist
juntamente com os mecanismos de rastreabilidade para identificar o relacionamento entre requisitos
e outros produtos de trabalho. Analisando os relacionamentos, é possível definir quais produtos
deverão ser alterados. Isto é possível porque a ferramenta permite o registro de qualquer produto
envolvido no processo.
Neste resultado esperado foi identificado como uma possibilidade de melhoria disponibilizar um
relatório apontando prováveis inconsistências entre os produtos de trabalho (ex.: código fonte
sem requisito, caso de uso sem requisitos). Este relatório também poderia ser utilizado para o
acompanhamento das ações corretivas das inconsistências encontradas.
3.5. GRE5 – Mudanças nos requisitos são gerenciadas ao longo do projeto
A ferramenta Controlle apóia o ciclo de vida de uma mudança de requisitos, desde a solicitação
ao acompanhamento de sua implementação. Conforme pode ser observado na Figura 5, além
das informações básicas (data, descrição, justificativa e objetivo), o registro da mudança permite
identificar o solicitante e o requisito que está sendo alterado (se aplicável).
Figura 5. Gerenciamento de Mudança.
WAMPS 2011 151
Artigos selecionados sobre ferramentas
Para auxiliar na análise de impacto a equipe pode utilizar o diagrama de produtos apresentado
anteriormente na Figura 4. Nesta tela é possível navegar entre os produtos e neste momento identificar
e registrar quais serão impactados pela mudança. Feito isto, a equipe deve descrever o impacto em
cada produto conforme apresentado na Figura 6, e ainda em outros itens como cronograma, custos,
esforço, etc.
Figura 6. Produtos Impactados.
Todo o ciclo de vida da mudança (proposta, aceita, recusada, concluída) também é registrado na
ferramenta, permitindo o acompanhamento e gerando um histórico das decisões. Quando a mudança
é aceita pela equipe todos os envolvidos devem registrar seu comprometimento. Além disto, deve
ser gerada uma nova versão dos requisitos que foram afetados, criando assim um histórico de
informações do requisito – incluindo a rastreabilidade – sobre antes e depois de uma mudança. Caso
a mudança tenha gerado um novo requisito, é possível identificar isto na ferramenta, enriquecendo
ainda mais a base de informações do requisito e da mudança.
3.6. RAP4 – (A partir do nível F) Medidas são planejadas e coletadas para
monitoração da execução do processo e ajustes são realizados
As medidas planejadas para monitoração e execução do processo de GRE podem ser coletadas
diretamente na ferramenta. É possível obter medidas relacionadas ao ciclo de vida de qualquer
produto de trabalho, como por exemplo: quantidade de requisitos por status, solicitações de mudança
por status, quantidade de requisitos já codificados. Estas medidas também podem ser utilizadas
para apoiar decisões de ajustes no processo e podem ser exibidas em forma de tabela ou gráfico,
conforme apresentado na Figura 7.
152 WAMPS 2011
Controlle: Ferramenta de Apoio à Gerência de Requisitos
Figura 7. Indicadores de Execução do Processo.
Desta forma, foi verificado que a utilização da ferramenta Controlle pode apoiar a construção de um
repositório de medidas desde os primeiros níveis de maturidade do modelo, permitindo demonstrar
aderência à algumas práticas do processo de Medição do nível F de maturidade e ainda apoiar
futuramente a realização das práticas do processo Gerência Quantitativa no nível B do modelo.
3.7. Avaliação da Aderência
A Tabela 1 apresenta o grau de aderência da ferramenta aos resultados esperados do processo de
GRE e para o atributo de processo RAP4 do nível F do modelo MPS.
Tabela 1. Avaliação da Aderência da Ferramenta Controlle.
Resultados Esperados
Avaliação
GRE 3 e 5
J – Aderente
GRE 1, 2 e 4
K – Aderente com oportunidades de melhoria
Atributos de Processo
RAP 4 (nível F)
Avaliação
J – Aderente para o processo de GRE
4. Considerações Finais
Este trabalho apresentou a ferramenta Controlle como uma alternativa para a implementação do
processo GRE do modelo de referência MPS. Além do atendimento dos resultados esperados deste
processo, também foi verificado que a ferramenta ainda apoia o resultado de atributo de processo
RAP 4, uma vez que ela oferece medidas para GRE. Embora não tenha sido discutido anteriormente
pelo artigo, a ferramenta Controlle ainda apoia o processo de Gerência de Configuração, uma vez
que oferece mecanismos para estabelecer e manter baselines de requisitos. Vale ressaltar que a
ferramenta não possui integração com outras de gerência de configuração e também não atende
a todos os resultados esperados desse processo. Um estudo mais detalhado será publicado em
trabalhos futuros.
WAMPS 2011 153
Artigos selecionados sobre ferramentas
Foram identificadas oportunidades de melhoria nos resultados GRE 1, 2 e 4, mas o atendimento
integral já pode ser realizado com o apoio de email e checklists. Os resultados esperados de GRE no
nível G de maturidade são alcançados sem esforço adicional, já que um dos objetivos da ferramenta
é auxiliar a equipe no dia a dia do projeto.
A evolução da aderência do Controlle já está em andamento com a implementação das oportunidades
de melhoria identificadas e também com a participação de outras empresas interessadas no uso da
ferramenta. Pretende-se, a longo prazo, criar soluções que atendam a outras áreas de processo,
como Projeto e Construção, Validação, Verificação, Garantia da Qualidade, entre outros.
Como trabalhos futuros propõem-se a avaliação da aderência da ferramenta a outros processos do
modelo – Gerência de Requisitos, Gerência de Configuração e Medição. Outra proposta seria um
comparativo com outras ferramentas disponíveis no mercado.
Referências
ALMEIDA, C. D. A., MACEDO, T. C., ALBUQUERQUE A. B., (2011). A continuidade da execução dos
processos de software em empresas avaliadas no MPS.BR. pp. 135-149, In: X SBQS, Curitiba – PR.
MARQUES, A. B., RABELO, J., VIEIRA, S. C., CONTE T. (2010). Um Estudo Experimental sobre
Abordagens de Apoio à Rastreabilidade de Requisitos. pp. 158-165 In: VI WAMPS, Campinas – SP.
MENDES F. F., FERNANDES, P. G., OLIVEIRA, J. L., MOTA, C. C., MARTINS, M. D. S., NUNES, R. S.
(2010), Análise de Ferramentas para Apoio à Gerência de Projetos e Gerência de Requisitos de
Software. pp. 148-157 In: VI WAMPS, Campinas – SP.
SEI (2010) SOFTWARE ENGINEERING INSTITUTE. CMMI for Development (CMMI-DEV), Version 1.3.
Technical Report CMU/SEI-2010-TR-033, 2010.
SOFTEX (2011). MPS.BR – Melhoria de Processo do Software Brasileiro, Guia de Implementação –
Parte 1. 2011. Disponível em www.softex.br/mpsbr.
154 WAMPS 2011
Controlle: Ferramenta de Apoio à Gerência de Requisitos
WAMPS 2011 155
Artigos selecionados sobre ferramentas
Portal EduES 2.0: Uma Ferramenta para Apoiar
a Gerência de Reutilização no Domínio de
Educação em Engenharia de Software
Hudson Borges1, Rafael do E. Santo2,3, Rodrigo Santos2
Heitor Costa1, Cláudia Werner2
Departamento de Ciência da Computação, Universidade Federal de Lavras
COPPE/UFRJ, Universidade Federal do Rio de Janeiro
3
Serviço Federal de Processamento de Dados, SERPRO
{hborges}@sistemas.ufla.br, {res, rps, werner}@cos.ufrj.br, [email protected]
1
2
Resumo. Com o crescimento de ambientes colaborativos para o desenvolvimento centrado em plataformas
e na formação de ecossistemas de software, a reutilização se destaca como disciplina estratégica nos mais
diversos domínios de aplicação. Dado que o processo de educação e treinamento em Engenharia de Software
(ES) constitui um desafio real e possui grande demanda por pesquisa e desenvolvimento de soluções, este
artigo apresenta o Portal EduES 2.0, uma ferramenta para apoiar processo de gerência de reutilização no
domínio de educação em ES. Além disso, uma análise do Portal EduES 2.0 à luz do Modelo MPS mostra que a
ferramenta implementa o processo Gerência de Reutilização (GRU), contribuindo como um exemplo prático
para a comunidade MPS.
1. Introdução
Com a emergência de sistemas de sistemas e de sistemas intensivos de software em uma indústria que
trabalha integrada a grandes plataformas [Bosch, 2009], organizam-se os chamados ecossistemas de
software (ECOSs)1. Entender como manter uma plataforma viva, seja proprietária ou não, depende
de compreender o processo de gerência e desenvolvimento de seus componentes, sejam estes
arquiteturais ou de conteúdo, a fim de manter a sua comunidade viva e o seu modelo de negócio
funcionando, dado que qualquer oscilação impacta a indústria e/ou ambientes colaborativos [Santos
& Werner, 2011]. Dessa forma, processos de Reutilização de Software ganham foco nos diversos
domínios de aplicação e em modelos de qualidade [Santos et al., 2010].
A fim de explorar a reutilização no domínio de educação em ES, o Projeto EduES [Santos et al., 2011]
foi criado com o objetivo de pesquisar repositórios de componentes, especificamente objetos de
aprendizagem (OAs) e relatos de experiência, o que resultou no desenvolvimento do Portal EduES. A
versão 1.0 do portal consiste de um ambiente web para apoiar a pesquisa colaborativa interinstitucional
e em larga escala para caracterizar a educação em ES no Brasil utilizando experimentação [Santo et
al., 2009]. Resultados desta caracterização e levantamentos da literatura evidenciaram a necessidade
de construir repositórios de soluções para melhorar a educação em ES [Lethbridge et al., 2007]. Mas
Um ECOS é um conjunto de atores funcionando como uma unidade que interage com um mercado distribuído entre software e serviços,
juntamente com as relações entre estas entidades, frequentemente apoiadas por uma plataforma tecnológica ou por um mercado comum, e
realizadas pela troca de informação, recursos e artefatos [Jansen et al., 2009 apud Santos & Werner, 2011].
1
156 WAMPS 2011
Portal EduES 2.0: Uma Ferramenta para Apoiar a Gerência de Reutilização no Domínio de Educação em Engenharia de Software
a existência de um repositório por si não promove a reutilização. Um requisito para explorar seu
potencial é a emergência de uma plataforma colaborativa apoiada por um processo de gerência de
reutilização [Bosch, 2009].
Visando ampliar o escopo do Portal EduES de um ambiente de experimentação para um ambiente
de reutilização, este artigo apresenta o Portal EduES 2.0, uma plataforma para apoiar processo de
gerência de reutilização no domínio de educação em ES. Esta plataforma resulta da incorporação
de um repositório à arquitetura do ambiente web, com uma base de dados de componentes (i.e.,
OAs e relatos de experiência) e de produtores e consumidores (professores e pesquisadores), e com
mecanismos de armazenamento, publicação, busca e recuperação [Borges et al., 2011]. Apesar de
essencialmente poder ser uma ferramenta estruturante para o domínio de educação de qualquer área
do conhecimento, as pesquisas realizadas foram direcionadas pela área de ES. O artigo apresenta a
seguinte estrutura: a Seção 2 contextualiza o Portal EduES e sua evolução; a Seção 3 resume a sua
arquitetura e implementação; a Seção 4 discute a aderência do Portal EduES 2.0 ao processo GRU do
Modelo MPS; a Seção 5 exibe exemplos; trabalhos relacionados são listados na Seção 6; e a Seção 7
conclui o artigo.
2. O Portal EduES e a sua Evolução para a Versão 2.0
O Portal EduES nasceu com o objetivo principal de oferecer estrutura de comunicação a educadores
e pesquisadores, facilitando a colaboração, a coordenação e a cooperação (CSCW) rumo à
organização de um corpo de conhecimento em educação em ES no Brasil [Santo et al., 2009]. Ou
seja, o Portal EduES estava focado em operacionalizar duas etapas iniciais que visam caracterizar
quais são os problemas, desafios, soluções existentes e peculiaridades do cenário nacional frente
ao internacional, do processo de ensino e aprendizagem de uma área do conhecimento: revisão
sistemática (pesquisadores caracterizam a educação em ES com base na literatura) e pesquisa de
opinião (pesquisadores verificam este conhecimento na prática, com educadores). Para isso, foram
implementados módulos que apoiam os envolvidos nas atividades realizadas (Figura 1): (i) Fórum;
(ii) Chat; (iii) Mensagens; (iv) Listas de Discussão; (v) Grupos (Áreas de Pesquisa, com gerenciador de
arquivos e versões); (vi) Estudos Experimentais; (vii) Gerenciador de Eventos de Educação em ES; e (viii)
Gerenciador de Publicações.
Novas características foram incorporadas ao Portal EduES a fim de transformá-lo em um repositório
onde existe a oportunidade da publicar, classificar, testar, avaliar e reutilizar (i.e., compor e gerar)
conteúdos educacionais relacionados aos resultados da caracterização apoiada pela versão 1.0,
considerando a inexistência de infraestruturas para tal até então. Neste repositório, os conteúdos
armazenados, isto é, os componentes, são distinguidos como OAs e relatos de experiência. Com foco
na reutilização, os OAs representam entidades autocontidas e reusáveis que podem ser claramente
utilizadas para aprendizagem, educação e treinamento [Teodoro et al.,2008], e os relatos consistem
de trocas de experiências entre educadores e pesquisadores na forma de coleções de tópicos em
páginas web (e.g., Wiki’s) [Hiebert et al., 2002]. O formato de compartilhamento destas experiências
permite que elas sejam sempre revisadas ou melhoradas, podendo ser ligadas a um OA. Neste sentido,
torna-se ainda mais evidente a necessidade de um mecanismo que realize a gerência de reutilização
desses componentes.
WAMPS 2011 157
Artigos selecionados sobre ferramentas
Partindo deste pressuposto, foram implementados módulos para que estes requisitos fossem
satisfeitos: (i) cadastro de OAs: módulo responsável por gerir este processo desde a sua solicitação
de aceitação à classificação, certificação, liberação, manutenção e eventual descontinuidade do
OA enviado por pesquisadores; (ii) busca e recuperação de OAs: módulo responsável pela busca e
recuperação de OAs dentro do repositório do Portal EduES 2.0; (iii) gerenciamento de OAs: módulo
responsável por gerir OAs tanto por parte dos usuários (i.e., OAs cadastrados por pesquisadores e/ou
adquiridos por educadores) como pelo sistema (administrador); e (iv) Wiki EduES: módulo responsável
por gerir relatos de experiência, implementado por um componente externo agregado ao Portal
EduES 2.0, chamado JAMWiki [JAMWiki, 2011].
3. Arquitetura e Implementação do Portal EduES 2.0
A arquitetura do Portal EduES é mostrada na Figura 1 por um conjunto de componentes (versão
1.0) e por um diagrama (versão 2.0), onde: o componente Portal EduES 1.0 representa a estrutura
original, o componente Wiki EduES é adaptação do componente JAMWiki para tratar o módulo de
relatos de experiência e o componente Gerenciamento de OAs foi desenvolvido para que seja possível
realizar os processos de gerência do ciclo de vida dos OAs, isto é, armazenamento, publicação, busca
e recuperação.
Figura 1. Módulos do Portal EduES 1.0 e Diagrama de Componentes do Portal EduES 2.0.
O componente Gerenciamento de OAs, cujo diagrama de classes conceitual é mostrado na Figura 2,
foi projetado para apoiar as atividades necessárias do repositório. A classe ObjetoDeAprendizagem
representa o OA publicado. A classe ObjetoDeAprendizagemMetadados representa o modelo
de metadados adotado para classificar o OA, baseado no padrão LOM [IEEE, 2002]. A classe
ObjetoDeAprendizagemArquivo representa o arquivo que os usuários podem adquirir (i.e.,
componente em si). A classe ObjetoDeAprendizagemFormulario faz um phrase do arquivo xml
enviado e representa o formulário que o usuário dará o feedback específico após o seu uso.
ObjetoDeAprendizagemComentario e ObjetoDeAprendizagemDenuncia representam os comentários
e denúncias feitos a um OA, respectivamente. Por fim, ObjetoDeAprendizagemDownloads armazena
os dados das aquisições de cada usuário.
Em termos de tecnologia, o Portal EduES é uma aplicação web desenvolvida na tecnologia JEE (Java
Enterprise Edition) a partir do framework JBoss Seam [JBoss, 2011], que reúne algumas características
158 WAMPS 2011
Portal EduES 2.0: Uma Ferramenta para Apoiar a Gerência de Reutilização no Domínio de Educação em Engenharia de Software
que permitem a fácil integração de tecnologias para desenvolvimento das visões do usuário, da
persistência dos dados e das regras de negócio, sendo assim considerados por muitos como um
framework de desenvolvimento unificado, completo e sofisticado. O componente Wiki EduES foi
desenvolvido tendo como base o componente JAMWiki [JAMWiki, 2011] que oferece funcionalidades
ricas e extensíveis baseada em Wiki. O servidor de aplicações adotado é o JBoss AS 5.0.1 [JBoss AS,
2011] e o banco de dados utilizado é o MySQL.
Figura 2. Diagrama de classes do componente Gerenciamento de OAs.
4. Gerência de Reutilização no Portal EduES 2.0
Pelo enfoque dado pelos novos componentes que fazem parte do Portal EduES 2.0, uma análise da
plataforma frente às orientações para implementação de um processo de reutilização demonstra
que a sua concepção pode apoiar o Processo GRU do Modelo MPS [SOFTEX, 2011], cujo propósito é
gerenciar o ciclo de vida de ativos reutilizáveis estabelecendo, para isso, cinco resultados esperados.
Para verificar cada resultado, foram analisadas as características e comportamentos dos novos
componentes do portal:
GRU1: conforme discutido na Seção 2, o conceito de componente no escopo do Portal EduES 2.0
consiste de OAs e relatos de experiência no domínio de educação em ES. Partindo desta definição de
componente, uma estratégia para o gerenciamento desses ativos e de recursos, artefatos e informações
relacionados deve ser estabelecida. Os módulos herdados da versão 1.0 (Figura 1) permitem aos envolvidos
(educadores e pesquisadores) se comunicarem e coordenarem a construção de um documento textual
que represente essa estratégia, a ser arquivado e versionado em um Grupo (Seção 2) sumarizando os
critérios que regem o ciclo de vida dos componentes. Este documento pode ser mantido de maneira
integrada, e periodicamente revisto e atualizado por discussões e reuniões on line usando recursos do
portal (módulos de fórum, listas de discussão e mensagens), ou registrando o histórico/contexto da
alteração (quando efetuada), além do documento estar disponível de forma transparente no portal.
WAMPS 2011 159
Artigos selecionados sobre ferramentas
GRU2: com a incorporação do repositório, concretiza-se o estabelecimento e manutenção de um
mecanismo de armazenamento e recuperação dos ativos reutilizáveis no Portal EduES 2.0, atendendo,
assim, a este resultado esperado.
GRU3: Uma vez definida a base de OAs e relatos de experiência, o Portal EduES 2.0 dá suporte às
atividades e relações mantidas entre papéis produtores e consumidores, no caso, (i) pesquisadores
publicando OAs e educadores os recuperando, e (ii) professores publicando relatos de experiência e
pesquisadores os analisando e utilizando para desenvolver novos OAs. Desta forma, é mantido ao
longo do tempo um mapa de reutilização no Portal EduES 2.0 , ou seja, uma tabela que registra os
contratos entre produtores e consumidores sobre o uso de OAs e de relatos de experiência.
GRU4: Além do mapa de reutilização, a manutenção e controle do ciclo de vida das liberações de
OAs e de relatos de experiência são realizados. Ou seja, os estados de um OA são registrados e
ajustados de acordo com as informações armazenadas no Portal EduES 2.0, permitindo responder
questões como “quem?”, “quando?”, “por quê?” e “como?”. Isso também se torna viável por meio
dos valores dos atributos das categorias do modelo de metadados para classificação de componente,
além dos relacionamentos entre os componentes, tais como requer, é parte de, é correção de, é
evolução de, faz referência a e é baseado em [Borges et al., 2011].
GRU5: De posse do mapa de reutilização e considerando as manutenções periódicas dos componentes
publicados no Portal EduES 2.0, o módulo de Mensagens da versão 1.0 (Figura 1) foi derivado para
notificar os envolvidos sobre as atualizações do repositório na forma de mensagens encaminhadas
ao e-mail particular. Por exemplo, caso um novo componente publicado tenha algum relacionamento
com outro componente já adquirido no portal (GRU4), os consumidores (professores) deste recebem
informações referentes a esta ligação entre os componentes (sobretudo no caso é correção de). Por
outro lado, os produtores (pesquisadores) recebem informações sobre o estado do seu componente
ao longo do ciclo de vida segundo manutenções periódicas baseadas nos critérios.
5. Exemplo de GRU no Portal EduES 2.0
Conforme discutido, o Portal EduES 2.0 apresenta um conjunto de módulos integrados que permite
o gerenciamento de todo o ciclo de vida do componente educacional dentro do repositório. Do lado
do produtor, o módulo de cadastro é ativado pela Solicitação de Cadastro de Novo OA, onde
deve ser informado pelo pesquisador o nome do OA e uma descrição simples e objetiva (conceito
do componente). Este passo é necessário para evitar que sejam enviados arquivos fora do escopo
do repositório (GRU1). A seguir, o administrador aciona a opção Solicitações de Aceitação de
OA, onde a solicitação passa pela aplicação dos critérios de aceitação realizada pelo administrador
do portal. Caso a solicitação seja aceita, o terceiro passo, intitulado Cadastro do OA, é liberado ao
pesquisador. É necessário que o pesquisador preencha um conjunto de atributos do OA agrupados
por categorias, que correspondem à classificação provida pelo modelo de metadados adotado [IEEE,
2002] [Borges et al., 2011]. Além disso, o pesquisador deve enviar o arquivo compactado contendo
o OA e um manual de utilização, e ainda um arquivo no formato XML correspondente ao formulário
com informações específicas de feedback que os consumidores deste OA devem responder. Assim,
o último passo é definido como Solicitação de Classificação e Certificação do OA e é realizado
pelo administrador pela aplicação dos critérios de certificação e de classificação, visando verificar a
160 WAMPS 2011
Portal EduES 2.0: Uma Ferramenta para Apoiar a Gerência de Reutilização no Domínio de Educação em Engenharia de Software
sua conformidade com a solicitação realizada. Quando todos os campos estiverem preenchidos e os
arquivos enviados corretamente, este será liberado (Figura 3) e disponibilizado para acesso a todos os
usuários no portal (GRU2), notificando os interessados quando for o caso (GRU4 e GRU5).
Figura 3. Tela Meus OAs, na perspectiva do produtor (pesquisador).
Por sua vez, do lado do consumidor, o módulo de busca e recuperação (GRU2) é dividido em dois
submódulos: busca simples e busca avançada. A busca simples é feita pela combinação de três
campos, título, palavras-chave e área de conhecimento (SWEBoK), sendo retornado ao usuário
o resultado da combinação direta dos campos e também resultados relacionados a cada campo
separadamente, em duas abas. Na busca avançada, a consulta é realizada através do preenchimento
de campos relativos aos atributos das categorias do modelo de metadados (Figura 4). O resultado
também é retornado das duas formas como na busca simples. Partindo destes resultados, é possível
que o usuário analise os dados dos OAs e adquira aquele de interesse, criando uma instância no
mapa de reutilização (GRU3), além de poder adaptá-lo ou integrá-lo de acordo com a licença que
rege o OA e, mais tarde, avaliá-lo qualitativamente e preencher o formulário de feedback específico
requerido pelo pesquisador.
Do lado do administrador, o módulo de gerenciamento de OAs está dividido em três submódulos
que são: gerência de OAs cadastrados, gerência de OAs adquiridos, gerência geral de OAs e gerência
administrativa de OAs. O módulo gerência de OAs cadastrados gerencia todos os OAs enviados por
determinado pesquisador, permitindo visualizar suas informações, e.g., situação (liberado, pendente,
bloqueado, excluído ou descontinuado), número de consumidores, total de consumidores que
forneceram feedback específico e dados agregados destes e, ainda, ações como editar dados do
OA, descontinuar o OA etc. O módulo gerência de OAs adquiridos gerencia aquisições e feedback
específico realizados por todos os consumidores, onde é possível realizar um levantamento de todos
os professores que utilizaram um determinado OA, assim como seus perfis. O módulo gerência geral
de OAs gere as atividades de interação dos envolvidos com os OAs, como avaliações (comentários
e graus), rastreabilidade de OAs e denúncia de irregularidades em OAs. Por fim, o modulo
gerência administrativa de OAs é exclusiva de uso do administrador visando analisar denúncias de
irregularidades, bloquear OAs que estejam irregulares e descontinuar OAs de qualquer pesquisador.
Para o compartilhamento de experiências entre os membros do portal, foi anexada a Wiki EduES à
estrutura original do portal . O acesso é possível somente a usuários cadastrados no portal, sendo possível
criar, comentar, revisar ou até melhorar qualquer experiência já adicionada. Na Figura 5, é apresentada
WAMPS 2011 161
Artigos selecionados sobre ferramentas
a situação onde um usuário criou a página ProblemasSolucoesDesafiosNoEnsinoReutilizacaoSoftware
onde pretende-se discutir problemas, soluções e desafios no ensino de Reutilização de Software. A
partir deste simples comentário, é possível que uma série de discussões sejam geradas, fazendo com
que novos estudos sejam instanciados e que este simples comentário seja revisado e melhorado por
outros usuários.
Figura 4. Tela Busca Avançada, na perspectiva do consumidor (professor).
Figura 5. Wiki EduES.
162 WAMPS 2011
Portal EduES 2.0: Uma Ferramenta para Apoiar a Gerência de Reutilização no Domínio de Educação em Engenharia de Software
6. Trabalhos Relacionados
O projeto CESTA teve origem na UFRGS com propósito de organizar todo conteúdo educacional,
geralmente OAs, gerados pelos cursos oferecidos [Tarouco et al., 2003]. O projeto OE3 (Objetos
Educacionais para Engenharia de Estruturas) visa servir de repositório de OAs com foco em engenharia
de estruturas [Sheer & Gama, 2004]. Apesar de positivas, as iniciativas falharam ao oferecer um
mecanismo que permita ao pesquisador (ou quem publicou o OA) ter um feedback adequado de seus
consumidores. Além disso, não oferecem um canal para compartilhamento das experiências no uso
destes materiais. O Portal EduES 2.0 procura sanar estes problemas através da possibilidade de criação
de um formulário de feedback personalizado de cada OA e uma Wiki para que os pesquisadores e
educadores possam compartilhar experiências obtidas tanto no processo de desenvolvimento quanto
de uso dos OAs.
7. Conclusão
Este artigo apresentou o Portal EduES 2.0, uma ferramenta para apoiar a gerência de reutilização no
domínio de educação em ES. Conforme a análise do Portal EduES 2.0 realizada à luz do Modelo MPS,
foi mostrado que a ferramenta implementa o processo GRU, contribuindo como um caso prático para
a comunidade MPS e estendendo as pesquisas da biblioteca Brechó [Santos et al., 2011], que foca
em componentes e serviços de software, para o domínio de educação em ES. Com a incorporação
de um repositório, esta ferramenta se transforma em uma plataforma para realização de estudos de
caracterização de uma área, evoluída para apoiar a organização de um corpo de conhecimento em
educação em ES. Isso permite que professores e pesquisadores apliquem reutilização em pesquisas
educacionais baseadas em OA e relato de experiência. O portal encontra-se em http://lab3d.coppe.
ufrj.br/portaledues. Como trabalhos futuros, pretende-se executar um estudo de usabilidade junto a
professores e pesquisadores simulando atividades que exploram GRU, além de explorar o processo
Gerência de Recursos Humanos (GRH), considerando a Gestão de Conhecimento.
Agradecimentos
Os autores agradece m ao CNPq/FAPERJ pelo apoio financeiro.
Referências
Borges, H.S. et al. (2011) “Gerenciamento de Objetos de Aprendizagem para o Ensino de Engenharia
de Software no Portal EduES Brasil”. In: IV FEES, II CBSoft, São Paulo.
Bosch, J. (2009) “From Software Product Lines to Software Ecosystem”. In: Proceedings of 13th SPLC,
San Francisco, pp. 1-10.
Hiebert, J., Gallimore, R., Stigler, J.W. (2002) “A Knowledge Base for the Teaching Profession: What
Would It Look Like and How Can We Get One?”. Educational Research 31(5): 3-15.
WAMPS 2011 163
Artigos selecionados sobre ferramentas
IEEE Learning Technology Standards Committee (2002) “Draft Standard for Learning Object Metadata
(IEEE 1484.12.1-2002)”. 44p.
JBoss (2011). “JBoss Seam Framework”. Disponível em <http://seamframework.org>.
JBoss AS (2011). “JBoss Application Server”. Disponível em: <http://www.jboss.org/jbossas>.
JAMWiki (2011) “JAMWiki Java Wiki Engine”. Disponível em: <http://jamwiki.org/ >.
Lethbridge, T.C. et al. (2007) “Improving Software Practice through Education: Challenges and Future
Trends”. In: Proc. of the 29th ICSE, The Future of SE, Minneapolis, pp. 12-28.
Santo, R.E. et al. (2009) “Portal EduES Brasil: Um Ambiente para Apoiar a Pesquisa em Educação em
Engenharia de Software no Brasil”, In: II FEES, SBES, Fortaleza, pp. 33-40.
Santos, R., Marinho, A., Silva, M., Werner, C., Murta, L. (2010) “Brechó 2.0: Uma Ferramenta para
Apoiar a Gerência de Reutilização”. In: Anais do VI WAMPS, Campinas, pp. 174-182.
Santos, R.P., Werner, C.M.L. (2011) “Gerência e Desenvolvimento de Sistemas de Informação na
Realidade dos Ecossistemas de Software”. In: Anais do VII SBSI, Salvador, pp. 20-25.
Santos, R. et al. (2011) “Supporting Software Engineering Education through a Learning Objects and
Experience Reports Repository”. In: Proc. of the 23nd SEKE, Miami, pp. 272-275.
Sheer, S., Gama, C.L.G. (2004) “Learning Objects for a Teaching and Learning Network in Structural
Engineering”, In: Proceedigns of the X International Conference on Computing in Civil and Building
Engineering, Weimar, 12p.
SOFTEX (2011) “Guia Geral do MPS.BR – Modelo MPS e Modelo de Referência”.
Tarouco, L.M.R., Fabre, M.C.J.M., Tamusiunas, F.R. (2003) “Reusabilidade de Objetos Educacionais”.
Revista Novas Tecnologias na Educação 1(1): 1-11.
Teodoro, G., Carvalho, M. B., Comassetto, L. S. (2008) “Compartilhamento e Reusabilidade de
Objetos de Aprendizagem”. In: V Congresso Bras. de Ensino Superior a Distância, pp. 1-10.
164 WAMPS 2011
Portal EduES 2.0: Uma Ferramenta para Apoiar a Gerência de Reutilização no Domínio de Educação em Engenharia de Software
WAMPS 2011 165
Artigos selecionados sobre ferramentas
Aderência do IBM Rational Team Concert ao MRMPS – Uma análise com ênfase em gerência de
configuração
João Condack
PrimeUp – Instituição Implementadora MPS.Br
Rio de Janeiro – RJ – Brasil
[email protected]
Abstract. This paper describes how IBM Rational Team Concert (RTC) can be compliant to MPS reference
model. It presents the model elements supported by the tool and its features. The configuration management
discipline expected results are detailed while other results and attributes of the model are grouped by
functionality. Practical experiences were taken into account in the analysis and conclusions.
Resumo. Este artigo descreve como a ferramenta IBM Rational Team Concert (RTC) pode ser aderente
ao modelo de referência MR-MPS. Os elementos do modelo ao qual a ferramenta apóia e as respectivas
funcionalidades são apresentadas. Os resultados esperados da disciplina de gerência de configuração são
detalhados enquanto outros resultados e atributos do modelo são agrupados por funcionalidade. Experiências
práticas foram levadas em conta na análise e conclusões.
1. Introdução
Frequentemente projetos de software exigem que sejamos mais rápidos e produtivos, atendendo
aos desafios do mercado. Isto faz com que áreas de TI invistam em qualidade, capacidade de
monitoramento e governança, e garantam flexibilidade e velocidade para as demandas através de
orçamentos cada vez mais reduzidos. Paralelamente, novas interpretações para boas práticas de
engenharia de software tem clamado por formas mais ágeis e colaborativas de trabalho sem abrir
mão da qualidade e da previsibilidade.
Neste contexto, avaliamos a aderência de uma ferramenta orientada a gestão ágil e colaborativa do
ciclo de vida de aplicações com relação ao modelo de referência MR-MPS. A PrimeUp é Instituição
Implementadora do MPS-Br e também parceira IBM, portanto, foi possível levar em consideração a
experiência de profissionais da PrimeUp em projetos internos e externos que envolveram tanto o IBM
Rational Team Concert (RTC) quanto o MR MPS.
O restante deste artigo está organizado da seguinte forma: a seção 2 apresenta a ferramenta IBM
Rational Team Concert. Na seção 3 são analisados os elementos do modelo ao qual a ferramenta
apóia e as respectivas funcionalidades. Por fim, na seção 4, são descritas as conclusões deste trabalho.
166 WAMPS 2011
Aderência do IBM Rational Team Concert ao MR-MPS – Uma análise com ênfase em gerência de configuração
2. O IBM Rational Team Concert
As novas ferramentas IBM Rational foram desenvolvidas utilizando como base a plataforma Jazz
[IBM, 2011 a]. Jazz é um projeto e plataforma de código aberto para transformar como as pessoas
trabalham juntas visando entregar maior valor e desempenho em seus projetos de software. Seu
principal resultado é uma arquitetura – apresentada na Figura 1 – que disponibiliza serviços que
dão suporte a colaboração, tais como: painéis de informação, registro de projetos e equipes, busca,
segurança, notificações de eventos e integração com IDEs Eclipse, Visual Studio e Web [IBM, 2011 b].
Figura 1. Arquitetura Jazz. (Fonte: IBM)
O Rational Team Concert foi a primeira ferramenta desenvolvida utilizando a estrutura da plataforma
Jazz. O RTC implementa a disciplina de Gerência de Configuração, possibilitando o desenvolvimento
distribuído e o controle de versão dos artefatos de projetos bem como as atividades dos envolvidos.
2.1. Principais funcionalidades
Estão disponíveis no RTC funcionalidades de criação, acompanhamento, planejamento, administração
de itens de trabalho; painel de controle via web; versionamento de artefatos; gestão de baselines;
definição, execução e registro de builds realizados. Uma lista detalhada de funcionalidades pode ser
obtida em [IBM, 2011 c].
2.2. Acesso a ferramenta
O RTC pode ser obtido no endereço http://jazz.net onde o servidor e os clientes (para Eclipse e Visual
Studio) podem ser copiados. Existem diferentes formas de utilização: Sandbox: com qualquer cliente
é possível acessar o servidor disponível para testes residente no site do Jazz; Instalação própria: o
RTC é instalado em um servidor próprio e clientes são utilizados para acessá-lo; JazzHub: iniciativa
que permite a educadores utilizar servidores RTC na nuvem para realização de atividades acadêmicas.
Um mesmo cliente pode acessar distintos servidores.
WAMPS 2011 167
Artigos selecionados sobre ferramentas
Para se conectar a um servidor é necessário uma licença. As licenças de uso podem ser nomeadas
(direcionadas a um determinado usuário) ou flutuantes (usuários compartilham um “pool” de licenças).
Existem ainda distinção entre licenças de acordo com perfis de uso (ex. interessados, contribuidores,
desenvolvedores). Detalhes sobre os tipos e funcionamento do mecanismo de licença podem ser
encontrados em [IBM, 2011 d]. Vale observar são oferecidas até 10 licenças gratuitamente.
3. Aderência ao Modelo de Referência MR-MPS
A aderência será descrita através do apoio que o RTC oferece as práticas que visem atender aos
resultados esperados pelo modelo [SOFTEX, 2011] . Esta seção está dividida em duas partes. A
primeira relata os achados relacionados a gerência de configuração, principal disciplina atendida
pela ferramenta e, portanto, com análise mais detalhada. A segunda parte apresenta análises
referentes a outras disciplinas de forma geral e agrupadas pelo tratamento dado pela ferramenta.
O aprofundamento das análises da segunda parte, embora importantes, não estão no escopo deste
artigo.
3.1. Disciplina de Gerência de Configuração
GCO 11: O RTC implementa os conceitos necessários para a institucionalização de um sistema
de gerência de configuração. Possui controlador de versões, realiza a gerência de mudanças,
permite manter a rastreabilidade entre mudanças e artefatos (através do conceito de “conjunto de
alterações”), bem como criar baselines, oferecer suporte ao desenvolvimento em paralelo (criação de
ramos), atender a políticas otimista e pessimista de checkout e permite a gerência de construções e
liberações.
GCO 2: O RTC oferece formas de identificar nos projetos quais são os itens de configuração, permite
organizá-los em componentes. É possível tratar também quais itens não estarão sob a gerência de
configuração, mantendo-os em outras estruturas da ferramenta como anexos a itens de trabalho ou
projetos.
Na Figura 2 é apresentada a esquerda, entre outros elementos, um projeto aberto (SEGUI), seus
componentes (Core, SEGUIServer, SEGUIWeb) e um ramo (SEGUI Team Stream) criado com baselines
de dois dos componentes. A direita está a definição do ramo e uma visão dos itens de configuração
de um dos componentes selecionados.
GCO 3 e GCO 4: O RTC oferece o controle formal para a criação de baselines de componentes, bem
como o fechamento de versões de um conjunto de componentes (snapshots). Indica também quais
dos snapshots serão marcados como release (entrega do produto).
Também possui visões para a consulta dos itens de configuração, bem como os históricos de baselines
e snapshots. Todo acesso a ferramenta é realizado e configurado de acordo com mecanismos de
identificação de usuários e autorização por papéis.
Itens do MR-MPS como resultados esperados e atributos de processos estão identificados através dos códigos derivados do modelo. Por exemplo:
“GCO 1” refere-se ao resultado esperado “Um Sistema de Gerência de Configuração é estabelecido e mantido” da disciplina de Gerencia de
Configuração (GCO)
1
168 WAMPS 2011
Aderência do IBM Rational Team Concert ao MR-MPS – Uma análise com ênfase em gerência de configuração
Figura 2. Projetos, componentes, ramos e itens de configuração.
Figura 3. Histórico de baselines.
A Figura 3 mostra o histórico das baselines geradas a partir de builds de um ramo do projeto (Baselines
for Build in SEGUI Team Stream).
GCO 5: O RTC oferece visões para acessar o histórico de modificações de um item de configuração,
controlar as modificações de um item de configuração através de um fluxo de trabalho implementado
em um item de trabalho e oferece a rastreabilidade de um item de trabalho com as modificações
realizadas nos diversos itens de configuração envolvidos. Um item de trabalho é um elemento da
ferramenta que possui dados e um fluxo de trabalho associados. Também possui um tipo que o
caracteriza frente ao seu uso, como por exemplo, solicitação de mudança, tarefa, defeito, entre
outros. É um recurso bastante flexível da ferramenta, permitindo customizações.
WAMPS 2011 169
Artigos selecionados sobre ferramentas
A Figura 4 sinaliza a primeira entrega do arquivo “.classpath” para o repositório de itens
versionados. O item pertence ao componente “SEGUIServer”.
Figura 4. Controle de modificações em itens de configuração.
A Figura 5 mostra um item de trabalho do tipo defeito (Defect) e no detalhe a rastreabilidade através de links para os conjuntos de alterações (change sets).
Figura 5. Item de trabalho com rastreabilidade para conjunto de alterações.
170 WAMPS 2011
Aderência do IBM Rational Team Concert ao MR-MPS – Uma análise com ênfase em gerência de configuração
GCO 6: O RTC oferece visões para controlar a liberação dos itens de trabalho e baselines.
Os seguintes elementos e comandos são utilizados:
Fluxos (Streams): Visões do repositório versionado que contém itens de
configuração organizados em componentes. São utilizados para implantar
políticas de ramificação.
Espaços de Trabalho do Repositório (Repository Workspaces): Residem no Servidor e referenciam componentes definidos em um fluxo. São espaços intermediários entre o repositório e as estações de trabalho. Permitem
o trabalho isolado ou compartilhamento entre usuários.
Espaços de Trabalho Local (Local Workspaces): Residem na estação de
trabalho local do usuário. Possuem cópias controladas pela ferramenta de
versões específicas de artefatos onde o trabalho é realizado.
Carregar (Load): Copia o conteúdo do espaço de trabalho do repositório
para o espaço de trabalho local.
Figura 6. Elementos
e comandos para
controle dos itens de
configuração.
(Fonte: IBM)
Registrar Entrada (Check-in): Copia arquivos alterados do espaço de trabalho local para o espaço no repositório
Entregar (Deliver): Copia as alterações do espaço de trabalho do repositório para o fluxo.
Aceitar (Accept): Copia alterações do fluxo para os espaços de trabalho do
repositório e local
A Figura 7 apresenta a interface de uma definição de build responsável pela liberação das baselines
e itens de configuração. As definições de build determinam quais componentes serão liberados e é
possível configurar quais os responsáveis pela liberação. Na parte inferior da figura está o histórico
com todas as liberações registradas.
Figura 7. Definição de um build e seu histórico.
WAMPS 2011 171
Artigos selecionados sobre ferramentas
A Figura 8 mostra o resultado de um build. Neste painel é possível verificar os pacotes gerados,
testes que foram executados, as baselines dos componentes envolvidos na construção, as atividades
trabalhadas para as entregas, as modificações realizadas.
Figura 8. Resultado de um build.
GCO 7: O RTC permite realizar comparações entre baselines, possui rastreabilidade entre itens de
trabalho e itens de configuração, histórico de alterações e visualização dos itens que compõem
uma determinada baseline ou build. Todas estas funcionalidades podem apoiar as atividades de
auditoria previstas em um processo definido. Alem disso, auditorias podem ser programadas, revistas
e aprovadas através de itens de trabalho caracterizados para este propósito.
3.2. Apoio a outros itens do modelo de referência
GPR 1 e GPR2: Trata-se da definição do escopo do projeto e do detalhamento e dimensionamento
de tarefas. Um escopo pode ser representado de diversas formas, dentre elas, por uma estrutura
analítica do projeto (EAP). O RTC permite definir hierarquia de items de trabalho, os quais podem
representar tanto marcos do projeto e atividades quanto tarefas simples. O esforço do trabalho pode
ser registrado utilizando pontos de história (story points) ou tempo estimado.
GPR 3 e DFP 4: Estes resultados tratam da definição e manutenção de ciclos de vida de projeto. O
RTC permite a criação e reutilização de modelos de processos. Os modelos apóiam na implementação
destes ciclos de vida permitindo, entre outras coisas, a definição padrões para: fases, iterações,
templates de itens de trabalho, comportamentos e restrições sobre operações. Estes padrões são
aplicados a cada projeto criado utilizando um modelo de processo selecionado.
GRE 5, GQA 3, GQA 4, GPR 18 e GPR 19: De modo geral estes resultados abordam a identificação
de mudanças (ou problemas) e a gestão de ações para o devido acompanhamento. GRE 5 trata da
gestão de mudanças nos requisitos ao longo do projeto. GQA 3 e GQA 4 dizem respeito a problemas,
172 WAMPS 2011
Aderência do IBM Rational Team Concert ao MR-MPS – Uma análise com ênfase em gerência de configuração
não-conformidades e ações corretivas no âmbito de auditorias de qualidade. GPR 18 e GPR 19
abordam problemas, análises e ações corretivas no escopo da gerência do projeto. O RTC permite
criação de itens de trabalho específicos para solicitações de mudança, desvios (issues) e tarefas o
que permite a identificação dos itens e gestão de ações corretivas em qualquer versão dos ativos de
software. Internamente em um item de trabalho existe o mecanismo de aprovações que viabiliza o
direcionamento das ações corretivas para níveis superiores e o envolvimento das partes interessadas.
Este envolvimento também pode ser obtido através da funcionalidade de assinatura de um item de
trabalho, onde o assinante passa a receber automaticamente informações sobre o item assinado (por
e-mail, rss ou pop-up).
GPR 6, GPR 15 e a disciplina de GRI: Os tipos de itens “Risco” e “Ação de Mitigação” permitem
criação de itens de trabalho específicos para identificação e acompanhamento dos riscos e ações
associadas, o que apóia a gestão riscos nos projetos.
GPR 9, RAP 12 e RAP 13: O resultado esperado e os atributos de processo envolvem a gerência
de configuração respectivamente para dados relevantes do projeto e para produtos de trabalho dos
processos do modelo de referência. Uma vez que a ferramenta fornece um sistema de gerência de
configuração completo, por consequência também apóia estes itens.
GPR 5, GPR 13 e GPR 14: Estes resultados de gerência de projetos abordam, entre outros pontos, o
estabelecimento, manutenção e monitoramento de elementos como cronogramas, marcos, pontos
de controle e recursos humanos. Estes pontos podem ser definidos, controlados e acompanhados
no RTC através do encadeamento de itens de trabalho do tipo “tarefa” e do tipo “marco”, os
quais possuem estruturas para estimativa e contabilização de duração, esforço e datas. Os recursos
humanos no RTC podem ser associados aos itens de trabalho e terem suas alocação organizada de
acordo com a distribuição de tempo disponível entre distintos projetos.
GPR 16: Sobre o envolvimento das partes interessadas no projeto isto pode ser alcançado na ferramenta
de diversas maneiras. Os itens de trabalho têm registro de seus criadores, executores e assinantes. Os
interessados podem assinar também resultados de consultas, de construções e eventos de equipes.
Estes relacionamentos permitem que a ferramenta notifique por e-mail, rss ou pop up o assinante
quando algum evento ou mudança ocorre. Outra funcionalidade que permite o envolvimento da
equipe são os painéis customizáveis que permitem a troca de informações, relatórios, indicadores
sobre os projetos. Fóruns, chats e comunicação por voz também são possíveis no RTC.
4. Conclusões
A qualidade dos profissionais e a solução ferramental adotada em uma implementação do modelo,
traz retorno abrangente de qualidade. Especialmente na disciplina de gerência de configuração, o
uso de ferramentas se caracteriza como peça fundamental.
O RTC mostrou que, além de prover um sistema completo e integrado de gerência de configuração,
sua flexibilidade para expansão, seus elementos de conhecimento já embutidos (como modelos de
processo e tipos de itens de trabalho) e a arquitetura da plataforma, compõem uma base para outras
práticas de engenharia de software. Assim a ferramenta passa de um nível fundamental de uso para
WAMPS 2011 173
Artigos selecionados sobre ferramentas
outro superior que agrega diferencial técnico, permitindo a institucionalização e a integração com
outras disciplinas, como gerência de projetos, gerência de riscos e garantia da qualidade.
Foi percebido também que, dado o alto volume de funcionalidades e procedimentos envolvidos, além
da capacitação específica na ferramenta e nas disciplinas envolvidas, faz-se necessário a elaboração
colaborativa de um guia de uso. Tal guia indica e orienta como, dentre as várias possibilidades, a
ferramenta deve ser utilizada para atender aos processos da organização.
Um ponto não abordado neste artigo mas que merece atenção futura é a integração do RTC com
outras ferramentas de engenharia de software. Esta conexão é propiciada pela plataforma Jazz
e permite que uma composição de softwares compartilhem dados e serviços de modo a atender
outras disciplinas como requisitos, testes, reuso, solução técnica e gestão de portfólio de forma
unificada. Outro trabalho futuro seria, semelhante a gerência de configuração, analizar a ferramenta
exclusivamente sob a ótica de gerência de projetos, disciplina atendida pelo RTC de forma abrangente.
Referências
[IBM, 2011 a] IBM – About Jazz, agosto 2011. Disponível em http://jazz.net/about/
[IBM, 2011 b] IBM – Team awareness, agosto 2011. Disponível em http://jazz.net/projects/rationalteam-concert/features/team-aware
[IBM, 2011 c] IBM – Rational Team Concert Features , agosto 2011. Disponível em http://jazz.net/
projects/rational-team-concert/features
[IBM, 2011 d] IBM – Licensing in the Rational solution for Collaborative Lifecycle Management (CLM)
2011, agosto 2011. Disponível em https://jazz.net/library/article/548
[SOFTEX, 2011] ASSOCIAÇÃO PARA PROMOÇÃO DA EXCELÊNCIA DO SOFTWARE BRASILEIRO –
SOFTEX. MPS.BR – Guia Geral:2011, junho 2011. Disponível em www.softex.br
174 WAMPS 2011
Aderência do IBM Rational Team Concert ao MR-MPS – Uma análise com ênfase em gerência de configuração
WAMPS 2011 175
Artigos selecionados sobre ferramentas
Apoio aos Processos de Gerência de Requisitos
e Verificação e Validação em um Ambiente
Integrado
Giselle T. de Almeida, Michelle M. F. Neto, Bruno A. Ramos, Jonnathan dos S. Carvalho,
Mara R. dos S. Barcelos, Simone V. Silva, Aline P. V. de Vasconcelos
Projeto QUALI-EPT – Instituto Federal Fluminense (IFF)
Rua Dr. Siqueira, 273 – Parque Dom Bosco – CEP 28030-130 – Campos dos Goytacazes – RJ – Brasil
{galmeida,mneto,bazevedo,joncarv,mrbarcelos, simonevs,apires}@iff.edu.br
Abstract. This paper presents a tool set available in an integrated environment to partially support MPS.
Br Requirements Management, Verification, and Validation processes. From its use, it is possible to maintain
actors, requirements, business rules, glossary, use cases, test plans and test cases. In addition to defining
traceability between these work products, the tools set allows the automatic creation of test cases from use
cases. The main goals are: documents standardization in an integrated environment, evaluation support of
change impact, automation of test cases generation and productivity increase.
Resumo. Este artigo apresenta um conjunto de ferramentas disponíveis em um ambiente integrado para
apoiar parcialmente os processos de Gerência de Requisitos, Verificação e Validação do MPS.Br. O seu
uso possibilita a manutenção de atores, requisitos, regras de negócio, glossário, casos de uso, planos de
teste e casos de teste. Além disso, define a rastreabilidade entre estes produtos de trabalho e permite a
criação automática de casos de teste a partir de casos de uso. Os principais objetivos são: a padronização de
documentos em um ambiente integrado, apoio à avaliação do impacto de mudanças, a automatização da
geração de casos de teste e o aumento da produtividade.
1. Introdução
A importância crescente da tecnologia no cotidiano da sociedade e das organizações tem
impulsionado continuamente o desenvolvimento de soluções que facilitem a construção de sistemas
computacionais considerados de qualidade [Pressman, 2007].
De acordo com Pressman (2007), “uma compreensão completa dos requisitos de software é
fundamental para um bem-sucedido desenvolvimento de software”. Para Sommerville (2003), a
Engenharia de Requisitos (ER) é o processo que envolve todas as atividades para criação e manutenção
de requisitos do sistema. Ainda neste contexto, Guedes (2008) descreve o levantamento de requisitos
como uma atividade da ER onde o engenheiro de software tenta compreender as necessidades do
usuário e o que ele espera que o sistema realize, ao passo que a análise de requisitos é entendida
como uma atividade da ER que objetiva determinar se as necessidades dos usuários foram entendidas
da maneira correta.
De forma similar, os processos de Verificação e Validação (V&V) são definidos por Sommerville (2003)
como aqueles que visam assegurar que o software cumpre suas especificações e atende às necessidades
dos clientes; destacando, para isto, as técnicas de inspeção e teste. A inspeção é uma técnica estática
176 WAMPS 2011
Apoio aos Processos de Gerência de Requisitos e Verificação e Validação em um Ambiente Integrado
que não requer a execução do sistema, pois analisa e verifica apenas suas representações; ao passo
que o teste é uma técnica dinâmica que trabalha com uma versão executável do sistema. Embora os
testes sejam executados após a liberação do código, suas atividades podem ser realizadas desde o
início do ciclo de desenvolvimento. Os casos de testes podem ser especificados assim que os artefatos
necessários estiverem prontos [Pezzè e Young, 2008].
Portanto, quando bem sucedidos, tanto as atividades da ER quanto os processos de V&V conduzem à
obtenção de diversos benefícios como a redução do retrabalho e a satisfação dos clientes em relação
às soluções desenvolvidas.
O Projeto Qualidade de Software Aplicada à Educação Profissional e Tecnológica – QUALI-EPT (2011)
é responsável pela implantação da qualidade de software nos projetos da Rede Nacional de Pesquisa e
Inovação em Tecnologias Digitais – RENAPI (2011), segundo as diretrizes do MPS.Br (2011) – Melhoria
de Processo do Software Brasileiro. Para isto, o QUALI-EPT interage e atua junto a cada projeto,
adequando-o inicialmente ao Nível G (Parcialmente Gerenciado) do MR-MPS, implementando os
processos de Gerência de Projetos (GPR) e Gerência de Requisitos (GRE) com êxito. Já os processos
de Gerência de Configuração (GCO) e Medição (MED) do Nível F (Gerenciado) do MR-MPS têm sido
parcialmente implementados. Por fim, devido à necessidade de executar as atividades de testes e
inspeção nos projetos, os processos de Verificação (VER) e Validação (VAL) do Nível D (Largamente
Definido) do MR-MPS também vêm sendo parcialmente atendidos.
Apesar do MPS.Br estabelecer os resultados esperados por processo, os meios para atendê-los não
são determinados. Diante disto, o QUALI-EPT tem desenvolvido abordagens com apoio ferramental
para a adequação a estes processos, entre elas a abordagem suportada pelas ferramentas Fermine
e WiseTest, apresentadas neste artigo. A Fermine [Almeida et al. 2010] apóia o processo GRE,
permitindo a criação e manutenção dos itens da ER (atores, requisitos, regras de negócio, casos de uso
e glossário) e a definição da rastreabilidade entre eles. Já a WiseTest permite a criação e manutenção
de plano de testes e a geração automática de casos de testes (CDTs) a partir da especificação de
casos de uso (CDUs). As ferramentas foram desenvolvidas, de forma integrada, como plugins de um
ambiente colaborativo de código-aberto [Redmine, 2011], criado e mantido sob a licença GPL (GNU
General Public License v2). Como os projetos da RENAPI envolvem equipes distribuídas no Brasil,
foi necessária a integração das ferramentas em um único ambiente, proporcionando um ganho de
produtividade e a padronização dos documentos produzidos.
O restante do artigo está organizado da seguinte forma: a Seção 2 apresenta a ferramenta Fermine;
a Seção 3 apresenta a ferramenta WiseTest; a Seção 4 apresenta as ferramentas no contexto do MPS.
Br; a Seção 5 apresenta os trabalhos relacionados; e a Seção 6 apresenta as conclusões e os trabalhos
futuros.
2. Fermine: Ferramenta de Apoio ao Processo de Gerência de
Requisitos
A Fermine é uma ferramenta de apoio ao processo de Gerência de Requisitos (GRE) do MPS.Br, capaz
de realizar a manutenção de diversos artefatos que contemplam a Engenharia de Requisitos (ER) como:
atores, requisitos (funcionais e não-funcionais), regras de negócio, glossário, casos de uso etc. Além
disso, permite a associação entre estes produtos de trabalho, definindo a rastreabilidade entre eles.
WAMPS 2011 177
Artigos selecionados sobre ferramentas
A ferramenta disponibiliza um conjunto de templates eletrônicos que padronizam e otimizam o
preenchimento de documentos da ER. Um exemplo é a especificação de casos de uso, onde é possível
definir pré-condições, fluxos de eventos, pós-condições, exceções etc., além de associar atores, regras
de negócio e requisitos. Na descrição do fluxo principal, para cada passo criado, é possível definir uma
mensagem que será exibida pelo sistema, se for o caso. Para isto, o especificador pode selecionar
mensagens que já foram criadas anteriormente ou criar novas mensagens. A inclusão de fluxo
alternativo ou de exceção é feita a partir da escolha do passo de origem baseado no fluxo principal
previamente informado. Além disso, todos os passos dos fluxos são numerados automaticamente,
seguindo um padrão de identificação unívoca. Os casos de uso incluídos (includes) e estendidos
(extends) também podem ser associados ao caso de uso especificado. Neste caso, a única diferença
entre eles, é que para os casos de uso estendidos, além de informar o passo do fluxo principal que
dá origem à associação, também é preciso descrever a condição necessária à ocorrência da extensão.
Outro destaque é a descrição resumida do caso de uso, onde os termos do glossário são exibidos como
links que permitem consultar suas definições. É possível ainda no caso de uso, adicionar imagens dos
protótipos das telas e associar tabela de especificação de dados. Cabe ressaltar que todos os dados
informados na tabela de dados durante a especificação dos casos de uso servirão de insumo para
ferramenta de testes, descrita na seção seguinte, para geração automática dos casos de teste.
Figura 1. Rastreabilidade entre um caso de uso e demais artefatos na Fermine.
178 WAMPS 2011
Apoio aos Processos de Gerência de Requisitos e Verificação e Validação em um Ambiente Integrado
Em relação aos demais artefatos, a Fermine faz a manutenção de requisitos funcionais e nãofuncionais, possibilitando a inclusão de novos tipos de requisitos não-funcionais além dos previamente
cadastrados. Quanto aos atores, durante sua criação, é possível definir sua interface de comunicação
com o sistema (ICS), informando inclusive novos tipos de ICS além dos já existentes. A definição da
ICS para cada ator será utilizada futuramente para calcular métricas referentes ao caso de uso. Por
isso, para cada novo tipo de ICS criada é preciso definir sua complexidade, associada implicitamente
a uma escala numérica de valores. Além disso, é permitido definir se o ator possui associação do tipo
generalização com outro ator, herdando assim todas suas demais relações com outros artefatos. Por
fim, o ator representa um artefato reutilizável, que depois de criado, pode estar associado a um ou
mais projetos no ambiente.
A fim de se adequar ao MPS.Br, a ferramenta permite ainda definir a rastreabilidade entre os artefatos
mantidos, sendo útil na avaliação dos impactos que mudanças nos requisitos podem ocasionar e
apoiando a identificação de inconsistências, conforme ilustra a Figura 1.
3. WiseTest: Ferramenta de Apoio aos Processos de Validação e
Verificação
As funcionalidades da ferramenta WiseTest estão relacionadas principalmente com as etapas de
planejamento e projeto de testes. Para facilitar o planejamento dos testes, a ferramenta permite
a inclusão e a manutenção do plano de testes. Esse artefato, segundo Rios (2007) é o documento
criado no planejamento como referência para a execução dos testes e pode ser usado como forma
de comunicação junto ao cliente.
O plano de testes contempla diversos campos para apoiar a tarefa de planejamento. Um exemplo é
o campo “Abordagem do Teste” que pode ser usado para armazenar detalhes sobre as atividades de
teste, como os tipos de testes que serão considerados, as ferramentas e técnicas que serão utilizadas.
Da mesma forma, recursos utilizados na validação e verificação poderão ser descritos através do
campo “Necessidades de Ambientes”. Rios (2007) destaca que muitos autores consideram como
necessidades de ambientes, recursos como software, hardware, pessoal etc.
A primeira versão da ferramenta inclui no plano de testes um cronograma simplificado para
estabelecimento de atividades e prazos. Esse documento será devidamente relacionado ao
planejamento gerado pela Ferramenta de Gestão Integrada [Silva et. al. 2011] desenvolvida para
adequação ao processo GPR. Além disso, o plano de testes é integrado à Fermine, permitindo associar
casos de uso (CDUs). Dessa forma, a WiseTest pode gerar os casos de teste (CDTs) automaticamente
via leitura desses CDUs. Essa funcionalidade é uma das principais contribuições da WiseTest,
possibilitando um ganho de produtividade em relação à especificação de testes.
Na geração automática, os passos dos fluxos dos CDUs são lidos e convertidos em passos dos CDTs.
Para obter o resultado esperado dos CDTs é feita uma conversão das pós-condições do fluxo principal
e dos fluxos alternativos. Igualmente, os fluxos de exceção são lidos e as mensagens exibidas nesses
fluxos informam os resultados esperados para os casos de teste de exceção.
A WiseTest lê ainda a tabela de especificação de dados dos CDUs mantidos pela Fermine, gerando
assim CDTs considerando obrigatoriedade, tipos de dados pré-definidos, tamanho dos campos etc.
WAMPS 2011 179
Artigos selecionados sobre ferramentas
Isto é, caso um campo tenha sido definido na Fermine como obrigatório, a WiseTest gera um caso
de teste para testar se houve o preenchimento do campo. Além disso, os casos de teste automáticos
podem ser editados pelo projetista de testes que também pode criar novos CDTs para situações não
previstas nos CDUs que necessitem de validação. A criação automática de testes a partir de CDUs foi
motivada pela constatação do grande tempo gasto pelos projetistas de testes dos projetos da RENAPI
na sua especificação manual. A Figura 2 mostra um conjunto de casos de testes extraídos a partir da
leitura do caso de uso da Figura 1.
Figura 2. Casos de teste gerados a partir de caso de uso.
4. Fermine e WiseTest no Contexto do MPS.Br
O propósito do processo de Gerência de Requisitos (GRE) do MR-MPS é “gerenciar os requisitos
do produto e dos componentes do produto do projeto e identificar inconsistências entre os
requisitos, os planos do projeto e os produtos de trabalho do projeto” [SOFTEX, 2009]. Para isto, os
seguintes resultados são esperados: GRE1 – os requisitos são entendidos, avaliados e aceitos junto
aos fornecedores de requisitos; GRE2 – o comprometimento da equipe técnica com os requisitos
aprovados é obtido; GRE3 – a rastreabilidade bidirecional entre os requisitos e os produtos de
180 WAMPS 2011
Apoio aos Processos de Gerência de Requisitos e Verificação e Validação em um Ambiente Integrado
trabalho é estabelecida e mantida; GRE4 – revisões em planos e produtos de trabalho do projeto são
realizadas visando identificar e corrigir inconsistências em relação aos requisitos; GRE5 – mudanças
nos requisitos são gerenciadas ao longo do projeto.
Para atender parcialmente os resultados GRE1 e GRE2, a Fermine permite a manutenção completa
de requisitos funcionais e não-funcionais, definindo templates de documentos padronizados que
podem ser compartilhados entre toda a equipe e os clientes. Quanto ao resultado GRE3, a Fermine,
além de requisitos, mantém outros artefatos da Engenharia de Requisitos (ER) como atores, glossário,
regras de negócio e casos de uso; permitindo definir a rastreabilidade entre tais produtos de trabalho.
Desta forma, é possível conhecer a relação existente entre os produtos de trabalho mantidos e,
consequentemente, avaliar o impacto que mudanças em um artefato podem ocasionar no sistema.
Para atender ao GRE5, está prevista a integração da ferramenta de Gerência de Configuração
RedSCoM, apresentada em [Carvalho et al. 2010] no ambiente proposto neste trabalho. O resultado
GRE4 é o único ainda não totalmente automatizado pela Fermine que, por hora, apenas, disponibiliza
um conjunto de checklists de revisão. A revisão nos artefatos da ER é realizada pela equipe do QUALIEPT no início do ciclo de vida do software, mas, neste momento, ainda de forma manual.
Em relação à validação (VAL), seu propósito no MR-MPS é “confirmar que um produto ou componente
do produto atenderá a seu uso pretendido” [SOFTEX, 2009]. Para o processo de verificação (VER) o
objetivo é “confirmar que cada serviço e/ou produto de trabalho do processo ou do projeto atende
apropriadamente os requisitos especificados” [SOFTEX, 2009]. A WiseTest foca os testes funcionais,
alcançando parcialmente alguns dos resultados esperados para os processos de VER e VAL.
Um desses resultados é a identificação dos produtos que serão validados e verificados. Na WiseTest,
isto é previsto por meio do registro no plano de testes dos CDUs a serem considerados na validação e
verificação e também através do campo “Funcionalidades a serem testadas”, que descreve, na visão
do cliente, as funções do sistema que serão validadas.
A ferramenta também contribui com os resultados esperados VER2 e VAL2, que consistem no
desenvolvimento e na implementação de estratégias de validação e verificação. A contribuição se dá
através do plano de testes que permite a inclusão de informações como a abordagem dos testes, o
cronograma e os recursos usados nas atividades de validação e verificação.
Outra contribuição a ser ressaltada é em relação ao terceiro resultado esperado (VAL3) que refere-se à
identificação de critérios e procedimentos para validação de produtos de trabalho e o estabelecimento
de um ambiente para validação. Para isto, a WiseTest, integrada à ferramenta de requisitos Fermine,
apóia a equipe de testes na geração automática de CDTs a partir de CDUs. Este recurso pode ser visto
como um dos critérios utilizados para o planejamento e execução dos testes funcionais.
Além disso, os checklists para a revisão dos artefatos da Gerência de Requisitos, disponíveis na
Fermine, também contribuem com resultados dos processos de V&V.
5. Trabalhos Relacionados
Foi realizada uma análise comparativa do ambiente proposto com outras soluções similares existentes,
como: TestLink (2011), Enterprise Architect (2011) e Microsoft Visual Studio Test Professional (2010).
WAMPS 2011 181
Artigos selecionados sobre ferramentas
O TestLink é uma ferramenta web de código aberto para gerenciamento de testes que permite o
cadastro de planos e casos de teste, além do controle de execução dos testes; porém o preenchimento
dos dados é manual. Possibilita o registro de requisitos e a associação destes aos casos de teste.
O Enterprise Architect é uma ferramenta proprietária da Sparx Systems que permite o cadastro de
requisitos e a descrição parcial de casos de uso. Possibilita a execução de testes categorizados (ex: de
sistema, aceitação etc.). Entretanto, a descrição dos CDTs não apresenta um nível de detalhamento
conforme previsto neste trabalho, como a inclusão de tabelas de dados, mensagens de exceção etc.
A Microsoft Visual Studio Test Professional (M. V. S. Test Professional) é uma solução proprietária e
permite a criação de planos, conjuntos e casos de teste, além da execução de testes manuais. Pode
ter suas funcionalidades ampliadas através da integração com outras plataformas compatíveis.
A Tabela 1 apresenta um resumo comparativo dos ambientes descritos.
Tabela 1. Comparação entre ferramentas.
Ferramentas
TestLink
Enterprise
Architect
M. V. S. Test
Professional
Fermine
Integrada com
WiseTest
Código Aberto
Sim
Não
Não
Sim
Registro de Requisitos
Sim
Sim
Não
Sim
Registro de Especificação
de Casos de Uso
Não
Sim
Não
Sim
Geração Automática de
Casos de Teste
Não
Parcialmente
Não
Sim
Critérios
6. Conclusões e Trabalhos Futuros
Este artigo apresenta um ambiente integrado contemplando ferramentas que apóiam a implementação
dos processos de GRE, VER e VAL que vem sendo utilizado pelos projetos da RENAPI. De modo geral, o
ambiente proposto permite a padronização de documentos, redução do tempo gasto na elaboração
da documentação requerida pela GRE, VER e VAL, centralização dos produtos de trabalho em um
único ambiente de desenvolvimento, flexibilidade na personalização (solução de código aberto),
trabalho colaborativo entre equipes distribuídas, aumento da produtividade etc.
Como principais contribuições, destacam-se: manutenção e integração de artefatos da GRE, VER e
VAL, descrição e especificação completa de casos de uso, definição de rastreabilidade entre artefatos
da GRE e casos de teste, manutenção do plano de testes e geração automática de CDTs a partir da
especificação de CDUs.
Como trabalhos futuros, encontram-se: visualização da matriz de rastreabilidade, contemplando os
CDTs; definição do status dos requisitos (avaliado, aceito etc); associação dos CDUs com artefatos
de modelo por meio da leitura de arquivos XMI; rastreabilidade para código fonte; integração
182 WAMPS 2011
Apoio aos Processos de Gerência de Requisitos e Verificação e Validação em um Ambiente Integrado
com ferramentas de automação de testes; disponibilização no portal de software público brasileiro;
evolução da WiseTest para ampliar o apoio à verificação, incluindo a automatização dos checklists de
revisão; apresentação dos resultados de avaliação sobre o uso das ferramentas.
Referências
Almeida, G., Ramos, B., Neto, M., Reis, M., Barcelos, M., Vasconcelos, A., (2010), Ferramenta de
Apoio à Engenharia de Requisitos Integrada a um Ambiente Colaborativo de Código Aberto.
In: Congresso Brasileiro de Software: Teoria e Prática (CBSoft), Sessão de Ferramentas – Vol. 4,
Salvador, BA, Brasil, Setembro. Anais ISSN 2178-6097, pp. 1-6.
Carvalho, J. Amaral, M., Barcelos, M., Silva, S., Vasconcelos, A., (2010), Integração da Gerência de
Configuração com a Gerência de Projetos e de Requisitos em um Ambiente Colaborativo. In: VI
Workshop Anual do MPS (WAMPS), Sessão de Ferramentas, Campinas, SP, Brasil, Outubro. ISBN
978-85-99334-19-5, pp. 254-262.
Enterprise Architect, www.sparxsystems.com/products/ea/, versão 9.1. Acessado em 15/09/11.
Guedes, G. T. A. (2008), UML: Uma Abordagem Prática, Novatec Editora, 3ª Edição.
Microsoft Visual Studio Test Professional,
aspx?id=24988, acessado em 06/08/11.
www.microsoft.com/download/en/confirmation.
MPS.Br – Melhoria de Processo do Software Brasileiro,
www.softex.br/mpsbr/_home/default.asp, acessado em 04/08/11.
Pezzè, M. e Young, M. (2008), Teste e Análise de Software, Bookman.
Pressman, R. S. (2007), Engenharia de Software, Makron Books, 6ª edição. São Paulo.
QUALI-EPT – Projeto de Qualidade de Software Aplicada à Educação Profissional e Tecnológica,
www.renapi.gov.br/qualidade/conheca-o-projeto, acessado em 04/08/11.
Redmine, www.redmine.org, acessado em 10/08/11.
RENAPI – Portal da Rede Nacional de Pesquisa e Inovação em Tecnologias Digitais,
www.renapi.gov.br, acessado em 04/08/11.
Rios, E. (2007), Documentação de Teste de Software – Dissecando o Padrão IEEE 829, Imagem Art
Studio, 1ª Edição.
Silva, S., Lisboa, J., Vasconcelos, A., Barbosa, C., Reis, M., Leite, R., Barroso, L. (2011). Gestão Integrada
– Uma Ferramenta para Atender aos Processos de Gerência de Projetos e Portfólio do MPS.Br. IV
Workshop de Gerenciamento de Projetos de Software (WPGS 2011). SBQS 2011. Curitiba, PR.
SOFTEX – Associação Para Promoção da Excelência do Software Brasileiro – SOFTEX. MPS.Br – Guia
Geral: 2009, maio 2009. www.softex.br/mpsbr/_guias/guias/MPS.BR_Guia_Geral_2009.pdf.
Sommerville, Ian. (2003), Engenharia de Software, Addison Wesley, 6ª Edição.
TestLink, testlink.sourceforge.net/docs/testLink.php, acessado em 03/08/11.
WAMPS 2011 183
184 WAMPS 2011
WAMPS 2011
O WAMPS 2011 (VII Workshop Anual do MPS) tem
por objetivo reunir representantes tanto da Indústria,
Governo e Academia (tripla hélice brasileira), da
SOFTEX - Associação para Promoção da Excelência
do Software Brasileiro, seus Agentes e empresas
associadas, da Equipe Técnica do Modelo MPS
(ETM), inclusive os ‘senior advisors’, do Fórum de
Credenciamento e Controle (FCC), das Instituições
Implementadoras MPS (II), Instituições Avaliadoras
MPS (IA) e Instituições Organizadoras de Grupos
de Empresas MPS (IOGE), quanto de 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 - Melhoria de
Processo do Software Brasileiro.
Nesta publicação encontram-se tanto o resumo das
apresentações dos palestrantes internacionais e das
palestras convidadas, quanto a íntegra dos artigos
técnicos selecionados pelo Comitê de Programa
do WAMPS 2011 e dos artigos selecionados para
publicação na Seção de Ferramentas.
Apoio:
ISBN: 978-85-99334-31-7
9 788599 334317
www.softex.br/mpsbr