W WAMPS 2011 - softex.br

WAMPS 2011 VII Workshop Anual do MPS

WA

MPS 2011

Apoio:

www.softex.br/mpsbr

Campinas-SP, 24 a 28 de outubro de 2011

WAMPS 20114

WAMPS 2011 5

FICHA CATALOGRÁFICA ELABORADA PELO

Sistemas de Bibliotecas da UNICAMP / Setor de Catalogação

Bibliotecária: Priscila Gomes Cruz

W892aWorkshop 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. Software - Congressos - 001.64252. Programas de computador – Congressos - 001.642

WAMPS 20116

SOFTEX - Associação para Promoção da Excelência do Software BrasileiroCriada 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 SOFTEXAmpliar 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 SOFTEXRubén Delgado

Vice-Presidente Executivo da SOFTEXArnaldo Bacha de Almeida

Diretoria Executiva da SOFTEXDescartes 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 BrasileiroKival 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

WAMPS 2011 7

Sumário

Apresentação

Organização do WAMPS 2011

Programação do WAMPS 2011

1 – Palestrantes convidados

1.1 – “Perspectivas para Ciência, Tecnologia e Inovação no Brasil 2010-2020”. Jorge Audy (PUC-RS)

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

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)

1.4 – “Consultores e Consultoria. Uma visão Crítica”. Carlos Barbieri (CCOMP.MG/FUMSOFT)

1.5 – “Como verificar se a empresa está pronta para avaliação inicial”. Cristina Machado (CELEPAR / QUALITYFOCUS)

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)

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)

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)

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)

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)

9

11

12

16

20

26

38

42

44

54

62

74

84

WAMPS 20118

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)

2.7 – “Relato da Experiência do Processo de Institucionalização do Modelo CMMI na Dataprev”, Rosana Osorio, Guilherme Motta (DATAPREV)

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 )

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)

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)

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)

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)

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)

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)

94

104

114

124

136

146

156

166

176

WAMPS 2011 9

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 201110

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

WAMPS 2011 11

Organização do WAMPS 2011

Coordenação GeralJosé Antonio Antonioni (SOFTEX)

Kival Weber (SOFTEX/MPS.BR)

Ana Regina Rocha (COPPE/UFRJ)

Nelson Franco (SOFTEX)

Coordenação CientíficaTayana Conte (UFAM)

Coordenação Científica da Sessão de Ferramentas Gleison Santos (UNIRIO)

Comitê de Avaliação da Trilha Artigos TécnicosAdriano 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écnicosLuiz Leandro Fortaleza (UFAM)

Comitê de Avaliação da Trilha de FerramentasAdler 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 FerramentasMarcelo Schots (COPPE/UFRJ)

Mylene Cabral (COPPE/UFRJ)

Natália Chaves Lessa Schots (COPPE/UFRJ)

WAMPS 201112


WAMPS 2011 - VII WORKSHOP ANUAL DO MPS – 24 a 28 de outubro de 2011Local: Hotel Tryp Campinas (by Sol Meliá) - Rua Severo Penteado, 140 – Cambuí, Campinas, SPCoordenaçã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:00Curso “Implementação nível E”

(Mariano Montoni)Curso “Como escrever um relato de experiência”

(Gleison Santos)9:00-9:30

9:30-10:00

10:00-10:30 Intervalo Exposição de Ferramentas

10:30-11:00

Continuidade do Curso “Implementação nível E” (Mariano Montoni)

Continuidade do Curso “Como

escrever um relato de experiência”

(Gleison Santos)

Exposição de Ferramentas

11:00-11:30 Exposição de Ferramentas



12:30-14:00 Almoço Exposição de Ferramentas

14:00-14:30Artigo 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:30Artigo aceito 3: “Apoio à Medição em um ADS Centrado em Processos”, Talita Ribeiro,

Luciana Nascimento, Liken Lima, Carla Lima Reis, Rodrigo Reis (UFPA)


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)


16:30-17:00Artigo 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)


17:00-17:30Artigo 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)


17:30-18:00 Palestra de Carlos Barbieri (CCOMP.MG / FUMSOFT): “Consultores e Consultoria. Uma visão crítica”18:00-18:30

18:30-20:00 Abertura do WAMPS e Entrega de Placas MPS.BR

20:00-00:00 Festa de Abertura


WAMPS 2011 13


8:30-9:00Curso “Como conduzir um processo de Planejamento

Estratégico” (Francisco Vasconcellos)

Prova para Avaliadores MPS 8:30 as 12:30 (sem intervalo)

9:00-9:30

Reu CGP - Conselho de Gestão do

Programa MPS.BR (9:00-12:00)

9:30-10:00


10:30-11:00Continuidade do Curso

“Como conduzir um processo de Planejamento Estratégico”

(Francisco Vasconcellos)




12:00-12:30 Exposição de FerramentasAlmoço


14:00-14:30Palestrante Nacional: Jorge Audi (PUCRS)

“Perspectivas para Ciência, Tecnologia e Inovação no Brasil 2010-2020”14:30-15:00

15:00-15:30


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)


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)


17:00-17:30Artigo aceito 9: “Relato da Experiência do Processo de

Institucionalização do Modelo CMMI na Dataprev”, Rosana Osorio, Guilherme Motta (DATAPREV)


17:30-18: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”18:00-18:30

18:30-19:00Reunião Coordenadores de II, de IA e IOGE

19:00-20:00

WAMPS 201114


8:00–8:30

Curso “Medição e Definição de Indicadores” (Monalessa Barcellos)

8:30–9:00 Palestra de Cristina Machado (CELEPAR / QUALITYFOCUS):

“Como verificar se a empresa está pronta para avaliação inicial”

9:00–9:30

9:30–10:00


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 )

Continuação do Curso “Medição e Definição

de Indicadores” (Monalessa Barcellos)


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:30Almoço



14:00-14:30Palestrante 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


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)

“Reunião RELAIS - Aquisição de Software

entre SOFTEX e representantes da Colômbia, México

e Peru”


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


WAMPS 2011 15


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




17:30-18:30Palestra Edmeia Leonor Pereira de Andrade (EMBRAPA) -

“Processo de Contratação de Serviços de TI para Organizações Públicas”





12:30-14:00 Almoço




Palestrantes convidados

WAMPS 201116

Perspectivas para Ciência, Tecnologia e Inovação no Brasil 2010-2020

Jorge Audy, [email protected]ó-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.


WAMPS 2011 17

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 201118

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.


WAMPS 2011 19

WAMPS 201120


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.


WAMPS 2011 21

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

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

WAMPS 201122


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 third-party 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 cloud-computing 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.


WAMPS 2011 23

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 hands-on 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 201124


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


WAMPS 2011 25

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 201126


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çãoCaixa Postal 68511 – CEP 21945-970 – Rio de Janeiro, [email protected]

Kali Software2 - Centro Empresarial Mourisco, Praia de Botafogo 501, 1° AndarBloco Pão de Açucar – CEP 22250-040 – Rio de Janeiro, [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

iMPS – Rodada 4: Variação de Desempenho nas Empresas que Adotaram o Modelo MPS de 2008 a 2011

WAMPS 2011 27

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 201128


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 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 1. Mediana do tamanho dos projetos.

Figura 2. Boxplot da Precisão de Estimativa.


WAMPS 2011 29

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.

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

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

WAMPS 201130


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

Tabela 1. Nível de Confiança nos Indicadores

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.


WAMPS 2011 31

Figura 4. Variação de Desempenho das 53 Empresas que Adotaram o MPS e Participaram da Pesquisa

Periódica iMPS em 2010 e 2011

Fatur

amento

Mudança

de Nível

Custo

Medio Pro

j.

Temp

o Médio Est

imado

Temp

o Médio Ga

sto

Precisão de

Estim

ativa

Tama

nho M

édio dos P

roj.

No Clien

tes no

País

No Fu

ncion

ários

No Proje

tos no

País

Produtivida

de

Qualidade

0%

20%

40%

60%

80%

100%

Aumentou

Não Alterou

Reduziu

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.

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

Fatur

amento

Mudança

de Nível

Custo

Medio Pro

j.

Temp

o Médio Est

imado

Temp

o Médio Ga

sto

Precisão de

Estim

ativa

Tama

nho M

édio dos P

roj.

No Clien

tes no

País

No Fu

ncion

ários

No Proje

tos no

País

Produtivida

de

Qualidade

0%

20%

40%

60%

80%

100%

Aumentou

Não Alterou

Reduziu

WAMPS 201132


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.



Mudança de Nível MPS 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.


WAMPS 2011 33

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.

Figura 6. Indicadores de Variação de Desempenho 2009-2011 para 21 empresas

Desempenho 2009-‐2011 ( 21 empresas)

0%10%20%30%40%50%60%70%80%90%

100%

Mudança

de Ni

vel M

PS

Custo

Médio dos P

rojeto

s

Temp

o Médio Est

imado

Temp

o Médio Ga

sto

Precisão de

Estim

ativa

Tama

nho M

édio dos P

rojeto

s

No Clien

tes no

País

No Fu

ncion

ários

No Proje

tos no

País

AumentouNão AlterouReduziu

WAMPS 201134


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.


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


WAMPS 2011 35

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.

Figura 7. Indicadores de Desempenho 2008-2011 para 7 empresas

Desempenho 2008-‐2011 (7 empresas)

0%

10%

20%

30%

40%

50%

60%

70%

80%

90%

100%

Mudança deNivel MPS

Tempo MédioEstimado

Tempo MédioGasto

Precisão deEstimativa

No Clientes noPaís

NoFuncionários

No Projetos noPaís

AumentouNão AlterouReduziu

WAMPS 201136


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ós-doutorado em Engenharia de Software Experimental na University of Maryland-College Park. Professor de Engenharia de Software do Programa de Engenharia de Sistemas e Computação da COPPE/UFRJ. Pesquisador 1D CNPq. Líder do Grupo de Engenharia de Software Experimental. Atualmente é Diretor de Planejamento e Administração da COPPE/UFRJ, membro da ISERN. 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


WAMPS 2011 37

WAMPS 201138


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


WAMPS 2011 39

“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 201140


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ós-graduaçã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.


WAMPS 2011 41

WAMPS 201142


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.

Como verificar se a empresa está pronta para a avaliação

WAMPS 2011 43

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 201144

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

1Departamento de Computação – Universidade Estadual de Londrina (UEL) CEP 86051-990 – Bloco J – Sala 305A – Londrina – PR – Brasil

2Guenka Desenvolvimento de Software Ltda. Londrina – PR – Brasil

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


WAMPS 2011 45

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 201146


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


WAMPS 2011 47

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 201148


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


WAMPS 2011 49

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 201150


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


WAMPS 2011 51

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 201152


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.


WAMPS 2011 53

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 201154


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

1Athenas Engenharia de Software – Av. Rio Branco, 12, 14º andar, Centro CEP 20090-000 – Rio de Janeiro – RJ – Brasil

2 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

3 COPPE/UFRJ – Universidade Federal do Rio de Janeiro – Caixa Postal 68511 – CEP 21945-970 – Rio de Janeiro – Brasil

{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


WAMPS 2011 55

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 201156


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


WAMPS 2011 57

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 201158


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.

Figura 2. Composição do processo de desenvolvimento APD.


WAMPS 2011 59

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


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.


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


WAMPS 2011 61

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”, Addison-Wesley.

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 201162


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.


WAMPS 2011 63

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 201164


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


WAMPS 2011 65

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.

SPICE Automotive SPICE

ENG1 – Análise de requisitos e design de sistemaENG2 – Análise de requisitos do sistemaENG3 – 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].

WAMPS 201166


Quadro 1. Práticas base dos processos ENG1, ENG2 e ENG4.

ENG1 – Elicitação de Requisitos ENG2 – Análise de Requisitos do Sistema

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.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 sistemaENG2.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 DRE – Desenvolvimento 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.

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.


WAMPS 2011 67

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 MR-MPS. 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 201168


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 2. Arquitetura de processos e processo padrão Engenharia de Requisitos SE.

Figura 3. Processo padrão Engenharia de Requisitos.


WAMPS 2011 69

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 SistemaTarefa consiste na identificação dos requisitos de sistema.Atende ao item ENG2.BP1. Identificar Requisitos de Sistema.

Especificar Requisitos de SistemaTarefa consiste na especificação dos requisitos de sistema.Atende ao item ENG2.BP2. Analisar Requisitos de Sistema

WAMPS 201170


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 RequisitosTarefa adaptada para incluir a priorização de requisitos de sistemas.Atende ao item ENG2.BP4. Priorizar e categorizar os requisitos de sistema

Quadro 4. Tarefas adaptadas no processo Engenharia de Software SE.

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.


WAMPS 2011 71

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. 37-61. 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 201172


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.


WAMPS 2011 73

WAMPS 201174


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

1 CELEPAR – Companhia de Informática do ParanáR Mateus Leme 1561 – CEP 80530-010 – Curitiba – PR – Brasil

2 Empresa Brasileira de Pesquisa AgropecuáriaParque Estação Biológica – PqEB s/nº – AV. W3 Norte (final) – Edifício Sede – 70770-901 – Brasília – DF – Brasil

3 PrimeUp – Instituição de Consultoria de Aquisição Av. Graça Aranha, 326 sala 91 – CEP 20030-001 – Rio de Janeiro – RJ – Brasil

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


WAMPS 2011 75

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


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

Figura 1. Processo de Aquisição MPS.

Preparação da aquisição

Seleção do fornecedor

Monitoração do contrato

Aceitação pelo cliente

1. Estabelecer a necessidade 2. Definir os requisitos 3. Revisar os requisitos 4. Desenvolver uma estratégia de aquisição 5. Definir os critérios de seleção de fornecedores

1. Avaliar a capacidade dos fornecedores 2. Selecionar o fornecedor 3. Preparar e negociar um contrato

1. Estabelecer e manter comunicações 2. Trocar informação sobre o progresso técnico 3. Revisar o desempenho do fornecedor 4. Monitorar a aquisição 5. Obter acordo quanto às alterações 6. Acompanhar problemas

1. Preparar a aceitação 2. Avaliar o S&SC entregue 3. Manter conformidade com o contrato 4. Aceitar o S&SC


WAMPS 2011 77

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 201178


das pessoas envolvidas em projetos de aquisição; políticas gerais de contratação de S&SC; 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.


WAMPS 2011 79

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 201180


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.


WAMPS 2011 81

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 2178-0277. Disponível em: <http://www.mct.gov.br/upd_blob/0212/212192.pdf>. Acesso em: 30 set. 2010.

WAMPS 201182


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


WAMPS 2011 83

WAMPS 201184


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

1 COPPE/UFRJ – Universidade Federal do Rio de Janeiro Caixa Postal 68511 – CEP 21945-970 – Rio de Janeiro – Brasil

2 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

[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


WAMPS 2011 85

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 201186


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.


WAMPS 2011 87

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 SPI-KM 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 201188


Tabela 1. Caracterização das Organizações.

Organização #1

Organização #2

Organização #3

Organização #4

Nível MR-MPS pretendido F E F F

Experiência anterior em proces-sos

RUPMR-MPS Nível G

Nenhuma Nenhuma

Característica do desenvolvi-mento

RUP + técnicas ágeis

Iterativo Cascata SCRUM

Colaboradores envolvidos 7 24 96 16

Pessoas internas alocadas inte-gralmente à melhoria

Sim (1) Não Sim (1) Não

Tempo total do início da imple-mentação até avaliação final

10 meses 13 meses 21 meses 18 meses

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


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.


WAMPS 2011 89

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.


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 201190


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.


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.


WAMPS 2011 91

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 201192


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


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


WAMPS 2011 93

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 201194


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


WAMPS 2011 95

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 mostrava-se 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 201196


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.


WAMPS 2011 97

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 201198


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


WAMPS 2011 99



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 2011100


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

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


WAMPS 2011 101

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


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


WAMPS 2011 103

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 2011104


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 CMMI-DTP: 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.


WAMPS 2011 105

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 2011106


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.


WAMPS 2011 107

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.

3RD – Desenvolvimento de Requisitos; TS – Solução Técnica; PI – Integração de Produtos; DAR – Análise de Decisão.

4OPD – Definição do Processo Organizacional; OPF – Foco no Processo Organizacional; OT – Trei-namento Organizacional.

5PP – Planejamento de Projeto; PMC – Monitoramento e Controle de Projeto; RSKM – Gerência de Riscos; IPM – Gerência Integrada de Produtos.

WAMPS 2011108


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.


WAMPS 2011 109

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 im-plantaçã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 / institucionali-zaçã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 / institucionali-zação das práticas

Não conformidades e termos de aceite

Planejamento e execução das correções das não confor-midades

Plano de correção das falhas

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 SCAM-PI C e B, para os Níveis 2 e 3 do modelo CMMI

Relatórios de Achados e Planos de Ação

WAMPS 2011110


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


WAMPS 2011 111

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 2011112


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


WAMPS 2011 113

• 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 – MPS-BR, 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-85-99334-15-7, setembro.

WAMPS 2011114


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

1Laboratory 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

2Instituto 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

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


WAMPS 2011 115

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 2011116


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.

Figura 1. Fluxograma de Implantação de Melhorias.


WAMPS 2011 117

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 2011118


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.


WAMPS 2011 119

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 2011120


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


WAMPS 2011 121

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 2011122


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.


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,


WAMPS 2011 123

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 2011124


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

1Instituto de Informática – Universidade Federal de Goiás (UFG) Caixa Postal 131, Campus II – 74.001-970 – Goiânia – GO – Brasil

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


WAMPS 2011 125

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 2011126


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.


WAMPS 2011 127

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 2011128


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.


WAMPS 2011 129

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 2011130


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.


WAMPS 2011 131

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

Tabela 1. Taxonomia e Aplicações das Formas de Comunicação em Projetos.

Critério de Classificação Indicações de Uso e Exemplos

Quanto aoSincronismo

• SíncronaIndicada para diálogos importantes e urgentes. Ex.: Reuniões (presenciais ou vídeo-conferências); Instant Messenger; Conversas pessoais.

• AssíncronaIndicada para recados e afazeres sem restrição de tempo. Ex.: E-mail estruturado, Voice-mail; Grupos de discussão; Fóruns; SMS.

Quanto àFormalidade

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

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

Quanto aoCódigo

ou Canal

• Verbal Usada em praticamente todos os casos que envolvem comunicação.

º OralPreferível em comunicações de trabalho de caráter não deliberativo. Ex.: Reuniões técnicas; Palestras; Entrevistas; Apresentações.

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

WAMPS 2011132


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.


WAMPS 2011 133

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ão-verbal, 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 2011134


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.


WAMPS 2011 135

WAMPS 2011136

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 – FACOMPLaboratório de Engenharia de Software – LABESAvenida 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,


WAMPS 2011 137

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 2011138


Figura 2. Fases do processo de medição.

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

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.


WAMPS 2011 139

FIgura 3. Métricas: a) Definição e b) Coleta.

Figura 4. Planejamento da Medição – Modelos de Classes.

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.

a

b

WAMPS 2011140


a

b

Figura 5. Indicador: a) Definição e b) Seleção de alvos.

a

b

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.


WAMPS 2011 141

Figura 6. Análise e exportação dos resultados.

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

WAMPS 2011142


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.


WAMPS 2011 143


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.

Resultados Atendimento

MED 1A 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 necessi-dades 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 infor-maçõ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 4No planejamento de cada indicador é possível definir o procedimento de análise deste e, por conseguinte, das métricas que o compõe.

MED 5A 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 6Em 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 ferra-menta 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.

Tabela 1. Apoio aos Resultados Esperados de Medição – Nível F MR-MPS.

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 2011144


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.


WAMPS 2011 145

WAMPS 2011146


Controlle: Ferramenta de Apoio à Gerência de Requisitos

Fernando Nascimento1, Marcus Teixeira1, Marcello Thiry2 e Alessandra Zoucas2

1 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

2 (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

Abstract. Under the Incremental Tecnologia consultancy, an implementing insitution (II-MPS), the Khor Tec-nologia 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 oppor-tunities at the software.

Resumo. A empresa Khor Tecnologia da Informação, sob consultoria dos especialistas da instituição im-plementadora (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 descrev-endo 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 recon-hecidos 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 en-tre 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 automatiza-das 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 rastrea-bilidade 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].


WAMPS 2011 147

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 tra-balho 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 in-stituiçã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, esta-belecendo 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 2011148


• 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 possibili-dade 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 fornece-dor do requisito. Apenas fornecedores previamente cadastrados no projeto podem ser vinculados aos requisitos.

Figura 1. Registro do Requisito.


WAMPS 2011 149

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 2011150


Figura 3. Produtos Relacionados.

Figura 4. Diagrama – Rastreabilidade Visual.

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.

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.


WAMPS 2011 151

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 2011152


Figura 6. Produtos Impactados.

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.

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.


WAMPS 2011 153

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.

Resultados Esperados Avaliação

GRE 3 e 5 J – Aderente

GRE 1, 2 e 4 K – Aderente com oportunidades de melhoria

Atributos de Processo Avaliação

RAP 4 (nível F) J – Aderente para o processo de GRE

Tabela 1. Avaliação da Aderência da Ferramenta Controlle.


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 2011154


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.


WAMPS 2011 155

WAMPS 2011156


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

1Departamento de Ciência da Computação, Universidade Federal de Lavras2COPPE/UFRJ, Universidade Federal do Rio de Janeiro3Serviço Federal de Processamento de Dados, SERPRO{hborges}@sistemas.ufla.br, {res, rps, werner}@cos.ufrj.br, [email protected]

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

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


WAMPS 2011 157

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 2011158


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


WAMPS 2011 159

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 2011160


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


WAMPS 2011 161

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 2011162


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.


WAMPS 2011 163

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 2011164


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.


WAMPS 2011 165

WAMPS 2011166


Aderência do IBM Rational Team Concert ao MR-MPS – Uma análise com ênfase em gerência de configuração

João Condack

PrimeUp – Instituição Implementadora MPS.Br Rio de Janeiro – RJ – [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.


WAMPS 2011 167

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 2011168


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.

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


WAMPS 2011 169

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 2011170


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 rastreabili-dade através de links para os conjuntos de alterações (change sets).

Figura 5. Item de trabalho com rastreabilidade para conjunto de alterações.


WAMPS 2011 171

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:

Figura 6. Elementos e comandos para

controle dos itens de configuração. (Fonte: IBM)

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): Resi-dem no Servidor e referenciam componentes definidos em um fluxo. São es-paç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.

Registrar Entrada (Check-in): Copia arquivos alterados do espaço de tra-balho local para o espaço no repositório

Entregar (Deliver): Copia as alterações do espaço de trabalho do re-positó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 2011172


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,


WAMPS 2011 173

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 2011174


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/rational-team-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


WAMPS 2011 175

WAMPS 2011176


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


WAMPS 2011 177

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 2011178


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.


WAMPS 2011 179

Em relação aos demais artefatos, a Fermine faz a manutenção de requisitos funcionais e não-funcionais, 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 2011180


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


WAMPS 2011 181

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 QUALI-EPT 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 2011182


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.

Critérios

Ferramentas

TestLinkEnterpriseArchitect

M. V. S. Test Professional

FermineIntegrada 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

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


WAMPS 2011 183

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, www.microsoft.com/download/en/confirmation.aspx?id=24988, acessado em 06/08/11.

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 2011184

WAMPS 2011 VII Workshop Anual do MPS

WA

MPS 2011

Apoio:

www.softex.br/mpsbr

Campinas-SP, 24 a 28 de outubro de 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 latino-americanos, envolvidos e interessados na utilização e evolução tanto do Modelo MPS quanto do Programa MPS.BR – Melhoria de Processo do Software Brasileiro.

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.

ISBN: 978-85-99334-31-7

9 7 8 8 5 9 9 3 3 4 3 1 7

W WAMPS 2011 - softex.br

Documents

Transcript of W WAMPS 2011 - softex.br