VII SIMPÓSIO BRASILEIRO DE QUALIDADE DE SOFTWARE 02 de Junho a 06 de Junho de 2008 Florianópolis Santa Catarina, Brasil ANAIS

Transcrição

1

2 VII SIMPÓSIO BRASILEIRO DE QUALIDADE DE SOFTWARE 02 de Junho a 06 de Junho de 2008 Florianópolis Santa Catarina, Brasil ANAIS Promoção Sociedade Brasileira de Computação SBC Ministério da Ciência e Tecnologia MCT Programa Brasileiro da Qualidade e Produtividade em Software PBPQ Software Edição Sociedade Brasileira de Computação SBC Editores Marcello Thiry (Universidade do Vale do Itajaí) Christiane Gresse von Wangenheim (Universidade do Vale do Itajaí) Ana Cristina Rouiller (Universidade Federal Rural de Pernambuco) Organização UNIVALI Universidade do Vale do Itajaí UFRPE Universidade Federal Rural de Pernambuco Realização UNIVALI - Universidade do Vale do Itajaí UFRPE - Universidade Federal Rural de Pernambuco i

3 CIP CATALOGAÇÃO NA PUBLICAÇÃO Simpósio Brasileiro de Qualidade de Software (6.:2008 jun : Florianópolis) Anais / VII Simpósio Brasileiro de Qualidade de Software, editado por Marcello Thiry, Christiane Gresse von Wangenheim Florianópolis: Universidade do Vale do Itajaí (UNIVALI), Ana Cristina Rouiller Recife: Universidade Federal Rural de Pernambuco (UFRPE), xx, 473 p :il. ISBN Conhecido também como SBQS Engenharia de Software. I Thiry, Marcello. II Wagenheim, Christiane Gresse von. III Rouiller, Ana Cristina. IV SBQS (6.:2008: Florianópolis). Esta obra foi impressa a partir de originais entregues, já compostos pelos autores. Editoração: Marcello Thiry, Christiane Gresse von Wangenheim, Ana Cristina Rouiller. Capa e impressão: Copy Laser Gráfica. ii

4 7TH BRAZILIAN SYMPOSIUM ON SOFTWARE QUALITY June 02 06, 2008 Florianópolis Santa Catarina, Brasil PROCEEDINGS Promotion Sociedade Brasileira de Computação SBC Ministério da Ciência e Tecnologia MCT Programa Brasileiro da Qualidade e Produtividade em Software PBPQ Software Edition Sociedade Brasileira de Computação SBC Editors Marcello Thiry (Universidade do Vale do Itajaí) Christiane Gresse von Wangenheim (Universidade do Vale do Itajaí) Ana Cristina Rouiller (Universidade Federal Rural de Pernambuco) Organization UNIVALI Universidade do Vale do Itajaí UFRPE Universidade Federal Rural de Pernambuco Realization UNIVALI - Universidade do Vale do Itajaí UFRPE - Universidade Federal Rural de Pernambuco iii

5 iv

6 Apresentação É com grande satisfação que, em nome do Comitê de Programa e da Comissão Organizadora, saudamos os participantes do VII Simpósio Brasileiro de Qualidade de Software (SBQS 2008). Este é um evento promovido pela Sociedade Brasileira da Computação (SBC) e pelo Ministério da Ciência e Tecnologia (MCT), Programa Brasileiro da Qualidade e Produtividade em Software (PBQP Software) e tem como objetivo reunir empresários, profissionais, professores e estudantes de diversas áreas, interessados em questões relativas à Qualidade de Software. O SBQS foi iniciado em 2002, a partir do reconhecimento da SBC do crescimento contínuo, em termos de participação de público e apresentação de trabalhos, do Workshop de Qualidade de Software (WQS), evento satélite realizado durante oito anos, desde 1994, em paralelo ao Simpósio Brasileiro de Engenharia de Software (SBES). O SBQS tem se consolidado como um evento que integra as comunidades acadêmicas e empresariais em Qualidade de Software, por meio de várias atividades realizadas durante o simpósio: palestras convidadas, tutoriais, mini-cursos, sessões técnicas de apresentação de artigos e diferentes eventos satélites. Como já é tradição no SBQS, foram aceitos dois tipos de artigos: trabalhos técnicos, que exploram pesquisas realizadas na área de Qualidade de Software, e relatos de experiência, que descrevem a aplicação de procedimentos para garantia da qualidade, mostrando resultados obtidos e lições aprendidas, em uma experiência prática, com contribuição para a indústria. Neste ano foram submetidos ao SBQS artigos (88 trabalhos técnicos e 54 relatos de experiência) dos quais 30 foram aceitos para publicação (20 trabalhos técnicos e 10 relatos de experiência). O processo de revisão foi realizado por Comitês de Programa independentes, segundo critérios pré-estabelecidos para cada trilha (trabalho técnico ou relato de experiência). O SBQS 2008 congrega, ainda, o VI Concurso de Teses e Dissertações em Qualidade de Software (CTD-QS), que visa divulgar e premiar os melhores trabalhos de tese de doutorado e dissertações de mestrado na área de Qualidade de Software concluídas de janeiro a dezembro de A partir deste ano, o CTD-QS passa a entregar o Prêmio Prof. Arnaldo Dias Belchior como homenagem póstuma pela contribuição inestimável que o professor trouxe à área de Qualidade de Software. Em 2008, o SBQS conta com a presença de três palestrantes convidados, sendo dois nacionais e um internacional. O palestrante internacional é David Card (Q-Labs) e os palestrantes nacionais são Kival Weber (SOFTEX) e Prof. Guilherme Travassos (COPPE/UFRJ). Quatro mini-cursos e cinco cursos oficiais do MPS.BR também compõe a grade de programação do SBQS 2008, além de uma palestra da ABNT a respeito da norma nacional ABNT NBR ISO/IEC e dos futuros projetos da ABNT na área de Qualidade de Software. Paralelamente ao SBQS 2008, têm-se os seguintes eventos satélites: o Encontro da Qualidade e Produtividade em Software (EQPS), o VI Workshop de Teses e v

7 Dissertações em Qualidade de Software (WTDQS), o IV Workshop Olhar Sociotécnico sobre a Engenharia de Software (WOSES), V Workshop de Manutenção de Software Moderna (WMSWM), o I Workshop em Gerenciamento de Projetos de Software (WGPS) e o II Workshop de Desenvolvimento Rápido de Aplicações (WDRA). Gostaríamos de agradecer a todos os autores que submeteram artigos, aos membros dos Comitês de Programa, e do Comitê de Direção, aos patrocinadores que apoiaram o evento, aos palestrantes e professores convidados, e principalmente do Comitê de Organização, além de todos que de alguma forma, direta ou indireta, contribuíram para sua realização. Sem a contribuição de vocês, a realização deste evento não seria possível. Finalmente, desejamos a todos um ótimo simpósio e uma proveitosa semana em Florianópolis! Florianópolis, junho de Marcello Thiry, Christiane Gresse von Wangenheim e Ana Cristina Rouiller Coordenadores do SBQS 2008 vi

8 Coordenação do Comitê de Programa / Program Committee Chair Marcello Thiry, UNIVALI, Brasil Christiane Gresse von Wangenheim, UNIVALI, Brasil Ana Cristina Rouiller, UFRPE/ProQualiti, Brasil Comitê Diretivo / Steering Committee Ana Cristina Rouiller, UFRPE/ProQualiti, Brasil Ana Regina Rocha, COPPE/UFRJ, Brasil Christiane Gresse von Wangenheim, UNIVALI, Brasil Jorge Luis Nicolas Audy, PUC-RS, Brasil Kival Chaves Weber, PBQP/Software, Brasil Marcello Thiry, UNIVALI, Brasil Ricardo de Almeida Falbo, UFES, Brasil Comitê de Organização / Organizing Committee Alessandra Casses Zoucas, Incremental Tecnologia, Brasil Ana Cristina Rouiller, UFRPE/ProQualiti, Brasil Christiane Gresse von Wangenheim, UNIVALI, Brasil Gisele Prosdossimi Stahelin, Incremental Tecnologia, Brasil Marcello Thiry, UNIVALI, Brasil Sean Cassiolato, Agência É, Brasil vii

9 Coordenação do Comitê de Programa / Program Committee Coordination Trilha de Trabalhos Técnicos / Technical Paper Track Christiane Gresse von Wangenheim, UNIVALI, Brasil Trilha de Relatos de Experiência / Experience Report Track Marcello Thiry, UNIVALI, Brasil Membros do Comitê de Programa / Program Commitee Members Trilha de Trabalhos Técnicos / Technical Paper Track Adalberto Nobiato Crespo, CenPRA, Brasil Alejandro Bedini G., Universidad Tecnica Federico Santa Maria, Chile Alexandre Marcos Lins Vasconcelos, UFPE, Brasil Ana Cristina Rouiller, UFPE, Brasil Ana Guerra, CenPRA, Brasil Ana Liddy Magalhães, SWQuality, Brasil Ana Regina Rocha, COPPE/UFRJ, Brasil Bernardo Copstein, PUC-RS, Brasil Carla Alessandra Lima Reis, UFPA, Brasil Carlos Alberto Marques Pietrobon, UFOP, Brasil Carmen Maidantchik, COPPE/UFRJ, Brasil Clênio F. Salviano, CenPRA, Brasil Edmundo Spoto, UNIVEM, Brasil Fernanda Campos, UFJF, Brasil Geraldo Xexeo, COPPE/UFRJ, Brasil Guilherme Travassos, COPPE/UFRJ, Brasil Jones Oliveira Albuquerque, UFRPE, Brasil Jorge Luis Audy, PUC-RS, Brasil Junia Anacleto, UFSCar, Brasil Karina Villela, UNIFACS, Brasil Káthia Marçal de Oliveira, UCB, Brasil Kechi Hirama, USP, Brasil Leonardo Murta, UFRJ, Brasil Luiz Eduardo G. Martins, UNIMEP, Brasil Marcelo Blois, PUC-RS, Brasil Marcelo Hideki Yamaguti, PUC-RS, Brasil Marcelo Schneck de Paula Pessoa, USP, Brasil Marcio Barros, UNIRIO, Brasil Marcio Delamaro, Fundação Eurípedes da Rocha, Brasil Mario Jino, FEEC-UNICAMP, Brasil Mauro de Mesquita Spinola, USP, Brasil Miriam Capretz, The University of Western Ontário, Canadá Nicolas Anquetil, UCB, Brasil Oscar Pastor, Universitat Politècnica de València, Espanha viii

10 Raul Wazlawick, UFSC, Brasil Renata Araujo, UNIRIO, Brasil Ricardo Falbo, UFES, Brasil Ricardo Pereira e Silva, UFSC, Brasil Rodolfo Resende, DCC/UFMG, Brasil Rosana Teresinha Vaccare Braga, USP, Brasil Rosângela Penteado, UFSCar, Brasil Sandra Fabbri, UFSCar, Brasil Selma Melnikoff, USP, Brasil Silvia Abrahao, Valencia University of Technology, Espanha Vera Werneck, UERJ, Brasil Wilson Paula Filho, UFMG, Brasil Trilha de Relatos de Experiência / Experience Report Track Alfredo Tsukumo - CenPRA, Brasil Ana Candida Cruz Natali, UFRJ, Brasil André Villas-Boas, Fundação CPqD, Telecom & IT Solutions, Brasil Cristina Ângela Filipak Machado, CELEPAR, Brasil Cristiane S. Ramos, UCB, Brasil David Yoshida, ITS, Brasil Denise Carneiro, UNIFOR, Brasil Edmeia Leonor Andrade, EMBRAPA, Brasil Gleison Santos, COPPE/UFRJ, Brasil Jean Carlo R. Hauck, UFSC, Brasil Leonardo Murta, UFRJ, Brasil Marbilia Passagnolo Sergio, CenPRA, Brasil Maria Teresa Aguayo, CenPRA, Brasil Mariano Montoni, COPPE/UFRJ, Brasil Miriam Capretz, The University of Western Ontário, Canadá Nilson Salvetti, Fundação Vanzolini, Brasil Odisnei Galarraga, QualityFocus, Brasil Ozeas Vieira Santana Filho, SENAI, Brasil Regina Maria Thienne Colombo, CenPRA, Brasil Renato Renato Luiz Della Volpe, ASR, Brasil Sarah Kohan, Fundação Carlos Alberto Vanzolini, Brasil Sheila dos Santos Reinehr, PUC-PR, Brasil Teresa Maria de Medeiros Maciel, CESAR, Brasil Wagner Roberto De Martino, CENPRA, Brasil Avaliadores Externos / External Reviewers Alessandra Casses Zoucas, Incremental Tecnologia, Brasil Alexandre Álvaro, UFPE, Brasil Antonio Carlos Santos, UFSCar, Brasil Arilo Claudio Dias Neto, COPPE/UFRJ, Brasil Auri Vincenzi, UFG, Brasil Breno França, UFPA, Brasil Carlos Antônio Menezes de Albuquerque, UFPE, Brasil Cristiano Schwening, EngSoft, Brasil ix

11 Débora Maria Barroso Paiva, UFMS, Brasil Djone Kochanski, UNIASSELVI, Brasil Elisa Yumi Nakagawa, USP, Brasil Ellen Francine Barbosa, USP, Brasil Gisele Prosdossimi Stahelin, Incremental Tecnologia, Brasil Gustavo Olanda Veronese, RiskControl Serviços, Brasil Helio Rodrigues Costa, UFRJ, Brasil Heron Vieira Aguiar, SWQuality, Brasil Jadielly Oliveira, UFPA, Brasil Jean Carlo R. Hauck, UFSC, Brasil Juliano Lopes de Oliveira, UFG, Brasil Kristiane Adorno, POLITEC, Brasil Luciana A.F. Martimiano, UEM, Brasil Luiz Ricardo Lopes Lima, UNIFOR, Brasil Marcos Kalinowski, COPPE/UFRJ, Brasil Maria Istela Cagnin, UNIVEM, Brasil Marlise There Dias, UNIVALI, Brasil Paulino Wagner Palheta Viana, UFPE, Brasil Richard Henrique de Souza, CTAI, Brasil Rodrigo Reis, UFPA, Brasil Rosanne Carneiro, Instituto Atlântico, Brasil Tayana Conte, COPPE/UFRJ, Brasil Valter Vieira Camargo, UNIVEM, Brasil Coordenação do Concurso de Teses e Dissertações de Mestrado em Qualidade de Software Carlos Alberto Marques Pietrobon, PUC-MG, UFOP, Brasil Comissão Julgadora do Concurso de Teses e Dissertações de Mestrado em Qualidade de Software Alexandre Marcos Lins de Vasconcelos, UFPE, Brasil Ana Liddy Magalhães, SWQuality, Brasil Clenio F. Salviano, CenPRA e ProQualiti, Brasil Debora Maria Barroso Paiva, UFMS, Brasil Jones Albuquerque,UFRPE, Brasil Ricardo de Almeida Falbo, UFES, Brasil Coordenação do VI Workshop de Teses e Dissertações em Qualidade de Software Ricardo Pereira e Silva, UFSC, Brasil x

12 Comissão Julgadora do VI Workshop de Teses e Dissertações em Qualidade de Software Ana Liddy Magalhães, SWQuality, Brasil Carla Lima Reis, UFPA, Brasil Clenio Salviano, CenPRA, Brasil Ellen Francine Barbosa, Brasil Guilherme Travassos, COPPE/UFRJ, Brasil José Luís Braga, UFV, Brasil Maria Augusta Vieira Nelson, PUC-MG, Brasil Mauro Spinola, USP, Brasil Raul Wazlawick, UFSC, Brasil Ricardo Falbo, UFES, Brasil Coordenação do IV Workshop Olhar Sociotécnico sobre a Engenharia de Software Rafael Prikladnicki, PUC-RS, Brasil João Porto de Albuquerque, Universitaet Hamburg e EACH/USP, Brasil Henrique Luiz Cukierman, COPPE/UFRJ, Brasil Cássio Adriano Nunes Teixeira, COPPE/UFRJ, Brasil Comissão Julgadora do IV Workshop Olhar Sociotécnico sobre a Engenharia de Software Ana Guerra, CENPRA, Brasil Ana Regina Rocha, COPPE/UFRJ, Brasil Cássio Adriano Nunes Teixeira, COPPE/UFRJ, Brasil Fabio Rilston, SERPRO, Brasil Fernanda Baião, UNIRIO, Brasil Flavia Santoro, UNIRIO, Brasil Francisco Lima, UFMG, Brasil Guilherme Travassos, COPPE/UFRJ, Brasil Heitor Augustus Xavier Costa, UFLA, Brasil Henrique Luiz Cukierman, COPPE/UFRJ, Brasil Ivan da Costa Marques, UFRJ, Brasil João Porto de Albuquerque, EACH/USP, Brasil Jorge Audy, PUC-RS, Brasil Jose Antonio Xexeo, Centro Universitário Metodista Bennett, Brasil Kival Weber, SOFTEX, Brasil Márcia Moraes, UFF, Brasil Marcio Silveira, EDS, Brasil Miriam Akemi Manabe Capretz, University of Western Ontario, Brasil Rafael Prikladnicki, PUC-RS, Brasil Renata Araújo, UNIRIO, Brasil Rosa Pedro, UFRJ, Brasil Tamara Benakouche, UFSC, Brasil xi

13 Coordenação do V Workshop de Manutenção de Software Moderna Leonardo Murta, COPPE/UFRJ, Brasil Rosana Braga, ICMC/USP, Brasil Cláudia Werner, COPPE/UFRJ, Brasil Marcos Chaim, USP, Brasil Nicolas Anquetil, UCB, Brasil Rosângela Penteado, UFSCar, Brasil Comissão Julgadora do V Workshop de Manutenção de Software Moderna Aline Vasconcelos, CEFET Campos, Brasil Ana Regina Rocha, COPPE/UFRJ, Brasil Cláudia Werner, COPPE/UFRJ, Brasil Elisa Huzita, UEM, Brasil Guilherme Travassos, COPPE/UFRJ, Brasil Heitor Augustus Xavier Costa, UFLA, Brasil Junia Anacleto, UFSCar, Brasil Lucia Vilela Leite Filgueiras, USP, Brasil Manoel Mendonça, UNIFACS, Brasil Marcelo Maia, UFU, Brasil Marcos Chaim, USP, Brasil Maria Istela Cagnin, UNIVEM, Brasil Nabor Mendonça, UNIFOR, Brasil Nicolas Anquetil, UCB, Brasil Paulo Masiero, USP, Brasil Roberto Tom Price, UFRGS, Brasil Rosângela Penteado, UFSCar, Brasil Selma Melnikoff, USP, Brasil Coordenação do II Workshop de Desenvolvimento Rápido de Aplicações Ana Liddy Magalhães, SWQuality, Brasil Ana Cristina Rouiller, UFRPE, Brasil xii

14 Comissão Julgadora do II Workshop de Desenvolvimento Rápido de Aplicações Alexandre Correa, UFRJ, Brasil Alexandre Vasconcelos, UFPE, Brasil Alfredo Goldman, USP, Brasil Claudia Werner, COPPE/UFRJ, Brasil Cristine Gusmão, UFPE, Brasil Elisa Nakagawa, USP, Brasil Jones Albuquerque, UFRPE, Brasil Leonardo Murta, COPPE/UFRJ, Brasil Marco Mangan, PUC-RS, Brasil Márcio Barros, UNIRIO, Brasil Regina Braga, UFJF, Brasil Rodrigo Reis, UFPA, Brasil Rosana Braga, USP, Brasil Rosângela Penteado, UFSCAR, Brasil Vera Werneck, UERJ, Brasil Coordenação do I Workshop de Gerenciamento de Projetos de Software Maurício Fiorese, JExperts, Brasil Comissão Julgadora do I Workshop de Gerenciamento de Projetos de Software Alfredo Tsukumo, CenPRA, Brasil Christiane Gresse von Wangenheim, UNIVALI, Alemanha Everaldo Grahl, FURB, Brasil Farhad Abdollahyan, PMI-SP, Brasil Ivo Michalick, PMI-MG, Brasil Kristiane Adorno, POLITEC, Brasil Luiz Henrique Souza, WBS-RJ, Brasil Nelson José Rosamilha, PMI-SP, Brasil Nikolai Albuquerque, Faculdade Estácio de Sá, Brasil Paulo Buzin, PMI-RS, Brasil Rivalino Matias Jr., Duke University, Brasil Sheila dos Santos Reinehr, PUC-PR, Brasil xiii

15 Sociedade Brasileira de Computação Diretoria Presidente: José Carlos Maldonado, ICMC - USP Vice-Presidente: Virgílio Augusto Fernandes Almeida, UFMG Administrativa: Carla Maria Dal Sasso Freitas, UFRGS Finanças: Paulo Cesar Masiero, ICMC - USP Eventos e Comissões Especiais: Marcelo Walter, UFPE Educação: Edson Norberto Cáceres, UFMS Publicações: Karin Breitman, PUC-RJ Planejamento e Programas Especiais: Augusto Sampaio, UFPE Secretarias Regionais: Aline Maria Santos Andrade, UFBA Divulgação e Marketing: Altigran Soares da Silva, UFAM Regulamentação da Profissão: Ricardo de Oliveira Anido, UNICAMP Eventos Especiais: Carlos Eduardo Ferreira, USP Cooperação com Sociedades Científicas: Taisy Silva Weber, UFRGS Conselho Membros Titulares Mandato Cláudia Bauzer Medeiros, UNICAMP Roberto da Silva Bigonha, UFMG Cláudio Lucchesi, UNICAMP Daltro José Nunes, UFRGS André F. de Carvalho, ICMC USP Mandato Ana Carolina Salgado, UFPE Jaime Simão Sichman, USP Daniel Schwabe, PUC-RJ Vera Lúcia Strube de Lima, PUC-RS Raul Sidnei Wazlawick, UFSC Suplentes - Mandato Ricardo Augusto da Luz Reis, UFRGS Jacques Wainer, UNICAMP Marta Lima de Queiroz Mattoso, UFRJ xiv

16 Sumário / Contents Trabalhos Técnicos A Comparison of BPMN and UML 2.0 Activity Diagrams. Daniela Peixoto (UFMG), Vitor Batista (UFMG), Ana Paula Atayde (UFMG), Rodolfo Resende (DCC/UFMG), Clarindo Pádua (UFMG) Abordagem para Implantação de testes baseada no TMM e em Práticas Ágeis... Juliana Ochner (UFPE), Alexandre Vasconcelos (UFPE) Análise de Mutantes de Aplicações SQL de Bando de Dados... Andrea Cabeça (University of Campinas), Mario Jino (FEEC-UNICAMP), Plínio Leitão-Júnior (Universidade Federal de Goiás) Atabaque : Uma contribuição de sucesso de processos... Viviane Malheiros (SERPRO, USP(ICMC)), Serge Rehem (Serpro), José Maldonado (SSC/ICMC-USP/ São Carlos) Avaliação da Qualidade de Software Através de Técnicas da Mineração de Dados... Simone Vasconcelos (UFF / CEFETCampos / ISECENSA) Avaliação de Bases de Medidas considerando sua Aplicabilidade ao Controle Estatístico de Processos de Software... Monalessa Barcellos (Universidade Federal do Espírito Santo) Desenvolvimento de um Ambiente de Apoio á Tomada de Decisões em Projetos de Software... Helio Costa (Universidade Federal do Rio de Janeiro), Gustavo Vieira (Universidade Federal do Rio de Janeiro), Luiz Claudius Leite (UFRJ), Ana Regina Rocha (COPPE/UFRJ) Estratégia para apoiar a seleção de Abordagens de Teste Baseado em Modelos para Projetos de Software... Arilo Dias Neto (COPPE/UFRJ), Guilherme Travassos (COPPE/UFRJ) Fatores humanos que influenciam a utilização de processos de software... Paula Ferreira (UFPE) Guidance for Efficiently Implementing Defect Casual Analysis... Marcos Kalinowski (COPPE/UFRJ), Guilherme Travassos (COPPE/UFRJ), David Card (Det Norske Veritas) Inspeção de Qualidade em Descrições de Casos de Uso: Uma Proposta de Modelo de Artefatos... José Eduardo Deboni (Instituto de Pesquisas Tecnológicas do Estado de São Paulo), Rosângela Gregolin (Instituto de Pesquisas Tecnologicas do Estado de São Paulo) Metodologia para Implementação do MPS.BR Utilizando o Ambiente WebAPSEE.. Vanderlene Covre (Universidade Federal do Pará), Carla Lima Reis (UFPA), Elói Favero (UFPA) Planejando e Automatizando a Geração de Casos de Teste de Unidade Utilizando Diagrama de Seqüência... Antonio Carlos Silva (Univali), Fabiane Barreto Vavassori Benitti (Univali) xv

17 ProEvaluator: Uma Ferramenta para Avaliação de Processos de Software... Juliana Xavier (SERPRO), Alexandre Vasconcelos (UFPE) Um Estudo Exploratório sobre a Satisfação do Usuário de Sistemas de Software... Tereza Kirner (Universidade Metodista de Piracicaba) Um Modelo de Avaliação da Produtividade de Projetos de Software baseado em uma Abordagem Multicritério... Adson Cunha (UFPE), João Thomaz (CEG-IST), Hermano Moura (UFPE) Um Simulador Estocástico de Processo de Software Baseado em Conhecimento... Breno França (UFPA), Rodrigo Reis (UFPA) Uma Abordagem para Condução de Iniciativas de Melhoria de Processos de Software... Mariano Montoni (Universidade Federal do Rio de Janeiro), Cristina Cerdeiral (COPPE/UFRJ), David Zanetti (UFRJ), Ana Regina Rocha (COPPE/UFRJ) Uma Estratégia de Gerência de Configuração de Ativos de Processos de Software Apoiada por um Ambiente de Engenharia de Software Centrado em Processos... Gleison Santos (COPPE/UFRJ) Uma proposta de processo de Gerência de Configuração baseado no nível 2 do CMMI estagiado para Fábricas de Software Orientadas a Produto... Karine Oliveira (UFPE), Alexandre Vasconcelos (UFPE) Relatos de Experiência 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... Gleison Santos (COPPE/UFRJ), Mariano Montoni (UFRJ), Anne Elise Katsurayama (COPPE/UFRJ), Reinaldo Cabral (COPPE/UFRJ), Sávio Figueiredo (COPPE / UFRJ), Ana Natali (COPPE/UFRJ) Aplicação dos Gráficos de Controle CUSUM Tabular para Avaliação da Aderência dos Projetos ao Processo de Software... Paula Daniele (UFPA), Lenilda Pinheiro (Serviço Federal de Processamento de Dados), Jaciane Ribeiro (UFPA), Cleidson de Souza (UFPA), Rodrigo Reis (UFPA) Avaliação de um Método para Estimativa de Esforço para Testes baseado em Casos de Uso... Erika Almeida (State University of Campinas), Bruno Abreu (UNICAMP), Regina Moraes (Universidade Estadual de Campinas), Eliane Martins (UNICAMP) Avaliação dos Efeitos da Utilização do TDD na Qualidade Interna do Produto... Carlos Zacarias Santos (Secretaria da Fazenda de Alagoas), Josué Santos (Secretaria da Fazenda de Alagoas), Reinaldo Cabral (COPPE/UFRJ), Ana Regina Rocha (COPPE/UFRJ) Comparando a Implantação de Projetos Cooperados baseados no MR-MPS através da Replicação de um Instrumento de Avaliação: Análise Quantitativa sob a ótica das Empresas... Rafael Prikladnicki (PUCRS), Odisnei Galarraga (Software process), Carlos Becker (Software process) Desenvolvimento de um Processo de Software Aderente à ISO 9001:2000 Baseado xvi

18 no Processo Ágil Scrum... Antonio Santos (UFAM), Vandermi da Silva (UFAM), Vicente Lucena (UFAM) Inspeção de Usabilidade em Organizações de Desenvolvimento de Software Uma Experiência Prática... Verônica Vaz (Federal University of Rio de Janeiro), Tayana Conte (COPPE/UFRJ), Guilherme Travassos (COPPE/UFRJ), Emilia Mendes (The University of Auckland), Andrew Bott (Fundação Coordenação de Projetos, Pesquisas e Estudos Tecnológicos) Institucionalização de processo aderente ao CMMI-DEV ML3 em uma empresa exportadora de software... Cesar Rodrigues (Vetta), Alvaro Santos (Vetta Technologies), Thiago Paiva (Vetta Technologies), Marcelo Barbosa (PUC Minas) Uma Experiência de Melhoria de Processo utilizando a Análise Casual de Defeitos. Daniela Peixoto (Federal University of Minas Gerais), Vitor Batista (UFMG), Gustavo Monti (UFMG) Uso da Ferramenta de Análise Estática Klocwork na Motorola... Rachel Reis (Eldorado Research Institute), Denise Prado (Eldorado Research Institute), Maria das Graças Fernandes (Eldorado Research Institute) Concurso de Teses e Dissertações em Qualidade de Software Dissertações de Mestrado Geração de Metadados para apoio ao teste estrutural de componentes... Autor: Vânia Somaio Teixeira, UNIVEM Orientador: Márcio Eduardo Delamaro, UNIVEM PASS: Processo de Apoio à Segurança de Software... Autor: Francisco José Barreto Nunes, Unifor Orientador: Arnaldo Dias Belchior, Unifor Prêmio Dorgival Brandão Junior de Qualidade e Produtividade em Software PBQP Software Ciclo 2007 Projetos Premiados 1º Lugar - Plataforma de Tecnologia da Informação e Comunicação de Santa Catarina PLATIC... Carlos Eduardo Bizzotto (Universidade Regional de Blumenau FURB), Eliza Coral (Instituto Euvaldo Lodi de Santa Catarina IEL/SC), Valéria Arriero Pereira (Instituto Euvaldo Lodi de Santa Catarina IEL/SC) 2º Lugar - IACS Identificação Automática de Componentes de Software... Marcílio Oliveira (Laboratório de Inovação DigitalAssest/ Ci&T - Universidade Estadual de Campinas - UNICAMP), José Vahl (Laboratório de Inovação DigitalAssest/ Ci&T - Universidade Estadual de Campinas - UNICAMP), Kleber Bacili (Laboratório de Inovação DigitalAssest/ Ci&T) 3º Lugar - Avaliação de Riscos Aplicada à Qualidade em Desenvolvimento de Software... Alberto Bastos (Módulo Security), Gustavo Carvalho (Prime Up Soluções em TI Ltda), Leandro Daflon (Prime Up Soluções em TI Ltda), Rafael Espinha(Prime Up Soluções em TI Ltda) xvii

19 xviii

20 VII Simpósio Brasileiro de Qualidade de Software Trabalhos Técnicos

21

22 A Comparison of BPMN and UML 2.0 Activity Diagrams Daniela C. C. Peixoto 1, Vitor A. Batista 1, Ana P. Atayde 1, Eduardo P. Borges 1, Rodolfo F. Resende 2, Clarindo Isaías P. S. Pádua 1. 1 Synergia Universidade Federal de Minas Gerais 2 Departamento de Ciência da Computação Universidade Federal de Minas Gerais Av. Antônio Carlos CEP Belo Horizonte MG - Brasil {cascini, vitor, atayde, eborges, rodolfo, clarindo}@dcc.ufmg.br Abstract: Interest in evaluating Business Process Modeling Languages has widespread, in part due to the increase of the number of languages available for this purpose. Several works on the evaluation of BPMLs are available. Their evaluation are mainly based on perspectives centered in modeling experts. In this paper, we address the readability perspective of two BPMLs (UML 2.0 and BPMN) for people not familiar with process modeling. The UML can be tailored for purposes beyond software modeling and offers Activity Diagrams for business process modeling. BPMN was designed for modeling business process and has a primary goal of being understandable by all business stakeholders. We compared undergraduates (freshmen) understanding of business process modeled in BPMN and UML 2.0 Activity Diagrams. Our results are interesting, since we were able to find that these two languages do not have significant differences, despite BPMN readability design goals. 1. Introduction A business process modeling focus on describing activities within the business and how they interact with the resources in the business to achieve a goal. According to Penker [Eriksson & Penker, 2000] a business process model may have six different reasons to be created, which are: to understand the key mechanisms of an existing business; to orient the creation of suitable information systems that support the business; to implement improvements in the current business; to show the structure of an innovated business; to experiment new business concepts; and to identify business elements not considered part of the core, which could be delegated to an outside supplier. The increasing interest in business process modeling has resulted in the appearance of various Business Process Modeling Languages (BPMLs). Today, there are several notations that can be used for business process modeling [List & Korherr, 2006]: UML 2.0 Activity Diagram [OMG, 2005], Business Process Modeling Notation [OMG, 2006], Event Driven Process Chain (EPC) [Scheer, 1999], Integrated DEFinition Method 3 (IDEF3) [Mayer & Perakath, 1995], and others. These languages express certain aspects of processes, for example, activities and roles, and address different application areas. However 1

23 no one of these languages is predominant in the business process modeling area [Mendling et al., 2004]. One major reason [zur Muehlen, 2004] is the wide disparity in the needs and viewpoints of various modelers and designers. There are many different stakeholders interested in the results of a business process modeling. They correspond to people that participate in the process directly or indirectly as the owner, external customers (example: business modelers or designers) and internal customers (example: managers or employees). The owner sets the goals and allocates the resources to make the business run. The business modeler describes the processes using specific notations and tools [Eriksson & Penker, 2000]. It is important to note that the internal business customers do not need to be an expert in these BPMLs, they only need to understand the results of the modeling, more specifically, and they should know how to read business process diagrams. Before the selection of an appropriate business modeling language, the modelers and designers should observe the kind of process being modeled and the purpose for which the modeling is being done [Russell et al., 2006b]. This article investigates two BPMLs - UML 2.0 Activity Diagrams (AD) and BPMN - capacity of being readily understood. Our main contribution consists of an experiment with computer science students (freshmen) representing internal customers reading business process diagrams. The Unified Modeling Language (UML) [OMG, 2005] is increasingly being seen as a de facto standard for software modeling and design. UML is an object-oriented notation that embodies a set of formalisms for capturing detailed design aspects of software systems. The UML can be tailored for several purposes and its Activity Diagram can be used for business process modeling [Wohed et al., 2005]. Business Process Modeling Notation (BPMN) was designed for modeling business process and their transformation into an execution language. The primary goal of the BPMN is to be understandable by all business stakeholders [OMG, 2006]. We originally expected that BPMN models were easier to understand than UML 2.0. This assumption was derived from the fact that BPMN primary goal was to be understandable by all business stakeholders. Furthermore, BPMN has model elements that, in some cases, do not have a correspondent element in UML 2.0 AD. The comparison in our work is based on Workflow Patterns, a taxonomy of generic, recurring constructs originally devised to evaluate workflow systems, and more recently used to successfully evaluate workflow standards, business process languages and processaware information systems in general [White, 2004], [Wohed et al., 2003]. The remainder of this paper is structured as follows. Section 2 presents some works that describe evaluations of BPMLs. Section 3 presents the workflow patterns. Section 4 describes the methodology used for comparing UML 2.0 AD e BPML. Section 5, 6 and 7 reports the results achieved. Section 8 concludes and suggests future work. 2

24 2. Related Work In BPML related works the evaluated concepts are mainly based on meta-models, which address a very technical perspective. List and Korherr [List & Korherr, 2006], for example, propose a generic meta-model for evaluating BPMLs. This meta-model is categorized using five perspectives, inspired by business process theory [Ould, 1995], Workflow Patterns [Russell et al., 2006a], and the Workflow Management Coalition (WfMC) [WMC, 1998]: Organizational: represents where and by whom (agents) process elements are performed; Functional: represents the process elements which are being performed, e.g., activities; Behavioral: represents when and how process elements are performed; Informational: represents the informational entities produced or manipulated by a process; and Business process context: provides an overview perspective of the process and describes major business process characteristics, such as goals. List and Korherr evaluated seven BPMLs, including UML2.0 Activity Diagram [OMG, 2005], Business Process Modeling Notation (BPMN) [OMG, 2006], Business Process Definition Metamodel (BPDM) [OMG, 2004], Role Activity Diagram (RAD) [Holt & Grimes, 1983], Event Driven Process Chain (EPC) [Scheer, 1999], and Petri Net [Gou et al., 2000]. They observed that the functional and the behavioral perspectives are very well represented in all BMPLs, while the organizational and informational perspectives are only partly supported, and business process context is not explicitly supported. Russell examines the suitability of UML 2.0 Activity Diagrams for business process modeling, using Workflow Patterns [Russell et al., 2006b] as an evaluation framework. The pattern evaluation shows that UML 2.0 Activity Diagrams is not suitable for representing all aspects of this type of modeling. It offers support for control-flow and data perspective allowing most of the constructs to be directly captured. However, it is extremely limited in modeling resource-related or organizational aspects of business process. These limitations are shared with most of the other BPMLs, showing the emphasis that has been placed on the control-flow and data perspectives in these notations. White [White, 2004] examines whether two modeling notation, BPMN and UML 2.0 Activity Diagrams, can graphically represent the control flow workflow patterns. White examined 21 workflow patterns and observed that they could adequately model most of them. Both notations provide similar solutions for most of the patterns indicating how close the notation is in their presentation. The similarities in the two diagrams are explained by the fact that both were designed to solve the problem of the diagramming of procedural business processes. Some differences are due to the fact that they have different target users of diagrams: business people for BPMN, and software developer for UML 2.0 (this language is more technically oriented). It is interesting to observe that in all these evaluations, characteristics related to the consumption of business modeling results (legibility, for example) are not addressed at all. 3

25 3. Workflow Patterns Russel et al [Russell et al., 2006a] identify patterns in four perspectives 1 : control-flow, data, resource and exception handling. The control-flow perspective captures aspects related to control-flow dependencies. Originally twenty patterns were proposed for this perspective, but in the latest revision this has grown to forty-two patterns. This perspective includes patterns for Basic Control Flow, Advanced Branching and Synchronization, Multiple Instance, Cancellation and Force Completion, Iteration, Termination and Trigger The data perspective represents the definition and use of data elements (visibility), information passing, data transfer and interaction with other perspectives. This perspective includes patterns for Data visibility, Data Interaction (Internal Data Interaction and External Data Interaction), Data Transfer Mechanisms and Data-based Routing. The resource perspective captures the various ways in which resources are represented and utilized in workflows. This perspective includes patterns for Creation, Push, Pull, Detour, Auto-Start, Visibility, and Multiple Resource. Finally the patterns for the exception handling perspective deal with the various causes and the resultants actions need to be taken as a result of exception occurrences. All these patterns range from very simple to very complex aspects of business process models. 4. The experiment In this section, we described the techniques used to analyze UML 2.0 AD and BPMN related to the legibility of the business process model. We have conducted a controlled experiment to examine this characteristic based on end-users point of view. Our strategies follow the experiment process defined by Wohlin et al. [Wohlin et al., 2000] that consists of five activities: definition, planning, operation, analysis & interpretation, and presentation & package. With this experiment we evaluated the reading activity of a notation, which is the process of parsing a notation and creating an understanding of it [Wright & Cockburn, 2005]. We do not evaluate other tasks executed when modeling business process, e.g., writing Hypothesis This evaluation tests the hypothesis that using a BPMN notation for a business process model is easier to understanding than using UML 2.0 AD notation. 1 See for more details. 4

26 4.2. Experiment details The experiment was conducted with 35 undergraduate computer science students. All participants were in the first year of this course. During this experiment, these students represent internal customers, so they need to read and understand business process diagrams. At the experiment beginning, the instructor explained to the participants what they were expected to do during that experiment. Firstly, the participants answered a questionnaire with the purpose of collecting their knowledge about the subject under study: business process domain (a retirement process) and BPMNs. After that, the students were randomly assigned to one version of the diagrams (BPMN or in UML 2.0 AD). Every student saw four diagrams and answered 11 true/false questions related to the semantics of the diagrams. The diagrams modeled government retirement process. The diagrams were selected from models produced in three months by a team of five experienced business process modelers. These models were produced with the aim to document and guide the improvement of the organization. We decided to choose diagrams from real project since there is no business process models database available to be used as a benchmark. Figure 1 shows an example of BPMN diagram used in the experiment. Figure 2 shows the same diagram modeled in UML 2.0. The diagrams were organized in two levels of abstraction. The first level shows the main processes and the second level shows sub-processes details. The diagrams were available in HTML format and the students could navigate through all levels of these diagrams. Both notations were implemented in Sparx Enterprise Architect tool and they were modeled, in both languages, in a very similar way. Whenever possible, processes, objects and other elements of these notations were equally arranged. The diagrams were chosen trying to maximize usage of the following workflow patterns. These patterns summarize the findings presented in [Russell et al., 2006a], thus serving as a guide for the evaluation of BPMN and UML 2.0 AD. WCP-1: Sequence the ability to depict a sequence of activities, with one activity starting after a previous activity has completed; WCP-2: Parallel split the ability to execute activities concurrently; WCP-3: Synchronization the ability to capture a convergence of two or more branches, generated by the Parallel split pattern, into a single subsequent branch; WCP-4: Exclusive choice the ability to represent a decision point where only one of the branches is chosen; WCP-5: Simple merge the ability to show the convergence of two or more branches into one, without synchronization. WCP-6: Multi-choice the ability to depict a divergence of a branch into two or more parallel branches on a selective bases; WCP-10: Arbitrary cycles the ability to represent loops in a process that have more than one entry or exit point. WCP means Workflow Control Pattern. Each question was assigned to a main goal, that is, each question was assigned to the workflow pattern(s) related to it. This assignment 5

27 was helpful in order to map the use of each pattern in the diagrams. Table 1 illustrates this relation. Figure 1 A BPMN diagram used in the experiment An example of a question that evaluates Arbitrary Cycles and Multiple choice (Question number 10 Table 1) is The activity Sanar Irregularidades could be executed several times during the whole process execution. True or False?. Figure 3 shows an excerpt from a diagram related to this question. Participants were given as much time as needed to complete the task and the instructor collected the questionnaires with the answers after they have finished. 6

28 Figure 2 - UML 2.0 diagram used in the experiment. Table 1 - Purpose of each question and patterns used Question What was evalutated Patterns used 1 Simple activities sequence Sequence 2 Branch after decisions Sequence, Exclusive Choice 3 Use of artifacts and decisions Sequence (multiple diagrams), Exclusive Choice 4 Roles and multiple diagrams 5 Roles and decisions Sequence (multiple diagrams), Exclusive Choice, Simple Merge 6 Branch after decisions Sequence, Exclusive Choice, Simple Merge 7 Parallelism and synchronization Synchronization 8 Roles 9 Decisions over multiple diagrams 10 Loops over multiple diagrams Sequence (multiple diagrams), Simple Merge Multiple choice, Arbitrary Cycles 11 Messages between roles Synchronization 7

29 Figure 3 - Excerpt of diagram used in the experiment to evaluate arbitrary cycles 5. Preliminary Results According to profile forms, no students have had experience with any of these notations before or with the kind of business that was modeled in the diagrams (government retirement process). To examine the hypothesis stated we used Mann-Whitney test [Triola, 2008] since data is not normally distributed to compare the scores on each question and the total score for both questionnaires. Table 2 shows the global score for each notation. This score was calculated dividing the number of correct answers by the number of questions (11 in this case). Table 3 shows a per question comparison using proportion of correct answers. All results presented in this paper have 95% of confidence. These tables show an interesting pattern of results. The number of correct answers obtained in both languages is very similar. Table 2 - Global results: percentage of correct answers. Notation Forms Mean StDev UML BPMN

30 Table 3 - Correct answers per question Comparison of proportion of correct answers between notations Note that UML has 17 forms and BPMN Confidence 18 Correct answers Interval of Proportion proportion Question UML BPMN Difference difference P-value (0,033; 0,436) (-0,204; 0,217) (-0,178; 0,446) (-0,027; 0,511) (-0,063; 0,566) (-0,124; 0,248) (-0,454; 0,016) (-0,077; 0,443) (-0,166; 0,297) (-0,350; 0,141) (-0,004; 0,357) Table 3 shows that UML questions were easier for students to answer in only 2 of 11 questions. However, only question number 1 had a significant difference between notations (note that in all other questions, the confidence interval of difference includes zero) Time Mann-Whitney test did not show that the task in one notation was completed faster than in the other one. Participants needed a mean of ± 2.11 minutes to answer the questionnaire in BPMN and a mean of ± 2.96 minutes to answer the same questionnaire in UML 2.0 AD Hit rate Mann-Whitney test also did not show any differences in the results related to hit rate of the answers. Participants achieved a mean of 9.44 correct answers of 11 in BPMN and a mean of 8.41 in the same questionnaire in UML 2.0 AD. Figure 4 shows the interval plot of the results presented in Table 2. Observe the overlapped confidence intervals. 6. Comments from Participants After taking part, participants were asked about the clarity of the questions. General comments: 6% of the participants commented the questions were hard, and they needed some training for doing better. 68% said they had some difficult in understanding the questions, but they were able to do it, and 26% thought the questions were easy and could understand them with no major problems. 9

31 UML 2.0 AD: four of seventeen participants dealing with UML 2.0 AD diagrams found that it was easy to answer the questions, 12 found difficult, but not too much, and one found it was very hard to answer the questions. BPMN: five of eighteen participants dealing with the BPMN diagrams found easy to answer the questions, 12 found it that was difficult, but not too much, and one found it was very hard to answer the questions. 10,5 Interval Plot of UML; BPMN 95% CI for the Mean 10,0 9,5 Data 9,0 8,5 8,0 UML BPMN Figure 4 Hit rate of answers 7. Additional Comments With these results, we could not confirm that exist differences in the business modeling using BPMN and UML 2.0 Activity Diagrams from the point of view of end user readability. However, in our study we have analyzed only workflow patterns described in Table 1. This suggests that, as far as these patterns are concerned, the level of difficult for understanding the business process, in both languages, is the same. Our proposed hypothesis that using a BPMN notation for a business process model is easier to understanding than using UML 2.0 AD notation was rejected. 8. Conclusions and future work This paper describes an evaluation examining the readability of business models written in BPMN and UML 2.0 AD. We used computer science freshmen not familiar with the languages and with the modeled domain, representing internal customers of one organization. We originally expected that BPMN models were easier to understand than UML 2.0 AD. This assumption was derived from the BPMN primary goal and its distinct model elements not present in UML 2.0 AD. Our study does not offer evidence that exist differences in modeling using BPMN and UML 2.0 Activity Diagrams from the point of view of end user readability. Indeed, we 10

32 hope that these results provide more information to organizations in deciding to adopt or not a new notation for business process modeling. In our study we have analyzed only workflow patterns described in Table 1. This suggests that using these patterns the level of difficult for understanding the business process, in both languages, is the same. This restriction is an important scope for future work. It is important to determine whether there are differences in the results using other workflow patterns. It is also important to determine if there are differences in other modeling activities like model writing. Other research questions include: Is this lack of difference due to a limited use of workflow patterns? To answer this question we need to run experiments using other workflow patterns. Re-running this evaluation will tell us with a greater level of confidence the differences between these notations. Does the difference exist on the writing activity? To answer this question we need to run evaluations concentrating on the writing activities. This evaluation will give us a base to examine the effect of each notation. References [Eriksson & Penker, 2000] Eriksson, H., & Penker, M Business Modeling with UML: business patterns at work. John Wiley & Sons. [Gou et al., 2000] Gou, H., Huang, B., Liu, W., Ren, S., & Y., Li Petri-net-based business process modeling for virtual enterprises Systems. Pages of: IEEE International Conference on Man, and Cybernetics, 2000, vol. 5. [Holt & Grimes, 1983] Holt, A, Ramsey R., & Grimes, J Coordinating System Technology as the Basis for a Programming Environment. Electrical Communication, 57(4), [List & Korherr, 2006] List, Beate, & Korherr, Birgit An evaluation of conceptual business process modelling languages. Pages of: SAC '06: Proceedings of the 2006 ACM symposium on Applied computing. New York, NY, USA: ACM Press. [Mayer & Perakath, 1995] Mayer, R., Menzel C. Painter M. Witte P. Blinn T., & Perakath, B Information Integration for Concurrent Engineering (IICE) IDEF3 Process Description Capture Method Report. Tech. rept. Knowledge Based Systems Inc. (KBSI). [Mendling et al., 2004] Mendling, J., uttgens, N., & Neumann, M A Comparison of XML Interchange Formats for Business Process Modelling. [OMG, 2004] OMG (January). Business Process Definition Metamodel - Version [OMG, 2005] OMG Unified Modeling Language Specification, version 2.0. Object Management Group (OMG). 11

33 [OMG, 2006] OMG Business Process Modeling Notation Specification. Object Modeling Group. [Ould, 1995] Ould, M Business Process Modeling and Analysis for Reengineering and Improvement. John Wiley & Sons. [Russell et al., 2006a] Russell, N., ter Hofsted, A.H.M., van der Aalst, W.M.P., & Mulyar, N. 2006a. Workflow Control-Flow Patterns: A Revised View. Tech. rept. BPM Center Report BPM [Russell et al., 2006b] Russell, Nick, van der Aalst, Wil M. P., ter Hofstede, Arthur H. M., & Wohed, Petia. 2006b. On the suitability of UML 2.0 activity diagrams for business process modelling. Pages of: APCCM '06: Proceedings of the 3rd Asia-Pacific conference on Conceptual modelling. Darlinghurst, Australia, Australia: Australian Computer Society, Inc. [Scheer, 1999] Scheer, A. W ARIS Business Process Modeling. 2nd edition edn. Springer Verlag. [Triola, 2008] Triola, Mario F Introdução à Estatística. 10a. edição edn. LTC Editora. [White, 2004] White, Stephen A Process Modeling Notations and Workflow Patterns. [WMC, 1998] WMC Workflow Management Coalition. Interface 1: Process Definition Interchange Process Model, WfMC TC M (1998). [Wohed et al., 2003] Wohed, P., Perjons, E., Dumas, M., & ter, A Pattern based analysis of EAI languages - the case of the business modeling language. [Wohed et al., 2005] Wohed, Petia, van der Aalst, Wil M.P., Dumas, Marlon, ter Hofstede, Arthur H.M., & Russell, Nick Pattern-based analysis of the control flow perspective of UML activity diagrams. In: ER 2005: 24th International Conference on Conceptual Modelling. Springer Verlag. [Wohlin et al., 2000] Wohlin, Claes, Runeson, Per, Höst, Martin, Ohlsson, Magnus C., Regnell, Björn, & Wesslén, Anders Experimentation in Software Engineering, An Introduction. Kluwer Academic Publishers. [Wright & Cockburn, 2005] Wright, Tim, & Cockburn, Andy Evaluation of two textual programming notations for children. Pages of: AUIC '05: Proceedings of the Sixth Australasian conference on User interface. Darlinghurst, Australia, Australia: Australian Computer Society, Inc. [zur Muehlen, 2004] zur Muehlen, M.; Rosemann, M Multi-Paradigm Process Management. Pages of: Janis Grundspenkis, Marite Kirikova, Riga Latvia (ed), Proceedings of CAiSE'04 Workshops - 5th Workshop on Business Process Modeling, Development and Support (BPMDS 2004). 12

34 13

35 14

36 Abordagem para Implantação de Testes baseada no TMM e em Práticas Ágeis Juliana Ochner 1, Alexandre Vasconcelos 1, Roberto Mendes 1 1 Centro de Informática Universidade Federal de Pernambuco (UFPE) Recife PE Brasil {jo, amlv, rdm}@cin.ufpe.br Resumo. Este artigo descreve uma abordagem para implantação de testes de software baseada no TMM e em práticas ágeis com o objetivo de viabilizar a melhoria e implantação de processos de testes em empresas que necessitam de resultados rápidos e com poucos investimentos. Para a validação da abordagem, ela foi aplicada em duas empresas de desenvolvimento de software. Este artigo apresenta a abordagem desenvolvida, uma aplicação prática e as conclusões. Abstract. This paper describes an approach to improve software test process based on TMM and agile practices in order to make feasible the improvement and implementation of software test process on the organizations that need fast results with low costs. To validate the approach, it was applied in two software companies. This article presents the developed approach, a practical application and conclusions. 1. Introdução Nas últimas décadas, indústrias de software têm investido um esforço substancial na melhoria da qualidade de seus produtos. Este tem sido um trabalho difícil, já que o tamanho e a complexidade do software aumentam rapidamente, os usuários e clientes estão se tornando mais exigentes e o mercado cada vez mais competitivo [Vasconcelos et al, 2006]. Pensando nisso, muitas empresas estão buscando implantar ou melhorar seus processos de teste. Com o intuito de facilitar a melhoria de processo de software, diversos modelos têm surgido nas últimas décadas. São modelos que fornecem diretrizes para guiar iniciativas de programas de melhoria de software, tais como IDEAL [McFeeley, 1996], ISO/IEC [ISO 15504, 2005] e Pro2Pi [Salviano, 2006]. Existem também modelos de referência específicos para a definição de requisitos necessários a um Processo de Testes, tais como: TMM ( Test Maturity Model) [Burnstein, 2003], TIM (Test Improvement Model) [Ericson, 1996] e TPI (Test Process Improvement) [Koomen, 1999]. Embora tenham surgido tais modelos grande parte da indústria de software ainda apresenta muitas dificuldades em realizar um programa de melhoria de processo de testes de software efetivo. Isto ocorre por uma série de motivos, conforme descrito em [Niazi, 2003], [MCT_01, 2001], [Santana, 2007] e [Carosia, 2003]. Dentre estes motivos, há o fato dos modelos de melhoria ser genéricos e exigirem diversas 15

37 adaptações para tratar as dificuldades comumente encontradas em um programa de melhoria de testes. Adaptar, para a necessidade da organização, um modelo detalhado não é uma tarefa fácil, pois é necessário um conhecimento do modelo completo para que sejam escolhidas quais atividades serão realmente úteis. Devido ao grande escopo e ao alto grau de detalhamento destes modelos de melhoria, esta é uma tarefa bastante trabalhosa e complexa. Brodman [Brodman, 1994] afirma que um número alto de programas de melhoria de software baseado em modelos como CMM [Humphrey, 1989] e IDEAL falham e que 53% dos casos de falha estão relacionados à complexidade e tamanho destes modelos. Por outro lado, modelos de referência específicos, como o TMM, não fornecem o como fazer fornecem somente o que fazer para que a empresa possa atingir um dos seus níveis de maturidade. Diante deste cenário, foi elaborada uma abordagem simples e ágil, utilizando pra isso práticas ágeis, que combine os benefícios dos modelos de melhoria de processo com os benefícios fornecidos pelos modelos de referência em testes, no nosso caso o TMM, que foi escolhido por ser o modelo focado em testes mais conhecido [Freesz, 2004], [Reffson, 2006], [Santos, 2006]. Tal abordagem deve atender as necessidades das empresas, que necessitam melhorar seus processos de testes rapidamente mesmo, possuindo todas as limitações apresentadas acima, para conseguir competir no mercado do qual elas fazem parte. Além desta seção introdutória, este artigo está organizado nas seguintes seções: a seção 2 descreve a abordagem proposta; a seção 3 descreve o estudo de caso realizado e a seção 4 as conclusões. 2. Abordagem AITS A abordagem AITS (Abordagem para Implantação de Teste de Software) foi elaborada para um contexto caracterizado por organizações intensivas em software com processos de testes de baixa maturidade, que queiram iniciar um ciclo de melhoria de teste o mais rápido possível, investindo poucos recursos e com resultados de curto prazo. Ela é uma adaptação do modelo de melhoria IDEAL e específica para o contexto de implantação de processo de teste de software, utilizando o TMM [Burnstein, 2003] como modelo base de referência para o programa de melhoria e inserindo práticas ágeis presentes no Scrum [Schwaber, 2004] e XP [Beck, 1999]. A abordagem definida está organizada em fases, atividades e templates 1 conforme exibido na figura 1. Algumas fases definidas estão inseridas em uma iteração. Cada iteração terá a duração máxima de 30 dias aproximadamente, conforme definido no Scrum. A adoção desta prática na abordagem se faz necessária para apresentar resultados em um curto espaço de tempo para a organização, motivar os envolvidos com o programa de melhoria e diminuir a resistência em relação às mudanças propostas, já que os benefícios estarão sendo percebidos ao final de cada iteração. 1 Todos os templates mencionados neste artigo podem ser visualizados através do site: 16

38 Figura 1 - Ciclo da abordagem AITS Para a sua aplicação prática, a abordagem necessita que um pequeno time de condutores seja formado para coordenar e conduzir todas as fases durante um programa de melhoria. As pessoas que farão parte do time de condutores deverão possuir preferencialmente os seguintes requisitos para que a abordagem seja aplicada corretamente: experiência em qualidade de software e modelos de melhoria de processos, conhecimento sobre testes de software, boa influência e respeito na organização, boa comunicação. O time de condutores deve possuir preferencialmente as seguintes características: Ter entre 2 e 3 integrantes. É necessário que haja troca de idéias e conhecimentos entre os integrantes do time de condutores. Acredita-se que o time de condutores também não deve ter um número alto de integrantes, 3 seria um número máximo ideal, para que o time não perca o foco do trabalho. Além disso, os times de testes são geralmente pequenos, o que torna desnecessário a formação de um time de condutores com muitas pessoas. Cada integrante deverá dedicar pelo menos 50% da sua jornada de trabalho para a condução do programa de melhoria através da abordagem. Isto ocorre porque, na maioria das vezes, os integrantes do time de condutores têm um acúmulo de papéis por causa da falta de recursos financeiros da organização, por isso a abordagem não exige dedicação integral do condutor no programa, mas sua dedicação deve ser pelo menos 50% para que o programa tenha um bom andamento. Não é indicado que nenhum participante do programa de melhoria trabalhe mais do que 8 horas diárias, pois isso pode prejudicar fortemente o seu desempenho no programa. Assim, o princípio de Ritmo Sustentável de XP deve ser seguido pelos participantes do programa de melhoria. Conhecimentos sobre a Abordagem AITS. O time de testes não deve ser superior a 12 pessoas, conforme utilizado no XP e no Scrum. A adoção desta prática se faz necessária para maximizar a comunicação entre 17

39 todos os membros do time e manter o feedback constante entre eles, com o aumento da equipe torna-se difícil manter uma comunicação efetiva Fase 1 Inicialização Esta fase é iniciada a partir do momento que a alta direção decide iniciar um programa de melhoria na organização. É nela que a alta direção entende a necessidade, se compromete e define o contexto para o programa de melhoria. Nela o comprometimento da alta direção é obtido. As atividades envolvidas nesta fase são: Obter Comprometimento dos Interessados: Os interessados no programa de implantação de testes devem estar comprometidos com o programa, para isto, é necessário: reconhecer e entender o estímulo para a melhoria, verificar objetivos de negócio da organização, estabelecer o contexto para a melhoria, obter o comprometimento da alta direção e dos principais interessados. Kickoff do Projeto: O programa de melhoria deve ser encarado pelos envolvidos como um projeto, que tem início, meio e fim. Todos os envolvidos devem estar cientes qual é o objetivo do programa, quais as dificuldades e benefícios que este programa trará para a empresa. Uma apresentação deve ser realizada para toda a empresa para fornecer informações sobre o programa de melhoria de testes para todos os envolvidos. Esta apresentação deve ser realizada para que todos os envolvidos obtenham ciência do programa de melhoria, sintam-se parte dele e o conheça como um todo. Com isso, espera-se que todos se sintam beneficiados com o sucesso do programa de melhoria e estejam estimulados para que isso aconteça. Assim, os princípios de Posse Coletiva e Time Inteiro utilizados no XP são aplicados nesta atividade Fase 2 Diagnóstico O principal objetivo desta fase é entender o processo de testes atual utilizado pela empresa, assim como as interações organizacionais e como tudo isso contribui com o negócio da organização. As atividades desta fase são: Realizar Diagnóstico: esta atividade tem como principal objetivo realizar a avaliação da situação e do processo de testes atual da organização. A avaliação é realizada pelo time de condutores, baseada em um checklist elaborado a partir das práticas e sub-práticas definidas no modelo de maturidade em testes TMM para os níveis 2 e 3. Entrevistas com representantes-chaves das áreas de testes, requisitos e planejamento de projeto são realizadas. Compilar Resultados: A partir das observações resultantes da avaliação é atribuída uma nota a cada pergunta que indica desde o não atendimento a esta pergunta ao completo atendimento. Com isso, é possível compilar os resultados do diagnóstico, identificando os pontos fortes e as oportunidades de melhorias levantados e corroborados nas entrevistas. Com os resultados do diagnóstico, o time de condutores deverá classificar o processo de testes avaliado em um dos dois níveis de maturidade do TMM considerado por este trabalho. Para ajudar o trabalho dos condutores e evitar erros na classificação de maturidade do processo, o próprio checklist de avaliação determina automaticamente 2 em qual nível do TMM aquele processo se encaixa, seguindo as notas 2 O checklist automático foi elaborado no excel. 18

40 atribuídas. O processo de classificação seguido pelo checklist de avaliação é muito semelhante ao algoritmo de classificação definido do TMM. Abaixo é descrito o processo de classificação utilizado pelo checklist de avaliação da abordagem AITS: Questões que tiveram as opções Não se Aplica ou Não Sei selecionadas não serão consideradas para avaliação, ou seja, serão retiradas do cálculo. Estas opções deverão ser utilizadas em casos extremamente particulares não podendo representar mais do que 10% das respostas do checklist de avaliação para não comprometerem o resultado da avaliação. As opções Não, Parcialmente e Sim correspondem aos seguintes pesos 0, 1 e 2 respectivamente no resultado da avaliação do processo de teste. O Resultado Final é dado da seguinte maneira: se o total de pontos adquiridos nas questões para cada área de processo do TMM for maior ou igual a 70% dos pontos válidos, a área de processo avaliada será considerada como satisfeita. Se todas as áreas de processo do nível forem satisfeitas, o processo de teste será considerado Aprovado naquele determinado nível do TMM. Caso contrário, será considerado como Reprovado. Ressaltando que para o processo de testes seja considerado no nível 3 do TMM, será necessário que ele satisfaça todas as áreas de processo dos níveis 2 e 3. O critério de aprovação do AITS é considerado bastante arrojado se comparado com o TMM-AM. Isto se deve ao fato do checklist possuir um menor número de questões que conseguem atender as sub-práticas do TMM, fazendo com que estas questões tenham maior representatividade e peso frente às sub-práticas que elas representam. Além disso, o checklist de avaliação da AITS possui a opção Parcialmente, o que pode elevar a pontuação final da avaliação se considerado com o TMM-AM que não possui esta opção. Apresentar Diagnóstico: Deve ser elaborado um relatório final da avaliação contendo os resultados do diagnóstico, este relatório é apresentado à alta direção da empresa. Deve ser também realizada uma apresentação contendo um resumo da avaliação para todos os membros diretamente envolvidos com a área de testes e com programa de melhoria. Esta atividade tem como principal objetivo fornecer uma visão geral do processo de teste atual para todos os interessados no programa. É muito importante que esta apresentação seja realizada para estimular a comunicação e o feedback contínuo entre os integrantes do programa de melhoria e obter um entendimento comum em relação ao estado atual do processo de teste da organização. Nesta atividade são aplicados os princípios de Comunicação e Feedback presentes no XP. Template do Checklist: Este template foi elaborado a partir de uma adaptação do questionário de avaliação do TMM-AM níveis 2 e 3. A principal diferença entre os dois documentos é que o checklist da AITS foi customizado para se tornar um artefato mais simples e mais objetivo, possibilitando um melhor entendimento das questões por parte dos entrevistadores e dos entrevistados, tornando assim, a fase de avaliação mais dinâmica e fornecendo uma compreensão mais rápida aos interessados no programa. O checklist de avaliação da AITS possui 64 questões que cobrem todos os objetivos estabelecidos nas áreas de processo do TMM níveis 2 e 3, enquanto o questionário de avaliação apresentado no TMM-AM possui 104 questões para cobrir os mesmos objetivos. Isto se deve ao fato de que algumas questões do 19

41 TMM-AM não foram consideradas no questionário de avaliação da AITS por não serem relevantes para o contexto definido neste trabalho. Além disso, algumas questões do TMM-AM também foram diluídas ao longo do checklist de avaliação da AITS. É importante ressaltar que embora o checklist tenha sido adaptado, ele mantém a cobertura em relação a todos os objetivos definidos pelo TMM nos níveis citados. Template do Relatório Final da Avaliação e Template da Apresentação da Avaliação Fase 3 - Identificar e Priorizar Ações de Melhoria O objetivo desta fase é identificar e priorizar as ações a serem estabelecidas em cada iteração do programa de melhoria de testes da organização. Para isto, os resultados da fase de diagnóstico devem ser considerados. Após a primeira iteração finalizada, as análises e experiências passadas também devem ser observadas. Identificar Ações: Identificar as ações que devem ser realizadas para que os pontos de melhoria levantados sejam resolvidos. Um template com ações padrões foi elaborado baseado em experiências anteriores de melhoria de processos de testes e as ações aderentes às práticas do TMM níveis 2 e 3. Ações padrões não podem ser substituídas ou removidas, pois todas as ações existentes no documento têm uma relação direta com as práticas do TMM. Sendo assim, é necessário que elas sejam implementadas para que a empresa atinja o nível desejado do TMM. Priorizar Ações: as ações a serem tomadas deverão ser priorizadas através de critérios que determinarão quais ações devem ser consideradas mais urgentes para a organização e deverão estar nas primeiras iterações do plano de ação. É importante ressaltar que as ações referentes às práticas do TMM nível 2 terão maior prioridade em relação às ações do TMM nível 3 por serem mais básicas e darem suporte para ações do nível 3. Por isso, a pré-priorização e a priorização final só fazem sentido para ações que estão no mesmo nível do TMM. É necessário que a priorização final seja feita com base nos seguintes critérios pra cada ação: análise SWOT [Johnson, Scholes e Sexty, 1989], benefícios esperados com sua implementação para a organização, custo de implementação desta ação, interdependência em relação a outras ações. Um template foi elaborado para avaliar a priorização final das ações considerando todos os critérios citados. A pontuação final é derivada do somatório da pontuação obtida em cada critério apresentado. Em caso de empate, fica a critério dos condutores escolherem a ação mais prioritária. A priorização das ações se faz necessária para definir o escopo de entrega de cada iteração, priorizando as ações que possuem mais urgência para a organização. Com isso, nesta atividade é feita a aplicação do princípio Jogo do Planejamento utilizado no XP. As ações pertencentes às próximas iterações constituem o backlog do programa de melhoria aplicando o mesmo conceito de backlog utilizado no Scrum. Elaborar Plano de Ação: Esta atividade consiste em elaborar um plano de ação iterativo e incremental, este plano deve considerar as práticas priorizadas e agrupadas por iterações. As práticas mais prioritárias devem estar nas primeiras iterações do plano. É fortemente recomendado que no máximo 10 ações sejam selecionadas por iteração, a fim de que a equipe de testes não seja sobrecarregada em suas atividades e as mudanças 20

42 sejam introduzidas gradativamente utilizando o princípio de Pequenas Versões presente no XP. O template do plano de ação definido é divido em iterações, e as iterações são constituídas por ações. O plano ainda contempla a execução de um projeto piloto ao final de cada iteração. Templates: Template de Ações Padrões, Template de SWOT, Template de Priorização, Template Plano de Ação Fase 4 Implementar Ações de Melhoria O objetivo desta fase é colocar em prática as ações de melhoria planejadas de acordo com o plano de ação. Executar Ações: Uma vez que o plano de ação foi estabelecido, é necessário implementar as ações planejadas. Nesta fase, deverá ser incluída também a execução do piloto, a fim de avaliar e exercitar o entendimento da equipe em relação às novas ações. Os artefatos gerados durante a execução dos pilotos não devem ser reaproveitados para os projetos, afim de que as pessoas se sintam confortáveis para aprender, errar e corrigir. É nesta atividade que os integrantes do time de teste junto com o time de condutores irão testar e darão os aceites em relação às ações implementadas, eles irão analisar quais ações são passíveis de utilização no dia-a-dia da organização. Com isso, o princípio do XP Pequenas Versões é utilizado nesta atividade, pois a cada nova iteração, um conjunto pequeno de ações é disponibilizado aos participantes para que eles possam utilizar e testar as ações através dos projetos pilotos. Outro princípio do XP presente nesta atividade é o princípio Testes de Aceitação, uma vez que a equipe já utilizou as ações, eles junto com o time de condutores estão aptos para escolher as ações que serão agregadas ao processo de teste da organização. Templates : Não se aplica 2.5. Fase 5 Verificar Resultados e Aprender Nesta fase é importante que experiências sejam capturadas e documentadas, bem como os benefícios adquiridos e problemas enfrentados durante a iteração atual. Estas informações devem ser disponibilizadas aos principais envolvidos com o programa de melhoria de testes. Verificar Resultados: nesta atividade é importante que lições aprendidas sejam coletadas, analisadas e documentadas. A coleta das informações deve ser realizada através de uma reunião com todos os envolvidos na iteração atual do programa de melhoria de testes e questões como: O que deu certo? E o que poderia ter sido melhor? devem ser respondidas nesta reunião por cada um dos participantes. O objetivo principal desta atividade é levantar oportunidades de melhoria para a próxima iteração que será iniciada. Após o término da reunião, o time de condutores deve documentar os resultados obtidos através de um documento formal. Nesta atividade é utilizado o conceito Reunião de Retrospectiva da Sprint definido no Scrum. Apresentar Resultados: Os resultados da iteração atual devem ser apresentados pelo time de condutores a todos os envolvidos com o programa de melhoria de testes, e também para a alta direção da empresa. As dificuldades levantadas e benefícios da iteração também devem ser apresentados. Se a iteração atual for a última iteração do programa de melhoria, todos os resultados alcançados durante o programa devem ser 21

43 apresentados e relacionados com os objetivos de negócios levantados durante a fase de iniciação. Um nível do TMM também deve ser identificado para a empresa com a finalização do programa. Esta atividade é essencial para mostrar aos envolvidos, os resultados alcançados por eles na iteração, as dificuldades enfrentadas e etc. Isto auxilia no estabelecimento de uma comunicação forte e contínua entre todos do time, motiva os envolvidos e principalmente a alta direção, pois eles conseguem enxergar os resultados obtidos em um curto espaço de tempo. Com isso, os valores Comunicação e Feedback do XP estão fortemente presentes nesta atividade. Templates: Template de Lições Aprendidas, Template de Apresentação de Resultados. 2.6 Fase 6 Institucionalizar a Melhoria O objetivo desta fase é institucionalizar as ações de melhoria que deram resultados positivos nas fases anteriores. Estas ações que deram certo devem ser refletidas no processo de testes da organização. Institucionalizar a Melhoria: todas as melhorias que foram implementadas na iteração e obtiveram resultados positivos, devem ser refletidas no processo de testes da organização. As ações são agregadas ao processo de teste ao final de cada iteração, inserindo mudanças gradativas e incrementais, diminuindo assim a resistência às mudanças, diminuindo as chances de rejeição às ações de melhoria adotadas, respeitando a cultura da empresa e o tempo que as pessoas levam para se adaptar ao processo modificado. Com isso, o princípio Integração Contínua do XP é aplicado nesta atividade. Templates: Não se aplica 2.7. Fase 7 Acompanhamento do Programa de Melhoria Esta fase tem como objetivo acompanhar a execução e evolução da abordagem, para medir os resultados da implantação de testes trazidos por ela, principalmente em relação aos objetivos da organização. Para isto, dados precisam ser coletados, organizados e analisados através de métricas estabelecidas. Estabelecer Métricas: Nesta atividade, métricas devem ser identificadas pelos condutores e pela alta direção da organização. Estas métricas devem permitir avaliar se a organização alcançou os objetivos estabelecidos pelo programa. Um template com métricas básicas foi elaborado para facilitar a realização desta atividade. As métricas contidas no template foram definidas utilizando o paradigma GQM (Goal Question Metric Paradigm), criado por Basili [Basili, 1993]. Os objetivos que foram utilizados para derivação das métricas do template são objetivos organizacionais comumente encontrados em programas de melhoria. O template definido permite customizações, para cobrir objetivos que eventualmente não tenham sido cobertos pelo template padrão. Coletar Métricas: nesta atividade as métricas devem ser coletadas para que na atividade seguinte elas sejam analisadas e seus resultados divulgados. Para a coleta, é necessário que seja definida a periodicidade, o responsável, o procedimento de análise e a unidade de medida para cada métrica. Um template de coleta de métricas foi elaborado a fim de facilitar a execução desta atividade. 22

44 Avaliar e Divulgar Métricas: É importante que as métricas que foram coletadas sejam analisadas pelos responsáveis e seus resultados divulgados por toda a organização. Os resultados devem ser comparados com os dados atuais, para avaliar os benefícios que a abordagem trouxe para a organização. Templates: Templates de Métricas Básicas, Template de Plano de Coleta de Métricas. 3. Estudos de Caso As experiências, baseadas em estudo de caso, iniciaram durante a definição da abordagem AITS, auxiliaram sua definição e foram fundamentais para sua melhoria. Os dados gerados e os problemas enfrentados durante os estudos de caso permitiram analisar sua aplicabilidade no contexto de implantação e melhoria de testes de software e avaliar os resultados alcançados com sua execução. Durante o desenvolvimento da abordagem foram realizados dois estudos de casos, o primeiro estudo de caso juntamente com seus resultados pode ser visto em [Diniz et al, 2007]. O segundo estudo de caso realizado será detalhado abaixo. 3.1 Estudo de Caso O segundo estudo de caso foi realizado numa empresa voltada para o desenvolvimento de projetos para os mais diversos setores. A empresa conta atualmente com aproximadamente 1200 colaboradores e possui a estrutura projetizada. A abordagem AITS foi aplicada em um projeto desta organização que estava desenvolvendo uma ferramenta de gerência de projetos para uma multinacional do setor de telefonia. A escolha deste projeto para a aplicação da abordagem se deu, principalmente, porque o cliente era estratégico para a organização e se mostrava extremamente insatisfeito com a qualidade dos releases entregues pela equipe. Por causa disso, a alta direção tomou uma série de medidas que entre elas estavam a aplicação da abordagem AITS. A equipe do projeto contava com a participação de 15 pessoas ao todo, sendo 10 engenheiros de sistemas, 4 engenheiros de teste e um gerente de projeto. Durante a aplicação da abordagem AITS, a empresa estava se preparando para ser avaliada no CMMI estagiado nível 3. O projeto escolhido não estava dentro do escopo da avaliação, mas mesmo assim deveria seguir uma customização do processo organizacional. Neste estudo de caso foi utilizada a versão final da abordagem AITS, a fim de validar sua aplicação e comprovar os resultados obtidos. Para iniciar a aplicação da abordagem, o grupo de condutores foi estabelecido, sendo formado por dois membros da equipe de testes do projeto. Na fase de Inicialização, foi obtido o comprometimento entre a alta direção, a gerente do projeto, que representava a alta direção da empresa, e o time independente de testes. Este comprometimento foi realizado através de uma reunião onde foram definidos dois objetivos da organização em relação ao programa de melhoria de testes do projeto: aumentar a qualidade do produto e aumentar a satisfação do cliente. Na fase de Diagnóstico, o questionário de avaliação foi enviado via para os membros que estavam direta ou indiretamente envolvidos com a área de testes. Os 23

45 questionários preenchidos foram re-enviados para o time de condutores em um tempo médio de 2 dias. Entre os participantes da avaliação estavam todos os engenheiros de teste do projeto, um analista de requisitos e o gerente de projetos. Os resultados dos checklists de avaliação das entrevistas foram consolidados pelos condutores em um único checklist de avaliação. Na tabela 1 é apresentado resultado da avaliação. RESULTADO DA AVALIAÇÃO PONTOS Nível 2 Nível 3 Total de Pontos Válidos Total de Pontos Adquiridos RESULTADO REPROVADO REPROVADO Tabela 1 - Resultado da avaliação do processo Após a consolidação dos dados obtidos, o time de condutores realizou uma reunião, com participação do time do projeto, e a gerente como representante da alta direção da empresa. A apresentação tinha como objetivo exibir os pontos fortes e fracos existentes no processo de testes utilizado pelo projeto. Entre os principais pontos fortes levantados durante a avaliação estavam: existia um processo definido para planejamento, projeto, execução e análise de testes; a gerência de configuração do projeto funcionava de maneira adequada; um ambiente adequado para a realização das atividades de testes era fornecido; defeitos eram identificados e registrados no repositório de defeitos; treinamentos organizacionais em testes eram fornecidos. Entre os principais pontos fracos levantados durante o diagnóstico estavam: embora houvesse um processo de testes definido, ele não era utilizado; testes funcionais e manuais eram realizados de forma exploratória, baseados apenas no conhecimento dos engenheiros de testes, não havia nada documentado; não existia planejamento de testes; testes não-funcionais não eram realizados; testes unitários não eram planejados, projetados e realizados; os requisitos não eram aprovados pelo stakeholders apropriados e os integrantes do time de testes não eram envolvidos apropriadamente; nenhuma métrica de testes estava definida. Após o fim da fase de Diagnóstico, foi iniciada a fase de Planejamento de Ações de Melhoria. A primeira atividade desta fase foi selecionar as ações a partir do template de ações padrões. As ações selecionadas foram aquelas que endereçavam diretamente as deficiências de teste levantadas durante a avaliação. As ações selecionadas foram priorizadas de acordo com os critérios definidos na abordagem AITS. Uma vez realizada a priorização das ações selecionadas, o plano de ação iterativo e incremental foi elaborado considerando as prioridades obtidas para cada ação. No plano de ação foram identificadas quatro iterações para todo o programa de melhoria. Este plano considerava ainda a realização de pilotos para prática e fixação do conhecimento adquirido durante a iteração. Um plano de ação mais detalhado com responsabilidades, marcos era elaborado no início de cada iteração. 24

46 A fase seguinte, Implementar Ações de Melhorias, foi realizada de forma que toda a equipe de teste estivesse envolvida na execução das ações de melhoria planejadas para a iteração corrente. Ao final de cada iteração, os pilotos previstos foram realizados com sucesso. Devido ao tempo reduzido e à boa qualidade dos artefatos produzidos, os mesmos foram reaproveitados para no projeto real. Para a equipe de testes do projeto, isto foi um ponto positivo, pois ela estava produzindo e utilizando os artefatos, otimizando assim o tempo que eles tinham. A fase Implementar Ações de Melhoria foi realizada 4 vezes durante o todo o programa de melhoria. A prática de automação dos testes prevista na última iteração planejada do plano de ação não foi realizada, pois não haveria continuação do projeto o que não justificava mais o esforço que seria gasto para implementação de tal prática. Desta forma, a gerência do projeto juntamente com um representante do time de teste optaram por implementar a prática caso houvesse uma continuação do projeto posteriormente. Entre a iteração 3 e 4 houve um período de aproximadamente 25 dias sem a realização do programa, isto se deve ao fato de que a equipe de testes estava muito sobrecarregada com as atividades do projeto e não podia dedicar 50% de sua carga horária para o programa de melhoria. Na fase Verificar Resultados e Aprender, reuniões ao final da iteração foram realizadas com a equipe de testes, com a equipe de desenvolvimento, com a engenheira de qualidade e a gerente do projeto. As reuniões tinham duração de aproximadamente quatro horas. Todas as respostas eram exibidas e discutidas por todos os presentes na reunião. Ao final da reunião, um dos membros do time de condutores juntamente com a engenheira de qualidade reunia e compilava todas as informações para elas ficassem disponíveis para o time. Ao final de cada iteração o conjunto de práticas que tiveram aceitação positiva pelo time de teste era agregado ao processo de teste customizado para o projeto, institucionalizando assim a melhoria no âmbito daquele projeto. A fase Acompanhar Melhoria foi realizada durante todo o programa de melhoria pela gerente do projeto e um membro do time de condutor. Como o gerente do projeto que era também representante da alta direção e estava muito próximo da equipe de condutores e testes, o acompanhamento do andamento do programa era realizado diariamente através de reuniões rápidas de 15 minutos. Com isso, não houve a necessidade de métricas de acompanhamento do programa de melhoria. A fase Implementar Ações foi a que mais consumiu esforço na aplicação da abordagem. Isto se deve, principalmente, ao fato da equipe de testes ter tido um tempo muito reduzido para realização de atividades do projeto real, o que acabou muitas vezes impactando nas atividades e nas horas do projeto do programa de melhoria, aumentando assim os prazos para finalização das atividades no projeto piloto. Para este estudo de caso, o custo para implementação e melhoria do processo customizado também foi considerado baixo pela organização em relação à capacidade produtiva da empresa e os benefícios trazidos por ela. Ao final do programa de melhoria, o diagnóstico do processo de teste foi realizado novamente com o objetivo de verificar sua evolução com a implementação da abordagem AITS. A tabela 2 exibe o resultado da avaliação após a implementação da AITS. 25

47 RESULTADO DA AVALIAÇÃO PONTOS Nível 2 Nível 3 Total de Pontos Válidos Total de Pontos Adquiridos RESULTADO PASSOU PASSOU Tabela 2 - Resultado Final da Avaliação do Processo Como pode ser observado através da tabela 2, o processo conseguiu atingir o nível 2 e o nível 3 do TMM. Com isso temos ao final do programa de melhoria um processo de testes que atende a 81% do nível 2 e 85% do nível 3 TMM representando uma melhoria de 43% e 48% respectivamente. Algumas melhorias ainda precisarão ser realizadas para que o processo atenda por completo as práticas nível 2 e 3 do TMM, principalmente porque as práticas relacionadas com a automação de testes não foram implementadas, impactando assim na área Execução de Teste. Além da avaliação do processo em relação ao TMM, um indicador foi estabelecido e coletado ao longo do programa para verificar a eficiência do time de teste. A tabela 3 exibe a quantidade de bugs identificados antes e durante a implementação da abordagem AITS Bugs Número total de CRs 0 Release 1 Release 2 Release 3 Release 4 Release 5 Release 6 Release 7 Tabela 3 - Número de bugs antes e durante a AITS Como pode ser observado no gráfico acima, a quantidade de bugs identificados pelo time de teste após a implantação da abordagem AITS (após Release 3) aumentou consideravelmente. O que pode indicar um aumento na qualidade no produto entregue já que mais defeitos foram identificados antes do produto chegar ao cliente. A satisfação do cliente também aumentou consideravelmente ao longo do projeto, se antes da aplicação da abordagem a satisfação do cliente era em média 3,0 ao final da aplicação da abordagem esta satisfação atingiu a média 4,5, sendo que a pontuação máxima possível era 5,0. Além disso, ao final do projeto foi enviado um questionário para os dois representantes do cliente, a fim de analisar suas percepções em relação à qualidade final do produto e como a equipe de testes pode ter influenciado nisto. Os dois representantes do cliente consideraram que a equipe de teste influenciou muito positivamente na qualidade do produto final. Além disso, outro ponto bastante enfatizado por eles foi o envolvimento do time de testes na revisão dos requisitos, ajudando no entendimento das regras de negócio e com isso, realizando testes mais eficazes. Em relação ao time do 26

48 projeto, um questionário com mais questões foi enviado para alguns membros da equipe a fim de coletar a percepção deles em relação aos benefícios trazidos pelas mudanças realizadas no time de teste. A grande maioria dos entrevistados respondeu que as mudanças realizadas ao longo do projeto impactaram diretamente na melhora da qualidade do produto entregue ao cliente. Ao final da aplicação da abordagem, a alta direção e a equipe de testes das empresas participantes, consideraram a abordagem como sendo uma boa alternativa para a realização de implantação e/ou melhoria de processo de testes. As principais vantagens listadas por eles em relação à AITS foram: baixo custo de implementação, simples e de fácil entendimento, resultados alcançados em um curto espaço de tempo, participação de toda a equipe de testes na implementação de novas práticas, baixa resistência das equipes envolvidas. Assim, pelos resultados obtidos dos estudos de casos, pode-se dizer que a abordagem AITS se mostra uma boa alternativa para organizações que desejam alcançar melhores resultados na qualidade do produto e na satisfação dos clientes. Apesar disso, algumas dificuldades foram encontradas ao longo da implantação da abordagem AITS nos estudos de caso relatados, tais como: grande resistência inicial por parte de outras equipes na implantação da abordagem AITS; conflitos entre iniciativas nas empresas, as duas empresas estavam realizando outras iniciativas em melhoria de software, o que, muitas vezes, impedia grandes alterações em seus processos de teste; em um dos projetos, houve reaproveitamento dos artefatos dos projetos pilotos devido à limitação de tempo; houve interrupção do programa de melhoria por sobrecarga da equipe no projeto real. 4. Conclusão Este trabalho apresentou a abordagem AITS, cujo objetivo é contribuir para a melhoria de processo de teste de software em organizações de desenvolvimento de software, através da implantação e melhoria de processos de teste baseada em práticas ágeis, considerando suas características e limitações. O grande benefício deste trabalho é prover uma alternativa às empresas, que desejam melhorar seus processos e a qualidade dos seus produtos. Através da implantação desta abordagem a melhoria de processos de testes é alcançada de forma gradual, minimizando a resistência das pessoas afetadas, aproveitando os recursos internos da organização, motivando os envolvidos com resultados em curto prazo, evitando abandono do programa de melhoria por falta no entendimento do modelo e evitando adaptações na abordagem para sua aplicação. Em relação aos modelos existentes, a abordagem AITS apresenta as seguintes diferenças: Necessita a criação de somente um grupo específico dentro da organização para a implementação/melhoria do processo de teste, que é o time de condutores. Além disso, este time conta com a participação dos próprios colaboradores da organização. Isto faz com que os custos do programa de melhoria sejam reduzidos, já que não há necessidade de contratação de uma consultoria externa e nem há um alto número de funcionários alocados em atividades do programa de melhoria; 27

49 Incorpora muitas práticas/princípios ágeis que a torna mais simples e ágil, contando com a presença de um conjunto mínimo de atividades necessárias para a realização de um programa de melhoria, com templates que apóiam a realização das atividades e com um vocabulário simples, evitando más interpretações; É específica para o contexto de testes unindo os benefícios trazidos pelos principais modelos de melhoria de processo e por um modelo de maturidade em testes TMM. Conta ainda com os templates elaborados especificamente para o contexto de melhoria de processo de testes, possuindo ao mesmo tempo o como fazer e o que fazer para melhorar um processo de teste em uma organização; Elaborada considerando as principais limitações e dificuldades enfrentadas pelas empresas de software em um programa de melhoria possuindo investimento compatível com a realidade das empresas e possibilitando a visualização de resultados em um curto espaço de tempo; O processo de avaliação contido na abordagem é bastante simplificado se comparado aos processos de avaliação dos modelos de melhoria apresentados. Conta ainda com o apoio de um template que calcula automaticamente o nível do TMM que a organização se encontra baseado nas respostas dadas pelos entrevistados, minimizando assim as chances de erros inerentes a este processo. A abordagem se mostrou muito atrativa para as organizações utilizadas por ser extremamente simples; é específica para o contexto de teste de software, evitando trabalho com grandes adaptações da abordagem. 5. Referências [Basili, 1993] BASILI, V. R., CALDIERA G., ROMBACH H. D., The Goal Question Metric Approach, University of Maryland, 1993 [Beck, 1999] BECK, K.; ANDRES, C. Extreme Programming explained: embrace change. 1. ed. Upper Saddle River: Addison-Wesley, p. [Brodman, 1994] BRODMAN, J.G.; JOHNSON, D.L. What Small Business and Small Organisations say about CMM? Procedings of the 16th International Conference on Software Engineering, Sorrento, Italy, May [Burnstein, 2003] BURNSTEIN, I. Practical software testing : a process-oriented approach. Springer-Verlag New York, Inc, [Carosia, 2003] CAROSIA, J.S. Levantamento da qualidade do processo de software com foco em pequenas organizações. Dissertação de Mestrado. Instituto Nacional de Pesquisas Espaciais, [Diniz et al, 2007] DINIZ, R.; OCHNER, J. Implantação de uma Metodologia de Testes em Iterações para um Grupo Independente. Relato de Experiência, SBQS Simpósio Brasileiro de Qualidade de Software, [Ericson, 1996] ERICSON, T., SUBOTIC A. A Test Improvement Model. Artigo Técnico EUROSTAR,

50 [Freesz, 2004] FREESZ. E.V., Melhoria do processo de teste com TMM em uma grande empresa. Trabalho de Especialização em Melhoria de Processo de Software, Universidade Federal de Lavras, [Humphrey, 1989] HUMPHREY W., Managing the Software Process - Addison Wesley Professional, Massachusetts, [ISO15504, 2005] Internacional Organization for Standarlization. ISO/IEC 15504: Information Technology Process Assessment, Part 1 to Part 5. ISO/IEC International Standard, [Koomen, 1999] KOOMEN, T.; POL, M. Test Process Improvement: A practical Step by Stepguide to structured testing, Addison-Wesley, [McFeeley, 1996] McFEELEY, R. IDEAL: A User s Guide for Software Process Improvement. Relatório Técnico CMU/SEI-96-HB-001, Software Engineering Institute, [MCT_01, 2001] MINISTÉRIO DA CIÊNCIA E TECNOLOGIA. Qualidade e Produtividade no Setor de Software Brasileiro: Resultados da Pesquisa Disponível em: Acesso em: 28 nov [Niasi, 2003] NIAZI, M.; WILSON D.; ZOWGHI Didar. A model for the implementation of software process improvement: A pilot study. Artigo Técnico. Proceedings of the Third International Conference On Quality Software (QSIC 03). IEEE Software, [Reffson, 2006] REFFSON A.; BEZERRA C.I.; COUTINHO E. Análise da Aderência de um Processo de Teste ao TMM. Artigo Técnico, SBTS I Simpósio Brasileiro de Teste de Software, [Salviano, 2006] SALVIANO, C. F.; Uma Proposta orientada a Perfis de Capacidade de Processo para Evolução da Melhoria de Processo de Software. Tese de Doutorado, Universidade Estadual de Campinas, [Santana, 2007] SANTANA, A.F., Problemas em Iniciativas de Melhoria de Processos de Software sob a Ótica de uma Teoria de Intervenção. Dissertação de Mestrado, Universidade Federal de Pernambuco, [Santos, 2006] SANTOS J.; ALVES G. TMM-e Framework. Artigo Técnico, SBTS I Simpósio Brasileiro de Teste de Software, [Schwaber, 2004] SCHWABER, K. Agile Project Management with Scrum. 1 ed. Microsoft Press, WA, [Vasconcelos et al, 2006] VASCONCELOS, A. M.; ROUILLER, A.C. et al. Introdução à Engenharia de Software e à Qualidade de Software. Lavras: UFLA/FAEPE,

51 30

52 Análise de Mutantes em Aplicações SQL de Banco de Dados Andrea G. Cabeça 1, Plínio S Leitao-Junior 2, Mario Jino 1 1 Faculdade de Engenharia Elétrica e de Computação - Universidade Estadual de Campinas (UNICAMP) Campinas, SP - Brasil 2 Instituto de Informática Universidade Federal de Goiás - Goiânia, GO - Brasil. {andrea.cabeca@kpocs.com.br, plinio@inf.ufg.br, jino@dca.fee.unicamp.br} Abstract. Testing database applications is crucial for ensuring high quality software as undetected faults can result in unrecoverable data corruption. SQL is the most widely used interface language for relational database systems. Our approach aims to achieve better tests by selecting fault-revealing databases. We use mutation analysis on SQL statements and discuss two scenarios for applying strong and weak mutation techniques. Experiments using real applications, real faults and real data were performed to: (i) evaluate the applicability of the approach, and (ii) compare fault-revealing abilities of input databases. Resumo. O teste de aplicações de banco de dados é crucial para assegurar a alta qualidade do software, pois defeitos não detectados podem resultar em corrupção irrecuperável dos dados. SQL é a mais amplamente utilizada interface para sistemas de banco de dados. Nossa abordagem visa a alcançar melhores testes pela seleção de bases de dados reveladoras de defeitos. Usamos a análise de mutantes em comandos SQL e discutimos dois cenários para aplicar as técnicas de mutação forte e fraca. Experimentos usando aplicações reais, defeitos reais e dados reais foram conduzidos para: (i) avaliar a aplicabilidade da abordagem; e (ii) comparar as capacidades de revelação de defeitos de bases de dados de entrada. 1. Introdução A incapacidade humana para executar tarefas e comunicar-se com perfeição é um dos fatores motivadores para que o desenvolvimento de software seja acompanhado por esforços direcionados à garantia de qualidade [Deutsch, 1979]. Da perspectiva de software, podemos dizer que eles são expressivos tanto no meio industrial quanto no acadêmico. Em cada fase do processo de desenvolvimento, encontramos dezenas de metodologias e guias para auxiliar o profissional na busca da qualidade, na direção da confiabilidade e da corretude do software. Nesse contexto, o teste de software aparece como um elemento crítico para a busca da qualidade. A análise de mutantes ou teste de mutação [DeMillo, 1978] é uma técnica (critério) que consiste em inserir pequenas alterações em um programa em teste, resultando em programas ligeiramente diferentes do original, chamados mutantes. As 31

53 alterações são determinadas por meio de regras, denominadas operadores de mutação, que visam a caracterizar um determinado modelo de defeitos. Dada uma entrada, o comportamento do programa original P é comparado com o de cada programa mutante M. Em tempo de execução, se o comportamento de M for distinto do de P, diz-se que M está morto. Se, para um conjunto de caso de testes T, M apresentar o mesmo comportamento de P, diz-se que M está vivo e uma análise adicional deverá ser feita para determinar: (i) se M é equivalente a P; ou (ii) se T não é bom o suficiente para matar M. Após a execução dos mutantes, o escore de mutação EscM é calculado; EscM é a razão entre a quantidade de mutantes mortos e a quantidade de mutantes não equivalentes vivos (gerados menos os equivalentes); varia entre 0 e 1 e dá uma indicação da qualidade dos casos de teste escolhidos para exercitar o programa [DeMillo, 1980]. De acordo com Kapfhammer e Soffa (2003), uma aplicação de banco de dados é um programa cujo ambiente sempre contém uma ou mais bases de dados. Em geral, a Aplicação de Banco de Dados Relacional (ABDR) pode ser composta por vários programas codificados em diversas linguagens como C e Java, sendo sua principal característica a manipulação de dados por comandos que acessam as bases de dados controladas por um Sistema Gerenciador de Banco de Dados (SGBD) [Spoto, 2000]. No âmbito da ABDR, as bases de dados integram o conjunto de dados de entrada dos testes; assim, um caso de teste é formado por: (i) dados de entrada para o programa; (ii) conjunto de instâncias de bases de dados; e (iii) a saída esperada e instâncias esperadas das bases para estes dados de entrada. A SQL (Structured Query Language) é uma linguagem padrão utilizada para a comunicação com um banco de dados relacional, representando a forma de acesso das aplicações às bases de dados; é a linguagem mais usada pelos SGBDs comerciais. Técnicas de teste para programas convencionais e até mesmo para a geração de bases de dados têm sido propostas, implementadas e avaliadas, tais como em Chan e Cheung (1999) e Chays e Deng (2003), mas ainda há carência de abordagens sistemáticas de testes na busca pela melhoria da qualidade das aplicações de banco de dados que usam a SQL [Tuya et al., 2007; Chan et al., 2005 e Leitao-Junior et al., 2005]. Este trabalho explora o teste de mutação para a SQL no contexto de ABDRs, estabelecendo operadores de mutação para a linguagem e, sobretudo, experimentando cenários próprios de aplicações reais. Tais cenários são complementares e representam etapas pertinentes à atividade de teste, a saber: (i) teste isolado de comandos SQL; e (ii) teste de seqüências SQL geradas a partir de aplicações de banco de dados. Em ambos os cenários, são empregados operadores de mutação que constituem uma evolução dos propostos na literatura e que representam defeitos comumente inseridos por programadores SQL. A análise empírica dos operadores em tais cenários tem o suporte de uma ferramenta, a qual cobre a geração de mutantes e a avaliação do teste, permitindo a análise da eficácia dos conjuntos de teste (bases de dados de entrada). A Seção 2 apresenta definições relativas ao teste de mutação aplicado a SQL. A definição dos cenários de mutação forte e de mutação fraca é apresentada na Seção 3. Os operadores de mutação são introduzidos na Seção 4. A Seção 5 explora as características da ferramenta desenvolvida para o suporte à abordagem. A Seção 6 descreve os experimentos que objetivam a investigação da aplicabilidade e da 32

54 capacidade de detecção de defeitos dos operadores de mutação e o seu comportamento nos cenários estudados. A Seção 7 discute brevemente alguns trabalhos relacionados, que também exploram o teste de mutação em aplicações SQL. A Seção 8 apresenta as conclusões e contribuições do trabalho. 2. Teste de Mutação Aplicado a SQL Nesta seção são introduzidos conceitos pertinentes à análise de mutantes nas aplicações que utilizam a SQL. A Subseção 2.1 apresenta o conceito de Unidade de Programa com SQL e suas abordagens para teste; tal conceito é útil na introdução dos cenários de teste para o experimento. A Subseção 2.2 estende as definições do teste de mutação para aplicações que utilizam a linguagem de manipulação SQL. 2.1 Unidade de Programa com SQL Uma unidade de programa é dita Unidade de Programa com SQL (UPS), se possuir comandos da SQL para o acesso à base de dados. Para a avaliação de UPSs, identificamos duas abordagens de teste: (Ti) o resultado do teste é a saída O da UPS e o estado final DB f (instância de saída) da base de dados; (Tii) o resultado do teste é a saída O da UPS e a seqüência S de comandos da SQL, tal que a aplicação de S à instância de entrada da base de dados produz o estado final DB f da base de dados. Ambas as abordagens podem ser aplicadas ao teste de UPSs. Na segunda abordagem (Tii), vale ressaltar que a seqüência S é oriunda da execução da UPS a partir do dado de teste: valores de entrada e instância de banco de dados. 2.2 Definições Esta subseção estende as definições do teste de mutação para aplicações que utilizam a linguagem de manipulação SQL. Considere P uma unidade de programa com SQL. Definição 1: O Dado de Teste ID para a execução de P é definido como ID = { I, DB i }, tal que: I representa os dados de entrada de P; e DB i é a instância inicial da base de dados. Definição 2: O Caso de Teste TC para a execução de P é definido como TC = { ID, O, S } ou TC = { ID, O, DB f }, tal que: ID constitui o dado de teste para P; O é a saída da execução de P a partir de ID, S é a seqüência de comandos SQL oriunda da execução de P a partir de ID; e DB f é a instância final da base de dados obtida aplicando-se a seqüência S à instância Db i em ID. Definição 3: O conjunto de operadores de mutação aplicáveis à seqüência S de comandos SQL é definido como MO = { mo 1, mo 2,..., mo x }, x >= 1, em que cada operador mo i MO, 1 i x, pode ser aplicado a algum comando de S. Definição 4: A partir de S e MO, pode-se derivar o conjunto de mutantes M = {mo 11, mo 12,..., mo i1, mo i2,..., mo ij,..., mo x1, mo x2,...}, tal que: (1) mo ij é o j-ésimo mutante obtido a partir do operador de mutação mo i MO; e (2) M x, sendo x a cardinalidade do conjunto MO. 33

55 Definição 5: A partir do conjunto M, é derivado o conjunto de mutantes possíveis M*, tal que M* M. Um mutante é possível se for sintaticamente válido. Ao aplicar um dado de teste ID à unidade P, é obtida a seqüência S de comandos SQL. Da seqüência S é derivado o conjunto MO = { mo 1, mo 2,..., mo x } de operadores de mutação, donde se constroem x mutantes, x >= 0. Aplica-se DB i a cada mo i MO e determina-se o número y de mutantes mortos, y MO. O escore de mutação EscM = y / MO determina o percentual de mutantes mortos dentre os mutantes existentes. Se EscM=1, significa que todos os mutantes foram mortos (situação ideal). Dado o conjunto C de casos de teste, deve-se selecionar o subconjunto C* de C que é composto dos casos de teste de C que resultaram nos maiores valores para o escore EscM. 3. Cenários Nesta seção, são introduzidos os cenários dos experimentos para o teste de mutação aplicado a Unidades de Programa com SQL. O foco são o teste e a análise de seqüências de comandos SQL, ou de componentes dessas seqüências. 3.1 Cenário 1 Neste cenário, seqüências SQL são analisadas como um átomo, caracterizando o aspecto de Mutação Forte [Woodward, 1993] para o teste. Uma seqüência S de comandos SQL é obtida pela aplicação dos dados de teste ID (dados de entrada e instância inicial da base de dados) a uma UPS. A seqüência S e um conjunto de mutantes, os quais foram gerados a partir de S, são executados usando a instância de entrada da base de dados em ID. A instância de banco de dados produzida pela execução de S é comparada com as instâncias de banco de dados oriundas das execuções dos mutantes de S. O resultado dessa comparação produz o escore de mutação EscM, referente ao dado de teste ID. O escore de mutação EscM obtido demonstrará o valor relativo do dado de teste ID em relação a outros dados de teste para o teste da UPS. O foco da avaliação é a comparação de dados de teste, onde o teste de mutação os avaliará em sua eficiência sob diversos aspectos, tais como a capacidade de revelar classes de defeitos e a cobertura de comandos SQL a serem exercitados. Vale ressaltar que qualquer variação na instância de entrada da base de dados caracterizará um outro dado de teste, denominado ID (cuja aplicação à UPS produz a seqüência S de comandos SQL, possivelmente distinta de S ), o qual é passível de comparação com ID. 3.2 Cenário 2 Neste cenário, seqüências de comandos SQL são também consideradas como objetos do teste, mas são analisadas em termos de seus componentes, caracterizando o aspecto de Mutação Fraca [Woodward, 1993] para o teste. Geralmente, um componente da seqüência é constituído por um único comando de acesso à base de dados, tais como SELECT e INSERT, mas pode ser composto por um grupo de comandos que denotem algum aspecto particular da seqüência (por exemplo, um subcaminho ou uma classe de defeitos). 34

56 Os mutantes são gerados a partir da aplicação de operadores de mutação aos comandos do componente em questão. O escore de mutação EscM indica o valor relativo entre instâncias de entrada da base de dados para o teste do componente. Vale ressaltar que esta abordagem é pertinente à comparação de instâncias de base de dados para: (i) o teste de uma UPS particular, pois apóia a seleção de bases potencialmente reveladoras de defeito pela análise de componentes de seqüências; (ii) o teste de seqüências SQL oriundas de outras fontes, tais como scripts SQL de uso geral, triggers e stored procedures. 4. Operadores de Mutação A definição dos operadores de mutação em SQL visa à avaliação de instâncias de entrada de bases de dados, com respeito à sua capacidade em revelar defeitos, que estejam presentes no esquema da base de dados ou nos comandos SQL de acesso à base de dados. Nosso objetivo foi cobrir todos os comandos pertencentes ao padrão SQL 3 [ANSI, 2003], cujas sintaxes sejam passíveis de mutação. Embora alguns estudos, como o de Pönighaus (1995), demonstrem que o comando SELECT é o mais utilizado nas aplicações comerciais, não há registros sobre a relevância dos demais comandos. Ou seja, isso não significa que nos demais comandos da linguagem SQL não existam defeitos, nem que os defeitos nos demais comandos sejam pouco freqüentes ou que não sejam tão graves quanto os defeitos nos comandos de consulta. Este trabalho define operadores de mutação para a maioria dos comandos da SQL, em adição aos comandos de consulta e atualização de dados. Os operadores foram divididos em 5 categorias definidas conforme a funcionalidade dos comandos SQL, à exceção da categoria Miscelânea com operadores que podem ser utilizados em comandos de funcionalidades distintas. Por exemplo, um operador de mutação definido para um operador matemático, tal como +, é classificado na categoria Operadores de Mutação para Operadores de SQL. Um operador definido para alterar o parâmetro de entrada ou saída de uma procedure de SQL, tal como in ou out, pertence à categoria Operadores de Mutação para Funções e Procedimentos. Todos os operadores definidos para diversos comandos da SQL, tais como INSERT e DELETE, pertencem à categoria Miscelânea, pois podem caracterizar defeitos diferentes, dependendo da funcionalidade do comando ao qual ele foi aplicado. As próximas subseções apresentam as 5 categorias de operadores de mutação. 4.1 Operadores de Mutação para Operadores de SQL O objetivo desta categoria de operadores é a caracterização dos erros normalmente criados pelo programador devido ao uso incorreto dos operadores de SQL. Foram definidos operadores de mutação para os 5 tipos de operadores mais comuns em SQL operadores matemáticos, de comparação, lógicos, conjuntivos e de negação, visando a caracterizar defeitos em: desvios de fluxos; repetições em estruturas condicionais; número de tuplas (número a mais ou a menos de tuplas na seleção, inserção, exclusão ou atualização); inserção, atualização e exclusão de dados persistentes; e visualização ou cálculo de dados. Os 5 operadores pertencentes a esta 35

57 categoria são: Troca de Operador Matemático (topmt), Troca de Operador de Comparação (topcp), Troca de Operador Conjuntivo (topcj), Troca de Operador de Lógico (toplg), Inserção de Operador de Negação (inot), e Retirada de Operador de Negação (rnot). 4.2 Operadores de Mutação Miscelânea Os operadores desta categoria são caracterizados pela sua aplicação em muitos comandos com funcionalidades distintas. São aplicáveis a diversos comandos da SQL, tais como INSERT e DELETE, e podem caracterizar defeitos em: inserção, atualização ou exclusão de dados persistentes; visualização ou cálculo de dados; definição de atributos e variáveis; e número de tuplas. Os 15 operadores pertencentes a esta categoria são: Troca de Posição de Atributo (tpoat); Retirada de Atributo (ratr); Inserção de Atributo (iatr); Troca de Atributo (tat); Troca de Posição de Valor (tpovr); Troca de Valor (tvr); Troca de Tipo de Variável (ttpvar); Troca de Nome de Tabela (tnmtb); Troca de Nome de ROLE (tnmrole); Inserção de ROLE (irole); Retirada de ROLE (rrole); Troca de Nome de Cursor (tnmcursor); Troca de Função de Agregação (tfuag); Troca de Intersecção (tinsec); e Troca de Join (tjoin). 4.3 Operadores de Mutação para Fluxo de Controle O objetivo desta categoria de operadores é abordar o fluxo de controle nos comandos SQL, por modificações em estruturas condicionais e de repetição. Operadores desta categoria caracterizam os seguintes defeitos: execução indevida de comandos e comandos não executados. Os 6 operadores pertencentes a esta categoria são: Troca de Bloco de Comandos nas estruturas de condição e repetição (tblcmestrep); Retirada de Comando do Bloco de Repetição/Condição (rcmblrep); Inserção de Comando do Bloco de Repetição/Condição (icmblrep); Troca de Posição do Leave no Bloco de Comandos (tposleave); Retirada de LEAVE (rleave); e Inserção de LEAVE (ileave). 4.4 Operadores de Mutação para Controle de Transações. Esta categoria de operadores está focada nos defeitos associados ao controle das transações e às permissões de acesso por parte dos usuários. Os defeitos nesta categoria são normalmente cometidos pelos usuários no momento da execução dos comandos e na definição do esquema de permissões de acesso, pela ausência ou excesso de permissão de execução de comandos para usuários. Os 12 operadores pertencentes a esta categoria são: Inserção de COMMIT (icm); Retirada de COMMIT (rcm); Inserção de ROLLBACK (irb); Retirada de ROLLBACK (rrb); Troca de COMMIT por ROLLBACK (tcmrb); Troca de ROLLBACK por COMMIT (trbcm); Troca de Nome do SAVEPOINT (tnmsp); Troca de Permissão (tperm); Troca de Privilégio (tpriv); Troca de GRANT por REVOKE (tgrre); Troca de REVOKE por GRANT (tregr); e Troca de Nome de Usuário (tnmusr). 36

58 4.5 Operadores de Mutação para Funções, Procedimentos e Triggers Esta categoria visa a caracterizar o uso incorreto de valores e de chamadas externas: execução errônea de função, trigger, view ou procedimento; retorno de valores incorretos; ausência de retorno de valores; execução de trigger em evento incorreto. Os 5 operadores pertencentes a esta categoria são: Troca de Nome da Função, Procedimento, VIEW ou TRIGGER (tnm); Troca Posição de Retorno da Função (tporefu); Retirada de Retorno da Função (rrefu); Troca de Parâmetros da PROCEDURE (in por out) (tpapro); e Troca de Evento na TRIGGER (tev). 5. Ferramenta para a Automação O número elevado de mutantes criados a partir de uma classe de operadores torna necessários o desenvolvimento e o uso de uma ferramenta para dar suporte à criação, execução e análise de mutantes (mortos, vivos e equivalentes). Quatro aspectos foram observados na automação da análise de mutantes para SQL: (1) captura de dados: envolve a obtenção dos dados de entrada e de saída, incluindo: os comandos SQL executados pela linguagem hospedeira, os dados de entrada (incluindo o estado da base de dados) e os resultados obtidos pela execução dos comandos SQL; (2) definição dos operadores de mutação a serem aplicados nos comandos SQL; (3) geração e execução dos mutantes; e (4) análise dos resultados. Para os mutantes vivos, a análise de uma possível equivalência é realizada pelo testador com o apoio da ferramenta, e a decisão pode ser armazenada na ferramenta. Os dados dos mutantes são armazenados na base de testes, permitindo que cada grupo de comandos e seus mutantes sejam re-executados a qualquer tempo. A ferramenta permite a visualização e a armazenagem de informações sobre o experimento, tais como: (i) identificação da seqüência de comandos executados para um determinado caso de teste; (ii) operadores de mutação aplicados; (iii) mutantes gerados para cada operador; (iv) resultado da avaliação do mutante; (v) comandos SQL original e modificado para cada mutante; (vi) resultado da execução dos comandos original e modificado, incluindo os dados persistentes envolvidos; (vii) mensagens do sistema gerenciador de banco de dados; e (viii) número de tuplas selecionadas, modificadas, número de operações de escrita e de leitura. Em adição, relatórios são gerados sobre o experimento com informações do projeto: operadores aplicados; quantidade de mutantes gerados; índices de mutantes mortos, vivos e equivalentes por operador, projeto, caso de teste, comando SQL ou categoria de operador. 6. Experimentos Foram conduzidos três experimentos utilizando aplicações e bases de dados reais, com o objetivo de: investigar a aplicabilidade e a habilidade de detecção de defeitos dos operadores de mutação propostos, validar a aplicação da automação com a ferramenta desenvolvida e investigar os 2 cenários propostos para a aplicação do teste de mutação. Os Experimentos 1 e 2 exploram o Cenário 1 (Subseção 3.1). O Experimento 3 explora o Cenário 2 (Subseção 3.2). Nos experimentos foram aplicados operadores de mutação nos quatro comandos de manipulação da SQL INSERT, SELECT, UPDATE e DELETE, pois são os mais 37

59 comuns em sistemas comerciais de informação. Foram empregados os Operadores para SQL (Seção 3.1) e os de Miscelânea (Seção 3.2), por representarem os mais aplicáveis aos comandos selecionados. O Experimento 1 utilizou uma aplicação de gestão de equipamentos de informática. Suas principais funcionalidades são o controle de: entrada e saída de equipamentos (software e hardware); materiais; custo, amortização, emissão de notas, fatura e outras operações. A aplicação foi desenvolvida, sob demanda, para uma empresa de médio porte atuante no comércio varejista e está implantada e em funcionamento em 25 filiais, sendo utilizada por aproximadamente 4 usuários por filial. A equipe de desenvolvimento da aplicação possui perfil pleno (não é composta de pessoal inexperiente). O analista de testes foi o responsável pelo projeto dos casos de testes, os quais visam o teste de regras de negócio e de aspectos de funcionamento básico da aplicação (operações de inclusão, alteração, navegação e exclusão), com cobertura de um caso de uso. O Experimento 2 utilizou um software de controle de empréstimo de materiais, cujas principais funcionalidades são: controle de entrada e saída, e reserva de materiais (livros, cds, revistas, etc.); integração com outros sistemas da empresa pelo envio de notificações. A aplicação foi desenvolvida, sob demanda, para uma empresa de médio porte atuante no comércio varejista e está implantada e em funcionamento em 30 filiais; é utilizada por aproximadamente 40 usuários por filial. A equipe de desenvolvimento da aplicação possui perfil senior. O analista de testes foi o responsável pelo projeto dos casos de testes, os quais visam o teste de regras de negócio e de aspectos de funcionamento básico da aplicação (operações de inclusão, alteração, navegação e exclusão), com cobertura de um caso de uso. O Experimento 3 utilizou uma aplicação cuja principal função é exemplificar padrões de desenvolvimento como telas, componentes e relatórios. Esta aplicação é utilizada internamente em uma empresa multinacional de tecnologia de informação. A base de dados utilizada neste sistema é denominada Adventure Works: um banco de dados exemplo do sistema gerenciador de banco de dados SQL Server. Não há informações sobre a equipe de desenvolvimento do software. Os casos de testes utilizados neste experimento foram criados por um analista de testes com perfil senior. Foram utilizados 42 comandos de manipulação SQL retirados de procedimentos da aplicação em teste. Tabela 1: Características das bases de dados utilizadas nos experimentos. Experimento Base Ambiente Descrição das Bases de Dados Utilizada por desenvolvedores e testadores para executar testes de 1 Testes unidades, funcionais, de integração e de sistemas. 1 Dados da produção, sem nenhuma alteração de testadores ou 2 Produção desenvolvedores. As persistências de dados são reais. Dados da produção, sem nenhuma alteração de testadores ou 1 Produção desenvolvedores. As persistências de dados são reais. Dados da produção com redução de persistências de dados de 2 Produção 30%, realizada através de ferramenta proprietária, que busca 2 Reduzido reduzir o volume de dados das bases sem, no entanto, perder a qualidade dos dados de testes. 3 1 Adventure Works Dados disponíveis no banco de dados de exemplo sem nenhuma alteração. 38

60 2 Adventure Works Reduzido Dados disponíveis no banco de dados de exemplo com redução de persistências de dados de 50%, realizada através de uma ferramenta proprietária, que busca reduzir o volume de dados das bases sem prejuízo para a qualidade dos dados de testes. As características das bases de dados utilizadas nos experimentos são descritas na Tabela 1. Tais bancos de dados basearam as instâncias de entrada para as bases de dados e caracterizam o uso de dados reais nas situações de produção e de testes. Note que, para cada experimento, são descritas duas bases de dados. O objetivo da análise empírica é comparar as duas bases de dados dentro do cenário de cada experimento. 6.1 Seleção dos Operadores Devido ao grande número de mutantes gerados para os experimentos, alguns operadores foram aplicados em apenas 10% dos casos. Para a seleção dos operadores, o estudo de mutação seletiva [Mathur, 1991; Offutt et al., 1996] foi adaptado. A Mutação Seletiva consiste em selecionar um número reduzido de operadores de mutação que sejam realmente diferentes dos demais. A não aplicação de um operador que resulta em um grande número de mutantes reduz o custo do teste. Operador topmt topcp topcj, inot, rnot tpoat, tat tvr tpovr tnmtb tjoin tfuag Operador tinsec topcp topcj, inot, rnot tpoat, tat tvr tpovr tnmtb tjoin tfuag Tabela 2: Operadores Aplicados no Experimento 1 Observações Aplicado às permutas do operador multiplicação pelos operadores adição, subtração e divisão. Todas as trocas possíveis para este operador foram utilizadas. Aplicado às permutas dos operadores igualdade, maior e menor pelos demais operadores comparativos. Todas as trocas possíveis para estes operadores foram utilizadas. Todas as trocas possíveis foram aplicadas. Aplicado para 10% dos atributos. Aplicado para 10% dos valores em condições Aplicado para 10% dos atributos em atualizações. Aplicado para 10% das tabelas. Aplicado às permutas de INNER JOIN pelos outros tipos de JOIN. Todas as trocas possíveis para este operador foram utilizadas. Aplicada à permuta de COUNT por SUM. Todas as trocas possíveis para este operador foram utilizadas. Tabela 3: Operadores Aplicados no Experimento 2 Observações Aplicado às permutas de INTERCEPT e EXCEPT pelas outras intersecções. Todas as trocas possíveis para estes operadores foram utilizadas. Aplicado às permutas dos operadores igualdade, maior e menor pelos demais operadores comparativos. Todas as trocas possíveis para estes operadores foram utilizadas. Todas as trocas possíveis foram aplicadas. Aplicado para 10% dos atributos. Aplicado para 10% dos valores em condições Aplicado para 10% dos atributos em atualizações. Aplicado para 10% das tabelas. Aplicado às permutas de INNER JOIN pelos outros tipos de JOIN. Todas as trocas possíveis para este operador foram utilizadas. Aplicado à permuta de COUNT por SUM. Todas as trocas possíveis para este operador foram utilizadas. 39

61 Neste estudo, a seleção foi realizada pelo cálculo de escores de mutação para os seguintes casos: (1) foram gerados 100% dos mutantes e os testes foram executados; (2) foram gerados mutantes com apenas 10% dos operadores selecionados e os testes foram executados. Os escores de mutação foram comparados e os valores foram muito próximos, demonstrando que os mutantes excluídos podem ser removidos, pois não revelarão defeitos diferentes daqueles revelados pelos mutantes que permanecerão no experimento. O critério de seleção de operadores para redução considerou também a experiência do testador que apontou quais seriam os operadores mais interessantes, considerando as características do software e o conhecimento da equipe de desenvolvimento. As Tabelas 2, 3 e 4 listam os operadores aplicados em cada um dos três experimentos. Operador tinsec topmt topcp topcj, inot, rnot tpoat, tat tvr tpovr tnmtb tjoin tfuag toplg Tabela 4: Operadores Aplicados no Experimento 3 Observações Aplicado às permutas de INTERCEPT e EXCEPT pelas outras intersecções. Todas as trocas possíveis para estes operadores foram utilizadas. Aplicado às permutas do operador adição pelo operador subtração. Todas as trocas possíveis para este operador foram utilizadas. Aplicado às permutas dos operadores igualdade, maior e menor pelos demais operadores comparativos. Todas as trocas possíveis para estes operadores foram utilizadas. Todas as trocas possíveis foram aplicadas. Aplicado para 10% dos atributos. Aplicado para 10% dos valores em condições Aplicado para 10% dos atributos em atualizações. Aplicado para 10% das tabelas. Aplicado às permutas de INNER JOIN pelos outros tipos de JOIN. Todas as trocas possíveis para este operador foram utilizadas. Aplicado às permutas de AVG e MIN por MAX, COUNT, MIN, AVG e SUM. Todas as trocas possíveis para tallany, tanyall, texun foram aplicadas. 6.2 Procedimento de Realização dos Experimentos A realização do experimento ocorreu em 3 passos, sendo o primeiro passo diferente para o Experimento 3 pois, ao contrário dos outros, utilizou o Cenário 2 (Seção 3.2): Passo 1: O testador entra com uma combinação de instâncias do banco de dados (Bases 1 e 2) e com valores de entrada parametrizados (dados de entrada dos casos de testes projetados pelo testador) em uma UP (nos Experimentos 1 e 2), que obtém como saída comandos de manipulação da SQL, que por sua vez, selecionam ou modificam registros em suas instâncias alvos do BD. No Experimento 3, tais dados são aplicados para executar uma seqüência de comandos SQL, que são retirados de procedures; estes alteram e modificam as instâncias alvos do BD. Passo 2: A ferramenta armazena informações das alterações e modificações juntamente com os comandos executados; os operadores de mutação selecionados são aplicados automaticamente pela ferramenta nos comandos SQL coletados e os mutantes gerados são executados (os comandos originais são gerados antes do mutante). Após a 40

62 execução, as informações sobre as alterações e seleções feitas são armazenadas e comparadas com os comandos de manipulação original. Passo 3: A ferramenta automaticamente classifica os mutantes em mortos ou vivos. No caso de mutantes vivos a ferramenta demonstra os resultados tanto do comando original quanto do mutante, para que o testador decida se o mutante é equivalente ou não. A ferramenta permite que o mutante seja re-executado isoladamente para análise. O escore de mutação EscM é gerado para cada caso de teste executado no experimento e seus valores são avaliados. 6.3 Resultados dos Experimentos A Figuras 1, 2 e 3 apresentam os escores de mutação obtidos nos Experimentos 1, 2 e 3, respectivamente, para as bases de dados 1 e 2 de cada experimento. Foi observado, nos Experimentos 1 e 2, uma variação na quantidade de comandos SQL entre suas bases de dados: 79 e 85 comandos (Experimento 1), 71 e 66 comandos (Experimento 2), para as bases de dados 1 e 2, respectivamente. Essa variação ocorreu devido ao fato de as instâncias das bases de dados exercitarem partes diferentes do software em teste. O Experimento 3 foi realizado com os mesmos 42 comandos SQL para ambas as bases, devido às características do cenário do experimento (Cenário 2). Na maioria dos casos de teste dos Experimentos 1 e 3, os escores de mutação alcançados para a base de dados 1 foram superiores ou iguais aos obtidos para a base de dados 2. No Experimento 2, a base de dados 2 obteve melhores escores de mutação. Assim, os Experimentos 1 e 2 sugerem que as bases de dados reduzidas, as quais foram preparadas pelas empresas para a realização de testes (base de dados 1 no Experimento 1, e base de dados 2 no Experimento 2), possuem habilidade igual ou melhor de detecção de defeitos do que as bases de dados de produção. Por outro lado, a redução simples de uma base de dados pode causar perda em sua habilidade de detecção de defeitos (base de dados 2 no Experimento 3). No Experimento 1, a aplicação dos operadores de Troca de Posição, tais como tpoat e tpovr, mostrou que as bases de dados possuem um esquema bem definido, uma vez que todos os mutantes definidos a partir desses operadores foram mortos por ambas as bases, pois as restrições de dados estão preparadas para não receber dados inválidos. Por outro lado, a aplicação desses operadores para comparar a qualidade dos dados entre as duas bases é ineficiente, pois o esquema (meta-dado) e os escores de mutação obtidos são iguais para as bases de dados. No Experimento 2, a base de dados reduzida (base de dados 2) exercitou menos código (5 comandos a menos) e revelou 2 defeitos a menos em relação à base de dados de produção (base de dados 1). Contudo, apenas a base de dados reduzida revelou alguns defeitos e o escore de mutação para esta base de dados foi mais elevado do que o da base de produção para a maioria dos operadores de mutação. Na Figura 2, observa-se que o escore de mutação para ambas as bases de dados é similar em muitos casos de teste, podendo indicar que a base reduzida possui eficiência de detecção de defeitos, no mínimo, similar à da base de produção. 41

63 Escore de Mutação 1,000 0,900 0,800 Escore de Mutação 0,700 0,600 0,500 0,400 0,300 Base 1 Base 2 0,200 0,100 0, Casos de Testes Figura 1: Escores de mutação para as bases de dados 1 e 2 do Experimento 1. Escore de Mutação 1,000 0,900 0,800 0,700 Escore de Mutação 0,600 0,500 0,400 Base 1 Base 2 0,300 0,200 0,100 0, Casos de Testes Figura 2: Escores de mutação para as bases de dados 1 e 2 do Experimento 2. No Cenário 1 (Experimentos 1 e 2), as seqüências de comandos SQL resultantes do emprego de bases de dados diferentes podem ser distintas. Essa possibilidade não invalida a análise para a comparação das bases de dados, pois os escores de mutação representam valores relativos com respeito a defeitos comuns no software (operadores de mutação). O Cenário 2 possui um efeito de comparação mais forte, pois a seqüência de comandos SQL (e qualquer de seus componentes) será igual, independentemente das bases de dados de entrada. Assim, do Experimento 3, conclui-se que a base de dados 1 é superior à base de dados 2 para a detecção de defeitos. 42

64 Escore de Mutação 1,000 0,900 0,800 0,700 Escore de Mutação 0,600 0,500 0,400 0,300 0,200 0,100 0, Base 1 Comandos Base 2 Figura 3: Escores de mutação para as bases de dados 1 e 2 do Experimento Considerações Finais O operador de troca de join conseguiu atingir, no Experimento 3, ao contrário dos outros dois experimentos, escores de mutação distintos de zero. Se a base de dados for boa o suficiente para revelar este tipo de defeito, ele será revelado. Assim, dos 2 primeiros experimentos conclui-se que as bases de dados eram ruins e não que o operador é difícil de matar. Contudo, a seleção dos operadores de troca de join deve ser feita cautelosamente, devido aos seus baixos escores de mutação. Um aspecto favorável às bases de dados reduzidas é o tempo de processamento; mesmo com a utilização de poucos operadores de mutação, o tempo de processamento das bases de produção foi muito superior ao das bases reduzidas. 7. Trabalhos Relacionados Na aplicação da análise de mutantes em aplicações de banco de dados com SQL, temos conhecimento de apenas dois estudos, com as seguintes características: (i) criação de operadores de mutação baseado em apenas um comando de manipulação; e (ii) uso de dados sintéticos. Em Tuya et al. (2007), são propostos operadores de mutação para comandos de consulta SQL (SELECT) envolvendo mutações para: as principais cláusulas da SQL, condições e expressões, manipulação de valores nulos e substituição de parâmetros, tuplas e constantes. Os mutantes foram gerados a partir de comandos estáticos de consulta SQL. O experimento ocorreu em uma base de dados que sofreu alterações conforme a aplicação dos operadores. A detecção de mutantes equivalentes e a criação de casos de testes adicionais são realizadas de forma manual; não se indica se existe automação. O artigo abrange também o conceito de redução de custos, utilizando a técnica de redução do número de mutantes por mutação seletiva [Mathur, 1991] e redução do tamanho do conjunto de teste por ordenação de mutantes [Rothermel e Elbaum, 2003; Rothermel et al., 2001; Elbaum et al., 2002]. O experimento não inclui 43

65 comandos de consulta SQL complexos, tais como sub-consultas e utilização de múltiplas tabelas, e não utiliza dados reais. Segundo os autores, a ausência de dados reais torna o experimento incerto em relação à representatividade de cada consulta, em termos das combinações de características que podem ser encontradas no mundo real, impossibilitando a comparação da aplicabilidade dos operadores com sistemas reais. Chan et al. (2005) propõem operadores de substituição para a mutação da SQL. A abordagem explora informações semânticas do modelo de dados conceitual, tais como relações entre os atributos armazenados e derivados para a criação dos mutantes, de acordo com a família de operadores de substituição definida. A mutação ocorre nos comandos SQL embutidos na linguagem hospedeira. O artigo não mostra resultados da aplicabilidade dos mutantes e nem apresenta uma ferramenta ou uma abordagem de como automatizar a geração, execução e avaliação dos mutantes. Os operadores de mutação definidos pelo artigo são apenas para consulta (comando SELECT) e o motivo de tal escolha não é explicitado no trabalho. O artigo é pioneiro na aplicação da análise de mutantes para comandos SQL. 8. Conclusões O objetivo principal do trabalho é a melhoria da qualidade dos testes de aplicações de banco de dados, pela seleção de bases de dados mais reveladoras de defeitos, por meio da aplicação da análise de mutantes em comandos da linguagem SQL. A motivação para este trabalho é a constatação de que apenas dois estudos buscam o mesmo objetivo [Tuya et al., 2007; Chan et al., 2005] e, mesmo assim, tais pesquisas limitam-se ao estudo de comandos estáticos de consulta da linguagem SQL e a experimentos utilizando apenas dados sintéticos e sem suporte à automação. As principais contribuições deste trabalho são: definições para o teste de mutação aplicado a SQL; definição e caracterização de cenários para a aplicação do teste de mutação em SQL, nos níveis de mutação fraca e forte; definição e categorização de operadores de mutação para SQL; análise experimental usando aplicações reais e dados reais, cobrindo os cenários definidos e apresentando resultados promissores para a aplicação de teste de mutantes em aplicações SQL, com respeito à detecção de defeitos e à aplicabilidade da técnica. Uma peculiaridade dos cenários definidos é a mutação de seqüências de comandos da SQL, as quais são oriundas da execução de aplicações. Tais seqüências caracterizam o código da aplicação que manipula os dados persistentes. A abordagem permite o teste de aplicações com montagem dinâmica de comandos da SQL. Uma conclusão é a constatação de que a técnica permite a comparação de bases de dados nos cenários de mutação forte e fraca. Nos experimentos foram utilizadas bases de dados de produção e bases de dados reduzidas, as quais são dedicadas à atividade de teste. A aplicação da técnica permitiu avaliar a qualidade das bases de dados reduzidas. 44

66 Alguns trabalhos futuros são: estender a análise experimental a outras aplicações reais e dados reais; implantar a técnica nas empresas que colocaram à disposição os programas e dados reais para o experimento; inicialmente, motivar a avaliação de todas as bases de dados reduzidas derivadas de bases de dados de produção, para aquilatar a sua eficácia na atividade de teste. 9. Referências Bibliográficas ANSI SQL-3 STANDARD, Acesso em: 12 de jun Chan,W.K., Cheung, S.C., and Tse, T.H. (2005) Fault-based testing of database application programs with conceptual data model. Proceedings of the 5 th Intl. Conference on Quality Software, IEEE Computer Society Press, pg , Los Alamitos, CA. Chan, M. Y. and Cheung, S. C. (1999) Testing Database Applications with SQL Semantic. Proceedings of the 2 nd Intl. Symposium on Cooperative Database Systems for Advanced Applications, Springer, pg , Singapore. Chays, D. and Deng, Y. (2003) Demonstration of AGENDA Tool Set for Testing Relational Database Applications. Proceedings of the 25 th Intl. Conference on Software Engineering, pg , Portland, Oregon. DeMillo, A.R., Lipton, R.J., and Sayward, F.G (1978). Hints on test data selection: Help for the practicing programmer. IEEE Computer, Vol.11, nº 4, pg DeMillo, A.R. (1980) Mutation analysis as a tool for software quality assurance. Proceedings of COMPSAC 80, Chicago, IL, pg Deutsch, M. (1979) Verification and Validation in Software Engineering (R. Jensen and C.Tonies, Eds.), Prentice-Hall, 1979, pg Elbaum, S., Malishevssky, A.G., and Rothermel, G. (2002). Test case priorization: A family of empirical studies. IEEE Trans. on Software Engineering 28 (2), pg Kapfhammer, G.M. and Soffa, M.L. (2003). A Family of Test Adequacy Criteria for Database-Driven Applications. European Software Engineering Conference and ACM SIGSOFT Symposium on the Foundations of Software Engineering, ESEC/FSE. Helsinki, Finland, pg Leitao-Junior, P.S., Vilela, P.R.S., and Jino, M. (2005). Mapping Faults to Failures in SQL Manipulation Commands. Proceedings of the 3 rd ACS/IEEE Intl. Conference on Computer Systems and Applications (AICCSA-05), pg 1-4, Egito, Cairo. Mathur, A.P. (1991). Performance, effectiveness and reliability issues in software testing. 15 th Annual International Computer Software and Application Conference, Tokio, Japan, IEEE Computer Society Press, pg Offutt, A.J, Lee, A., Rothermel, G., Untch, R.H and Zapf, C. (1996) An experimental determination of sufficient mutant operators". ACM Trans. on Software Engineering Methodology, Vol.5, n o 2 pages

67 Pönighaus, R. (1995) Favourite SQL-Statements an empirical analysis of SQL- Usage in commercial applications. Proceedings of the 6 th Intl. Conference on Information Systems and Management of Data, Lecture Notes in Computer Science, Vol. 1006, Springer, pg Rothermel, G. and Elbaum, S. (2003) Putting your best tests forward. IEEE Software 20 (5), pg Rothermel, G., Untch, R.H., and Harrold, M.J. (2001). Prioritizing test cases for regression testing. IEEE Trans. on Software Engineering 27 (10), pg Spoto, E.S. (2000). Teste Estrutural de Programas de Aplicação de Banco de Dados Relacional. Tese de Doutorado, DCA/FEEC/UNICAMP, Campinas, SP, Brasil. Tuya, J., Suárez-Cabal, M.S. and de la Riva, C. (2007) Mutation Database queries. Information and Software Technology 49, pg Woodward, M.R. (1993). Mutation Testing its Origin and Evolution. Information and Software Technology, Vol. 35, nº 3, pg

68 Atabaque: uma contribuição de sucesso na evolução de processos Viviane Malheiros 1,2, Serge Rehem 2, José Carlos Maldonado 1 1 Instituto de Ciências Matemáticas e de Computação USP Caixa Postal São Carlos SP Brazil 2 Serpro Serviço Federal de Processamento de Dados Av. Luiz Vianna Filho, 2355, Paralela, Salvador/BA, Brazil Abstract. For many software development organizations, having well-known, documented and continuously improved processes can be a business advantage. Process documentation, however, is not a trivial task. The efficient maintenance of process assets, while guarantying its general integrity, can be an onerous, complex and very error prone task. Therefore, it is important to provide tools to support process documentation and evolution. In this article, we present Atabaque, a free and simple solution for processes documentation on a collaborative environment, that is based on open standards as XML, XSL and HTML. After almost two years since its conception and first use, it is possible to analyze some benefits of its use. Resumo. Para muitas organizações de desenvolvimento de software, processos documentados, conhecidos e continuamente melhorados podem ser um grande diferencial. A documentação de um processo, contudo, não é tarefa trivial. A manutenção eficiente desses ativos, incluindo a garantia da integridade geral do processo, pode ser uma atividade muito onerosa, complexa e propensa a erros. Por isso, é importante prover ferramentas para apoiá-la. Nesse artigo, apresentamos Atabaque, uma solução livre e simples para documentação de processos de forma colaborativa, baseada em padrões abertos como XML, XSL e HTML. Há quase dois anos desde sua concepção e primeira utilização, já é possível analisar os benefícios de seu uso. 1. Introdução A definição e evolução de processos de software não são tarefas triviais. Um processo de software bem definido deve indicar as atividades a serem realizadas, os recursos necessários, os produtos e modelos a serem elaborados/ utilizados, os procedimentos a serem executados (métodos, técnicas, etc.), as ferramentas e os papéis a serem desempenhados. Várias pesquisas destacam a melhoria dos processos de produção de software como uma opção para aumentar a qualidade do produto de software e/ou reduzir o tempo e o custo de desenvolvimento, associando a qualidade do produto a qualidade do processo adotado para produzi-lo. Muitos estudos têm sido conduzidos explorando diferentes perspectivas da melhoria de processos: definição de processos e sua evolução contínua; institucionalização de processos; adequação de processos a diferentes contextos e perfis (ex: adoção de métodos ágeis ou de abordagens tradicionais - Boehm 47

69 and Turner(2004)); padronização x customização de processos; etc. Essas vertentes de pesquisa têm em comum, em menor ou maior grau, a necessidade de documentação (explicitação) de todo o processo ou parte dele. Neste contexto, a documentação de processos, sua evolução e a sua disponibilização são atividades importantes. Essas atividades viabilizam o compartilhamento e a retenção do conhecimento de uma organização. Por meio do processo é possível saber quem faz o que, quando e como para que um objetivo seja atingido. Quanto mais amigável for o acesso ao seu conteúdo, mais fácil será a absorção do conhecimento embutido naquele processo e, conseqüentemente, a inovação e a geração de novo conhecimento a partir do conhecimento explicitado no processo (REHEM, 2006). Além de definir um processo, para que ele se mantenha adequado, é preciso melhorá-lo. No entanto, a manutenção eficiente do processo e da sua documentação, garantindo a integridade do mesmo, pode ser uma atividade onerosa, complexa e propensa a erros. Osterweil (1997) estabelece uma analogia entre software e processo de software, uma vez que ambos são executáveis, possuem um conjunto de requisitos, apresentam benefícios se modelados por uma variedade de técnicas e evoluem guiados por medições. Essa analogia é interessante para entender a magnitude de manutenções em processos de desenvolvimento de software (MALHEIROS, 2007). Tal qual acontece nas manutenções evolutivas e adaptativas de software, é possível identificar e tratar fraquezas de uma versão de um processo de desenvolvimento, convertendo-as em melhorias para a próxima versão. Nesse contexto, soluções automatizadas que apóiem a documentação e a evolução de processos podem ser muito úteis. Essa foi a principal motivação para a concepção da ferramenta livre Atabaque, cujo objetivo é contribuir para a documentação e evolução de processos documentados em formato de sistemas hipermídia. Sua premissa básica é separar o conteúdo do processo (XML 1 ) da sua forma de apresentação (HTML 2 ). Este trabalho apresenta Atabaque, procurando antes esclarecer os fundamentos para sua compreensão. Após mais de um ano desde sua concepção e primeira apresentação no Conserpro é possível apontar os benefícios e as limitações da solução, bem como a evolução de suas funcionalidades. Além da esperada facilidade de atualização do processo, a possibilidade de controlar e explorar meta-dados do processo tem se mostrado muito interessante. A atividade de adaptação de processos (tailoring) também pode ser otimizada com a utilização da solução. Também chama a atenção o interesse pelo assunto por parte da comunidade de software livre. Na Seção 2, são descritos alguns conceitos de melhoria de processo. A ferramenta Atabaque, e sua contribuição para melhoria de processo, é descrita na Seção 3. Os resultados alcançados até o momento e a aplicação da ferramenta em uma organização de desenvolvimento de software de grande porte procuram demonstrar como Atabaque pode contribuir para a superação dos entraves inerentes a evolução dos 1 XML (extensible Markup Language) é uma linguagem puramente baseada em texto, criada pelo consórcio W3C, que está rapidamente se tornando um padrão para troca de informações entre sistemas ( 2 HTML (Hyper Text Markup Language) é uma linguagem de marcação de hiper texto utilizada para construção de páginas Web, visualizadas através de programas chamados navegadores (ou browsers). 3 O Conserpro é um congresso nacional interno promovido desde 2004 pelo Serpro. 48

70 processos (Seção 4). Alguns trabalhos relacionados são comentados na seção 5. Por fim, as conclusões, contribuições e oportunidades de trabalhos futuros são consolidadas na Seção Conceitos Básicos Entende-se por processo de software um conjunto coerente de políticas, estruturas organizacionais, tecnologias, procedimentos e artefatos que são necessários para conceber, desenvolver e manter um produto de software (FUGGETTA, 2000). Um processo de software bem definido deve indicar as atividades a serem executadas, os recursos requiridos, os artefatos consumidos e produzidos e os procedimentos a serem adotados (métodos, técnicas, modelos de documentos, entre outros) (BERTOLLO, SEGRINI e FALBO, 2006). Os processos de desenvolvimento normalmente se enquadram em duas categorias: Técnicos - são processos orientados ao produto, envolvem a especificação e criação dos produtos resultantes do projeto; e Gerenciais - são processos que envolvem a organização do trabalho dentro do projeto. Independentemente da categoria, é possível identificar os componentes de um processo de software (atividades, artefatos, ferramentas, etc.). Os processos (e seus componentes) podem ser documentados/disponibilizados de várias formas. O foco deste trabalho são os processos documentados em formato de sistemas hipermídia. A definição e manutenção de processos são tarefas complexas, inerentemente baseadas em conhecimento e suscetíveis a vários tipos de problemas, agrupados neste artigo em duas categorias: problemas semânticos e problemas de exibição: Os problemas semânticos são aqueles relacionados com o conteúdo, o significado de cada ativo do processo. A utilização da expressão problema de conteúdo será evitada para que não se confunda com o significado atribuído à palavra conteúdo na expressão geração de conteúdo, utilizada neste artigo. São exemplos de problemas semânticos: definição equivocada de termos; fórmulas de cálculo erradas; definição de procedimentos burocráticos e pouco eficientes. Os problemas de exibição são aqueles relacionados com a forma como os ativos documentados do processo são disponibilizados. Estão nessa categoria erros como: tamanho e tipo de fonte; links quebrados e inconsistentes; alinhamento; cores; e consistência entre a forma de exibição e o conteúdo semântico que está sendo exibido. Os dois tipos de problemas precisam ser tratados e, paulatinamente, eliminados do processo. Ambos demandam tempo e recurso e podem influenciar negativamente na qualidade do processo e, conseqüentemente, do produto final. Apesar de serem de mais simples identificação e correção, os problemas de exibição podem comprometer a obtenção de conhecimento a partir do processo de desenvolvimento documentado e promover resistência à sua utilização, além de gerar descrédito no conteúdo disponibilizado. Portanto, pode-se afirmar que problemas de exibição têm impacto na usabilidade do processo. O interesse em usabilidade cresceu após o gradativo reconhecimento do quanto as interfaces são mal projetadas e do quanto uma interface elegante pode trazer de benefício (SHNEIDERMAN e PLAISANT, 2004). A norma NBR/ISO define usabilidade como a medida na qual um produto pode ser usado por usuários específicos 49

71 para alcançar objetivos específicos com eficácia, eficiência e satisfação em um contexto de uso específico. As pesquisas na área de processos de software nos últimos anos têm explorado duas principais vertentes (ARBAOUI et al.,2002 apud BERTOLLO, SEGRINI e FALBO, 2006): (i) abordagens para modelagem, análise e melhoria do processo de software; (ii) tecnologia de apoio ao processo de software. A primeira vertente enfoca abordagens e melhores práticas para estruturação, organização, documentação e descrição formal de processos de software e inclui normas de qualidade de processo de software e modelos de qualidade de processo (BERTOLLO, SEGRINI e FALBO, 2006), tais como o CMMI (SEI, 2002) e o MPS.BR (SOFTEX, 2005). O mercado fornece também arcabouços (frameworks) de processos que podem ser reutilizados nas empresas. Um exemplo é o Rational Unified Process RUP (RUP, 2005). A segunda vertente enfoca desenvolvimento de Ambientes de Desenvolvimento de Software (ADS) Centrado em Processos, integrando ferramentas de apoio ao desenvolvimento de artefatos com ferramentas de apoio à modelagem e execução de processos de software (BERTOLLO, SEGRINI e FALBO, 2006). Seja baseado em uma ou em outra vertente, atualmente é amplamente reconhecido por pesquisadores que a utilização de métodos, processos e ferramentas de desenvolvimento em projetos pode contribuir decisivamente para a qualidade do produto final. Em ambas as vertentes, uma descrição efetiva dos ativos do processo pode ser decisiva para a compreensão tanto do objetivo de cada componente isoladamente (atividade, papel, etc.) quanto do fluxo a ser adotado (integração dos componentes). Atabaque pode apoiar a definição/manutenção de processos, (a) agilizando e minimizando a possibilidade de ocorrência de problemas de exibição e (b) possibilitando a exploração de diferentes formas de apresentação, potencialmente contribuindo para a usabilidade do processo. 3. Atabaque Atabaque é uma solução livre e simples para documentação de processos de forma colaborativa, baseada em padrões abertos como XML, XSL e HTML. Sua principal vantagem é permitir que os criadores e mantenedores de processos se preocupem eminentemente com os problemas semânticos (problemas do processo diretamente relacionados com suas atividades, entradas, saída, artefatos, etc.) e não com os problemas de exibição. Adicionalmente, estudos da usabilidade da documentação do processo podem rapidamente evoluir para intervenções na exibição, sem que o conteúdo do processo seja afetado. O isolamento das duas perspectivas aumenta a flexibilidade da evolução do processo. O encapsulamento de alguns passos e a geração automática de alguns itens da documentação do processo aumentam a integridade do processo como um todo. O movimento de software livre vem ganhando espaço no mercado e despertando o interesse da academia, do governo e da indústria. Software Livre é qualquer software cuja licença garanta ao seu usuário liberdades relacionadas ao uso, alteração e redistribuição. Seu aspecto fundamental é o fato do código-fonte estar livremente disponível para ser lido, estudado ou modificado por qualquer pessoa interessada (REIS, 2003). A solução Atabaque, aqui apresentada, está consonante com o movimento de software livre pois foi concebida e disponibilizada como um software 50

72 livre e pode ser lida, estudada ou modificada por qualquer pessoa interessada. Além disso, a ferramenta utiliza componentes livres e gera todas as informações do processo em padrões abertos. A solução Atabaque é baseada em componentes, permitindo a aplicação das suas funcionalidades como um todo ou o uso de apenas alguns de seus componentes. Além disso, a própria evolução da ferramenta pode acontecer isoladamente. As principais funcionalidades disponíveis em Atabaque são: Componente Editor Visual; Componente Gerador de Site e Processo Modelo Gerador de Site Para representação do conteúdo do processo gerado a partir de Atabaque foi escolhida linguagem XML (BRAY, 2004), por se tratar de um padrão aberto e baseado em arquivos puramente texto, de fácil compreensão. Um processo definido/ mantido em XML é facilmente lido por humanos, convertido para bancos de dados relacionais, transformado para exibição em HTML e integrado com ferramentas visuais de modelagem de processo. O fato de ser um padrão aberto facilita a manutenção colaborativa de Atabaque e viabiliza, por exemplo, que uma empresa compartilhe seu processo para que outras a tomem como modelo e o evoluam conforme sua conveniência. São inúmeras as possibilidades de compartilhamento de conhecimento que podem ser proporcionadas a partir da abordagem proposta. A utilização de XML, e sua possível exibição em HTML, tem o benefício de permitir a utilização de browsers para a navegação do processo, o que pode trazer ganhos para usabilidade como: facilidade de aprendizado, o processo deve ser fácil de aprender; permanência, deve ser fácil lembrar-se de como navegar pelo processo, para que mesmo o usuário eventual possa retomar o seu uso, após longo períodos sem utilizá-lo, sem a necessidade de aprender todos os procedimentos de novo; acessibilidade, flexibilidade para a sua utilização por pessoas com necessidades especiais, bem como a utilização em diferentes ambientes e situações, e através de vários equipamentos ou navegadores; satisfação, o processo deve ser agradável de usar, agradando subjetivamente aos usuários. Por essas razões, e por ser um padrão altamente difundido na internet, o formato de apresentação adotado é o HTML, permitindo a visualização do processo usando qualquer navegador, independente de sistema operacional. O componente Gerador do Site é responsável pela transformação de XML para HTML por meio da linguagem XSL - extensible Stylesheet Language (ADLER, 2001). XSL também é um padrão aberto baseado em XML, criado com o propósito de processar toda estrutura hierárquica de um documento XML gerando uma saída normalmente em formato texto, HTML ou até mesmo outro XML. De forma simplificada, um arquivo XSL define as regras de transformação de um documento XML. Detalhes sobre o funcionamento desse componente estão disponíveis em atabaque.sourceforge.net. Na Figura 1, é ilustrado um exemplo de sítio de processo construído com a ferramenta Atabaque, resultado da aplicação do componente Gerador 51

73 do Site. Figura 1 Exemplo de sítio de processo gerado com Atabaque 3.2. Editor Visual Sem o uso da ferramenta Atabaque, qualquer processo poderia ser totalmente construído utilizando-se um editor de textos comum para editar os arquivos XML e XSL. Para gerar os arquivos HTML, a partir dos arquivos XML e XSL, seria necessário utilizar algum processador (parser) XML para promover as transformações especificadas (o Gerador de Site utiliza um parser desse tipo). O conjunto de todos arquivos HTML gerados seriam disponibilizados em um servidor Web e formariam o sítio do processo. No entanto, o acompanhamento de sucessivas manutenções em processos documentados em HTML mostrou que essa atividade pode demandar muito esforço e limitar o perfil das pessoas que atuam diretamente na evolução de um processo, já que conhecer HTML torna-se um habilidade requerida. Embora seja mais fácil editar o XML de um processo (pois não é necessário preocupar-se com formatação, apenas conteúdo), ainda assim seria necessário alguma compreensão das regras exigidas pelo XML. Nesse contexto, editores visuais que facilitem o trabalho de construção do processo, isolando o mantenedor do processo de detalhes técnicos da implementação em XML, podem ser muito úteis. Um componente Editor Visual foi desenvolvido para Atabaque, eliminando a necessidade de utilização de editores de texto ou de HTML/XML. O editor visual (Figura 2), além de permitir a edição de todo o conteúdo do processo, permite o acionamento do componente Gerador de Site para executar as transformações definidas no XSL. 52

74 Figura 2 Editando o conteúdo de um processo com Atabaque A partir da Figura 2, é possível perceber como a manutenção do processo acontece de forma isolada dos detalhes técnicos de documentação. O editor traz uma árvore com todos os componentes do processo, organizados de acordo com a estrutura estabelecida para o processo (ver exemplo na seção 3.3 Processo Modelo). Um mantenedor de processo pode, então, selecionar um componente do processo para alteração, criar novos componentes ou excluí-los. No exemplo, o mantenedor está trabalhando em uma sub-atividade ( Verificar Andamento do Projeto ), podendo alterar sua descrição ou qualquer atributo, como participantes, entradas e saídas. Vale ressaltar que nesse momento, nenhuma característica visual está sendo trabalhada. O mantenedor do processo está focado apenas no seu conteúdo. Apenas, poucos recursos de edição de texto estão disponíveis basicamente para permitir ênfase em trechos, como alteração de efeitos de fonte para negrito, itálico ou sublinhado. Para tal, é utilizada a notação Wiki 4, auxiliada por um componente criado para este fim (Figura 3). O usuário também não precisa conhecer a notação Wiki já que botões para formatação de texto são disponibilizados (Figura 3). A limitação dos recursos disponíveis de edição de texto nesse editor é proposital, já que a intenção é que o foco seja eminentemente no conteúdo. As características visuais do processo serão trabalhadas isoladamente em arquivos XSL e folhas de estilo CSS 5, por pessoas com perfil para essa atividade. Esse 4 A notação Wiki possui uma sintaxe simples baseada em texto (por exemplo, usar texto para exibir um trecho em negrito. 5 Cascading Style Sheets é uma linguagem de estilo utilizada para definir a apresentação de documentos escritos em uma linguagem de marcação, como HTML ou XML. 53

75 isolamento tem o benefício de garantir a padronização visual do processo Processo Modelo Figura 3 Usando a notação Wiki para editar conteúdo Para iniciar o uso do Atabaque é preciso, primeiramente, definir o Processo (que está sendo documentado), sua estrutura e componentes (ex: atividade, artefato, papel). Definido o processo conceitualmente, três passos podem ser aplicados para documentação desse processo com o apoio de Atabaque: 1. um mapeamento dos meta-dados do processo (estrutura e componentes) e sua organização em arquivos XML, de acordo com uma estrutura de diretórios específica; 2. a definição das características visuais (folhas de estilo, padrões/tamanhos/cores de fonte, layout do sítio) do processo. Nesse caso, as regras de transformação seriam montadas, por meio da criação de arquivos XSL específicos a cada área de conhecimento; 3. criação de editores visuais específicos para evitar a manipulação direta de XML pelos mantenedores do processo. A versão de Atabaque disponível no SourceForge (atabaque.sourceforge.net) fornece um processo hipotético (com toda estrutura mapeada e definição de características visuais), que pode ser usado como ponto de partida para o mapeamento de novos processos. Esse processo hipotético foi encapsulado no componente Processo Modelo. O uso do Processo Modelo pode eliminar ou minimizar a necessidade dos passos 1, 2 e 3. A estrutura utilizada pelo componente está representada na Figura 4. Aparentemente, essa estrutura de processo é genérica e pode ser utilizada para a documentação da maioria dos processos de desenvolvimento de software, mas essa adequação precisa ser avaliada e comparada com ontologias de processo existentes. Essa estrutura é compatível com a estrutura do framework RUP (RUP, 2005). 54

76 Figura 4 Estrutura de processo implementada pelo componente Processo Modelo. Diagrama UML adaptado. Um mesmo papel pode ser participante e responsável para atividades distintas. Um mesmo artefato pode atuar como entrada e também como saída. Caso a estrutura de referência do Processo Modelo (Figura 4) seja equivalente a estrutura definida para o processo a ser documentado, o passo 3 pode ser completamente eliminado com a utilização do componente Editor Visual já disponível em Atabaque. O passo 1, por sua vez, será resumido ao detalhamento dos atributos de cada componente do processo. Caso as características visuais do Processo Modelo sejam adequadas para a organização, o passo 2 pode ser completamente eliminado. Da forma como foi concebido, Atabaque também pode ser utilizado para redocumentar processos existentes em formato hipermídia. Sua estrutura flexível e adaptável (Atabaque se adapta a qualquer processo) permite manter o mesmo resultado visual do processo já documentado e, ao mesmo tempo, melhorá-lo para que se beneficie dos ganhos decorrentes da separação do conteúdo da forma de apresentação. A execução dos passos 1, 2 e 3, especialmente do 2, demandará maior ou menor esforço a depender das diferenças do processo sendo redocumentado para o Processo Modelo disponível em Atabaque. Mas, uma vez executado o processo de migração, a evolução do processo poderá se beneficiar de todos os ganhos identificados com o uso da ferramenta Atabaque. 4. Resultados alcançados Logo após a sua criação, a ferramenta Atabaque foi aplicada em um estudo de caso, para sua validação e identificação de oportunidades de melhoria. Observações identificadas à época foram registradas em Rehem (2006). A divulgação da ferramenta permitiu que os autores tivessem contato com a abordagem de desenvolvimento colaborativo do software livre. Interessados na solução apareceram em alguns lugares do país, um deles tornando-se um desenvolvedor ativo da ferramenta. Em função de comentários recebidos, o editor visual da ferramenta foi melhorado e uma nova versão foi disponibilizada. O interesse na ferramenta pode ser demonstrado pelo histórico de download: entre a ferramenta e sua documentação foram 55

77 mais de 980 downloads (Figura 5), até o meados de março de É importante ressalvar que, apesar de demonstrar interesse, o histórico de downloads não demonstra satisfação dos usuários ou uso efetivo. Figura 5 Histórico da evolução dos downloads em sourceforge.atabaque.net Várias mensagens eletrônicas foram enviadas para os autores solicitando informações acerca da ferramenta. Observou-se que a proposta notadamente teve ressonância na comunidade de software livre. A simplicidade da ferramenta, o fato desta estar consonante com os princípios de software livre e a possibilidade de apoiar a documentação de qualquer processo, inclusive os inspirados nos princípios ágeis, contribuíram para aumentar o interesse. Também entraram em contato indivíduos da academia e a integração de Atabaque com a uma ferramenta acadêmica de adaptação de processos, Protto (PEREIRA, 2007), começou a ser estudada. Adicionalmente, a ferramenta está sendo avaliada para a definição e manutenção de processos de Gestão de Projetos em uma agência nacional do governo brasileiro. O intercâmbio com representante dessa agência permitiu a identificação de uma funcionalidade desejável: diagramação visual do processo. Discussões para desenvolvimento dessa funcionalidade estão em andamento, também lastreadas em padrões abertos. A ferramenta Atabaque (com todos os seus componentes) foi adotada para evolução de parte do processo de desenvolvimento padrão de uma organização de desenvolvimento de software de grande porte (mais de desenvolvedores de software). O número de propostas de melhoria para o processo relacionada a questões de exibição reduziu bastante. Nas duas últimas versões do processo, publicadas sem Atabaque, 13% das propostas de melhoria eram relacionadas a questões de exibição. Nas duas primeiras versões do processo publicadas com o uso de Atabaque, esse percentual caiu para 2%. Na última publicação do processo, disponível há mais de 2 meses, nenhum erro de exibição foi reportado até o fechamento deste artigo. Durante a última homologação do processo, nenhum erro de exibição ou inconsistência entre os componentes do processo foi reportado. Dados relativos a homologações de versões anteriores do processo não estavam disponíveis. No entanto, houve significativa melhoria, de acordo com uma análise subjetiva do grupo mantenedor: [Na etapa de] homologação é onde mais aparece este tipo de erro de exibição, o fato de ter caído a zero melhorou muito a etapa de homologação. 56

78 A manutenção do processo ficou mais rápida e agora é feita pelo próprio grupo mantenedor do processo, já no momento de definição da alteração. Recentemente, um dos grupos mantenedores do processo fez uma evolução no processo que envolveu: a eliminação de 5 artefatos, 4 atividades e 55 sub-atividades; a alteração de 30 subatividades e 7 atividades e a criação de 1 atividade. A manutenção total de 100% das atividades e 83% das sub-atividades foi feita em apenas 5 dias úteis. O próprio grupo estima que uma manutenção equivalente, sem o uso de Atabaque, demandaria ao menos 10 dias úteis, ou 100% a mais de esforço. Com o uso de Atabaque, o grupo está focado apenas no conteúdo do processo, questões relacionadas a apresentação ou integridade do que é exibido são tratadas implicitamente pela ferramenta. Antes do uso de Atabaque, a produtividade dos especialistas durante alterações do processo era muito inferior(no exemplo acima a produtividade dobrou), devido a preocupações com questões de exibição e necessidade de editar diretamente (ou através de algum software específico) arquivos HTML. O perfil do mantenedor também foi alterado, já que agora conhecer HTML não e mais um pré-requisito. A alteração pode ser feita diretamente pelo responsável pela definição do processo. Nenhum tempo foi investido para tratar questões visuais. A organização do conteúdo do processo em XML permitiu a exploração de meta-dados do processo. A definição e o acompanhamento de métricas sobre a melhoria de processos se beneficiam desses meta-dados. Esse potencial ainda deve ser mais explorado. Mas, a identificação dos dados da evolução acima citados já foi feita a partir do processo em Atabaque. Análises do tipo quantidades de erros por versão implantada podem ser mais precisas se o tamanho do processo é conhecido. Com a ferramenta é mais fácil responder, por exemplo, qual o percentual do processo alterado em uma manutenção. Se um artefato por exemplo é dissociado de uma atividade, a exclusão desse artefato, automaticamente implicará na remoção dos links para esse artefato no processo. 5. Trabalhos Correlatos Existem trabalhos publicados que apontam para o apoio automatizado a documentação e evolução de processos. Alguns deles foram, de alguma forma, testados empiricamente, outros ainda estão em estágio de proposta. A principal contribuição da ferramenta Atabaque é o fato de ser uma ferramenta livre (e multiplataforma, portanto independente de sistema operacional) podendo ser estudada, alterada e evoluída por qualquer interessado. Pelo que verificamos, as ferramentas existentes não disponibilizaram seu código. Disponibilizada como ferramenta livre, encontramos apenas ferramenta EPF Composer 6 (HAUMER, 2007), que parece interessante para a definição de processo. Essa ferramenta também privilegia um formato amigável do processo, mas induz seu usuário a usar a estrutura de processos e forma de visualização encontradas no seu processo (não está claro se outros formatos ou estrutura podem ser utilizados). Aparentemente é uma ferramenta mais completa que Atabaque. Por outro lado, pode ser mais difícil entendê-la e usá-la corretamente. Adicionalmente, a ferramenta não está pronta para ser usada por nativos da língua portuguesa. O fato de Atabaque está estruturado em componentes é outro diferencial da solução, assim, ela pode ser aplicada em diferentes contextos. Encontramos na internet, por exemplo depoimento sobre o uso de um componente 6 EPF Composer 57

79 isolado da ferramenta (Atabaque DTDtoBean, em dtdtobean.sourceforge.net) com o comentário Good work (bom trabalho). Trabalhos sobre documentação de processos são apresentados no contexto de ambientes de desenvolvimento de software (ADS) centrados em processo, estando fortemente ligados a esses ambientes. Esse é o caso das ferramentas AssistPro (FALBO, 1998) e Def-Pro (MACHADO, 2000) - relacionadas com a Estação Taba - e da ferramenta de definição de processos do ambiente ODE (RUY, 2003). Essas ferramentas são restritas ao sistemas operacionais Windows e não disponibilizam o código fonte. Elas compartilham o enfoque em definição de processos e divergem no suporte a especialização e instanciação de processos. Uma vantagem dessas ferramentas em relação a Atabaque é o fato delas incorporarem, de alguma forma, componentes de gestão de conhecimento (lições aprendidas sobre instanciação, tipo de ADS ou características da organização) para a definição dos processos. Por outro lado Atabaque tem um enfoque maior na apresentação final do processo (ganho em usabilidade), com mais recursos para a documentação de ativos gerais do processo. O formato final do processo é flexível e independente de seu conteúdo e Atabaque não tem qualquer vínculo com ADS, podendo ser utilizado por qualquer organização, mesmo aquelas que não pretendem migrar para um ADS. Atabaque parece mais adequado para documentação de framework de processos. A geração de páginas XML/HTML permite que o processo gerado seja acessado por qualquer máquina que possua um browser. Formatos diferentes de exibição podem ser definidos para cada componente (artefato, atividade, papel, etc.) e recursos de edição de texto estão disponíveis de forma a permitir ênfase onde for necessário. Foi iniciado um estudo de integração de Atabaque com a ferramenta Protto (PEREIRA, 2007), cujo objetivo é apoiar a adaptação de processos. Essas ferramentas são complementares. Com as funcionalidades de Protto e sua verificação de consistência, Atabaque poderá apoiar melhor a adaptação de processos, ao mesmo tempo que complementará Protto permitindo a integração da estrutura do processo com o seu conteúdo. Atabaque está integrado ao CVS 7 (e pode ser usado com qualquer outro sistema de controle de versão), permitindo controle das alterações no processo. O conteúdo do processo armazenado em XML permite que o CVS apresente as diferenças entre duas versões de um mesmo arquivo, ou ainda que pessoas diferentes trabalhem em paralelo em áreas distintas de um mesmo XML (por exemplo, em sub-atividades de uma mesma atividade), efetivando a junção (merge) ao final. Ao se consolidar uma versão oficial do processo também é permitido gerar linhas-de-base (baselines), recurso útil quando se deseja rastreabilidade das alterações. Nem sempre está claro se outras ferramentas possuem esse recurso, que é importante para uma manutenção colaborativa do processo. Outra linha de trabalho correlato é a construção de ferramentas de Gestão de Conteúdo que têm o mesmo, ou maior, potencial para uma documentação amigável em formato XML/HTML que Atabaque. As vantagens de Atabaque em relação a essas ferramentas são a sua adequação para documentação de processos e a possibilidade de tratar os meta-dados de processo. 7 Concurrent Version System, um popular sistema de controle de versão de código aberto, muito usado pelas comunidades de software livre ( 58

80 6. Conclusão e trabalhos futuros A ferramenta Atabaque se mostrou um instrumento efetivo para a geração de um processo e manipulação de seu conteúdo. Entre os benefícios de utilização da ferramenta foram observados: (a) rápida geração de páginas HTML, uma vez definidos os arquivos XSL e XML; (b) reutilização da estrutura das páginas (XSL) proporcionando agilidade na geração de novas páginas e minimização de problemas de inconsistência no formato das páginas; (c) facilidade de alteração no formato padrão de cada área de conhecimento (elemento do processo), exigindo a manutenção de apenas um arquivo XSL, ao invés de vários arquivos HTML como seria necessário na implementação de processos utilizando HTML(como na organização onde Atabaque foi implantado); (d) redução de erros de exibição (tamanho, tipo e cor de texto, links e tabelas) em função de todas as características de formatação estarem concentradas em um único XSL; (e) possibilidade de manutenção no site por pessoas com um baixo conhecimento da tecnologia Web. Atabaque tem pode contribuir para a gestão de conteúdo de processos em geral. Para a organização onde foi implantada, além de contribuir para a evolução do processo de desenvolvimento de software, a ferramenta pode ser adaptada para a evolução de outros processos que usam a tecnologia Web. Atabaque já está sendo utilizada gradativamente para a manutenção do processo de desenvolvimento. Sua validade para a manutenção desse processo pôde ser constatada por meio de sua aplicação no processo de Gestão de Projetos de desenvolvimento de software. Três versões do processo de Gestão de Projetos de desenvolvimento de software foram alteradas com Atabaque. A primeira versão alterada não utilizou o editor visual, que foi utilizado nas duas seguintes. A possibilidade de convivência pacífica entre partes do processo (as geradas de forma tradicional edição de HTML e as mantidas com Atabaque) é outra vantagem, pois pode-se definir um cronograma de plano de implantação, inicialmente focado nas áreas de conhecimento mais críticas, até que todo o processo seja migrado. Para os autores a experiência de desenvolver, disponibilizar e acompanhar o desenvolvimento de uma solução utilizando a filosofia do desenvolvimento em software livre tem sido enriquecedora, especialmente no que tange a colaboração proporcionada por esse tipo de desenvolvimento Sendo uma ferramenta livre, Atabaque surge como contribuição para as comunidades de software livre e de engenharia de software. Modelos de processo por área (engenharia de software, gestão de projetos, gerenciamento de serviços de TI, etc.) podem ser facilmente criados e compartilhados. Processos inteiros podem ser disponibilizados e diversos padrões de exibição HTML poderão surgir. Ao invés de algo restrito a poucas pessoas a modelagem de processos com Atabaque pode ser tratada por empresas de diferentes naturezas e tamanhos, envolvendo profissionais de diversas áreas, não necessariamente relacionadas a TIC. Com o aprendizado em diferentes contextos, a ferramenta pode ser evoluída por qualquer interessado e retornar para a comunidade como uma solução mais robusta e efetiva. A integração de Atabaque com outras ferramentas (RUY, 2003; MACHADO, FALBO, 1998) pode ser interessante, já que aparentemente são complementares. O ambiente ODES, apesar de não ter seu código disponível, é desenvolvido em plataforma livre, isso deve facilitar a integração. Atabaque e sua documentação estão disponíveis em 59

81 Referências ADLER, Sharon et al. Extensible Stylesheet Languagem (XSL) Version 1.0. World Wide Web Consortium Recomendation, 15 out Disponível em: < Acesso em: 27 jun ARBAOUI, S. DERMIANE,J., OQUENDO, F.Comparative review of process centered Software Engineering Enviroments. Software Engineering 14, p BERTOLLO, G. SEGRINI, B. FALBO, R. Definição de processos de software em um Ambiente de Desenvolvimetno de Software Baseado em Ontologias. In:V Simpósio Brasileiro de Qualidade de Software, Anais, BOEHM, B. and TURNER, R. Balancing Agility and Discipline: A Guide for the Perplexed. Addison-Wesley. Boston, MA, USA, BRAY, Tim et al. Extensible Markup Language (XML) 1.0 (Second Edition). World Wide Web Consortium Recommendation, 4 fev Disponível em: < Acesso em: 29 jun FALBO, R. Integração de Conhecimento em um Ambiente de Desenvolvimento de Software. Tese de doutorado, COPPE, UFRJ. Dezembro,1998. FUGGETTA, A. Software Process: A Roadmap. In: The Future of Software Engineering, ICSE 2000, Ireland, HAUMER, P. Eclipse Framework Composer. Available at: April, MACHADO, L. SANTOS, G., OLIVEIRA, K., ROCHA, A.R. Def-pro:Uma ferramenta para apoiar a Definição de Processos Padrões. XI conferência Internacional de Tecnologia de Software (CITS), MALHEIROS, V. Malheiros, V. Gestão de Conhecimento para Definição e Melhoria de Processos de Teste. Monografia de Qualificação de doutorado. Orientador: Prof. Dr. José Carlos Maldonado. Universidade São Paulo, abril, REHEM, S. Atabaque: Uma ferramenta livre para modelagem de processo de forma cooperativa. Congresso Serpro de Tecnologia e Gestão Aplicadas 2006 (ConSerpro 2006). Salvador, OSTERWEIL, J. Software processes are software too (revised). In Proc. Of the 1997 International Conference on Software Engineering, Boston, USA, ACM Press, PEREIRA, E. BASTOS, R, OLIVEIRA, T. A Systematic Approach to Process Tailoring. Systems Engineering and Modeling, ICSEM '07. Israel. Março, REIS, C.. Caracterização de um Processo de Software para Projetos de Software Livre.. Dissertação (Mestrado) ICMC, Universidade São Paulo, São Carlos, Disponível em: Acesso em abril RUP IBM Rational Unified Process. Rational Unified Process. Disponível em: Acesso em julho RUY, F. BERTOLLO, G., FALBO, R. Apoio Baseado em Conhecimento à Integração de Processo em ODE. JIISIC,

82 Avaliação da Qualidade de Software Através de Técnicas da Mineração de Dados Simone Vasconcelos Silva Coordenação de Informática Centro Federal de Educação Tecnológica de Campos (CEFETCampos) Campos RJ Brasil Abstract: This work approaches the evaluation of the quality of software based on the satisfaction of the users through the use of the data mining. The improvement of the quality of software is proposal in accordance with the extracted useful knowledge of diverse bases through the data mining. The present work uses the concepts of the two boarded areas, quality of software and data mining, besides considering a methodology of evaluation of the quality of software products, being this validated through a case study. Resumo: Este trabalho aborda a avaliação da qualidade de software baseada na satisfação dos usuários através da utilização da mineração de dados. A melhoria da qualidade do software é proposta de acordo com os conhecimentos úteis extraídos de diversas bases através da mineração de dados. O presente trabalho utiliza os conceitos das duas áreas abordadas, qualidade de software e mineração de dados, além de propor uma metodologia de avaliação da qualidade de produtos de software, sendo esta validada através de um estudo de caso. 1. Introdução Atualmente a avaliação da qualidade de produtos ou serviços tornou-se uma necessidade, visto que os usuários estão cada vez mais exigentes quanto à qualidade dos produtos ou serviços adquiridos. E na visão do usuário um produto de qualidade é aquele que atende as suas necessidades, que seja fácil de usar e que funcione no seu ambiente organizacional [Silva 2003]. Na indústria de software é crescente a preocupação com metodologias de produção de software que permitam a qualidade dos softwares e a satisfação do usuário. Um dos importantes aspectos da qualidade de software, que tem merecido crescente atenção é a qualidade da interação entre o usuário e os softwares. A qualidade de software pode ser dividida em duas partes: qualidade do processo e qualidade do produto [Pressman 2001]. Neste trabalho será abordada a qualidade do produto. Atualmente a indústria de software, em todo o mundo, vivência um processo de preocupação crescente com metodologias de produção de software que permitam o controle da qualidade dos programas e a satisfação do usuário, dentre outras características [Pressman 2001]. As técnicas de avaliação da qualidade de software podem vir a auxiliar o setor de desenvolvimento de software a alcançar um grau de satisfação maior dos usuários em relação aos produtos desenvolvidos. E assim, aproximar as características de seus produtos de software às demandas dos usuários. 61

83 A informação vem desempenhando um papel fundamental em todos os setores da sociedade. O desenvolvimento e sucesso das organizações baseiam-se na capacidade de coletar, tratar, interpretar e utilizar a informação de forma eficaz. A rápida evolução dos recursos computacionais, ocorrida nos últimos anos permitiu que fossem gerados grandes volumes de dados. O crescimento do volume de dados tem gerado a necessidade de novas técnicas e ferramentas capazes de transformar dados em informações significativas e em conhecimento. Em resposta a essa necessidade, surgiu a Mineração de Dados (Data Mining). Data Mining é uma tecnologia que emergiu da intersecção de três áreas: estatística clássica, inteligência artificial e aprendizado de máquina. Data Mining é parte de um processo chamado KDD (Knowledge Discovery in Databases), ou seja, Descoberta de Conhecimento em Bases de Dados, que, permite a extração de conhecimento previamente desconhecido e potencialmente útil de um banco de dados [Pampa 2003]. Este trabalho é uma aplicação das técnicas e ferramentas de extração inteligente de conhecimento em bases de dados na avaliação de qualidade de produtos de software. 2. Qualidade de Software Qualidade de software (QS) é a conformidade do produto com os requisitos funcionais e de desempenho explicitamente declarados, a padrões de desenvolvimento claramente documentados e a características implícitas que são esperadas de todo software profissionalmente desenvolvido [Pressman 2001]. A avaliação da qualidade de software pode ser realizada em dois momentos: durante a geração do software e após este estar pronto para o uso, chamando esses dois momentos, respectivamente, de processo e produto [Rocha et. al. 2001]. No primeiro momento procura-se avaliar de que forma o software está sendo desenvolvido, identificando práticas que possam conduzir a problemas na qualidade do produto e desenvolvendo e/ou utilizando métodos e ferramentas que evitem esses problemas. No segundo momento, como produto concluído, procura-se avaliar a sua qualidade a fim de identificar deficiências e limitações em sua aplicabilidade como um produto final. A norma internacional ISO/IEC define qualidade de software como A totalidade de características de um produto de software que lhe confere a capacidade de satisfazer necessidades explícitas e implícitas [ISO/IEC ]. Necessidades explícitas são as condições e objetivos propostos por aqueles que produzem o software. A qualidade em uso é a satisfação das necessidades em um contexto específico. Muitas vezes a qualidade em uso vai de encontro às necessidades implícitas e devem permitir aos usuários atingir metas com efetividade, produtividade, segurança e satisfação em um contexto de uso especificado Norma de Qualidade do Produto de Software A norma ISO (International Organization for Standardization) / IEC (International Electrotechnical Commission) Tecnologia da Informação Características da Qualidade de Software e Métricas, propõe um enquadramento no qual é definido um conjunto de características que permitem avaliar a qualidade de um produto de software. 62

84 Essa norma é dividida em 4 partes: ISO/IEC : Modelo de qualidade, ISO/IEC : Métricas externas, ISO/IEC : Métricas internas e ISO/IEC : Métricas de qualidade em uso. A ISO/IEC permite a avaliação da qualidade do produto final desenvolvido através de um conjunto de características e sub-características que devem ser verificadas, e certificam o produto de software quanto à sua qualidade. A norma apresenta um conjunto de seis características que devem estar presentes em um produto de software de qualidade, conforme mostra a tabela abaixo. Tabela 1. Definição das características e sub-características Característica Conceito Sub-característica Funcionalidade Funções que satisfazem as Adequação, Acurácia necessidades explícitas e Conformidade, Segurança de implícitas. acesso e Interoperabilidade. Confiabilidade Capacidade do software Maturidade, Tolerância à falhas, de manter o nível de Recuperabilidade, e desempenho sob Conformidade. Usabilidade Eficiência determinadas condições. Esforço necessário para se utilizar o software, bem como o julgamento individual desse uso, por um conjunto de usuários. Relacionamento entre o nível de desempenho do software e a quantidade de recursos usados. Manutenibilidade Capacidade do software de ser transferido de um ambiente para outro. Portabilidade Esforço necessário para fazer modificações especificadas no software. 63 Operacionalidade, Atratividade Apreensibilidade,Conformidade e Inteligibilidade. Comportamento em relação ao tempo e em relação aos recursos, e Conformidade. Testabilidade, Estabilidade, Conformidade, Analisabilidade e Modificabilidade. Adaptabilidade, Capacidade para ser instalado, Coexistência, Capacidade para substituir e Conformidade. A norma estabelece que cada característica seja dividida em sub-características, conforme a tabela acima, e que as sub-características sejam divididas em atributos ou critérios, os quais são definidos pela equipe de avaliação. 3. Mineração de Dados A mineração de dados é a análise inteligente e automática de dados para descobrir padrões ou regularidades em grandes conjuntos de dados, através de técnicas que envolvem métodos matemáticos, algoritmos baseados em conceitos biológicos, lingüísticos e heurísticos [Coutinho 2003]. Pode-se dizer que Data Mining (ou mineração de dados) é o processo de extrair informação válida, previamente desconhecida e de máxima abrangência a partir de grandes bases de dados, usando-as para efetuar decisões cruciais [Fayyad e Uthurusamy

85 2002]. Data Mining (DM) vai além da simples consulta a um banco de dados, no sentido de que permite aos usuários explorar e inferir informação útil a partir dos dados, descobrindo relacionamentos escondidos no banco de dados. Pode ser considerada uma forma de descobrimento de conhecimento em bancos de dados (KDD - Knowledge Discovery in Databases), área de pesquisa de bastante evidência no momento, envolvendo Inteligência Artificial e Banco de Dados. O Data Mining descende fundamentalmente de três linhagens: estatística clássica, inteligência artificial (IA) e o aprendizado de máquina (casamento entre a estatística e a IA) [Pampa 2003]. Essas técnicas são usadas juntas para estudar os dados e achar tendências e padrões nos mesmos. Hoje, o DM tem experimentado uma crescente aceitação nas ciências e nos negócios que precisam analisar grandes volumes de dados e achar tendências que eles não poderiam achar de outra forma Descoberta de Conhecimento em Banco de Dados (Knowledge Discovery in Database - KDD) É o processo que envolve a automação da identificação e do reconhecimento de padrões em um banco de dados. KDD é a extração da informação interessante ou padrões dos dados em bases de dados grandes [Fayyad et. al 1996]. KDD é a tecnologia através da qual se pode extrair informação valida, previamente desconhecida e de máxima abrangência a partir de quantidades grandes de dados armazenados em bases de dados. Figura 1. Etapas do KDD [Pampa 2003] 64

86 De acordo com Pampa (2003), as etapas do KDD são: Seleção: nesta etapa destaca-se o conhecimento prévio dos objetivos de um usuário final e o conhecimento do domínio, e nesta etapa é preciso compreensão do domínio, conhecimento dos dados relevantes, definição do problema em termos de domínio, definição de objetivos da aplicação e metas especificas, e definição do modelo da solução desejada. Pré-Processamento: atividades que visam gerar um grupo de dados representativos convenientemente organizados e estruturados para ser minerados pelo algoritmo selecionado, e esta etapa é composta por integração de dados (múltiplas fontes de dados heterogêneos podem ser integradas em um único BD), seleção de dado (identifica um subconjunto de atributos onde será minerado, facilitando o trabalho dos algoritmos de mineração), e limpeza de dados (estratégia adequada de manipulação de dados ruidosos, errôneos, perdidos ou irrelevantes). Transformação de dados: os dados são transformados ou consolidados em formatos apropriados para minerar, e consiste em discretizar dados (os valores contínuos dos atributos são divididos numa lista de intervalos, convertendo valores contínuos em valores discretos), com isso obtém uma melhora da compreensão do conhecimento, redução do tempo de processamento, diminuição do espaço de busca, facilitação do algoritmo de tomada de decisões, agregação de dados (agrega dados existentes nas informações de modo que essas agregações contribuam no processo de descoberta de conhecimento), derivação de dados (adicionam-se novos dados derivados por uma operação ou por séries de operações de dados existentes na tabela de dados), e redução de dados (reduz-se o número de variáveis a considerar). Processamento: os dados são analisados por um algoritmo e transformados em informações (resultados, padrões) úteis que serão avaliados no processo seguinte e consiste em escolha da função de mineração de dados, seleção de algoritmo de mineração de dados, e Data Mining (análise dos dados armazenados através de um programa computacional capaz de analisar os dados e encontrar padrões de interesse). Pós-Processamento: são feitas a avaliação e interpretação dos padrões, para serem representados em forma de conhecimento compreensível e confiável ao usuário, e para serem incorporadas ao conhecimento anterior e consiste em interpretação e avaliação dos resultados (identifica os padrões interessantes que representam o conhecimento baseado em algumas medidas de interesse), apresentação e incorporação de conhecimento (são usadas técnicas de representação e visualização para apresentar o conhecimento de forma compreensível ao usuário) Tarefas do KDD Dependendo dos objetivos da aplicação, a mineração de dados pode realizar múltiplas tarefas. Cada tarefa tem como base um conjunto de algoritmos que são utilizados na extração de relações relevantes em um, ou vários conjuntos de dados [Pampa e Aguayo 2003]. Este trabalho apresentará algumas tarefas, tais como: Associação: Visa determinar relacionamentos entre conjuntos de itens ou regras de associação, identifica afinidades entre itens de um subconjunto de dados. Essas 65

87 afinidades são expressas na forma de regras. A porcentagem de ocorrência representa o fator de confiança da regra, e costuma ser usado para eliminar tendências fracas, mantendo apenas as regras mais fortes. Regras de Associação representam um padrão de relacionamento entre itens de dados do domínio da aplicação que ocorre com uma determinada freqüência na base. A associação utiliza técnicas como algoritmos de extração de regras de associação. Classificação: É uma função que consiste na aplicação de um conjunto de exemplos pré-classificados para desenvolver um modelo capaz de classificar uma população maior de registros. É uma função de previsão que pode ser usada para encontrar um modelo que classifique um item de dado entre várias classes previamente definidas. Os algoritmos de classificação incluem árvores de decisão, estatística, redes neurais, algoritmos genéticos, etc. [Aurélio et. al. 1999]. A classificação identifica, entre um conjunto pré-definido de classes, aquela a qual pertence um elemento, a partir de seus atributos. Agregação e segmentação (Clustering): É a função descritiva cujo objetivo é identificar um conjunto de categorias finitas ou agrupamentos naturais. Estas categorias podem ser mutuamente exclusivas ou podem consistir em uma representação hierárquica. A proposta de segmentação é basicamente endereçada a problemas de agrupação, na qual se faz um corte de um grande número de atributos em um pequeno conjunto de grupos ou de segmentos relativos. A segmentação é realizada automaticamente por algoritmos que identificam características em comum e particionam o espaço n-dimensional definido pelos atributos. Análise de Clusters é o resultado da identificação de um conjunto finito de categorias (ou grupos - clusters) que contêm objetos similares. A clusterização utiliza técnicas como algoritmos de clusterização e redes neurais. 4. Metodologia para Avaliação da Qualidade do Software Através da Mineração de Dados Com base tanto na literatura quanto em experiências práticas, propõe-se uma metodologia na qual a qualidade do produto de software será avaliada de acordo com o grau de satisfação dos usuários, ou seja, de acordo com a qualidade da interação entre os usuários e os produtos de software. E para extrair conhecimento desta avaliação será utilizada a Mineração de Dados. O objetivo da metodologia é definir quais critérios precisam ser melhorados para garantir a qualidade do software e quais grupos de usuários possuem maior ou menor dificuldade para possível correção direcionada as reais necessidades. A metodologia é baseada em três etapas, tais como, seleção dos critérios que serão avaliados no software; seleção da técnica de avaliação que será utilizada; e tratamento das etapas do KDD Critérios e Técnica de Avaliação Utilizados no Software Seleciona-se as características e sub-características presentes na ISO que sejam facilmente percebidas pelos usuários comuns. 66

88 Estas características e suas sub-características selecionadas da norma, assim como os critérios atribuídos a cada característica utilizada para avaliação encontram-se na tabela abaixo. Tabela 2. Características, sub-características e critérios para avaliação do software Características Sub-características Critérios Funcionalidade Acurácia e Segurança de acesso Precisão, Validação dos Dados e Segurança Confiabilidade Tolerância à falhas e Recuperabilidade Recuperação de Dados e Resistência aos Erros. Usabilidade Operacionalidade, Atratividade, Apreensibilidade e Inteligibilidade Help, Navegação, Documentação, Glossário, Aproveitamento de Dados, Mensagens e Padronização Eficiência Comportamento em relação ao tempo Tempo de Processamento A técnica de avaliação de satisfação do usuário que será utilizada é a pesquisa de opinião através de questionários, por apresentar baixo custo, rapidez de aplicação e dispensar a participação de especialistas. Os dados coletados através do questionário serão armazenados em um banco de dados. O questionário é composto das seguintes informações: Em relação ao usuário: nome, matrícula, setor, cargo e tempo de experiência com o software (em anos); Em relação aos critérios do software (conforme Tabela 2): cada critério poderá ser classificado pelo usuário como Muito Bom (MB), Bom (B), Médio (M), Ruim (R), Péssimo (P) ou Inexistente (I); Em relação a satisfação do usuário com o uso do software: o usuário poderá classificar o nível de satisfação como alto, médio ou baixo Etapas do KDD Seleção: domínio utilizado para geração de conhecimento, e serão utilizados os dados coletados através do questionário. Pré-Processamento: serão eliminados os campos referentes às informações dos usuários, como nome e matrícula, pois não influenciaram no conhecimento da qualidade do software utilizado. Eliminação dos registros que possuem campos com resposta nula, pois contribuem negativamente para a obtenção de resultados úteis. Transformação: O campo tempo de experiência que é medido em anos, deverá ser transformado em valor nominal obedecendo aos níveis (novato, médio, experiente). Para isso será necessário obter o intervalo entre o tempo mínimo e máximo da amostra e dividi-lo em três faixas. Na maioria dos casos a base de dados também sofre transformação no seu formato, de acordo com o software de mineração que será utilizado. Mineração de dados: para uma análise mais precisa e abrangente, propõe-se a utilização de três tarefas de mineração (classificação, clusterização e associação) com o objetivo de obter algum conhecimento útil, pois nem sempre uma única tarefa é capaz 67

89 de retirar de uma base os conhecimentos que se deseja ou necessita. A tabela abaixo define as tarefas, técnicas e algoritmos propostos para utilização. Tabela 3. Tarefas, técnicas e algoritmos propostos Tarefas Técnicas Algoritmos Classificação Árvores de Decisão J48 Associação Algoritmos de Regras de APRIORI Associação Clusterização Algoritmos de Clusterização SimpleKmeans Os algoritmos propostos são baseados em suas inúmeras utilizações em casos práticos e citações na literatura. A ferramenta utilizada poderá ser única, caso ofereça todos os algoritmos citados acima, ou um conjunto de ferramentas diversas de modo que todos os algoritmos citados acima sejam executados. Pós-Processamento: análise e interpretação dos resultados, abordando apenas aqueles que sejam de interesse para avaliação da qualidade. Para a tarefa da classificação espera-se identificar o nível de satisfação do usuário por tempo de experiência no software, o nível de satisfação do usuário por cargo e o nível de satisfação do usuário por setor. Para a tarefa da associação espera-se identificar regras que relacionem os critérios ao nível de satisfação do usuário, o tempo de experiência no software ao nível de satisfação do usuário, setor o nível de satisfação do usuário por e setor o nível de satisfação do usuário. Para a tarefa de clusterização espera-se identificar os grupos de critérios mais próximos de modo que possa observar o grupo relacionado a satisfação alta, media ou baixa. Identificar os grupos de critérios mais próximos de modo que possa observar o grupo relacionado a experiência novato, médio, experiente. Identificar os grupos de critérios mais próximos de modo que possa observar o grupo relacionado a cada setor e a cada cargo. 5. Estudo de Caso O estudo de caso foi utilizado apenas como um meio de ilustrar a metodologia apresentada no capítulo anterior. O produto de software avaliado foi o Sistema de Gestão Hospitalar (SGH) utilizado no Hospital Álvaro Alvin, localizado na cidade de Campos - RJ. Participaram da pesquisa 58 usuários do SGH. Os setores do hospital que participaram da pesquisa foram: Laboratório, Ultra, Farmácia, Ambulatório, Secretaria, Núcleo de Processamento de Dados (NPD), SAME (Setor de Atendimento aos Médicos), Compras, Financeiro e Prontuário. A base de dados que contém os dados coletados pelo questionário de avaliação é utilizada desde Etapas do KDD Seleção: a base de dados que contém as informações dos questionários de avaliação. Pré-Processamento: foram eliminados oito registros que possuíam campos com respostas nulas O campo cargo foi eliminado pois os funcionários do hospital são divididos em quatro cargos (médicos, enfermeiros, direção e administrativos) e participaram da pesquisa apenas usuários que pertencem ao cargo administrativo. Transformação: o menor tempo na amostra foi de 1 ano e 2 meses e o maior de 12 anos. Então foi feito um intervalo de 1 a 12 anos, este intervalo dividido em três faixas, 68

90 gerou: 1<= tempo <=4 (Novato), 4< tempo <=8 (Médio), e 8< Tempo <=12 (Experiente). Os dados do arquivo Questionário.mdb (criado em Access) foram exportados para um arquivo texto. Após a limpeza e transformação a base para mineração contém 16 atributos nominais e 50 instâncias. O arquivo texto foi transformado em um arquivo ARFF (Questionário.arff), que será utilizado na mineração de dados, pela necessidade criada pela ferramenta utilizada. Mineração de Dados: utilização da ferramenta WEKA para mineração de dados. A ferramenta WEKA (Waikato Enviroment for Knowledge Analysis) tem sido bastante utilizada na realização da etapa de Data Mining. Desenvolvida na linguagem Java, pela Universidade de Waikato na Nova Zelândia, esta ferramenta é de Domínio Público e trabalha com diversas Técnicas de Data Mining. Ela é composta de dois pacotes que podem ser embutidos em outros programas escritos em Java, permitindo que um desenvolvedor possa criar seu próprio Data Mining Explorer. A escolha da ferramenta se justifica por ela apresentar as seguintes características: software livre, facilidade de download, facilidade de instalação, usabilidade e quantidade de algoritmos. A ferramenta WEKA e a sua documentação encontram-se no site Setor TempoExp {Novato, Médio, Help Mensagem Navegação Padronização Precisão Validação RecuperarDds Segurança TempoProcess Documentação Glossário Satisfação Farm,Médio,MB,B,B,B,B,M,M,R,R,MB,B,I,I,Média Amb,Novato,B,MB,B,MB,B,M,M,R,P,MB,B,I,I,Média... Figura 2. Arquivo questionário.arff Pós-Processamento: Análise e interpretação dos resultados. Resultado e Análise 1: Tarefa Técnica Algoritmo Clusterização Algoritmo de Clusterização SimpleKmeans Com K=3 - Atributos ignorados: setor e tempo de experiência: A Satisfação é considerada Baixa quando sete critérios (Help, Mensagem, Navegação, Padronização, Precisão, Segurança e Tempo de Processamento) são considerados Bons, dois critérios (Validação dos Dados e Aproveitamento de Dados) são considerados Médios, um critério (Recuperação de Dados) é considerado Ruim e um critério (Resistência aos Erros) é considerado Péssimo. A Satisfação é considerada 69

91 Média quando dois critérios (Help e Segurança) são considerados Muito Bons, cinco critérios (Mensagem, Navegação, Padronização, Precisão e Tempo de Processamento) são considerados Bons, dois critérios (Validação dos Dados e Aproveitamento de Dados) são considerados Médios e dois critérios (Recuperação de Dados e Resistência aos Erros) são considerados Ruins. A Satisfação é considerada Alta quando quatro critérios (Help, Mensagem, Precisão e Segurança) são considerados Muito Bons, três critérios (Navegação, Padronização e Tempo de Processamento) são considerados Bons, um critério (Validação dos Dados) é considerado Médio, dois critérios (Aproveitamento de Dados e Recuperação de Dados) são considerados Ruins e um critério (Resistência aos Erros) é considerado Péssimo. Pode-se verificar que os critérios Documentação e Glossário foram considerados inexistentes em todas as instâncias, e que a maioria dos usuários classificou o nível de satisfação como Médio (50%). Com K=3 - Atributo Ignorado - Setor: Alta Média Novato Médio Experiente Figura 3. Nível de satisfação dos usuários em relação ao tempo de experiência O nível de satisfação dos usuários em relação ao tempo de experiência dos mesmos, sofre declínio do Novato para o Experiente, devido a este conhecer mais detalhes do software e das tarefas, o que o torna mais exigente quanto a sua utilização, conforme a figura acima. Com K=11 - Atributo Ignorado - Tempo de Experiência: Verificou-se que não foram encontrados clusters que tivessem um significado relevante para a análise. Com o objetivo de prover algum tipo de informação útil, foi selecionado o critério setor e a partir daí repetido o algoritmo de clusterização. Com isso obteve-se resultados significativos, mas descaracterizou-se a tarefa de clusterização, a qual passou a ser apenas uma consulta. O resultado dos clusters apresentado abaixo segue os seguintes critérios respectivamente: Help, Mensagem, Navegação, Padronização, Precisão, Validação, AproveitarDds, RecuperarDds, ResistirErros, Segurança, TempoProcess, Documentação, Glossário e Satisfação. Cluster 0 Farmácia (12%): MB B B MB B M M R P MB B I I Média Cluster 1 Prontuário (6%): MB B B B MB M M R R B MB I I Média Cluster 2 Financeiro (12%): MB MB B B MB M R R P MB B I I Alta Cluster 3 SAME (6%): MB B MB B B M R R R B B I I Alta Cluster 4 Compras (12%): MB B B B B M M R R MB B I I Média Cluster 5 NPD (8%): B B MB B B M R R R B B I I Média Cluster 6 Ambulatório (8%): B MB B MB B M M R P MB B I I Média Cluster 7 Faturamento (6%): MB B B B B M R R R B B I I Média Cluster 8 Ultra (4%): MB MB B B MB M R R P MB B I I Média Cluster 9 Secretaria (10%): MB B B MB B M M R P MB B I I Alta Cluster 10 Laboratório (16%): B B B B B P M R P B B I I Baixa Figura 4. Resultado dos clusters 70

92 Pode-se verificar que a qualidade dos critérios variou de acordo com o setor de utilização do software. O nível de satisfação dos usuários, em utilizar o software, também variou de acordo com o setor. Pode-se verificar também a necessidade de melhoria no software, relacionada com as dificuldades apresentadas por cada setor. A maioria dos setores classificou o nível de satisfação como Médio em relação ao uso do software, conforme figura abaixo. Alta Média Baixa Farmácia Prontuário Financeiro SAME Compras NPD Ambulatório Faturamento Ultra Secretaria Laboratório Figura 5. Qualidade dos critérios de acordo com o setor de utilização do software Resultado e Análise 2: Tarefa Técnica Algoritmo Associação Algoritmo de Associação Apriori As regras mais importantes foram: Satisfação=Alta ==> Help=MB TempoExp=Experiente ==> Satisfação=Baixa Satisfação=Alta ==> TempoExp=Novato Analisando os resultados acima: conf:(1) conf:(0.78) conf:(0.77) 100% dos usuários que classificaram o nível de satisfação na utilização do software como Alto, consideram o Help do software Muito Bom. 78% dos usuários considerados Experientes classificaram o nível de satisfação na utilização do software como Baixo. 77% dos usuários que classificaram o nível de satisfação na utilização do software como Alto, são considerados usuários Novatos. O help teve uma influência positiva na satisfação dos usuários. E o nível de satisfação dos usuários em relação ao tempo de experiência sofre declínio do Novato (Alto) para o Experiente (Baixo), devido a este conhecer mais detalhes do software e das tarefas, o que o torna mais exigente quanto a sua utilização. 71

93 Resultado e Análise 3: Tarefa Técnica Algoritmo Classificação Árvore de Decisão J48 Critérios: Tempo de Experiência e Satisfação: Assim como na Clusterização e na Associação, através da figura abaixo, verifica-se que o nível de satisfação decresce do Novato para o Experiente também na Classificação. Figura 6. Árvore de decisão (tempo de experiência x satisfação) Critérios: Setor e Satisfação: Assim como na Clusterização, verifica-se que o nível de satisfação dos usuários varia de acordo com o setor também na Classificação. Sendo que na árvore de decisão houve um empate entre os usuários que consideraram o nível de satisfação com o software Médio e Alto, conforme figura abaixo. Figura 7. Árvore de decisão (setor x satisfação) Resumo das análises: Com as experiências adquiridas pelo processo de descoberta de conhecimento é possível diagnosticar os critérios do software que precisam ser melhorados, verificar as tarefas do software referentes a quais setores precisam de melhoria na interação com o usuário e propor resultados estratégicos para a equipe de desenvolvimento do software, orientando em tomadas de decisões que poderão garantir uma maior qualidade do software e satisfação de seus usuários. 72

94 6. Considerações Finais As informações obtidas após a mineração dos dados servirão para subsidiar as tomadas de decisões e para aperfeiçoar os softwares avaliados, bem como para determinar a satisfação dos usuários, descobrindo falhas e identificando pontos onde os softwares necessitariam de melhorias. O tratamento das informações coletadas deve conduzir a uma clara interpretação das reais necessidades de melhoria no software visando aumentar sua qualidade. A mineração de dados utilizada na avaliação da qualidade de software deverá identificar padrões e tomar decisões para garantia da qualidade do software, visando sua permanência no mercado. Neste trabalho foi possível verificar que a utilização da mineração de dados na avaliação da qualidade de software é bastante eficaz, gerando conhecimento útil para: Diagnosticar a qualidade de diferentes produtos de software de acordo com as características de qualidade; Identificar a satisfação dos usuários em relação ao software; Identificar a necessidade de melhorias no software para garantia da qualidade, selecionado os critérios que precisam de alterações. Referências Aurélio, M.; Vellasco, M.; Henrique L.C. (1999) Descoberta de Conhecimento e Mineração de Dados. Notas de aula, Engenharia Elétrica, PUC-RIO. Rio de Janeiro. Coutinho, F. (2003) Data Mining. Disponível em Fayyad, U. M.; Uthurusamy, R. (2002) Evolving Data Mining into Solutions for Insights, Comminications of the ACM: vol.45, Nº 8, p Fayyad, U. M.; Piatestky-Shapiro, G.; Smith P.; Uthurusamy, R. (1996) Advances in Knowledge Discovery and Data Mining. AAIPress, The Mit Press. ISO/IEC (1999) Information Technology, Software Product Quality, part 1: quality model. Pampa N. R. (2003) Técnicas e Ferramentas automáticas e inteligentes para a extração de conhecimento em bases de dados. Dissertação de tese de mestrado. DSIF, FEEC, UNICAMP. Pampa N. R.; Aguayo M. T. (2003) Aplicação de Data Mining a Dados de Avaliação da Qualidade de Produtos de Software. Ministério da Ciência e Tecnologia. Centro de Pesquisas Renato Archer. São Paulo. Pressman, R. (2001) Software Engineering - A practitioner's Approach. 5ª edição, McGraw-Hill. Rocha, A., Maldonato, J., Weber, K. (2001) Qualidade de Software Teoria e Prática. 1. ed. São Paulo: Prentice Hall. Silva, S. (2003) Qualidade de Software Uma Abordagem Baseada na Satisfação do Usuário. Dissertação (Mestrado em Engenharia de Produção) Campos-RJ, UENF, 172p. 73

95 74

96 Avaliação de Bases de Medidas considerando sua Aplicabilidade ao Controle Estatístico de Processos de Software Monalessa Perini Barcellos 1, 2, Ana Regina Cavalcanti da Rocha 1 1 COPPE/UFRJ - Universidade Federal do Rio de Janeiro Caixa Postal: CEP: Rio de Janeiro, RJ, Brasil 2 UFES - Universidade Federal do Espírito Santo Centro Tecnológico Departamento de Informática, CEP: Vitória, ES, Brasil monalessa@inf.ufes.br; darocha@entroin.com.br Resumo. As exigências cada vez maiores do mercado de software levam as empresas a necessitarem de processos de software maduros, capazes de atender às demandas de qualidade e produtividade. A aplicação do controle estatístico na análise de desempenho de processos utiliza dados coletados ao longo dos projetos para analisar o comportamento dos processos da organização, identificando as ações necessárias para a estabilização e melhoria desses processos. Um elemento essencial para a aplicação do controle estatístico de processos é a adequação das medidas utilizadas. Este artigo apresenta um instrumento para avaliação de bases de medidas considerando sua aplicabilidade ao controle estatístico de processos. Abstract. The escalating demands on the development of software products require software organizations to produce mature software processes that are capable of providing the required levels of quality and productivity. The use of statistical process control in performance process analysis use data collected during the course of the project to analyze the behavior of organization processes, identifying actions that are needed for the stabilization and improvement of those processes. An essential element for the statistical process control application is the suitability of the metrics being used. This article presents an instrument to the evaluation of statistical metrics schemes, considering their applicability in the statistical process control. 1. Introdução As organizações buscam melhorar suas práticas de desenvolvimento e gerenciamento de projetos de software, a fim de aumentar sua competitividade no mercado. Nesse contexto, a gerência dos processos de software tem sido fator amplamente reconhecido para a melhoria dos processos e produtos das organizações de software [Fuggetta 2000]. Considerando a avaliação e melhoria de processos, exemplos notáveis de modelos e normas de apoio são o MPS.BR - Melhoria de Processo de Software Brasileiro (2007), o CMMI - Capability Maturity Model Integration (2006) e a norma internacional ISO/IEC Avaliação de Processos de Software (2003). Em todas essas iniciativas, a medição ocupa papel fundamental no alcance e institucionalização dos programas de melhoria de processos de software. A medição de software é considerada essencial no apoio à gerência e melhoria de processos e produtos de software [ISO/IEC FDIS E 2002]. Porém, a gerência 75

97 e melhoria de processos baseada na medição tradicional, que consiste na análise de medidas e a comparação destas, em um determinado ponto dos projetos, com os valores que foram planejados para aquele momento, não é suficiente para as organizações que buscam alta maturidade em seus processos. Nessas organizações, faz-se necessário conhecer o comportamento dos processos para determinar o seu desempenho em execuções anteriores e, a partir daí, prever o desempenho nos projetos correntes e futuros para analisar se serão capazes de atender os objetivos estabelecidos [Fenton et al. 2004]. A análise de desempenho de processos é realizada a partir da aplicação de métodos estatísticos aos dados coletados nos projetos, que alimentam o repositório organizacional de medidas para que seja realizada sua análise, sendo possível, a partir daí, identificar tendências e ações, não só no nível dos projetos, mas também no nível organizacional. A identificação de tendências e outros aspectos relativos ao desempenho e capacidade dos processos tornam-se a base concreta para a tomada de decisões que resultarão na melhoria dos processos. A utilização do controle estatístico na análise de desempenho de processos requer que as organizações tenham alcançado um considerável nível de maturidade em seus processos de software, devendo possuir um conjunto de processos padrão definido e implementado e utilizar práticas de Engenharia de Software em seus projetos, incluindo a definição e coleta de medidas ao longo dos projetos e armazenamento destas em uma base organizacional de medidas [Sargut and Demirors 2006]. A análise de desempenho dos processos somente pode ser realizada se a organização possuir uma base com medidas válidas. Wang and Li (2005) argumentam que é muito difícil para as organizações definirem e coletarem medidas adequadamente, o que faz que as práticas necessárias às organizações de alta maturidade não sejam possíveis para a maioria das organizações de software. Para que medidas adequadas à realização da análise de desempenho dos processos sejam definidas e coletadas, um programa de medição bem planejado e cuidadosamente focado deve ser definido [Kilpi 2001]. Porém, essa ainda é uma questão que requer atenção, pois vários estudos têm mostrado que as organizações, comumente, definem programas de medição precários, que não produzem medidas que permitam a análise do desempenho e capacidade de seus processos [Wang and Li 2005] [Kitchenham et al. 2006] [Sargut and Demirors 2006] [Komuro 2006]. No contexto dos problemas relacionados às medidas, que dificultam a realização do controle estatístico de processos, este artigo apresenta um instrumento para avaliar bases de medidas considerando sua aplicabilidade ao controle estatístico dos processos. O artigo encontra-se assim organizado: na seção 2 é realizada uma breve fundamentação teórica sobre o controle estatístico de processos, destacando-se questões relacionadas à medição nesse contexto; na seção 3 é apresentado o instrumento de avaliação definido; na seção 4 são apresentados os resultados de aplicação do instrumento às bases de medidas de duas organizações; e, na seção 5, são realizadas as conclusões do artigo. 2. Controle Estatístico de Processos O controle estatístico de processos foi originalmente desenvolvido para implementar um processo de melhoria contínua em linhas de produção na área de manufatura, envolvendo o uso de técnicas estatísticas e de resolução de problemas com o objetivo de detectar padrões de variação no processo de produção para garantir que os padrões de 76

98 qualidade estabelecidos para os produtos fossem alcançados. É uma metodologia utilizada para determinar se um processo está sob controle, sob o ponto de vista estatístico [Lantzy 1992]. Apesar de sua utilização na análise de desempenho e melhoria de processos não ser novidade para a indústria em geral, no contexto das organizações de software, pode ser considerado algo relativamente recente. Consequentemente existem, ainda, muitas dúvidas sobre sua aplicação [Card, 2004] [Komuro 2006] [Garcia et al. 2007]. Mesmo sendo considerada recente, é possível encontrar relatos de experiência e estudos no contexto da aplicação do controle estatístico a processos de software [Kilpi 2001] [Garcia et al. 2004] [Komuro 2006] [Sargut and Demirors 2006] [Tarhan and Demirors 2006] [Wang et al. 2006]. Analisando-se os relatos e estudos registrados na literatura, é possível perceber que há um gap entre os cenários organizacionais reais e os cenários desejáveis, propícios à implantação e realização efetiva do controle estatístico de processos. As experiências com a realização do controle estatístico de processos nas organizações têm revelado aos pesquisadores e profissionais de empresas um cenário caracterizado por problemas e situações não favoráveis ou impossibilitadoras da implantação/execução bem sucedida do controle estatístico de processos. Nesse aspecto, são apontadas diversas dificuldades, destacando-se: (i) a não adequação das medidas coletadas pelas organizações à aplicação no controle estatístico de processos para que seja possível analisar o desempenho dos processos [Wheeler and Poling 1998] [Sargut e Demirors 2006] [Tarhan and Demirors 2006] [Boria, 2007] [Kitchenham et al. 2007]; (ii) a utilização inadequada dos métodos estatísticos necessários à estabilização e análise de desempenho de processos [Eickelman and Anant 2003] [Kitchenham et al. 2007]; e, (iii) as particularidades inerentes aos processos de software, o que exige uma adaptação dos conceitos do controle estatístico de processos tradicional (manufatura) à área de software [Lantzy 1992] [Sargut and Demirors 2006] [Komuro 2006] [Wang et al. 2006]. Considerando os problemas citados e focando as questões relacionadas à não adequação das medidas, Sargut and Demirors (2006) afirmam que há mais trabalho para preparar a estrutura necessária para realizar o controle estatístico de processos do que para realizar o controle estatístico propriamente dito, já que, na maioria das vezes, as organizações não alimentam suas bases de medidas com medidas válidas e aplicáveis ao controle estatístico de processos, o que retarda sua realização, uma vez que, primeiramente, deve ser realizada a adequação das medidas para, só então, aplicar as técnicas do controle estatístico de processos. Uma organização pode minimizar o esforço e tempo despendidos na preparação para o controle estatístico de processos utilizando, desde o início, um programa de medição bem definido que oriente a alimentação da base de medidas organizacional com medidas aplicáveis ao controle estatístico de processos. Porém, considerando os estudos e experiências registrados, esse não tem sido um fato comum. Boria (2007), analisando organizações que buscam alcançar os níveis de maturidade mais elevados do CMMI (2006), onde, a partir do nível 4, faz-se necessário o controle estatístico de processos para a análise de desempenho, afirma que aquelas que, durante a realização das atividades requeridas ao nível 3, simplesmente se preocupam em atender os requisitos das áreas de processo, acabam criando uma base de medidas inúteis ao pensamento estatístico exigido no nível 4. Segundo ele, dois dos principais obstáculos para a realização do controle estatístico de processos são: o 77

99 acúmulo de dados incorretos, capturados em medidas inúteis definidas sem visar utilização futura, e a escassez de dados. Wang et al. (2006) também consideram o problema da escassez de dados e Komuro (2006) destaca que mesmo quando há volume de dados, muitas vezes eles são inúteis, resultantes de medições em organizações que dão maior ênfase ao volume de dados coletados do que à qualidade desses dados. Wheeler and Poling (1998) enfatizam a importância da qualidade dos dados armazenados na base de medidas da organização, pois, no controle estatístico de processos, todas as ações de melhoria são baseadas nas análises dos gráficos de comportamento dos processos, gerados a partir dos dados armazenados na base de medidas. Segundo eles, para aplicar o controle estatístico de processos é preciso construir uma fundação, ou seja, os processos devem ser caracterizados por medidas válidas e dados de qualidade que serão utilizados para analisar a previsibilidade dos processos. 3. Avaliação de Bases de Medidas considerando sua Aplicabilidade ao Controle Estatístico de Processos Conforme apresentado na seção anterior, a literatura aponta que um dos maiores problemas para realizar o controle estatístico de processos de software se deve às dificuldades relacionadas às medidas coletadas e à base de medidas das organizações [Kitchenham et al. 2006] [Komuro 2006] [Boria 2007]. Considerando esse contexto, foi realizado um estudo baseado em revisão sistemática da literatura 1 com o objetivo de identificar os principais fatores relacionados ao processo de medição e às medidas que influenciam, positiva ou negativamente, na implementação do controle estatístico de processos e, a partir desses fatores, identificar um conjunto de requisitos necessários às medidas/base de medidas considerando sua utilização no controle estatístico de processos 2. Baseando-se nos resultados do estudo, um instrumento para avaliação de bases de medidas considerando sua aplicabilidade no controle estatístico de processos foi definido. O estudo realizado e o instrumento definido são apresentados a seguir. 3.1 Estudo Baseado em Revisão Sistemática da Literatura A aplicação da revisão sistemática da literatura estabelece um processo formal e controlado para conduzir revisões de literatura, evitando a introdução de tendências que podem desvirtuar os resultados da pesquisa. A aplicação da revisão sistemática da literatura requer que seja seguido um conjunto bem definido e seqüencial de passos metodológicos segundo um protocolo de pesquisa desenvolvido apropriadamente [Biolchini et al. 2005]. Para a realização do estudo deste trabalho foi utilizado o processo de apoio à condução de estudos baseados em revisão sistemática definido em [Montoni 2007], que apesar de utilizar os conceitos básicos da revisão sistemática da literatura, não utiliza todo o rigor original proposto, uma vez que o objetivo não é revelar hipóteses, e sim, garantir uma boa cobertura para a pesquisa. O processo utilizado é composto por três atividades: 1 O estudo foi realizado durante os meses de janeiro e fevereiro de No estudo realizado, os fatores que contribuem negativamente para a implementação do controle estatístico de processos foram denominados problemas e os fatores que contribuem positivamente foram denominados características. 78

100 (i) Desenvolver o Protocolo: nesta atividade o pesquisador realiza a prospecção sobre o tema de interesse do estudo definindo o contexto no qual o estudo será realizado e o objeto de análise. Em seguida, o protocolo que será utilizado como guia na execução do estudo deve ser definido, testado para verificar sua viabilidade e avaliado, identificando-se as alterações necessárias (se pertinente). (ii) Conduzir a Pesquisa: nesta atividade o pesquisador executa a pesquisa coletando e armazenando os dados segundo o protocolo definido. Em seguida, análises quantitativas e qualitativas devem ser realizadas com base nos dados coletados. (iii) Relatar Resultados: nesta atividade o pesquisador empacota os resultados gerados ao longo da execução do estudo, devendo estes ser publicados em alguma conferência, revista ou biblioteca de trabalhos científicos. Na atividade Desenvolver o Protocolo, o protocolo de pesquisa foi definido e testado, tendo sido verificada sua viabilidade para a execução integral da pesquisa. Para a realização da pesquisa, foram consideradas publicações de estudos relacionados ao controle estatístico de processos que relatem problemas e/ou características relacionados à medição e/ou medidas que influenciam na realização do controle estatístico de processos, bem como publicações que descrevam estudos ou experiências de aplicação do controle estatístico de processos (nessas, os problemas e/ou características foram identificados durante a análise do conteúdo da publicação). A não limitação a publicações que relatem, explicitamente, os problemas e/ou características relacionados à medição e/ou medidas que influenciam na realização do controle estatístico de processos se deu, pois, apesar do crescente número de publicações relacionadas à aplicação do controle estatístico a processos de software, o foco dessas publicações ainda é limitado a evidenciar a possibilidade e vantagens dessa aplicação ou a propor abordagens utilizadas em processos de software baseadas nos princípios do controle estatístico. Sendo assim, considerar apenas as publicações que relatem explicitamente os problemas e/ou características relacionadas à medição e/ou medidas que influenciam na realização do controle estatístico de processos poderia significar uma redução considerável de publicações analisadas. Na execução da pesquisa foram consideradas como fontes as seguintes bibliotecas digitais: Scopus, Compendex, IEEE e ScienceDirect (considerando Journal of Systems and Software, Journal of System Architecture e Information and Software Technology). Considerando os problemas relacionados ao processo de medição e/ou às medidas que impactam na implementação do controle estatístico de processos mencionados nas publicações, foram registrados 18 achados, listados na tabela 1: Id P1 P2 P3 P4 P5 P6 P7 P8 P9 P10 P11 Tabela 1 Lista de achados do tipo Problemas Problema Agrupamento de dados de projetos não similares. Base de medição mal estruturada. Coleta de uma mesma medida em momentos diferentes da execução dos processos nos projetos. Dados agregados. Dados ambíguos. Dados armazenados em diversas fontes não integradas. Dados de uma mesma medida coletados com granularidades diferentes. Dados perdidos. Definição operacional deficiente das medidas. Insuficiência ou ausência de dados coletados para as medidas definidas. Insuficiência ou ausência de informações de contexto das medidas. 79

101 Id P12 P13 P14 P15 P16 P17 P18 Problema Insuficiência ou ausência de medidas associadas aos processos. Medidas associadas a processos muito longos (mesmo com a granularidade correta, a frequência de coleta é baixa). Medidas de alta granularidade. Medidas isoladas, sem que as medidas associadas, necessárias à análise, sejam coletadas. Medidas não alinhadas aos objetivos de negócio da organização. Medidas normalizadas incorretamente. Utilização de medidas de controle, ao invés de medidas de melhoria. Analisando-se os dados extraídos das publicações selecionadas, percebeu-se que não há uma homogeneidade na identificação dos problemas relacionados ao processo de medição e/ou medidas que impactam na implementação do controle estatístico de processos. Uma outra percepção obtida foi a diferença no nível de detalhamento das publicações ao citarem os problemas. Alguns autores generalizaram os problemas relacionados às medidas em um único problema: medidas inúteis. Outros, por sua vez, não utilizam a expressão medidas inúteis, mas, implicitamente, indicam, através dos problemas por eles relatados, a inutilidade das medidas. Por exemplo, o problema medidas de alta granularidade, em uma análise geral, caracteriza medidas inúteis. Na pesquisa, 19,35% das publicações relataram o problema medidas inúteis, que, apesar de não se encontrar explícito na lista de achados de problemas, é implicitamente representado pelos demais problemas que caracterizam a inutilidade das medidas. Insuficiência ou ausência de informações de contexto das medidas e definição operacional deficiente das medidas foram os problemas mais citados nas publicações, sendo seguidos por medidas isoladas, sem que as medidas associadas, necessárias à análise, sejam coletadas, o que torna possível perceber que os problemas mais citados poderiam ser evitados em uma organização através de um programa de medição bem definido desde seus primeiros momentos. Dados perdidos e insuficiência ou ausência de dados coletados para as medidas definidas também foram destacados, mostrando a necessidade de coleta e armazenamento constante dos dados para que as medidas possam ser utilizadas no controle estatístico de processos. Apesar de alguns itens da lista de achados terem sido citados em um pequeno percentual das publicações, a importância dos mesmos não deve ser subestimada, como, por exemplo, o problema utilização de medidas de controle, ao invés de medidas de melhoria, relevante para organizações que utilizam o controle estatístico de processos como apoio ao alcance de um nível mais elevado de maturidade em modelos como o MPS.BR (2007) e CMMI (2006). Considerando as características relacionadas ao processo de medição e/ou às medidas que contribuem na implementação do controle estatístico de processos mencionadas nas publicações analisadas, foram registrados 21 achados, listados na tabela 2: Tabela 2 Lista de achados do tipo Características. Id C1 C2 C3 C4 Característica Associação de medidas de processo com medidas de produto. Centralização dos dados coletados. Coleta automática das medidas. Coleta consistente das medidas. 80

102 Id C5 C6 C7 C8 C9 C10 C11 C12 C13 C14 C15 C16 C17 C18 C19 C20 C21 Característica Definição dos critérios que devem ser obedecidos para agrupar/comparar medidas coletadas nos projetos da organização. Definição e coleta de medidas de produto e processo. Definição e coleta de medidas orientadas às tomadas de decisão. Definição e coleta, desde o início das atividades de medição, de medidas relacionadas ao desempenho dos processos. Existência de medidas de um processo de apoio quando o processo primário não possuir medidas suficientes. Existência de pelo menos 20 valores para cada medida a ser utilizada no controle estatístico de processos. Identificação dos relacionamentos entre as medidas. Medidas associadas a atividades que produzam itens tangíveis. Medidas associadas aos processos críticos. Medidas coletadas ao longo de todo o processo de desenvolvimento. Medidas coletadas para um fim específico, conhecido pelos envolvidos. Medidas de controle e melhoria de processo. Medidas passíveis de normalização, para possibilitar comparações. Medidas relacionadas às características de qualidade dos produtos. Registro preciso dos dados coletados para as medidas. Identificação de conjuntos de dados homogêneos. Utilização integrada de medidas de processo, projeto e produto. A característica coleta consistente das medidas foi a mais citada pelas publicações, aparecendo em 45,16% delas. Esse alto índice pode ser explicado pela ampla conotação que a característica apresenta (várias (sub)características podem ser consideradas para que se obtenha uma coleta consistente das medidas). Também foi destacada a característica definição dos critérios que devem ser obedecidos para agrupar/comparar medidas coletadas nos projetos da organização. Alguns autores destacaram a importância dessa característica ao afirmarem que, em algumas organizações, apesar de haver volume de dados e medidas suficientes, o agrupamento dos mesmos de forma não adequada fornece informações que baseiam decisões equivocadas. Em outros casos, organizações que não possuem o volume de dados necessários para aplicar as técnicas estatísticas reúnem diversas medidas inadequadamente, para obter o volume de dados necessário. Outra característica reconhecida foi a identificação dos relacionamentos entre as medidas que, no controle estatístico de processos, apóia a interpretação, análise e investigação de situações demonstradas no comportamento dos processos. Após terem sido obtidas a lista de problemas e a lista de características relacionadas ao processo de medição e/ou medidas que impactam na implementação do controle estatístico de processos, foi elaborada uma lista de requisitos necessários às medidas para utilização no controle estatístico de processos. Foram identificados os 20 requisitos listados na tabela 3: Id R1 R2 R3 R4 R5 R6 R7 R8 R9 Tabela 3 Lista de Requisitos identificados. Requisito Alinhamento a objetivo(s) do projeto e da organização. Apoio à melhoria de processo. Associação a atividade(s) que produz(em) item(ns) tangível(is). Associação a processo crítico. Baixa granularidade. Consistência dos dados coletados. Critérios para agrupamento/comparação da medida definidos. Definição operacional correta e satisfatória. Existência das informações de contexto da medida. 81

103 Id R10 R11 R12 R13 R14 R15 R16 R17 R18 R19 R20 Requisito Localização conhecida e acessível dos dados coletados para a medida. Medidas correlatas definidas. Não existência ou irrelevância de dados perdidos. Não utilização de dados agregados. Normalização correta (se normalizada). Possibilidade de normalização (se aplicável). Precisão dos dados coletados. Relação com o desempenho do processo. Relevância para tomada de decisão. Validade das medidas correlatas. Volume suficiente de dados coletados. A tabulação detalhada dos dados da pesquisa, bem como a descrição completa do protocolo de pesquisa, seu teste e a lista de publicações analisadas podem ser encontradas em [Barcellos 2008]. Com base no conjunto de requisitos identificados foi definido um instrumento (checklist) para avaliação das bases de medidas. A figura 1 apresenta esse checklist. Requisitos Avaliação 1. A definição operacional da medida é correta e satisfatória. ( ) atende ( ) não atende ( ) atende parcialmente ( ) NFPA A definição operacional da medida inclui: 1.1 Definição da medida ( ) sim ( ) não ( ) NFPA 1.2 Entidade medida ( ) sim ( ) não ( ) NFPA 1.3 Atributo medido ( ) sim ( ) não ( ) NFPA 1.4 Unidade de medida ( ) sim ( ) não ( ) NFPA 1.5 Tipo de dados (real, inteiro, etc) ( ) sim ( ) não ( ) NFPA 1.6 Intervalo esperado dos dados ( ) sim ( ) não ( ) NFPA 1.7 Fórmula(s) ( ) sim ( ) não ( ) NFPA 1.8 Descrição precisa do procedimento de coleta ( ) sim ( ) não ( ) NFPA 1.9 Descrição precisa do procedimento de análise ( ) sim ( ) não ( ) NFPA 2. A medida está alinhada a objetivo(s) do(s) projeto(s) e da organização. ( ) atende ( ) não atende ( ) atende parcialmente ( ) NFPA A medida está associada a: 2.1 Objetivo do projeto ( ) sim ( ) não ( ) NFPA 2.2 Objetivo da organização ( ) sim ( ) não ( ) NFPA 3. Os resultados da análise da medida são relevantes às tomadas de decisão. ( ) atende ( ) não atende ( ) atende parcialmente ( ) NFPA 4. A medida está relacionada ao desempenho de processo. ( ) atende ( ) não atende ( ) atende parcialmente ( ) NFPA 5. A medida está associada a um processo crítico. ( ) atende ( ) não atende ( ) atende parcialmente ( ) NFPA 6. Os resultados da análise da medida são úteis à melhoria de processo. ( ) atende ( ) não atende 7. A medida está associada a uma atividade que produz item(ns) tangível(is). ( ) atende ( ) não atende 8. As medidas correlatas à medida estão identificadas. ( ) atende ( ) não atende 9. As medidas correlatas à medida são válidas. ( ) atende ( ) não atende 10. A medida possui baixa granularidade. ( ) atende ( ) não atende 11. A medida é passível de normalização (se aplicável). ( ) atende ( ) não atende 12. A medida está normalizada corretamente (se aplicável). ( ) atende ( ) não atende 13. A medida não considera dados agregados. ( ) atende ( ) não atende 14. Os critérios para agrupamento/comparação da medida estão definidos. ( ) atende ( ) não atende 15. As informações de contexto da medida estão armazenadas. ( ) atende ( ) não atende É possível identificar: 15.1 Momento da coleta ( ) atende parcialmente ( ) atende parcialmente ( ) atende parcialmente ( ) atende parcialmente ( ) atende parcialmente ( ) atende parcialmente ( ) atende parcialmente ( ) atende parcialmente ( ) atende parcialmente ( ) atende parcialmente ( ) NFPA ( ) NFPA ( ) NFPA ( ) NFPA ( ) NFPA ( ) NFPA ( ) NFPA ( ) NFPA ( ) NFPA ( ) NFPA ( ) sim ( ) não ( ) NFPA 82

104 Requisitos Avaliação 15.2 Condições da coleta (dados relevantes sobre a execução do processo/projeto no momento da coleta da medida) ( ) sim ( ) não ( ) NFPA 15.3 Executor da coleta ( ) sim ( ) não ( ) NFPA 15.4 Características do projeto no qual a medida foi coletada ( ) sim ( ) não ( ) NFPA 16. Os dados coletados para a medida têm localização conhecida e acessível. ( ) atende ( ) não atende ( ) atende parcialmente ( ) NFPA 17. Há volume suficiente de dados coletados. ( ) atende ( ) não atende ( ) atende parcialmente ( ) NFPA 18. Não há dados perdidos para a medida ou a quantidade de dados perdidos é irrelevante. ( ) atende ( ) não atende 19. Os dados coletados são precisos. ( ) atende ( ) não atende 20. Os dados coletados são consistentes. ( ) atende ( ) não atende Características dos dados coletados: ( ) atende parcialmente ( ) atende parcialmente ( ) atende parcialmente ( ) NFPA ( ) NFPA ( ) NFPA 20.1 Os dados foram coletados no mesmo momento da execução do processo ao longo dos projetos. ( ) sim ( ) não ( ) NFPA 20.2 Os dados foram coletados sob as mesmas condições. ( ) sim ( ) não ( ) NFPA 20.3 Os dados compõem grupos relativamente homogêneos. ( ) sim ( ) não ( ) NFPA NFPA = Não foi possível avaliar Figura 1 Checklist para avaliação de bases de medidas. 4. Experiência de Avaliação de Bases de Medidas Após a elaboração do checklist, este foi utilizado em duas empresas do Rio de Janeiro, como uma primeira avaliação de sua aplicabilidade e utilidade. Inicialmente, o checklist foi aplicado individualmente a cada medida selecionada na base de medidas das organizações. Em seguida, as medidas foram agrupadas para uma análise por processo. Avaliação da Base de Medidas da Organização A (i) Contexto: Os dados presentes na base de medidas da organização A foram coletados ao longo de projetos realizados nessa organização, avaliada CMMI nível 2 e que encontra-se implementando as práticas necessárias ao atendimento dos requisitos do nível 3 do modelo. Antes da avaliação da base de medidas, foram realizadas reuniões que permitiram que os principais processos, práticas e ferramentas da organização fossem conhecidos. (ii) Análise Geral: A organização A possui um plano de medição detalhado, que, recentemente, foi adequado para atender os requisitos do nível 3 do CMMI. As medidas definidas no plano encontram-se alinhadas ao planejamento estratégico organizacional. Os projetos são agrupados de acordo com suas características, permitindo analisar os valores coletados para as medidas entre projetos de um mesmo grupo. A empresa possui um ambiente de apoio à gerência dos projetos que permite que algumas das medidas definidas sejam coletadas automaticamente ou através do próprio ambiente. Outras são registradas manualmente em planilhas. Apesar da organização não possuir um banco de dados com uma estrutura refinada para a base de medidas e das medidas coletadas serem armazenadas em locais distintos (planilhas e banco de dados), a organização realiza a integração dos dados coletados centralizando-os em planilhas de projetos e organizacional, vinculadas entre si. Considerando que a coleta das medidas despende esforço e, consequentemente, tem um custo para a organização, ao definir o plano de medição, a organização A 83

105 incluiu apenas as medidas que considerou indispensáveis. No momento em que o objetivo principal era alcançar o nível 2 do CMMI, foi definido um pequeno grupo de medidas capaz de atender aos requisitos do modelo e, ao mesmo tempo, ser útil à organização, tendo seus resultados aplicáveis em decisões e perceptíveis a todos os envolvidos, o que, naturalmente, motivaria a medição. À medida em que novas necessidades surgiram, novas medidas foram definidas. Quando o objetivo principal passou a ser alcançar o nível 3 do modelo, uma revisão refinada do plano de medição foi realizada para identificar as medidas necessárias às novas práticas da organização. (iii) Análise Detalhada: Para realizar a avaliação foram utilizados dados de medidas coletadas pela organização em 2007, tendo sido consideradas apenas as medidas referentes a processos diretamente relacionados ao desenvolvimento de software. A organização A possui em sua base de medidas um volume considerável de dados que foram coletados em mais de quarenta projetos desde 2003, porém, muitos desses dados não podem ser utilizados no controle estatístico de processos, pois referem-se a definições diferentes de um mesmo processo. Por esse motivo, decidiu-se considerar apenas os dados de projetos realizados em 2007, onde foram utilizadas as mesmas definições para os processos dos projetos. Considerando as medidas referentes a processos relacionados ao desenvolvimento de software coletadas em 2007, neste estudo foram avaliadas 61 medidas. Na base de medidas dessa empresa foram encontradas medidas como: esforço planejado, esforço realizado, esforço consumido, nº de itens planejados, nº de itens realizados, itens com desvio de prazo, nº de requisitos incluídos, nº de requisitos excluídos, nº de requisitos alterados, nº de não conformidades, nº de defeitos identificados internamente, nº de defeitos identificados pelo cliente, nº total de não conformidades registradas, nº de não conformidades concluídas e esforço despendido em correção de não conformidades, que, conforme sua definição operacional no plano de medição, seriam coletadas/analisadas ao final de cada fase ou mês, o que caracteriza uma granularidade muito alta para aplicação no controle estatístico de processos. Porém, percebeu-se que a organização, devido ao apoio provido pelo ambiente de gerência de projetos utilizado, manteve o registro de algumas dessas medidas em granularidade menor. Por exemplo, algumas medidas relacionadas a prazo e esforço, apesar de, para atender os requisitos dos níveis iniciais do CMMI poderem ser coletadas/analisadas mensalmente, os registros por dia, semana e atividade foram mantidos, podendo ser recuperados. Além disso, mesmo que, no plano de medição, as medidas não estivessem explicitamente relacionadas a processos específicos, os dados foram coletados e armazenados de tal forma que foi possível identificar o valor das medidas para cada processo. Durante a aplicação do checklist a cada medida, notou-se que o requisito referente à identificação das medidas correlatas não foi atendido por nenhuma medida. Além disso, outros requisitos importantes como existência das informações de contexto e definição dos critérios de agrupamento/comparação das medidas também não foram atendidos. Além disso, não há volume de dados suficiente para o controle estatístico para a maioria das medidas (ressaltando que, conforme já mencionado, foram considerados apenas os dados de projetos realizados em 2007). 84

106 A análise dos dados da base de medidas da organização A confirmou a afirmação de alguns autores, como Boria (2007) e Kitchenham et al. (2007), de que as medidas utilizadas para atender os requisitos dos níveis iniciais do CMMI não são aplicáveis ao controle estatístico de processos. Como diagnóstico geral da avaliação, concluiu-se que as medidas da base de medidas da organização A precisam de adequações para que possam ser utilizadas no controle estatístico de processos. Algumas das medidas coletadas são inúteis ao controle estatístico de processos como, por exemplo, número de projetos aderentes ao plano de medição. Outras, considerando os dados coletados, têm aplicabilidade, mas, sozinhas, não são suficientes para a realização do controle estatístico de processos pois, mesmo que seus dados sejam utilizados em técnicas estatísticas, a análise será muito difícil ou, até, impraticável, uma vez que informações de contexto e medidas correlatas não estão disponíveis. Além disso, a utilização apenas das medidas existentes não é capaz de descrever o desempenho dos processos. Baseando-se nos resultados da avaliação, algumas ações que devem ser realizadas pela organização para adequar sua base de medidas aos requisitos necessários para realização do controle estatístico de processos são: refinar o plano de medição a fim de relacionar, formalmente, as medidas aos processos; organizar a base de medidas conforme alterações no plano de medição; definir e coletar medidas correlatas às medidas definidas; registrar informações de contexto das medidas, incluindo informações relevantes sobre a execução do processo e projeto no momento da coleta da medida; refinar a caracterização dos projetos e definir critérios para agrupamento/comparação de medidas; definir e coletar outras medidas relacionadas ao desempenho e melhoria dos processos 3 ; coletar volume de dados suficiente para as medidas. Avaliação da Base de Medidas da Organização B (i) Contexto: Os dados presentes na base de medidas da organização B foram coletados ao longo de projetos realizados na organização, também avaliada CMMI e usuária do Ambiente TABA [Villela 2004]. A avaliação da base de medidas foi realizada sem interação com os membros da organização, ou seja, para a realização da avaliação foram consideradas, exclusivamente, as informações contidas na base de medidas e o conhecimento pessoal relativo aos ambientes, processos e estrutura do Ambiente TABA. (ii) Análise Geral: A organização B possui um plano de medição bastante refinado cujas medidas definidas encontram-se alinhadas aos objetivos de software estabelecidos pela organização. No entanto, não foi possível avaliar o planejamento estratégico da organização para analisar o alinhamento dos objetivos de software estabelecidos aos objetivos definidos no planejamento estratégico, uma vez que tais informações não se encontravam na base de medidas. Os projetos da organização são caracterizados seguindo o mecanismo de caracterização presente no Ambiente TABA, que inclui os critérios: indústria, tipo de software, paradigma, natureza do projeto, nível de experiência do gerente, nível de experiência da equipe, nível de experiência dos clientes, uso de tecnologia inovadora, 3 Apesar das medidas analisadas terem relação com o desempenho dos processos, a maioria delas está mais relacionada a controle que melhoria. 85

107 restrição de cronograma, restrição de desempenho, restrição de segurança, restrição de recursos humanos e distribuição geográfica da equipe. Na organização B, o plano de medição é elaborado através da identificação dos objetivos de software e, a partir deles, da seleção de questões e medidas a eles associadas. Essas medidas são relacionadas a processos que compõem o processo padrão da organização. Em cada projeto, o plano de medição é instanciado e novas medidas, necessárias ao atendimento de objetivos específicos do projeto, podem ser adicionadas. (iii) Análise Detalhada: Para realizar a avaliação foram utilizados dados de medidas coletadas pela organização em 2005, considerando 7 projetos. Foram avaliadas 124 medidas, associadas aos processos: gerência de requisitos, gerência de riscos, planejamento do projeto, gerência de configuração, medição e análise, garantia da qualidade, definição de requisitos, solução técnica, verificação, validação, análise de decisão e resolução, integração do produto, definição do processo organizacional, foco no processo organizacional e gerência integrada do projeto. Algumas das medidas avaliadas foram: esforço planejado, esforço realizado, tempo estimado, tempo real, nº de não conformidades, nº de requisitos incorretos, nº de requisitos ambíguos, nº de riscos identificados, nº de riscos identificados que ocorreram e nº de erros, entre outras. Apesar da organização possuir medidas com definições operacionais satisfatórias, alinhadas aos objetivos e relacionadas a todos os processos executados, o maior problema percebido foi a alta granularidade das medidas. A maior parte das medidas foi coletada ao final das fases ou por macroatividade nos projetos, uma vez que sua definição e coleta foram baseadas, principalmente, na necessidade de atender aos requisitos dos níveis iniciais do CMMI. A baixa freqüência da coleta também levou ao não atendimento do requisito volume de dados suficiente. Considerando que foram analisados dados de 7 projetos, algumas medidas, que foram coletadas uma única vez em cada projeto, não apresentaram volume de dados suficiente para aplicação do controle estatístico de processos. Além disso, faltam informações de contexto sobre as medidas. O registro do valor coletado para as medidas contém informações sobre o momento da coleta, porém, essas informações não são suficientes para a aplicação do controle estatístico de processos. Alguns pontos positivos percebidos durante a avaliação foram: presença de medidas correlatas, raras situações de dados não coletados para as medidas, grupos de dados relativamente homogêneos, presença de medidas para todos os processos e relevância das medidas às tomadas de decisão. Assim como ocorreu na análise dos dados da base de medidas da organização A, a análise da base de medidas da organização B gerou resultados que vão ao encontro da afirmação de que as medidas utilizadas para atender os requisitos dos níveis iniciais do CMMI não são aplicáveis ao controle estatístico de processos. A base de medidas B mostra-se aderente aos requisitos dos níveis iniciais do CMMI, porém, suas medidas ainda não são aplicáveis para o controle estatístico de processos. Como diagnóstico geral, conclui-se que a base de medidas B precisa de algumas adequações para que suas medidas sejam úteis ao controle estatístico de processos. A principal delas relaciona-se à freqüência de coleta das medidas, o que impacta diretamente em sua granularidade. Há medidas associadas a todos os processos e há um número satisfatório de medidas definidas, o que contribui para a seleção dos processos 86

108 críticos a serem submetidos ao controle estatístico de processos, porém, para isso, novos dados devem ser coletados, com a granularidade adequada, a fim de produzir o volume de dados necessário às medidas. Baseando-se nos resultados da avaliação, algumas ações que devem ser realizadas pela organização B para adequar sua base de medidas aos requisitos necessários para realização do controle estatístico de processos são: revisar a definição das medidas considerando menor granularidade; incluir nas informações de contexto das medidas coletadas informações relevantes sobre a execução do processo e projeto no momento da coleta da medida; e coletar volume de dados suficiente para as medidas. O Ambiente TABA, ao apoiar a organização B na definição e execução do plano de medição, contribuiu para um cenário mais propício à aplicação do controle estatístico de processos do que o cenário diagnosticado na organização A. Em comparação à base de medidas A, a base de medidas B precisará de menos adequações para atender aos requisitos para aplicação do controle estatístico de processos. 5. Conclusão O controle estatístico de processos contém diversas ferramentas de apoio à análise do comportamento de processos que são utilizadas para alcançar a estabilidade dos processos e buscar sua melhoria contínua através da redução dos limites de variação. Sua utilização no domínio da manufatura é ampla, porém, a aplicação a processos de software ainda é recente. O crescente interesse das organizações em elevar o grau de maturidade de seus processos e alcançar os níveis mais elevados de modelos de maturidade como MPS.BR (2007) e CMMI (2006) tem levado as organizações de software à utilização das técnicas do controle estatístico em seus processos. Apesar do crescente número de estudos publicados no contexto da aplicação das técnicas do controle estatístico de processos a processos de software, há muito poucos registros que forneçam orientações práticas satisfatórias para a implementação do controle estatístico de processos, pois uma parte considerável dos estudos registrados foca evidenciar a possibilidade e vantagens da aplicação do controle estatístico de processos a processos de software ou propor abordagens utilizadas em processos de software baseadas nos princípios do controle estatístico. Uma vez que ainda não há um conjunto formal, consolidado e detalhado, de diretrizes para a realização do controle estatístico de processos em processos de software, as organizações que realizam sua implementação têm encontrado dificuldades. Dentre as dificuldades que as organizações de software enfrentam para realizar o controle estatístico de processos, a não adequação de suas bases de medidas à aplicação das técnicas estatísticas tem sido destacada [Kitchenham et al. 2006] [Boria 2007]. Resolver essa questão é fundamental, pois, sem os dados adequados, o controle estatístico de processos não pode ser realizado de forma satisfatória. A identificação, seleção, coleta e armazenamento de medidas adequadas têm papel fundamental para iniciar a implementação do controle estatístico de processos para processos de software [Tarhan and Demirors, 2006]. Este artigo apresentou um instrumento para avaliação de bases de medidas considerando sua aplicabilidade para o controle estatístico de processos. Algumas considerações sobre a experiência de avaliação de bases de medidas, relatada na seção 4, são pertinentes e necessárias. Para realizar a avaliação, antes de 87

109 aplicar o checklist, foi necessária uma análise global do plano de medição e da base de medidas das organizações. Também foi necessário avaliar as medidas no contexto dos processos aos quais estavam relacionadas. A avaliação das medidas individualmente através do checklist não se mostrou suficiente para determinar a aplicabilidade ou não para o controle estatístico de processos. Sendo assim, conclui-se que o instrumento para avaliação de medidas proposto deve considerar, além da avaliação individual das medidas, a avaliação no contexto dos processos e da base de medidas como um todo. O trabalho descrito neste artigo está relacionado a uma tese de doutorado em andamento. Sendo assim, uma evolução do instrumento proposto contemplando os aspectos ressaltados durante a experiência de avaliação das bases de medidas será realizada. Essa evolução deve incluir a avaliação das medidas no contexto dos processos e da base de medidas como um todo, bem como a definição do procedimento a ser utilizado para concluir, a partir dos resultados da avaliação, se uma medida é aplicável ou não ao controle estatístico de processos. O procedimento deve considerar a criticidade dos requisitos à realização do controle estatístico de processos e, com base nos requisitos atendidos e não atendidos por uma medida, indicar seu grau de aplicabilidade. Para identificar a criticidade de cada requisito à aplicação do controle estatístico de processos, pode-se considerar os registros da literatura (sabe-se, por exemplo, que ter baixa granularidade é condição fundamental para que uma medida possa ser aplicada ao controle estatístico de processos) e realizar testes incluindo a aplicação das técnicas estatísticas em dados coletados para medidas que não atendam a um requisito específico, a fim de analisar as consequências do não atendimento de um determinado requisito. Além disso, a evolução do instrumento incluirá uma definição detalhada de cada requisito, bem como orientações sobre como cada um deles deve ser avaliado. 6. Referências Bibliográficas Barcellos, M. P., 2008, Uma Abordagem para Controle Estatístico de Processos de Software em Organizações de Alta Maturidade, Exame de Qualificação para Tese de D.Sc., COPPE/UFRJ, Rio de Janeiro, Brasil. Biolchini, J., Mian, P. G., Natali, A. C., 2005, Systematic Review in Software Engineering, RT-ES 679/05, COPPE/UFRJ, Rio de Janeiro, Brasil. Boria, J. L., 2007, What s Wrong With My Level 4?, Comunicação Pessoal. Card, D. N.: Statistical Techniques for Software Engineering Practice. Proceedings of the 26th International Conference on Software Engineering, pp (2004). CMMI Capability Maturity Model Integration, 2006, SEI Software Engineering Institute, CMU - Carnegie Mellon University, v 1.2. Eickelmann, N., Anant, A., 2003, Statistical Process Control: What You Don t Measure Can Hurt You, IEEE Software, Volume 20, Issue 2, pp Fenton, N., Marsh W., Neil, M., Cates, P., Forey, S., Tailor, M.:, 2004, Making Resource Decisions for Software Projects, Proceedings of the 26th International Conference on Software Engineering - ICSE 04, pp Fuggetta, A., 2000, Software Process: A Roadmap, In: Proceedings of the 22 nd International Conference on Software Engineering, Limerick, Irlanda, pp Garcia, F., Serrano, M., Cruz-Lemos, J., Ruiz, F., Piattini, M., 2007, "Managing Software Process Measurement: A Metamodel-Based Approach"Information Sciences, Volume 177, nº 12, pp

110 ISO/IEC, ISO/IEC TR , 2003, Information Technology Software Process Assessment, International Organization for Standardization and the International Electrotechnical Commission, Geneva, Switzerland. ISO/IEC FDIS (E) Software Engineering Software Measurement Process, International Organization for Standardization and the International Electrotechnical Commission, Geneva, Switzerland. Kilpi, T., 2001, Implementing a Software Metrics Program at Nokia, IEEE Software, Volume 18, Issue 6, pp Kitchenhan, B., Kutay, C., Jeffery, R., Connaughton, C., 2006, Lessons Learnet from the Analysis of Large-scale Corporate Databases, Proceedings of the 28th International Conference on Software Engineering ICSE 06, pp Kitchenhan, B., Kutay, C., Jeffery, R., Connaughton, C., 2007, Misleading Metrics and Unsound Analyses, IEEE Software, Volume 24, Issue 2, pp Komuro, M., 2006, Experiences of Applying SPC Techniques to Software Development, Proceedings of the 28th International Conference on Software Engineering - ICSE 06, pp Lantzy, M. A., 1992, Application of Statistical Process Control to the Software Process, Proceedings of the 9th Washington Ada Symposium on Empowering Software Users and Developers, ACM Press, pp Montoni, M., 2007, Uma Abordagem para Condução de Iniciativas de Melhoria de Processos de Software, Exame de Qualificação para o Doutorado, COPPE/UFRJ, Rio de Janeiro, Brasil. MPS.BR Melhoria de Processo do Software Brasileiro, Guia Geral, v. 1.2, Sargut, K. U., Demirors, O., 2006, Utilization of Statistical Process Control (SPC) in Emergent Software Organizations: Pitfalls and Suggestions, Software Quality Journal, pp Tarhan, A., Demirors, O., 2006, Investigating Suitability of Software Process and Metrics for Statistical Process Control, Lectures Notes in Computer Science, Volume 4257/2006, pp Villela, K., 2004, Definição e Construção de Ambientes de Desenvolvimento de Software Orientados à Organização, Tese de D. Sc., COPPE/UFRJ, Rio de Janeiro, Brasil. Wang, Q., Li, M., 2005, Measurement and Improving Software Process in China, Proceedings of International Symposium on Empirical Software Engineering - ISESE 2005, pp Wang, Q., Jiang, N, Gou, L., Liu, X., Li, M., Wang, Y., 2006, BSR: A Statistical- Based Approach for Establishing and Refining Software Process Performance Baseline, International Conference on Software Engineering ICSE 06, pp Wheeler, D. J., Poling, R. S., 1998, Building Continual Improvement: A Guide for Business, SPC Press. 89

111 90

112 Desenvolvimento de um Ambiente de Apoio à Tomada de Decisões em Projetos de Software Hélio R. Costa 1, 2, Gustavo B. Vieira 1,2, Luiz Claudius Coelho F. Leite 1,2, Ana Regina Rocha 1 1 COPPE/UFRJ Programa de Engenharia de Sistemas e Computação Caixa Postal CEP: Rio de Janeiro RJ 2 CCA-RJ Ponta do Galeão s/nº - Ilha do Governador RJ, CEP heliorcosta@terra.com.br, gustavo_barbi@yahoo.com.br, luiz.claudius@gmail.com, darocha@centroin.com.br Abstract. Almost everything we do in our lives is about making decisions under an uncertain scenario. Software Engineers and Project Managers also experience this problem during a software development process. Nevertheless, up to the present moment, there not exist a body of knowledge that may help managers and practitioners during a decision process. This paper describes the steps that are being taken in order to build an environment for decision making in software projects based on a formal process, the reuse of knowledge and decision support methods. Resumo. Quase tudo o que fazemos na vida envolve a tomada de decisão sobre um cenário de incerteza. Engenheiros de software e gerentes de projetos também vivenciam este problema ao longo do processo de desenvolvimento de software. Contudo, não existe, até o presente momento, um corpo de conhecimento organizado que possa auxiliar gerentes e engenheiros de software durante um processo decisório. Este artigo descreve os passos que estão sendo realizados para a construção de um ambiente de apoio à tomada de decisões em projetos de software, baseado em um processo formal, no reuso de conhecimento e na aplicação de métodos de apoio à decisão. 1. Introdução Tomar decisões é uma atividade central na vida de todas as pessoas. Quase tudo o que fazemos envolve algum tipo de tomada de decisão, seja ela simples ou complexa. A Engenharia de Software, assim como diversas áreas de conhecimento, também requer o uso de técnicas gerenciais, pois decisões precisam ser tomadas ao longo de todo o processo de desenvolvimento e evolução dos sistemas. Questões como: tipos de tecnologias, processos, recursos e ferramentas são fundamentais para a garantia da qualidade de produtos e serviços. Ruhe [Ruhe 2003] comenta que a tomada de decisões afeta significativamente todos os estágios do ciclo-de-vida de um projeto e que processos e sistemas de apoio à decisão são fundamentais para aumentar a eficiência, a qualidade e a relação custo-benefício de sistemas. 91

113 Normalmente, a experiência obtida durante o desenvolvimento de software é armazenada de forma implícita e dificilmente está acessível. Este fato acontece devido à falta de uma infra-estrutura que permita que o conhecimento adquirido não seja perdido e que forneça meios dele circular dentro da organização [Hoffmann 1997]. É certo que, com a atual complexidade dos sistemas, a rapidez da evolução dos requisitos e tecnologias, a elevada concorrência do mercado e a restrição cada vez maior de recursos, não há mais espaço para decisões equivocadas ou que provoquem retrabalho sem uma adequada justificativa. No entanto, tem-se observado que: (i) problemas são, normalmente, mal-entendidos e/ou mal-descritos; (ii) decisões são tomadas sob pressão de tempo; (iii) decisões não são baseadas em dados confiáveis, modelos avaliados experimentalmente ou em boas práticas comprovadas; (iv) decisões são tomadas sem considerar a perspectiva de todos os interessados na questão; (v) decisões não são esclarecidas ou tornadas transparentes para todos os envolvidos; e (vi) decisões são tomadas sem nenhuma metodologia ou utilizando metodologias não confiáveis [Clemen e Reilly 2004]. O apoio à decisão na Engenharia de Software é de grande interesse, tanto para a academia quanto para a indústria. Contudo, Ruhe [Ruhe 2003] comenta que, atualmente, muitas decisões cruciais são tomadas de forma ad hoc, baseadas em impressões e sem conexão com as melhores práticas, modelos e experiências. É preciso, pois, envidar esforços no sentido de definir processos, estabelecer metodologias adequadas e integrar o maior número possível de informações disponíveis, para que seja criado um ambiente adequado para auxiliar tomadores de decisão em organizações desenvolvedoras de software. Durante a realização deste trabalho, diversos Sistemas de Apoio a Decisão (SAD) foram estudados e analisados, visando identificar a possibilidade de atender gerentes e engenheiros de software nas suas atividades rotineiras de tomada de decisão. Exemplos de Sistemas de Apoio à Decisão (SADs) aplicados à Engenharia de Software podem ser encontrados em [Collofello et al. 1998; Raffo et al. 2002; Fenton et al. 2004]. No entanto, todos os sistemas encontrados apóiam um tipo específico de problema com base em modelos voltados para o domínio representado. Este trabalho tem como meta final desenvolver um Ambiente Apoio à Tomada de Decisão (Oráculo) acoplado ao Ambiente Taba de Desenvolvimento [Santos et al. 2005]. Partindo dos resultados esperados de todos os processos do MR-MPS.BR [SOFTEX 2007] que envolvem tomada de decisão, será realizado um mapeamento entre esses resultados esperados e os processos e atividades do Taba. Dessa forma ao utilizar o Ambiente Taba, um usuário poderá ser assistido durante todo o tempo pelo Ambiente Oráculo, melhorando a qualidade e a velocidade do processo decisório. O Oráculo terá como pilares três componentes principais: (i) um processo formal de tomada de decisão, (ii) um mecanismo de armazenamento e recuperação de conhecimento e a (iii) seleção de métodos que apóiem a tomada de decisão. Além desta introdução, a seção 2 do artigo faz uma revisão da literatura sobre as condições de tomada de decisão, das classes de problemas e objetivos e das perspectivas de tomada de decisão. A seção 3 descreve o processo definido para apoiar a tomada de decisão em projetos de software. A seção 4 apresenta os resultados da aplicação do processo proposto. A seção 5 descreve como o ambiente trata os aspectos de 92

114 armazenamento e recuperação de conhecimento. A seção 6 enfoca como os métodos deverão ser utilizados nos processos de tomada de decisão. Na seção 7 são apresentadas algumas perspectivas futuras, visando esclarecer os próximos passos deste trabalho e, finalmente, na seção 8 são traçadas conclusões. 2. Tomada de Decisão 2.1 Condições de Tomada de Decisão Em todas as formas de tomada de decisão existem sempre dois elementos básicos a serem analisados: os fatores que fazem parte do problema e da solução e suas respectivas probabilidades de ocorrência. Quanto aos fatores, pode-se obter dois estados: conhecimento total ou parcial. Quanto às probabilidades têm-se, também, dois estados: 100% ou algum valor entre 0% e 100%. Dessa forma podemos encontrar três condições onde decisões são tomadas: Certeza, Certeza Parcial e Ignorância. [Klein 1999]. 2.2 Classes de Problemas e Objetivos Existem duas classes de problemas e de objetivos: os bem-definidos e os mal definidos [Reitman 1965]. Problemas bem-definidos são aqueles cujos objetivos, caminhos e obstáculos estão claros e baseados em informações confiáveis. Por sua vez, problemas mal definidos são caracterizados pela ausência de um caminho claro que leve à solução. Os objetivos bem-definidos são aqueles que proporcionam ao solucionador uma linha clara de ação em sua direção. Já nos objetivos mal definidos, as metas a serem alcançadas não são claras. 2.3 Perspectivas de Tomada de Decisão De acordo com [Klein 1999] existem duas perspectivas nas quais os seres humanos tomam decisões: a Natural e a Racional. Na primeira, os decisores estão, geralmente, envolvidos com problemas ou objetivos mal definidos e as decisões são baseadas na experiência. Já na Racional, existe um processo formal de tomada de decisão, ou linha de raciocínio a ser seguida, onde, passo-a-passo, o decisor é levado a atingir o objetivo proposto pelo processo. Em relação à perspectiva Natural, Klein [Klein 1999] verificou que as pessoas possuem uma gama de habilidades para tomar decisões de forma Natural, às quais ele chamou de Fontes de Poder: Intuição, Simulação Mental, Pontos de Apoio, Analogias e Metáforas, Mente da Equipe, Criação de Estórias e Visão do Invisível. A perspectiva Racional, segundo o próprio Klein [Klein 1999], também é uma importante fonte de poder, pois fornece os benefícios de ordenar e sistematizar abordagens de solução para problemas tanto complexos como simples. Por sua vez, nossa habilidade de analisar situações requer, apenas, pensamento racional, que é independente de experiência. Algumas outras vantagens da Perspectiva Racional são: (i) permite a discriminação de idéias; (ii) reduz a chance de uma possível alternativa de solução ser negligenciada; (iii) possibilita a ampla busca por muitas opções; (iv) permite o registro de lições aprendidas para reutilização em decisões futuras; (v) permite ao decisor usar seu conhecimento de forma declarativa; e (vi) aproxima-se mais de resoluções livres de erros do que outras abordagens. 93

115 Diversas críticas, contudo, são apresentadas à perspectiva racional [Gigerenzer e Selten 2002]: (i) requer um maior tempo de análise comparada à perspectiva natural; (ii) normalmente é aplicada a problemas bem-definidos; (iii) depende de muitas informações para ser colocada em prática; (iv) complexidade ao se aplicar cálculos, pois existe uma grande dificuldade em se obter dados precisos ou estimativas para serem aplicados aos métodos. Vários outros estudos discutem as vantagens e as desvantagens tanto da abordagem natural quanto da racional, tais como [Klein e Weitzenfeld 1978; Lipsitz e Bar-Ilan 1996]. No entanto, alguns fatores tendem a levar o processo de tomada de decisão, no contexto da Engenharia de Software, para a Perspectiva Racional, motivo pelo qual este trabalho adotou a Perspectiva Racional como forma de apoiar o processo de tomada de decisões durante o ciclo-de-vida de projetos de software: A Engenharia de Software faz parte de um contexto financeiro e é uma atividade econômica como qualquer outra. Neste sentido, tanto gerentes como técnicos precisam, em muitos casos, embasar e justificar suas decisões de maneira formal [Costa et al. 2004]; Durante um processo de desenvolvimento de software, geralmente há tempo suficiente para se tomar decisões baseadas em uma análise mais detalhada como a sugerida pela perspectiva racional; Permite que o registro dos processos seja reutilizado em futuras decisões, facilitando a geração de conhecimento, o aprendizado organizacional, o aperfeiçoamento do processo e a melhoria dos parâmetros de decisão; e Modelos de referência e normas internacionais, tais como o CMMI - Capability Maturity Model Integration [Chrissis et al. 2006], a ISO/IEC Software lifecycle processes Amendment 2 [ISO/IEC 2004], a ISO/IEC Software Process Assessment [ISO/IEC 2003] e o MR-MPS.BR Modelo de Referência para Melhoria de Processo do Software Brasileiro [SOFTEX 2007] - exigem que processos formais de tomada de decisão sejam utilizados em situações onde isto seja necessário para se atingir determinados níveis de maturidade e capacitação em processos de software. 3. Processo Formal A fim de viabilizar a construção do ambiente de tomada de decisão foi elaborado um processo que conduzisse o decisor a uma solução mais adequada para o problema, devendo ser associado a problemas com risco médio, alto ou que afetem a possibilidade de alcançar os objetivos do projeto, bem como nos momentos em que o impacto da decisão envolver uma quantia determinada do orçamento, alteração significativa do cronograma ou qualidade, decisões técnicas não triviais, etc. Ele pode ser usado tanto para problemas técnicos (escolher o tipo de arquitetura a ser empregado) como para problemas não-técnicos (definir o melhor fornecedor de um produto). No entanto, devese atentar para o fato de que o custo de um processo de avaliação formal deve ser aceitável quando comparado ao impacto da decisão. Os critérios para a utilização do processo de decisão formal em uma organização devem estar definidos na sua Política Organizacional. 94

116 Não existe uma lista completa de situações onde se deve aplicar um processo formal de decisão, pois sua utilização é extremamente dependente do tipo de organização, do projeto ou até mesmo do produto. No entanto, alguns exemplos passíveis da utilização de um processo formal de decisão são: definição de componentes, decisão sobre construir ou adquirir um produto, seleção de ferramentas, definição de estratégias de contingências de riscos, priorização de recursos, contratação de pessoal e plataformas de sistemas. 3.1 Contextualizar a Decisão O primeiro passo em um processo de tomada de decisão formal é a contextualização da decisão, a fim de esclarecer dúvidas, definir responsabilidades e o ambiente em que o processo será utilizado. Deve-se considerá-la inicialmente para que seja possível compreender e deixar claro o contexto de utilização do processo. Nesta atividade são definidas questões tais como: a empresa ou o local onde o problema será resolvido, o projeto em pauta, os responsáveis, participantes, o contexto em si e, caso necessário, um glossário dos termos que serão utilizados, para que todos tenham ciência do assunto que está sendo tratado. 3.2 Definir o Problema Em seguida é necessário definir exatamente qual o problema se deseja resolver, o que terá forte influência sobre as possíveis soluções adotadas. Definir um problema erroneamente pode conduzir o decisor a um caminho que não o levará à solução do problema real. Esta atividade visa assegurar que se pretende resolver o problema correto e deve estar alinhada com os objetivos de negócio da organização. Para uma correta definição do problema e embasamento para a elaboração das possíveis soluções, sugerese atentar para os detalhes propostos por [Gomes et al. 2004]. 3.3 Definir Critérios de Seleção Em muitos casos, mais de uma variável pode influenciar na escolha da melhor solução. Essas variáveis são chamadas critérios. Dessa forma, os critérios de avaliação devem ser priorizados e/ou ponderados, bem como definidos os parâmetros de aceitação de cada critério, para que eles possam ser aplicados e a melhor solução possa ser escolhida. A priorização e/ou a ponderação dos critérios pode ser feita por uma ou mais pessoas, devendo-se registrar o resultado do trabalho e os motivos que levaram à escolha dos critérios e à sua priorização e/ou ponderação. Pode-se, também, registrar os motivos que levaram à exclusão de alguns critérios. Os critérios escolhidos não devem ser tendenciosos, devendo ser escolhidos apenas aqueles que colaboram para que o objetivo seja alcançado. Na priorização e/ou ponderação de critérios, estes devem ser ordenados de tal forma que aquele com maior grau de prioridade seja o que realmente tem maior influência no processo de decisão. 3.4 Definir o(s) Método(s) de Avaliação Não existe um consenso sobre qual o melhor método a ser utilizado em um processo de decisão formal, pois eles dependem de diversos fatores, tais como: o nível de precisão requerido na resposta; o tempo disponível para a tomada de decisão; os recursos a serem empregados; o grau de conhecimento da equipe na aplicação de um método específico; a complexidade do problema; e, até mesmo, as informações disponíveis para a tomada 95

117 de decisão. Alguns problemas podem necessitar o uso de apenas um método de avaliação, outros, por sua vez, podem requerer diversos métodos para se determinar que alternativa de solução melhor se aplica ao problema definido. Os métodos a serem usados para avaliação podem variar desde uma simples reunião, a simulações e ao uso de modelos probabilísticos complexos, chegando ao desenvolvimento de sistemas especialistas para situações mais específicas. Exemplos de métodos de avaliação tais como simulação, árvores de decisão, análise de custobenefício podem ser encontradas em [Clemen e Reilly 2004]. Detalhes sobre métodos mais simples, tais como Multivotação Ponderada, Análise de Pareto e Comparação aos Pares podem ser encontrados em [Wildman e Warner 2003]. Outros métodos mais complexos, tais como Redes Bayesianas [Jensen 1996], Análise multi-critério [Bana e Costa e Vansnick 1995] e Dinâmicas de Sistemas [Barros 2001] também podem ser utilizados. 3.5 Identificar Alternativas de Solução A identificação de alternativas de solução deve ser realizada de forma a permitir uma boa avaliação e uma implementação correta. Sempre que possível, os principais envolvidos no problema devem estar presentes na execução desta atividade, bem como especialistas e demais pessoas que serão afetadas pelo problema ou pela(s) solução(ões). Uma boa prática para a identificação das possíveis soluções é realizar um trabalho de grupo ou reuniões de brainstorming, onde, além das alternativas de solução, sejam levantados os riscos, problemas, vantagens e desvantagens das referidas alternativas, bem como possíveis premissas e restrições para a implementação de uma solução. É de suma importância, neste momento, a avaliação quantitativa dos riscos envolvidos na implementação (ameaças e oportunidades) de cada solução, pois caso alguma solução seja considerada inviável, devido a uma ameaça que comprometa os objetivos do projeto, esta não deverá ser levada para a próxima fase do processo. No entanto, a análise das oportunidades que uma alternativa pode produzir também deverá ser foco de atenção. Esta avaliação deve considerar a probabilidade de ocorrência, o impacto e, se a implementação desta solução afetará o processo de desenvolvimento, o produto final ou qualquer outra atividade em alguma fase futura. 3.6 Avaliar Alternativas Avaliar as alternativas significa realizar o trabalho necessário para aplicar os métodos selecionados às possíveis soluções listadas. Durante esta fase do processo, cada alternativa de solução deve ser submetida ao método escolhido e os resultados registrados para futura análise. A aplicação do método deve ser o mais imparcial possível, a fim de não influenciar a avaliação das alternativas, lembrando sempre que os resultados não serão analisados nesta etapa do processo. 3.7 Analisar Resultados Nesta atividade deve-se comparar os resultados obtidos na avaliação de cada alternativa em relação aos critérios estabelecidos. Ao realizar a análise de uma alternativa, faz-se necessário verificar se ela está adequada às restrições e premissas impostas, tanto pelo problema quanto pela própria alternativa em questão. Deve-se elaborar um breve parecer do resultado obtido após a aplicação dos critérios de seleção a cada alternativa 96

118 analisada, sugerindo a solução proposta para que o responsável pela decisão final aprove ou não a solução, visto que nem sempre o responsável pela decisão é a mesma pessoa que executou o processo. É importante que se verifiquem os riscos associados a cada alternativa, os quais já foram listados e avaliados ao identificá-la. Possíveis respostas aos riscos (contenções ou contingências) necessárias para sua eliminação ou mitigação devem ser definidas. Algumas abordagens para gerenciamento de risco podem ser encontradas em [Farias 2002 e Carr et al. 2003; Chrissis et al. 2006]. 3.8 Selecionar a Solução Selecionar uma solução implica escolher aquela que melhor se enquadra nos critérios determinados e faz com que o problema seja resolvido. Todo o processo de escolha da solução deve ser documentado para que questionamentos futuros possam ser esclarecidos. Os motivos que justificam a escolha de uma solução devem ser descritos, bem como os motivos que levaram à exclusão das demais alternativas. 3.9 Implementar a Solução Após a escolha de uma alternativa de solução é aconselhável elaborar algumas recomendações para a sua implementação. Isto significa traçar as linhas gerais da forma como a solução escolhida deve ser implementada, podendo conter informações adicionais, procedimentos, responsáveis, etc. Caso sejam necessárias modificações no Plano do Projeto ou em baselines previamente estabelecidas, estas deverão ser registradas para que os responsáveis tomem ciência desses fatos. 4. Aplicações do Processo Para se chegar à atual versão, testar sua validade e realizar aperfeiçoamentos, o processo foi utilizado pela empresa BL Informática que teve os seus processos avaliados em relação às áreas de processo dos níveis 2 e 3 do CMMI e uma avaliação oficial SCAMPI e foi considerada aderente ao nível 3 do CMMI. Durante a iniciativa de melhoria de processos, com o objetivo de apoiar a implantação dos processos de Análise de Decisão e Resolução e Solução Técnica que deveriam estar aderentes ao CMMI, a BL Informática utilizou a ferramenta TechSolution [Figueiredo 2006] e o processo proposto. Antes da implantação deste processo, as decisões eram simplesmente registradas em ata de reunião e tomadas com base na experiência dos envolvidos, não existindo registro detalhado dos critérios utilizados e a causa da não utilização de uma determinada alternativa. Os maiores benefícios constatados até então, foram: (i) a diminuição da subjetividade em torno das decisões; (ii) o registro detalhado das decisões que começaram a ser utilizados como lição aprendida, apoio e informação para novas decisões; (iii) maior assertividade nas soluções propostas; (iv) maior entendimento dos envolvidos sobre os benefícios e riscos das alternativas, facilitando a decisão; e (v) disseminação do conhecimento obtido durante a execução do projeto. 97

119 5. A Gestão do Conhecimento O conhecimento adquirido em um projeto de software, por meio da utilização de técnicas de Engenharia de Software, pode ser melhor aproveitado pela sua transferência para outros projetos. A disseminação das experiências aprendidas permite o melhoramento contínuo do desenvolvimento de projetos de software e também proporciona a diminuição de seus custos. Porém, para que a transferência de conhecimento seja possível e viável, é necessário que as experiências adquiridas sejam catalogadas e armazenadas, de modo que elas não sejam futuramente esquecidas ou perdidas. Além disso, é necessária a identificação de características de cada experiência e do projeto no qual ela se originou para que este conhecimento possa ser transferido entre projetos similares [Souza 2002]. O segundo passo para a construção do ambiente de tomada de decisão foi descobrir um mecanismo ou tecnologia que fosse simples e eficiente no sentido, tanto de armazenar quanto de recuperar informações e conhecimentos adquiridos ao longo do tempo, a fim de auxiliar decisões futuras. Abordagens tradicionais de Gestão de Conhecimento, tais como as de [Nonaka 1994; Meehan e Richardson 2002] não se mostraram ágeis o suficiente para atender aos requisitos do ambiente. A solução encontrada foi aplicar os conceitos de Raciocínio Baseado em Casos (RBC) [Schank 1982; Aamodt e Plaza 1994] e registrar os passos de realização do processo de decisão formal em forma de casos, bem como palavras-chaves, para que estes possam ser recuperados por questão de similaridade com problemas futuros e, desta forma, auxiliar decisores em suas atividades. 5.1 Raciocínio Baseado em Casos RBC é um enfoque de aprendizado contínuo e incremental que utiliza o conhecimento de situações concretas acontecidas no passado (casos) para resolver novos problemas e aprender por meio da experiência adquirida. O principal objetivo da abordagem RBC é o desenvolvimento de um conjunto de experiências práticas e o fornecimento de um amplo suporte ao desenvolvimento de sistemas apoiado nesta base de conhecimento [Wangenheim 1998]. O uso de RBC em Engenharia de Software não é uma novidade e diversos exemplos bem sucedidos podem ser observados. Na área de estimativas encontramos [Bisio e Malabochia 1995; Finnie et al. 1997]. Em relação ao reuso de software tem-se o exemplo de [Ostertag et al. 1992]. Outras aplicações podem ser encontradas em [Rodrigues 2000]. Desta forma, acredita-se que quanto mais casos forem cadastrados no ambiente, maiores serão as possibilidades de um decisor beneficiar-se de casos anteriores, eliminando dúvidas, aproveitando erros e acertos passados e contribuindo cada vez mais para o aperfeiçoamento, tanto de suas decisões quanto da base de conhecimento. Em um processo RBC, a descrição inicial de um problema define um novo caso. Este novo caso é utilizado para recuperar um ou mais casos da coleção de casos passados que estão armazenados na base de experiências. O problema de representação de conhecimento em RBC está em decidir o que armazenar em um caso, encontrar uma estrutura apropriada para descrever o conteúdo dos casos, e decidir como uma base de 98

120 casos deverá ser organizada e indexada para uma efetiva recuperação e reutilização do conhecimento contido nela [Souza 2002]. Esses problemas foram solucionados da seguinte forma: a partir da definição dos processos e atividades definidos na estação Taba, foram mapeadas todas as situações onde sejam possíveis tomadas de decisão. Em seguida, foram analisados todos os resultados esperados dos processos do MR-MPS.BR a fim de se obter uma visualização de quais resultados eram passíveis de tomada de decisão. Finalmente foi realizado um mapeamento entre esses resultados esperados e as situações problema dos processos e atividades da estação Taba. Assim, já se pode fornecer ao usuário do ambiente uma série de situações onde possivelmente ele poderá tomar decisões formais. Em relação à estrutura dos casos eles serão registrados de acordo com o padrão estabelecido para o processo formal adaptado à situação que se deseja resolver. Por exemplo, ao ser iniciado um processo de tomada de decisão durante a fase de definição de arquitetura, todos os itens do processo formal referentes a esta situação, já estarão previamente preenchidos, restando ao usuário o preenchimento dos itens referentes ao seu caso específico. Desta forma, dois problemas foram automaticamente resolvidos, quais sejam: o que armazenar, definido pelas situações-problema; a estrutura de armazenamento dos casos, que ficou definida como sendo a do processo formal. O último problema a ser resolvido era como seria o cálculo grau de similaridade entre os casos cadastrados na base de casos. Isto foi resolvido da seguinte maneira: a indexação dos casos será composta por dois níveis. O primeiro nível será referente ao Resultado Esperado do MR-MPS-BR a que ao caso faz referência.. O segundo nível será relativo ao Contexto do Caso (primeiro passo do processo formal) e à Definição do Problema (segundo passo do processo formal). Nesse segundo nível a indexação será feita por palavras-chaves associadas tanto ao contexto quanto à definição do problema do caso em questão, sendo esta associação feita pelo próprio usuário que está sendo responsável pelo caso. Vale ressaltar que no Ambiente Taba já existem diversas palavras-chaves já cadastradas que serão utilizadas como base para os cadastros dos índices, sendo que um usuário será capaz de cadastrar novas palavras-chaves. A partir dos dados fornecidos pelo usuário, a busca será feita por um algoritmo que realizará uma pesquisa na base de casos e disponibilizará uma listagem de casos em ordem de grau de similaridade com os dados fornecidos. Assim, se um caso possuir em seu banco de palavras-chaves os mesmos dados fornecidos e estiver associado ao mesmo Resultado Esperado pelo usuário no momento da busca, ele será 100% semelhante ao seu caso e, possivelmente terá grande valia para auxiliar a solução do problema em questão. Consequentemente, quanto menos índices coincidentes, menos similares serão os casos. A fim de ilustrar a proposta, considere o seguinte exemplo: 03 (três) casos cadastrados e diversas palavras-chave (índices hipotéticos) representadas pelas letras de A a M, fornecidas no momento do armazenamento do caso na base de casos, conforme a Tabela 5.1 Tabela 5.1 Base de casos 99

121 Caso 1 Caso 2 Caso 3 Contexto Índices Contexto Índices Contexto Índices Texto descritivo para A,B,C, Texto descritivo para B,C,E Texto descritivo para A, F, G contexto do caso 1. D contexto do caso 2. contexto do caso 3. Índices Problema Problema Índices Problema Índices Texto descritivo para o H, I,J Texto descritivo para J, K, L Texto descritivo para o I, K, M problema do caso 1. o problema do caso 2. problema do caso 3. Supondo que um usuário esteja tentando resolver um novo problema referente a um dado resultado esperado do MR-MPS-BR (por exemplo, RE1) e q ueira buscar casos semelhantes para auxiliar seu processo decisório. Ele indicará que seu caso se refere a este Resultado Esperado e a busca se restringirá aos casos vinculados a RE1 na base de casos. Baseado na análise dos fatores envolvidos, o usuário informa que as palavraschave que mais caracterizam o Contexto seu Problema são os índices (A, B e C) e as que mais caracterizam sua Definição de Problema são os índices (I e J). Portanto, estes índices serão usados como palavras-chaves na tentativa de busca de casos similares. Com base nestas informações, o cálculo de similaridade é realizado da seguinte forma: N c / N T, onde (i) N c - n o de coincidências entre as palavras-chaves fornecidas e os índices definidos para o Contexto e a Definição do Problema e (ii) N T - n o total de palavras-chaves fornecidas. O cálculo é efetuado separadamente tanto para o Contexto quanto para a Definição do Problema. Finalmente, calcula-se o somatório da média ponderada destes resultados. Para efeito de simplificação os pesos estão sendo considerados idênticos (1/2) tanto para o Contexto quanto para a Definição do Problema. Dessa forma, a busca teria um resultado como e exibido na Tabela 5.2. Tabela 5.2. Resultado da Busca Caso Similaridade Explicação Caso % Das 3 (Nt) palavras-chaves informadas na busca para Contexto (A,B,C), as 3 (Nc) A, B e C foram definidas como índices do caso 2. Contexto=3/3=1. Das 2 (Nt) palavras-chaves informadas para a busca para problema (I, J), 2 (Nc) I e J foram definidas como índice do caso 2. Problema=2/2=1 Caso 2 58,3 % Caso 3 41,7 % Similaridade = (1 x 1/2) + (1 x ½)=1 Das 3 (Nt) palavras-chaves informadas na busca para Contexto (A,B,C), apenas 2 (Nc) B e C foram definidas como índices do caso 2. Contexto=2/3=0,666. Das 2 (Nt) palavras-chaves informadas para a busca para problema (I, J), apenas 1 (Nc) J foi definida como índice do caso 2. Problema=1/2=0,5 Similaridade = (0,666 x 1/2) +.(0,5 x 1/2)=0,583 Das 3 (Nt) palavras-chaves informadas na busca para contexto (A,B,C), apenas 1 (Nc) A foi definida como índice do caso 3. Contexto=1/3=0,333. Das 2 (Nt) palavras-chaves informadas para a busca para problema (I, J), apenas 1 (Nc) I foi definida como índice do caso 2. Problema=1/2=0,5 Similaridade = (0,333 x 1/2) +.(0,5 x 1/2)=0,417 Com base no resultado, o usuário do sistema tem condições de avaliar que casos apresentam maior grau de similaridade em relação ao seu problema, o que o ajudará a 100

122 reutilizar adequadamente experiências anteriores para avaliar possíveis soluções e optar por uma alternativa adequada. 6. Métodos de Tomada de Decisão Uma das maiores dificuldades observadas durante a aplicação do processo em empresas é escolher e aplicar um método às alternativas encontradas de forma a determinar qual a mais adequada à solução do problema. Conforme descrito na seção 3.4, diversos métodos podem ser aplicados, desde os mais simples aos mais elaborados, dependendo de quão crítico é o problema. No entanto, observa-se que métodos mais complexos tais como Simulações, Redes Bayesianas, Dinâmica de Sistemas e Redes Neurais requerem um longo tempo para que se desenvolvam modelos confiáveis, bem como são mais utilizados para sistemas especialistas. Levando-se em conta que o objetivo do ambiente é fornecer apoio genérico para a tomada de decisão, buscou-se na literatura um conjunto de métodos e ferramentas que fossem simples de serem empregados, mas que oferecessem confiabilidade em suas aplicações, de tal forma que a grande maioria dos problemas vivenciados no dia-a-dia de projetos de software pudessem ser atendidos Princípio de Pareto [Aron 1937]. Wildman e Warner (2000) realizaram um extenso estudo sobre métodos mais simples que têm sido usado ao longo da história para auxiliar o processo de decisão em diversas áreas de conhecimento. Desta forma, pretende-se aproveitar a experiência do autor para aplicá-la na proposta deste trabalho. São eles: Árvores de Decisão, Matriz de Avaliação, Force Field Analysis, Matriz de Análise de Decisão, Multivotação, MAUT, Comparação aos Pares, PMI (Plus, Minus, Interesting) e Six Thinking Hats. A fim de descobrir que métodos eram adequados a quais tipos de problema, foi realizada uma busca por taxonomias de classificação de métodos de tomada de decisão, pois, dependendo das características do problema (tipos de informações disponíveis), um ou outro método é mais apropriado. A taxonomia de classificação que mais se enquadrou no contexto deste trabalho foi a proposta por [Ullman e D Ambrosio 1995]. Originalmente, esta taxonomia foi utilizada para classificar Problemas e Sistemas de Apoio à Decisão. No entanto, demonstrou-se perfeitamente adequada aos propósitos deste trabalho, ou seja, classificar problemas e Métodos de Tomada de Decisão. A taxonomia é apresentada na Tabela 6.1. Tabela 6.1. Taxonomia de Classificação de Problemas e Métodos Estrutura Espaço de Decisão Modelo de Preferência Foco Faixa Suporte Modelo de Crença 1. Completeza do Problema 2. Nível de Abstração 3. Determinismo 4. Funções Objetivas 5. Consistência 6. Base de Comparação 7. Dimensão 8. Completeza de Crença 9. Foco do Problema 10. Faixa de Independência 11. Nível de Suporte 101

123 Com base nessa taxonomia os problemas e os métodos acima listados podem ser classificados e, em seguida, os métodos adequados para utilização no problema em questão podem ser disponibilizados para o usuário do ambiente. Por exemplo, já foi realizada previamente a classificação de todos os métodos escolhidos para a utilização deste trabalho conforme a Tabela 6.2. A partir deste ponto, todas as situações-problema de cada fase dos processos Ambiente Taba também serão classificadas. Assim é possível identificar qual ou quais métodos são adequados para cada tipo de problema. Tabela 6.2. Classificação dos Métodos Métodos Características Completeza do Problema Nível de Abstração Determinismo Funções Objetivas Consistência Base de Comparação Dimensão Completeza de Crença Foco do Problema Faixa de Independência Nível de Suporte Valores Force Field Analysis Multivotação PMI Seis Chapéus Árvore de Decisão Matriz de Avaliação Análise da Decisão Comparação aos Pares MAUT Completo X X X X X X X X Incompleto X Quantitativo X X X X X X Qualitativo X X X X X X X Determinístico X X X X X X Probabilístico X X X X Ponto Ótimo X Julgamento X X X X X X X X Consistente X X X X Inconsistente X X X X X Absoluta X X X X X Relativa X X X X Confiança X X X X X X Conhecimento X X Ambos X X X Completa X X X X X X X X X Incompleta Processo X X X X X X Produto X X X X X X Independente X X X X X X X Dependente X X Interdependente X Representação X X Definição dos Resultados X X X X X Análise da Decisão X X 7. Perspectivas Futuras Após a definição dos três componentes básicos do ambiente, este trabalho terá continuidade com a construção do ambiente propriamente dito e sua disponibilização junto ao Ambiente Taba. 102

124 O objetivo final é gerar um corpo de conhecimento sólido com experiências reais e extrair informações relevantes no contexto de tomada de decisão em Engenharia de Software. Acredita-se que mantendo uma base centralizada de dados, meta-análises poderão ser realizadas e o conhecimento poderá ser gerado mais rapidamente dentro de uma empresa. Pretende-se, também, realizar pesquisas para uma melhor definição da similaridade entre casos, avaliando a definição de pesos para os fatores Contexto e Definição do Problema. 8. Conclusões Nesse artigo, foram descritos os três principais passos realizados para a proposta de construção de um ambiente de tomada de decisões em projetos de software. O primeiro passo envolveu a definição de um processo formal que pudesse ser aplicado a qualquer tipo de problema dentro do contexto da Engenharia de Software. O processo definido foi aplicado em situações reais, aprimorado e estabelecido como padrão em virtude da sua comprovada eficiência. O segundo passo foi buscar uma forma de armazenar e recuperar conhecimento de soluções de problemas anteriores. Após uma extensa revisão na literatura, adotou-se o Raciocínio Baseado em Conhecimento como a abordagem utilizada para realizar esta tarefa. Finalmente, era necessário fornecer ao usuário do ambiente um conjunto de métodos que auxiliasse na escolha da solução mais adequada. Dessa forma, um conjunto de métodos foi selecionado e classificado para que, dependendo da necessidade do usuário, o método adequado seja disponibilizado. 9. Agradecimentos Agradecemos à BL Informática e a Analia Irigoyen pela utilização do processo e valiosas sugestões. Agradecemos também ao Sávio Figueiredo, que possibilitou a avaliação prática inicial do processo com a ferramenta Techsolution, desenvolvida durante sua tese de mestrado [Figueiredo 2006]. 10. Referências Aamodt, A., Plaza, E., (1994), Case-Based Reasoning: Foundational Issues, Methodological Variations, and System Approaches, AI Communications, vol. 17, nr. 1. Aron, R., (1937), "La sociologie de Pareto", Zeitschrift für Sozialforschung. Bana e Costa, C.A. e Vansnick, J.C., (1995) A Theoretical Framework for Measuring Attractiveness by a Categorical Based Evaluation Technique (MACBETH). In Clímaco, J. Multicriteria Analysis. Berlin: Springer Verlag. Barros, M. O., (2001) Gerenciamento de Projetos Baseado em Cenários: uma Abordagem de Modelagem Dinâmica e Simulação, Tese de Doutorado, COPPE/UFRJ, Rio de Janeiro, RJ, Brasil. Bisio, R. and Malabocchia, F., (1995), Cost estimation of software projects through case base reasoning. 1st Intl. Conf. on Case-Based Reasoning Research & Development. pp11-22: Springer-Verlag. Carr, M. J., Konda, S.L, Monarch, I., Ulrich, F.C., Walker, C.F., (1993) Taxonomy- Based Risk Identification, Technical Report CMU/SEI 93-TR-6, Software Engineering Institute, Carnegie Mellon University, EUA, July. 103

125 Chrissis, M. B., Konrad, M., Shrum, S., (2006). CMMI: Guidelines for Process Integration and Product Improvement (2nd Edition). Addison-Wesley Professional. Clemen, R. T., and Reilly, T., (2004) Making Hard Decisions, Duxbury Thomson Learning, CA, United States. Collofello, J., Rus., I., Houston, D., Sycamore, D., Mith-Daniels, D., (1998), A system Dynamics Software Process Simulator for Staffing Policies Decision Support. In Proceedings of the 31st Annual Hawaii International Conference on Systems Sciences, pp , Kohala Coast, Estados Unidos. Costa, H. R., Barros, M., O., Travassos, G., H., (2004). Software Project Risk Evaluation Based on Specific and Systemic Risks. In Proceedings of the 16th International Conference of Software Engineering and Knowledge Engineering. Farias, L. L., (2002), Planejamento de Riscos em Ambientes de Desenvolvimento de Software Orientados à Organização, Dissertação de Mestrado, COPPE/UFRJ, Rio de Janeiro, RJ, Brasil. Fenton, N., Marsh, W.. Neil, M., Cates, P., Forey, S., Tailor, M., (2004), Making Resource Decisions for Software Projects. In Proceedings of the 26th International Conference on Software Engineering. Figueiredo, S. M. (2006). Apoio à Tomada de Decisão no Processo de Solução Técnica em Ambientes de Desenvolvimento de Software Orientados à Organização. Dissertação de Mestrado COPPE/UFRJ. Rio de Janeiro, Finnie, G. R., Wittig, G. E. and Desharnais, J. M., (1997), Estimating software development effort with case-based reasoning. 2nd Intl. Conf. on Case Based Reasoning. pp Gigerenzer, G., Selten, R., (2002), Bounded Rationality, the adaptive toolbox, MIT Press. Gomes, L. F. A. M.; Araya, M. C. G.; Carignano, C., (2004) Tomada de Decisões em Cenários Complexos. Ed. Thompson, SP. Hoffmann, H., (1997), A Decision Support System for Selection of Software Engineering Technologies Based on Models of their Application Domains, Fraunhofer IESE, Germany. ISO/IEC, (2003), The International Organization for Standardization and The International Electrotechnical Commission, ISO/IEC Software Process Assessment. ISO/IEC, (2004), The International Organization for Standardization and The International Electrotechnical Commission ISO/IEC Software life clycle processes Amendment 2. Jensen, F. V., (1996) An introduction to Bayesian Networks, UCL Press. Klein, G., Weitzenfeld, J., (1978) Improvements of skills for solving ill defined problems. Educational Psychologist 13: Klein, G., (1999), Sources of Power: How people make decisions, MIT Press, Massachussets, USA. 104

126 Lipshitz, R., Bar-Ilan, O., (1996), How problems are solved: Reconsidering the phase theorem. Organiaztional Behavior and Human Decision Process, 65, Meehan, B. and Richerdson, I., (2002), Identification of Software Process Knowledgement. Software Process Improvement and Praactice. Nonaka, I., (1994), A dynamic theory of Organizational Knowledge Creation. Organizations Science, vol. 5, p Ostertag, E., et al., (1992), Computing similarity in a reuse library system: an AIbased approach. ACM Transactions on Software Engineering Methodology 1(3): pp Raffo, D., Harrison, W., Vandeville, J., (2002), Software Process Decision Support: Making Process Tradeoffs Using Hybrid Metrics, Modeling and Utility Framework. In Proceedings of the SEKE 2002, pp , Ischia, Itália. Reitman, W. R., (1965), Cognition and Thought. New York: Wiley. Rodrigues, M. R., (2000), Desenvolvimento e Implementação de um Protótipo de Ferramenta para a Reutilização de Planos de Mensuração Utilizando Raciocino Baseada em Casos, Universidade Federal de Santa Catarina. Ruhe G., (2003), Guest Editor's Introduction, International Journal of Software Engineering and Knowledge Engineering Vol. 13, No. 5. Rus I., Ilalling M., and Biffl S., (2003), Supporting Decision Making in Software Engineering with Process Simulation and Empirical Studies. In Proceedings of the 4th Workshop on Learning Software Organizations, Chicago. Santos, G., Montoni, M., Rocha, A.R., Figueiredo, S., Mafra, S., Albuquerque, A., Diaz P., B., Amaral, M., (2005). Using a Software Development Environment with Knowledge Management to Support Deploying Software Processes in Small and Medium Size Companies, 7th Int. Workshop on Learning Software Organizations (LSO' 2005), Kaiserslautern, Alemanha, Apr. Schank, R. C., (1982), Dynamic Memory: A theory of reminding and learning in computers and people, Cambridge, UK: Cambridge University Press. SOFTEX, (2007), "MPS.BR Melhoria de Processo do Software Brasileiro, Guia de Implementação Parte 5 (v1.1)". In: Souza, M. P., (2002) Identificação de Características Relevantes para reutilização de experiências de desenvolvimento de software. Dissertação de Mestrado da UFSC Engenharia de Produção. Ullman, D. e D ambrosio B., (1995), A Taxonomy for Classifying Engineering Decision Problems and Support Systems, Artificial Intelligence for Engineering Design, Analysis, and Manufacturing, AI EDAM #9, pp Wangenheim, C. G., Wangenheim, A., Barcia, R. M., (1998), Case-Based Reuse of Software Engineering Measurement Plans. In Proceedings of the 10th Int. Conference on Software Engineering and Knowledge Engineering. Wildman, P. and Warner, J, (2003) The problem solving decision-making toolkit, HRD Press, Amherst, Massachusetts. 105

127 106

128 Estratégia para Apoiar a Seleção de Abordagens de Teste Baseado em Modelos para Projetos de Software Arilo Cláudio Dias Neto, Guilherme Horta Travassos Programa de Engenharia de Sistemas e Computação COPPE/UFRJ Caixa Postal Rio de Janeiro RJ Brasil. {acdn, ght}@cos.ufrj.br Abstract. Software technologies, such as model-based testing approaches, have specific characteristics and limitations that can affect their use in software projects. It is very important to make available knowledge regarding such technologies aiming at to support its applicability in software projects. In particular, a choice of model-based testing approach can influence testing success or failure. Therefore, this paper presents the knowledge acquired from some secondary and primary studies regarding model-based testing approaches and the proposal of a strategy towards supporting their selection for software projects. Resumo. Tecnologias de Software, tais como abordagens de teste baseado em modelos, possuem características e limitações específicas que afetam a sua utilização em projetos de software. É importante tornar disponível conhecimento sobre tais tecnologias para apoiar sua aplicabilidade em projetos de software. Em particular, a escolha de abordagem de teste baseado em modelos pode influenciar no sucesso ou fracasso dos testes. Portanto, neste artigo é apresentado o conhecimento adquirido a partir de estudos secundários e primários relacionados a abordagens de teste baseado em modelos e proposta uma estratégia visando apoiar a seleção dessas abordagens para projetos de software. 1. Introdução Teste Baseado em Modelos (TBM) consiste em uma técnica para geração automática de casos de teste usando modelos extraídos de artefatos de software (Dalal et al., 1999). De acordo com (El-Far e Whittaker, 2001), uma série de benefícios podem ser esperados com a utilização de TBM no processo de testes em uma organização de software, tais como: cronogramas mais curtos; menores custo e esforço; melhor qualidade; facilidade na comunicação entre as equipes de desenvolvimento e testes; simplificação na exposição de ambigüidades na especificação e projeto do software; capacidade de gerar e executar automaticamente muitos testes úteis e não repetitivos; facilidades na atualização do conjunto de casos de teste após mudanças nos requisitos e; capacidade para avaliar cenários de teste de regressão. De acordo com Dalal et al. (1999), a automação de uma Abordagem de Teste Baseado em Modelos (ATBM) depende de três elementos chaves: (i) o modelo usado para descrição do comportamento/estrutura do software, (ii) o algoritmo (critérios) de geração dos testes e (iii) ferramentas que provêm uma infra-estrutura de apoio para os testes. No entanto, outras características adicionais podem ser adicionadas a estas com o objetivo de melhorar o entendimento sobre uma ATBM e seu funcionamento, além de possibilitar uma melhor classificação e comparação entre as abordagens. Exemplos dessas características adicionais são: nível de teste avaliado por uma ATBM, nível de automação e complexidade dos passos não-automatizados. 107

129 Dias Neto et al. (2007a e 2007b) identificaram e caracterizaram cerca de 71 ATBM s disponíveis na literatura técnica a partir de uma Revisão Sistemática (Biolchini et al., 2005), analisando tais abordagens quantitativamente e qualitativamente e considerando diferentes cenários de abstração, tais como: o tipo de modelo usado para geração dos testes, o nível de teste que a abordagem está apta a ser aplicada, se a abordagem é aplicada para teste funcional ou estrutural, a existência de ferramentas de apoio, seus critérios de geração dos testes, dentre outras informações. Considerando os resultados descritos por Dias Neto et al.(2007a), observou-se que a maioria das abordagens não foi avaliada experimentalmente. Portanto, não foi possível identificar conhecimento/evidência suficiente a respeito da escalabilidade, desempenho, efetividade e complexidade de tais abordagens para serem aplicada na indústria. Dessa forma, a seleção de uma ATBM para um projeto de software torna-se uma tarefa complexa, de forma que escolhas não-adequadas podem invalidar ou tornar inviável os testes para um projeto de software (Dias Neto e Travassos, 2008). Baseado neste cenário, este artigo descreve um conjunto de resultados obtidos a partir de estudos secundários e primários conduzidos ao longo do desenvolvimento deste trabalho. Inicialmente é descrito um estudo secundário para caracterização das ATBM s disponíveis e são apresentados fatores de risco identificados na literatura técnica que podem influenciar na seleção e utilização de ATBM s em projetos de software. Em seguida são descritos os resultados preliminares de um survey cujo objetivo é identificar o grau de relevância dos diferentes atributos que caracterizam uma ATBM no momento da escolha de uma abordagem para um projeto de software, e por fim, é apresentada uma proposta de estratégia a ser apoiada por uma infra-estrutura computacional, descrita inicialmente de forma resumida em (Dias Neto e Travassos, 2008), para apoiar a seleção de ATBM s para projetos de software. O principal resultado esperado com este trabalho é fornecer mecanismos e informações a respeito das diferentes ATBM s disponíveis para uso em um projeto para que a equipe de teste possa estar provida de mais conhecimento no momento da realização de uma das tarefas mais complexas do processo de teste, a seleção de uma abordagem de teste para um projeto. Alguns trabalhos relacionados estão publicados na literatura técnica descrevendo mecanismos de apoio à seleção de técnicas de teste (ou outros tipos de técnicas) para um projeto de software. Por exemplo, em (Vegas e Basili, 2005) é descrito um mecanismo para apoiar a seleção de técnicas de teste a partir de um esquema de caracterização. Os atributos das técnicas de teste são armazenados em um repositório, e para cada projeto de software um catálogo é gerado. Os aspectos positivos da proposta de Vegas e Basili (2005) são tornar conhecimento disponível e simplificar a escolha de uma técnica de teste de propósito geral para projetos de software. No entanto, a generalidade de seus atributos torna difícil a sua customização para técnicas baseadas em modelos, o que pode representar um risco para um projeto. Em um outro trabalho (Juristo et al., 2004) é descrito um estudo experimental indicando diferenças e similaridades entre técnicas de teste. Apesar de seu propósito não ser apoiar a seleção de técnicas de teste, testadores podem usar este conhecimento para apoiar esta tarefa. Outros trabalhos similares descrevem a caracterização/seleção de métodos, técnicas e ferramentas relacionadas ao desenvolvimento de software [ex: (Birk, 1997) caracterização de tecnologias de software, (Maiden e Rugg, 1996) seleção de técnicas de identificação de requisitos]. Apesar da importância desses trabalhos, na literatura técnica não foi encontrada a definição de alguma estratégia ou infra-estrutura para seleção de ATBM s para projetos. Este artigo está organizado da seguinte forma: Na seção 2 é descrita uma 108

130 caracterização da área de TBM a partir de seus conceitos, uma revisão sistemática sobre ATBM s e uma análise de fatores de risco que podem influenciar a utilização de ATBM s em projetos de software. Na seção 3 é apresentada a proposta de estratégia de apoio à seleção de ATBM s para projetos de software. Finalmente, na seção 4 são discutidas as conclusões e trabalhos futuros. 2. Caracterização da Área de Teste Baseado em Modelos 2.1. Definição de Teste Baseado em Modelos De acordo com Myers (1979), o principal fator que influencia o custo associado à atividade de teste é o número total de casos de teste. Para cada caso de teste, é necessário alocar recursos para planejar, projetar e executá-lo. Portanto, a automação da geração e execução dos casos de teste pode ser um mecanismo interessante para reduzir o custo e esforço dessa atividade. Neste contexto, Teste Baseado em Modelos surge como uma abordagem viável para controlar a qualidade do software reduzindo o custo e esforço associado a algumas atividades do processo de teste, visto que os casos de teste são gerados a partir de artefatos (modelos) construídos ao longo do processo de desenvolvimento de software. Uma ATBM segue, normalmente, os seguintes passos: Construção do modelo de software; Geração dos Casos de Teste; o Geração das entradas necessárias; o Geração dos resultados esperados; Execução dos Testes; Comparação entre os resultados obtidos e os resultados esperados; Decisão a respeito das futuras ações (se modificar o modelo de software, gerar mais casos de teste, parar os testes ou estimar a confiabilidade [qualidade] do software); Uma estratégia de teste baseado em modelos normalmente inclui diferentes níveis de abstração, um modelo descrevendo o comportamento/estrutura do software, um relacionamento entre modelos e código fonte, tecnologia de geração dos casos de teste, a importância dos critérios de geração dos testes e uma discussão sobre o quê pode ou não ser automatizado durante os testes (Pretschner, 2005). Esses diferentes atributos tornam a identificação e caracterização de ATBM s uma atividade importante, conforme descrito na seção seguinte Revisão Sistemática sobre Abordagens de Teste Baseado em Modelos Em (Dias Neto et al., 2007a; Dias Neto et al., 2007b) é descrita uma Revisão Sistemática (estudo secundário) com o propósito de identificar, caracterizar e analisar quantitativamente e qualitativamente ATBM s publicadas na literatura técnica. No total, 406 artigos foram encontrados. Após a leitura dos artigos, este conjunto foi reduzido para 202 artigos descrevendo ATBM s. Atualmente, a análise dos dados tem sido direcionada para 85 artigos que descrevem 71 ATBM s e que foram selecionados a partir de critérios previamente definidos, tais como o número de citações, ano de publicação e nível de teste. A lista completa com todos os artigos identificados e os critérios usados para seleção/rejeição deles está disponível em (Dias Neto et al., 2007a). Para apoiar a caracterização de ATBM s, catorze atributos identificados a partir 109

131 de uma revisão informal de literatura, principalmente a partir de (Dalal et al., 1999), (Pretschner, 2005) e (Utting et al., 2006), foram usados para extrair informações a respeito dos artigos selecionados: (1) Modelo Comportamental/Estrutural do Software; (2) Nível de Teste; (3) Ferramentas de Apoio; (4) Domínio do Software; (5) Critérios de Cobertura dos Testes; (6) Critério de Geração dos Testes; (7) Nível de Automação; (8) Nível de Complexidade dos Passos Não-Automatizados; (9) Tecnologia de Geração dos Testes; (10) Tipo de Técnica de Teste (Funcional ou Estrutural); (11) Característica de Qualidade de Software que a abordagem possibilita avaliar; (12) Saídas geradas pela abordagem; (13) Entradas requeridas pela abordagem; (14) Limitações/Restrições para usar a abordagem. Uma descrição detalhada sobre cada atributo pode ser obtida em (Dias Neto et al., 2007b). Baseado nos atributos descritos anteriormente, uma análise quantitativa foi realizada possibilitando observar as seguintes características: 63% das ATBM s são aplicadas no nível de Teste de Sistema; Os passos não-automatizados estão associados à construção/transformação do modelo ou seleção dos critérios de geração dos testes. Diagramas UML, Máquinas de Estado Finito e Grafos de Fluxo de Eventos são os modelos que têm sido usados por um grande número de abordagens (mais de 70%). A maioria das ATBM s possui uma ferramenta de apoio disponível (60%). No entanto, elas são normalmente protótipos e não representam produtos prontos para serem comercializados. 54% das ATBM s usam modelos intermediários para reduzir o escopo e a complexidade do problema antes da geração dos casos de teste. Em outra perspectiva, os resultados obtidos a partir de uma análise qualitativa descreveram uma discussão individual e subjetiva a respeito das abordagens selecionadas, tais como: limitações, indicações de custo, esforço, nível de complexidade, entradas requeridas, pré-requisitos, formato e qualidade das saídas geradas e habilidade necessária para usar uma abordagem. As informações descritas nesta seção possuem a intenção apenas de justificar as razões a respeito da pesquisa que está sendo conduzida e que será descrita ao longo deste artigo. Para aqueles que se interessarem em maiores detalhes a respeito dos resultados da revisão sistemática realizada, isso pode ser obtido em (Dias Neto et al., 2007a; Dias Neto et al., 2007b) Fatores de Risco que influenciam o uso de Abordagens de Teste Baseado em Modelos em Projetos de Software Uma ATBM normalmente é desenvolvida para ser aplicada exclusivamente nas atividades de teste em um projeto de software específico, e normalmente suas avaliações descritas nos artigos são realizadas para exemplos simples e direcionados a um cenário. No entanto, em projetos reais, a atividade de teste é apenas uma das atividades a serem realizadas ao longo do processo de desenvolvimento de um software. Além disso, teste, como todas as demais atividades, deve atender às restrições impostas pelo planejamento do projeto, tais como tecnologia, cronograma, orçamento e recursos. Dado esse cenário, foi iniciado um mapeamento a partir da literatura técnica de um conjunto de fatores de riscos que podem influenciar a utilização de uma ATBM em projetos de software. Para isso, doze fatores de risco puderam ser identificados (Tabela 1). Alguns fatores são exclusivos do uso de abordagens de teste baseado em modelos e 110

132 outros são aplicados ao processo de teste, independente do tipo de técnica adotada. Independentemente disso, esses fatores indicam cenários incluídos no processo de testes que não fazem parte do escopo de uma ATBM, mas que precisam ser gerenciados pois podem tornar inviáveis os testes gerados para um projeto de software. Tabela 1. Fatores de Risco que afetariam a utilização de ATBM's em projetos Id Fator de Risco Descrição Garantia da qualidade dos 1 artefatos usados por uma ATBM para geração de testes Mecanismo eficiente para disponibilizar os artefatos de software usados como entrada para as ATBM s Estratégia para alocação de recursos (humanos e físicos) e planejamento do cronograma dos testes Estratégia para seleção de ATBM s para um projeto Estratégia adotada para construção do modelo comportamental/estrutural do software Estratégia adotada para a escolha dos critérios de geração/cobertura dos testes Rastreamento e análise de impacto de mudanças na especificação do software Atualização dos casos de teste após mudanças na especificação do software Inclusão manual de casos de 9 teste extras Controle do processo de 10 geração e execução dos testes Rastreamento de falhas reveladas pelas ATBM s Avaliação de ATBM s e seus critérios de geração dos testes O sucesso dos testes está diretamente associado à qualidade dos artefatos recebidos como entrada para construção do modelo comportamental/estrutural a ser usado para geração dos testes. A equipe de teste deve ter acesso constante às versões correntes dos artefatos usados por uma ATBM. A habilidade e grau de complexidade requerido para usar cada ATBM são diferentes. Eles impactam diretamente na seleção da equipe de teste e definição do orçamento e cronograma dos testes em um projeto de software. Diferentes atributos devem ser observados no momento da seleção de ATBM s a serem usadas em projetos de software, tais como: cobertura dos testes desejada ou as características de qualidade do produto que precisam ser avaliadas. ATBM s não consideram as variáveis a respeito do custo, esforço ou estratégia de construção dos modelos de software usados para geração dos testes. Estes modelos são os principais requisitos para se usar uma ATBM. A escolha de qual critério de geração do testes usar em um software ou em um módulo específico do software deve ser baseada no esforço ou custo para construção e execução dos casos de testes, o número total de casos de teste gerados e, principalmente, do nível de cobertura dos testes desejado. É necessário analisar quais mudanças ocorreram na especificação do software e quais são os seus impactos no conjunto de casos de teste já gerados para um software antes que um novo modelo seja construído para re-gerar os testes. ATBM s não indicam como atualizar seus modelos, qual o esforço e custo, ou a viabilidade para realizar esta tarefa. Elas normalmente consideram que um novo modelo já está criado para re-gerar casos de testes, não provendo informações essenciais para o controle do processo de teste. Eventualmente, pode ser necessário incluir casos de teste para avaliar funcionalidades ou características do software não cobertas por uma ATBM. A equipe de teste deve sempre ser provida com informações a respeito do estágio atual do processo de testes. O rastreamento de falhas apóia o controle dos testes e futuras avaliações das ATBM s e seus critérios de seleção dos testes, associando falhas aos casos de teste responsáveis pela sua identificação. A avaliação de ATBM s e seus critérios de seleção dos testes pode tornar mais simples e mais precisa as estimativas de custo e esforço e também apoiar a seleção de ATBM s para projetos de software. Após a caracterização das ATBM s e a identificação de um conjunto de fatores de risco que podem influenciar sua utilização em projetos de software, pensou-se em mecanismos para mitigar tais riscos. A próxima seção irá discutir e apresentar a estratégia adotada para o desenvolvimento desses mecanismos visando ao desenvolvimento de uma estratégia para apoiar a seleção de ATBM s para serem aplicadas em projetos de software. 3. Estratégia para Construção de um Mecanismo de Apoio à Seleção de 111

133 Abordagens de Teste Baseado em Modelos para Projetos de Software Como observado nas seções anteriores, existem diversas ATBM s com diferentes características disponíveis para uso em projetos de software. A seleção de qual delas aplicar de acordo com as características específicas do projeto de software deve ser realizada cuidadosamente e a partir de critérios bem definidos. Escolhas inadequadas podem aumentar significativamente a complexidade, esforço e custo para utilizar uma ATBM, e pode ainda tornar inviável os testes gerados por uma abordagem não adaptável ao projeto em questão. As próximas subseções irão apresentar a estratégia definida visando ao desenvolvimento de uma estratégia, cuja proposta foi apresentada inicialmente de forma simplifica em (Dias Neto e Travassos, 2008), definida para apoiar a tarefa de seleção de ATBM s para projetos de software Corpo de Conhecimento sobre Abordagens de Teste Baseado em Modelos O primeiro passo visando ao desenvolvimento da estratégia proposta consiste em conhecer quais ATBM s estão disponíveis e respectivamente quais são suas principais características. Isso possibilitará a criação de um corpo de conhecimento a respeito de ATBM s. A existência de um corpo de conhecimento pode simplificar a análise sobre qual abordagem é mais adequada para um projeto de software com certas características. Atualmente este corpo de conhecimento é representado pelos 202 artigos publicados na literatura técnica e capturados através da revisão sistemática descrita em (Dias Neto et al., 2007a). Ele tem sido organizado e estruturado por meio de um banco de dados da ferramenta JabRef 1, contendo todos os atributos relevantes (seção 2.2) preenchidos com informações extraídas a partir dos artigos originais. Alguns atributos representam categorias com valores pré-definidos a fim de apoiar a classificação, agrupamento e consequentemente localização de ATBM s (ex: o nível de testes). Outros terão seus conteúdos livres possibilitando uma caracterização individual de tais abordagens (ex: restrições ou limitações). Após a estruturação e instanciação do corpo de conhecimento, foi identificada uma funcionalidade adicional que deveria compô-lo. Observou-se que cada atributo caracterizando uma ATBM pode ter um nível de relevância diferenciado no momento da seleção de uma ATBM para um projeto de software. Assim, pesos devem ser associados a cada atributo quando estiver sendo realizada a tarefa de seleção de uma abordagem. No entanto, a definição dos pesos não pode ser feita aleatoriamente ou sem qualquer critério. Com isso, um survey foi planejado e tem sido executado visando à identificação dos níveis de relevância de cada atributo de caracterização no momento da seleção de uma ATBM para um projeto de software. A próxima subseção descreverá este survey com maiores detalhes Survey sobre Atributos de Abordagens de Teste Baseado em Modelos O objetivo deste estudo primário é analisar um conjunto de atributos que descrevem ATBM s extraídos da literatura técnica, e apresentados na seção 2.2, com respeito à sua relevância no contexto de apoio à seleção de ATBM s para projetos de software no ponto de vista de pesquisadores ao redor do mundo trabalhando com pesquisa e desenvolvimento de soluções em TBM. E suas questões de pesquisa são:

134 Os atributos extraídos da literatura técnica (e apresentados na seção 2.2) são importantes (ou não importantes) para caracterizar uma ATBM? Existe qualquer atributo adicional considerado importante para caracterizar ATBM s que não está apresentado no conjunto inicial? Qual a ordem de relevância dos atributos de ATBM s que compõem o conjunto final de atributos no momento da seleção de uma abordagem para projetos de software? Este survey já passou pelas fases de planejamento e execução 2. O questionário foi elaborado no idioma Inglês e ficou disponível na Internet no período de 10/12/2007 a 10/02/2008. Os participantes do estudo foram contatados por (ao total cerca de 100 pesquisadores identificados dentre os autores que compõem o corpo de conhecimento sobre ATBM foram convidados), onde receberam um login e senha de acesso, evitando participantes não planejados e conseqüentemente a introdução de viés nos resultados. O preenchimento do questionário é seguido em três passos: 1. Caracterização do conhecimento e habilidades dos participantes (Figura 1). Neste passo os participantes são questionados sobre seus dados pessoais (nome, , afiliação e país), nível de formação acadêmica, número de artigos publicados sobre TBM e nível de experiência em TBM na indústria; Figura 1. Tela de Caracterização e Autorização do Participante 2. Identificação dos atributos importantes ou não importantes para caracterizar uma ATBM (Figura 2). Para cada atributo, o participante deve preencher se ele é ou não importante para a caracterização de uma ATBM, ou seja, se ele deve compor o corpo de conhecimento sobre ATBM s. Além disso, o participante pode inserir 5 atributos adicionais que ele considere importante e que não estão incluídos no 2 O plano do estudo pode ser obtido com os autores do trabalho. 113

135 conjunto inicial; Figura 2. Tela de Identificação dos atributos importantes para caracterizar uma ATBM 3. Definição do nível de relevância de cada atributo de ATBM quando apoiando a seleção de uma abordagem para um projeto de software (Figura 3). Neste passo, apenas os atributos indicados pelo participante como importante no PASSO 2 são avaliados. Seis níveis de relevância foram definidos: (0) Sem relevância; (1) Muito Baixa Relevância; (2) Baixa Relevância; (3) Média Relevância; (4) Alta Relevância; (5) Muito Alta Relevância. Figura 3. Tela de Definição do Nível de Relevância para a Seleção de ATBM s Para a análise dos dados, cada participante deve possuir um peso diferenciado de acordo com seu nível de conhecimento e habilidade. Pesquisadores com níveis maiores de experiência ou habilidade devem possuir no estudo um peso maior. Após a definição 114

136 dos pesos, as respostas de todos os participantes devem ser analisadas para cada atributo de ATBM avaliado, e ao final a ordem de relevância dos atributos será obtida. Até o momento da escrita deste artigo, 34 pesquisadores responderam ao survey. Alguns resultados preliminares já foram obtidos considerando os dados já disponíveis. No entanto, eventualmente esses resultados podem mudar quando novos participantes inserirem suas respostas. Assim, a fase de coleção dos dados precisa ser finalizada para que a fase de análise possa iniciar efetivamente. Como resultado preliminar, a Tabela 2 apresenta a ordem dos atributos avaliados a partir dos dados coletados até o momento em relação à sua importância para caracterização de uma ATBM e em relação ao grau de relevância no momento da seleção de uma abordagem para um projeto. As setas na terceira coluna da Tabela 2 indicam uma variação (ou não) da ordem do atributo na classificação por grau de relevância em relação à sua classificação pelo grau de importância. Observa-se que os resultados tendem, inicialmente, a confirmar a importância de todos os atributos avaliados para caracterização de uma ATBM (mesmo aqueles não descritos com tanta intensidade nos artigos que descrevem tais abordagens, tais como: avaliação experimental ou grau de complexidade para usar uma ATBM). Além disso, os atributos com maior grau de relevância no momento da seleção de uma ATBM para um projeto de software são aqueles relacionados aos requisitos básicos para se utilizar uma abordagem, tais como modelo estrutural/comportamental, critérios de geração/cobertura dos testes e restrições/limitações para se usar uma abordagem. Tabela 2. Resultados Iniciais obtidos no Survey Atributos de ATBM s Ordem por grau Ordem por Grau de Importância de Relevância Modelo Comportamental/Estrutural 1 1 Critério de Geração de Casos de Teste 2 3 Critério de Cobertura dos Testes 3 2 Entradas requeridas para usar uma abordagem 4 4 Limitações/Restrições para usar uma abordagem 5 5 Característica de Qualidade de Software que a abordagem está apta a avaliar 6 9 Nível de Teste 7 8 Tipo de Técnica de Teste (Funcional ou Estrutural) 8 6 Domínio de Software 9 11 Resultados gerados pela abordagem 10 7 Ferramenta de Apoio Resultados Históricos Uso de Modelos Intermediários Tecnologia de Geração dos Testes Nível de Complexidade dos Passos Não-automatizados Avaliação Experimental Necessidade de Ferramentas Externas Proporção de Passos Automatizados Apesar de ter sido apresentada a ordem dos atributos, o resultado relevante a ser obtido com este survey é o peso (grau de relevância valor entre 0% e 100%) de cada atributo no momento da seleção de uma ATBM para um projeto de software. Após definidos, esses valores irão compor o corpo de conhecimento sobre ATBM s descrito na seção 3.1. Consequentemente, eles poderão apoiar o desenvolvimento de um 115

137 mecanismo que indique abordagens mais adequadas a um projeto de software, dadas suas características, como será apresentado na próxima subseção Infra-estrutura de Apoio à Indicação/Seleção de ATBM s adequadas a Projetos de Software Na infra-estrutura proposta, a seleção de ATBM s para um projeto de software será baseada em algumas etapas (ver Figura 4). Esta seção apresenta os requisitos que compõem a infra-estrutura, indicando como eles têm sido desenvolvidos. Caracterização do projeto de software Obtenção do grau de adequação de ATBM s para um projeto Seleção de ATBM s Avaliação das ATBM s aplicadas ao final projeto Figura 4. Etapas que compõem a Infra-estrutura de Apoio à seleção de ATBM s Caracterização de Projetos de Software A primeira etapa que compõe a infra-estrutura de apoio à seleção de ATBM s consiste em conhecer as principais características do projeto no qual uma ATBM precisa ser aplicada. A estratégia adotada para caracterização de um projeto de software neste trabalho consiste na definição de algumas informações/atributos a respeito de um projeto de software e que foram extraídas, principalmente, da funcionalidade responsável pela caracterização de projetos de software definida na ferramenta ADAPTPRO (Berger, 2003) que compõe a Estação TABA, e evoluídas a partir dos resultados do survey realizado. As informações utilizadas na versão inicial da infra-estrutura apresentada para caracterização de um projeto de software são: plataforma de execução, paradigma ou linguagem de desenvolvimento, domínio da aplicação, modelo de ciclo de vida adotado, duração estimada do projeto, formato dos requisitos de software, características de qualidade que precisam ser avaliadas, tecnologia usada para modelagem do software, tamanho do projeto, complexidade do problema. No entanto, essa lista de características pode evoluir ao longo desta pesquisa e pode ainda sofrer variações de acordo com o tipo ou domínio da aplicação a ser desenvolvida no projeto. Esta caracterização será usada para indicar ATBM s incluídas no corpo de conhecimento que são mais adequadas às características do projeto em questão Obtenção do Nível de Adequação e Indicadores para a Seleção de ATBM s A escolha de uma ATBM para um projeto de software não pode ser realizada automaticamente, ou seja, sem a confirmação de um membro da equipe de teste, pois aspectos externos ou não-técnicos que eventualmente não são passíveis de automação podem afetar esta escolha. Portanto, a infra-estrutura proposta neste trabalho apresenta como funcionalidade a indicação de diferentes opções de ATBM s mais adequadas para um projeto a partir do cálculo de um nível de adequação de cada ATBM para o projeto de software em questão. Este nível de adequação é calculado pela infra-estrutura para cada ATBM incluída no corpo de conhecimento. Para isso, está sendo utilizado o conceito matemático de distância euclidiana (Boldrini et al., 1980), que foi adotado por Xavier et al. (2002) para apoiar a seleção de padrões arquiteturais em projetos de software. Segundo Xavier et al. (2002), este mecanismo de busca explora a possibilidade de avaliação de distâncias conceituais a partir da comparação de elementos em um espaço vetorial multidimensional. A noção de distância conceitual é realizada, 116

138 matematicamente, pela norma da diferença entre dois vetores v1 e v2. Neste trabalho, os vetores são representados pelas características do projeto (v1) e características de cada ATBM (v2). A distância entre eles indica o grau de adequação de uma ATBM para o projeto de software. Quantos mais próximos eles estiverem, mais adequada ao projeto é tal abordagem (grau de adequação = [1-distância]*100) (ver exemplo da Figura 5). v1: características de um projeto de software v2: características de uma ATBM Cálculo da Distância Vetorial: d( v y 2 2 1, v2 ) = ( x1 x2 ) + ( y1 2 ) Figura 5. Distância entre vetores e exemplo do cálculo da distância entre eles Após o cálculo da distância das características de cada abordagem em relação às características do projeto, a infra-estrutura ordena as abordagens e exibe aquelas com os níveis de adequação mais altos agrupadas por nível de teste (o número de ATBM s sugeridas pela infra-estrutura é definido como parâmetro). Além do nível de adequação calculado para cada abordagem, a infra-estrutura provê ainda informações a respeito de como o nível de adequação de uma ATBM para um projeto foi obtido a partir do cruzamento das características do projeto com as características da ATBM selecionada. A Tabela 3 exibe um exemplo de tela de detalhamento de nível de adequação. Tabela 3. Exemplo de Tela de Detalhamento de Nível de Adequação Características do Projeto Valores Nível de Adequação Plataforma de Execução Web Paradigma de Desenvolvimento Linguagem de Programação Exemplo Características do Projeto: as características do projeto são transformadas em valores e devem ser multiplicadas pelos pesos associados a cada atributo de caracterização para se obter o vetor normalizado associado às características do projeto. Exemplo: Pr oj = (0,8;0,9) Abordagens: as características das abordagens também são transformadas em número, que devem ser multiplicados pelos pesos de cada atributo para se obter o vetor associado à ATBM. Exemplo: ATBM 1 = (0,6;0,95) e ATBM 2 = (0,8;0,6) Distância de Projeto para a Abordagem 1: d (Pr oj X 2 2, ATBM 1) = (0,8 0,6) + (0,9 0,95) = 0, OO Java X 80% de adequação Distância de Projeto para a Abordagem 2: 2 2 d(pr oj X, ATBM 2 ) = (0,8 0,95) + (0,9 0,6) = 0,33 67% de adequação Assim, as características da abordagem 1 estão mais próximas das características do projeto que a abordagem 2. Porém, a decisão de qual usar deve ainda ser da equipe de teste. 10% 20% 30% 40% 50% 60% 70% 80% 90% 100 % 10% 20% 30% 40% 50% 60% 70% 80% 90% 100 % 10% 20% 30% 40% 50% 60% 70% 80% 90% 100 %

139 Modelo de Ciclo de Vida Duração Estimada do Projeto Incremental 4 meses 10% 20% 30% 40% 50% 60% 70% 80% 90% 100 % 10% 20% 30% 40% 50% 60% 70% 80% 90% 100 % 10% 20% 30% 40% 50% 60% 70% 80% 90% 100 Formato dos Requisitos do Software % Textual (Funcional e Não-funcional) 10% 20% 30% 40% 50% 60% 70% 80% 90% 100 Características de Qualidade do Software a Funcionalidade % serem avaliadas Segurança 10% 20% 30% 40% 50% 60% 70% 80% 90% 100 Tecnologia usada para modelagem do software UML % Complexidade do Problema Alta 10% 20% 30% 40% 50% 60% 70% 80% 90% 100 % Freqüência de Mudança dos Requisitos Alta 10% 20% 30% 40% 50% 60% 70% 80% 90% 100 % Tamanho da Aplicação Médio 10% 20% 30% 40% 50% 60% 70% 80% 90% 100 % Recursos Humanos disponíveis para o projeto Baixo 10% 20% 30% 40% 50% 60% 70% 80% 90% 100 % Tempo disponível para o projeto Baixo 10% 20% 30% 40% 50% 60% 70% 80% 90% 100 % Seleção/Combinação de Abordagens de Teste Baseado em Modelos A partir do cálculo dos níveis de adequação de ATBM s ao projeto de software, a equipe de teste poderá optar pela seleção de uma ou mais abordagens para serem aplicadas no projeto. Cada ATBM pode ser apta a cobrir uma característica específica do software para um certo domínio de aplicação, e cada uma requer um determinado nível de esforço e custo para ser aplicada em um projeto de software. No entanto, quando mais que uma abordagem é selecionada, a equipe de teste precisa ser apoiada por informações a respeito da cobertura ou nível de adequação, esforço/custo e o nível de recursos necessário para utilizar as abordagens selecionadas de forma combinada. A infra-estrutura apresentada neste trabalho fornece tais informações combinando as características individuais das abordagens selecionadas com as características do projeto de software. No momento da seleção das abordagens, esses indicadores podem ser visualizados através de um gráfico do tipo speedometer. Esta escolha de gráfico ocorreu por este tipo de gráfico visualizar facilmente diferentes faixas de valores representando categorias que são separadas por limites pré-estabelecidos. O marcador do velocímetro indica quanto o valor obtido atualmente está posicionado em relação a uma Figura 6. Exemplo de gráfico indicando custo e cobertura dos testes para uma certa combinação de ATBM s 118 meta definida. Por exemplo, a Figura 6 apresenta um exemplo demonstrativo do uso deste gráfico no contexto deste trabalho Medição e Avaliação de Abordagens de Teste Baseado em Modelos O corpo de conhecimento a respeito de ATBM s deve ser atualizado constantemente. Assim, a infra-estrutura apresentada provê um mecanismo de apoio à avaliação de uma ATBM s e seus critérios de geração dos testes ao final de cada projeto de software. Neste momento, dois tipos de informações são obtidos: métricas são coletadas

140 automaticamente do processo de testes (ex.: número de casos de teste gerados por cada critério de geração dos testes, esforço para construção dos modelos, número de incidentes de teste por caso de teste, dentre outros), além dessas informações, existe um questionário ao final de cada processo de teste a ser preenchido pela equipe de teste com itens a respeito da adequação das abordagens utilizadas de acordo com as características do projeto onde elas foram aplicadas. A presença deste mecanismo de avaliação das ATBM s ao final do projeto permite que as informações contidas no corpo de conhecimento sobre ATBM s que compõem a infra-estrutura apresentada estejam sempre atualizadas, de forma que os indicadores apresentados por ela sejam sempre confiáveis para a equipe de teste. A Figura 7 exibe um extrato exemplificando a tela de avaliação de ATBM, separando claramente as informações obtidas automaticamente do processo de testes daquelas a serem preenchidas pela equipe de testes. Os dados apresentados são apenas ilustrativos. Medidas coletadas automaticamente do processo de testes Avaliação a respeito dos Critérios de Geração dos Testes Medidas - Todos os caminhos 95% de cobertura dos testes Número de Casos de Teste 156 casos de teste Número de Incidentes de Teste 46 incidentes de teste - Fluxos Principais 88% de cobertura dos testes Número de Casos de Teste 143 casos de teste Número de Incidentes de Teste 30 incidentes de teste Avaliação a respeito do Modelo Comportamental/Estrutural Medidas Número de Casos de Uso 15 casos de uso Número de Modelos construídos 8 modelos Esforço para construir os modelos 100 horas Avaliação a respeito dos Testes de Regressão Medidas Número de Modelos atualizados 5 modelos Esforço para atualizar os modelos 45 horas Informações sobre adequabilidade da ATBM ao projeto a serem preenchidas pela equipe de teste Avaliação Características Valores (preenchida por um membro) 10% 20% 30% 40% 50% 60% 70% 80% 90% 100% Plataforma de Execução Web Paradigma de Desenvolvimento Linguagem de Programação Domínio de Aplicação Modelo de ciclo de vida Duração Estimada do Projeto Formato dos Requisitos do Software (Funcional e Não-funcional) Características de Qualidade do Software a serem avaliadas Características de Qualidade do Software a serem avaliadas Tecnologia usada para Modelagem do Software 119 OO Java Financeiro Incremental 4 meses Textual Funcionalidade Segurança UML Figura 7. Exemplo de Tela de Avaliação de ATBM 10% 20% 30% 40% 50% 60% 70% 80% 90% 100% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100% Um protótipo (ferramenta computacional) para apoiar a estratégia descrita neste trabalho já está definido. Esta infra-estrutura está sendo desenvolvida sobre a plataforma PHP+MySQL como uma extensão da infra-estrutura de apoio ao planejamento e controle de teste de software, Maraká (Dias Neto e Travassos, 2006).

141 No entanto, apesar das facilidades providas por um apoio ferramental, a parte essencial que compõe esta pesquisa é o conteúdo provido pela estratégia proposta, ou seja, o conhecimento científico sobre ATBM s a ser disponibilizado a fim de simplificar a implantação deste tipo de técnica de teste em organizações de software. Sendo assim, a continuidade desta pesquisa será direcionada para a avaliação experimental da infraestrutura apresentada neste artigo em relação ao conhecimento científico contido no seu corpo de conhecimento e aos indicadores providos por ela como mecanismo de apoio à seleção de ATBM s para projetos de software. 4. Conclusões e Trabalhos Futuros Este artigo apresentou uma estratégia que apóia a seleção de ATBM s para projetos de software. A principal característica associada a este trabalho é que este tem sido desenvolvido utilizando conhecimento e resultados obtidos adotando uma metodologia científica baseada em estudos experimentais, primários e secundários. Algumas contribuições resultantes deste trabalho podem ser observadas para a área de Teste Baseado em Modelos: A descrição dos resultados obtidos a respeito da caracterização de ATBM s disponíveis na literatura técnica realizada a partir de uma revisão sistemática, aliado aos resultados um survey realizado com pesquisadores da área de TBM que possibilitou a definição e ordenação dos atributos de caracterização de uma ATBM no momento da seleção de uma abordagem para um projeto de software. Estes resultados propiciaram a definição e construção de um corpo de conhecimento sobre ATBM s representado por meio de um banco de dados de uma ferramenta de gerência de referências bibliográficas estendida para possibilitar a caracterização de abordagens de teste baseado em modelos. A identificação e contextualização de fatores de risco que podem influenciar na utilização de ATBM s para projeto de software, uma vez que essas abordagens normalmente são desenvolvidas e avaliadas para cenários restritos e que consistem em simplificações de cenários reais presentes em projetos. A partir da identificação de tais fatores de risco, definiram-se mecanismos para mitigar seus impactos em um projeto de software, o que resultou na elaboração de uma estratégia para apoiar a seleção de ATBM s para projetos de software, que foi apresentada neste trabalho a partir dos requisitos e funcionalidades que a compõem. Com a elaboração da estratégia proposta, o passo seguinte desta pesquisa será direcionado à obtenção e avaliação de conhecimento científico sobre ATBM s, a fim de viabilizar a implantação e avaliação da estratégia apresentada em organizações de software através do fornecimento adequado de informações que auxiliem a equipe de teste na seleção de ATBM s para um projeto de software. Este conhecimento já vem sendo obtido ao longo do desenvolvimento deste trabalho (através dos resultados da revisão sistemática citada na seção 2.2 aliados aos resultados do survey descrito na seção 3.2, que formam a versão inicial do corpo de conhecimento sobre ATBM s), e precisa ser constantemente evoluído. 5. Agradecimentos Os autores agradecem ao CNPq, FAPERJ, FAPEAM e SCR pelo apoio financeiro fornecido para a realização deste trabalho. Agradecemos especialmente a Marlon Vieira e Rajesh 120

142 Subramanyan (SCR Siemens Corporate Research) pela sua contribuição para a realização da Revisão Sistemática sobre TBM. 6. Referências Berger, P. (2003), Instanciação de Processos de Software em Ambientes Configurados na Estação TABA, Dissertação de Mestrado COPPE/UFRJ. Rio de Janeiro. Bernard, E.; Legeard, B.; Luck, X.; Peureux, F. (2004), Generation of test sequences from formal specifications: GSM standard case-study, SW Practice and Experience 34 (10), pp Biolchini, J.; Mian, P.G.; Natali, A.C.; & Travassos, G.H. (2005), Systematic Review in Software Engineering: Relevance and Utility, Relatório Técnico ES-679/05, PESC- COPPE/UFRJ. Disponível em Birk, A. (1997), Modelling the application domains of software engineering technologies, Proceedings of the Twelfth International Conference on Automated Software Engineering (ASE). Lake Tahoe, CA, Novembro. Blackburn, M.; Busser, R.; Nauman, A. (2004), Why Model-Based Test Automation is Different and What You Should Know to Get Started. In: International Conference on Practical Software Quality and Testing, PSQT/PSTT'2004 East., Washington D.C., USA. Boldrini, J. L.; Costa, S. R.; Figueiredo, V. L., et al. (1980), Álgebra Linear, 3 ed., capítulo 8, Harper & Row do Brasil. Dalal, S.; Jain, A.; Karunanithi, N.; Leaton, J. M.; Lott, C. M.; Patton, G. C.; Horowitz, B. M. (1999), Model-based testing in practice, In: ICSE 99, Maio, pp Dias Neto, A. C., Travassos, G.H. (2006) Maraká: Uma Infra-estrutura Computacional para Apoiar o Planejamento e Controle de Testes de Software, In: 5º Simpósio Brasileiro de Qualidade de Software (SBQS), pp , Vila Velha, ES. Dias Neto, A.C.; Subramanyan, R.; Vieira, M.; Travassos, G.H. (2007a), Characterization of Model-based Software Testing Approaches, Relatório Técnico ES-713/07, PESC- COPPE/UFRJ. Disponível em Dias Neto, A.C.; Subramanyan, R.; Vieira, M. (2007b), Travassos, G.H. A Survey on Model-based Testing Approaches: A Systematic Review, In: 1 st WEASELTech 07 ASE2007, Atlanta. Dias Neto, A.C.; Travassos, G.H. (2008), Supporting the Selection of Model-based Testing Approaches for Software Projects, In: 3 rd International Workshop on Automation of Software Test (AST 08), Leipzig, Germany, Maio. El-Far, I. K.; Whittaker, J. A. (2001) Model-Based Software Testing. Encyclopedia of Software Engineering (edited by J. J. Marciniak). Wiley. Hortmann, M.; Prenninger, W.; El-Ramly, M. (2005), Case Studies. In: Model-Based Testing a tutorial volume, pp Juristo, N.; Moreno, A.M.; Vegas, S. (2004), Reviewing 25 years of testing technique experiments. Empirical SW Engineering: An International Journal, 9(1), p.7-44, March. Maiden, N. A. M.; Rugg, G. (1996), ACRE: Selecting methods for requirements acquisition, Software Engineering Journal 11(3): 183Y192. Myers, G. (1979), The Art of Software Testing. Wiley-Interscience. Pretschner, A. (2005), Model-based testing, Proceedings of 27th International Conference on Software Engineering, (ICSE 2005), pp Pretschner, A; Prenninger, W.; Wagner, S.; Kühnel, C.; Baumgartner, M.; Sostawa, B.; Zölch, R.; Stauner, T. (2005), One evaluation of model-based testing and its automation, in: Proc. ICSE 05, pp Santos-Neto, P., Resende, R., and Pádua, C. (2007), Requirements for information systems model-based testing, In Proceedings of the 2007 ACM Symposium on Applied Computing (Seoul, Korea, March 11-15, 2007). SAC'07. ACM, New York. 121

143 Utting, A. Pretschner, B. Legeard, B., A taxonomy of model-based testing, Technical report 04/2006, Department of Computer Science, University of Waikato, Abril, Vegas, S.; Basili, V. (2005), A Characterization Schema for Software Testing Techniques, Empirical Software Engineering, v.10 n.4, p , Outubro. Xavier, J. R.; Werner, C.M.L.; Travassos, G.H.; (2002), Uma Abordagem para a Seleção de Padrões Arquiteturais Baseada em Características de Qualidade, XVI Simpósio Brasileiro de Engenharia de Software, Gramado, RS, Brasil. 122

144 Fatores humanos que influenciam a utilização de processos de software Paula G. Ferreira 1, Fabio Q. B. da Silva 1 1 Centro de Informática - Universidade Federal de Pernambuco (UFPE) Caixa Postal Recife - PE - Brasil {pgf2, fabio}@cin.ufpe.br Abstract. Recent researches in software engineering indicate non-technical aspects as a factor that contributes to software project success and failure. Based on this premise, this paper presents a qualitative research conducted with quality area, project managers and leaders from software development projects, regarding the influence of team roles and personality in use of software development processes. The analyses show which psychological profile was more frequent on successful projects. Our aim is to contribute to the discussion of how teams could be balanced to increasing likelihood of process and project success. Resumo. As pesquisas mais atuais na engenharia de software indicam o aspecto não técnico como um fator que contribui tanto para o sucesso quanto para o fracasso de projetos de software. Partindo dessa premissa, serão apresentados os resultados de uma pesquisa qualitativa realizada com a área de qualidade, gerentes e líderes de projetos de desenvolvimento de software, sobre a influência do papel de equipe bem como a personalidade na utilização de processos. As análises mostram qual perfil foi mais freqüente em processos com alto índice de aderência. Busca-se com esta pesquisa contribuir para a discussão sobre como montar equipes balanceadas e maximizar as chances de sucesso do processo e do projeto. 1. Introdução A busca por implantação de processos de melhoria e certificações de qualidade tem aumentado no âmbito dos projetos de desenvolvimento de software das pequenas, médias e grandes empresas brasileiras. Cada vez mais são investidos recursos financeiros, técnicos e humanos para garantir produtos de qualidade, bem como projetos realizados no prazo, custo e qualidade definidos durante a fase de planejamento dos projetos [Vasconcelos et al. 2006]. Algumas empresas e consultorias relataram suas experiências, pontos fortes e fracos, desafios e riscos da implantação de um processo de software [Souza et al. 2004, Rocha et al. 2005, Roullier et al. 2006, Mendes et al. 2007]. Os dados mostram que além dos problemas de alto custo e falta de apoio da alta gerência, destaca-se também a barreira da cultura organizacional e falta de envolvimento e comprometimento dos envolvidos entre os motivos de insucesso do processo. A pesquisa de Sharp e Robinson (2005) apresenta aspectos sociais que afetam a 123

145 engenharia de software que englobam aspectos provenientes das várias interações interpessoais necessárias para o desenvolvimento do software, desde a equipe ao cliente. Segundo estes autores, a engenharia de software é muito mais uma atividade social com atividades técnicas do que uma atividade técnica com fatores sociais. Entretanto, ainda são escassas as pesquisas sobre este assunto que tenham como contexto a realidade brasileira em relação à utilização de processos de software. Diante desses desafios, o foco deste trabalho está no elemento humano, mais especificamente no que tange o comportamento em equipe e a personalidade dos gerentes e líderes envolvidos em projetos que utilizam processos de desenvolvimento de software aderentes ao CMMI nível 3, e como eles influenciam e motivam a equipe a utilizar os processos. A hipótese deste trabalho é que existe uma tendência natural de pessoas com determinados perfis a se interessarem pela área de qualidade e pelo uso do processo. A metodologia do trabalho consiste na avaliação qualitativa (através dos métodos SPI e MBTI) do padrão de papéis de equipe e tipos psicológicos identificados na área de qualidade, e a correlação dos mesmos com o uso do processo (avaliado através das auditorias de processo). Os dados foram coletados em um extenso trabalho de campo, realizado durante o ano de 2007 em uma empresa de software de grande porte do Nordeste do Brasil. Este trabalho está organizado da seguinte forma. Na Seção 2 estão apresentados os intrumentos de pesquisa utilizados e os trabalhos relacionados. Na seção 3 será explicada a metodologia. Na seção 4 serão apresentados os dados da pesquisa de campo e os resultados obtidos. Por fim, na seção 5, serão apresentadas as conclusões. 2. Instrumentos e Trabalhos Relacionados A engenharia de software possui poucos trabalhos que relacionam tipo de personalidade e efetividade do uso de processos de desenvolvimento de software. Alguns trabalhos apresentam resultados sobre o relacionamento entre os tipos de personalidade com papéis funcionais do RUP (Rational Unified Process) [França e Silva 2005], ou com modelos como PMCD (Project Management Competency Development) [Fernandes e Silva 2007], ou ainda com as práticas definidas no PMBoK (Project Management Body of Knowledge) [Pereira 2005]. Outras pesquisas relacionam o tipo de personalidade ao desempenho de atividades específicas [Cunha and Greathead 2007], ou a influência de um determinado perfil na composição da equipe [Stevens 1998; Henry and Stevens 1999; Gorla and Lam 2004]. Tendo em vista que pesquisas mais recentes mostram a importância de relacionar o trabalho em equipe e a personalidade em relação às atividades de gerência de projeto, assim como o desempenho em equipes e atividades de revisão de código, esta pesquisa visa identificar a relação entre comportamento em equipe e personalidade e sua influência na utilização de processos de desenvolvimento de software em uma empresa do Nordeste do Brasil. 124

146 Busca-se identificar quem apóia o uso do processo de forma a permitir que equipes sejam formadas a partir desse conhecimento, aumentando as chances de uso do processo no projeto e, conseqüentemente, o sucesso do projeto. Para tanto, foram utilizados os instrumentos Self-Perception Inventory (SPI) e o Myers-Briggs Type Indicator (MBTI) e os trabalhos relacionados às atividades de engenharia de software Os papéis de equipe de Belbin Em 1981, o doutor Meredith Belbin lançou um livro sobre gerenciamento de equipes baseado na teoria de papéis que ele desenvolveu. O livro surgiu de um experimento acadêmico realizado durante 9 anos no Henley Management College. Os padrões de comportamento identificados por Belbin foram classificados e nomeados em oito tipos de papéis de equipe. A lista abaixo apresenta os oito papéis de equipe sugeridos por Belbin: Co-ordinator (CO) : organiza, coordena e controla as atividades da equipe. Isto envolve esclarecer objetivos e problemas. Atribui tarefas e responsabilidades, e incentiva os membros a se envolverem para atingir os objetivos e metas; Shaper (SH) : desafia, argumenta e discorda. Motivado a realizações, extrovertido, impaciente, tende a se frustar. Interesse em ganhar o jogo. Tem boa visão, especialmente se perde; Plant (PL) : concentrado em apresentar idéias e estratégias para atingir os objetivos da equipe. Este papel requer criatividade, imaginação e inovação; Resource Investigator (RI) : explora o ambiente fora do time, identificando idéias, informações e recursos. Desenvolve bem os contatos de coordenação e negociação com outros times e indivíduos; Monitor Evaluator (ME) : analisa idéias e propostas da equipe, avalia a viabilidade e valor para aintigir os objetivos. Considera de forma construtiva as debilidades das propostas; Completer Finisher (CF) : garante que o esforço da equipe atinge os padrões e que os erros sejam evitados. Busca por detalhes e mantém o senso de urgência da equipe; Team Worker (TW) : cria e mantém o espírito de equipe. Promove a comunicação através de apoio pessoal e cordialidade entre os membros, e evita tensões e conflitos; Implementer (IM) : preocupado que a aplicação de conceitos e planos sejam devenvolvidos pela equipe. Isto envolve perserverança face às dificuldades. Em 1993, Belbin indicou mais um papel chamado de Specialist, mas muitos autores criticam sua necessidade, e a maior parte dos trabalhos ainda utiliza o modelo de 8 papéis, e por isso também foi utilizado nesta pesquisa. Belbin defende que estes papéis quando colocados juntos numa mesma equipe, garantem uma coesão e sintonia entre os membros. Uma equipe não pode ser formada apenas por pessoas extrovertidas, como também não pode existir apenas pessoas 125

147 coordenadoras. Deve haver um equilíbrio entre as forças e fraquezas da equipe. O questionário ficou conhecido como Self Perception Inventory (SPI) e foi bastante difundido na Europa pela sua facilidade, rapidez e lógica de utilização. O modelo já foi traduzido para 16 línguas e tem sido utilizado por diversas organizações incluindo o grupo de companhias do FTSE 100 (Financial Times Stock Exchange) que representam 80% do mercado do Reino Unido, agências multinacionais, governo e consultorias [Aritzeta; Swailles; Senior 2005]. É importante ressaltar que uma pessoa pode apresentar todos os 8 papéis do SPI em maior ou menor escala. Eles são agrupados em muito alto, alto, moderado e leve. Para este trabalho foram considerados os papéis das categorias muito alto e alto Uso do SPI A pesquisa de Stevens (1998) apresentou resultados positivos ao utilizar o questionário de Belbin e comprovar empiricamente a eficácia da formação de equipes balanceadas com os papéis de equipe sugeridos por Belbin. Foi avaliado apenas o papel inovador do SPI e o impacto da sua presença no desempenho das equipes, visto que em equipes de desenvolvimento, o papel de inovação é fundamental, pois traz novas idéias à equipe, principalmente na fase inicial do desenvolvimento. Em outra pesquisa, Henry e Stevens identificaram que a presença de um dos papéis de liderança de Belbin faz diferença no desempenho da equipe [Henry and Stevens 1999]. Eles realizaram um experimento controlado com estudantes seniors de engenharia de software, no qual os estudantes foram agrupados em equipes com apenas um líder e equipes com nenhum ou mais de um líder, nesse segundo caso houve conflito de liderança Os tipos psicológicos do MBTI O MBTI [Myers and Briggs 2007] foi criado em 1942 por Isabel Briggs Myers e Katherine Cook Briggs. Elas desenvolveram o instrumento de indicador de personalidade após dezoito anos de estudos e aplicação da teoria Junguiana, cujo objetivo foi medir traços como inteligência e definir as preferências de personalidade. O instrumento foi publicado pela primeira vez em 1962 e usado para fins de pesquisa. Em 1975 o MBTI passou a ser largamente difundido e disponibilizado para o mercado através do Consulting Psychologists Press. No Brasil sua aplicação é administrada exclusivamente pela Coaching Psicologia Estratégica, que realiza seminários de qualificação para profissionais. No MBTI, as preferências de personalidade são agrupadas em quatro grandes aspectos: como a pessoa interage com o mundo e obtém energia (Extrovertida/Introvertida), como a pessoa percebe e assimila as informações (Sensitiva/Intuitiva), como a pessoa toma decisões e chega a conclusões (Pensamento /Sentimento), e como a pessoa organiza sua vida (Julgamento/Percepção). Os tipos psicológicos citados por Myers-Briggs são classificados nestas quatro dimensões, cuja escala de preferência varia entre dois extremos. 126

148 O MBTI pressupõe que as pessoas utilizam vários processos cognitivos, mas tendem a ter uma preferência entre as dicotomias citadas. Cada tipo tem qualidades, riquezas e possibilidades de desenvolvimento. Esses quatro pares de combinação resultam em dezesseis tipos de personalidade. Como resultado dessas funções surgiu a classificação dos tipos através de letras emprestadas de palavras inglesas cujas iniciais são: Extraversion/Introversion, Sensing/iNtuition, Thinking/Feeling, Judging/Perceiving. As letras iniciais de cada par de atributos, exceto intuition que usa a segunda letra, são combinadas e identificam a personalidade da pessoa, resultando em um código de quatro letras. A lista abaixo apresenta a descrição das características de cada um dos 16 tipos: ISTJ - Responsável, cumpre os compromissos. Tipo o gerente essencial. Trabalha duro mas se diverte de fato nas horas de folga. Vive para os resultados e pode ser muito preocupado com custos; ISFJ - Sério em relação aos compromissos, responsável e leal. Leva o trabalho a sério, é dedicado e cumpre o dever sob todos os aspectos da vida. Quieto, fica contente em trabalhar sozinho. Está sempre ajudando no trabalho de outros; ISTP - É freqüentemente mal entendido e subestimado. É o tipo solitário que prefere fazer a planejar. Produz resultados sem se atrapalhar com entraves burocráticos. Prefere apagar incêndios a treinar formas de prevenção dos mesmos; ISFP - O tipo de pessoa que recusa uma promoção para poder continuar onde as coisas acontecem. Viver e deixar viver é a sua filosofia e o trabalho é a chave de sua motivação. Apóia e ajuda todos os colegas de trabalho; ESTP - Gosta de enfrentar riscos, experimentar e é empreendedor. É um tipo com várias aptidões. "Fazedor" com uma grande energia que o mantém envolvido em diversos projetos, animando todos e fazendo com que a vida seja excitante; ESFP - Corajoso e não-conformista. Se o trabalho não for divertido, irá evitá-lo ou mudar para algo mais interessante. Muito sociável, gosta de interagir com alegria e energia. Seu ponto forte está em permitir que outros sejam diferentes e trabalhem à sua maneira; ESTJ - Responsável, produtivo e orientado para resultados. Encontrado em posições de liderança em várias profissões. Quando um trabalho precisa ser feito, normas estabelecidas, sistemas implementados ou um programa avaliado chame o ESTJ; ESFJ - Elegância. Define o seu estilo de vida e gerencial. Encoraja e motiva as pessoas a atingirem seus objetivos. Gosta de um ambiente de trabalho formal, mas agradável. Possui uma tendência para agir paternalmente e, às vezes, com alguma impaciência. Distribui recompensas e também críticas. Bom fornecedor de feedbacks; INFJ - Estudioso, confiável no trabalho. Um tipo popular na indústria de serviços porque sempre dirige a sua energia e atenção para melhorar a condição 127

149 humana. Uma pessoa gentil que se importa genuinamente com os outros. Gosta de ordem e tranqüilidade no ambiente de trabalho. Intelectual e idealista; INTJ - Possui visão e capacidade para torná-la realidade. Habilidades de liderança fazem com que desempenhem um papel muito importante na formação da cultura das corporações. Independência é a força que os motiva. É perfeito para o papel de especialista de "solucionador de problemas"; INFP - Mais produtivo na área de serviços ou para trabalhar com idéias. Não tolera rotina. Precisa trabalhar de acordo com seus valores pessoais. Seu trabalho é voltado para pessoas. Tende a tomar decisões subjetivamente, baseando-se em valores pessoais, não gosta de controlar as pessoas. Sente-se confortável com a filosofia do "viver e deixar viver"; INTP - Professores e pensadores. Ama o abstrato e precisa ficar sozinho para pensar e repensar suas idéias. Ele estuda e pesquisa profundamente qualquer assunto ou trabalho pelo qual seja responsável. Fonte de idéias e inspiração, mas não se preocupa com prazos no trabalho. Possui pensamento claro e visão na execução de seus projetos; ENFP - Este tipo desempenha muito bem num cargo executivo embora suas características de efervescência, entusiasmo e espontaneidade não sejam típicas nos ocupantes de altos cargos executivos nas empresas. Pode ser muito habilidoso em situações de improviso e pode fazer várias coisas ao mesmo tempo, embora, às vezes, negligencie o planejamento e a preparação; ENTP - Nunca se sabe o que esperar. Todo o momento é bom para alguma coisa e suas características são: energia, dinamismo, criatividade, resistência e argumentação. Prefere se envolver em desafios intelectuais a fazer um trabalho rotineiro. Gosta de público e tende a perder o interesse pelo que está fazendo se alguma coisa mais excitante ou desafiante aparecer; ENFJ - É o vendedor nato com grande poder de persuasão. Prefere viver sua vida de forma estruturada e ordeira. Muito atento à dinâmica interpessoal de cada situação, sente necessidade de liderar; ENTJ - Possui a mistura certa das qualidades de liderança: entusiasmo, visão, objetividade e responsabilidade. O ENTJ é forte, direto e bom estrategista, pode ver possibilidades em quase tudo e agir rapidamente Uso do MBTI A pesquisa de Gorla e Lam (2004) teve como objetivo identificar a relação entre a composição dos tipos psicológicos e o desempenho em pequenas equipes de software de Hong Kong. Como resultado foram identificadas algumas caracterísitcas do líder de equipe, do analista e do programador que afetavam o desempenho da equipe. Por exemplo: um líder de equipe intuitivo (N) e sentimental (F) funcionava bem em equipes pequenas. No caso do analista, foi identificado que o tipo pensador (T) teve mais influência, pois nessa atividade as habilidades analíticas são mais importantes do que as comportamentais. Em equipes pequenas, o analista não foca apenas nos requisitos e 128

150 especificação do sistema, ele está envolvido em múltiplas atividades que necessitam de uma abordagem científica e decisões lógicas. Para o programador a forte influência foi apresentada no aspecto social, sendo o tipo extrovertido (E) mais significativo para equipes pequenas. Isto se explica pelo fato do programador ter que se comunicar com muitas pessoas, analistas, designer e outros programadores. O autor conclui que é diferente alocar pessoas em equipes pequenas e grandes, e por isso o gerente deve ficar atento e considerar a heterogeneidade no momento de selecionar sua equipe. A pesquisa de Cunha e Greathead (2007) teve como objetivo investigar se existia um tipo psicológico relacionado com o desempenho na atividade de revisão de código. Os autores detectaram que alguns profissionais apresentaram mais habilidade do que outros. De uma forma geral, as pessoas com perfil NT tiveram melhor perfomance dos que os não- NT. A maior diferença foi entre as pessoas com o tipo NT e SF. Os NTs são conhecidos como "lógicos e habilidosos" e são melhores na resolução de problemas, por isso não foi uma surpresa que este tipo fosse melhor nesta atividade. Entretanto, a grande diferença entre NT e SF, que são tipos opostos, foi que chamou a atenção, pois foi muito grande: os SF acertaram menos do que a metade do que os NT. 3. Metodologia O arcabouço metodológico envolveu a seleção de projetos de software que utilizam processos aderentes ao modelo CMMI nível 3 como guia para o desenvolvimento do projeto. A empresa na qual foi realizada a pesquisa teve o seu processo estabelecido desde 1996, e vêm amadurecendo ao longo dos últimos 11 anos, e recentemente, em Outubro de 2007, obteve a certificação CMMI nível 3. Foram analisados 9 projetos diversificados em seus domínios, prazos, tamanho das equipes, papéis de equipe e tipos psicológicos envolvendo 37 pessoas, das quais 15 da área de qualidade e 22 gerentes e líderes de projetos. A pesquisa teve abordagem qualitativa com a aplicação de questionários para identificação dos perfis, e foram analisados os resultados das auditorias de processos de planejamento e acompanhamento desses projetos. Para classificação dos papéis de equipe e tipos psicológicos foram utilizadas as ferramentas SPI e o MBTI. Os percentuais de aderência dos processos de planejamento (Project Planning - PP) e acompanhamento (Project Monitoring and Control - PMC) foram analisados e relacionados aos papéis exercidos pelos gerentes e líderes. O objetivo foi avaliar qual o padrão de papéis da área de qualidade, e qual a relação entre os papéis dos gerentes e líderes na utilização de processos nos projetos. Quanto maior o percentual atingido, maior a possibilidade de adequação do papel ao uso do processo. O resultado foi avaliado em relação aos papéis identificados na área de qualidade, visto que pessoas que atuam nesta área são consideradas favoráveis à utilização de processos. Para este trabalho foi considerada a premissa de que o uso do processo depende da disposição das pessoas em utilizar e melhorar o processo. Não é possível avaliar, julgar ou 129

151 criticar um processo se o mesmo não for utilizado. Independente do modelo, existem pessoas que vão utilizar e contribuir para a melhoria do processo, e existem pessoas que não vão se adaptar a seguir padrões, procedimentos, nem ao menos contribuir através de críticas. A hipótese é que isto depende do perfil de cada pessoa Caracterização da Amostra Os projetos analisados foram classificados quanto à duração e tamanho da equipe conforme tabela 1: Tabela 1: Duração e tamanho da equipe Para efeito de anáise, a classificação dos projetos em relação ao uso do processo foi dividida em 3 grupos: Satisfatório (S): considera os projetos que contêm uma aderência ao processo igual ou superior a 90%; Adequado (A): considera os projetos que contêm uma aderência ao entre 40% e 89%; Insatisfatório (I): considera todos os projetos abaixo de 39% Limitações Foi realizado um levantamento dos projetos dentro da organização, e foram selecionados todos que utilizavam o processo aderente ao modelo CMMI nível 3 (18 no total). Entretanto, para esta pesquisa, foram removidos os projetos que se diferenciavam no tipo, por exemplo: consultoria e desenvolvimento. O foco foi nos projetos de desenvolvimento. Outros projetos foram retirados da pesquisa por apresentarem dados insuficientes dos participantes (gerentes e líderes) ou por serem de caráter confidencial. Alguns projetos também foram removidos, quando foi identificado, previamente, que a causa do problema do projeto foi proveniente de outras fontes, como falta de experiência do gerente, e por isso, a utilização do processo não pode ser avaliada. Desta forma, foram selecionados apenas os projetos cujas variáveis tipo de projeto e experiência não pudessem interferir na análise dos resultados. 130

152 4. Resultados e Análises Serão apresentados primeiramente os dados da área de qualidade e depois as informações dos gerentes e líderes, e o resultado do uso do processo em 9 projetos. Para cada grupo serão apresentados os resultados do SPI e em seguida os do MBTI Área de Qualidade O gráfico 1 apresenta os papéis de equipe mais relevantes identificados na área de qualidade: Gráfico 1: Resultado SPI da área de qualidade: 131

153 Gráfico 1: Resultado SPI da área de qualidade Os dados indicam a forte tendência da área de qualidade nos tipos Implementer (IMP), Completer Finisher (CF), Co-ordinator (CO) e Monitor Evaluator (ME). Percebe-se que há uma maior aglomeração de pessoas com o mesmo papel na área de qualidade com um perfil de controle, organização, críticos e, principalmente, atento aos detalhes. Este resultado é consistente com o trabalho de [Meira et al. 2008] que, utilizando outra abordagem metodológica, concluiu que os papéis em time de Belbin mais adequados para as funções de qualidade são CO e CF, seguidos de ME e IMP. Para o MBTI, dos 16 tipos psicológicos previstos, apenas 7 foram identificados na área de qualidade. O gráfico 2 apresenta os tipos psicológicos da equipe de qualidade: Gráfico 2 : Tipos psicológicos do MBTI na área de qualidade Nota-se que 8 pessoas possuem as letras STJ, e todas as outras possuem pelo menos uma combinação dessas letras, ou ST ou SJ, com exceção de 1 pessoa ESFP. Era esperado que o grupo de qualidade apresentasse uma tendência destes tipos psicológicos visto que as pessoas que atuam nesta área são mais favoráveis ao uso do processo. 132

154 4.2. Aderência dos Projetos ao Processo A tabela 2 apresenta a lista dos 9 projetos, e seus respectivos resultados nas áreas de planejamento (PP) e acompanhamento (PMC), e a relação quanto à duração e tamanho da equipe: Tabela 2: Classificação dos projetos (auditorias PP e PMC, duração e equipe) Pode-se perceber inicialmente um padrão onde projetos de duração G e M com equipes de tamanho M utilizaram melhor o processo do que os projetos com equipes de tamanho P. Isso leva a crer que em equipes de tamanho P pode haver sobrecarga de trabalho nas atividades do projeto diminuindo as chances de utilização do processo. No caso de equipes de tamanho M pode haver uma melhor distribuição das atividades e responsabilidades e maior disponibilidade das pessoas em utilizar o processo. Dentre os projetos com equipe de tamanho P apenas o projeto 2 apresentou sucesso em ambos os processos. Nos projetos 7, 8 e 9 houve falha no processo de planejamento e / ou no de acompanhamento. Pode-se inferir que um projeto G com equipe M precisa dos processos de PP e PMC mais formais e mais aderentes para apoiar as atividades de planejamento e acompanhamento do projeto. Já no caso de projetos com equipe P, o processo pode ter sido subutilizado devido à equipe reduzida bem como sobrecarga de trabalho nas atividades do projeto Avaliação dos Gerentes e Líderes dos Projetos A tabela 3 apresenta a lista dos 9 projetos, o resultado de aderência aos processos de PP e PMC, os papéis de equipe e tipos psicológicos identificados nos gerentes e líderes dos projetos: 133

155 Tabela 3: Processos de PP e PMC versus SPI e MBTI Projeto A partir da tabela 3, é possível perceber que todos os projetos, com exceção dos projetos 1 e 8, possuem um dos papéis de liderança indicados no SPI, no caso, o CO ou SH. Já os líderes apresentaram mais os papéis de IMP e CF que são papéis orientados à ação e execução. Percebe-se que os projetos de 1 a 6 possuem uso adequado dos processos de PP e PMC, e neles existe pelo menos 4 papéis envolvidos, dos quais um deles é o papel de liderança CO ou SH e outro é um papel de ação CF ou IMP, e muitas vezes ambos os papéis. Isso leva a crer que a presença destes papéis dentro de uma equipe possibilitará o uso adequado dos processos de PP e PMC. Esses dados indicam o mesmo padrão identificado na área de qualidade, o que confirma e aumenta as evidências da predominância de alguns papéis favoráveis ao uso do processo. Já os projetos que apresentaram resultado insatisfatório, no caso os projetos 7, 8 e 9 foram cuidadosamente avaliados para confirmar ou acrescentar novas informações ao resultado anterior. Podemos perceber que os projetos 7 e 8 contêm o menor número de papéis envolvidos, apenas 3. O projeto 7 apesar de possuir um dos papéis de liderança e um dos 134

156 papéis orientados à ação, obteve resultado insatisfatório apenas no processo de PP. Podemos considerar que a ausência do papel SH no gerente ou no líder prejudicou o uso do processo de PP. Entretanto, se considerarmos os dados da tabela 2, identificamos que o projeto 7 tem uma equipe pequena, o que leva a crer que o gerente e o líder ficaram sobrecarregados na fase inicial do projeto e por sua vez, não conseguiram cumprir com as atividades previstas no processo, mas que, conseqüentemente, levou a uma maior necessidade de acompanhamento do projeto. Já no caso do projeto 8, o resultado foi insatisfatório em ambos os processos, tanto PP como PMC. Este projeto também contém o menor número de papéis envolvidos, só que neste caso não possui nenhum dos papéis de liderança, e possui apenas um dos papéis orientados à ação. Considerando a tabela 2, podemos verificar que é um projeto de duração M e equipe de tamanho P, o que agrava ainda mais a situação do não uso do processo. Isso leva a crer que o gerente juntamente com o líder estavam focados em executar as atividades do projeto, visto que o período era médio, e não houve disponibilidade em executar as atividades do processo. Além disso, podemos considerar que a ausência dos papéis CO, SH e IMP prejudicaram o uso do processo. Este resultado reforça a importância de um papel de liderança na condução dos processos de PP e PMC. Na análise do projeto 9, podemos chegar a mesma conclusão do projeto 7. Apesar de existirem 6 papéis de Belbin, dos quais há a presença de um papel de liderança e um papel orientado à ação, podemos alinhar ao resultado da tabela 2, que apresenta o projeto 9 com uma equipe pequena, o que pode ter levado a uma sobrecarga dos gerentes e líderes e falta de uso do processo, mas com maior necessidade de acompanhamento posterior. Além dos papéis do SPI, é possível identificar um padrão nos tipos psicológicos do MBTI nos líderes de projeto. A partir da tabela 2, é possível perceber que todos os projetos, com exceção do projeto 1, possuem o tipo psicológico ISTJ ou ESTJ. A maioria destes tipos foi identificada nos líderes de projetos, sendo apresentado em apenas um gerente. Apesar dos gerentes serem mais perceptivos (letra P), eles possuem líderes com características correspondentes às identificadas na área de qualidade, que indica o tipo STJ mais favorável ao uso do processo. Para o MBTI, a análise deve considerar não apenas a combinação dos tipos psicológicos entre gerentes e líderes, mas também a combinação das letras de cada tipo e do índice de clareza de cada uma delas. É possível perceber que dos projetos 1 a 6 que tiverem resultado adequado em ambos os processos de PP e PMC, 5 gerentes possuem a letra P em seu tipo psicológico, indicando pessoas perceptivas o que indica pessoas espontâneas e flexíveis. Este resultado leva a crer que este tipo é menos resistente à utilização de processos visto que são pessoas abertas. Estes mesmos projetos possuem líderes com a letra J, que são pessoas organizadas e planejadas. Logo, podemos inferir que o gerente fica aberto ao uso do processo e tem o apoio do líder para executá-lo. O projeto 7 é um caso particular, visto que o mesmo possui um gerente com a letra F, mas não tem a letra P, e um líder com a letra J, e houve insatisfatoriedade no processo de 135

157 PP. Além da ausência da letra P e, de acordo com o quadro 18, o projeto 7 tem duração G e uma equipe P, o que leva a crer que o esforço inicial para organizar o projeto impediu a utilização adequada do uso do processo de PP, visto que o acompanhamento foi executado de forma adequada. No caso do projeto 8 temos um gerente atípico com um perfil que envolve a combinação das letras NTP, o que indica uma pessoa intuitiva, lógica, objetiva, espontânea e flexível. Apesar de ter a letra P, não existe a combinação FP, podemos considerar que a análise do resultado SPI indica a ausência de um dos papéis de liderança, o que levar a crer que isso prejudicou o uso do processo. Já o projeto 9, é similar à análise do projeto 7, visto que também é um projeto grande com equipe pequena, e pode ter sofrido demanda de planejamento no início do projeto prejudicando as atividades do processo. De todos os projetos apresentados, o projeto 8 confirma que a ausência da combinação das letras FP no tipo psicológico do gerente prejudica a utilização do processo, visto que a dicotomia TJ para o caso do gerente pode ser mais resistente a aceitar o seguimento de padrões. Consideramos que as letras FP devem estar presentes no gerente de projeto, combinada com líderes que possuem as letras STJ para garantir que os processos de PP e PMC sejam utilizados. Apesar da pequena amostra e do seu caráter qualitativo desta pesquisa, é possível observar que há uma relação entre o papel de equipe e tipos psicológicos dos gerentes e líderes de projetos na utilização de processos, e que os mesmos estão alinhados à outras pesquisas na área de qualidade na qual foram identificados os mesmos papéis e tipos predispostos ao uso do processo, no caso CO, CF, IMP, e tipos STJ. Mais especificamente, foi possível identificar que a área de qualidade possui um padrão do papel de equipe bem como tipo psicológico que corresponde às características de pessoas organizadas, planejadas, críticas, sistemáticas e que contribuem para o uso do processo. Portanto, esta pesquisa confirma a hipótese de que existe uma tendência natural de pessoas com estes perfis a se interessarem pela área de qualidade e pelo uso do processo. Além do comportamento do gerente e líder, fica explícito que a duração do projeto atrelada ao tamanho da equipe, conforme citado por Gorla e Lam (2004), são variáveis que devem ser consideradas durante a composição da equipe, visto que ainda que os gerentes e líderes tenham os perfis indicados, essas variáveis podem prejudicar a utilização dos processos de PP e PMC. 5. Considerações Finais O motivo principal para conhecer os tipos de personalidade é permitir que o processo possa ser orientado às pessoas, desde a sua forma de escrita, os treinamentos realizados, às ferramentas e atividades. É possível identificar aquelas pessoas que são naturalmente aptas ao uso do processo e aqueles que não são favoráveis ao uso do processo. A pesquisa apresentou a similaridade entre os papéis de equipe e tipos psicológicos 136

158 da área de qualidade e gerentes e líderes de projetos no sucesso do uso dos processos de PP e PMC, e mostra que existe uma característica comum nas pessoas que estão em busca da qualidade. É necessário a inserção dessas pessoas dentro das equipes, ou permitir que equipes sejam formadas garantindo a participação de pessoas com papéis CO, CF e IMP e tipo psicológico com as letras STJ para maximizar a utilização dos processos nos projetos. Os dados apresentados refletem que há uma tendência de uso do processo por um certo tipo de indivíduo, seja pelo seu papel de equipe ou pelo seu tipo psicológico, ou a combinação destes, e que seu comportamento influencia a equipe no uso do processo. Foi possível observar que a duração do projeto e o tamanho da equipe também influenciam no uso do processo. Este trabalho teve como objetivo relacionar a influência dos gerentes e líderes de projeto, e área de qualidade, e seus respectivos papéis de equipe e tipos psicológicos, no uso de processos de desenvolvimento de software. Verificou-se que fatores humanos e sociais afetam o uso do processo. Por fim, vale ressaltar a importância de estudar cada vez mais aspectos humanos e aplicabilidade das teorias de personalidade dentro da engenharia de software, possibilitando estender o conhecimento destas teorias ainda pouco utilizadas no Brasil. Agradecimentos Os autores agradecem a revisão realizada pela doutora Renata Gonçalves Ferreira, pesquisadora da Pós-Graduação em Psicobiologia da Universidade Federal do Rio Grande do Norte. Referências Aritzeta, A. ; Senior, B. ; Swailes, S. (2005) Team role preference and cognitive styles: a convergent validity study. Small Group Research, (S.l.: s.n.), v. 36, n. 4, p Belbin, M. R. (1981) Management Teams: Why they succeed or Fail? Butterworth- Heinemann Ltd, ISBN (1993) Team Roles at Work. At Linarc House, Jordan Hill, Oxford: Butterworth- Heinemann, ISBN Cunha, A. D. and Greathead, D. (2007) Does personality matter? : an analysis of codereview ability. Communications of the ACM. New York, USA : Associatiom for Computing Machinery, v. 50, n. 5, p , Maio. Fernandes, F. e Silva, F. (2007) Relações entre competências pessoais e tipos de personalidade do gerente de projetos. In: Congresso Brasileiro em Gerenciamento de Projetos, 2., 2007, Salvador-BA-Brasil. Resumos. Project Management Institute Chapter Bahia,. França, C. A. e Silva. F. Q. B. (2007) Um estudo sobre relações entre papéis funcionais do RUP e o comportamento pessoal no trabalho em equipe em fábricas de software. In: 137

159 WOSES - Workshop: um olhar sociotécnico sobre a engenharia de software, 3., 2007, Ipojuca/PE. Resumos... Sociedade Brasileira de Computação. Gorla, N. and Lam, Y.W. (2004) Who should work with whom? Building effective software project teams. Communication of the ACM, June, v. 47, n. 6. Henry, S. M. and Stevens, K. T. (1999) Using Belbin's Leadership Role to Improve Team Effectiveness: an empirical investigation, Journal of Systems and Software, v. 44, n. 3, Jan., p Meira, A.F, et al. (2008) Um estudo da adequação de perfis profissionais para o SQA em empresas de desenvolvimento de software, Relatório de Pesquisa, UFPE, Recife/PE. Mendes, F. F. ; Oliveira, J. L. ; Fernandes, P. G. ; Souza, A. (2007) Análise de Riscos na Implantação de Melhorias de Processos de Software. ProQuality (UFLA), v. 3, p Myers, I. and Briggs, K. Myers-Briggs Type Indicator. Disponível em: < Acesso em: 26 set Pereira, M. S. (2005) Implicações Práticas da gerência de projetos baseada em aptidões dos membros. Trabalho de graduação em empreendedorismo, UFPE, Rocha, A.R. et al. (2005) Dificuldades e Fatores de Sucesso na Implantação de Processos de Software Utilizando o MR-MPS e o CMMI, In: Workshop de Implementadores MPS.BR, 1. Resumos... Brasília, Brasil. Out. Roullier, A. C. et al. (2006) Metodologias e analise das implantacoes do MPS-BR realizadas pela SWQuality. Revista ProQuality: Qualidade na Producao de Software. v. 2, n. 2, p Sharp, H. and Robinson, H. (2005) Some Social Factors of Software Engineering: the maverick, community and technical practices, Human and Social Factors of Software Engineering (HSSE), May 16. Souza, A. S.; Oliveira, J. L.; Jino, M. (2004) Experiências e riscos na implantação de processos de software em empresas do centro-oeste brasileiro. In de Ingeniería del Software e Ingeniería del Conocimiento, Q. J. I., editor, Anais... Quarta Jornadas IberoAmericanas de Ingeniería del Software e Ingeniería del Conocimiento, volume 1, pages 1-4, Madri. Stevens, T. K. (1998) The Effects of Roles and Personality Characteristics on Software Development Team Effectiveness, Virginia Polytechnic Institute and State University. Vasconcelos, A. M. L.; Rouiller, A.C.; Machado, C. Â. F.; Medeiros, T. M. M. (2006) Introdução à Engenharia de Software e à Qualidade de Software. Lavras: UFLA/FAEPE. 157 p. :il. - (Curso de Pós- graduação "Lato Sensu" (Especialização) à Distância - Melhoria de Processo de Software. 138

160 Guidance for Efficiently Implementing Defect Causal Analysis Marcos Kalinowski 1, 2, Guilherme H. Travassos 1, David N. Card 3 1 COPPE/UFRJ Federal University of Rio de Janeiro Caixa Postal CEP Rio de Janeiro Brazil 2 Bennett Methodist University of Rio de Janeiro Rua Marquês de Abrantes, 55 - Flamengo - CEP Rio de Janeiro Brazil 3 Det Norske Veritas Windward Way - Indian Harbour, FL USA {mkali, ght}@cos.ufrj.br, card@computer.org Abstract. Defect causal analysis has shown itself to be a cheap and high return means of product-focused software process improvement. However, despite its advantages and wide industry adoption little academic research is being done in this area. Thus, professionals face several questions when implementing it in software organizations. Aiming to provide unbiased and evidence-based answers to those questions, a systematic review has been conducted. Based on the results of the systematic review, better guidance for implementing defect causal analysis efficiently in software organizations can be elaborated. 1. Introduction Causal analysis and resolution is a means of identifying causes of defects and other problems and taking action to prevent them from occurring in the future. It is considered in many software process improvement models and approaches, such as MPS [SOFTEX, 2007a], CMMI [SEI, 2006], ISO/IEC [ISO/IEC, 2004], Lean [Poppendieck and Poppendieck, 2003], and Six Sigma [Eckes, 2000]. Robitaille (2004) highlights causal analysis as a way to identify opportunities for improving organizational process assets based on experience with the projects defined processes. Defect causal analysis (or defect prevention 1 ), comprises applying causal analysis and resolution to a specific type of problem: the defects introduced in software artifacts throughout the software lifecycle. Given this initial definition, defect causal analysis can be seen as a systematic process to identify and analyze causes associated with the occurrence of specific defect types, allowing the identification of improvement opportunities for organizational process assets and the implementation of actions to prevent the occurrence of that same defect type in future projects. Thus defect causal analysis provides an opportunity to enable product-focused software process improvement, based on data about the products defects [Kalinowski, 2007]. Other problems, such as schedule flaws, are not considered directly by defect causal analysis. Accomplishing defect causal analysis activities throughout the software development lifecycle has shown to reduce defect rates by over fifty percent in different organizational contexts, such as IBM [Mays et al., 1990], Computer Science Corporation [Dangerfield et al., 1992 apud Card, 1993], HP [Grady, 1996], and InfoSys 1 More precisely, defect causal analysis can be considered part of defect prevention. The latter also addresses the implementation of actions and the communication of changes to the development team explicitly. 139

161 [Jalote and Agrawal, 2005]. As a consequence, it helps to diminish the rework effort [Jalote and Agrawal, 2005] and increases the probability of achieving other process quality and performance goals [SEI, 2006]. Moreover, defect causal analysis is a means for communicating lessons learned among projects [SEI, 2006]. However, as mentioned by Card (2005), despite its benefits and the wide industry adoption of causal analysis, little research is being done in this area, and little scientific knowledge has been generated and published. Thus many doubts and questions remain when implementing defect causal analysis in software organizations. For instance: Is my organization ready for defect causal analysis? What approach 2 should be followed? How should defects be categorized? How should causes be categorized? What are the expected costs and results of implementing defect causal analysis? Aiming to provide unbiased and evidence-based answers to these questions, a systematic review has been conducted. This systematic review identifies the defect causal analysis state of the art and provides guidance on how to efficiently implement it in software organizations. The systematic review and the resulting guidance are the focus of this paper. Further information and details on the systematic review can be found in a technical report [Kalinowski and Travassos, 2008] that supports this paper. The remainder of this paper is organized as follows. In section 2 the systematic review is described. In section 3 the guidance and suggestions obtained from analyzing the results of the systematic review are presented in the form of evidence-based and unbiased answers to common questions. Section 4 concludes the paper. 2. A Systematic Review on Defect Causal Analysis A systematic review is a means of identifying, evaluating and interpreting research relevant to research questions in an unbiased and fair way [Brereton et al., 2007]. Systematic reviews tend to be more reliable because it makes use of a rigorous methodology that is open to auditing and replication. A systematic review was conducted to identify the state of the art regarding defect causal analysis and to provide guidance on how to effectively implement defect causal analysis in software organizations. An unbiased review protocol, focusing on the research questions was developed to guide the literature review according to the systematic review process. This process involves three main activities: planning, execution and result analysis [Biolchini et al., 2005]. The next subsection presents an introduction to defect causal analysis, in order to provide the basis for understanding of the remaining subsections, in which a description of the systematic review activity and results is presented Defect Causal Analysis To have a clear understanding of what defect causal analysis represents in the scope of this paper it is important to understand precisely what we mean by the term defect, since its interpretation often depends on the context in which it is being used. For instance, when a defect is found through peer reviews it is related to a fault in the artifact being reviewed. When a defect is found through testing activities, on the other hand, usually it is related to a failure in the software product being tested. These definitions follow the IEEE standard terminology for software defects [IEEE , 1990]: 2 Hereafter we refer to defect causal analysis approach as a strategy for an investigative process and to defect causal analysis techniques as a specific tool or method used in a defect causal analysis process. 140

162 Error: a mistake committed by a person while trying to understand given information, solve a problem, or using a method or tool. Fault: the concrete manifestation of an error in a software artifact. An error may result in many faults. Failure: the operational behavior different from the one expected by the user. A failure may be caused by many faults, one fault may cause many failures, and some faults may never cause failures. This paper uses the term defect to represent the IEEE definition of fault. Thus, in the case of failures it will be necessary to find the related defects (faults) by analyzing the artifacts (for instance, by debugging source code) before starting defect causal analysis. Analyzing causes of software defects has been discussed since the seventies [Endres, 1975] and is cited by Boehm (2006), in addition to software inspections, as one of the main contributions of that decade to software engineering. Since then, defect causal analysis processes have been implemented in industry for large projects involving hundreds of employees [Mays et al., 1990] [Leszak et al., 2002] as well as smaller projects [Dangerfield et al., 1992] [Yu, 1998] [Jalote and Agrawal, 2005]. Card (2005) summarizes the defect causal analysis process in six steps: (1) select a sample of the defects, (2) classify selected defects, (3) identify systematic errors, (4) determine principal cause, (5) develop action proposals, and (6) document meeting results. In this context a systematic error is an error that results in the same or similar defects being repeated in different occasions [Card, 2005]. Finding systematic errors indicates the existence of significant improvement opportunities for the project or organizational process assets. Besides listing these six steps, Card (2005) highlights the importance of managing the implementation of the action proposals until their conclusion and communicating the implemented changes to the development team. A representation of the traditional software defect prevention process [Mays et al., 1990], consistent with the defect causal analysis process described above, is shown in Figure 2. Besides the causal analysis meeting, the figure shows a specific activity for implementing the action proposals by an action team and the communication of the implemented changes before starting the Figure 2. Defect prevention process. Adapted from [Mays et al, 1990 apud Rombach and Endres, 2003]. 141 development activity. Moreover, the position of the experience base shows that defect causal analysis is a mean for communicating lessons learned among projects as well as a way to disseminate knowledge in the organization, as suggested by the SEI (2006). Given this brief introduction to defect causal analysis, the remaining subsections describe the defect causal analysis systematic literature review Planning the Systematic Review The goal of the systematic review was to conduct an unbiased and fair review regarding the state of the art of defect causal analysis, more specifically aiming at: Summarizing the processes, approaches, and guidance that have been proposed for defect causal analysis.

163 Additionally, summarize and analyze the defect and cause classification schemes used. Note that the goal here isn t to analyze all the existing classification schemes for defects and causes, but to focus on those from sources related to defect causal analysis. Two research questions, Q0 and Q1, where formulated to address the goals listed previously. The question Q0 relates to a broader scope, analyzing causes of defects. The question Q1, on the other hand, is specifically related to defect causal analysis (involving the prevention in future projects). This strategy was adopted so that generic knowledge regarding the analysis of causes of defects could also be identified, since this knowledge can be used as a starting point towards defect causal analysis (including prevention). The description of the research questions, in the format suggested in [Biolchini et al., 2005], follows: Q0: Which processes, approaches and knowledge have been proposed and/or used for analyzing causes of software defects? o (P) Population: scientific publications and experience reports from software development projects, environments or organizations. o (I) Intervention: processes, approaches and knowledge for analyzing causes of software defects. o (C) Comparison: does not exist. o (O) Output: identification of processes, approaches and knowledge for analyzing causes of software defects. Q1: Which processes, approaches and knowledge have been proposed and/or used for software defect causal analysis (or defect prevention)? o (P) Population: scientific publications and experience reports from software development projects, environments or organizations. o (I) Intervention: processes, approaches and knowledge for software defect causal analysis (or defect prevention). o (C) Comparison: does not exist. o (O) Output: identification of processes, approaches and knowledge for software defect causal analysis (or defect prevention). Based on these research questions, search strings could be derived and adjusted so that they could be executed on different digital libraries. Below we present the search string S0, derived for question Q0 by listing the keywords identified for the (P) and (I) and (C) and (O) structure. S0: (P) Population and (I) Intervention and (O) Output ( software development or software project or software process or software engineering or software organization or software environment or experience factory or software factory ) and (( causal analysis or cause analysis or defect analysis or error analysis or failure analysis or fault analysis ) and (defect or error or failure or fault) and (causal or cause)) and (process or approach or method or methodology or technique or knowledge or tool or paradigm or strategy). The chosen digital libraries were: ACM Digital Library, EI Compendex, IEEE, Inspec, and Web of Science. The search strings were tested against a set of seven control papers dealing with defect causal analysis, read before the systematic review. The strings were able to retrieve five of them and, of course, many other defect causal analysis papers from the digital libraries. The two control papers that were not retrieved both satisfied the strings search criteria, however, in our opinion they were not retrieved because one of them was really not indexed in the chosen digital libraries and the other one was probably indexed improperly. Thus, our strings seemed to fit their purpose. The criteria for including a retrieved paper in our review was that it must comprise processes, approaches or knowledge regarding analyzing causes of defects or defect causal analysis (defect prevention). For each of the selected papers the following 142

164 information was extracted: title, complete reference, source, defect classification scheme, cause classification scheme, identification of the process or approach, description of the process or approach, identification of knowledge, description of the knowledge, and type of study Execution of the Systematic Review Once the review protocol was finished, the execution of the systematic review could be started. It was planned to occur on a yearly basis, thus avoiding becoming outdated over the years. A summary of the executions in August 2006 and August 2007 follows. August 2006 Execution. The search strings were executed on the selected digital libraries, and 203 papers were retrieved. After eliminating replications (the same paper retrieved from more than one digital library) the total number of retrieved papers fell to 159. Those 159 papers were filtered further. The initial filtering was based on the title and abstract. Only those papers that were surely not related were excluded. As a result, the number of papers to read and evaluate decreased to 57. After reading the papers and trying to extract the information from them, some more papers were excluded, based on the criteria defined previously. Finally, 41 papers were selected as part of the first execution of our systematic review. The number of papers retrieved from each digital library during the filtering process is shown in Figure ACM IEEE Inspec EI Compendex Web Of Science Total Filtering by Content Filtering by Title and Abstract Before Filtering Figure 3. Number of papers retrieved in august In addition to the 41 papers obtained by applying the review protocol to the digital libraries, information was extracted from the two control papers that were not retrieved and from one other paper: [Endres, 1975]. This paper was included because it was referenced by some of the selected papers as a seminal paper in the area. Again, we believe that the paper was indexed improperly in the IEEE digital library, since its content satisfies the strings search criteria. Therefore, as a result of applying the systematic review in August 2006, information was extracted from 44 research papers. August 2007 Execution. In 2007 the same filtering process was performed. As a result 15 new papers were identified. After filtering by title and abstract the number of new papers decreased to 7. Finally, after filtering by content the number decreased to 6. The quantity of new papers from each digital library during the filtering process is shown in Figure ACM IEEE Inspec EI Compendex Web Of Science Total Filtering by Content Filtering by Title and Abstract Before Filtering Figure 4. Number of additional papers retrieved in august All the analyzed papers and the way they cite each other, considering the August 2006 and August 2007 executions, are shown in Figure 5. This graph representation allowed 143

165 us to identify the most influential papers and research trends. The papers cited by more than three of the remaining papers are shown in light grey. The additional papers retrieved in the August 2007 execution are shown in grey. The information extracted from each of the papers is registered in [Kalinowski and Travassos, 2008]. 144

166 Figure 5. Citations between papers selected in the august 2006 and august 2007 reviews. VII Simpósio Brasileiro de Qualidade de Software 145

167 2.4. Results of the Systematic Review The following information, regarding the goals of our systematic review, was extracted and grouped in tables, organized by publication date: processes and approaches used for defect causal analysis; defect classification schemes used by the papers; cause classification schemes used by the papers, and; knowledge regarding defect causal analysis generated or cited by those papers. In the following subsections a summary of the analyses that performed based on those tables, aiming at obtaining the state of the art for each of the systematic review goals, is presented Processes and Approaches The first approach found was the one described by Endres (1975), at IBM. This approach deals with individual analysis of software defects, in such a way that they can be categorized and their causes identified, allowing actions to be taken to prevent their occurrence in future projects or at least to assure their detection. The analysis of the defects occurs occasionally, as well as the corrective actions. This approach is still referenced in recent papers that involve retrospective defect analysis, such as [Li et al., 2006]. The difference between this approach and the traditional defect prevention process, also established at IBM [Jones, 1985] [Philips, 1986] [Mays, 1990] [Mays et al., 1990], about ten years later, is that the latter one is integrated into the development process. This integration occurs by establishing two additional tasks: (1) a causal analysis meeting after the rework activity is finished (which means that the defects at this point were already removed), and (2) a kickoff meeting, where the actions implemented since the last causal analysis meeting are communicated to the personnel involved in performing the activity. The approach presented by Endres (1975) and the defect prevention process [Jones, 1985] analyzes defects exhaustively and involves in the analysis, if possible, the people responsible for introducing the defects. When appropriate, the meeting leader can skip some of the defects during the meeting without them being discussed. Card (1993), describes a more flexible process involving the same concepts. The apparent flexibility comes from the fact that the causal analysis meeting isn t coupled to a specific development activity, but occurs periodically. Card (1993) also highlights, based on the experience at Computer Science Corporation referenced in the paper, that it is not necessary to analyze all defects exhaustively, a sample will suffice, and that the action proposals should treat classes of defects and not each defect separately. Most of the papers analyzed follow processes congruent to the traditional defect prevention process [Jones, 1985] or the corresponding defect causal analysis process [Card, 1993]. Among the papers that explicitly follow or suggest this process are [Jones, 1985], [Philips, 1986], [Mays, 1990], [Mays et al., 1990], [Pratt, 1991], [Card, 1993], [Collofello and Gosalla, 1993], [Damele et al., 1996], [Grady, 1996], [Card, 1998], [Leszak et al., 2000], [Leszak et al., 2002], [van Moll et al., 2002], [Jalote and Agrawal, 2005], and [Card, 2005]. Grady (1996) describes defect causal analysis experiences at Hewlett Packard. The periodicity varied: one shot causal analysis (performed randomly), post project causal analysis (performed after the conclusion of the project), and a continuous process improvement cycle (performed after each development phase). 146

168 Besides the defect causal analysis approaches, some specific techniques to support causal analysis could be identified. Even though they are not defect causal analysis approaches, we considered them in our review. They represent techniques to identify cause-effect relations: [Nakajo, 1991], [Nakajo and Kume, 1991], [Wohlin et al., 2000], [Krause et al., 2002], and [Gras, 2004]; statistical control techniques: [Hong et al., 1999], and [Wang et al., 2006]; and defect analysis techniques: [Bhandari et al., 1993], [Bhandari and Roth, 1993], [Kelsey, 1997], [Nakamura et al., 2006], and [Damm and Lundberg, 2007]. A summary of those techniques is described in [Kalinowski and Travassos, 2008]. Based on the literature review, two techniques that seem to show themselves particularly useful to support defect causal analysis activities are Pareto charts and cause-effect (or Ishikawa) diagrams [Ishikawa, 1976]. They support, respectively, identifying the most common defect types and finding the causes for specific defect classes. Although cause-effect diagrams were cited by [Mays et al., 1990] as used in the manufacturing area, the first of the analyzed papers to use those diagrams in the context of software defect causal analysis appeared in The cause-effect diagram is used and/or suggested in many of the analyzed papers, including [Chernak, 1996], [Damele et al., 1996], [Grady, 1996], [Card, 1998], [van Moll et al., 2002], [Jacobs et al., 2004], [Card, 2005], [Jacobs et al., 2005] [Jalote and Agrawal, 2005], and [Wang et al., 2006]. Among the papers that cite pareto charts as a useful technique are [Card, 1998], [Hong et al., 1999], [van Moll et al., 2002], [Card, 2005] [Jalote and Agrawal, 2005], and [Wang et al., 2006] Defect Classification Schemes Two types of information about classification were extracted from the papers: defect information to be collected and defect types. Defect information to be collected. We noted a certain consensus among the authors on the relevant information to be collected about software defects in order to support defect causal analysis. Among the data considered relevant since the initial papers [Endres, 1975] [Jones, 1985] [Mays, 1990] and continuing to the more recent ones [Agrawal and Jalote, 2005] [Jantti et al., 2006] [Chang and Chu, 2007] [Damm e Lundberg, 2007] are: The moment (or phase) in which the defect was introduced. The moment (or phase) in which the defect was detected. Defect type. This information matches the three dimensions to classify defects suggested in [Card, 1998] and [Card, 2005]. None of the analyzed papers argued against the use of any of these dimensions to classify defects. However, other information is considered in some papers, according to the specific goals of the defect causal analysis approaches presented in them: Correction (effort and time) or severity (impact), is considered in many papers, for example [Endres, 1975] [Collofello e Gosalla, 1993] [Fairley, 1999] [Leszak et al., 2000] [Leszak et al., 2002] [Jantti et al., 2006] [Nakamura et al., 2006] and [Chang and Chu, 2007]. Moreover, severity is also considered in the papers that use ODC (Othogonal Defect Classification): [Bhandari et al., 1993] [Chernak, 1996]. Location (or module), is considered by many papers, such as [Endres, 1975], [Bhandari et al., 1993], [Bhandari e Roth, 1993], [Kelsey, 1997], [Leszak et al., 2000], [Leszak et al., 2002], [van Moll et al., 2002], [Nakamura et al., 2006], and [Chang and Chu, 2007]. 147

169 Aditional information found in two papers that use the ODC [Chillarege et al., 1992] classification scheme [Bhandari et al., 1993] [Chernak, 1996] includes: Trigger, which indicates how the defect was detected. If the defect was introduced while developing new functionality or while maintaining existing functionality. Defect types. Regarding the defect types, several different taxonomies could be found. The complete list of taxonomies in chronological order is reported in [Kalinowski and Travassos, 2008]. An excerpt of that list, with three most cited of the nine taxonomies found in the papers, follows: ODC taxonomy [Chillarege et al., 1992], with the following types: interface, function, build/package/merge, assignment, documentation, checking, algorithm, timing/serialization. Of the analyzed papers this taxonomy was used by [Bhandari et al., 1993] and [Chernak, 1996] it was also mentioned in some other papers, like [Card, 1998] [Card, 2005]. Taxonomy for defects used at Hewlett-Packard [Grady, 1996], containing several types of defects organized by development phase. For each type its nature or mode (missing, unclear, wrong, changed, or better way) are also determined. Taxonomy for requirements defects used at NASA, containing 13 types of requirements defects, used in [Hayes et al., 2006]. It represents a tailoring of the taxonomy described by Shull (1998) (which includes the defect types: ambiguity, omission, inconsistent information, incorrect fact, and extraneous information), reflecting the reality of NASA. In Leszak et al (2002) similar types of defects are referred to as the nature of the defect, and aggregated to more refined defect types. The great variety of taxonomies found reflects the argument of Card (2005), that the defect taxonomy should be created in such a way that it supports the specific analysis interests of the organization that is implementing defect causal analysis. This argument is reinforced by Jalote and Agrawal (2005), for instance, who used the same argument to justify the elaboration of a specific taxonomy for InfoSys Cause Classification Schemes Analyzing the different cause classification schemes listed in [Kalinowski and Travassos, 2008] it is possible to identify a consensus among the authors about the categories that should be considered for defect causes. Moreover, most of the categories contained in the different classification schemes can be easily mapped to the categories initially proposed by Ishikawa (1976) for manufacturing. The Ishikawa categories are suggested as a starting point for defect causal analysis approaches in [Card, 1998] and [Card, 2005]. They are the following: tools, input, people, and methods. However, it is important to highlight that the remaining schemes, considering the specific context of software, can bring contribute additional information by refining the Ishikawa scheme. For instance, an additional category considered in many schemes developed for analyzing software defects is lack of understanding of the requirements. This category can be considered a subcategory of people 3, but since in several cases [Endres, 1975] [Nakajo and Kume, 1991] [Hayes, 2006] many causes matched that category it could be helpful to consider it separately. Further suggestions 3 It could also be mapped to the input category, depending on the nature of the misunderstanding. 148

170 on subcategories identified in other schemes can be found in [Kalinowski and Travassos, 2008]. An interesting classification scheme is that cited in [Jalote and Agrawal, 2005], the five Ms and one E scheme [Robitaille, 2004]. The five Ms refer to the categories Material, Method, Manpower, and Measurement, and Machinery. The E refers to the Environment. According to Robitalle (2004) this scheme is commonly used in manufacturing. However, Jalote and Agrawal (2005) decided to adapt it to the context of software, and suggest the following categories: process, people, and technology. They mention that those are the factors with the highest impact on quality and productivity [Jalote, 2000] and [SEI, 1995]. Those categories again can be mapped to the Ishikawa categories, removing just the input category. Finally, the papers [Jacobs et al., 2004] and [Jacobs et al., 2005] present a category that is not obviously included in the Ishikawa categories, the organization. This category is related to organizational causes and not specifically to its processes. For instance, inadequate or unavailable organizational policies, improper geographical distribution of departments (for instance, communication problems do to different time zones), improper organizational structure (for instance, no employee responsible for configuration management), among others. It is important to mention that those papers focus on projects with globally distributed teams, and that this category seems to be especially useful in that context Knowledge Regarding Defect Causal Analysis In order to facilitate the application of the knowledge gathered from analyzing the papers, it was structured to separate generic knowledge about the entire process from the knowledge limited to specific activities and tasks. The following tables were generated: A table with generic knowledge regarding the entire process. One table for each of the defect causal analysis activities of the defect prevention process described in [Jones, 1985], [Mays, 1990], and [Mays et al., 1990]. As described before, those four activities are: (1) causal analysis meeting, (2) implementation of the actions, (3) stage kickoff, and (4) data collection and monitoring. Inside the causal analysis meeting group of knowledge subgroups were created for each of the six steps mentioned in [Card, 2005]: (1) selecting the sample, (2) categorizing the defects, (3) finding the systematic error, (4) finding the main causes, (5) elaborating action proposals, and (6) documenting meeting results. The complete tables of knowledge, organized by publication date, are available in the report that supports this paper [Kalinowski and Travassos, 2008]. It is important to mention that the knowledge described in the tables should be used considering the context in which it was generated, as described in the appendix of the report. The appendix lists the information extracted from each of the papers, together with a description of the knowledge and the type of study the paper presents. 3. Guidance to Efficiently Implement Defect Causal Analysis Based on the knowledge acquired and the analyses performed as a result of the systematic review some guidance to implement defect causal analysis could be elaborated. The guidance aims at providing reasonable answers to the questions listed in the introduction. These are questions commonly faced by professionals when trying to implement defect causal analysis in software organizations. Is my organization ready for defect causal analysis? What approach should be followed? How should defects be 149

171 categorized? How should causes be categorized? What are the expected costs and results of implementing defect causal analysis? The guidance is composed of unbiased evidence-based answers to those questions and is complemented by the tables of knowledge regarding the process and each of its activities, listed in [Kalinowski and Travassos, 2008]. Is my organization ready for defect causal analysis? The main requirement for applying defect causal analysis is collecting data regarding defects. However, as argued by Card (1993) and van Moll et al (2002), defect causal analysis benefits from having a defined process established for the projects. Given the potential benefits and return of investment [Mays et al., 1990] [Card, 1993] [Leszak et al., 2000] [Jalote and Agrawal, 2005], we recommend the implementation of defect causal analysis approaches even for lower maturity organizations, even though it is only required at the highest maturity levels of models such as MPS and CMMI. Defect causal analysis can help to improve the performance and capability of processes before those high maturity levels are achieved [Card, 1998] [Card, 2005]. What approach should be followed? Based on the scenario described in the previous section we believe that an efficient defect causal analysis approach could follow the traditional defect prevention approach [Jones, 1985], which has been used in early and recent approaches. As mentioned before, this process has shown itself of low cost and efficient in reducing defect rates in different organizational contexts. As suggested by Card (1993) the causal analysis meeting should focus on classes of defects, sampled before the causal analysis meeting. Among the specific techniques we suggest Pareto charts to identify the main defect classes to be analyzed and cause-effect diagrams to support identifying the main causes for the systematic errors that lead to those defect classes. Among the metrics to be collected to support defect causal analysis and understanding its results, based on the systematic review, we suggest the number of defects found per unit of size, the mean number of defects found per inspector per hour (if available), and the PIQ (Phase Input Quality) and POQ (Phase Output Quality) metrics defined by Damm and Lundberg (2007). The number of defects indicates efficiency in preventing defects, the PIQ and POQ metrics, on the other hand, provide further insight into the defect detection mechanisms efficiency. Those metrics could be placed under statistical control integrating defect causal analysis with statistical process control, providing a more precise and quantitative way of determining how the process performance and capability are affected by defect causal analysis. Defect causal analysis helps accomplish two goals of statistical process control: (1) controlling and stabilizing processes and (2) improving their performance and capability. As mentioned in [Florac and Carleton, 1999] the first of these goals deals with assignable (or special) causes. The existence of assignable causes can be detected by applying process stability tests, such as the ones described by Wheeler et al., (1992) to statistical process control charts. If the process is not stable, then defect causal analysis can help to find the assignable causes and implement actions that stabilize it. The second goal addresses the common causes for the process current performance and capability [Florac and Carleton, 1999]. This can be accomplished by applying defect causal analysis even if it the process is stable, for instance, after each development phase. Relating this to the capability maturity models MPS and CMMI, controlling and stabilizing processes is related to MPS maturity level B and CMMI maturity level

172 Improving the performance and capability on the hand is related to MPS maturity level A and CMMI maturity level 5. Our systematic review indicates that the most appropriate control charts for controlling defect data and supporting defect causal analysis are the U charts [Hong et al., 1999][Card, 2005]. U charts apply to data that has a Poisson distribution, with a varying area of opportunity (for instance, the size of a document) for an event to occur (for instance, detecting a defect) [Montgomery, 1991 apud Hong et al., 1999]. Individuals or XmR charts may be used, but are less sensitive. How should defects be categorized? Defect information to collect. Based on the information collected from the retrieved approaches and papers, we believe that an efficient defect causal analysis approach should consider at least the consensus information, which is: moment of introduction, moment of detection, and type of defect. Additionally, in our point of view, knowing the severity of the defects (or their impact) and their location could support defect causal analysis by identifying clusters of defects to support the selection of the samples to be analyzed and monitoring the efficiency of the defect causal analysis process itself. However, severity is largely an accident and the same mistake made in different contexts can have very different impacts. Finally, additional information, such as the trigger and if the defect is related to new functionality, can be used for specific situations, such as trying to improve detection mechanisms (when prevention is difficult to achieve), as done by [Chernak, 1996]. Moreover, once the cause of the defect is determined, a link between the defect and its cause should be established and the cause should be stored according to its own classification scheme. Defect types. The results of the systematic review suggest that an efficient defect causal analysis approach should use a taxonomy that considers the nature and the type of defect. The nature can be expressed using the categories described by Shull (1998), which can be tailored to specific contexts, as in [Hayes, 2006]. These categories (omission, ambiguity, inconsistent information, incorrect fact, extraneous information, and other) can be used in a generic way for the different artifact types generated throughout he software development lifecycle, as observed by Travassos et al (2001). For the defect type, a taxonomy should be created considering the specific goals of the organizations defect causal analysis approach, as suggested by Card (2005). Not having a defect type taxonomy in place at the organization the types considered by ODC [Chillarege et al., 1992], commonly used [Card, 2005], could serve as a starting point for further tailoring. How should causes be categorized? Given the consensus scenario regarding defect cause categories, we believe that the Ishikawa categories represent a good starting point [Ishikawa, 1976], as suggested by Card [Card, 1998] [Card, 2005], adding for the sake of completeness the category organization [Jacobs et al., 2004] [Jacobs et al., 2005]. The tailoring of the classification scheme can be done afterwards, by creating specific subcategories, based on the reality of the organization itself (taken for instance from the results of prior defect causal analyses). What are the expected costs and results of implementing defect causal analysis? The answer to this question helps to establish quantitative improvement goals for implementations of defect causal analysis. Based on the generic knowledge gathered regarding defect causal analysis approaches, its cost varies from 0.5 to 1.5 percent of the projects budget (including the implementations of the proposed actions), according 151

173 to data taken from IBM and Computer Science Corporation [Card, 2005]. In our point of view this is a very low cost, especially when considering the benefits, which have been reducing defect rates by over 50 percent (again considering data from IBM and Computer Science Corporation) [Card, 2005]. As a consequence rework effort and costs will be reduced while productivity is increased. Even though they measured the benefits in different ways (for instance, reduction of rework effort, reduction of specific defect types, among others), all of the analyzed papers showed positive results from implementing defect causal analysis. The papers describe experiences from a great range of software organizations, including: AG Communication Systems Corporation, Computer Science Corporation, Hewlett- Packard, IBM (several organizational units), InfoSys, Italtel SIT BUCT Línea UT, Lucent Technology, Motorola, and Philips Software Centre. 4. Conclusions Defect causal analysis has shown itself an inexpensive and high return means of product focused software process improvement [Kalinowski, 2007]. However, as mentioned by Card [2005], despite its advantages and wide industry adoption little academic research is being done in this area. Thus little knowledge has been generated and published. As a consequence professionals face many questions when trying to implement defect causal analysis in software organizations. A systematic review was conducted in order to provide unbiased and evidence-based answers to some of those questions [Kalinowski and Travassos, 2008]. Based on the results of the systematic review we were able to identify the defect causal analysis state of the art in an unbiased way and to provide some guidance on how to efficiently implement it in software organizations. Moreover, some opportunities for further investigation were identified. For instance, we found no approach allowing dynamic updates to the cause-effect relationships that reflect the reality of the organizational context, based on the results of the causal analysis itself. According to the results of the systematic review and to our knowledge this is first being addressed in the proposal described in [Kalinowski et al., 2008]. We believe that making the resulting guidance and knowledge available in the academic and software practitioners community could facilitate the implementation of defect causal analysis, complementing other valuable sources of information, such as [Card, 2005] and [SOFTEX, 2007b]. As the main contributions of this guidance we highlight the unbiased compilation of answers to commonly faced questions and lists of knowledge regarding the defect causal analysis process and its activities. References Al-Shehab, A. J., Hughes, R. T., Winstanley, G., Facilitating Organisational Learning through Causal Mapping Techniques in IS/IT Project Risk Management, LNCS, 3782 NAI, , Bhandari, I., Halliday, M., Tarver, E., Brown, D., Chaar, J., Chillarege, R., A Case Study of Software Process Improvement During Development, IEEE Trans. on Soft. Eng., 19 (12), , Bhandari, I., Roth, N., Post-process Feedback with and without Attribute Focusing: a Comparative Evaluation, in 'ICSE '93: Proceedings of the 15th Intl Conf. on Soft. Eng.', IEEE Computer Society Press, Los Alamitos, CA, USA, pp , Biolchini, J.; Mian, P.G.; Natali, A.C.; & Travassos, G.H. (2005), Systematic Review in Software Engineering: Relevance and Utility, Technical Report ES-679/05, PESC-COPPE/UFRJ. Available at Boehm, B., A view of 20th and 21st century software engineering, in 'ICSE '06: Proceeding of the 28th international conf. on Soft. Eng.', ACM Press, New York, NY, USA, pp , Brereton, P., Kitchenham, B. A., Budgen, D., Turner, M., Khalil, M., Lessons from applying the systematic literature review process within the software engineering domain. Journal of Systems and Software. Volume 80, Issue 4. Pages , Bush, M., Getting started on metrics - JPL productivity and quality, in 'ICSE '90: Proceedings of the 12th international conf. on soft. eng.', IEEE Comp. Soc. Press, Los Alamitos, CA, USA, pp ,

174 Card, D., Defect Analysis: Basic Techniques for Management and Learning, Advances in Computers, vol. 65, chapter 7, pp , Card, D., Learning from our mistakes with defect causal analysis, IEEE Software, 15(1), pp , Card, D., Defect Causal Analysis Drives Down Error Rates, IEEE Software 1/1993, Volume 10, Issue 4, 7/1993, p.98-99, Chang, C., Chu, C., "Defect Prevention in Software Processes: An Action-Based Approach", The Journal of Systems and Software, Vol. 80, issue 4, April 2007, pp , Chernak, Y., A statistical Approach to the Inspection Checklist Formal Synthesis and Improvement, IEEE Transactions on Software Engineering, 22(12), , Chillarege, R., Bhandari, I., Chaar, J., Halliday, M., Moebus, D., Ray, B., Wong, M.Y., Ortogonal Defect Classification A Concept for In-Process Measurement, IEEE Transactions on Software Engineering, vol. 18, pp , Collofello, J., Gosalla, B., Application of Causal Analysis to the Software Modification Process, Software Practice and Experience, 23(10), pp , Dalal, S. R., Horgan, J. R., Kettenring, J. R., Reliable Software and Communication: Software Quality, Reliability, and Safety, in 'ICSE '93: Proceedings of the 15th International Conference on Software Engineering', IEEE Computer Society Press, Los Alamitos, CA, USA, pp , Damele, G., Bazzana, G., Andreis, F., Aquilio, S., Process Improvement through Root Cause Analysis, in Proceedings of Third International Conference on Achieving Quality in Software, pp , Damm, L., Lundberg, L., Company-wide Implementation of Metrics for Early Software Fault Detection, Proc. of the 29th International Conference on Software Engineering (ICSE 07), Minneapolis, Dangerfield, O., Ambardekar, P., Paluzzi, P., Card, D., Giblin, D., Defect Causal Analysis: A Report from the Field, Proceedings of International Conference of Software Quality, American Society for Quality Control, Eckes, G., The Six Sigma Revolution: How General Electric and Others Turned Process Into Profits, John Wiley and Sons, Endres, A., An Analysis of Errors and Their Causes in Systems Programs", IEEE Transactions on Software Engineering, SE-1, 2, June 1975, pp , Fairley, R. E., Managing by the Numbers: a tutorial on quantitative measurement and control of software projects, in 'Proceedings of the 21st International Conference on Software Engineering, ICSE 99', IEEE Computer Society Press, Los Alamitos, CA, USA, pp , Florac, A.W., Carleton A.D., Measuring the Software Process: Statistical Process Control for Software Process Improvement, Pearson Education, Grady, R. B., Software Failure Analysis for High-Return Process Improvement Decisions, Hewlett- Packard Journal, 47 (4), 15-24, Gras, J.J., End-to-End Defect Modeling, IEEE Software, 21(5), , Hayes, J.H., Raphael, I., Holbrook, E.A., Pruett, D.M., A case history of International Space Station requirement faults, Proceedings of the11th IEEE International Conference on Engineering of Complex Computer Systems, Stanford University, California, Hong, G., Xie, M., Shanmugan, P., A Statistical Method for Controlling Software Defect Detection Process, Computers and Industrial Engineering 37 (1-2), pp , IEEE, 1990, IEEE Standard Glossary of Software Engineering Terminology, Standard 610, IEEE Press. ISO/IEC, ISO/IEC 12207: Information technology - Software life-cycle processes Amendment 2, Geneve: ISO, Int. Org. for Standardization and the Int. Electrotechnical Commission, Jacobs, J.C., van Moll, J.H., Krause, P.J., Kusters, R.J., Trienekens, J.J.M., Brombacher, A., Exploring Defect Causes in Products Developed by Virtual Teams, Journal on Information and Software Technology, 47( 6), , Jacobs, J.C., van Moll, J.H., Krause, P.J., Kusters, R.J., Trienekens, J.J.M., Effects of Virtual Development on Product Quality: Exploring Defect Causes, Proceedings of the 11th Annual International Workshop on Software Technology and Engineering Practice (STEP 04), Jalote, P., Agrawal, N., Using Defect Analysis Feedback for Improving Quality and Productivity in Iterative Software Development, (Invited paper, 3rd International Conference on Information and Communication Technology, ICICT, 2005.), pp , Cairo, Jantti, M., Toroi, T., Eerola, A., Difficulties in establishing a defect management process: A case study, Lecture Notes in Computer Science (including subseries Lecture Notes in Artificial Intelligence and Lecture Notes in Bioinformatics) 4034 NCS, pp , Jones, C.L., A process-integrated approach to defect prevention, IBM Systems Journal, 24(2), , Kalinowski, M., Travassos, G.H., Uma revisão sistemática a respeito de análise causal de defeitos de software, technical report available at COPPE/UFRJ, Kalinowski, M., Travassos, G.H., Card, D.N., Towards a Defect Prevention Based Process Improvement Approach, 34 th EUROMICRO Conference, IEEE Computer Society, Kalinowski, M., Defect Causal Analysis: An Opportunity for Product Focused Software Process Improvement, Invited paper at the V CICIS (Congreso Internacional de Computación y Ingenieria de Sistemas), Moquegua, Peru, Keene, J., Managing Software Reliability and Support Costs, in 'Proceedings of the Leesburg Workshop on Reliability and Maintainability Computer-Aided Engineering in Concurrent Engineering', pp ,

175 Kelsey, R.B., Integrating a Defect Typology with Containment Metrics, ACM SIGSOFT Software Engineering Notes, 22(2), 64-67, Kitchenham, B.A., Procedures for Performing Systematic Reviews, Joint Technical Report Keele University and National ICT Australia Ltd., Krause, P., Freimut, B., Suryn, W., New Directions in Measurement for Software Quality Control, in 'Proc. of the 10th Int. Workshop on Soft. Tech. and Eng. Practice, STEP 2002', pp , Lederer, A.L., Prasad, J., A Causal Model for Software Cost Estimating Error, IEEE Transactions on Software Engineering, 24 (2), pp , Leszak, M., Perry, D., Stoll, D., A Case Study in Root Cause Defect Analysis, in 'International Conference on Software Engineering, ICSE 2000', pp , Leszak, M., Perry, D. E., Stoll, D., Classification and evaluation of defects in a project retrospective, Journal of Systems and Software, 61( 3), , Li, Z., Tan, L., Wang, X., Lu, S., Zhou, Y., Zhai, C., Have things changed now? An empirical study of bug characteristics in modern open source software, Proceedings of ASID'06: 1st Workshop on Architectural and System Support for Improving Software Dependability, pp , Linger, R. C., Cleanroom Software Engineering for Zero-Defect Software, in 'ICSE '93: Proceedings of the 15th International Conference on Software Engineering', IEEE Computer Society Press, Los Alamitos, CA, USA, pp. 2-13, Mays, R.G., Applications of Defect Prevention in Software Development, IEEE Journal on Selected Areas in Communications, Vol.8, No.2, pp , February Mays, R.G., Jones, C.L., Holloway, G.J., Studinski, D.P., Experiences with Defect Prevention, IBM Systems Journal, 29(1), pp. 4-32, van Moll, J., Jacobs, J., Freimut, B., Trienekens, J., The Importance of Life Cycle Modeling to Defect Detection and Prevention, in '10th International Workshop on Software Technology and Engineering Practice, STEP 2002', pp , Nakajo, T. & Kume, H. (1991), A Case History Analysis of Software Error Cause-Effect Relationships, IEEE Transactions on Software Engineering, 17(8), , Nakajo, T., Foolproofing and Quality Feedback: Keys of Process-Based Management, Proceedings of the Fifteenth Annual International Computer Software and Applications Conference, COMPSAC'91, IEEE Computer Society Press, , Nakamura, T., Hochstein, L., Basili, V.R., Identifying Domain-Specific Defect Classes Using Inspections and Change History, Proceedings of the 2006 International Symposium on Empirical Software Engineering (ISESE), Sept , Rio de Janeiro, Brazil. p , Oshana, R., Coyle, F.P., Implementing Cleanroom Software Engineering into a Mature CMM-Based Software Organization, Proceedings of the 19th International Conference on Software Engineering, ICSE 97, ACM Press, New York, NY, USA, pp , Paul, R. A., Bastani, F.; Yen, I., Challagulla, V. U., Defect-based Reliability Analysis for Mission- Critical Software, Proceedings of the IEEE Computer Society's International Computer Software and Applications Conference, pp , Philips, R.T., An approach to software causal analysis and defect extinction, in Proceedings of the IEEE Globecom Conference, pp , Poppendieck, M., Poppendieck, T., Lean Software Development: An Agile Toolkit, Addison Wesley Professional, Pratt, W. M., Experiences in the Application of Customer-Based Metrics in Improving Software Service Quality, Conf. Record of the International Conference on Communications, pp , Robitaille, D., Root Cause Analysis Basic Tools and Techniques, Paton Press, Rombach, D., Endres, A., A Handbook of Software and Systems Engineering Empirical Observations, Laws and Theories, Pearson Addison Wesley, Rosen, C., PLUNGE DA: A Case Study, ACM SIGSOFT Soft. Eng. Notes, 22(2), pp , SEI, CMMI for Development (CMMI-DEV), Version 1.2, Technical report CMU/SEI-2006-TR-008. Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University, Shull, F., Developing Techniques for Using Software Documents: A Series of Empirical Studies, Ph.D. thesis, University of Maryland, College Park, SOFTEX, MPS.BR Melhoria de Processo do Software Brasileiro Guia Geral, version 1.2, June 2007, available at a. SOFTEX (Rocha, A.R.C., Montoni, M.A., Souza, G.S., Kalinowski, M., Scalet, D.), MPS.BR Melhoria de Processo do Software Brasileiro Guia de Implementação do Nível A, version 1.0, June 2007, available at b. Travassos, G.H., Shull, F., Carver, J., Working with UML: A Software Design Process Based on Inspections for the Unified Modeling Language, in: Advances in Computers, vol. 54, Academic Press, Troster, J., Henshaw, J., Buss, E., Filtering for Quality, in 'Proceedings of the 1993 Conf. of the Centre for Advanced Studies on Collaborative Research, CASCON 93', IBM Press, pp , Vantine, W., Benfield, K., Pritts, D., Ballard, K., Evaluating and Incorporating New Age Software Technology for Identifying Systemic Root Causes, in: Proceedings of the Joint ESA-NASA Space Flight Safety Conference, ESTEC, ESA SP-486, Noordwijk (NL), pp , Walia, G., Carver, J., Philip, T., Requirements Error Abstraction and Classification: An Empirical Study, Proc. Int. Symposium on Empirical Soft. Eng. (ISESE), Sept , Rio de Janeiro, Brazil,

176 Wang, Q., Jiang, N., Gou, L., Liu, X., Li, M., Wang, Y., BSR: A Statistic-based Approach for Establishing and Refining Software Process Performance Baseline, in 'ICSE '06: Proceeding of the 28th Int. Conf. on Software Engineering', ACM Press, New York, NY, USA, pp , Wheeler, D.J., Chambers, D.S., Understanding Statistical Process Control, 2ed, Knoxville, Tenn., SPC Press, Wigglesworth, J., Surveys as a Method for Improving the Development Process, in 'CASCON '93: Proc. conf. of the Centre for Advanced Studies on Collaborative research', IBM Press, pp , Wohlin, C., Host, M., Ohlsson, M., Understanding the Sources of Software Defects: A Filtering Approach, in '8th Int. Workshop on Program Comprehension, 2000, IWPC 2000', pp. 9-17,

177 156

178 Inspeção de Qualidade em Descrições de Casos de Uso: Uma Proposta de Modelo e Artefatos José Eduardo Zindel Deboni 1, Rosângela Gregolin 1 1 Instituto de Pesquisas Tecnológicas (IPT) Av. Prof. Almeida Prado São Paulo SP Brazil deboni@voxxel.com.br, rgregolin@yahoo.com.br Abstract. Use case models are used as a method for capturing and specifying functional requirements. However, its use do not guarantee a good quality of specification, because the use of natural language gives way to errors, such as omissions, ambiguities, misunderstandings, and imprecision. With the goal to increase quality in the use case models, this paper proposes a checklist for orientation in the elaboration and inspection of use case descriptions. Techniques for measuring the use case quality are also suggested. An application of the proposal is made. Resumo. Modelos de caso de uso são utilizados como um método de captura e especificação de requisitos funcionais. Todavia, sua utilização não garante uma especificação de boa qualidade, pois sua elaboração, feita em sua maior parte em linguagem natural, dá margem à presença de diversos defeitos, tais como omissões, ambigüidades, pouca compreensibilidade e imprecisão. Com o objetivo de aumentar a qualidade dos casos de uso, este trabalho propõe um checklist para a orientação na elaboração e inspeção de descrições de caso de uso. Técnicas para medição da qualidade do caso de uso também são sugeridas. Uma aplicação da proposta exemplifica a inspeção. 1. Introdução O caso de uso é um meio para capturar e especificar requisitos de um sistema, definindo seu comportamento de acordo com as necessidades dos atores: usuários e outras entidades que interagem com o sistema. O caso de uso deve produzir um resultado de valor para o ator, representando as grandes funcionalidades do sistema. O modelo de caso de uso é composto de diagramas e descrições de casos de uso, e deve descrever com detalhes as funcionalidades do sistema. Todos os requisitos funcionais descritos são utilizados como entrada para diversas atividades no desenvolvimento de software, tais como o projeto, codificação e testes. Portanto, a qualidade do modelo de caso de uso tem um impacto significativo no processo de desenvolvimento e na qualidade do restante do produto [Jacobson 1992] A descrição de caso de uso é elaborada, em geral, em linguagem natural, o que a torna simples de utilizar e de entender. No entanto, a aparente simplicidade pode representar um perigo para a precisão e clareza, na medida em que pode levar equipes de desenvolvimento a cometer erros como ambigüidades, redundâncias e omissões na 157

179 descrição, comprometendo os eventuais benefícios do seu uso [Fogarty 2004]. Embora existam diversas publicações de como construir bons modelos de caso de uso, sua qualidade pode aumentar se, além de seguidas as diretrizes corretas para elaborá-los, também for aplicada uma inspeção de qualidade, como sugerem Anda e Sjoberg (2002). A inspeção é uma atividade de teste de software baseada no exame visual de produtos do desenvolvimento para detectar defeitos, violações de padrões de desenvolvimento, entre outros problemas [IEEE 1990]. Shull et al (2000) mostram ainda que a inspeção é uma maneira sistemática de ensinar a equipe de desenvolvimento como construir um software melhor, atuando também de forma preventiva à ocorrência de defeitos. O objetivo deste trabalho é desenvolver um instrumento para apoiar a inspeção de qualidade das descrições dos casos de uso, e que possa, ao mesmo tempo, ser utilizado como subsídio para a orientação de equipes de desenvolvimento na elaboração de descrições de caso de uso com qualidade. Este instrumento, fundamentado principalmente na ferramenta de um checklist, facilita o encontro de defeitos nas descrições dos casos de uso, antes que elas passem para a próxima etapa do desenvolvimento do software. Visto que o caso de uso é utilizado nas etapas seguintes do decorrer do processo de desenvolvimento de software, aumentar sua qualidade significa aumentar a qualidade do software como um todo, contribuindo para a detecção de falhas antecipada onde se estima que o custo de correção é menor. É importante considerar, no entanto, que a proposta visa detectar se os requisitos foram especificados da forma certa e não se os requisitos certos foram especificados, o que significa que mesmo que um caso de uso obtenha o aceite da inspeção proposta, isso não significa que ele traduza os requisitos corretos para o usuário. A validação de requisitos está fora do escopo deste trabalho. 2. Considerações sobre inspeção e o checklist Para Gilb e Graham (1993), a inspeção consiste em um valioso investimento no esforço de desenvolvimento de um software, já que há um aumento na produtividade nas fases posteriores à inspeção que se utilizarão do produto inspecionado: redução de testes de execução, redução na manutenção, diminuição do prazo de entrega do software e redução do total de defeitos. Consideram que uma inspeção é capaz de descobrir de 60% a 80% de defeitos. Shull et al. (2000) propõem que o processo de inspeção seja constituído das etapas de: planejamento, detecção de defeitos, registro dos defeitos encontrados e correção dos defeitos, e afirma que inspeções efetuadas por um único inspetor podem ser tão úteis quanto uma reunião de vários inspetores. O checklist é uma ferramenta de inspeção de qualidade que apresenta as diretrizes para a leitura de um determinado artefato com o objetivo de encontrar defeitos. Consiste em uma lista de questões que o inspetor deve identificar se estão presentes ou não no artefato em teste [Travassos e Mafra 2005]. Para Laitenberger et al. (2002), o checklist é a técnica de leitura mais empregada para a detecção de defeitos no contexto de inspeção de software. Anda e Sjoberg (2000) enfatizam que essa popularidade se dá pela facilidade de sua aplicação. 158

180 Gilb e Graham (1993) sugerem que o checklist deva ser derivado de regras de elaboração do produto a ser inspecionado, incluindo, a cada questão, uma referência à regra da qual a questão é derivada. Essas regras devem ser informadas previamente ao autor do produto a ser inspecionado. É conveniente que o conjunto de questões de um checklist não deva exceder uma única página, mantendo-se no máximo em 25 questões. Por esta razão, as questões devem se concentrar nos maiores defeitos. As questões devem ser diretas e objetivas, e devem esclarecer as regras de elaboração do produto inspecionado. Também devem ser formatadas de forma que a resposta negativa represente a identificação de um problema. Além disso, cada questão deve conter sugestões de níveis de severidade, dependendo do impacto que o defeito encontrado pode causar. 3. Modelo e Artefatos para inspeção da qualidade Para a elaboração do checklist de descrições de casos de uso foi, inicialmente, criado um modelo de qualidade com os atributos de qualidade e as regras de elaboração de uma descrição de caso de uso. A partir desse modelo, deriva-se o checklist que verifica se as descrições de caso de uso inspecionadas atendem ao modelo de qualidade Elaboração de um modelo de qualidade Para a criação do modelo de qualidade, foram analisados e comparados os atributos de qualidade e suas características dos modelos de qualidade do IEEE (1998), de Davis et al. (1993) e de Fabbrini et al. (2001), resumidos na Tabela 1. A Tabela 1 compara os atributos de qualidade. Nela busca-se sintetizar em uma definição única os diversos atributos de qualidade empregados por cada modelo de qualidade, para dela se extrair os atributos de qualidade a serem empregados para elaborar o modelo de qualidade da descrição de casos de uso e dele o checklist para apoiar a inspeção. Atributo de qualidade (IEEE, 1998) Tabela 1. Comparativo de modelos de qualidade de especificação Atributo de qualidade (DAVIS et al., 1993) Atributo de qualidade (FABBRINI et al., 2001) 159 Definição Não ambigüidade Não ambigüidade Compreensibilidade Termos que dão margem a múltiplas interpretações devem constar em glossário, com clara definição. Completeza Contemplação de todos os requisitos. Completeza Definição de resposta do sistema para as entradas de dados em todas as situações, considerando valores válidos e inválidos. Completeza Consistência As referências devem estar numeradas e os documentos anexos devem estar referenciados. Completeza Compreensibilidade Deve haver explicações para todas as figuras, tabelas, diagramas,

181 acrônimos e unidades de medida. Correção Correção A especificação deve representar exatamente o que o sistema deve fazer. Compreensibilidade Os requisitos devem ser entendidos pelos envolvidos com o mínimo de Verificabilidade Consistência Rastreabilidade para frente Rastreabilidade para trás Modificabilidade Modificabilidade Classificação por importância Verificabilidade, Precisão Consistência interna e consistência externa Alcançabilidade, Prototipação Independência de ferramenta Rastreabilidade Modificabilidade, Não redundância Armazenamento eletrônico Classificação por importância e por estabilidade Referência à versão Testabilidade Testabilidade Compreensibilidade 160 explanação. Todo requisito deve ser preciso, para verificação futura se foi atendido. A especificação deve evitar presença de opiniões pessoais, palavras que indicam opção, sentenças com verbos que não exprimem ações, menção a funcionalidades ainda não especificadas. Os requisitos não podem se conflitar com requisitos do mesmo sistema ou de sistemas externos. A especificação deve ser acompanhada de protótipo de interface. Deve haver mais de uma ferramenta de interface capaz de viabilizar o requisito Cada requisito tem que ter um único nome ou nº de referência. Cada requisito tem que ter sua origem em documentos iniciais do projeto. A especificação deve ser organizada de forma a ser facilmente modificável. Deve ser simples, evitando redundâncias. A especificação deve estar eletronicamente armazenada, de forma organizada. Os requisitos devem ser classificados para ajudar na priorização de esforços O requisito deve ter referência a qual versão será implementado. As sentenças devem ter quantidade limitada de palavras e evitar mais de um verbo principal. Após o comparativo, os atributos selecionados para compor o modelo de qualidade das descrições de caso de uso são: completeza, compreensibilidade, precisão, não ambigüidade, consistência, independência de ferramenta e de interface, rastreabilidade, e objetividade. O atributo prototipação sugerido por Davis et al. (1993) recebeu o nome de compreensibilidade, visto ser a compreensibilidade o objetivo da prototipação. Também foi classificado como compreensibilidade o atributo de modificabilidade, que define a característica de que a especificação deve evitar

182 redundâncias, assim como conter índices para aumentar a compreensibilidade e facilidade de manutenção [IEEE 1998]. Os atributos de classificação por importância e referência à versão de Davis et al. (1993) não foram considerados no contexto restrito da inspeção proposta, por terem uma utilização voltada para o gerenciamento do processo de desenvolvimento e não restrita à qualidade da descrição de caso de uso. 3.2 Modelo de Qualidade para Descrição de Caso de Uso Com base nos atributos selecionados e derivados da Tabela 1, e adicionados das diretrizes de elaboração de modelo de caso de uso de Spence e Bittner (2003), Jacobson et al (1992), Jacobson (2003), Gottesdiener (2003), OMG (2007) e Ambler (2003), criou-se um modelo de qualidade, descrito a seguir: Atributo de Qualidade 1: Completeza Regra 1.1. A descrição de caso de uso deve ser a especificação detalhada de um caso de uso representado no diagrama com o mesmo nome da descrição de caso de uso. Um modelo de caso de uso, portanto, quando chega na etapa de descrição do caso de uso, necessita ter o diagrama. Regra 1.2. A descrição de caso de uso deve conter minimamente o nome do caso de uso, nome dos atores, fluxo básico e alternativo completos. Regra 1.3. A descrição de caso de uso deve especificar o fluxo básico e alternativo da forma mais completa possível, prevendo no fluxo alternativo decisões alternativas de usuários e exceções. Atributo de Qualidade 2: Compreensibilidade Regra 2.1. As sentenças devem evidenciar um diálogo exato entre ator e sistema. Isto significa que para que o sistema execute uma ação, é necessária uma ação invocativa do ator, e para que o ator execute uma ação, é necessária uma ação de disponibilidade do sistema, para possibilitar a ação ao ator. Regra 2.2. A escrita deve ser em voz ativa ao invés de passiva. (Exemplo de voz ativa: Atendente seleciona opção de finalizar pedido. Exemplo de voz passiva: Opção de finalização de pedido é selecionada pelo atendente). Regra 2.3. A escrita deve ser em tempo presente ao invés de passado ou futuro. Regra 2.4. É recomendável que a escrita de fluxos longos, que ocupem mais de uma página, utilize subtítulos para comunicar as idéias chaves. Regra 2.5. A descrição de caso de uso com fluxo de mais de uma página deve conter índice e paginação. Regra 2.6. As tabelas, figuras, acrônimos devem ser seguidas de explicações que facilitem o entendimento. Regra 2.7. A descrição deve tratar o quê o sistema deve fazer e não como fazer, e, portanto, devem evitar presença de especificações de código de sistema. Regra 2.8. A descrição deve definir requisitos de sistema e não de negócio, evitando descrever o que ocorre fora do sistema sem ação direta ao sistema. 161

183 Regra 2.9. A presença dos artefatos de suporte aumenta a compreensabilidade: glossário, protótipo de interface, especificação de requisitos não funcionais, modelo de domínio, regras de negócio separadas do fluxo básico e alternativo do caso de uso. Regra O fluxo alternativo, quando causa desvio da compreensão do fluxo básico e tem mais de uma linha, deve ser descrito separadamente do fluxo básico. Regra A descrição do caso de uso deve conter breve descrição, com especificação clara do propósito do caso de uso. Atributo de Qualidade 3: Precisão Regra 3.1. Os termos devem ser precisos e quantificáveis, evitando termos impossíveis de quantificação, como muito, pouco, adequado, claro, fácil longo, curto, rápido etc. Regra 3.2. Os termos que indicam opção: possivelmente, alternativamente, no caso de, se, só podem ocorrer se especificarem fluxo alternativo. Atributo de Qualidade 4: Não ambigüidade Regra 4.1. Termos que dão margem a mais de uma interpretação devem constar em glossário, de forma clara. Atributo de Qualidade 5: Consistência Regra 5.1. Os termos utilizados devem ser iguais quando se referem à mesma coisa, evitando-se, por exemplo, ora utilizar-se o termo pedido e ora utilizar-se o termo requisição. Regra 5.2. Qualquer referência do caso de uso deve ser corretamente numerada ou nomeada, tanto na origem como no destino para que permita fácil localização. Atributo de Qualidade 6: Independência de ferramenta e de interface Regra 6.1. A descrição de caso de uso deve evitar termos que indicam dependência de ferramenta ou interface de usuário, como por exemplo, presença do termo clicar, aba, botão etc. Atributo de Qualidade 7: Rastreabilidade Regra 7.1. As ações especificadas na descrição do caso de uso devem ser identificadas preferencialmente através de numeração para permitir a rastreabilidade ao longo do processo. Atributo de Qualidade 8: Objetividade Regra 8.1. As sentenças devem ser objetivas e evitar redundâncias, evitando-se sentenças redundantes, longas e excessivas, que poderiam ser reduzidas sem perder o sentido. Também se devem evitar sentenças desnecessárias e fora do escopo do problema Checklist para Descrição de Caso de Uso Com base no modelo de qualidade para descrição de caso de uso, cria-se um artefato para inspeção da descrição de caso de uso na forma de um checklist, elaborando 162

184 questões que buscam localizar não-conformidades ao modelo de qualidade. O artefato se apresenta na Tabela 2. Para cada questão, é sugerida uma classificação do impacto para o defeito encontrado, categorizados em impacto alto (A), médio (M) e baixo (B). A classificação do impacto é uma proposta que pode ser reavaliada pela equipe para cada fase do desenvolvimento, tipo de sistema a ser desenvolvido e objetivos da aplicação da inspeção. Como critérios para a sugestão de impacto alto, foram considerados defeitos que afetam a compreensibilidade de forma mais significativa como a falta de coerência entre a descrição e o diagrama, a falta de definição clara de termos ambíguos em glossário, a ausência do protótipo de interface, e defeitos que afetam a completeza. Como critérios para o impacto médio, foram considerados defeitos que afetam a qualidade do caso de uso de forma considerável, mas num grau menos importante que os defeitos de impacto alto. Como critérios para o impacto baixo, foram considerados defeitos que, se corrigidos, aumentariam a qualidade do caso de uso, mas não impedem a compreensibilidade geral. Tabela 2. Checklist de descrição de caso de uso Questão Regra Impacto 1. A descrição de caso de uso é a de um caso de uso representado no diagrama? 1.1 A 2. A descrição de caso de uso contém nome do caso de uso, nome do ator, fluxo básico e alternativo? (Se não houver um fluxo alternativo definido, considerar se ele está especificado dentro do fluxo básico) 1.2 A 3. A descrição de caso de uso com mais de uma página contém índice e paginação? 2.5 B 4. Se houver tabelas ou figuras, elas têm explicação adicional de forma que fiquem compreensíveis para o leitor? 2.6 B 5. Se houver referências, essas são numeradas ou nomeadas da mesma forma na origem (descrição de caso de uso) e no destino (a própria referência)? 5.2 B 6. As frases representam um diálogo entre ator e sistema, evidenciando a ação do ator e a resposta do sistema? 2.1 M 7. As frases se utilizam de subtítulos para comunicar as idéias chaves dos fluxos de forma mais clara? 2.4 B 8. As frases são construídas em voz ativa? (ex.: Sistema valida a quantia informada em vez de A quantia informada deve ser validada pelo sistema ). 2.2 B 9. As frases utilizam o tempo presente? 2.3 B 10.São evitados termos sem quantificação precisa, como muito, pouco, adequado, claro, fácil longo, curto, rápido etc? 3.1 M 11.São evitados termos que indicam opção, como possivelmente, alternativamente, no caso, se, etc, sem especificar um fluxo alternativo? 3.2 M 12.Os termos passíveis de mais de uma interpretação constam em glossário, com clara definição? 4.1 A 13.Uma vez utilizado um termo, ele é mantido para referenciar-se ao mesmo elemento? 5.1 M 14.São evitados termos que indicam a prematura especificação de interface, tais como clicar botão etc? 6.1 B 15.As funcionalidades se restringem ao quê o sistema deve fazer e não em como, 2.7 M 163

185 evitando a definição explícita de código na especificação? 16.A descrição evita requisitos de negócio sem ação direta ao sistema? 2.8 M 17.Há presença de breve descrição ou resumo no início da descrição de caso de uso, que especifique de forma clara o seu propósito? 2.11 B 18.O fluxo básico está aparentemente completo, isto é, há inexistência de evidências claras de incompleteza na especificação? 1.3 A 19.O fluxo alternativo está aparentemente completo, isto é, há inexistência de evidências claras de incompleteza na especificação? 1.3 A 20.As frases são numeradas para que possibilitem a rastreabilidade? 7.1 M 21.As frases procuram ser objetivas, evitando redundâncias ou presença de informações evidentemente desnecessárias? 8.1 M 22.O caso de uso é acompanhado de protótipo de interface a fim de aumentar a sua compreensibilidade? 2.9 A 23.O caso de uso é acompanhado de especificação de requisitos não funcionais separadas do fluxo de eventos do caso de uso ou em documento de especificação suplementar? 2.9 M 24.O caso de uso é acompanhado de modelo de domínio, mostrando os relacionamentos entre os principais conceitos do sistema, a fim de aumentar a sua compreensibilidade? 2.9 M 25.Se houver regras de negócios associadas, estas estão separadas dos fluxos de evento do caso de uso ou em documento de especificação de regras de negócios? 2.9 B 3.3. Artefato de Registro de Inspeção Para registrar os defeitos encontrados quando da aplicação do checklist, e para que sirvam de base para uma medida da qualidade, propõe-se o artefato de registro de inspeção apresentado na Tabela 3. Visto que o termo defeito pode causar desconforto e resistência por parte dos autores de produtos inspecionados, sugere-se no registro a substituição do termo por não-conformidade, baseado na norma ISO [ABNT 2002], que fornece orientação sobre a gestão de programas de auditoria e propões que registros que não atendam aos critérios da auditoria sejam classificados como não-conformidade. Tabela 3. Registro de inspeção em descrição de caso de uso Nome do caso de uso: Data da inspeção: Responsável pela inspeção: Hora inicial: Hora final: Tempo despendido: Quantidade de páginas inspecionadas: Nº. da Impacto questão (A/M/B) N/A Sim Não Qtde Registros de não-conformidades Observações (Localização, obs.) Outras Observações: Após a identificação da descrição de caso de uso a ser inspecionada, registra-se para cada questão do checklist, na forma de linhas: o impacto daquela questão obtido na 164

186 Tabela 1, as não-conformidades encontradas em cada questão, onde N/A (não ser aplica) indica que a questão não se aplica ao produto inspecionado, S (sim) indica que o produto inspecionado atende à questão e N (não) indica que o produto não atende à questão e, portanto, caracteriza um defeito. Alguns tipos de defeitos podem ocorrer mais de uma vez na descrição, e por isso a quantidade encontrada deve ser registrada. Uma coluna permite que o inspetor faça observações em cada item inspecionado. 4. Medição da Inspeção A busca de uma técnica para a medição da inspeção é importante para se obter um resultado de aceite para o produto inspecionado e prover uma noção mais clara e confiável da qualidade de um caso de uso, que de outra forma seria baseada apenas na intuição. Mora e Denger (2003) efetuaram amplo levantamento de publicações de trabalhos no campo de medições de qualidade de especificação de requisitos e constataram de que não existe o consenso de uma medição padronizada nesse campo. Propõe-se uma técnica de medição da inspeção da descrição de caso de uso com base nos resultados da aplicação do checklist. Esta medição pode ajudar na criação de critérios objetivos de aprovação ou reprovação dos casos de uso inspecionados. A Tabela 4 descreve um artefato de registro dos defeitos encontratos e permite obter um resultado quantitativo de cada descrição de caso de uso do modelo inspecionado. Critério de aceite (em %): Tabela 4. Registro para a medição da inspeção Impacto Peso Qtde de questões aplicadas Alto Médio Baixo Qtde de nãoconformidades encontradas Peso total 165 Peso das nãoconformidades Total TotalPT = TotalNC = Resultado quantitativo MQ = Descrição do resultado quantitativo: (Aprovada ou Reprovada) O critério de aceite da descrição refere-se a um percentual máximo de defeitos que o produto inspecionado poderá ter e que será obtido pela somatória da coluna de resultado quantitativo. Se o resultado quantitativo ultrapassar o critério de aceite, não obterá um aceite da inspeção, sendo assim reprovado. Pode-se, por exemplo, usar um critério de maior tolerância nas fases preliminares de um projeto e aumentar o rigor, diminuindo a tolerância em fases mais avançadas do projeto. Para cada nível de impacto devem ser registrados: o peso atribuido para aquele tipo de defeito, o número de questões que foram classificadas com aquele nível de impacto e o número de não conformidades encontradas naquele nível de impacto. A coluna Peso total é o resultado da multiplicação do peso com o número de questões aplicadas. A coluna de Peso das não-conformidades é o resultado da multiplicação da coluna de Peso pela coluna de Qtde de não-conformidades encontradas. O resultado quantitativo da medida da qualidade (MQ) refere-se a um percentual do peso das não-conformidades encontradas em relação ao peso das questões aplicadas,

187 seguindo a seguinte fórmula: Onde: MQ = TotalNC*100/TotalPT TotalNC = Somatória do Total do peso das não-confomidades e TotalPT = Somatória do Total do peso das questões aplicadas. A descrição do resultado quantitativo compara MQ com o critério de aceite préestabelecido. Isto é, se o resultado quantitativo for menor ou igual ao critério de aceite, a descrição do caso de uso é aprovada, caso contrário é reprovada. 8. Avaliação experimental do checklist de inspeção Para avaliar a inspeção proposta, realizou-se uma aplicação com três estudantes de pósgraduação em engenharia de software, que foram apresentados ao checklist a fim de atuarem como inspetores. Duas descrições de casos de uso extraídos de dois modelos de caso de uso de projetos reais de sucesso foram avaliadas pelos estudantes. O objetivo da aplicação foi o de avaliar a facilidade de entendimento e uso do checklist, assim como a sua precisão pela coerência das respostas dos inspetores. A opinião geral do grupo foi de que a aplicação do checklist foi fácil de executar e que o entendimento das questões ocorre sem dificuldade. A forma de elaboração do checklist, em uma única página, a objetividade das questões e as regras detalhadas sobre cada item a ser inspecionado, facilitam a aplicação do checklist. O tempo médio da aplicação foi de 20 minutos para cada descrição, composta de cerca de sete páginas cada. Na descrição do primeiro caso de uso, 21 questões foram aplicadas e foram encontradas, na média, 8 não-conformidades, levando a uma MQ que varia de 26% a 30% como mostra a Tabela 5. Como o critério adotado foi de 40% a descrição do primeiro caso de uso foi aprovada por todos. Tabela 5. Resumo das medições de qualidade da aplicação em caso de uso nº1 Inspetor Número de nãoconformidades encontradas Peso TotalNC MQ Resultado do diagrama de caso de uso ,19% Aprovada ,95% Aprovada ,57% Aprovada A segunda descrição do caso de uso permitiu aplicar 22 questões. A Tabela 6 descreve um resumo das medições de qualidade obtidas da aplicação do checklist pelos 3 inspetores. Neste exemplo houve um entendimento pelo 3º inspetor de que a questão 14 não foi atendida em diversos momentos da descrição. Observa-se que apesar do rigor diferenciado do inspetor, o resultado final não se alterou, dando indícios que o modelo pode gerar uma independência do resultado em relação ao inspetor. 166

188 Conforme exposto na Tabela 6, a descrição de caso de uso foi aprovada nas três inspeções, pois as inspeções obtiveram percentuais de defeitos inferiores ao critério de aceite, que é de 40%. Importante ressaltar que todos os impactos sugeridos, assim como os pesos e critério de aceite de 40%, são propostas passíveis de serem adequadas a cada aplicação. Tabela 6. Resumo das medições de qualidade da aplicação em caso de uso nº2 Inspetor Número de nãoconformidades encontradas Peso TotalNC MQ Resultado do diagrama de caso de uso ,63% Aprovada ,63% Aprovada ,58% Aprovada 9. Conclusões e perspectivas de trabalhos futuros Embora o modelo de caso de uso seja amplamente utilizado como um método de especificação de requisitos funcionais, sua utilização não garante uma especificação de boa qualidade, já que as descrições em linguagem natural dão margem à presença de diversos defeitos. Objetivando proporcionar a melhoria da qualidade dos modelos de caso de uso, este trabalho propõe um checklist como subsídio para a orientação de equipes de desenvolvimento na elaboração de descrições de caso de uso e para que clientes utilizem-no para a inspeção de qualidade destas descrições. O checklist proposto sugere uma classificação dos defeitos em graus de severidade, o que combinado com as respostas do checklist possibilita associar uma medida da qualidade da descrição de caso de uso inspecionada. Em conjunto com um critério pré-definido de aceite, pode-se obter um resultado objetivo da aprovação ou reprovação da descrição de caso de uso. Esta medida não é absoluta e deve ser motivo de ajustes preliminares para cada equipe de desenvolvimento antes de poder ser aplicada amplamente. Na aplicação da proposta, o checklist mostrou-se eficaz no encontro de nãoconformidades nos casos de uso, uma vez que os resultados dos inspetores foram bastante semelhantes. Acredita-se que o uso do checklist possa tornar a inspeção uma atividade mais independente das habilidades e experiência do inspetor. Através da técnica de medição proposta, é possível prover uma noção mais clara da qualidade da descrição de caso de uso inspecionada, provendo uma objetividade maior para a decisão se o produto poderá passar para a próxima etapa de desenvolvimento ou se terá que retornar para a correção dos defeitos encontrados. A adoção da proposta em processos de desenvolvimento de software poderá representar, além de uma forma de apontamento de não-conformidades, também uma forma de prevenção de defeitos, pois os especificadores de modelos de caso de uso poderão se basear nos modelos de qualidade propostos para a elaboração da descrição, garantindo sua qualidade. 167

189 Uma importante limitação da proposta, que deve ser ressalvada, é a que diz respeito ao objetivo da inspeção. O checklist proposto visa verificar que se está construindo uma descrição corretamente e não validar que a descrição reflete as necessidades do usuário. O processo de inspeção é um momento adequado de se realizar a validação da especificação do sistema junto ao usuário, mas a inspeção proposta não colabora para este objetivo. Como trabalho futuro de pesquisa, sugere-se a automatização de inspeções em modelos de caso de uso, e a possibilidade da criação de uma ferramenta de automatização de inspeção. Sugere-se a ampliação da aplicação do checklist em um número maior de projetos para observar sua real eficácia. 10. Referências ABNT (2002) ISO Diretrizes para Auditorias de Sistemas de Gestão da Qualidade e/ou Ambiental. Associação Brasileira de Normas Técnicas. Ambler, S. W. (2003) The Elements of UML Style. Cambridge University Press. 1 st Edition. Anda, B. e Sjoberg, D.I.K.(2002) Towards an Inspection Technique for Use Case Models. 14th International Conference on Software Engineering and Knowledge Engineering. Bittner, K. (2000) Why Use Cases are Not Functions. The Rational Edge. Davis, A et al. (1993) Identifying and Measuring Quality in a Software Requirements Specification. Proceedings of the First International Software Metrics Symposium. Baltimore. Fabbrini, F et al. (2001) An Automatic Quality Evaluation for Natural Language Requirements. 7th International Workshop on Requirements Engineering (REFSQ'01). Fogarty, M. (2004) A Practitioner s Guide to Writing Use Cases. IEEE Software. Vol 21. n.2, March/April Gilb, T. e Graham D. (1993). Software Inspection. Addison-Wesley. Gottesdiener, E. (2003) Use Cases: Best Practices. Rational Software. IEEE (1990) Standard Glossary of Software Engineering Terminology. IEEE Std IEEE (1998) Recommended Practice for Software Requirements Specifications. IEEE Std Jacobson, I. (2003) Use Cases: Yesterday, Today, and Tomorrow. The Rational Edge. Jacobson, I. et al. (1992) Object-Oriented Software Engineering: A Use Case Driven Approach. Addison-Wesley. 1 st Edition Revised. 168

190 Laitenberger, O. et al. (2002) An Industrial Case Study to examine a non-traditional Inspection Implementation for Requirements Specifications. Eighth IEEE International Symposium on Software Metrics. Mora, M. e Denger, C. (2003) An Initial Literature Survey on Measurement Approaches for Requirement Specifications. Fraunhofer IESE Institute Experimentelles Software Engineering. Relatório Técnico nº /E OMG (2007) Object Management Group. Unified Modeling Language, version Shull, F, et al. (2000) How Perspective-Based Reading can Improve Requirements Inspections. Computer. IEEE. vol.33, n.7, pages Spence, I e Bittner, K. (2003) Use Case Modeling. Addison-Wesley. Travassos, G. H. e Mafra, N.M. (2005) Técnicas de Leitura de Software: Uma Revisão Sistemática. XIX Simpósio Brasileiro de Engenharia de Software. 169

191 170

192 Metodologia para Implementação do MPS.BR Utilizando o Ambiente WebAPSEE Vanderlene Covre 1,2, Carla Lima Reis 2, Eloi Luiz Favero 1 1 Universidade Federal do Pará (UFPA) Belém PA - Brasil PPGEE - Programa de Pós-Graduação em Engenharia Elétrica 2 Universidade Federal do Pará (UFPA) Belém PA - Brasil Laboratório de Engenharia de Software (LABES) vanderlene@gmail.com, {clima, favero}@ufpa.br Abstract. A number of software process improvement initiatives emerged recently aiming to improve software quality and productivity in software development organizations. Some models and standards, such as the IDEAL and MPS.BR models, are examples of these initiatives. In this context, the present work proposes a deployment methodology for the MPS.BR model based on IDEAL model, through the use of a specific tool, called WebAPSEE. Currently, this methodology is on validation process, with partial results, at a software development organization. This paper discusses both the methodology and its results. Resumo. Uma série de iniciativas para melhoria de processo de software surgiu recentemente visando melhorar a qualidade e a produtividade em organizações de desenvolvimento de software. Alguns modelos e normas, tais como os modelos IDEAL e MPS.BR são exemplos dessas iniciativas. Neste contexto, o presente trabalho propõe uma metodologia para a implementação do modelo MPS.BR baseada no modelo de implantação IDEAL, através de uma ferramenta específica, chamada WebAPSEE. Atualmente, esta metodologia encontra-se em validação, com resultados parciais, em uma organização de desenvolvimento de software. O artigo apresenta a metodologia e discute seus principais resultados. 1. Introdução Na medida em que a sociedade depende cada vez mais de software, presente em grande parte dos produtos e serviços que consome, o desenvolvimento de software passou a ser uma atividade crítica em vários setores (Fuggetta, 2000). No entanto, aplicações de software são complexas e muitas vezes difíceis de desenvolver e testar, sem contar com as restrições de prazo, custos e exigências de qualidade. Questões como essas têm motivado organizações a adotarem modelos de melhoria de qualidade. Estudos recentes sobre qualidade estão voltados para o aperfeiçoamento do processo de desenvolvimento de software e, como afirma Fuggetta (2000), a qualidade do produto está fortemente relacionada à qualidade do processo. O processo utilizado para desenvolver e manter o software afeta significativamente o custo, a qualidade e o prazo de entrega do produto. O impacto é tão significante que a melhoria do processo 171

193 de software é vista por alguns como a mais importante forma para melhorar o produto de software. Organizações que almejam melhorar seus processos têm dificuldade em analisar sua situação atual, identificar pontos fortes e pontos fracos e definir ações de melhoria. Embora a ISO (ISO/IEC 12207, 1998), o CMMI (CMU/SEI, 2002) e o MPS.BR (Softex, 2007) descrevam possíveis estratégias, estas não estão definidas com detalhes suficientes de modo a apoiar as organizações nesse processo de melhoria. A ausência de uma metodologia e o apoio adequado de ferramentas também dificulta a implantação e a evolução da melhoria de processos de software nas organizações. Diante da necessidade das organizações em melhorar a qualidade do processo de software, o desafio que se percebe é a utilização de uma metodologia para a implantação de melhorias em processos de software que seja vinculada ao uso de ferramentas específicas, com o objetivo de potencializar os resultados da implantação e obter maior comprometimento com a evolução da maturidade da organização. A utilização do modelo MPS.BR é vista como um alicerce para tal metodologia porque representa um modelo voltado à realidade brasileira e compatível com normas internacionais, além de amplamente aceito pela indústria e academia. Considerando o trabalho que vem sendo feito na área de tecnologia de processo de software, está sendo proposta a ferramenta WebAPSEE (WebAPSEE, 2007) para apoiar a implantação da metodologia. O diferencial da ferramenta citada está em permitir modelagem visual e execução flexível de processos de software, registro de métricas, políticas de alocação de pessoas, monitoração visual, reutilização de processos de software, dentre outras funcionalidades. Este artigo apresenta uma proposta de melhoria de processos com o auxílio de uma ferramenta de modelagem e execução de processos no apoio à implementação do MPS.BR. Esta metodologia está sendo aplicada em uma empresa do estado do Pará, que até então não possuía nenhuma experiência de implementação de processos com base em modelos de qualidade de processos de software. O restante desse trabalho está assim organizado: na seção 2 é feito um sumário relacionado a alguns modelos/normas de melhoria de processos de software. A seção 3 apresenta a ferramenta utilizada para apoiar a implementação do processo de melhoria. Os trabalhos relacionados estão apresentados na seção 4. A seção 5 expõe a metodologia proposta para implementar o MPS.BR. Na seção 6 são descritas a definição e a implantação de melhoria de processos em uma empresa. Finalmente a seção 7 apresenta as considerações finais. 2. Modelos/Normas de Melhoria de Processos de Software Vários modelos e normas para qualidade de software ganharam destaque devido a sua qualidade e aplicação. A seguir são apresentados aqueles que foram mais significativos para embasamento do presente trabalho Norma ISO/IEC A norma internacional ISO/IEC foi criada pelo esforço conjunto entre a ISO International Organization for Standardization e o IEC International Electrotechnical 172

194 Commission e tem como objetivo estabelecer uma estrutura comum para os processos de ciclo de vida do software. Com terminologia bem definida, tal estrutura contém processos, atividades e tarefas para serem aplicadas durante a aquisição, fornecimento, desenvolvimento, operação e manutenção de produtos de software. Além disso, fornece um processo que pode ser usado para definir, controlar e melhorar os processos do ciclo de vida do software. Esta norma não está ligada a métodos, ferramentas, treinamentos, métricas ou tecnologias empregadas. Tal determinação é importante para permitir que a norma seja utilizada mundialmente e possa acompanhar a evolução da engenharia de software nas diversas culturas organizacionais. Ela pode ser utilizada com qualquer modelo de ciclo de vida, método ou técnica de engenharia de software e linguagem de programação. Sua flexibilidade é uma característica importante, ela descreve a arquitetura dos processos de ciclo de vida do software, mas não especifica os detalhes de como implementar ou executar as atividades e tarefas incluídas no processo (ISO/IEC 12207, 1998). A utilização dos processos da ISO/IEC é de responsabilidade da organização, que dependendo de seu objetivo, pode selecionar um subconjunto de processos apropriado para satisfazê-lo. Os processos são agrupados, por uma questão de organização, de acordo com o seu objetivo principal no ciclo de vida de software. Esse agrupamento resultou em três diferentes classes de processos, que são: Processos Fundamentais: Aquisição, Fornecimento, Desenvolvimento, Operação e Manutenção; Processos de Apoio: Documentação, Gerência de Configuração, Garantia de Qualidade, Verificação, Validação, Revisão Conjunta, Auditoria e Resolução de Problema; Processos Organizacionais: Gerência, Infra-estrutura, Melhoria e Treinamento Modelo PDCA O princípio básico da melhoria de processos está calcado no ciclo PDCA, proposto por Walter Shewart da década de 20 e difundido amplamente na indústria japonesa após a segunda guerra por um de seus seguidores, William Edwards Deming (Filho, 2006). O ciclo tem por princípio tornar mais claros e ágeis os processos envolvidos na execução da gestão e está dividido em quatro passos: planejamento (Plan), execução (Do), verificação (Check) e ação (Act). Este ciclo também inspirou modelos como CMMI, IDEAL, QIP, dentro outros. O ciclo começa pelo planejamento, onde são definidos os objetivos de melhoria e os procedimentos necessários para atingir os resultados. Em seguida a ação ou conjunto de ações planejadas é executado, checa-se o que foi feito para verificar se está de acordo com o planejado, constantemente e repetidamente, e por fim, ações de refinamento são realizadas para eliminar ou ao menos mitigar os defeitos encontrados no produto ou na execução. 173

195 2.3. Modelo QIP O modelo QIP - Quality Improvement Paradigm foi desenvolvido por Basili (1985) como resultado da aplicação do método científico ao problema de melhoria da qualidade do software. O QIP, inspirado no ciclo de Deming PDCA, é baseado em uma abordagem cíclica e contínua para melhoria de processos e pode ser detalhado em seis etapas (Basili, 1994): Caracterizar o projeto e seu ambiente utilizando modelos, dados, intuição, etc. e estabelecer linhas base com os processos de negócio existentes na organização; Estabelecer Objetivos quantificáveis com base na caracterização inicial e nos aspectos de relevância estratégica para a organização; Escolher o Processo conforme a caracterização do ambiente e dos objetivos que foram determinados; Executar os processos nos projetos, analisar os dados obtidos em cada projeto e fornecer um retorno a respeito dos dados que estão sendo coletados; Analisar os dados da informação reunida para avaliar as práticas atuais, determinar os problemas, registrar os achados e realizar recomendações para projetos futuros e, por fim, Empacotar as experiência adquiridas em modelos atualizados para torná-las disponíveis para futuros projetos Modelo IDEAL O modelo IDEAL Mcfeeley (1996) é um modelo de programa organizacional de melhoria de processos de software que serve como guia para iniciar, planejar e implementar ações de melhoria. O modelo IDEAL, desenvolvido pelo SEI (Software Engineering Institute), foi concebido como um modelo de ciclo de vida para o melhoramento do processo de software baseado no Capability Maturity Model (CMM), e por essa razão o modelo usa termos de melhoramento de processos (IDEAL, 2004). O modelo fornece uma abordagem de engenharia disciplinada para o aprimoramento, foca no gerenciamento do programa de aprimoramento, e estabelece a fundação para uma estratégia de melhoramento de longo prazo. O modelo consiste em cinco fases. São elas: 1. Initiating (Fase de Iniciação): estabelece um alicerce para um programa de melhoria bem sucedido. Os esforços são identificados, os recursos alocados e a infra-estrutura é definida. 2. Diagnosing (Fase de Diagnóstico): determina o estado atual da organização e o estado futuro, aonde ela quer chegar. Diante desses estados são realizadas recomendações para conduzir as atividades subseqüentes. 3. Establishing (Fase de Estabelecimento): planeja os detalhes de como a organização alcançará seu objetivo. As prioridades são definidas com base no diagnóstico e uma abordagem é então desenvolvida. 4. Acting (Fase de Ação): executa o trabalho de acordo com o planejamento feito nas fases anteriores e testa a solução através da execução de projetos pilotos ou outros mecanismos que possibilitem identificar problemas e refinar a solução. 5. Learning (Fase de Aprendizagem): aprender com a experiência e melhorar a habilidade da organização em adotar novas tecnologias no futuro. 174

196 2.5. MPS.BR O projeto MPS.BR Melhoria do Processo de Software Brasileiro é uma iniciativa brasileira envolvendo universidades, grupos de pesquisa e empresas, sob a coordenação da SOFTEX (Sociedade para Promoção da Excelência do Software Brasileiro). Este projeto visa promover a qualificação de um amplo grupo de empresas compatível com os padrões de qualidade aceitos internacionalmente pela comunidade de software, a custos acessíveis, sendo adequado ao perfil e cultura da grande maioria das empresas brasileiras, (Softex, 2007). O programa MPS.BR foi baseado nas normas ISO/IEC (ISO/IEC 12207, 1998), ISO/IEC (ISO/IEC 15507, 1998), além de ser aderente ao CMMI. Está dividido em três (3) componentes: Modelo de Referência (MR-MPS), Método de Avaliação (MA-MPS) e Modelo de Negócios (MN-MPS), e define sete níveis de maturidade: Parcialmente Gerenciado (G), Gerenciado (F), Parcialmente Definido (E), Largamente Definido (D), Definido (C), Gerenciado Quantitativamente (B) e Em Otimização (A). A divisão em estágios, embora baseada nos níveis de maturidade do CMMI, tem uma graduação diferente, com o objetivo de possibilitar uma implementação e avaliação mais gradual e adequada à realidade das micros, pequenas e médias empresas. Isso permite uma visibilidade dos resultados de melhoria em prazos mais curtos (Softex, 2007). 3. Ferramenta de Gerência de Processos WebAPSEE Os Ambientes de Desenvolvimento de Software (ADS) desempenham um importante papel no apoio aos engenheiros de software na execução de processos e tem sido bastante utilizados para auxiliar a implementação de melhorias no processo de software pelo fato de integram diversas ferramentas de apoio. O WebAPSEE (WebAPSEE, 2007) é um PSEE (Ambiente de desenvolvimento de Software Centrado em Processo - Process-Centered Software Engineering Environment) (Gimenes, 1994), que permite a modelagem e execução de processos de software e tem como diferenciais: 1. Ambiente para modelagem e acompanhamento visual do processo; 2. Mecanismos para auxiliar a alocação de pessoas no processo; 3. Permite a execução flexível de processos, isto é, apóia (entre outras funcionalidades) mudanças dinâmicas no processo, garantindo a consistência do mesmo; 4. Geração automatizada de diversos relatórios que auxiliam na implementação do MR-MPS, como por exemplo: cronograma, relatório de métricas, de custos, recursos, plano da organização, etc. 5. Possui feedback direto entre o desenvolvedor e o gerente; 6. Permite a reutilização de processos de software utilizando templates, através de três funcionalidades: Process Instantiation, Process Composition e Process Distilling. 175

197 Para apoiar a definição e implantação de melhoria do processo de software de acordo com o MR-MPS, o WebAPSEE disponibiliza duas principais ferramentas: o Manager Console e a Task Agenda. A imagem localizada ao fundo da figura 1 mostra o Manager Console com um processo modelado e sendo executado, através dele o gerente de projetos pode modelar, visualizar e gerenciar a execução de processos, visualizar relatórios, além de gerenciar as informações da organização, como por exemplo recursos humanos, cronograma, artefatos, dentre outras. Através da Agenda, o desenvolvedor pode acompanhar a execução de suas tarefas, bem como fornecer um feedback sobre o andamento dessas tarefas. Além disso, a Agenda permite ao desenvolvedor fazer download e upload dos artefatos do processo. Através da imagem a frente da figura 1 é possível ver a Task Agenda de um desenvolvedor. Figura 1. Execução do WebAPSEE 4. Proposta de Metodologia para Implementação do MR-MPS Para definir a metodologia em questão foi realizada uma pesquisa dentre os principais modelos de melhoria QIP (Basili, 1985), PDCA (Deming, 1990) e IDEAL (Mcfeeley, 1996). Diante das características apresentadas por cada um, o modelo IDEAL foi o selecionado, por estar diretamente relacionado à melhoria do processo de software, por ser baseado no CMM, que por sua vez tem compatibilidade com o MPS.BR e por sugerir o uso de projetos-piloto para avaliar a efetividade das ações em prol da melhoria. Independentemente das características de cada modelo, cabe ressaltar quão desafiador é implementá-los, preservando os valores e características de cada caso. Isso é evidenciado pela necessidade de disponibilidade de recursos (humanos, financeiros e 176

198 de tempo), e no levantamento bibliográfico, pela escassez de relatos detalhados sobre o processo de implementação, dado o valor confidencial dos procedimentos e resultados. Outra dificuldade encontrada em implementações de processos está relacionada à mudança da cultura organizacional. Há uma grande dificuldade em customizar o processo padrão de acordo com as necessidades da organização quando já existe uma cultura não completamente correta sobre os procedimentos de Engenharia de Software (modelagem, testes, documentação, etc.). Sabe-se que mudanças na cultura organizacional principalmente nas atividades tradicionalmente executadas de forma ad hoc são difíceis de serem aceitas pelos desenvolvedores. (Rocha et al., 2005). Para (El-Emam et al., 2001), a falta de aplicação de uma metodologia adequada para orientar a implementação de melhoria pode trazer sucesso limitado em projetos de melhoria de processo. Dessa forma, a necessidade de uma metodologia embasada nas normas e modelos de qualidade utilizados atualmente motivou o desenvolvimento da metodologia proposta neste trabalho. A metodologia foi definida através da linguagem visual de modelagem de processos do ambiente WebAPSEE. Ela é instanciada a cada novo projeto de implementação de melhoria de processos MPS.BR. A seguir são mostradas as etapas da metodologia proposta e como ela deve ser aplicada na organização Iniciação Nesta etapa são realizadas reuniões com a alta direção para aprovar o projeto de melhoria de processos da empresa e garantir recursos para iniciar e concluir o projeto. Também são feitas atividades de planejamento, como a definição do escopo do projeto, as estimativas, a infra-estrutura e os custos são planejados, os recursos humanos para implementar a melhoria são definidos dentro da equipe de implementação e a viabilidade do projeto é avaliada. Algumas palestras e reuniões de motivações são feitas para estimular as mudanças que irão ocorrer evitando assim, uma das dificuldades relatada por Rocha et al. (2005) - a falta de motivação da organização em implantar processo, o que traz resultados poucos satisfatórios, pois as pessoas não se empenham o suficiente para aprender sobre as práticas novas introduzidas pelos processos. Isto ocorre muitas vezes devido ao fato de as pessoas darem menos prioridade às tarefas importantes da implantação do processo, pois não compreendem os potenciais benefícios da implantação do processo Diagnóstico O objetivo desta fase é avaliar a situação atual da organização, para isso são realizadas entrevistas, são passados questionários aos membros da empresa, os projetos desenvolvidos são analisados e se já existir um processo de desenvolvimento este deve ser analisado. Em organizações com baixa maturidade de capacitação em software, os processos geralmente são informais, existem apenas na cabeça de seus praticantes (Natali, 2006). As informações levantadas são avaliadas e as principais falhas e pontos a serem melhorados devem ser explorados. 177

199 Os resultados obtidos são apresentados para a alta gerência da organização e é possível diagnosticar a maturidade da organização e traçar os pontos de melhoria Estabelecimento Nesta fase as prioridades e estratégias são definidas claramente, tendo como base os resultados da fase de diagnóstico e as metas de negócio da organização. É criado um plano de ação para a melhoria a ser implementada. Esse plano deve conter as ações necessárias para o sucesso da mudança. O projeto de implementação é planejado e os riscos são identificados. A estratégia de acompanhamento do trabalho de melhoria deve ser definida, como por exemplo, definir a periodicidade das reuniões para análise e discussão dos resultados obtidos em relação às atividades de implementação de melhoria. Depois de planejadas as ações, é preciso que se definam os recursos humanos necessários para a execução do projeto de implementação. Um ciclo de vida do processo de implementação também é definido Ação Nesta fase o trabalho contextualizado e planejado nas fases anteriores é implementado, testado e refinado. As atividades previamente planejadas na fase de estabelecimento são cumpridas. Ainda segundo (Rocha et al., 2005) as maiores dificuldades encontradas na implementação dos processos estão relacionadas às competências da equipe da empresa, daí a necessidade de realizar treinamentos, tais como elaboração de descrições de casos de uso, diagramas de classes e especificações de requisitos, planejamento de projetos, rastreabilidade de requisitos, dentre outros tópicos de engenharia de software. De acordo com as necessidades levantadas na fase de diagnósticos, treinamentos devem ser realizados para nivelar os recursos humanos da organização. Para Fernandes et al (2007), muitas das dificuldades observadas nas empresas poderiam ser minimizadas com a existência de uma ferramenta para apoiá-los na condução das melhorias, principalmente neste estágio inicial de maturidade. A existência dessa ferramenta iria auxiliar a definição e execução dos processos e traria ao processo de melhoria uma produtividade maior. Na metodologia proposta essa dificuldade é sanada com a implantação e treinamentos na ferramenta WebAPSEE que irá apoiar o processo de melhoria. Concluída a fase de diagnóstico e estabelecimento e com base nas práticas e sugestões dos principais modelos de qualidade mencionados (ISO/IEC 12207, CMMI, MPS.BR) é possível definir um processo padrão para a organização e aprimorá-lo de acordo com as necessidades da mesma. A existência de um processo padrão permite que a organização tenha um modus operandi padronizado e reprodutível. Isto facilita a capacitação das pessoas, e torna o funcionamento da organização menos dependente de determinados indivíduos. Para Weber et al. (2005) é importante definir o processo dentro do ambiente em que ele será executado. Para isso, é preciso conhecer bem a organização envolvida (características, tipos de software que são desenvolvidos, paradigmas de desenvolvimento e cultura), de forma a conceber processos que atendam as suas necessidades, suas metas de negócio e contenham aspectos chaves de qualidade. 178

200 O processo padrão deve ainda ser utilizado por todos os projetos da organização, adaptando-o e customizando-o às características dos mesmos. Para testar se a melhoria trará o resultado esperado pela organização e para cumprir um dos requisitos da avaliação do MA-MPS, são definidos e executados os projetos pilotos, onde, em um contexto mais restrito, a implementação MR-MPS é colocada em prática para avaliação. De acordo com Silva Filho (2006), a execução de projetos pilotos pode servir a vários propósitos, dentre eles: (i) Identificar questões relacionadas ao conhecimento tácito, tornando-o explícito à medida que o piloto é executado, servindo como uma importante fonte de lições aprendidas; (ii) Avaliar a conformidade do processo antes que qualquer esforço significante de replicação seja realizado; e (iii) Avaliar mudanças significativas ou melhorias inovadoras que não foram experimentadas e possuem alto risco, antes de serem amplamente disseminadas na organização. A execução dos pilotos é monitorada e controlada e ajustes são feitos a partir disso. São realizadas correções e planejamentos são alterados. Nesse momento é necessário um monitoramento eficiente para detectar problemas e solucioná-los com rapidez para evitar futuras falhas Aprendizagem Nesta fase as lições aprendidas com a implementação são analisadas para evitar erros parecidos no futuro. O modelo precisa ser executado várias vezes, de modo que o processo evolua dentro da organização. Nesta fase algumas métricas podem ser coletadas. É preciso pensar em ações futuras constantemente para que a melhoria se torne contínua. Depois de executado, o processo definido é avaliado e institucionalizado na organização. Para isso, deve-se garantir que todos os envolvidos conheçam e utilizem o processo e, sejam coletados dados que ofereçam informações sobre os resultados obtidos. 5. Implementação do Nível G do MR-MPS em uma Empresa Paraense Para experimentação e validação da metodologia a mesma está sendo aplicada na implantação do nível G do MR-MPS em uma empresa paraense. Esta empresa é uma unidade estratégica, onde a qualidade da informação e a agilidade para responder as demandas dos usuários são fatores críticos de sucesso. O Grupo de Melhoria de Processos de Software da UFPA (Universidade Federal do Pará) foi criado para ajudar a aumentar a maturidade em software da empresa, com possibilidade de efeitos positivos nas outras áreas de atuação da mesma (como suporte técnico, por exemplo). Isso, por si só, já demonstra uma preocupação com a questão da qualidade, que pode trazer retornos em forma de reconhecimento e em forma de aumento da capacidade para atendimento a mais serviços importantes. O projeto de implementação do nível G do MR-MPS teve início em março de A empresa conta com 44 servidores sendo que a maioria tem nível médio ou graduação, 6 possuem mestrado e 7 especialização. Desses funcionários, 14 estão afastados de suas atividades por estarem cedidos a outros órgãos ou cursando Doutorado. Devido à baixa quantidade de funcionários frente às demandas que surgem, 179

201 a empresa conta com vários bolsistas de graduação para auxiliarem na realização das tarefas. O projeto de implementação do nível G do MR-MPS do Grupo de Melhoria de Processos de Software da UFPA seguiu as cinco fases propostas pela metodologia apresentada anteriormente para atender os objetivos da implementação. Na fase de iniciação foi estabelecida uma infra-estrutura preliminar de melhoria. Foram feitas reuniões com o diretor da empresa para garantir recursos e disponibilização de funcionários para realização da melhoria. Algumas palestras sobre os benefícios da implementação de um processo de melhoria foram ministradas para os funcionários e direção e o planejamento da melhoria foi iniciado. Essas reuniões e palestras foram importantes para contornar um dos riscos descritos por Mendes et al. (2007), que é a falta de envolvimento da equipe da empresa. Através das palestras foi possível mostrar à equipe participante do programa Melhoria de Processos de Software (MPS) os benefícios, custos, e riscos do projeto, bem como, mostrar que práticas adequadas de engenharia de software são interessantes para a empresa, mesmo que para isso ela precise abandonar as práticas até então adotadas. Na fase de diagnóstico foram realizadas entrevistas diretas ou através de questionários com a gerência e com os funcionários da organização. Essas entrevistas apontaram inicialmente, a existência de espaço para melhorias na gerência de projetos e de requisitos, tendo em vista que na empresa não havia uma definição clara sobre funções e papéis, os projetos não estavam sendo gerenciados adequadamente e através do esforço heróico algum sucesso era obtido. Tais melhorias são cobertas pelo nível G do MR-MPS (que tem como propósitos a implantação da gerência de projetos e da gerência de requisitos). A organização em questão não possuía um processo de software definido, os processos eram informais, no entanto os pontos fortes e fracos dos mesmos foram analisados e levados em consideração na definição do processo padrão para a organização. Também foram levados em consideração os projetos já finalizados e as expectativas dos envolvidos no programa MPS. Na fase de estabelecimento, os aspectos que a organização decidiu considerar foram priorizados e as estratégias foram estabelecidas. Durante essa fase foram deixadas bem claras as necessidades e vantagens na definição de um processo padrão, tendo em vista que um processo bem descrito permite entendimento, gerência e melhoria e que organizações maduras conhecem detalhadamente seu processo e o gerenciam através de indicadores inseridos em suas diversas fases. No caso desta empresa, depois de feitas as devidas análises, decidiu-se por definir um processo padrão baseado no modelo cascata. Este processo foi modelado e executado no WebAPSEE (ferramenta escolhida para apoiar o programa MPS), o que o torna um modelo flexível e adaptável, de tal maneira que o processo padrão pode ser instanciado para projetos de diferentes tipos e tamanhos, um exemplo disso é a existência de uma atividade decomposta, na fase de Construção e Testes de Software do processo, composta de sub-atividades de implementação para cada Caso de Uso, tendo em vista que essas subatividades deverão ser criadas pelo gerente de projetos durante a execução do processo, logo após a fase de planejamento. 180

202 O processo foi definido levando em consideração a cultura da organização, além de atender os resultados esperados do Nível G do MR-MPS. O processo padrão definido para a empresa, após alguns refinamentos, possui cinco fases (Planejamento, Análise dos Requisitos, Projeto de Arquitetura do Software, Construção e Testes do Software, Implantação e Encerramento do Projeto). Nesta fase também foram realizados diversos treinamentos e reuniões a fim de alinhar todos os envolvidos com os objetivos do projeto de melhoria. Os colaboradores foram treinados antes de executar suas atividades e a execução das mesmas foi acompanhada para verificar se estavam sendo feitas de forma correta. Foram oferecidos treinamentos em gerência de requisitos, engenharia de software, gerência de projetos (muitas vezes através de mentoring), curso oficial de Introdução ao MPS.BR (em agosto de 2007), curso de especialização em gerência de projetos de software (para 3 colaboradores), além de treinamentos no processo padrão e na ferramenta WebAPSEE. O preenchimento dos artefatos também foi acompanhado pela equipe de implementação, sendo que para cada artefato foi proposto um template que define uma estrutura padrão para os documentos, além de informações importantes que eles precisam ter. Na fase de ação foram escolhidos dois projetos pilotos para testar o processo, sendo que um deles já foi finalizado, o projeto A (nome fictício). A utilização do WebAPSEE foi de grande importância para o projeto, visto que essa ferramenta permitiu a gerência de projetos com a modelagem e acompanhamento da execução do projeto feitas através do Manager e da Agenda. Alguns relatórios gerados pelo WebAPSEE, como cronograma, gantt chart, plano de recursos, plano de custos, plano de recursos humanos, organograma da empresa, a estrutura analítica do projeto, além do plano de gerência de documentos, ajudaram a automatizar ainda mais o processo. A figura 2 exemplifica um dos relatórios gerados pelo WebAPSEE, o gantt chart. Outra grande vantagem da ferramenta é a possibilidade de alteração dinâmica, isto é, durante a execução do processo novas atividades puderam ser adicionadas e/ou excluídas, sendo que para isso existem regras para checar automaticamente a consistência do modelo de processo em relação ao seu estado e de suas atividades, o fluxo de atividades, os estados dos recursos, dentre outras. O gerente de projetos pôde acompanhar o desenvolvimento do projeto em tempo real através do Manager e os desenvolvedores receberam automaticamente as suas tarefas e artefatos necessários pela Task Agenda. 181

203 Figura 2. Gantt chart de um processo executado no WebAPSEE Outro benefício observado foi a facilidade de acesso aos artefatos e templates de artefatos. O processo modelado no WebAPSEE permite que os mesmos possam ser baixados e atualizados diretamente pela Task Agenda ou pelo Manager. Um agente (pessoa responsável pela atividade) pode facilmente carregar o template de um artefato em seu computador, preenchê-lo e postá-lo pela Task Agenda, como mostra o item 1 da figura 3. A ferramenta também guarda as versões dos artefatos através da integração com o CVS (Concurrent Versions System), facilitando o acesso à versões anteriores. Cada atividade modelada no processo possui um roteiro, cadastrado pelo gerente de projetos no Manager, que inclui toda informação necessária para que um agente possa realizá-la de forma eficaz, como mostra o item 2 da figura 3. O desenvolvedor também pode ver o início e o fim estimados de suas atividades. Através da Task Agenda o agente pode iniciar, pausar e finalizar uma atividade. O WebAPSEE armazena o tempo gasto pela execução da atividade, com isso o gerente verifica a produtividade dos agentes e pode traçar comparativos sobre estimado versus realizado. Quando o status de uma atividade muda na Task Agenda o mesmo muda automaticamente no Manager e a execução do processo pode ser acompanhada visualmente. 182

204 Figura 3. Detalhes da Atividade mostrados pela Agenda Na fase de aprendizagem ficaram comprovados os benefícios do programa MPS, o projeto A foi muito elogiado pelos seus clientes, alcançando seu objetivo e atendendo as expectativas da patrocinadora do projeto. Durante a execução deste primeiro projeto foram identificadas as seguintes lições aprendidas: A presença freqüente da equipe de implementação favorece a disseminação das vantagens e dos benefícios do programa de melhoria na organização. Quando os gerentes ou líderes de projetos responsáveis pela execução dos processos na organização possuem conhecimento em engenharia de software, há uma considerável rapidez na implementação da melhoria e uma necessidade bem menor por acompanhamento da equipe de implementação. O primeiro projeto a utilizar o processo definido apresenta dificuldades, já que a equipe está se adaptando às novas atividades e a ferramenta de apoio, o que exige uma mudança na maneira como os projetos são executados. A obtenção dos comprometimentos ao longo do projeto teve certa resistência, pois a empresa não estava habituada a registrar o comprometimento formal tanto interna como externamente. Adotar uma ferramenta de rastreabilidade de requisitos, para diminuir a complexidade de criar uma matriz de rastreabilidade usando planilha. Os resultados alcançados com os projetos pilotos serão estendidos para outros projetos e o processo será institucionalizado. O próximo passo da empresa é se preparar para a avaliação preliminar do nível G do MR-MPS. 183

205 6. Trabalhos Relacionados Vários relatos têm sido publicados sobre o uso de modelos de qualidade e os resultados que as iniciativas de melhoria baseadas nestes modelos têm obtido em diversas organizações. Fernandes, 2007; Rocha, Montoni, Santos et al. 2005, Macedo et al., 2006 relatam implantações do MPS.BR, tanto em empresas individuais como em organizações cooperadas. Esses trabalhos apontam as necessidade e vantagens da utilização de ferramentas de apoio, e, mostram, de maneira simplificada, a utilização de alguma metodologia. No entanto, nenhum desses trabalhos sugere a execução da metodologia como um processo de melhoria executado em um ambiente centrado em processos. A metodologia discutida é tratada como um processo que foi modelado e executado utilizando o WebAPSEE. Apoiando a equipe de implementação desde o planejamento até as lições aprendidas, essa metodologia possibilita, além de outras vantagens, a gerência e redução do tempo de implementação e guarda os históricos que poderão ser úteis em outros projetos. 7. Considerações Finais Neste trabalho foi apresentada uma metodologia de implementação do nível G do MR- MPS, orientada pelo modelo IDEAL, que está sendo utilizada por uma empresa paraense para conseguir a avaliação nível G do MR-MPS. Esta metodologia engloba desde a definição da estratégia de implementação até a avaliação final. Esta metodologia específica inclui procedimentos, templates de documentos, material de treinamento e outros, voltados para a implementação do MR-MPS. Desta forma, espera-se ao final do projeto, ter esta metodologia de implementação de programa de melhoria revisada e totalmente testada, e a empresa com o nível G do MR- MPS implementado e apta para avaliação formal. Para colher os benefícios esperados com o programa MPS, deve haver a conscientização da organização em adotar a melhoria de processos de software como uma estratégia, treinando os seus gerentes e colaboradores e criando um ambiente favorável. A organização está bastante motivada, principalmente depois dos benefícios observados com a execução do projeto A. Ficou evidenciado que o apoio do WebAPSEE facilitou o treinamento, desenvolvimento, a definição, execução e está sendo de grande importância na institucionalização dos processos, ajudando a reduzir o tempo de implementação dos mesmos. A ferramenta ajudou a equipe de implementação tanto na execução do processo de implementação como na execução da metodologia e os benefícios obtidos pela organização cliente com o uso da ferramenta também puderam ser observados pela equipe de implementação, já que a metodologia é modelada e executada em tal ferramenta. Referências Basili, V.R. (1985) Quantitative Evaluation of Software Engineering Methodology, Proceedings of Fisrt Pan Pacific Computer Conference, Melbourne, Australia, September. 184

206 Basili, V. R.; Caldeira, G.; Rombach, H. D. (1994) The Experience Factory, In: MARCINIAK, John J.. (Ed.). Encyclopedia of Software Engineering. New York: John Wiley & Sons, pp Chrissis, Mary Beth et al., (2003) CMMI: Guidelines for Process Integration and Product Improvement. Boston, Addison Wesley. CMU/SEI, (2002), Capability Maturity Model Integration (CMMI), Version 1.1, Pittsburgh, Software Engineering Institute, Carnegie Mellon University. URL: Acesso em janeiro de Deming, W. E. (1990) Qualidade: A Revolução da Administração. Rio de Janeiro: Marques Saraiva. El-Emam, K., Goldenson, D., McCurley, J. and Herbsleb, J. (2001) Modelling the Likelihood of Software Process Improvement: An Exploratory Study," Empirical Software Engineering, vol. 6, pp Fernandes, P.G.; Oliveira, J. L.; Mendes, F.F.; Souza, A.S. (2007) Resultados de Implementação Cooperada MPS.BR. ProQualiti - Qualidade na Produção de Software, pages Filho, R.C.S. (2006) Uma Abordagem para a Avaliação de Propostas de Melhoria em Processos de Software. Dissertação de Mestrado. Rio de Janeiro Brasil. Fuggetta, (2000) A. Software Process: A Roadmap. The Future of Software Engineering. Gimenes, I.M. (1994) Uma Introdução ao Processo de Engenharia de Software: Ambientes e Formalismos. Trabalho apresentado na Jornada de Atualização em Informática, Caxambu - MG: SBC. IDEAL, (2004) The IDEAL SM Model. Software Engineering Institute (SEI). URL: Acesso em maio de ISO/IEC 12207, (1998) Tecnologia de Informação - Processos de ciclo de vida de Software, ABNT - ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS, Rio de Janeiro: ABNT. ISO/IEC TR 15504, (1998) Information technology software process assessment. International Organization for Standardization. Macedo, C. C.; Lima, S. H.; Rocha, A. R. et al. (2006) Implantação de Melhoria de Processo de Software no Tribunal Superior Eleitoral. V Simpósio Brasileiro de Qualidade de Software (SBQS'06). Vila Velha, Brasil. Mcfeeley, B. (1996) IDEAL SM : A User s Guide for Software Process Improvement. Pittsburgh, Software Engineering Institute. Mendes, F. F.; Oliveira, J. L.; Fernandes, P. G.; Souza, A. S. (2007) Análise de Riscos na Implementação de Melhorias de Processo de Software. ProQualiti Qualidade na Produção de Software, pages 25 31, Recife, Brasil. Natali, A. (2006) Engenharia de Software: Introdução e uma Visão do Processo de Software. Apostila de curso. 185

207 Rocha, A. R. et al. (2005) Fatores de Sucesso e Dificuldades na Implementação de Processos de Software Utilizando o MR-MPS e o CMMI, In: I Workshop de Implementadores MPS.BR, Brasília, Brasil. Rocha, A. R.; Montoni, M.; Santos, G. et al. (2005) Estação TABA: Uma Infraestrutura para Implantação do Modelo de Referência para Melhoria de Processo de Software. IV Simpósio Brasileiro de Qualidade de Software (SBQS'05). Porto Alegre, Brasil. Silva Filho R. C.; Rocha, A. R.; Travassos, G. H. (2006) O Uso de Projetos-Piloto para Avaliação da Efetividade da Melhoria de Processos. V Simpósio Brasileiro de Qualidade de Software (SBQS 06). Vila Velha, Brasil. Softex (2007) Sociedade para Promoção da Excelência do Software Brasileiro, MPS.BR - Melhoria de Processo do Software Brasileiro, Guia Geral (v. 1.2), URL: Acesso em agosto de Softex A (2007) Sociedade para Promoção da Excelência do Software Brasileiro, MPS.BR - Melhoria de Processo do Software Brasileiro, Guia Geral (v. 1.1), URL: V1.1.pdf. Acesso em agosto de WebAPSEE (2007). Documento de Referência da Ferramenta Versão 1.0. URL: Acesso em julho Weber, S.; Hauck, J.C.R.; Von Wangenheim, C.G. (2005) Estabelecendo Processos de Software em Micro e Pequenas Empresas. IV Simpósio Brasileiro de Qualidade de Software (SBQS 05). Porto Alegre, Brasil. 186

208 Planejando e Automatizando a Geração de Casos de Teste de Unidade Utilizando Diagrama de Seqüência Antonio Carlos Silva 1, Fabiane Barreto Vavassori Benitti 1,2 1 Centro de Educação de Ciências Tecnológicas da Terra e do Mar Universidade do Vale do Itajaí (UNIVALI) Itajaí, SC Brasil 2 Departamento de Sistemas e Computação Universidade Regional de Blumenau (FURB) Blumenau, SC Brasil {antonio.carlos,fabiane.benitti}@univali.br Abstract. One of the initial tests applied to a software is the unit test that happens right before the total codification of the system. This paper proposes the use of sequence diagram as a visual language to define the test cases, allowing to documenting them regardless of the language of implementation. This paper also proposes a tool which supports this definition along with a case study to demonstrate the proposed artifact viability. Resumo. Um dos testes iniciais aplicados a um software é o teste de unidade, que acontece antes mesmo da total codificação do sistema. Este artigo propõe o uso do diagrama de seqüência como linguagem visual para definição dos casos de teste, de forma a permitir a documentação dos mesmos independentemente da linguagem de implementação. Neste artigo é apresentada ainda, uma ferramenta que suporta esta definição juntamente com um estudo de caso, a fim de demonstrar a viabilidade do artefato proposto. 1. Introdução O teste de software é uma das etapas no ciclo de desenvolvimento de software que tem como principal objetivo encontrar os erros presentes em um software. Esta etapa é compreendida por sistemáticas aplicações de testes ao longo de todo o processo de desenvolvimento [Macgregor e Sykes 2001]. A etapa de testes é definida por Hetzel (1987) como: o processo de executar um programa ou sistema com a finalidade de encontrar erros. Teste é a medida de qualidade do software. Um dos testes iniciais aplicados a um software é o teste de unidade, que acontece antes mesmo da total codificação do sistema. O teste de unidade, conhecido também por teste de componente ou teste de módulo, é definido por Thomas et al (2004), como um teste projetado para verificar uma única unidade de software de forma isolada das demais unidades. Em projetos orientados a objetos, uma unidade de implementação é uma classe ou um método de uma classe. A técnica de desenvolvimento TDD (Test Driven Development), proposta por Beck (2002), apóia-se na aplicação de testes de unidade antes da codificação das unidades propriamente ditas. Alguns dos benefícios atribuídos ao uso da técnica 187

209 referem-se ao fato de que toda unidade de software possuirá um conjunto de testes que verifique seu funcionamento, baseado nos requisitos estabelecidos para esta unidade, assim antecipando a detecção de erros presentes na codificação. A etapa inicial envolvida na aplicação da técnica é o planejamento dos casos de teste, momento em que são definidos os detalhes envolvidos na execução dos testes, como os dados de entrada e os resultados esperados. Para o teste de unidade a etapa de planejamento é comumente confundida com a codificação dos drivers e stubs, resultando em pouca ou nenhuma documentação para os casos de teste, restando apenas o próprio código fonte dos testes como especificação [Beck 2002]. Esta deficiência na documentação dos casos de teste pode ser explicada pela falta de uma linguagem padrão para definição dos casos de teste e uma ferramenta que apóie este processo [Biasi e Becker 2006]. Desta forma, este artigo propõe a utilização do diagrama de seqüência, definido na UML (Unified Modeling Language), como artefato para definição de casos de teste (detalhado na seção 3). Também apresenta, na seção 4, uma ferramenta que visa auxiliar na definição dos casos de teste, bem como automatizar a geração do código fonte de execução dos testes utilizando o framework JUnit. Na seção seguinte são apresentados alguns dos pontos fundamentais da técnica TDD no que se refere a testes de unidade. Por fim são apresentadas as considerações finais e direcionamentos para trabalhos futuros. 2. TDD O TDD (Test Driven Development) ou Test First tem como base a definição e aplicação de testes de unidade antes mesmo da codificação das unidades envolvidas, fortalecendo este princípio, destaca-se que um código para uma unidade de software só pode ser desenvolvido se houver um conjunto de casos de teste para verificá-la [Astels 2003]. A técnica de desenvolvimento TDD consiste em três etapas: (i) definição dos casos de teste; (ii) codificação das classes com o objetivo de atender aos casos de teste; e (iii) refatoração. Cada uma destas etapas é aplicada a cada unidade de software [Beck 2004]. A definição dos casos de teste ganha destaque se comparado a abordagem tradicional de teste de software, uma vez que este guiará a codificação do sistema. Nesta etapa são identificados os drivers e stubs para posterior codificação [Astels 2003]. São os drivers que determinam a execução dos casos de teste definindo as mensagens entre os objetos envolvidos e as verificações estabelecidas a partir dos resultados esperados [Maldonado e Fabbri 2001]. Comumente este código é desenvolvido para atender a uma ferramenta que automatize a execução dos testes 1, como por exemplo, o JUnit da família xunit, responsável pela automatização de testes desenvolvidos em linguagem Java. Os stubs de testes têm por objetivo substituir outras unidades de software envolvidas em um caso de teste, eliminando a dependência entre as unidades [Maldonado e Fabbri 2001]. O uso de stubs permite atender ao princípio de isolamento 1 A automatização dos testes é um dos requisitos no uso da técnica TDD, sem este a técnica poderia tornar-se inviável devido às sucessivas aplicações de testes [Beck 2004]. 188

210 das unidades, em que cada unidade deve ser testada de forma isolada das demais [Thomas et al 2004] e [IEEE 1986]. A codificação das classes é efetuada com base nos casos de teste estabelecidos, tendo como objetivo o êxito na execução dos testes. Na etapa de refatoração o código desenvolvido para atender aos casos de testes é avaliado de forma a verificar questões como flexibilidade, reaproveitamento de código, desempenho, clareza na solução e duplicidade no código [Astels 2003]. 3. Definindo Casos de Teste Na etapa de planejamento dos casos de teste para o teste unitário são especificados os dados de entrada e os resultados esperados, bem como todo o fluxo de execução do caso de teste como, por exemplo, as mensagens trocadas entre os objetos. A pouca padronização na definição de casos de teste é destacada por Biasi e Becker (2006), Badri, Badri e Bourque-Fortin (2005) e Linzhang et al. (2004). Observa-se, ainda, que no padrão proposto pela IEEE (1986) para testes de unidade também não é abordada uma linguagem para definição de casos de testes. Dentre as soluções já propostas, destaca-se a de Badri, Badri e Bourque-Fortin (2005), que propõem a definição dos casos de teste tendo como base o diagrama de estados. No entanto, uma das limitações desta proposta refere-se ao fato de que os elementos deste diagrama não estão diretamente relacionados às unidades de software. A fim de contornar este problema Badri, Badri e Bourque-Fortin (2005) apresentam novos conceitos e definições ao diagrama de estados. Assim, a proposta de um modelo visual, baseado na UML e utilizando tão somente os recursos já especificados na linguagem, favorece a aplicabilidade por parte dos analistas e o suporte por ferramentas já existentes. O diagrama de seqüência é um dos diagramas disponibilizados pela UML para modelagem das interações na etapa de projeto, no entanto, propõem-se a sua utilização para etapa de teste. A figura a seguir resume a proposta de utilização do diagrama de seqüência como linguagem visual para definição de casos de teste, destacando os principais elementos envolvidos. Durante a elaboração do caso de teste devem ser definidas mensagens entre o driver (gerenciador dos casos de teste) e os objetos envolvidos neste. Para representação do driver utilizou-se a figura do ator, elemento já existente no diagrama de seqüência, denotando o responsável por invocar os métodos dos objetos envolvidos nos casos de teste, sendo apresentado à esquerda do diagrama, como demonstrado na Figura 1 (A). Conforme abordado na seção 2, a utilização de stubs em casos de teste é fundamental para garantir o isolamento da unidade testada, desta forma, um stub no diagrama proposto é representado como um objeto acrescido do estereótipo <<stub>>, conforme a Figura 1 (B). Outro recurso pertinente quando da criação de casos de teste refere-se ao SetUp. Este recurso permite definir objetos compartilhados por todos os casos de teste de uma classe, ou seja, considerados como de uso global. Assim, quando utilizado o SetUp de uma classe no diagrama de seqüência é exibida ao fim da linha de vida de cada objeto a 189

211 mensagem from SetUp, conforme a Figura 1 (C), evidenciando o uso de objetos compartilhados. Para todo caso de teste definido deve ser incluído um objeto Assert, como demonstrado na Figura 1 (D). O elemento Assert representa a classe de mesmo nome do framework xunit sendo responsável pela verificação do caso de teste. Ressalta-se que esta classe é padronizada nos frameworks da família xunit, ou seja, a sua utilização independe da linguagem de implementação. Figura 1. Diagrama de seqüência utilizado para definição dos casos de teste Destaca-se que para definição de um caso de teste utilizando o diagrama de seqüência basta que sejam definidos os objetos envolvidos no teste e as mensagens trocadas entre estes, com isso obtêm-se um padrão baseado em uma linguagem já estabelecida e de conhecimento de muitos dos analistas e testadores envolvidos no processo de desenvolvimento de software. Visando demonstrar a viabilidade de utilização deste diagrama como forma de especificar casos de testes, a seção seguinte apresenta a proposta de uma ferramenta que permite a geração automática do código de teste de unidade a partir de um caso de teste, definido visualmente através do diagrama de seqüencia, elaborado conforme descrito nesta seção. 4. Ferramenta para Apoio no Planejamento dos Casos de Teste A ferramenta tem como objetivo permitir a criação de um projeto de casos de teste, focando testes de unidade considerando o contexto de um método (unidade). Para tanto, faz-se necessário que o modelo de classes do projeto testado esteja definido, pois este compreende a base dos testes. Sendo assim, a ferramenta apóia-se nas etapas definidas no diagrama de atividades ilustrado na Figura

212 Importa Modelo de Classes Define casos de teste Inicio Valida projeto Gera código fonte Código para os casos de teste gerado Figura 2. Diagrama de atividades para a ferramenta proposta 1. Importa modelo de classes: permite conhecer o modelo de classes a ser testado, devendo ser compatível com o padrão XMI 2.1; 2. Define casos de teste: nesta etapa, utilizando o formato do diagrama de seqüência proposto, o usuário define os casos de teste para os métodos do modelo importado; 3. Valida projeto: após a definição dos casos de teste a ferramenta permite a validação dos casos de teste, fazendo críticas a possíveis problemas encontrados nos casos de teste; e 4. Gera código fonte: por fim o usuário tem a opção de gerar o código fonte para os casos de teste do modelo, possibilitando sua execução pelo framework JUnit (inicialmente, para demonstrar a viabilidade do diagrama proposto, optou-se por testar sistemas desenvolvidos na linguagem Java). Tendo em vista as etapas definidas, a Figura 3 apresenta o diagrama de casos de uso, representando as funcionalidades da ferramenta proposta. Neste modelo de casos de uso percebe-se comportamentos básicos para operacionalizar a ferramenta, como abrir, salvar e fechar projeto (UC02, UC03 e UC04). Os demais casos de uso são o foco da ferramenta e, portanto, são detalhados na seqüência abordando sua funcionalidade juntamente com um estudo de caso. A elaboração do caso de teste (UC05), através do diagrama de seqüência, parte da existência de um modelo de classes com seus respectivos métodos definidos. Sendo assim, considerando o modelo de classes ilustrado na Figura 4, é possível importá-lo na ferramenta (UC01) e iniciar a definição do caso de teste, através da interface ilustrada na Figura

213 UC02 - Abrir projeto UC03 - Salv ar proj eto UC01 - Criar projeto UC04 - Fechar projeto UC09 - Gerar código fonte Usuário UC05 - Criar caso de teste UC08 - Validar caso de teste UC07 - Criar Stub UC06 - Definir o SetUp Figura 3. Casos de uso para a ferramenta proposta O estudo de caso o qual é apresentado ao longo desta seção, a fim de demonstrar o funcionamento da ferramenta, possui como base o modelo de classes ilustrado pela Figura 4, onde o método adicionaproduto da classe CarrinhoDeCompras terá um caso de teste definido. Este caso de teste visa verificar se ao adicionar um produto ao CarrinhoDeCompras este será devidamente tratado. CarrinhoDeCompras - produtos: ArrayList + CarrinhoDeCompras() + gettotal() : double + adicionaproduto(produto) : void + retiraproduto(produto) : boolean + getnumerodeprodutos() : int + esvaziar() : void +produtos 0..* Produto - preco: double - nome: String + Produto(String, double) + getnome() : String + getpreco() : double + equals(object) : boolean Figura 4. Diagrama de classes do estudo de caso Alguns aspectos são importantes de serem destacados. Ao solicitar a criação de um novo caso de teste, a partir de um método presente no modelo e importado pela ferramenta (Figura 5 A), é apresentado ao usuário o diagrama de seqüência com alguns elementos pré-definidos, conforme observado em (Figura 5 B): Gerenciador (CarrinhoDeComprasTest): responsável por gerenciar o caso de teste e do qual partirão todas as mensagens; Objeto Assert, que compõe o framework JUnit e é responsável pela verificação do casos de teste; e Stubs: a ferramenta identifica com base na assinatura do método à ser testado, quais Stubs são necessários para sua chamada. Caso não exista nenhum Stub já criado do tipo necessário, um novo Stub é adicionado, devendo o usuário definir seu comportamento. 192

214 No caso da figura 5, tem-se os elementos propostos para o caso de teste do método AdicionaProduto da classe CarrinhoDeCompras, apresentado na Figura 4. O Stub de nome stubproduto, presente no caso de teste, tem por objetivo permitir que o método adicionaproduto da classe CarrinhoDeCompras possa ser invocado sem a necessidade de que seja instanciado um objeto do tipo Produto, fortalecendo assim o princípio do isolamento destacado por IEEE (2006). Figura 5. Interface para definição e visualização do caso de teste O UC06 permite ao usuário a definição do SetUp, funcionalidade oferecida pelo framework JUnit (e todos os demais da família xunit), que permite criar objetos que podem ser utilizados por vários casos de teste. No exemplo apresentado, ilustrado na Figura 6, é criado um objeto com nome de carrinho, como instância da classe CarrinhoDeCompras, sendo que para sua criação é selecionado o construtor padrão da classe. Figura 6. Interface para definição dos objetos do SetUp 193

215 Outra funcionalidade necessária é a criação de um Stub para uma classe (UC07). Esta funcionalidade é obtida a partir da seleção de uma das classes do modelo, quando a ferramenta apresenta a interface para criar um novo Stub, conforme demonstra a Figura 7a e incluí-lo em um caso de teste Figura 7b. Figura 7a. Interface para criação de um novo Stub Figura 7b. Interface para adicionar um Stub ao caso de teste Com os elementos do caso de teste definidos, pode-se então estabelecer as mensagens entre o gerenciador do caso de teste e os demais objetos (comportamento previsto para o UC05). Para definição de uma mensagem em um caso de teste é utilizada a interface apresentada na Figura 8, devendo ser indicado o método que será invocado e o valor dos parâmetros (se necessário). Figura 8. Interface para definição da mensagem 194

216 Para o caso de teste testadicionaproduto foram definidas quatro mensagens, apresentadas na Figura 9, com o objetivo de verificar se o método responde como esperado. A primeira delas adiciona o Stub stubproduto ao objeto carrinho, a mensagem seguinte invoca o construtor da classe Produto, a fim de construir o objeto produto1 o qual é adicionado ao objeto carrinho na mensagem seguinte. Por fim, a última mensagem do caso de teste verifica se o número de produtos do objeto carrinho corresponde ao valor esperado. Figura 9. Caso de teste testadicionaproduto Utilizando a opção de validação (UC08), o sistema apresenta críticas quanto aos possíveis problemas encontrados nos casos de teste definidos pelo usuário. Estas críticas referem-se, por exemplo, a casos de teste que não possuem chamadas aos métodos da classe Assert do framework JUnit, ou métodos que não possuem casos de teste, ou mesmo casos de teste que não possuam pelo menos uma chamada ao método testado, conforme apresentado na Figura

217 Figura 10. Interface para validação dos casos de teste A geração do código fonte dos casos de teste definidos pelo usuário (UC09) é realiza a partir da interface demonstrada na Figura 11. No exemplo apresentado, o código gerado pela ferramenta para o caso de teste AdicionaProduto pode ser visualizado na Figura 12. Figura 11. Interface para geração de código fonte 196

218 package EcommerceTest.ecommerce; import public class CarrinhoDeComprasTest { } ecommerce.carrinhodecompras public void setup() throws Exception { carrinho = new ecommerce.carrinhodecompras( ); public void testadicionaproduto() { } ecommerce.produto stubproduto = EasyMock.createMock(ecommerce.Produto.class); this.carrinho.adicionaproduto( stubproduto ); Produto produto1 = new Produto("Padrões de Projeto", 48.90); this.carrinho.adicionaproduto( produto1 ); Assert.assertEquals( 2, carrinho.getnumerodeprodutos() ); Figura 12. Código fonte gerado pela ferramenta 5. Exemplo de aplicação do diagrama proposto em diferentes contextos Como base para demonstração do diagrama de seqüência para definição de casos de teste focando em testes de unidade utilizou-se de algumas das classes do sistema TeamDOC da empresa QualyTeam, que desenvolve sistemas para gestão da qualidade. O TeamDOC, que corresponde a um GED (Gerenciador Eletrônico de Documentos), permite aos seus usuários controlar através de revisões os documentos produzidos pela empresa. A figura 13 apresenta em um diagrama de classes parte das classes do sistema com alguns de seus atributos e métodos, este diagrama será utilizado a seguir como base para definição dos casos de teste. Verificacao «enumeration» StatusDaVerificacao Aprov acao Consenso PENDENTE ABERTO APROVADO REPROVADO Processo Arquiv o +aprovacoes 0..* +revisao 1 +consensos 0..* +revisao 1 Rev isaododocumento - aprovacao: bool - consenso: bool - datadaelaboracao: DateTime - datadasolicitacao: DateTime - datadapublicacao: DateTime - publicada: bool - observacao: string + adicionararquivo(arquivo) : void + publicar() : bool + ispublicada() : bool +revisao 1 +arquivos 0..* +revisoes +documento 0..* 1 - nome: string - descricao: string PermissaoDoDocumento +permissoes +categoria Documento + getrevisaoatualpublicada() : RevisaoDoDocumento + getrevisao(int) : void + adicionarevisao(revisao) : void + removerevisao(revisao) : bool 0..* +processo 1 1 +categoria 1 CategoriaDeDocumento 197

219 Figura 13. Diagrama de classes do sistema TeamDOC Com base no diagrama de classes são apresentados casos de teste para os métodos getrevisaoatualpublicada(), getrevisao(int) da classe Documento, já a classe RevisaoDoDocumento() terá um caso de teste para o método publicar. O caso de teste para o método getrevisao(int) adiciona duas revisões ao documento e verifica se a revisão retornada pelo método corresponde ao índice especificado, este caso de teste é apresentado na figura 14. Figura 14. Caso de teste para o método getrevisao(int) O método getrevisaoatualpublicada() da classe Documento retorna sempre que invocada a revisão mais atual publicada para o documento em questão, caso não exista nenhuma revisão publicada este retorna null. O caso de teste apresentado na figura 15 verifica seu funcionamento adicionando duas revisões ao documento e comparando o retorno do método testado com o valor esperado. Figura 15. Caso de teste para o método getrevisaoatualpublicada() Cada documento no sistema TeamDOC possui uma única revisão publicada, as demais revisões de um documento podem encontrar-se em elaboração, que corresponde ao estado inicial de uma revisão ou cancelada, estado assumido após a publicação de uma revisão mais recente para o documento. O método publicar() da classe RevisaoDoDocumento deve alterar o estado da revisão para publicada, caso esta esteja em elaboração e avisar ao documento sobre a alteração, para que este altere o estado da revisão anterior, caso exista, para cancelada. O caso de teste apresentado na figura 16 verifica este comportamento adicionando a um documento duas revisões, inicialmente uma destas revisões é publicada, verifica-se se o estado desta e, em seguida, é publicada uma nova revisão e novamente verifica-se o estado das revisões do documento. 198

220 Figura 16. Caso de teste para o método publicar Com base nos casos de teste definidos para o sistema TemDOC apresentados nesta seção pode-se verificar a adequação do diagrama de seqüência proposto, diagramas estes que foram definidos com o auxílio da ferramenta apresentada neste documento. 6. Considerações Finais A principal contribuição deste artigo é apresentar uma proposta para utilização do diagrama de seqüência como artefato de definição de casos de teste visando auxiliar, por exemplo, a aplicação da técnica TDD. O uso do diagrama de seqüência na definição dos casos de teste, ganha destaque à medida que este não foi concebido para este fim. Apesar disso, sua adequação se deu de forma natural, não exigindo a criação de qualquer elemento ou comportamento em especial, apenas utilizando de recursos já existentes na UML, como o estereótipo, utilizado para identificação do stub. Biasi e Becker (2006) apresentam alguns problemas na utilização de ferramentas para automatização de: (i) o esforço necessário para preparar o código auxiliar; (ii) nem sempre há distinção clara entre as atividades de especificação dos casos de teste e de programação do código auxiliar; e (iii) dependência do caso de teste da linguagem de programação. Desta forma, o diagrama de seqüência como proposta para definição de casos de teste juntamente com a ferramenta desenvolvida se configuram como solução para os problemas citados em [Biasi e Becker 2006], dado que o código auxiliar é gerado automaticamente pela ferramenta. Os casos de testes podem ser definidos de forma visual sem qualquer contato com a linguagem de implementação, tendo como base apenas o modelo de classes do projeto. O uso do diagrama de seqüência para definição dos casos de teste se demonstrou compatível com os recursos necessários para tal aplicação, dado que a ferramenta desenvolvida com base nesta definição pode gerar o código fonte para os casos de teste, tendo como base tão somente o diagrama de seqüência definido pelo usuário na própria 199

221 ferramenta. No entanto, esta ferramenta necessita de melhorias para sua aplicação em um cenário corporativo, podendo-se citar como prioritárias as seguintes adequações: (i) permitir a execução dos testes integrado à ferramenta; e (ii) viabiliza a semiautomatização da geração do diagrama de casos de teste a partir de um diagrama de seqüência de projeto. Por fim, acredita-se que o uso de uma linguagem visual para definição de casos de teste linguagem esta que já é de domínio de parte dos analistas - permite uma melhor comunicação e interação entre os envolvidos no processo de desenvolvimento. Referências Astels, D. (2003) Test Driven development: a practical guide, Prentice Hall. Badri, M., Badri, L. e Bourque-Fortin, M.; (2005) Generating unit test sequences for aspect-oriented programs: towards a formal approach using UML state diagrams. In 3rd International Conference on Information and Communications Technology. p Coimbatore, India. Beck, K. (2002) Test driven development: by example, Addison-Wesley. Biasi, L. e Becker, K. (2006) Geração automatizada de drivers e stubs de teste para JUnit a partir de especificações U2TP. In Proceedings of Brazilian Symposium of Software Engineering (SBES), Florianópolis Santa Catarina. Hetzel, W. (1987) Guia completo do teste de software, Campus. IEEE (1986) IEEE standard for software unit testing. IEEE (2006). A survey of unit testing practices. In IEEE Software, v 23, Issue 4, p , July-Aug. Linzhang, W.; Jiesong Y.; Xiaofeng Y.; Jun H.; Xuandong L.; Guoliang Z. (2004). Generating test cases from UML activity diagram based on Gray-box method. In 11th Software Engineering Conference. p Asia-Pacific. Macgregor, J. e Sykes, D. (2001) A Practical guide to testing object-oriented software, Addison-Wesley. Maldonado, J. C. e Fabbri, S. C. P. F. (2001) Teste de software. In: Rocha, A. R. C. da; Maldonado, J. C.; Weber, K. C. (Coord.). Qualidade de software: teoria e prática. São Paulo: Prentice Hall, p Thomas, J., Young, M., Brown, K. e Glover, A. (2004) Java testing patterns, John Wiley. 200

222 ProEvaluator: Uma Ferramenta para Avaliação de Processos de Software Juliana Moura Cavalcanti Xavier 1, Alexandre Marcos Lins de Vasconcelos 2 1 Serviço Federal de Processamento de Dados (SERPRO) Av. Parnamirim, 295, CEP: Recife PE Brasil 2 Centro de Informática Universidade Federal de Pernambuco (UFPE) Caixa Postal 7851 CEP: Recife PE Brasil {jmcx, amlv}@cin.ufpe.br Abstract. In December 2003, SOFTEX (Association for Promoting Brazilian Software Excellence) launched the MPS.BR (the Model for Brazilian Software Process Improvement). The MA-MPS (MPS.BR Evaluation Method) was created to check if the organizations meet the requirements of such model. This paper presents a tool to support the activities described in the MA-MPS method. The tool allows the record of the process execution evidences, the attribution of concepts to the process expected results and, from that point, calculates automatically the maturity level of the organization and releases a final report with the evaluation results. Resumo. Em dezembro de 2003, a SOFTEX (Associação para Promoção da Excelência do Software Brasileiro) lançou o MPS.BR (Modelo para Melhoria de Processo de Software Brasileiro). Para verificar se as organizações atendem aos requisitos do modelo criado, foi definido o MA-MPS (Método de Avaliação do MPS.BR). Este artigo apresenta uma ferramenta para apoiar as atividades descritas no método MA-MPS. A ferramenta permite o cadastro de evidências da execução do processo, atribuição de conceitos aos resultados esperados dos processos e de seus atributos e, a partir daí, calcula automaticamente o nível de maturidade da organização e emite um relatório final com os resultados da avaliação. 1. Introdução Avaliação de Processo de Software tem sido um método popular e largamente utilizado para garantir a produção de software de qualidade. Esta atividade tem sido realizada por organizações que desejam melhorar seus processos de software e, conseqüentemente, seus produtos de software. Uma avaliação de processos de software produz uma quantidade enorme de dados associados à avaliação. Assim, a manipulação e análise desses dados são aspectos importantes na avaliação de processos. Logo, o uso de uma ferramenta para manipular os dados da avaliação se torna imprescindível. Segundo [HUNTER, 1997], os principais aspectos de manipulação de dados associados à avaliação de processos de software são: a captura, o armazenamento, a visualização e análise dos dados. 201

223 As ferramentas de avaliação de processos de software [WALKER, 1995] [FABBRINI, 2003] costumam mostrar um resumo dos principais resultados da avaliação de uma forma gráfica. Tais ferramentas permitem ao usuário visualizar os dados da avaliação e, assim, identificar os pontos fracos do processo e priorizar as atividades de melhoria. A ferramenta proposta por esse trabalho visa automatizar algumas atividades do Método de Avaliação MPS.BR, o MA-MPS. Hoje em dia, se alguma empresa deseja automatizar o processo de avaliação, precisa criar sua própria ferramenta, pois as que existem estão disponíveis apenas para consultorias. A ferramenta ProEvaluator ficará disponível gratuitamente para download pela Internet. O artigo está organizado em 5 seções. A seção 2 apresenta os trabalhos relacionados, ou seja, as ferramentas de avaliação de processos de software mais conhecidas. A seção 3 examina os principais métodos de avaliação, focando no Método de Avaliação do MPS.BR, o MA-MPS. A seção 4 explica a proposta da ferramenta ProEvaluator, que é o foco deste trabalho. A seção 5 mostra uma análise crítica da ferramenta. Por fim, a seção 6 conclui o artigo e apresenta os possíveis trabalhos futuros. 2. Trabalhos Relacionados A ferramenta PISA provê um suporte automático para as atividades de avaliação de processos de software baseadas na norma ISO/IEC [FABBRINI, 2003]. Ela oferece um apoio às atividades de coleta/validação de dados e fornecimento de notas aos atributos de processo. De acordo com a metodologia automatizada por essa ferramenta, a avaliação de processos é dividida em quatro partes: preparação, coleta de dados, avaliação e emissão de relatórios. A fase de preparação inclui atividades de registro de dados da organização, configuração de pesos das características da avaliação e registro do escopo da avaliação. A fase de coleta de dados contém a atividade de preenchimento de checklists. A fase de avaliação inclui as atividades de análise de práticas base e práticas de gerenciamento automaticamente. A última fase consiste na emissão do relatório final de avaliação. A ferramenta para avaliação de processos SEAL [WALKER, 1995] está disponível na Internet gratuitamente. Ela provê uma abordagem sistemática para a realização de avaliações baseadas no modelo de avaliação definido pela norma ISO/IEC É possível criar várias instâncias de avaliação e para cada uma delas, por meio de uma interface gráfica, registrar o nível alcançado dos produtos de trabalho, práticas base e práticas de gerenciamento. Uma vez que esses níveis são determinados, a ferramenta avalia automaticamente os atributos de processo. É possível aumentar ou diminuir os atributos de processo, práticas base, práticas de gerenciamento e produtos de trabalho, por isso essa ferramenta é adaptável a pequenas evoluções da norma ISO/IEC 15504, versão relatório técnico. O CORE-KM (Customizable Organizational Resources Environment with Knowledge Management) é um ambiente customizável para gerência de conhecimento em diferentes organizações, capaz de apoiar seus processos organizacionais [GALOTTA, 2004]. A infra-estrutura base do CORE-KM traz uma série de ferramentas 202

224 genéricas que podem ou não estar nos ambientes customizados, em função da necessidade de cada organização. O Ambiente de Apoio a Avaliações MPS pode ser instanciado a partir do CORE-KM. Este ambiente tem o conhecimento comum MPS e os templates de artefatos requeridos para a execução do processo [MURADAS, 2006]. A Instituição Avaliadora precisa então cadastrar suas próprias informações, bem como definir sua interface. A ferramenta é utilizada para apoiar uma Instituição Avaliadora na realização de avaliações MPS. Os principais objetivos desse ambiente é o apoio à execução das atividades de planejamento do processo de avaliação MPS, a gerência das atividades das Instituições Avaliadoras e a disseminação das experiências vividas pelos avaliadores durante a realização das avaliações segundo o método de avaliação MPS.BR. O Ambiente de Apoio a Avaliações MPS é composto por 3 ferramentas específicas. A primeira trata do apoio ao processo de avaliação MPS propriamente dito. A segunda trata do cadastro e consulta dos profissionais da Instituição Avaliadora com suas características. A última é uma agenda para se cadastrar atividades e consultar a disponibilidade dos profissionais para realizar as avaliações. Appraisal Assistant é uma aplicação de software desenvolvida pelo Software Quality Institute, da Griffith University, para dar apoio à avaliação da capacidade do processo ou maturidade organizacional. Sua abordagem é consistente com os requisitos do Processo de Avaliação da ISO/IEC e os requisitos de avaliação do CMMI. Diferente de outras ferramentas de avaliação de processos, Appraisal Assistant possui uma abordagem dirigida a evidências para registrar a informação gerada durante a avaliação. Ela provê suporte ao método de avaliação SCAMPI e ao método genérico definido pela Norma ISO/IEC Ou seja, é possível expressar resultados de uma avaliação CMMI como perfis de processo padrão ISO/IEC A ferramenta também facilita a geração de relatórios da avaliação. Nas avaliações MPS.BR, os avaliadores não utilizam nenhuma ferramenta automatizada, além de uma planilha de indicadores em Excel. Tal planilha contém os processos que vão ser avaliados e os seus respectivos resultados esperados. Ao final da avaliação, a planilha contém todos os resultados esperados para os processos e seus atributos que estão sendo avaliados. Para cada resultado esperado, evidências que comprovam que o resultado foi alcançado são inseridas. Para cada evidência, identifica-se a fonte da mesma e os projetos aos quais ela pertence. Caso a evidência não pertença a projetos específicos, e sim à organização toda, informa-se que se trata de uma evidência organizacional. O avaliador também informa um conceito para cada projeto e cada resultado esperado, através da análise das evidências do projeto. Baseado nos conceitos informados, calcula-se o conceito geral do resultado esperado. Se todos os resultados esperados de um processo forem satisfatórios, então o processo como todo é dito como satisfeito. Caso todos os processos sejam caracterizados como satisfeitos, conclui-se que a organização atingiu aquele nível organizacional almejado. 203

225 2.1. Comparação entre as Ferramentas de Avaliação A seguir encontra-se uma tabela com o resumo geral das principais características das ferramentas descritas. Tabela 1.1 Características das Ferramentas de Avaliação Ferramenta Gratuita? Oferece apoio à geração de relatórios? Suporta diferentes modelos? Oferece apoio à atribuição de notas? Método ou Modelo de Avaliação PISA Não Sim Sim Sim ISO/IEC SEAL Sim Sim Não Sim ISO/IEC Ambiente de Apoio às Avaliações MPS.BR Sim Sim Não Não MA-MPS Appraisal Assistant Sim Sim Sim Sim SCAMPI e ISO/IEC Planilha de Avaliação MPS.BR Sim Não Não Não MA-MPS Como podemos observar, a ferramenta que possui uma maior cobertura em relação às características comuns de uma ferramenta de avaliação é a Appraisal Assistant. Ela é uma ferramenta gratuita q ue suporta diferentes modelos de avaliação. Ela oferece apoio à avaliação baseada no método SCAMPI e no método baseado na Norma ISO/IEC 15504, porém ela não fornece apoio ao MA-MPS. Essa ferramenta também possui uma gama de tipos de relatórios que podem ser emitidos no fim da avaliação. As ferramentas PISA e SEAL são baseadas no modelo ISO 15504, oferecem suporte à atribuição de notas e geração de relatórios de avaliação. Além disso, a ferramenta SEAL está disponível gratuitamente na Internet, porém, não é adaptável a diferentes modelos. Já a ferramenta PISA é adaptável a pequenas evoluções do modelo ISO O Ambiente de Apoio às Avaliações MPS.BR está disponível gratuitamente 204

226 e fornece suporte à fase de planejamento do método MA-MPS, mas não contempla às fases de avaliação e geração de relatório final. A planilha de avaliação MPS.BR é disponibilizada gratuitamente pela SOFTEX apenas para as empresas que serão avaliadas oficialmente. Por não ser uma ferramenta automatizada, a planilha não fornece suporte a relatórios e só pode ser utilizada para avaliar processos baseados no modelo MPS.BR. A proposta desse trabalho, que é a ferramenta ProEvaluator, é gratuita, oferece suporte a relatórios, porém não é adaptável a diferentes modelos. No estágio atual, ela automatiza apenas parte do Método de Avaliação MPS.BR. 3. Métodos de Avaliação Os métodos de avaliação definem o procedimento de avaliação de processos de software. O método mais comum é o Standard CMMI Appraisal Method for Process Improvement SCAMPI [CMU/SEIa, 2002]. Ele é o método de avaliação descrito no modelo de referência CMMI. O método de avaliação do MPS.BR é o MA-MPS [MPS.BR, 2006b]. Ele orienta a execução de uma avaliação em conformidade ao Modelo de Referência MPS.BR. O Appraisal Requirements for CMMI, versão 1.1 ARC V1.1 foi publicado pelo CMMI Product Team em 2001 [CMU/SEId, 2001]. Ele define os requisitos para os métodos de avaliação de processo que têm como base de melhoria o modelo CMMI. O ARC V1.1 define um conjunto de classes de avaliação baseadas em aplicações típicas de métodos de avaliação. Ele identifica três classes de métodos de avaliação, denominados Classe A, Classe B e Classe C. Os métodos da Classe A devem satisfazer todos os requisitos do ARC V1.1. Esta é a única classe de métodos que pode fornecer graduação para análise comparativa (benchmarking). Os métodos dessa classe exigem que sejam aplicadas 3 fontes de dados na avaliação: entrevista, aplicação de instrumentos e revisão de documentação. Os métodos da Classe B devem satisfazer um subconjunto dos requisitos do ARC V1.1. Exigem apenas duas das três fontes de dados (entrevista, aplicação de instrumentos e revisão de documentação) dos métodos de classe A, sendo que uma destas fontes deve ser a entrevista. Além disso, não fornecem graduação e são indicados para organizações que estão começando as atividades de melhoria de processo utilizando modelos CMMI. Os métodos da Classe C devem satisfazer apenas um subconjunto dos requisitos dos métodos de Classe B. Exigem apenas uma das três fontes de dados dos métodos de Classe A. A validação das observações e o mecanismo de consenso entre os membros da equipe são requisitos opcionais desta classe de métodos. Este tipo de avaliação deve ser, provavelmente, mais utilizado quanto o objetivo é dar uma rápida olhada ou, para os casos de auto-avaliações periódicas, feitas por grupos de projetos ou de suporte. O Standard CMMI Appraisal Method for Process Improvement SCAMPI V1.1 é um método de avaliação compatível com os requisitos definidos pelo ARC V1.1 e atende avaliações conduzidas de acordo com a norma ISO/IEC TR Ele fornece a graduação da maturidade de processo em relação aos modelos CMMI, satisfaz todos os requisitos de métodos Classe A e é composto de três fases e onze processos. 205

227 O Método de Avaliação do MPS.BR (MA-MPS) está em conformidade com a Norma Internacional para avaliação de processos de software ISO/IEC [ISO/IEC , 2004]. Ele permite a avaliação objetiva dos processos de software de uma organização [MPS.BR, 2006b]. O MA-MPS pode ser aplicado a organizações de diversos tamanhos e diferentes domínios de aplicação. O resultado final da aplicação do método é a atribuição de um nível de maturidade para a organização com base no resultado da avaliação. A equipe de avaliação do MA-MPS é composta de 3 a 8 pessoas, sendo um avaliador líder, no mínimo, um avaliador adjunto e um técnico da empresa. A duração da avaliação varia de 2 a 4 dias. A validade de uma avaliação MPS é de 3 anos. Após esse período, a organização deve se submeter novamente à avaliação de seus processos. O processo de avaliação define um conjunto de atividades realizadas para verificar a maturidade da unidade organizacional na execução de seus processos de software. Cada avaliação tem um patrocinador que financia a realização da mesma, ou seja, ele é responsável pelos gastos necessários para execução da avaliação. Para realização de uma avaliação o patrocinador deve, inicialmente, selecionar uma Instituição Avaliadora dentre as credenciadas pela SOFTEX. Este processo se encerra com o registro da avaliação na base de dados confidencial da SOFTEX. Através da execução do processo de avaliação obtemos dados e informações que caracterizam os processos de software da organização. Também é determinado o grau em que os resultados esperados são alcançados e o nível em que os processos atingem seu propósito. O processo de avaliação é composto de quatro sub-processos principais. O resultado da execução do sub-processo Contratar Avaliação é estabelecer um contrato para realização da avaliação MPS. Essa contratação pode ser feita de três formas. A organização pode estabelecer um contrato diretamente com uma ou mais Instituições Avaliadoras credenciadas pela SOFTEX. Outra opção é a organização entrar em contato com a SOFTEX e solicitar uma avaliação. Neste caso, a SOFTEX pode encaminhar para uma Instituição Avaliadora ou ser a contratada, designando avaliadores credenciados para realizar a avaliação de forma independente das Instituições Avaliadoras. A última forma de solicitar uma avaliação é uma empresa diferente da unidade organizacional a ser avaliada solicitar uma avaliação de terceira parte para fins de contrato. A segunda fase do processo de avaliação é Preparar para Realização da Avaliação. A organização recebe o template do Plano de Avaliação da SOFTEX e preenche o mesmo com informações sobre a organização. Durante essa fase, a organização também deve assinar um Acordo de Confidencialidade e agendar a avaliação inicial. A terceira fase do processo consiste em Realizar a Avaliação. O propósito desse sub-processo é treinar a equipe, conduzir a avaliação MPS e comunicar seus resultados à unidade organizacional avaliada. É durante essa fase que são analisadas as evidências diretas e indiretas, são realizadas as entrevistas e atribuídos conceitos aos resultados esperados dos processos. Depois, é feita uma avaliação nos processos selecionados e o nível organizacional é obtido e reportado para a organização. 206

228 A última fase do processo é responsável por Documentar os resultados da avaliação. O propósito desse sub-processo é elaborar o relatório da avaliação, enviá-lo ao patrocinador da avaliação e à SOFTEX, que é responsável por inserir os dados da avaliação em sua base de dados e divulgar o resultado em seu site. Um detalhamento maior sobre o processo de avaliação do MA-MPS pode ser obtido através do Guia de Avaliação [MPS.BR, 2006b]. Os métodos MA-MPS e SCAMPI são bem semelhantes. Ambos definem uma fase de Planejamento de Avaliação, pregam o consenso da equipe para definir o nível organizacional, fazem uma apresentação final dos resultados apontando os pontos fortes e oportunidades de melhoria e divulgam o resultado final da avaliação apenas com o consentimento do patrocinador. A principal diferença entre esses métodos consiste no tipo de graduação que os mesmos fornecem. Os avaliadores que seguem o método MA- MPS avaliam o nível de maturidade da organização enquanto os avaliadores do SCAMPI analisam o nível de maturidade da organização e/ou de capacidade de seus processos. 4. ProEvaluator A proposta da ferramenta ProEvaluator é automatizar algumas atividades do método de avaliação MPS.BR. Ela pode ser usada nas organizações antes ou durante a avaliação oficial MPS.BR. Ou seja, essa ferramenta pode ser utilizada para as organizações se auto-avaliarem, podendo identificar seus pontos fracos e fortes; ou durante a avaliação oficial MPS.BR para que os avaliadores possam analisar os processos da organização e então atribuir conceitos aos respectivos resultados esperados. No fim da avaliação, a ferramenta exibe um relatório contendo o nível de maturidade do processo organizacional, de acordo com os níveis de maturidade descritos no modelo de referência MPS.BR. Baseado no estudo dos requisitos das principais ferramentas de avaliação de processos do mercado [FABBRINI, 2003] [WALKER, 1995] [LIANG, 2007] [MURADAS, 2006] e nas entrevistas realizadas com um avaliador oficial do MPS.BR, foram extraídos os seguintes requisitos para ferramenta ProEvaluator: Gratuidade: a ferramenta será totalmente gratuita e estará disponível para download na Internet; Adaptável a diferentes domínios: a ferramenta poderá ser usada para avaliação de processos em organizações de diferentes tamanhos e domínios; Baseada no método de avaliação do MPS.BR: a ferramenta visa automatizar as atividades do processo de avaliação do MPS.BR, versão 1.0. Suporte a relatórios: no final da avaliação será permitido ao usuário emitir um relatório final com o resultado da avaliação. Durante a execução da avaliação, relatórios parciais poderão ser emitidos. O ambiente de apoio às avaliações MPS definido por [MURADAS, 2006] oferece suporte a fase de planejamento da avaliação; no entanto, não oferece suporte às 207

229 demais fases da avaliação. O objetivo da construção da ferramenta ProEvaluator é automatizar as fases de Realização da Avaliação e Documentação dos Resultados, descritas no processo de avaliação do MPS.BR. A Figura 1 representa o modelo de casos de uso da ferramenta ProEvaluator, que fornece uma visão estática das funcionalidades da mesma. Podemos observar que existem 2 atores envolvidos no processo de avaliação: o usuário comum e o avaliador. O usuário pode criar ou abrir uma avaliação, inserir evidências diretas e indiretas para os resultados esperados, consultar o conceito dos processos, gerar os gráficos e o relatório final da avaliação. O avaliador é um usuário e além de todas as funcionalidades permitidas para o usuário também pode inserir afirmativas que são obtidas através das entrevistas, analisar os resultados esperados, atribuindo conceitos a eles e alterar os conceitos dos processos, se julgar necessário. Depois que o avaliador analisa todos os resultados esperados, o sistema calcula automaticamente o conceito para o processo. Figura 1. Modelo de Casos de Uso da ProEvaluator Para criar uma avaliação é necessário fornecer o nome da mesma, os projetos que serão avaliados e o nível almejado pela Organização. A partir daí a avaliação já foi criada e pode ser reaberta através da ferramenta sempre que necessário. Por isso, no início da execução da avaliação, o usuário precisa tomar uma decisão: criar ou abrir uma avaliação já existente. A partir daí é exibida uma tela contendo as informações da 208

230 avaliação, os processos que serão avaliados, os projetos e o nível almejado. O próximo passo é escolher o processo onde serão cadastradas as evidências do processo da Organização. O processo é exibido com seus resultados esperados e seus atributos de processo. O avaliador deve apenas selecionar o resultado que deseja cadastrar a evidência, escolher o tipo de evidência (Direta, Indireta ou Afirmativa) e realizar o cadastro. Ele deve realizar essa operação para todos os resultados esperados dos processos e de seus atributos. Após cadastrar as evidências, o avaliador procede com a atribuição de conceitos para os resultados esperados dos processos e de seus atributos. Nessa hora, ele pode descrever os pontos fortes e oportunidades de melhoria do processo da Organização. Essas informações estarão presentes no relatório final da avaliação. Depois que todos os resultados esperados de um processo forem avaliados, o sistema calcula automaticamente o conceito do mesmo (vide Figura 2). Esse conceito pode ser: Satisfeito, Não Satisfeito ou Fora de Escopo, conforme critérios definidos no MA-MPS. Figura 2. Avaliação de Processo na Ferramenta ProEvaluator Se o avaliador não concordar com a nota gerada automaticamente pela ferramenta, ele pode alterá-la. A partir daí, o usuário pode gerar o gráfico dos resultados do processo e de seus atributos. Para finalizar a avaliação, é necessário criar o relatório final da mesma. Tanto o usuário comum quanto o avaliador podem realizar essa operação. A ferramenta foi desenvolvida utilizando a modelagem orientada a objetos e a linguagem Java. Ela está dividida em três camadas: camada de negócio (classes básicas, cadastros e fachada), camada de dados (classes de persistência) e camada de apresentação (interfaces gráficas). Essa arquitetura foi projetada visando facilitar a manutenção evolutiva da ferramenta. Atualmente, ela está sendo evoluída para suportar outros métodos de avaliação. 209

231 5. Análise Crítica Para verificar se a ferramenta atendia aos requisitos especificados, foi necessário analisá-la do ponto de vista de quem iria utilizá-la na prática: os profissionais de avaliação de processos. Utilizamos um questionário com perguntas sobre o perfil do entrevistado e as principais características da ferramenta. Este questionário teve três objetivos principais: verificar se a ferramenta estava aderente ao método de avaliação do MPS.BR, verificar se a ferramenta poderia ser utilizada numa avaliação interna da organização, antes da avaliação MPS.BR oficial e verificar a usabilidade da ferramenta. Em relação ao perfil do entrevistado foram feitas perguntas sobre o seu papel na organização, experiência em desenvolvimento de sistemas, nível de conhecimento em Engenharia de Software, nível de conhecimento em Modelos de Qualidade, nível de conhecimento em Métodos de Avaliação, experiência prática com avaliação de processo, se já utilizou ferramentas de avaliação e, por fim, se possui alguma certificação MPS.BR. Em relação à avaliação da ferramenta foram feitas perguntas sobre o apoio que ela oferece ao cadastro de evidências, sua aderência ao MA-MPS, adequação em préavaliação, adequação numa avaliação oficial MPS.BR, exibição dos resultados, usabilidade e, por fim, os entrevistados fizeram observações gerais sobre a ferramenta ProEvaluator. Houve três apresentações presenciais da ferramenta (uma a alguns participantes do Simpósio Brasileiro de Engenharia de Software 2007 e outras duas a alguns profissionais de duas empresas desenvolvedoras de software, uma pública e uma privada). Após cada apresentação, o questionário foi respondido e devolvido para análise. Em todas as apresentações, inicialmente foi feita uma palestra sobre a ferramenta demonstrando o contexto onde ela estava inserida, seus requisitos e principais funcionalidades. Posteriormente, foi feita uma demonstração da ferramenta em execução criando uma avaliação e analisando seus resultados. A partir daí, foi iniciada a discussão com perguntas e esclarecimentos sobre a ferramenta. Para concluir, foram distribuídos os questionários para os ouvintes da apresentação e recolhido o resultado da análise. O SBQS foi escolhido devido à alta disponibilidade de profissionais peritos no modelo MPS.BR. Foi uma ótima oportunidade de reunir profissionais e pesquisadores para discutir os requisitos de uma ferramenta de avaliação de processos de software. A empresa pública foi escolhida devido à elevada quantidade de profissionais certificados no modelo MPS.BR. Além disso, essa organização tem a intenção de realizar uma avaliação MPS.BR até o fim de A outra empresa foi escolhida por estar se preparando para uma avaliação de processos de software baseada no modelo CMMI. Além dessas apresentações, um manual de uso da ferramenta foi enviado via a alguns profissionais de tecnologia da informação e em seguida, após lerem o manual, o questionário foi respondido e devolvido também via . Ao todo, foram respondidos 25 questionários, distribuídos nos papéis de Gerente de Qualidade, Analista, SQA e Desenvolvedor. As apresentações presenciais somaram um total de 17 espectadores e as avaliações à distância somaram 8 avaliadores. Esta abordagem está longe de ser a ideal, tanto pelo número de respostas obtidas, como por não ser uma aplicação prática da ferramenta. Entretanto, ela nos 210

232 permite ter uma idéia da aderência da ferramenta ao método MA-MPS, pois leva em conta a experiência de profissionais com diferentes perfis Análise dos Resultados A primeira parte dos questionários teve como objetivo traçar um perfil dos entrevistados, do ponto de vista da experiência em avaliação de processos de software e do conhecimento em modelos e métodos de avaliação. Para isso, foram elaboradas perguntas sobre a experiência técnica, em engenharia de software, em processo de desenvolvimento e o conhecimento prévio no método de avaliação do MA-MPS. Apesar da maioria dos entrevistados possuírem um bom conhecimento teórico dos métodos de avaliação, eles não possuem experiência prática em avaliação de processos. Mais de 50% dos entrevistados não possuem nenhum conhecimento prático nesta atividade (vide Figura 3). Experiência em Avaliação de Processos 16% 4% 0% 28% 52% Nenhuma 1 ano 2 a 3 anos 4 a 5 anos Mais de 5 anos Figura 3. Experiência em Avaliação de Processos A segunda parte do questionário teve como objetivo avaliar as funcionalidades da ferramenta ProEvaluator. A Figura 4 apresenta a adequação da ferramenta para uma avaliação anterior à avaliação oficial MPS.BR, ou seja, a uma pré-avaliação. Mais de 80% dos entrevistados informaram que ela é adequada para ser utilizada numa préavaliação. Aqueles que viram a ferramenta em execução fizeram uma avaliação mais positiva do que os que avaliaram pela Internet. Porém, um percentual considerável do total de entrevistados informou que ela poderia ser utilizada parcialmente em conjunto com outras ferramentas para realização de uma pré-avaliação. Acreditamos que esse seja o uso mais adequado da ferramenta no momento. Ela pode ser perfeitamente utilizada numa pré-avaliação para diagnotiscar pontos fortes e oportunidades de melhoria no processo da organização. 211

233 Figura 4. Utilização em pré-avaliação 6. Conclusão O trabalho descrito teve por objetivo o desenvolvimento de uma ferramenta para Avaliação de Processos de Software baseada no Método de Avaliação MPS.BR, versão 1.0. Essa ferramenta poderá ser utilizada para as organizações se auto-avaliarem, obtendo o seu nível de maturidade, além de identificar os pontos fracos e oportunidades de melhoria do seu processo. Outra abordagem interessante é utilizá-la durante a avaliação oficial MPS.BR. Os avaliadores poderiam utilizar a ferramenta como suporte ao processo de avaliação. Atualmente, os avaliadores MPS.BR utilizam uma planilha excel para cadastrar as evidências e atribuir os conceitos aos processos avaliados. O uso de uma ferramenta automatizaria o processo de avaliação e permitiria a geração dos relatórios finais automaticamente. Se as organizações utilizassem a ferramenta ProEvaluator para avaliações internas, formariam uma base histórica digital de avaliações. Isso permitiria que consultas fossem feitas para observar tendências. Por exemplo, poder-se-ia constatar que a maioria dos projetos da organização tem conceitos negativos em Gestão de Projetos, ou seja, elas podem estar tendo dificuldade de gerir seus projetos. Dada essa informação, ações poderiam ser tomadas para resolver os problemas identificados. A ferramenta ProEvaluator foi analisada por profissionais da área de Engenharia de Software e pessoas certificadas no modelo MPS.BR. Segundo os resultados dessa avaliação, no estágio atual da ferramenta ProEvaluator, ela é mais adequada para ser utilizada numa pré-avaliação MPS.BR. Melhorias na ferramenta, como, por exemplo, torná-la uma ferramenta multi-usuário, deixá-la com uma interface WEB, extendê-la para contemplar a fase de planejamento da avaliação, entre outras, permitirão que ela seja utilizada numa avaliação oficial MPS.BR. Referências Appraisal Requirements for CMMI (2001), Version 1.1 (ARC, V1.1), Pittsburgh, Software Engineering Institute, Carnegie Mellon University. Disponível em: 212

234 ASSOCIAÇÃO PARA PROMOÇÃO DA EXCELÊNCIA DO SOFTWARE BRASILEIRO SOFTEX. MPS.BR (2006), Guia Geral, versão 1.1. Disponível em: ASSOCIAÇÃO PARA PROMOÇÃO DA EXCELÊNCIA DO SOFTWARE BRASILEIRO SOFTEX. MPS.BR (2006), Guia de Avaliação, versão 1.0. Disponível em: Capability Maturity Model Integration (2002), Version 1.1 CMMI for Software Engineering (CMMI-SW, V1.1), Pittsburgh, Software Engineering Institute, Carnegie Mellon University. Disponível em: Capability Maturity Model for Software (1993), Version 1.1, Pittsburg, Software Engineering Institute, Carnigie Mellon University. Disponível em: Fabbrini, F., Fantini, E., Fusani, M., Lami, G. (2003), "Performing SPICE Assessments: Yet Another Tool". In Joint ESA - 3rd International SPICE Conference on Process Assessment and Improvement ESTEC, Noordwijk, The Netherlands. Galotta, C., Oliveira, K., Rocha, A.R. (2004), Apoio a Interação entre Processos de Negócio e de Software através de Gerência do Conhecimento, Simpósio Brasileiro de Qualidade de Software, Brasília-DF, Brasil. Hunter, R., Robinson, G., Woodman, I. (1997), Tool Support for Software Process Assessment and Improvement. University of Strathclyde, Department of Computer Science. Disponível em: Muradas, F.M. (2006), Processo de Avaliação MPS.BR: Definição e Ambiente de Apoio, COPPE/UFRJ, Rio de Janeiro. NBR/ISO 9000 (2000), Sistema de Gestão da Qualidade Fundamentos e Vocabulário, Associação Brasileira de Normas Técnicas, Rio de Janeiro, Brasil. Standard CMMI Appraisal Method for Process Improvement SCAMPI (2002), Version 1.1, Method Implementation Guidance for Government Source and Contract Process Monitoring, Pittsburgh, Software Engineering Institute, Carnegie Mellon University. Disponível em: The International Organization for Standardization and the International Electrotechnical Commission. ISO/IEC : Information Technology - Process Assessment - Part 5: An exemplar Process Assessment Model, Geneve: ISO, The International Organization for Standardization and the International Electrotechnical Commission (1995). ISO/IEC Information technology Software life cycle processes, Geneve: ISO. Walker, A.J., Lok, H.R. (1995), SPICE Assessments using the SEAL assessment tool, Software Engineering Applications Laboratory. 213

235 214

236 Um Estudo Exploratório sobre a Satisfação do Usuário de Sistemas de Software Tereza G. Kirner; José Carlos Perini; Maria I. Montebelo Universidade Metodista da Piracicaba Programa de Pós-Graduação em Ciência da Computação Rodovia do Açúcar, Km , Piracicaba SP {tgkirner, milmonte}@unimep.br, jcperini@uol.com.br Abstract. This work focuses on the user satisfaction of software products, proposing a model to evaluate the user satisfaction and discussing a research, based on the proposed model, which evaluated the user satisfaction of a software applied to the educational management area. The model is presented and the planning, implementation, data analysis and results of the research are discussed. The work aims at contributing to the evaluation of user satisfaction as well as to the quality improvement of software products. Resumo. Este trabalho trata da satisfação do usuário de produtos de software, apresentando um modelo para avaliar a satisfação do usuário e discutindo uma pesquisa, realizada, com base no modelo proposto, junto a usuários de um software de gestão acadêmica. O planejamento, implementação, análise de dados e resultados da pesquisa são apresentados. O trabalho visa contribuir para a avaliação da satisfação do usuário e para a melhoria da qualidade de sistemas de software. 1. Introdução O sucesso da implantação e uso de sistemas de software nas organizações depende não apenas do atendimento de características essencialmente técnicas, assumidas durante o processo de desenvolvimento, mas também da priorização de aspectos que, incorporados ao produto, levem à sua adequada utilização. Esses aspectos estão normalmente relacionados à usabilidade do software, que é um requisito de qualidade que envolve aspectos específicos, entre os quais se destaca a satisfação do usuário. A satisfação do usuário é, portanto, um atributo de qualidade que contribui para a usabilidade dos produtos de software [Abran, 2003; Sommerville, 2007]. Essa satisfação é determinada tanto por características relacionadas a medidas internas do software, como segurança e confiabilidade, por exemplo, quanto por característica subjetivas, de ordem externa, relacionadas às necessidades e expectativas do usuário. Os usuários incluem os indivíduos que interagem com determinado sistema ou aplicação de software. Este trabalho tem dois objetivos principais: (a) propor um Modelo de Avaliação da Satisfação do Usuário; e (b) discutir um estudo empírico exploratório, realizado junto a usuários de um Sistema de Gestão Acadêmica, baseado no Modelo proposto. Com 215

237 esses objetivos, pretende-se contribuir para a pesquisa e a prática relativa ao atendimento de requisitos ligados à satisfação dos usuários. A seção 2 destaca trabalhos relacionados ao tema, que forneceram uma base conceitual para o presente trabalho. A seção 3 detalha o modelo de satisfação do usuário proposto. A seção 4 apresenta o estudo empírico realizado junto a usuários de um sistema, utilizando o modelo definido. A seção 5 descreve a análise de dados realizada e os principais resultados obtidos. As conclusões do trabalho são apresentadas na seção Trabalhos Relacionados Para se obter sistemas de software compatíveis com o que os usuários necessitam e esperam, é fundamental se investir em modelos de avaliação de software direcionados especificamente para medir o nível de satisfação expressado pelos usuários para com os sistemas que eles utilizam ou estão em vias de utilizar. DeLone e McLean (1992, 2002, 2003) propuseram um modelo para avaliação da qualidade de sistemas, bastante divulgado e empregado em pesquisas sobre avaliação de aplicações e produtos de software. Segundo esse modelo, o sucesso de um sistema é resultado da combinação de quatro fatores chaves, que, juntos, podem gerar um impacto individual e um impacto organizacional positivo, resultando no sucesso do sistema: a qualidade do sistema, a qualidade da informação, o uso do sistema e a satisfação do usuário. A satisfação do usuário é um componente de destaque desse modelo, definido a partir de características ligadas ao uso do sistema, ao acesso às funções e resultados do sistema e também a características pessoais e subjetivas relacionadas às necessidades e expectativas do usuário. Tratando especificamente da avaliação da satisfação do usuário, destaca-se o modelo EUCS - End-User Computing Satisfaction [Doll, 2000; Ives, 1993]. Esse modelo enfoca dimensões distintas da satisfação do usuário, tais como: conteúdo do sistema, acurácia das informações geradas, formato de apresentação das informações pelo sistema, facilidade de uso do sistema e fornecimento de informações em tempo adequado para a execução das tarefas e tomada de decisões por parte dos usuários. Tanto as pesquisas que utilizaram o Modelo DeLone [Iivari, 2005; DeLone, 2003] quanto as que aplicaram o Modelo EUCS [Abdnnour, 2005; Barner, 2006; Chin, 2000; Zviran, 2006] forneceram um referencial teórico importante para a realização de estudos sobre satisfação do usuário de sistemas de software. No entanto, ambos apresentam deficiências, que se procurou sanar no presente trabalho. O Modelo DeLone não trata extensivamente dos aspectos específicos da satisfação do usuário e enfatiza muito o processo de análise estatística dos dados, em detrimento do detalhamento dos quesitos e características de qualidade. O Modelo EUCS, por sua vez, é muito detalhista, propondo um conjunto muito grande de questões, com aspectos repetitivos, que dificulta o levantamento de dados junto aos usuários. No estudo aqui apresentado buscou-se um avanço em relação aos trabalhos existentes, objetivando-se, principalmente, definir um Modelo de Satisfação do Usuário simples, claro e possível de ser aplicado na avaliação de sistemas reais e envolvendo usuários reais. 216

238 3. Modelo de Satisfação do Usuário Para a realização do estudo empírico, foi proposto um modelo composto por um conjunto de dez quesitos que retratam a satisfação do usuário, cada um deles avaliados através de duas questões. Para se chegar a esses quesitos, foram considerados os trabalhos existentes relacionados ao tema, principalmente os que apresentam o Modelo DeLone & McLean e o Modelo EUCS, citados na seção anterior. Os quesitos constantes desses dois modelos foram analisados e discutidos, chegando-se, assim, aos dez quesitos aqui considerados. O Quadro 1 define os quesitos que compõem a satisfação do usuário. Quesito Conteúdo do sistema Exatidão Segurança Formato Facilidade de uso Pontualidade da informação Velocidade do sistema Flexibilidade Atratividade Satisfação geral Quadro 1. Quesitos que compõem a satisfação do usuário Descrição Envolve o conteúdo das informações fornecidas pelo sistema, se estas informações são suficientes e se atendem às necessidades do usuário. Refere-se à confiabilidade do sistema e se a informação é exata. Indica se a informação é segura. Diz respeito ao formato em que os resultados são apresentados ao usuário. Refere-se à facilidade que o usuário tem para operar o sistema e obter o resultado desejado. Indica se a informação é obtida pelo usuário no momento que precisa dela e se essa informação é atualizada. Refere-se ao tempo que o usuário leva para obter as informações. Refere-se à possibilidade que o usuário tem de configurar ou definir o sistema ou parte dele. Refere-se às características atrativas do sistema, entre elas o aspecto visual. Diz respeito à satisfação do usuário na utilização do sistema, de uma maneira geral. O Quadro 2 apresenta as questões referentes a cada quesito considerado, além de uma questão final que solicita comentários de ordem geral. Quadro 2. Questões relacionadas aos quesitos da satisfação do usuário Questões por Quesito Conteúdo do sistema Q1. O conteúdo da informação vem ao encontro do que você necessita? Por exemplo, quando você solicita um relatório, o resultado é o que você realmente precisa? Q2. O sistema fornece informações completas e suficientes? Por exemplo, quando você solicita um relatório, o resultado é completo e suficiente? Exatidão Q3. A seu ver, o sistema fornece informações confiáveis? Por exemplo, para solicitações iguais, o sistema fornece resultados iguais? Q4. O sistema fornece informação exata? Por exemplo, o relatório de Turmas em Andamento apresenta as informações corretas e organizadas de forma adequada? Segurança Q5. A seu ver, o sistema é seguro? Por exemplo, o usuário pode utilizar senhas de acesso ao sistema? Q6. O sistema tem facilidade de recuperar erros? Por exemplo, se ocorrer um erro no sistema, os dados são recuperados com facilidade? Formato Q7. Você acha que o resultado é apresentado em um formato útil? Por exemplo, os relatórios, tabelas e listagens são mostrados de forma a destacar as informações importantes? Q8. A informação é clara? Por exemplo, você consegue visualizar rapidamente e facilmente a 217

239 informação de que necessita? Facilidade de uso Q9. Os menus e ícones do sistema facilitam a obtenção do que você precisa? Por exemplo, eles estão dispostos de uma maneira fácil de utilizar? Q10. Os nomes e figuras utilizados no sistema são significativos e fáceis de serem entendidos? Por exemplo, quando você quer utilizar uma função do sistema, você sabe imediatamente que figura ou nome você deve escolher? Pontualidade da informação Q11. O sistema sempre fornece informação atualizada? Por exemplo, ao ser solicitado o Controle de Notas, ele já vem com as notas atualizadas? Q12. Você tem a informação que precisa no prazo/tempo adequado? Por exemplo, quando você precisar de uma informação sobre um aluno, ela poderá ser obtida imediatamente? Velocidade do sistema Q13. A velocidade do sistema é satisfatória? Por exemplo, o sistema fornece as informações de forma rápida? Q14. Você está satisfeito com a rapidez em que o sistema opera? Por exemplo, tudo que você solicita do sistema é apresentado rapidamente? Flexibilidade Q15. O sistema é flexível? Por exemplo, o sistema disponibiliza diferentes visões, de acordo com o usuário? Q16. O sistema permite ser configurado? Por exemplo, de acordo com tarefas que você realiza, é fácil configurá-lo durante o seu uso? Atratividade Q17. O aspecto visual do sistema possui características atrativas? Por exemplo, o uso de cores, a disposição das informações e a apresentação dos menus compõem um visual interessante? Q18. Você se sente estimulado a utilizar o sistema? Satisfação geral Q19. De maneira geral, você se sente satisfeito com o uso do sistema? Q20. Você está satisfeito com a contribuição do sistema para melhorar o seu desempenho no trabalho? Informações Adicionais Q21. Comente aspectos que você considera importantes. Para avaliação dos quesitos, foram utilizadas métricas definidas por meio de uma escala de Likert de cinco pontos [Pereira, 2006], associada a cada questão listada no Quadro 2. A escala de Likert permite que os usuários informem qual o grau de concordância ou discordância com uma questão ou afirmativa apresentada, utilizando valores associados a métricas qualitativas previamente definidas. O Quadro 3 ilustra a escala adotada no estudo. métricas nunca ou quase nunca Quadro 3. Escala de Likert utilizada no estudo algumas vezes metade das vezes muitas vezes sempre ou quase sempre valores Definição e Realização do Estudo Empírico O estudo empírico foi organizado em etapas, de acordo com diretrizes propostas em Travassos (2002) e Wohlin (2000). O estudo teve como objetivo avaliar a satisfação do usuário do software SGA (Sistema de Gestão Acadêmica), um software de gestão escolar utilizado por uma Escola de Computação que ministra cursos de extensão e treinamento em informática, que possui várias franquias no estado de São Paulo. A avaliação da satisfação do usuário enfocou o módulo do software destinado às 218

240 coordenações e secretarias dos cursos, tomando por base o modelo apresentado na seção anterior. O SGA é usado por 40 unidades da Escola no estado de São Paulo, entre as quais foram escolhidas sete unidades da região de Campinas para participarem da pesquisa. Utilizou-se, portanto, uma amostra por conveniência [Levine, 2005], definida com base em facilidade para o pesquisador. Essa amostra constituiu-se dos 32 funcionários das sete unidades da Escola, que são usuários do sistema. Como usuários, foram considerados os funcionários das unidades da escola que utilizam o sistema SGA para desempenhar as tarefas da secretaria e da coordenação de cursos, incluindo controle de alunos, de turmas e de cursos ministrados pelas unidades. A coleta de dados foi feita por meio de três instrumentos: Questionário de Avaliação do Perfil do Usuário. Este questionário refere-se a informações gerais do perfil dos usuários que participaram do estudo, constando de seis perguntas de múltipla escolha. Formulário de Descrição das Tarefas. Este formulário compreende um conjunto de tarefas baseadas nas funções exigidas para a condução das atividades de secretaria e coordenação dos cursos na Escola, passíveis de serem apoiadas pelo SGA. Os usuários foram solicitados a exercitar essas tarefas, utilizando o sistema, antes de responderem o Questionário de Avaliação da Satisfação do Usuário. Questionário de Avaliação da Satisfação do Usuário. Este questionário é composto de 21 questões, sendo vinte questões a serem respondidas de acordo com a escala de Likert adotada e uma questão aberta (ver Quadro 2). Os participantes da avaliação deveriam responder cada questão, assinalando um dos valores apresentados na escala adotada. Tendo em vista o caráter exploratório do estudo, optou-se por definir duas perguntas básicas para a pesquisa, sem a formulação de hipótese, o que é um procedimento aceito para a condução de pesquisas [Pereira, 2004]. A pesquisa buscou responder às seguintes perguntas: Pergunta 1: Qual o nível de satisfação do usuário com o sistema, relacionado com cada um dos quesitos propostos, ou seja: conteúdo do sistema, exatidão, segurança, formato, facilidade de uso, pontualidade da informação, velocidade do sistema, flexibilidade, atratividade e satisfação geral? Para responder essa pergunta, foram analisadas as respostas dadas às questões constantes no Questionário de Avaliação da Satisfação do Usuário. Para determinar o nível de satisfação do usuário, enfocando cada quesito, foram assumidos os seguintes parâmetros: 219

241 - Um resultado incluindo entre 50% e 75% de respostas 4 (muitas vezes) e 5 (sempre ou quase sempre), em conjunto, indicaria que os usuários estavam satisfeitos com o sistema, sob o ponto de vista do quesito considerado. - Um resultado incluindo entre 76% e 100% de respostas 4 (muitas vezes) e 5 (sempre ou quase sempre), em conjunto, indicaria que os usuários estavam muito satisfeitos com o sistema, sob o ponto de vista do quesito considerado. - Um resultado incluindo entre 50% e 75% de respostas 1 (nunca ou quase nunca), 2 (algumas vezes) e 3 (metade das vezes), somadas, indicaria que os usuários estavam insatisfeitos com o sistema, sob o ponto de vista do quesito considerado. - Um resultado incluindo entre 76% e 100% de respostas 1 (nunca ou quase nunca), 2 (algumas vezes) e 3 (metade das vezes), somadas, indicaria que os usuários estavam muito insatisfeitos com o sistema, sob o ponto de vista do quesito considerado. Pergunta 2: Existe diferença entre o nível de satisfação com o sistema, expressado por diferentes categorias de usuários, considerando-se, nestas categorias, o tipo de atividade exercida e o tempo de experiência com o uso do sistema? Para responder essa pergunta, as respostas às questões constantes no Questionário de Avaliação da Satisfação do Usuário foram comparadas com os seguintes dados obtidos pelo Questionário de Avaliação do Perfil do Usuário: (a) tipo de atividade exercida pelo usuário, se atividade de secretaria ou atividade de coordenação; e (b) tempo de experiência do usuário com o sistema, se até 1 ano de experiência ou mais de 1 ano de experiência. Para identificar se existe diferença no nível de satisfação com o sistema, entre as diferentes categorias de usuários, foi aplicado o Teste Mann-Whitney [Pereira, 2004], considerando-se um nível de significância de 0,05 (1). A avaliação dos resultados obtidos foi realizada com base nos seguintes parâmetros: - Se o valor p, obtido no teste Mann-Whitney, for igual ou maior que 0,05, será considerado que não existe diferença significativa entre os níveis de satisfação do usuário em relação ao sistema, expressados pelas categorias consideradas. - Se o valor p, obtido no teste Mann-Whitney, for menor que 0,05, será considerado que existe diferença significativa entre os níveis de satisfação do usuário em relação ao sistema, expressados pelas categorias consideradas. Os seguintes cuidados foram tomados visando para garantir a validade do estudo: (1) O Teste Mann-Whitney é indicado para verificar se duas amostras pertencem ou não à mesma população ou se, em uma amostra aleatória, subdividida em grupos, existe uma diferença muito grande nas respostas provenientes dos diferentes grupos [Levine, 2005; Pereira, 2004]. 220

242 Realizar um teste piloto, com a colaboração de um usuário do sistema, a fim de verificar a compreensão do usuário em relação aos questionários. Ao realizar o teste, o usuário foi orientado a identificar questões ambíguas, não claras e confusas, o que possibilitou a realização de correções e complementações nos instrumentos de pesquisa. Enviar uma carta, entregue em mãos aos diretores das unidades participantes, explicando a importância da pesquisa para a melhoria da qualidade do software e, conseqüentemente, da produtividade dos funcionários nas suas atividades e decisões do dia-a dia da escola. Fazer uma reunião inicial com os participantes, explicando os detalhes da pesquisa e esclarecendo possíveis dúvidas. A coleta de dados foi executada nos meses de outubro e novembro de 2007, em datas agendadas com os diretores das respectivas unidades da escola. Os 32 usuários que compõem a amostra responderam os questionários. 5. Análise dos Dados e Resultados 5.1. Aspectos Gerais A análise dos dados embasou-se em fundamentos e técnicas da estatística [Levine, 2005; Pereira, 2004]. Os dados, coletados através dos questionários, foram processados através do software SPSS 10.1 [SPSS, 2007], sendo obtidas as freqüências de respostas às questões e preparados quadros e tabelas que elucidam os resultados. A discussão completa dos dados coletados, técnicas aplicadas e resultados obtidos é discutida em Perini (2008). A Tabela 1 contém as freqüências das respostas fornecidas pelos usuários às questões constantes do Questionário de Avaliação da Satisfação do Usuário. Para cada questão (Q1 a Q20), relacionada aos 10 quesitos que compõem o Modelo de Satisfação do Usuário, são mostradas a quantidade e a porcentagem de respostas obtidas, agrupadas com base nas métricas da escala de Likert adotada. Consultando-se a Tabela 1, verifica-se que: A maior freqüência de resposta, apontada por 23 usuários, foi a resposta 5, relativa à métrica sempre ou quase sempre da questão Q5. Conforme mostra o Quadro 1, a questão 5 refere-se ao quesito Segurança, que verifica se o usuário considera o sistema seguro. A freqüência obtida nesta questão indicou que 72% dos usuários mostraram-se satisfeitos quanto ao aspecto de segurança do Sistema SGA. 221

243 Quesitos Questões Tabela 1. Freqüência das respostas (1) Nunca ou quase nunca (2) Algumas vezes Categorias (escala de Likert) (3) Metade das vezes (4) Muitas vezes (5) Sempre ou quase sempre Conteúdo do Q1 0 0% 1 3% 3 9% 16 50% 12 38% sistema Q2 0 0% 3 9% 2 6% 15 47% 12 38% Exatidão Q3 0 0% 0 0% 3 9% 13 41% 16 50% Q4 1 3% 3 9% 2 6% 12 38% 14 44% Segurança Q5 2 6% 1 3% 1 3% 5 16% 23 72% Q6 2 6% 4 13% 5 16% 14 44% 7 22% Formato Q7 0 0% 1 3% 3 9% 17 53% 11 34% Q8 0 0% 1 3% 5 16% 15 47% 11 34% Facilidade de Q9 0 0% 1 3% 5 16% 14 44% 12 38% uso Q10 0 0% 2 6% 3 9% 12 38% 15 47% Pontualidade Q11 0 0% 1 3% 3 9% 16 50% 12 38% da informação Q12 0 0% 1 3% 3 9% 15 47% 13 41% Velocidade do Q13 0 0% 2 6% 4 13% 16 50% 10 31% sistema Q14 0 0% 4 13% 9 28% 12 38% 7 22% Flexibilidade Q % 5 16% 5 16% 9 28% 9 28% Q % 7 22% 6 19% 8 25% 6 19% Atratividade Q % 4 13% 5 16% 8 25% 6 19% Q18 0 0% 5 16% 2 6% 13 41% 12 38% Satisfação geral Q19 0 0% 2 6% 2 6% 15 47% 13 41% Q20 0 0% 1 3% 2 6% 14 44% 15 47% Figura 1. Gráfico de freqüências das respostas às questões A questão que obteve a maior freqüência de respostas 1 (relativa à métrica nunca ou quase nunca ) foi a questão Q17, com 9 respostas. Essa questão refere-se ao quesito Atratividade, abordando especificamente o aspecto visual do sistema, conforme mostra o Quadro 2. A freqüência obtida nesta questão indicou que 28% dos usuários não consideram o sistema visualmente atrativo, o que contribuiu para o nível deficiente de satisfação do usuário quanto à atratividade do Sistema SGA. A questão que obteve a maior freqüência de respostas 2 (relativa à métrica algumas vezes ) foi a questão Q16, com 7 respostas. Essa questão refere-se ao quesito Flexibilidade, perguntando especificamente se o sistema permite ser configurado pelo usuário. A freqüência obtida nesta questão indicou que 22% dos usuários afirmaram que o sistema permite ser configurado apenas algumas vezes, o que contribuiu para o nível deficiente de satisfação do usuário quanto à flexibilidade do Sistema SGA. A questão que obteve a maior freqüência de resposta 3 (relativa à métrica metade das vezes ) foi a questão Q14, com 9 respostas. Essa questão refere-se ao quesito Velocidade do Sistema, perguntando especificamente se o usuário está satisfeito com a rapidez em que o sistema opera. A freqüência obtida nesta questão indica que 28% dos usuários manifestaram que metade das vezes estão satisfeitos e metade das vezes estão insatisfeitos com esse quesito de qualidade do SGA. 222

244 A questão que obteve a maior freqüência de resposta 4 (relativa à métrica muitas vezes ) foi a questão Q14, com 17 respostas. Essa questão refere-se ao quesito Formato, perguntando especificamente se o usuário considera que as informações resultantes do sistema são apresentadas em um formato útil. A freqüência obtida nesta questão indica que 53% dos usuários manifestaram que muitas vezes o formato dos resultados do Sistema SGA gera satisfação Análise dos Quesitos da Satisfação do Usuário A Tabela 2 apresenta as porcentagens referentes às respostas dadas pelos usuários quanto à satisfação do usuário relativa a cada um dos quesitos que compõem a satisfação do usuário. Com base nessa tabela, serão analisados os resultados obtidos para os quesitos, a seguir. Com base nos valores mostrados na Tabela 2 e nos parâmetros assumidos para avaliação da Pergunta 1 da pesquisa, pode-se destacar aos seguintes resultados: Quanto ao Conteúdo do Sistema. Os resultados sugerem que os usuários estão muito satisfeitos com o sistema, no tocante ao quesito Conteúdo do Sistema. Isso porque a porcentagem das respostas 5 ( sempre ou quase sempre ), juntamente com a das respostas 4 ( muitas vezes ), somou 85,93 %. Adicionalmente, nenhum usuário anotou a resposta 1 (nunca ou quase nunca) e a porcentagem obtida somando-se as respostas 2 e 3 foi pequena, apenas14,1 %. Tabela 2. Porcentagem das respostas para cada quesito 1 Nunca ou quase nunca 2 Algumas vezes Metade das vezes 4 Muitas vezes Conteúdo do Sistema 0% 6,25% 7,85% 48,43% 37,35% Exatidão 1,56 4,68 7, ,87 Segurança 6,25 7,81 9,37 29,68 46,87 Formato 0 3,12 12, ,37 Facilidade de Uso 0 4,68 12, ,18 Pontualidade da Informação 0 3,12 9,37 48,43 39,06 Velocidade do Sistema 0 9,73 20,31 43,75 26,56 Flexibilidade 14,06 18,75 17,18 26,56 23,43 Atratividade 14,06 14,06 10,93 32,81 28,12 Satisfação Geral 0 4,65 6,25 45,31 43,71 5 Sempre ou quase sempre Quanto à Exatidão das Informações geradas pelo Sistema. Os resultados sugerem que os usuários estão muito satisfeitos com o sistema, no que se refere ao quesito Exatidão, uma vez que a soma das porcentagens das respostas 5 ( sempre ou quase sempre ) e 4 ( muitas vezes ) foi 85,87 %. Além disso, a soma das respostas negativas, incluindo os valores obtidos para as respostas 1, 2 e 3 foi apenas 14 %. Quanto à Segurança do Sistema. Os resultados sugerem que os usuários estão satisfeitos, porém não muito satisfeitos com o sistema, considerando-se o quesito Segurança. Pode-se assumir tal interpretação, pois a soma das porcentagens obtidas para as respostas 5 ( sempre ou quase sempre ) e 4 ( muitas vezes ) foi 76,55 %. Destaca-se também que a soma das demais respostas obtidas equivale a

245 23,43 %, o que é um indicativo para um menor nível de satisfação dos usuários com aspectos de segurança do sistema. Quanto ao Formato das Informações e Resultados gerados pelo Sistema. Os resultados sugerem que os usuários estão muito satisfeitos com o sistema, no tocante ao quesito Formato. Isso porque a porcentagem das respostas 5 ( sempre ou quase sempre ), juntamente com a das respostas 4 ( muitas vezes ), somou 84,37%. Adicionalmente, nenhum usuário anotou a resposta 1 (nunca ou quase nunca) e a porcentagem obtida somando-se as respostas 2 e 3 foi apenas 15,62 %. Quanto à Facilidade de Uso do Sistema. Os resultados sugerem que os usuários estão satisfeitos com o sistema, porém não muito satisfeitos, no tocante ao quesito Facilidade de Uso. Isso porque a porcentagem das respostas 5 ( sempre ou quase sempre ), juntamente com a das respostas 4 ( muitas vezes ), somou 67,18 %. Adicionalmente, nenhum usuário anotou a resposta 1 (nunca ou quase nunca) e a porcentagem obtida somando-se as respostas 2 e 3 foi 17,18 %. Quanto à Pontualidade da Informação gerada pelo Sistema. Os resultados sugerem que os usuários estão muito satisfeitos com o sistema, no tocante ao quesito Pontualidade da Informação. Isso porque a porcentagem das respostas 5 ( sempre ou quase sempre ), juntamente com a das respostas 4 ( muitas vezes ), somou 87,49 %. Adicionalmente, nenhum usuário anotou a resposta 1 (nunca ou quase nunca) e a porcentagem obtida somando-se as respostas 2 e 3 foi 12,49 %. Quanto à Velocidade do Sistema. Os resultados sugerem que os usuários estão satisfeitos com o sistema, porém não muito satisfeitos, no tocante ao quesito Velocidade. Isso porque a porcentagem das respostas 5 ( sempre ou quase sempre ), juntamente com a das respostas 4 ( muitas vezes ), somou 70 %. Adicionalmente, nenhum usuário anotou a resposta 1 (nunca ou quase nunca) e a porcentagem obtida somando-se as respostas 2 e 3 foi 30 %. Quanto à Flexibilidade do Sistema. Os resultados sugerem que nível de satisfação dos usuários está no limite entre satisfação e insatisfação, no que se refere à Flexibilidade, uma vez que a soma das porcentagem das respostas 5 ( sempre ou quase sempre ) e 4 ( muitas vezes ) foi 49,99 %. Além disso, a soma das respostas obtidas para os valores 1, 2 e 3 foi 50 %, o que é significativamente expressivo. Quanto à Atratividade do Sistema. Os resultados sugerem que os usuários estão satisfeitos com o sistema, porém não muito satisfeitos, no tocante à Atratividade. Isso porque a porcentagem das respostas 5 ( sempre ou quase sempre ), juntamente com a das respostas 4 ( muitas vezes ) foi 60,93 %. Complementarmente, a soma das respostas obtidas para os valores 1, 2 e 3 foi 40%. Quanto à Satisfação Geral com o Sistema. Os resultados sugerem que os usuários estão muito satisfeitos com o sistema, no tocante ao quesito Satisfação Geral com o sistema. Isso porque a porcentagem das respostas 5 ( sempre ou quase sempre ), juntamente com a das respostas 4 ( muitas vezes ), somou 89 %. 224

246 Adicionalmente, nenhum usuário anotou a resposta 1 (nunca ou quase nunca) e a porcentagem obtida somando-se as respostas 2 e 3 foi 10.9 %. Em suma, os resultados obtidos através da análise dos quesitos que compõem a satisfação do usuário são: Os usuários mostraram-se muito satisfeitos com os quesitos: Conteúdo do Sistema; Exatidão das Informações geradas pelo Sistema; Formato das Informações e Resultados gerados pelo Sistema; Pontualidade da Informação gerada pelo Sistema; e Satisfação Geral. Os usuários mostraram-se satisfeitos, porém não chegando a sentir-se muito satisfeitos com os quesitos: Segurança do Sistema; Facilidade de Uso do Sistema; Velocidade do Sistema; e Atratividade do Sistema. Os usuários indicaram estar em um nível limítrofe entre satisfação e insatisfação quanto ao quesito Flexibilidade do Sistema. Os usuários não se manifestaram muito insatisfeitos em relação a nenhum dos quesitos considerados no estudo Informações Adicionais A questão Q21 colheu informações adicionais que o usuário poderia fornecer sobre sua satisfação com o sistema SPG. Foram obtidas quinze respostas a essa questão, incluindo sugestões e críticas. Entre as sugestões, destacam-se: O aspecto visual do sistema poderia ser mais interessante; Alteração de layout de relatório e inclusão de novos filtros nos relatórios; Atribuição de novas funções ao sistema, como folha de pagamento, cartão ponto, pedido de autorização de material; Treinamento para diminuir as dúvidas na utilização do sistema; Inclusão de mais informações nos relatórios, e novos relatórios; A localização do aluno por meio de outros índices, como telefone, RG ou CPF; A inclusão de um link com os correios para ajudar na localização dos endereços através do campo CEP. As críticas apontadas foram: Algumas funções do sistema são difíceis de manusear, pois se o usuário selecionar uma opção errada, o resultado final pode ser comprometido; 225

247 As novas versões do sistema não levam em consideração a opinião do usuário, quanto às possíveis melhorias; Às vezes o sistema trava e gera mensagens de erro em inglês, sendo necessário contar com a ajuda do suporte para resolver o problema; Algumas vezes é necessário fechar a janela de chamada, e, ao reabri-la, verifica que o sistema não salvou as presenças já lançadas Análise por Categorias de Usuários Conforme citado na seção 5.1, foi empregado o Teste Mann-Whitney [Pereira, 2004] para verificar se diferentes categorias de usuários do sistema expressavam diferentes níveis de satisfação em relação a um ou mais quesitos constantes do Modelo de Satisfação do Usuário. Esse teste possibilitou uma análise comparativa entre os resultados referentes a grupos distintos de usuários, considerando-se, para isso: (a) dois grupos de usuários, determinados com base nas funções por eles executadas, ou seja, funções de secretaria e funções de coordenação; (b) dois grupos de usuários, determinados com base no tempo de uso do software, ou seja, até um ano e acima de um ano. Os resultados da análise feita através do Teste Mann-Whitney, assumindo-se um nível de significância de 0,05, são apresentados na Tabela 3. Tabela 3. Resultado do teste de Mann-Whitney Questões Função Tempo de uso por quesito Secretaria. Coordenação Até 1 ano Acima de 1 ano Medianas pvalor Medianas pvalor Conteúdo Q , ,50 Q , ,27 Exatidão Q , ,14 Q , ,73 Segurança Q , ,62 Q , ,31 Formato Q , ,15 Q , ,73 Facilidade de uso Q , ,71 Q , ,18 Pontualidade da Q , ,79 informação Q ,04* 4 4 0,34 Velocidade do sistema Q , ,22 Q , ,24 Flexibilidade Q , ,79 Q , ,47 Atratividade Q , ,32 Q , ,45 Satisfação geral Q , ,04* Q , ,38 * p < 0,05 há diferença significativa. 226

248 Os resultados mostrados na Tabela 2 levam às seguintes considerações: Quanto à Questão 12 (Q12). Essa questão refere-se à avaliação do quesito pontualidade da informação e indaga se o usuário tem a informação que precisa no prazo/tempo adequado. Os resultados mostraram que 58,82% dos usuários que desempenham funções de secretaria responderam sempre ou quase sempre, ao passo que apenas 20% dos usuários que desempenham funções de coordenação deram essa resposta. Tais resultados sugerem que o sistema atende mais prontamente às atividades mais estruturadas, que fazem parte do dia-a-dia da escola, fato que gera satisfação nos funcionários ligados a tais atividades. Porém, o sistema parece ser deficiente quanto ao atendimento de atividades de cunho gerencial, o que contribui para a insatisfação dos funcionários e professores que atuam na coordenação. Quanto à Questão 19 (Q19). Essa questão refere-se à avaliação do quesito satisfação geral e indaga se, de maneira geral, o usuário está satisfeito com o uso do sistema. Os resultados mostraram que a totalidade dos usuários (100%) que têm até um ano de uso do sistema manifestou-se positivamente satisfeita, ou seja, 38,46% dos usuários afirmaram estar muitas vezes satisfeitos e 61,54% afirmou estar sempre ou quase sempre satisfeitos. Em contrapartida, entre os usuários que utilizam o sistema há mais de um ano, houve 21,06% que responderam estar apenas algumas vezes satisfeitos e 10,53% afirmaram estar metade das vezes satisfeitos. Esse resultado sugere que os usuários com maior tempo de experiência com o sistema são mais críticos em relação às funcionalidades oferecidas pelo sistema, o que pode indicar a necessidade de atualizações periódicas e ajustes nos requisitos das diferentes classes de usuários Análise de Confiabilidade Para avaliar a consistência e confiabilidade do estudo, foi utilizado o teste estatístico que mede o Coeficiente Alfa de Cronbach, que identifica a relação entre covariâncias e variâncias internas das medidas. De acordo com Pereira (2004), o teste é robusto o suficiente para tolerar escalas não-homogêneas e basear-se em correlações calculadas como razão de covariâncias e variâncias. 4. Os valores obtidos através do Teste de Confiabilidade são mostrados na Tabela Tabela 4 Alfa de Cronbach para um indicador de Satisfação do Usuário Estatística Média Desvio Padrão N de Variáveis por Escala 3,9938 1,0450 (10) Coeficiente Confiável N de Casos = 32 N de Itens = 20 Alfa Geral = 0,8646 Os números obtidos para o coeficiente Alfa foram interpretados como indicadores da eficiência do Questionário de Avaliação da Satisfação do Usuário em avaliar os atributos de satisfação do usuário. O Alfa geral do estudo foi de 0,8646, o que 227

249 pode ser considerado um resultado bastante satisfatório, uma vez que, para um valor máximo de 1, obteve-se um Alfa de 0,8646. Isso significa que o estudo, de uma forma geral, teve consistência e que os resultados obtidos podem ser considerados confiáveis. 6. Conclusão Este trabalho abordou a satisfação do usuário de sistemas de software, visando atender a dois objetivos principais: propor um modelo de avaliação da satisfação do usuário; e discutir um estudo exploratório, realizado junto a usuários de um Sistema de Gestão Acadêmica, baseado no modelo proposto. O trabalho buscou contribuir para o tema enfocado, uma vez que o número de pesquisas sobre esse assunto é muito reduzido, principalmente no Brasil. Neste sentido, o Modelo de Satisfação do Usuário proposto poderá ser útil para futuras pesquisas e avaliações. Por sua vez, o estudo empírico realizado poderá servir de base para a condução de novas pesquisas que venham a ser realizadas. Considerando-se os principais estudos existentes sobre satisfação do usuário, o trabalho ora relatado representa um avanço, uma vez que propôs um Modelo de Satisfação do Usuário simples e claro, com 21 questões, que demonstrou ser viável de ser utilizado, na prática, para a avaliação de sistemas de software reais, envolvendo usuários reais. É importante destacar que os resultados obtidos através da pesquisa são representativos para o Sistema SGA, considerando-se sua utilização pelas unidades da Escola, que participaram da pesquisa. Neste sentido, a avaliação realizada apontou aspectos do Sistema SGA que precisam ser melhorados, com vistas a se atender mais amplamente as necessidades e expectativas das diferentes categorias de usuários do sistema considerado. Finalmente, cabe enfatizar a necessidade de trabalhos futuros, que contribuam para refinar, ajustar e validar o Modelo e o Processo de Execução de estudos empíricos similares. Referências Abdnnour, S.F., Chaparro, B.S. and Farmer, S.M. (2005) Using the End-User Computing Satisfaction (EUCS) Instrument to Measure Satisfaction with a Web Site, Decision Sciences, Volume 36, Number 2, p Abran, A., Khelif, A., Suryn, W. and Seffah, A. (2003) Consolidating the ISO Usability Models. Technical Report, Concordia University, Montreal, Canadá. Barner, M.E. A. (2006) Comparative Usability and End-User Satisfaction Analysis of two Geographic Information System (GIS) Applications. Technical Report, Graduate School of Engineering and Management, Air Force Institute of Technology, Ohio, USA. 228

250 Chin, W. and Lee, M.K. (2000) A Proposed Model and Measurement Instrument for the Formation of IS Satisfaction: The Case of End-User Computing Satisfaction, International Conference on Information Systems, Brisbane, Australia, p DeLone, W.H. and McLean, E.R. (1992) Information Systems Success: The Quest for the Dependent Variables, Information Systems Research, Volume 3, Number 1, p DeLone, W.H. and McLean, E.R. (2002) Information System Success Revisited, Proceedings of the 35 th Hawaiian International Conference on Systems Sciences, Big Island, Hawaii, p DeLone, W.H. and McLean, E.R. (2003) The DeLone and McLean Model of Information System Success: A Ten-Year Update, Journal of Management Information Systems, Volume. 19, Number 4, p Doll, W.J. and Torkzadeh, G. (1998) The Measurement of End-User Computing Satisfaction, MIS Quarterly, Volume 12, Number 2, p Iivari, J. (2005) An Empirical Test of the DeLone-McLean Model of Information System Success, The DATA BASE for Advances in Information Systems, Volume 36, Number 2, p Ives, B., Olson, M. and Baroudi, J. (1993) The Measurement of User Information Satisfaction, Communications of the ACM, Volume 26, Number 10, p Levine, D.M., Berenson, M.L. and Stephan, D. (2005) Estatística: Teoria e Aplicações, 3 ed., Rio de Janeiro: LTC Livros Técnicos e Científicos. Pereira, J.C. (2004) Análise de Dados Qualitativos. 3. ed., São Paulo: Editora da Universidade de São Paulo. Perini, J.C. (2008) Um Estudo sobre a Satisfação do Usuário de Sistemas de Software. Dissertação de Mestrado, Programa de Pós-Graduação em Ciência da Computação, Universidade Metodista de Piracicaba, SP. Sommerville, I. (2007) Engenharia de Software. 8 ed., São Paulo, Pearson. SPSS (2007) Statistical Package for de Social Sciences. Acessado em 10/11/2007. Disponível em: Travassos, G.H., Gurov, D. and Amaral, E.A. (2002) Introdução à Engenharia de Software Experimental. Relatório Técnico ES-590/02, Programa de Engenharia de Sistemas e Computação, COPPE UFRJ. Wohlin, C. et al. (2000) Experimentation in Software Engineering: an Introduction. Kluwer Academic Publishers, USA. Zviran, M., Gleser, C. and Avni, I. (2006) User Satisfaction from Commercial Web Sites: The Effect of Design and Use, Information & Management, Volume 43, Number 2, p

251 230

252 Um Modelo de Avaliação da Produtividade de Projetos de Software baseado em uma Abordagem Multicritério José Adson O. G. da Cunha 1,2, João Pedro C. Fernandes Thomaz 3,4, Hermano Perrelli de Moura 1 1 Centro de Informática Universidade Federal de Pernambuco (UFPE) Caixa Postal Recife PE Brasil 2 Unidade de Desenvolvimento Paraíba, DATAPREV Empresa de Tecnologia e Informações da Previdência Social João Pessoa PB Brasil 3 Faculdade Boa Viagem (FBV) Recife PE Brasil 4 Centro de Estudos de Gestão do Instituto Superior Técnico (CEG-IST) Lisboa Portugal jaogc@cin.ufpe.br, joaothomaz@netcabo.pt, hermano@cin.ufpe.br Abstract. In Software Engineering, productivity is determined by the interaction of many factors, so that none factor in particular is capable of ensuring high performance of a software project. Nevertheless, it is measured on a single way by the division between the quantities produced by the effort required. Therefore, it is necessary a way of measuring the real productivity of a software project taking into consideration the circumstances in which the software was developed. Thus, this article proposes a model for evaluating the productivity of software projects through a multicriteria approach. Resumo. No âmbito da Engenharia de Software, a produtividade é determinada pela interação de muitos fatores, de modo que nenhum fator em especial é capaz de garantir o alto desempenho em um projeto de software. Apesar disso, ela é medida de forma única, através da divisão entre a quantidade produzida pelo esforço necessário. Portanto, torna-se necessária uma forma de medição da real produtividade de um projeto de software que reflita as circunstâncias nas quais o software foi desenvolvido. Dessa forma, este artigo propõe um modelo de avaliação da produtividade de projetos de software através de uma abordagem multicritério. 1. Introdução Na Economia, a produtividade, de um modo geral, é a relação entre a quantidade de bens ou serviços produzidos e a despesa ou trabalho necessário para produzi-los (Jones, 1996). Conseqüentemente, a produtividade de software é a relação entre a quantidade 231

253 de software produzida e a despesa ou trabalho para produzi-la. Apesar de simples na teoria, na prática tal definição se torna um problema não muito trivial. Diversos estudos ao longo da história da Engenharia de Software procuraram identificar que fatores influenciam na produtividade e qualidade no desenvolvimento de software. Scacchi (1995) realizou um estudo, no qual discute as várias abordagens de medição da produtividade, bem como os fatores que afetam a produtividade, sugerindo a construção de um sistema de modelagem e simulação da produtividade em projetos de software baseado em conhecimento. Em seu estudo, Scacchi identificou dezoito fatores, dividindo-os em três grupos: os relacionados com o ambiente de desenvolvimento, com o produto a ser desenvolvido e com a equipe envolvida. Jones (1986) aponta mais de quarenta variáveis que podem influenciar na produtividade do desenvolvimento de software. O modelo de estimativa de custo COCOMO II (Boehm, 1996) divide os fatores em quatro grupos: relacionados com o produto, com os computadores utilizados no projeto, com a equipe de pessoas envolvida e com o projeto (que inclui práticas de desenvolvimento). White (1999) divide os fatores em quatro grupos: relacionados com o produto, com a equipe de pessoas envolvidas, com a tecnologia utilizada e com o processo utilizado. De acordo com Chiang (2004), a melhoria na produtividade no desenvolvimento de software se dá através do balanceamento de três pilares do gerenciamento de software: tecnologia, pessoas e processo. Clincy (2003) realizou um estudo com líderes de projeto de diferentes organizações e concluiu que as áreas que mais impactam na habilidade da organização de aumentar sua produtividade são: estrutura e clima organizacional, sistemas de recompensa, processos de desenvolvimento de software e uso de ferramentas. Taylor (2005) concluiu que, além dos demais fatores, o foco na melhoria da cultura organizacional pode trazer grandes benefícios na produtividade da organização. Outros trabalhos, além de realizar análises dos vários fatores que afetam a produtividade e qualidade, apontam padrões de comportamento e organização de projetos de software que possibilitam alta produtividade. Bailey et al. (1981) concluíram que a alta produtividade está diretamente relacionada com o uso de metodologia de desenvolvimento de software disciplinada. Já Behrens (1983) concluiu em sua análise realizada em vinte e cinco projetos de desenvolvimento de software que o tamanho do projeto, o ambiente de desenvolvimento e linguagem de programação impactam na produtividade. Em particular, o autor concluiu que pequenos times produzem mais código do que grandes times. Boehm (1981) reporta que a produtividade em um projeto de desenvolvimento de software é mais fortemente afetada por aqueles que desenvolvem o sistema e pela forma como estes estão organizados e gerenciados como time. Scacchi (1984) complementa esta evidência revisando alguns relatórios sobre gerenciamento de grandes projetos. Nesta revisão, ele confirma que quando projetos são mal gerenciados ou organizados, a produtividade é substancialmente mais baixa do que o normal. DeMarco (1999) em seu trabalho que envolveu a análise de aproximadamente 600 desenvolvedores de 92 organizações, defende que os principais problemas de produtividade estão relacionados a fatores humanos e organizacionais e não a fatores técnicos como muitos defendem. O autor apresenta, inclusive, uma série de 232

254 experimentos realizados com o objetivo de identificar tais fatores e em seus resultados fica explícita tal afirmação. Nestes experimentos, fatores como linguagem de programação adotada, faixa salarial e experiência na função não influenciam significativamente na produtividade. Já outros fatores, como espaço físico individual e nível de ruído no ambiente de trabalho afetam de um modo muito intenso. De fato, a produtividade é determinada pela interação de muitos fatores, de modo que nenhum fator em especial é capaz de garantir a alta produtividade em um projeto de software. Altos níveis de um determinado fator podem beneficiar o aumento da produtividade, mas um fator isoladamente não é suficiente para a obtenção de um alto nível de produtividade (Scacchi, 1995). De modo a estimar o esforço, bem como planejar o desenvolvimento de um software, gerentes de projetos precisam muitas vezes se basear nos resultados de bases históricas. Para tanto, é necessário que as circunstâncias nas quais os projetos foram desenvolvidos sejam documentadas de forma padronizada. No entanto, atualmente, a produtividade é medida de forma única, através da divisão entre a quantidade produzida (geralmente medida em linhas de código ou pontos de função) pelo esforço necessário (geralmente medido em horas ou homem-mês). A tarefa de avaliar um projeto de software segundo os vários fatores que afetam a produtividade constitui-se um problema multicritério. Problemas dessa natureza são comumente solucionados através de abordagens multicritério, que, segundo Bouyssou (1990), caracterizam-se pela construção de vários critérios através da utilização de vários pontos de vista. Estes pontos de vista representam os eixos através dos quais os diversos atores de um processo de decisão justificam, transformam e questionam as suas preferências, realizando comparações com base na avaliação das alternativas de acordo com estes pontos de vista e estabelecendo, então, as preferências parciais. Um dos principais objetivos dos modelos multicritério é a agregação de diferentes e conflitantes critérios em um indicador de desempenho (Santana, 2002). Os métodos de agregação a um critério único de síntese são abordagens multicritério onde a avaliação das alternativas é feita segundo uma função global de valor, que agrega todos os pontos de vista considerados fundamentais. Dessa forma, este artigo propõe um modelo de avaliação da produtividade que incorpore os fatores que influenciam no desenvolvimento de um projeto de software, através de uma abordagem multicritério. O restante do artigo está organizado da seguinte forma: a Seção 2 apresenta a metodologia utilizada para elaboração do modelo; a Seção 3 apresenta como o modelo foi estruturado; a Seção 4 apresenta a fase de avaliação do modelo; a Seção 5 apresenta as recomendações a partir de projetos fictícios; e por fim, a Seção 6 apresenta as conclusões. 2. Metodologia Utilizada De modo a construir o modelo proposto, foi utilizada a Metodologia de Conferências de Decisão (Phillips, 1982), que consiste em uma série de reuniões de trabalho intensivo, 233

255 chamadas de conferências de decisão, sem uma agenda pré-definida, tampouco apresentações preparadas, sendo compostas por grupos de pessoas que representam as várias dimensões da situação problemática, podendo durar de um a três dias, dependendo da complexidade do problema. Uma característica exclusiva é a criação, no local, de um modelo que incorpora dados e julgamentos dos participantes (Enterprise LSE, 2008). A integração da Teoria da Decisão (processo técnico de modelagem do contexto e situação decisional), das Tecnologias de Informação (processo tecnológico de apoio computacional especializado) e dos Processos de Grupo (processo social de facilitação para planejar e dirigir uma reunião bem sucedida, mantendo-a imparcial e focada nas necessidades do grupo), na Metodologia de Conferências de Decisão, conforme mostrado na Figura 1, permite criar sinergias que irão tornar o produto final das sessões de trabalho (valor) maior do que a soma das suas partes (Reagan-Cirincione, 1994). Figura 1. Metodologia de Conferências de Decisão (Thomaz, 2005) De modo a apoiar a decisão através da determinação dos fatores a serem considerados para a construção de um modelo multicritério, os participantes tiveram que ser rigorosamente escolhidos para representar as várias dimensões do problema em questão. As sessões foram compostas por seis participantes, além do facilitador, sendo três engenheiros de qualidade, com experiência em análise de requisitos, um consultor em métricas, um consultor em testes, com experiência em codificação e um gerente de projetos. Dos seis participantes, três são mestres e dois são mestrandos, além de um possuir certificação PMP. Dessa forma, constituiu-se uma equipe heterogênea, com membros experientes em áreas específicas da Engenharia de Software. Ao todo, foram realizadas quatro sessões de conferências de decisão, respeitando a restrição de tempo imposta pelos participantes, o que de certa forma não comprometeu o resultado final. As sessões foram realizadas em uma empresa de desenvolvimento e pesquisa reconhecida internacionalmente, avaliada como CMMI nível 3. Maiores detalhes sobre as fases de elaboração do modelo podem ser obtidas em Cunha (2008). 234

256 3. Estruturação do Modelo A fase de estruturação deu-se início com um pequeno brainstorming, auxiliado pela técnica de Oval Mapping Technique (Ovalmap, 2008) com a utilização de post-its, através da qual foram levantados alguns conceitos que serviram de pontos de partida para a determinação dos conceitos fundamentais para a resolução do problema. Foram fornecidos três post-its a cada participante para que escrevessem em cada um deles um conceito, aspecto ou uma pequena descrição que indicasse um fator considerado importante para a avaliação da produtividade de projetos de software. Uma vez preenchidos, tais post-its foram recolhidos e, um a um, lidos e colocados em um quadro, sendo levantadas questões sobre os conceitos expressos, de modo a esclarecer o seu significado e manter o grupo concentrado na compreensão dos aspectos referidos. A Figura 2 apresenta os post-its preenchidos pelos participantes. Figura 2. Sessão de post-its A partir das discussões entre os participantes, foi ficando evidente que muitos dos elementos do grupo tinham preocupações semelhantes sobre o problema, o que permitiu ao facilitador agrupar estes aspectos no quadro por áreas de preocupação, ou seja, em subconjuntos de aspectos relacionados ou similares, conforme a Figura 3. Toda esta atividade do grupo foi desenvolvida em um ambiente de diálogo e com a utilização de questões de diagnóstico (Schein, 1999) sobre o porquê? e o para quê? de cada um dos aspectos considerados importantes, fazendo uso dos princípios e técnicas da consultoria de processos de grupo (Thomaz, 2005). Nesta fase, o facilitador teve que muitas vezes parar a discussão para procurar esclarecer o significado de conceitos e obter definições que ajudassem a clarificar o conceito que se pretendia transmitir no post-it (ou durante a discussão). 235

257 Figura 3. Post-its agrupados Através da discussão realizada, foi possível reavaliar a importância de cada aspecto para a avaliação da produtividade de projetos de software e identificar novos aspectos e relações entre as várias dimensões do problema, o que permitiu descartar aspectos e renomear outros que não traduziam o conceito ou a idéia pretendida, sendo vários deles reescritos, desagregados ou agregados. Uma vez definido o mapa cognitivo, foi necessário construir a árvore de pontos de vista. Um ponto de vista (PV) é a representação de um valor julgado suficientemente importante pelos atores para ser considerado de uma forma explícita no processo de avaliação das ações ou alternativas, podendo ser classificados em pontos de vista fundamentais (PVF) e pontos de vista elementares (PVE) (Bana e Costa, 1992 in Thomaz, 2005). Um ponto de vista fundamental reflete um valor relevante no contexto do problema, enquanto que os pontos de vista elementares são meios para se alcançar os pontos de vista fundamentais. A Figura 4 mostra a árvore de pontos de vista construída para este problema. Conforme já referido, a árvore foi elaborada pelo facilitador e discutida com os atores. A árvore apresentada representa a estrutura definitiva do problema, não sendo a primeira proposta do facilitador e incorpora as modificações julgadas convenientes pelos atores não alterando, no entanto, a estrutura geral inicialmente obtida. 236

258 Figura 4. Árvore de Pontos de Vista Para viabilizar um consenso entre os atores, e evitar dúvidas quanto ao que buscam representar os diversos elementos de avaliação, tornando os PVF's inteligíveis, os conceitos dos vários PVF's apresentados na Figura 4, a partir dos seus respectivos PVE's, foram definidos, conforme abaixo: PVF 1 Experiência da Equipe: Corresponde às características da equipe em relação à capacidade de aplicar os conhecimentos teórico-práticos, tempo de uso desta capacidade para fins práticos e a aprendizagem demonstrada, conforme os PVE s abaixo. o PVE 1.1 Tempo: Tempo de experiência na área de atuação. o PVE 1.2 Conhecimento teórico-prático: Nível de conhecimento na área de atuação. o PVE 1.3 Capacidade de Aprendizagem: Aprendizado conquistado pelos membros ao final do projeto, em relação ao conhecimento dos mesmos no início do projeto. PVF 2 Ambiente de Trabalho: Corresponde ao ambiente proporcionado aos membros do projeto, em termos de estrutura física e cultura organizacional, conforme os PVE s abaixo. 237

259 o PVE 2.1 Estrutura Física: Adequação da empresa aos requisitos ergonômicos, de higiene, de segurança e de equipamentos, além do nível de barulho existente. o PVE 2.2 Cultura Organizacional: Cultura da empresa quanto à existência de procedimentos normalizados, de um ambiente sóciocultural, assim como de projeção internacional. PVF 3 Capacidade do Projeto: Corresponde às características dos membros da equipe em termos de organização, liderança e trabalho em equipe, conforme os PVE s abaixo. o PVE 3.1 Organização: Existência e atualização do planejamento por parte do gerente de projeto, com a definição do cronograma, pontos críticos, metas, alinhando à equipe com os resultados. o PVE 3.2 Liderança: Capacidade do líder (gerente de projeto) em conduzir a equipe ao sucesso. o PVE 3.3 Trabalho em Equipe: Nível de envolvimento, integração e compromisso mútuo dos membros do projeto para com os resultados. PVF 4 Processo: Corresponde à adaptabilidade do processo, bem como o grau de automação disponível para o mesmo, conforme os PVE s abaixo. o PVE 4.1 Adaptabilidade: Capacidade do processo de ser modificado de modo a torná-lo mais produtivo, diante das características do projeto. o PVE 4.2 Automação: Nível de utilização de ferramentas para automatizar as atividades do processo. PVF 5 Complexidade do Projeto: Corresponde à complexidade do projeto em termos da complexidade técnica e do negócio, conforme os PVE s abaixo. o PVE 5.1 Complexidade Técnica: Variedade de tecnologias utilizadas no projeto, bem como ao nível de complexidade dos algoritmos utilizados. o PVE 5.2 Complexidade do Negócio: Complexidade oriunda do domínio da aplicação. PVF 6 Cliente: Corresponde à participação do cliente ao longo do projeto, em termos da volatilidade dos requisitos e do envolvimento do mesmo ao longo do projeto, conforme os PVE s abaixo. o PVE 6.1 Volatilidade dos Requisitos: Nível com que os requisitos são modificados ao longo do projeto. o PVE 6.2 Envolvimento do Cliente: Nível de participação do cliente ao longo do projeto. Uma vez definidos os pontos de vista fundamentais, foi necessário operacionalizá-los, ou seja, construir seus descritores. De acordo com Bana e Costa 238

260 (1992), um descritor é definido como um conjunto ordenado de níveis de impacto plausíveis associado a um ponto de vista fundamental j, denotado por N j, onde cada nível de impacto deste descritor é denotado por N k,j, e corresponde à representação do impacto de uma ação ideal, de tal forma que da comparação de quaisquer dois níveis do descritor resulte sempre uma diferenciação clara, aos olhos dos atores, no que se refere aos elementos primários de avaliação que formam este ponto de vista fundamental. Uma vez que foi constatada a não existência de descritores diretos (ou naturais) para os PVF s, os mesmos foram operacionalizados através de descritores construídos, através de combinações entre os níveis dos descritores dos seus respectivos PVE s. Para cada PVF, foram definidos 3 a 5 níveis, dentre os quais os níveis Bom e Neutro, a serem utilizados posteriormente na ponderação dos pontos de vista fundamentais. A indicação de tais níveis é importante de modo a eliminar a influência de níveis de impacto considerados muito negativos, segundo o avaliador, de modo a não prejudicar a determinação dos pesos. De modo a exemplificar a construção dos descritores, será considerado o PVF 4 Processo, o qual foi operacionalizado através de um descritor qualitativo, construído e discreto, formado pelos PVE s Adaptabilidade e Automação. O PVE 4.1 Adaptabilidade foi operacionalizado através de um descritor qualitativo, construído e discreto, correspondendo à capacidade do processo de ser modificado de modo a torná-lo mais produtivo, em se tratando da necessidade de artefatos a serem produzidos. De modo a construir o descritor do PVF, foram definidos os níveis deste PVE, conforme a Tabela 1. Tabela 1. Descritor do PVE 4.1 Adaptabilidade O PVE 4.2 Automação foi operacionalizado através de um descritor qualitativo, construído e discreto, correspondendo ao nível de cobertura das ferramentas em relação às atividades do processo. De modo a construir o descritor do PVF, foram definidos os níveis deste PVE, conforme a Tabela 2. Tabela 2. Descritor do PVE 4.2 Automação 239

261 O PVF 4 - Processo foi operacionalizado através da combinação dos níveis dos descritores dos PVE s que o formam, conforme definido na Tabela 3, onde o nível N4 foi considerado Bom e o nível N2 Neutro. Tabela 3. Descritor do PVF 4 Processo O mesmo procedimento foi realizado para a construção dos descritores dos demais pontos de vista fundamentais, respeitando a verificação da não-ambiguidade, de forma a não haver perda de informação na associação de um determinado nível de impacto a um projeto (entre a pessoa que o associou e a outra que o interpreta). 4. Avaliação do Modelo A atividade de construção de escalas foi realizada com o uso da metodologia MACBETH (Measuring Attractiveness by a Categorical Based Evaluation Technique), uma técnica interativa de apoio à construção, sobre um conjunto S de estímulos ou ações potenciais, de escalas numéricas de intervalos que quantifiquem a atratividade dos elementos de S na opinião do(s) ator(es), baseada em juízos semânticos de diferença de atratividade entre duas ações (Bana e Costa et al., 1994). É útil tanto para a construção de uma função de valor cardinal, quanto como técnica de ponderação, para a determinação de constantes de escala (taxas de substituição, pesos) em um modelo de agregação aditiva. A idéia básica da abordagem MACBETH para a obtenção de escalas de valor cardinal é fazer um conjunto de questões sobre a diferença de atratividade entre dois estímulos e através de respostas semânticas permitir obter informação sobre cada PVF 240

262 (intra-critério), testando a consistência das respostas do decisor para obter uma escala cardinal compatível com os julgamentos semânticos (respostas) dados. Assim, o procedimento de questionamento consiste em solicitar ao decisor um julgamento verbal (qualitativo) sobre a diferença de atratividade entre cada duas ações x e y do conjunto S de estímulos ou ações (com x mais atrativo que y ), escolhendo uma das seguintes categorias semânticas de diferença de atratividade (C k ): Dessa forma, partiu-se para a construção das matrizes triangulares superiores de juízos de valor (ou de julgamentos absolutos de diferença de atratividade) sobre cada um dos descritores, obtendo escalas de valor cardinal que vão possibilitar a avaliação local (parcial) dos projetos de software em cada ponto de vista fundamental. Durante o processo de construção das matrizes ocorreram alguns casos de inconsistência cardinal que foram resolvidos através de discussões entre o facilitador e os atores, com a conseqüente modificação de alguns julgamentos. Os seis pontos de vista fundamentais foram operacionalizados através de descritores qualitativos, construídos e discretos, embora alguns deles possuam pontos de vistas elementares avaliados com descritores quantitativos. De modo a refinar as funções de valor e aumentar a inteligibilidade da escala obtida, foram criados três projetos fictícios, onde Proj 1 corresponde ao nível mais elevado em todos os PVF s, Proj 2 corresponde a um projeto entre Bom e Neutro em todos os PVF s, e Proj 3 corresponde a um projeto abaixo de Neutro em todos os PVF s. Assim, as matrizes ficaram com cinco níveis, compostos pelas 3 opções (projetos fictícios) e 2 níveis de referência ( Bom e Neutro ). Como se pode observar na Figura 5, nas matrizes de julgamento não houve unanimidade na atribuição de uma categoria semântica MACBETH para as diferenças de atratividade entre os alguns dos níveis de impacto, como no caso da diferença de atratividade entre o nível Proj 1 e o nível Neutro (Forte Muito Forte), do PVF 1. No entanto, tal hesitação foi considerada e aceita pela metodologia MACBETH obtendo-se assim, a escala de valor cardinal, à direita da figura, para este ponto de vista. É, obviamente, aconselhável que não haja hesitações que correspondam a grandes intervalos de diferença de atratividade para cada par, como por exemplo Fraco Muito Forte, uma vez que demonstra pouco conhecimento do problema por parte dos atores ou uma situação pouco esclarecida. A escala obtida na Figura 5 representa os valores cardinais gerados pelo MACBETH para cada um dos quatro níveis de impacto do descritor do PVF 4 Processo, através dos quais os projetos de software serão avaliados, segundo este PVF. 241

263 150 Escalas Macbeth Proj 3 Neutro Proj 2 Bom Proj 1 Níveis de Impacto Figura 5. Matriz de Juízos de Valor e Escala do PVF 4 Processo Uma vez definidas as funções de valor cardinal de cada PVF, foi necessário definir os pesos (fatores de harmonização de escala). Antes de proceder com os julgamentos de diferença de atratividade, os participantes tiveram que ordenar os PVF s em ordem decrescente de atratividade (condição para a utilização de uma matriz triangular superior). Concluída a ordenação dos PVF s, a matriz de julgamentos foi preenchida. Uma vez que não existia uma noção clara da diferença de atratividade entre os PVF s, optou-se por julgar a maioria das diferenças como positiva, como mostrado na Figura 6, verificando de seguida se a escala produzida correspondia à sensibilidade e intuição dos participantes. Figura 6. Matriz de Juízos de Valor para Obtenção das Taxas de Substituição A Figura 7 apresenta o histograma dos pesos atribuídos aos PVF s, onde o PVF 1 - Experiência da Equipe foi julgado como sendo o mais relevante dentro dos pontos de vista importantes para a avaliação da produtividade e o PVF 6 - Cliente como sendo o menos relevante nessa avaliação. Figura 7. Ponderação dos PVF s 242

264 5. Elaboração das Recomendações Uma vez concluído o processo, foram efetuadas as recomendações baseado no modelo de avaliação proposto. A Tabela 1 apresenta o resultado final do processo, com as avaliações globais das ações (ou projetos) fictícios diante dos seis pontos de vista fundamentais, através da agregação dos mesmos possibilitada pelos pesos, representando assim os índices de produtividade dos projetos. Sendo as escalas fixadas em dois pontos, Neutro com 0 pontos e Bom com 100 pontos, a ação Proj 1, com pontos, apresentou um rendimento superior à ação globalmente boa ( Bom ), enquanto a ação Proj 3, com pontos apresentou um rendimento inferior à ação globalmente neutra ( Neutro 0.00). Tabela 1. Resultado do modelo Dessa forma, caso o modelo fosse utilizado para fins de benchmarking, o resultado provido pelo índice poderia fornecer informações aos gerentes de projetos que queiram utilizar os dados daquele projeto para estimar o esforço de seu projeto. Dessa forma, além de possuir a métrica padrão de produtividade, o gerente de projetos poderá contar com as circunstâncias nas quais o software foi desenvolvido, representado pelo índice. Diante das restrições de tempo, o modelo não pôde ser discutido mais a fundo com os participantes das sessões. Desse modo, através da prática, o modelo apresentado pode servir de base para a elaboração de um modelo mais completo, com a participação de mais pessoas especialistas e com tempo disponível para as discussões que norteiam a elaboração de qualquer modelo. 6. Conclusões A integração da Metodologia de Conferências de Decisão com a Metodologia Multicritério de Apoio à Decisão, das técnicas de mapeamento cognitivo e da abordagem MACBETH, permite construir um modelo capaz de representar tanto os vários objetivos conflitantes dos participantes e sua subjetividade inerente, quanto a inevitável incerteza em relação às conseqüências futuras, constituindo assim uma ferramenta para pensar que permite aos participantes a visualização das conseqüências lógicas das suas decisões, sob diversos pontos de vista. A incorporação dos juízos valores do decisor, os múltiplos critérios, a interação e aprendizagem dos intervenientes, a abordagem de estruturação por pontos de vista e a utilização do software M-MACBETH, como gerador de funções de valor cardinal e das importâncias relativas dos pontos de vista fundamentais, se apresentaram como ferramentas bastante eficazes na apreciação de problemas multicritério. 243

265 Quando ao modelo proposto, uma vez que a simples medição da produtividade através da divisão da quantidade produzida pelo esforço gasto não retrata fielmente as circunstâncias nas quais um projeto foi desenvolvido, procurou-se através de uma abordagem multicritério elaborar um modelo que reflita a produtividade, levando em consideração os fatores elencados por especialistas nas diversas áreas da Engenharia de Software, em sessões de Conferências de Decisão. Dessa forma, além da utilização da medição padrão da produtividade (tamanho / esforço), gerentes de projetos poderiam utilizar o modelo proposto para enriquecer as bases históricas de projetos de software, de modo a tornar possível a realização de benchmarking permitindo a estimativa de esforço baseado em projetos similares levando em consideração as avaliações de cada projeto segundo o modelo proposto, refletindo assim as circunstâncias nas quais o software foi desenvolvido. O modelo proposto vem, assim, preencher o gap existente na avaliação da produtividade de projetos de software, o qual até então é medido através da quantidade produzida pelo esforço necessário. O índice de produtividade provido através do modelo proporcionará uma maior riqueza de informações quando a produtividade de projetos for utilizado para estimativa de esforço de projetos futuros. Referências Bailey, J. and Basili, V. (1981) A Meta-Model for Software Development Resource Expenditures. In: Proc. 5th. Intern. Conf. Soft. Engr., IEEE Computer Society, pp Bana e Costa. C.A., (1992) Structuration, Construction et Exploitation d'un Modèle Multicritère d'aide à la Décision, Tese de Doutoramento em Engenharia de Sistemas, Universidade Técnica de Lisboa, IST, Lisboa. Bana e Costa, C.A, Vansnick, J.C. (1994) MACBETH Na interactive path towards the construction of cardinal value functions, International Transactions in Operational Research, 1, 4, ( ). Behrens, C. A. (1983) Measuring Software Productivity of Computer System Development Activities with Point Functions. IEEE Trans. Soft. Engr. SE-9(6), pp Boehm, B. (1981) Software Engineering Economics. Prentice-Hall, Englewood Cliffs, NJ. Boehm, B. W. et al. (1996) The COCOMO 2.0 Software Cost Estimation Model. American Programmer, July, pp Bouyssou, D. (1990) Building Criteria: A prerequisite for MCDA, in: Bana e Costa, C. A. (Ed.), Readings in Multiple Criteria Decision Aid, Springer-Verlag, Berlin, (58-80). Chiang, R. and Mookerjee, S. (2004) Improving Software Team Productivity. Communications of the ACM. Volume 47, Issue 5. Pages:

266 Clincy, V. A. (2003) Software Development Productivity and Cycle Time Reduction. Journal of Computing Sciences in Colleges. Volume 19, Issue 2. Pages: Cunha, José Adson O. G. (2008) Decisius: Um Processo de Apoio à Decisão e sua Aplicação na Definição de um Índice de Produtividade para Projetos de Software. Dissertação de Mestrado. Universidade Federal de Pernambuco. DeMarco, T. (1999) Peopleware: Productive Projects and Teams, 2nd Ed. Dorset House Publishing. Enterprise LSE (2008), Decision Conferencing. Disponível em: Consulta realizada em 20/01/2008. Jones, C. (1986) Programming Productivity, McGraw-Hill, New York. Jones, C. (1996) Applied Software Measurement: Assuring Productivity and Quality. 2 ed. McGraw-Hill. Ovalmap (2008) Acessado em 26/01/2008. Phillips, L. D. (1982) Requisite decision modelling: A case study, Journal of the Operational Research Society, 33, 4 (pp ). Reagan-Cirincione, P. (1994), Improving the accuracy of group judgment: A process intervention combining group facilitation, social judgment analysis, and information technology, Organizational Behavior and Human Decision Processes, 58 (pp ). Santana, E. A. (2002) Contrato satisfatório multidimensional e a teoria do incentivo, Revista Brasileira de Economia, 56, 4 (pp ). Scacchi, W. (1984) Managing Software Engineering Projects: A social Analysis. IEEE Trans. Soft. Engr., SE-10(1), pp Scacchi, W. (1995) Understanding Software Productivity. Appears in Advances in Software Engineering and Knowledge Engineering, D. Hurley (ed.), Volume 4, pp Schein, E. H. (1999), Process Consultation Revisited: Building the Helping Relationship, Addison-Wesley, Reading, MA. Taylor, B. (2005) Organizational Culture is Important in Software Productivity. Thomaz, João Pedro da Cruz Fernandes (2005) O Apoio à Tomada de Decisão na Avaliação do Desempenho de Pessoas: Contributos para o Processo de Decisão Militar em Tempo de Paz, Tese de Doutorado, Instituto Superior Técnico, Universidade Técnica de Lisboa. White, K. S. (1999) Software Engineering Management For Productivity And Quality. In: International Conference on Accelerator and Large Experimental Physics Control Systems, Trieste, Italy. 245

267 246

268 Um Simulador Estocástico de Processo de Software Baseado em Conhecimento Breno Bernard Nicolau de França 1,2, Rodrigo Quites Reis 1,2 1 Programa de Pós-Graduação em Ciência da Computação Universidade Federal do Pará (PPGCC-UFPA) Belém PA Brasil 2 Laboratório de Engenharia de Software - Universidade Federal do Pará Belém PA Brasil breno@webapsee.com, quites@computer.org Abstract. The process behavior understanding capability, besides the opportunity to previously infer the impact of process changes, make simulation a potential decision support tool to software organizations. This paper presents a software process simulation model based on the concepts of Software Process Historical Data, Case-Based Reasoning (Analogy) and Monte Carlo Simulation. The current model is implemented and integrated to an Automated Environment, which enables the extraction of previous enactment data. Resumo. A capacidade de entendimento de como o processo se comporta em termos de desempenho, além da oportunidade de verificação a priori do impacto de mudanças no processo, tornam a simulação uma ferramenta com potencial para tomada de decisão nas organizações. Este artigo apresenta um modelo de simulação de processo de software baseado nos conceitos de Histórico de Processo de Software, Raciocínio Baseado em Casos (analogia) e Simulação de Monte Carlo. O modelo encontra-se implementado e integrado em um Ambiente Automatizado, explora os recursos já disponíveis na plataforma para extrair e executar modelos de simulação com base no histórico da organização. 1. Introdução Grande demanda tem surgido, tanto na Academia quanto na Indústria, por processos organizacionais definidos para apoiar o desenvolvimento de software. Isto é evidenciado em trabalhos científicos como [Jacobson, Booch e Rumbaugh 1999] e em editais de contratação de projetos de software, inclusive do Governo [TI Inside 2007], onde padrões de qualidade e maturidade em desenvolvimento de software são exigidos. Essa demanda ocorre em função da qualidade do produto ter uma íntima relação com a qualidade do processo executado para construir este produto [Fuggetta 2000]. Por isso, iniciativas como o MPS.Br [Softex 2008] visam, assim como CMMI [CMU/SEI 2006] e normas ISO [ISO/IEC 2004], estabelecer boas práticas e padrões de qualidade e maturidade em software, certificando e avaliando organizações que desenvolvem software quanto à sua capacidade de produzir resultados planejados e com 247

269 alta qualidade. Embora exista grande esforço pela qualidade, muitos projetos de software falham ou ultrapassam custos e prazos por problemas de planejamento [Little 2006]. Os motivos comuns para a utilização da simulação de modelos de processos recaem, segundo [Kellner, Madachy e Raffo 1999], em seis grandes categorias: 1) gerência estratégica, 2) planejamento, 3) gerência operacional e de controle, 4) melhoria de processo e adoção de tecnologia, 5) compreensão e treinamento, e 6) aprendizado. A simulação tem sido referenciada, ainda, como uma ferramenta útil para alcançar os mais altos níveis do CMMI [Raffo, Vandeville e Martin 1999] e como técnica viável para implementação das práticas do nível B do MPS.Br [Softex 2006]. Isto ocorre devido sua abordagem quantitativa que facilita a análise e controle do desempenho dos processos de desenvolvimento das organizações, áreas chave dos níveis 4 e 5 (CMMI) e B e A (MPS.Br). Já para níveis iniciais (CMMI nível 2 e MPS.Br nível E), a modelagem da simulação de processo de software ajuda no planejamento e definição dos seus processos, além das mudanças ocorridas durante a definição. Os ambientes e modelos de simulação propostos atualmente possuem muitas simplificações, gerando resultados que não condizem com a realidade das organizações de software hoje em dia. Além disso, poucas abordagens para simulação de processos de software são independentes do processo utilizado. As limitações inseridas fazem com que muitos modelos de simulação estejam voltados para um processo de software adotado por uma organização em específico, a fim de representar com mais fidelidade a execução do processo adotado na realidade. Dentre as propostas que possuem características mais abrangentes e, ainda assim, conseguem uma boa representação do modelo real, as abordagens híbridas apresentadas em [Martin and Raffo 2000] e em [Lakey 2003] são as que, atualmente, obtêm melhores resultados. Entretanto, exigem um grande esforço para definir o modelo de simulação para os processos de software reais. Mesmo as propostas de modelos generalizados de simulação de processo de software [Raffo, Nayak e Wakeland 2005], onde são utilizados componentes reutilizáveis de modelos de processo para facilitar a modelagem, a incorporação de funções de distribuição de probabilidade para gerar os valores das variáveis aleatórias, que representam o comportamento da execução do processo, é realizada de maneira não integrada, ou seja, supõe-se que esta análise já tenha sido realizada. O avanço deste trabalho está associado ao fato com a possibilidade de previsão do comportamento das três grandes variáveis do processo de desenvolvimento de software: custo, tempo e qualidade do produto gerado, além de variáveis auxiliares que ajudam na determinação dos valores das variáveis anteriores. Esta previsão é realizada em curto tempo através de um Simulador de Processo de software. Este reúne abordagens apresentadas na literatura, conforme os trabalhos relacionados e o estado da arte apresentados na seção 3, em uma abordagem baseada em conhecimento para a solução dos problemas de calibragem e não determinismo que envolvem os modelos de simulação atuais, além da independência do modelo de processo a ser simulado. Além disso, no modelo proposto, os dados históricos de 248

270 execuções anteriores obtidos a partir de um repositório estruturado de um PSEE fornecem subsídio para simulação utilizando o Método de Monte Carlo (MMC) [Goldsman 2007]. O restante do texto está organizado da seguinte forma: a seção 4 apresenta o modelo proposto e discute algumas decisões tomadas na solução, a seção 5 apresenta um exemplo contextualizado de como o modelo proposto funciona, a seção 6 apresenta as considerações finais e as direções futuras deste modelo de simulação. 2. Contextualização Este trabalho busca contribuir com avanços no escopo da área denominada Tecnologia de Processo de Software [Derniame 1992], cujo foco está na automação de processos de software do ponto de vista da gerência, execução e engenharia de processos. A proposta desse modelo de simulação é baseada principalmente em três conceitos: 1) Simulação de Monte Carlo, 2) Estimativa por Analogia - Raciocínio Baseado em Casos (RBC) e, 3) Histórico de Execução de Processos de Software. O Método de Monte Carlo consiste na formulação de um processo estocástico, o qual produz uma variável aleatória cujo valor esperado é a solução de um problema. Uma aproximação do valor esperado é então obtida a partir de uma amostra da distribuição de probabilidade resultante. A solução é considerada uma aproximação pelo fato de que sua base (dados que originam as distribuições) seja uma fonte de erro nas distribuições, pois o número de elementos na amostra é finito. Assim, a acurácia do método é diretamente proporcional ao tamanho da amostra de entrada [Bauer 1958]. A Simulação de Monte Carlo (SMC) modela um problema como um sistema, o qual é descrito como um conjunto de variáveis aleatórias regidas por alguma distribuição de probabilidade, de onde são gerados valores (pseudo) aleatórios para representar o comportamento de um sistema real. Estes valores gerados fazem parte da solução do problema a ser resolvido, seja esse valor parcial ou final. Cada número aleatório gerado é uma fonte de incerteza. Esta incerteza é acumulada até o final da execução do método (simulação) e pode ser tratada, desde que se conheça sua grandeza. A técnica de Estimativa Baseada em Analogia [McConnel 2006], muito utilizada para estimar esforço e prazo de projetos de software, parte do princípio de criar uma estimativa com um bom grau de acurácia para um novo projeto através da comparação com projetos anteriores similares. Este problema possui todas as características de um problema a ser resolvido utilizando a técnica de RBC. Delany et al [Delany, Cunningham e Wilke 1998] descrevem, em um estudo abrangente, as principais limitações para a técnica de RBC em resolver o problema de estimativa de esforço no desenvolvimento de software. Dentre elas se destaca a falta de atributos concretos para se comparar projetos de software em sua fase inicial (planejamento). Em um trabalho posterior, Delany e Cunningham (2000) apresentam uma proposta de um modelo RBC para estimativas de esforço com uma série de direcionadores de custo para caracterizar um projeto de software desde sua concepção. Os experimentos realizados por [Shepperd, Schofield e Kitchenham 1996] e [Shepperd e Schofield 1997] com a ferramenta ANGEL utilizaram nove bases de dados 249

271 diferentes de projetos de software. Para validar a abordagem baseada em analogia, foi utilizada a abordagem Jack Knifing, onde se retira uma unidade (um projeto neste caso) da base de dados e tenta-se realizar a estimativa para esta unidade com base nas unidades restantes. Então, o resultado da estimativa é confrontado com os resultados alcançados desta unidade (neste caso esforço real necessário). A coleta de métricas durante a execução do processo é um requisito muito citado para PSEEs (Process-centered Software Engineering Environments) [Bandinelli et al 1994] e para desenvolvimento de software em geral. Entretanto, este requisito nem sempre tem sido tratado com eficiência, ou seja, utilizando as métricas de forma adequada, o que tem causado uma falta de interesse em manter os esforços de coletar métricas. Este conhecimento (histórico dos processos) pode ser utilizado para ajudar na tomada de decisões para alocar pessoas e recursos no processo, além disso, utilizado para simulação de processo [Scacchi 1999]. Para a simulação de processo de software é importante dar um enfoque maior na meta-atividade de execução de processos, pois se trata do comportamento que a simulação se propõe a imitar. Muitos dos problemas que surgem no decorrer da execução de um processo de software podem ser detectados durante a simulação. Por exemplo, a utilização excessiva de recursos da organização, atividades realizadas seqüencialmente quando poderiam ser paralelizadas, entre outros. A simulação de processos deve, assim como a execução, considerar aspectos organizacionais, tais como: pessoas envolvidas, recursos utilizados, habilidades dos agentes, afinidade entre os agentes ao realizarem tarefas em grupo, políticas da organização, entre outros. 3. Trabalhos Relacionados Várias abordagens vêm sendo experimentadas pela literatura, com diferentes propósitos, desde o auxílio no diagnóstico a priori [Mi e Scacchi 1990], passando pela análise e desempenho de processos [Martin e Raffo 2001] até no desenvolvimento de jogos interativos que auxiliam no treinamento de gerentes novatos ou estudantes [Drappa e Ludewig 2000] [Dantas, Barros e Werner 2004]. Entretanto, apenas três modelos de simulação são comentados devido restrições de espaço. 3.1 Articulator Dentro da categoria de simuladores integrados à PSEEs, um dos trabalhos pioneiros é definido por Mi e Scacchi (1990). O Articulator é um ambiente com apoio à modelagem e simulação de processos que utiliza uma abordagem baseada em conhecimento. O modelo do Articulator é baseado em uma rede de recursos (materiais e pessoal) que estabelecem restrições de dependência entre as tarefas. Cada tarefa é realizada por um conjunto de agentes inteligentes, cujo comportamento é baseado em estratégias pré-definidas para lidar alocação de recursos e decisões relacionadas a sua capacidade de lidar com um número elevado ou baixo de carga de trabalho. A cada ciclo da simulação, também chamado de estado, uma série de ações são executadas pelos agentes inteligentes. Estas ações exigem que recursos estejam 250

272 disponíveis para serem realizadas e um conjunto de ações configuram um estado. Existe um mecanismo de resolução de conflitos para resolver conflitos na utilização dos recursos. Neste simulador também existe o mecanismo de busca que realiza consultas otimizadas no repositório de processos modelados para recuperar informações durante a simulação e um mecanismo para aquisição de conhecimento que recupera informações sobre uma base estruturada de conhecimento adquirido com o passar das simulações. 3.2 Illium A ferramenta de simulação Illium [Barros, Werner e Travassos 2000b] permite a construção e avaliação de modelos dinâmicos de projetos de software. O modelo é representado textualmente e o formalismo usado na sua definição segue a técnica de dinâmica de sistemas. Além disso, utiliza também o paradigma de gerência de projetos de software baseada em cenários [Barros, Werner e Travassos 2000a], estendendo o modelo de dinâmica de sistemas originalmente proposto por Abdel-Hamid e Madnick (1991) para acomodar a utilização deste paradigma. Três formas de conduzir a simulação são adotadas pela ferramenta Illium: 1) a simulação baseada em tempo, onde a cada ciclo da simulação ocorre um registro das dos valores correntes das variáveis do processo; 2) a simulação estocástica utilizando o Método de Monte Carlo e 3) a variação de parâmetros da simulação, que analisa o impacto no comportamento da execução do processo a partir de modificações realizadas sobre os valores dos parâmetros da simulação. 3.3 Simulação Híbrida O modelo apresentado em [Martin e Raffo 2000] e [Martin e Raffo 2001] é descrito de forma híbrida, isto é, composto por partes contínuas (dinâmica de sistemas) e partes discretas (evento-dicreta). O processo de software é modelado de forma discreta como conjunto de atividades conectadas em seqüência e o ambiente do projeto e suas variáveis transversais são modelados de maneira contínua de acordo com o modelo proposto por [Abdel-Hamid e Madnick 1991]. As atividades do processo são modeladas de acordo com três tipos genéricos: desenvolvimento, inspeção e re-trabalho. As atividades de desenvolvimento são as que produzem ou modificam atributos artefatos, tais como número de erros inseridos, tamanho, entre outros. As atividades de inspeção servem para detectar erros e as de retrabalho para corrigir os erros injetados em atividades passadas, ou ainda, injetar novos erros por conta de correções mal sucedidas. O esforço de cada atividade é calculado através de uma distribuição de porcentagens entre as fases do processo de um total que, por sua vez, é calculado através do modelo COCOMO [Boehm 1981]. Quanto às durações das atividades, é utilizado um fator de produtividade associado a cada pessoa envolvida no processo e o número de pessoas alocadas à atividade. Questões de qualidade são representadas por taxas contínuas, para mais detalhes sobre as equações, consultar [Martin e Raffo 2000]. Este modelo abrange ainda questões de paralelismo de atividades, porém com poucas alternativas para modelagem da dependência temporal entre as atividades se comparado ao modelo de conexões disponível atualmente em ambientes de 251

273 desenvolvimento de software centrados no processo (tal como apresentado em [Lima Reis 2003]). A produção de artefatos nas atividades é representada por filas que traçam o progresso dos itens individualmente. Por sua vez, os recursos são apresentados de forma bastante simplificada, enfatizando apenas o seu papel na habilitação ou não a execução de atividades, em função da sua disponibilidade. Quanto aos aspectos do ambiente do projeto, as três principais variáveis (em mais alto nível) modeladas são: o nível de pessoal em termos de disponibilidade e utilização, com isso, é possível identificar casos de super e sub-alocação de pessoal; a taxa de produtividade, utilizada no cálculo de duração das atividades; e as taxas de erros, para geração, detecção e correção de artefatos. 3.4 Diferencial da proposta Os principais diferenciais do simulador aqui apresentado em relação aos outros trabalhos da literatura são: a extração do modelo preditivo para realizar simulações (estocásticas) e a integração a um Ambiente de Desenvolvimento de Software Centrado em Processo. A extração a partir da análise de histórico de execuções passadas incorpora as incertezas inerentes ao processo de desenvolvimento de software por meio das funções distribuição de probabilidade e utilização da Simulação de Monte Carlo. A integração com o ambiente WebAPSEE [Lima et al. 2006] faz com que todos os dados necessários (incluindo métricas) a respeito dos modelos de processo, projetos e da organização estejam disponíveis para utilização no modelo de simulação. 4. O Modelo Proposto As sub-seções seguintes apresentam: 1) a correspondência do modelo de simulação aqui apresentado com os modelos de maturidade de desenvolvimento de software, 2) uma visão geral do modelo e, 3) a forma como este utiliza o conhecimento armazenado no repositório de histórico de execuções de processo. 4.1 Evolução Recente O modelo deste trabalho é uma evolução do modelo apresentado em [França 2007], entretanto, com algumas diferenças. O modelo COCOMO II [Bohem et al 2000] não é mais utilizado para cálculo de estimativas de esforço e duração das atividades. Ao invés deste modelo analítico, o modelo desta versão é estocástico no que diz respeito à determinação da duração de atividades e determinação de valores como produtividade, taxa de erros inseridos, entre outros. Esta característica é desejável considerando a dinâmica e variabilidade do processo de software Correspondência com Modelos de Maturidade Os modelos de maturidade em desenvolvimento de software como CMMI, ISO e MPS.Br possuem, em geral, áreas-chave destinadas à definição dos processos organizacionais, implementação de planos de medição, bem como áreas destinadas à 252

274 gerência quantitativa de seus projetos e, em maior grau de maturidade, a melhoria contínua dos processos padrões da organização [Raffo, Vandeville e Martin 1999]. Para definição do processo padrão para organização é necessário o conhecimento quanto aos recursos disponíveis na empresa, sejam estes materiais ou pessoais, artefatos de software produzidos e consumidos durante a execução do processo e ferramentas a serem utilizadas a fim de produzir estes artefatos. A alocação destes componentes do processo configuram um problema de tomada de decisão que pode ser resolvido com auxílio de simulação. Além disso, problemas de paralelismo entre atividades para otimização de recursos e tempo são facilmente visualizados com a utilização de abordagens discretas de simulação [Martin e Raffo 2000]. Nos níveis mais altos do CMMI e MPS.Br, por exemplo, existe a necessidade de gerenciar de forma quantitativa os projetos executados, permitindo uma avaliação contínua do desempenho dos processos da organização [Softex 2006]. Isto é, a gerência de projetos está integrada com o processo de medição a fim de utilizar as métricas coletadas durante a execução. Com isso, é possível estabelecer limites de controle para o processo e medidas para monitorar o desempenho do mesmo, permitindo que ações preventivas e corretivas possam ser tomadas de maneira pró-ativa, ou seja, antes que grandes problemas ocorram de fato. Com a coleta de métricas alinhada aos objetivos de monitoração do processo, é possível obter dados para utilizar em modelos de simulação (como o proposto nesse trabalho) a fim de melhorar a tomada de decisão na organização, prever impacto de modificações no processo e justificar iniciativas de melhoria de processo [Raffo 1999] Visão Geral do Modelo Segundo a classificação apresentada por Goldsman (2007), a abordagem de simulação utilizada é classificada como dinâmica - pela natureza dinâmica do sistema modelado (processo de software), estocástica - pela utilização do MMC e não ser determinística, e contínua - devido ao tempo avançar em pequenos intervalos de tempo constantes. A abordagem aqui proposta para simulação é realizada, unindo os três conceitos apresentados na seção 2, em três momentos: 1. No início da simulação é utilizada a técnica de analogia para determinar atividades passadas semelhantes para cada atividade do processo a ser simulada [França 2007]. Esta etapa é um setup da simulação, onde o modelo preditivo será extraído da base histórica (seção 4.4) para simular o processo dado como entrada (processo instanciado que se deseja simular); 2. A partir das atividades semelhantes recuperadas, é montada uma Função Distribuição de Probabilidade (FDP) para representar o comportamento de cada variável (duração, número de erros detectados, entre outras) para cada uma das atividades passadas. Estas variáveis determinam a dinâmica da execução do processo; 3. Ao final, é executada a simulação utilizando o MMC com base nas FDP originadas. Esta execução faz uso do Mecanismo de Execução do ambiente WebAPSEE [Lima Reis 2003], onde os eventos de execução 253

275 (início/termino de uma atividade) são disparados de acordo com os valores gerados pelas FDPs que representam a duração de cada atividade. A estrutura da base histórica (repositório de processos executados) utilizada nesse modelo é a da base de processos executados no ambiente WebAPSEE. A simulação de Monte Carlo funciona, nesse modelo, da seguinte forma: o modelo do sistema (processo) utilizado é o próprio modelo de processo, definido no ambiente WebAPSEE. Cada atividade é um processo (termo da simulação orientada processo), que requer um tempo para ser executado, como um caixa de atendimento em um serviço bancário. Os recursos requeridos e utilizados podem ser materiais e humanos e possuem um custo por unidade associado. Os artefatos produzidos e consumidos em cada atividade possuem atributos como tamanho e complexidade, por exemplo. O modelo possui diversas variáveis aleatórias para representar os valores da execução do processo, tais como: duração de atividades, produtividades dos agentes na realização de tarefas e disponibilidade de recursos. Estas variáveis aleatórias têm seu valor determinado de acordo com a distribuição de probabilidade que rege seu comportamento. Por exemplo, uma atividade de revisão de um documento de arquitetura tem a duração estimada (em dias) de acordo com uma distribuição normal com média 5 e desvio 1,3. As distribuições são determinadas de acordo com o histórico de execução de atividades similares à atividade em questão (ver seção 4.3). A cada ciclo (intervalos pequenos e constantes) do relógio da simulação, as variáveis são atualizadas com os valores gerados pelas distribuições. Com a simulação iniciada, é possível realizar diversas execuções/observações consecutivas e analisar um padrão ou tendências no comportamento da execução e no desempenho do processo. Essa tendência pode ser observada em alta granularidade, por exemplo, o aumento do custo do projeto em uma fase do projeto, ou em menor granularidade, por exemplo, na observação de uma atividade importante que represente um gargalo no processo em termos de duração, causando atrasos no projeto. Convém observar que este trabalho é um instrumento para apresentar estes indicadores, enquanto que o processo de resolução está fora do escopo da solução vislumbrada Utilização do Conhecimento Organizacional Esta seção apresenta de que forma o mecanismo RBC realiza o tratamento das informações contidas no histórico de processos para gerar o modelo estocástico de simulação, ou seja, a base para a Simulação de Monte Carlo. O esquema do funcionamento integrado do mecanismo RBC com a análise dos casos similares para gerar as distribuições de probabilidade é apresentado na Figura

276 Figura 1 Funcionamento integrado RBC e Análise de Dados. Para cada atividade de um processo, uma coleção de atividades similares anteriores é gerada a partir da base histórica (repositório WebAPSEE). Estas atividades são, então, filtradas pelo modelo RBC através de um filtro acumulador de valores, que para cada atributo da atividade relevante para o comportamento da simulação (duração, custo, qualidade dos produtos, entre outros) gera uma série dados (valores) acumulados. A partir destas séries são geradas as Funções Distribuição de Probabilidade para cada atributo das atividades do processo. Estas distribuições são responsáveis pela geração de números aleatórios atribuídos às variáveis do modelo de simulação, determinando a dinâmica para execução de cada atividade durante a simulação. Outras variáveis podem ter seu comportamento dado de acordo com uma distribuição baseada em dados históricos, tais como: produtividade, aprendizado durante o processo, grau de habilidade e afinidade dos desenvolvedores, taxa de disponibilidade de recursos, tempo médio entre falha/defeito de recursos materiais, entre outras. Isso diferencia este modelo dos modelos baseados em Dinâmica de Sistemas, onde as taxas que representam essas variáveis são fixas, dadas por rígidas equações diferenciais. A idéia de utilizar RBC na inicialização da Simulação de Monte Carlo parte do princípio de que esta última técnica é utilizada há muitos anos com sucesso em contextos industriais que possuem produção e serviço em larga escala, por exemplo, manufatura, linhas de montagem e logística [Goldsman 2007]. Nestes casos, os processos são bem definidos e as atividades dos processos são sempre similares, chegando a serem repetitivas (dependendo do caso). Assim, a técnica RBC na base histórica funciona como um filtro que resulta somente atividades similares como em um regime de Linha de Produção de Software [Clements 2005], ou seja, somente atividades que possuem um histórico e que já foram executadas anteriormente, seja em um contexto igual ou relativamente similar. Apesar da similaridade estar presente no modelo, isto não significa que todos os processos na base histórica devam ser originados obrigatoriamente de um processo padrão. Esta similaridade é medida em nível de atividade (considerando o contexto do projeto), e não em nível de processo. O princípio é que pode haver atividades similares inclusive em processos diferentes. Um sistema RBC é constituído de 4 partes: 1) Representação dos Casos, 2) Função de Similaridade, 3) Método de Recuperação e 4) Método de Adaptação. Para este trabalho foi utilizada a representação de casos de maneira orientada a objetos (assim como em [França 2007]), visto que o sistema e seu modelo de dados já apresentam as informações estruturadas neste paradigma. Entretanto, o modelo proposto 255

277 possui informações de contexto do projeto (identificação, descrição e duração). Quanto à função de similaridade, é apresentada de maneira similar à versão anterior: um somatório ponderado do grau de similaridade entre os atributos/relacionamentos multiplicados pelos pesos. O método de recuperação continua o mesmo, a recuperação em dois níveis [Von Wangenheim 2003] [França 2007]. A grande inovação do modelo RBC é que este é utilizado como um préprocessamento para a simulação, ou seja, atua na extração do modelo preditivo e não mais como fator determinante da duração de atividades durante a simulação. O método de Adaptação, onde concentra grande parte das modificações do modelo proposto, é chamado de Composicional. Na adaptação composicional, o problema atual (atividade a ser simulada) terá sua solução baseada na solução utilizada pelos casos mais similares contidos na base de casos. Segundo Von Wangenheim (2003), neste método os novos componentes de solução adaptados de vários casos anteriores são combinados para produzir uma nova solução composta. Esta combinação não, necessariamente, precisa ser estrutural 1, mas para compor novos valores aos atributos conhecidos com base em valores de vários casos anteriores. A adaptação composicional da solução proposta ocorre da seguinte forma. Sendo a solução composta pelo custo e tempo necessários para executar a atividade. O custo é a soma dos custos dos recursos requeridos (consumíveis) adicionada do custo por hora de cada um dos agentes envolvidos (multiplicado pela quantidade de horas - tempo). O tempo é determinado a partir do conjunto de durações das n atividades mais similares recuperadas da base de casos. Por exemplo, na Tabela 1 é apresentada (primeira coluna) uma série de atividades semelhantes a uma qualquer Atividade A e as respectivas durações de cada uma quando foi executada (primeira coluna). É este conjunto de dados (de durações da segunda coluna) que serve de base para adaptar um conjunto de casos anteriores para uma solução de um caso novo. Tabela 1. Atividades similares e suas respectivas durações. Atividade Similar Duração Atividade B 7 Atividade C 5 Atividade D 8 Atividade E 5 Atividade F 6 A solução parte da idéia de que problemas similares possuem soluções similares, ou seja, o tempo necessário para executar a nova atividade será similar ao tempo referente às atividades similares. 1 Em termos de estrutura de dados. 256

278 5. Exemplo de Funcionamento do Modelo Nesta seção um exemplo simples (focado em apenas uma atividade) é apresentado para ilustrar o funcionamento de como são extraídas as informações do modelo de maneira geral. Parte de um modelo de processo é apresentada na Figura 2 na notação do WebAPSEE. Esta visualização é a mesma utilizada quando da modelagem e execução da simulação, entretanto, é possível acrescentar parâmetros na inicialização (restrições de custo, duração e qualidade) e gerar relatórios das saídas da simulação. O modelo da figura 2 representa parte de um processo-exemplo de elicitação e análise de requisitos. A atividade-problema foco para este é exemplo é Especificação de Requisitos, cujo estado está Ready, ou seja, pronta para executar. Para esta atividade (e seus atributos) são recuperados da base de casos (repositório de processo do WebAPSEE) os quinze (15) casos mais similares, considerando um limiar de similaridade, que pode ser determinado ou como entrada do usuário - especificando o nível de acurácia dos resultados ou por um limite médio dos valores de similaridades calculados entre esta atividade e suas similares, por exemplo. Dadas as quinze atividades similares (conjunto de atividades-caso) com seus respectivos graus de semelhança aferido, por exemplo, acima de 65% de semelhança, a duração estimada da atividade-problema será gerada randomicamente a partir de uma FDP extraída das quinze atividades-caso similares, com o grau de acurácia em torno de 65%. Figura 2. Modelo de Processo Exemplo. Convém ressaltar que o limiar de similaridade (neste exemplo, 65%) é função do grau de acurácia geral desejado para a simulação (definido pelo usuário). A similaridade entre cada atividade é dada por uma soma ponderada da similaridade local entre os atributos destas atividade. Esta similaridade local é determinada pela comparação entre os atributos, na qual o método varia dependendo do tipo do atributo (texto, número, hierarquia de objetos, entre outros). Durante a determinação da distribuição de probabilidade da duração (em dias), por exemplo, não é correto que uma atividade mais similar (90%) tenha mesma 257

279 probabilidade de ocorrência na distribuição que uma atividade menos similar (75%), ou seja, dizer que a duração da atividade-caso pode ser aproximadamente igual à duração da atividade menos similar com mesma probabilidade da mais similar. O que ocorre é que quanto mais se executa uma atividade com os mesmos recursos, produzindo os mesmos artefatos (com tamanhos equivalentes) e realizadas por pessoas de mesmo papel/cargo a tendência é que os valores das durações se aproximem. Assim, é preciso estabelecer pesos maiores para as atividades mais similares e a forma de fazer isso é inserir estes pesos na distribuição através do aumento da probabilidade de ocorrência. A série de dados utilizada para gerar distribuições é não-ordenada e com possibilidade de dados replicados. Para considerar que, por exemplo, o caso mais similar tenha maior probabilidade, o seu valor é replicado na série em X vezes, onde X é um fator determinado em função dos graus de similaridade relativos. Uma vez gerada a distribuição, é possível gerar os valores aleatoriamente para as variáveis da simulação. Neste exemplo, é apresentada a duração em dias para a atividade de especificação de requisitos (figura 3). Segundo a distribuição apresentada na figura 3, a probabilidade de ocorrência de valores no intervalo fechado de 10 a 14 é maior que os outros valores. Para esta distribuição, o valor da media é de 10.7, com desvio de 2.97 e extremos 5 e 15. Por exemplo, ao gerar vinte números aleatoriamente a amostra resultante é mostrada no Quadro 1 a seguir, comprovando a maioria (treze em vinte) de ocorrência de valores entre 10 e Quadro 1. Amostra aleatória gerada a partir da distribuição. A análise a ser feita é que se, em execuções passadas, a duração das atividades mais similares ocorreu em sua maioria em um dado intervalo (como no exemplo: entre 10 e 14), é mais provável que em uma nova execução a duração esteja neste intervalo. Entretanto, nada impede que a nova duração esteja fora deste intervalo, por isso a característica estocástica da Simulação de Monte Carlo é desejada. Assim, com a abordagem estocástica é possível representar as incertezas inerentes à natureza dessas variáveis através dos geradores de números aleatórios. 258

280 Figura 3. Distribuição de Duração para a Atividade de Especificação de Requisitos. 6. Considerações Finais e Trabalhos Futuros A utilização da abordagem baseada em conhecimento na definição do simulador integrado ao ambiente WebAPSEE possui pontos fortes no que diz respeito á calibragem do modelo com os dados da organização. Essa integração dispensa métodos que consomem muito tempo para calibrar um modelo preditivo com os dados organizacionais, pois o modelo é extraído diretamente destes dados. Como o modelo de simulação é gerado a partir de bases históricas detalhadas, isto é, com uma granularidade refinada do processo, as simplificações comumente encontradas nos modelos de simulação atuais não se fazem necessárias. Isto agrega possibilidade de incorporar mais informações ao modelo, tornando-o cada vez mais próximo da realidade no que diz respeito a sua acurácia. Entretanto, trabalhos adicionais precisam ser realizados para comprovar este benefício, como comentado a seguir. As abordagens mais recentes apresentam resultados advindos de modelos híbridos de simulação [Martin e Raffo 2000]. Mostrando que para atingir um bom grau de completude na representação de processos reais é necessária a utilização de diferentes abordagens integradas, pois um processo é composta de variáveis discretas e contínuas. Pos isso, as distribuições geradas para Simulação de Monte Carlo podem ser tanto discretas quanto contínuas. Por exemplo, enquanto uma variável como tempo pode ser definida por uma distribuição contínua como uma Normal (Ou Gaussiana), uma variável discreta que represente o numero de defeitos encontrados em uma atividade de revisão como uma distribuição uniforme. A definição e implementação deste modelo é recente e não foi possível a realização de testes reais para uma validação da proposta. Como trabalho futuro, pretende-se planejar simulações para auxiliar na melhoria, estudos comparativos e análise de processos reais. Além da implementação recente, a indisponibilidade de uma base histórica real de projetos executados inviabilizou a validação deste modelo diante 259

281 das expectativas quanto à sua acurácia. Entretanto, a técnica a ser adotada para a validação é a técnica Jack Knifing [Shepperd e Schofield 1997], retirando um projeto da base de projetos e simulando-o com os dados históricos dos projetos restantes. Após a simulação, compara-se os resultados da simulação com os resultados reais do projeto. Referências Abdel-Hamid, T.; e Madnick, S. (1991) Software Project Dynamics: An Integrated Approach, Facsimile Edition, Prentice-Hall. Bandinelli, S.; Di Nitto, E.; Fugetta, A.; Lavazza, L. (1994) Coupled vs Decoupled User Interaction Environments in PSEEs. In 9 th International Software Process Workshop, Reston. Barros, M.O.; Werner, C. M. L.; Travassos, G.H. (2000a) Applying System Dynamics to Scenario Based Software Risk Management, In International System Dynamics Conference, Bergen, Norway. Barros, M.O.; Werner, C. M. L.; Travassos, G.H. (2000b) Illium: Uma ferramenta de Simulação de Modelos Dinâmicos de Projetos de Software, In XIV Simpósio Brasileiro de Engenharia de Software, Caderno de Ferramentas, p , João Pessoa, PB, Brasil. Bauer, W. F. (1958) The Monte Carlo Method. In: Journal of the Society for Industrial and Applied Mathematics, volume 6, number 4, pages , December. Boehm, B. (1981) Software Engineering Economics. Prentice Hall, 1st edition. Boehm, B.; Abts, C.; Brown, A. W.; Chulani, S.; Clark, B. K.; Horowitz, E.; Madachy, R.; Reifer, D.; Steece, B. (2000) Software cost estimation with Cocomo II. Prentice Hall, 1st edition. Clements, P. C. (2005) Project management in a software product line organization. In: Software, IEEE. volume 22, issue 5, pages CMU/SEI. (2006) CMMI for Development, Version 1.2. Carnegie Mellon University, Software Engineering Institute, Pittsburgh. Disponível em: Dantas, A. R.; Barros, M. O.; Werner, C. M. L. (2004) A Simulation-Based Game for Project Management Experiential Learning. In International Conference On Software Engineering and Knowledge Engineering, Banff, Canada. Delany, S. J.; Cunningham, P.; e Wilke, W. (1998) The Limits of CBR in Software Project Estimation. In 6 th German Workshop on Case-Based Reasoning, Berlin, Germany. Delany, S. J.; Cunningham, P. (2000) The Application of Case-Based Reasoning to Early Software Project Cost Estimation and Risk Assessment. University of Dublin, Trinity College, Department of Computer Science. Technical Report Disponível em: Acesso em: jan

282 Derniame, J. C. (1992) Software Process Technology. In Second European Workshop, EWSPT '92, Trondheim, Norway. Springer-Verlag, September. Drappa, A.; Ludewig, J. (2000) Simulation in Software Engineering Training. In 22nd International Conference On Software Engineering, ICSE '00. Limerick, Ireland: IEEE Computer Society. p França, B. B. N. de. (2007) Proposta de um Modelo de Simulação de Processo de Software para o Ambiente WebAPSEE. Trabalho de Conclusão de Curso (Bacharelado em Ciência da Computação) Faculdade de Computação, UFPA, Belém. Disponível em: Fuggetta, A. (2000) Software Process: A Roadmap. In 22th International Conference On Sosftware Engineering, Ireland. Ireland, ACM Press. Goldsman, D. (2007) Introduction to Simulation. In Winter Simulation Conference (WSC 07). Washington DC, USA. ISO/IEC. (2004) ISO/IEC : Information Technology Process Assessment, - Part 3: Guidance on performing an assessment. Geneve. Jacobson, I.; Booch, G.; Rumbaugh, J. (1999) The Unified Software Development Process. Massachusetts: Addison Wesley Longman, Inc. Kellner, M. I.; Madachy, R. J; Raffo, D. M. (1999) Software Process Simulation Modeling: Why? What? How? In The Journal of Systems and Software, number 46, pages Lakey, P. B. (2003) A Hybrid Software Process Simulation Model for Project Management. In Process Simulation Modeling Workshop (ProSim 03). Portland, Oregon, USA. Lima, A. M.; França, B. B. N. de; Costa, A.; Sales, E. O.; Lima Reis, C. A.; Reis, R. Q. (2006) Gerência Flexível de Processos de Software com o Ambiente WebAPSEE. In 19º Simpósio Brasileiro de Engenharia de Software, Florianópolis. Sessão de Ferramentas. Lima Reis, C. A. (2003) Uma Abordagem Flexível para Execução de Processos de Software Evolutivos. Tese de Doutorado PPGC, Universidade Federal do Rio Grande do Sul, Porto Alegre. Little, T. (2006) Schedule Estimation and Uncertainty Surrounding the Cone of Uncertainty. In IEEE Software. May-June. Volume 23, Issue 3. pages Martin, R. H. and Raffo, D. (2000) A Model of the Software Development Process Using Both Continuous and Discrete Models. In Software Process: Improvement and Practice, volume 5, number 2-3, pages John Wiley & Sons, Ltd. Martin, R. H. and Raffo, D. (2001) Application of a hybrid process simulation model to a software development project. In The Journal of Systems and Software, volume 59, pages McConnel, S. (2006) Software Estimation: Demystifying the Black Art (Best Practices). Microsoft Press. 261

283 Mi, P.; Scacchi, W. (1990) A Knowledge-Based Environment for Modeling and Simulating Software Engineering Process. In Knowledge and Data Engineering, IEEE Transactions, volume 2, pages Raffo, D.; Nayak, U.; Wakeland, W. (2005) Implementing Generalized Process Simulation Models. In 6 th Process Simulation Modeling Workshop (ProSim 05). St. Louis, Missouri, USA. Raffo, D. (1999) Getting the Benefits from Software Process Simulation. In International Conference on Software Engineering and Knowledge Engineering (SEKE 99), Kaiserslautern, Germany, June. Raffo, D. M.; Vandeville, J. V.; Martin, R. H. (1999) Software Process Simulation to achieve higher CMM levels. In The Journal of Systems and Software, number 46, pages Scacchi, W. (1999) Experience with software process simulation and modeling. In Journal of Systems and Software, number 46, pages Shepperd, M.; Schofield, C. e Kitchenham, B. (1996) Effort Estimation Using Analogy. In 18th International Conference on Software Engineering (ICSE '96), Berlin, Germany. pages Shepperd, M.; Schofield, C. (1997) Estimating Software Project Effort Using Analogies. In IEEE Transactions on Software Engineering, volume 23, number 12, pages Softex. (2006) MPS.BR Melhoria de Processo do Software Brasileiro, Guia Implementação, v.1.0, Softex, Brasil. Softex. (2008) MPS.BR Melhoria de Processo do Software Brasileiro. Disponível em: TI Inside. (2007) TCU recomenda exigência de certificado nacional de software em licitações. Secretaria de Comunicação Social - Presidência da República, Outubro. Disponível em: noticias/assunto10/nt14ago2c/. Acesso em: dez Von Wangenheim, C. G.; Von Wangenheim, A. (2003) Raciocínio Baseado em Casos. Editora Manole Ltda. 262

284 Uma Abordagem para Condução de Iniciativas de Melhoria de Processos de Software Mariano Angel Montoni, Cristina Cerdeiral, David Zanetti, Ana Regina Cavalcanti da Rocha COPPE/UFRJ Universidade Federal do Rio de Janeiro Caixa Postal CEP Rio de Janeiro RJ Brasil {mmontoni, cerdeiral, zanetti, Abstract. The success of software process improvement implementation initiatives depends fundamentally on the strategies adopted to support such initiatives. Therefore, it is essential to define adequate implementation strategies to support the achievement of organization objectives considering its specific characteristics. The objective of this work is to present an approach to support the conduction of software process improvement initiatives based on critical success factors identified by a national research with organizations that conducted software process improvement initiatives. This work also presents the functionalities of a set of tools integrated in a process-centered knowledge management environment customized to support the presented approach. Resumo. O sucesso das iniciativas de melhoria de processo de software depende fundamentalmente das estratégias adotadas para apoiar a condução dessas iniciativas. Portanto, é importante definir estratégias de implementação adequadas que atendam os objetivos de negócio da organização e considerem suas características específicas para aumentar os benefícios alcançados com as melhorias implantadas. O objetivo deste trabalho é apresentar uma abordagem para condução de iniciativas de melhoria de processos de software que leva em consideração fatores críticos de sucesso identificados a partir de uma pesquisa nacional com organizações que conduziram iniciativas de melhoria de processo de software. Este trabalho também apresenta as funcionalidades de um conjunto de ferramentas integradas em um ambiente de gerência de conhecimento centrado em processo customizado para apoiar a abordagem proposta. 1. Introdução Aumentar as vantagens competitivas de organizações desenvolvedoras de software é crucial para garantir a sobrevivência destas no mercado. Para aumentar a capacidade das organizações no desenvolvimento de software, diversas abordagens podem ser adotadas, sendo a implementação de melhoria de processo de software a mais amplamente utilizada. Desenvolvimento de software é uma atividade complexa e processos de software dependem fortemente do comprometimento humano para sua implementação (COLEMAN e O'CONNOR, 2006). Aspectos de comportamento individual e organizacional, geralmente, têm grande influência no sucesso de iniciativas de melhoria (BADDOO e HALL, 2002a; BADDOO e HALL, 2003). Equipes motivadas e satisfeitas 263

285 tendem a implementar melhorias mais eficientemente e os benefícios são prontamente observados. No entanto, quando o contrário ocorre, resistências a mudanças podem se tornar uma barreira crítica na implementação de melhorias nos processos. A implementação de melhorias em processos envolve atividades intensas em conhecimento. Isto significa que os envolvidos nas iniciativas de melhoria devem possuir profundo conhecimento sobre engenharia de software e serem capazes de usar esse conhecimento para orientar a implementação de melhorias nos processos da organização aumentando as chances de alcançar os resultados esperados (NIAZI et al., 2006). Ações de melhoria de processos requerem também, geralmente, uma quantidade significativa de recursos financeiros para serem colocadas em prática. Além disso, certos benefícios obtidos com as melhorias implementadas não são facilmente mensuráveis, diminuindo a visibilidade do retorno do investimento em melhoria dos processos (GOLDENSON e HERBSLEB, 1995). Segundo ZAHARAN (ZAHARAN, 1998), a falta de adequação das abordagens adotadas para apoiar a implementação de melhorias nos processos é uma das razões mais comuns para o fracasso das iniciativas de melhoria. A maioria das abordagens existentes apóiam apenas na identificação de quais atividades devem ser implementadas, e não o como implementar essas atividades (WU et al., 2004; NIAZI et al., 2005). Considerando que organizações de consultoria em melhoria de processos de software têm a implementação de melhoria de processos como seu negócio principal, e que o seu sucesso implica diretamente no sucesso das iniciativas de melhoria de organizações de software que contratam seus serviços, é fundamental fornecer mecanismos adequados para apoiar organizações de consultoria em melhoria de processos na gerência das iniciativas de implementação de melhoria. Este trabalho apresenta uma abordagem para condução de iniciativas de melhoria de processos de software. Para apoiar a abordagem, foram definidas ferramentas integradas em um ambiente de gerência de conhecimento centrado em processo com o propósito de permitir que organizações de consultoria em melhoria de processos de software estabeleçam estratégias adequadas para conduzir iniciativas de melhoria de processos de software, bem como permitir a execução e acompanhamento dessas estratégias, além de gerenciar o conhecimento necessário para conduzir iniciativas de melhoria de processo de software. Para possibilitar o desenvolvimento da abordagem, foi desenvolvida uma metodologia para identificação de fatores críticos de sucesso que influenciam iniciativas de melhoria de processo de software. A metodologia e os resultados de sua aplicação são também descritos neste trabalho. Na próxima seção são discutidas questões sobre gerência de iniciativas de implementação de melhoria de processo de software. A Seção 3 apresenta uma metodologia para apoiar a identificação de fatores críticos de sucesso que influenciam iniciativas de melhoria. A Seção 4 apresenta a abordagem desenvolvida para condução de iniciativas de melhoria de processo de software, bem como as funcionalidades do apoio ferramental à abordagem. A Seção 5 apresenta algumas considerações finais do trabalho e aponta os próximos passos. 264

286 2. Gerência de Iniciativas de Implementação de Melhoria de Processo de Software Um aspecto importante de ser considerado na gerência de iniciativas de implementação de melhoria de processo de software são as questões relevantes que influenciam o sucesso dessas iniciativas. Essas questões geralmente estão entranhadas na organização de tal forma que é difícil reconhecer tanto sua existência quanto sua importância (ZAHARAN, 1998). Por exemplo, a implementação de melhoria de processo de software envolve a introdução de práticas inovadoras na organização que requerem de seus colaboradores conhecimento aprofundado sobre as novas tecnologias. No entanto, é difícil para a organização reconhecer que seus colaboradores nem sempre possuem as competências necessárias para implementar essas tecnologias e melhorias de forma eficaz e eficiente. Essa possível deficiência é um risco para a implementação da melhoria (pessoas podem achar que a tecnologia ou melhoria não é adequada, quando de fato falta o conhecimento para obter dela o máximo de benefícios). As questões que exercem influência sobre as iniciativas de implementação de melhoria de processos de software vêm sendo objeto de estudo nas últimas décadas. O propósito desses estudos é obter um melhor entendimento sobre as questões que influenciam iniciativas de melhoria de processo de software, bem como suas interações, causas, efeitos e formas de tratamento. Essas questões são tratadas comumente por esses estudos como Fatores Críticos de Sucesso (FCS). No entanto, não existe um consenso na área sobre quais são esses fatores nem de que forma eles interagem ou influenciam o sucesso da implementação de melhoria de processo de software. Segundo NIAZI et al. (NIAZI et al., 2005), as organizações de software, geralmente, não tratam suas iniciativas de melhoria de processos como projetos reais. Dessa forma, torna-se difícil aplicar de forma eficaz e eficiente métodos e técnicas estabelecidos na área de gerência de projetos para apoiar a condução das iniciativas de melhoria. Um outro aspecto importante de ser considerado na implementação de melhoria de processo de software é que as atividades relacionadas às iniciativas de melhoria geralmente envolvem transferência de grande quantidade de conhecimento. Portanto, é importante que responsáveis pelas iniciativas de melhoria de processo de software tenham acesso a esse conhecimento para facilitar a definição, execução e acompanhamento de programas de melhoria. BADDOO e HALL (BADDOO e HALL, 2002b) sugerem que o aprimoramento do conhecimento sobre a relação entre os motivadores da melhoria de processo de software para diferentes grupos de engenheiros de software permitirá que gerentes de melhoria implementem iniciativas de melhoria mais eficientemente. EL-EMAM et al. (EL-EMAM et al., 2001) indicam também que diferenças culturais das organizações afetam diretamente o sucesso da melhoria de processo de software. Alguns trabalhos foram desenvolvidos para apoiar a gerência de implementação de melhoria de processos de software. NIAZI et al. (NIAZI et al., 2005) desenvolveram um framework de implementação de melhoria de processo de software chamado de SPI- IF a partir de estudos experimentais sobre os fatores críticos de sucesso (FCS) para melhoria de processo de software. Estes estudos tiveram dois focos principais: descobrir o que é crítico na implementação de melhorias de processo de software e descobrir o como implementar melhorias nas organizações. WILSON et al. (WILSON et al., 2001) desenvolveram um framework para avaliação de sucesso de iniciativas de 265

287 melhoria de processo de software e validaram essa abordagem com entrevistas em grupos em sete organizações do Reino Unido. DYBÅ (DYBA, 2000) desenvolveu um instrumento para medição de fatores críticos de sucesso na melhoria de processo de software baseados em dados coletados a partir de 120 organizações de software. 3. Uma Metodologia para Identificação de Fatores Críticos de Sucesso que Influenciam Iniciativas de Melhoria de Processo de Software Para apoiar a condução de estudos experimentais na área de melhoria de processos de software, foi desenvolvida uma metodologia que combina técnicas qualitativa e quantitativa para coletar e analisar dados relacionados a fatores que têm impacto positivo ou negativo em experiências de iniciativas de melhoria de processo de software de instituições implementadoras de melhoria de processo. Os métodos e técnicas utilizados neste estudo foram largamente aplicados por outros estudos com os mesmos objetivos de pesquisa, mas com foco em outros contextos. A metodologia desenvolvida será apresentada por meio da descrição dos passos realizados na sua aplicação em um estudo específico (MONTONI, 2007; MONTONI e ROCHA, 2007). Inicialmente, foram definidos um contexto e escopo para o estudo. O estudo foi restringido para analisar apenas experiências de um grupo específico de implementadores de melhoria de processo de software que participaram em iniciativas de melhoria baseadas em modelos e padrões de referência (por exemplo, CMMI e MPS.BR). Neste estudo, teve-se uma preocupação de identificar fatores críticos de sucesso sob dois pontos de vista. O primeiro ponto de vista é o de implementadores que participaram como consultores em projetos de implementação de melhoria de processo de software. O segundo ponto de vista é o de membros das organizações envolvidas nos projetos de melhoria. Neste estudo, foi aplicado inicialmente o método Grounded Theory (GT) (STRAUSS e CORBIN, 1998). O primeiro passo para aplicação desse método foi coletar os dados por meio da aplicação de dois tipos de questionários com o objetivo de identificar fatores que influenciam a implementação de melhoria de processo de software. O primeiro tipo de questionário foi enviado para um grupo selecionado de implementadores de melhoria de processo de software que participaram como consultores em organizações nacionais de diversos tipos. O segundo tipo de questionário foi enviado para membros de organizações envolvidos em projetos de implementação de melhoria. Os questionários não continham nenhum item prédeterminado e os participantes o preencheram separadamente. No total, 25 questionários foram retornados contendo descrições gerais sobre fatores que influenciaram as iniciativas de implementação de melhoria de processo de software. Depois de retornados os questionários, foram associados códigos a cada uma das declarações nos questionários representando tipos de achados de fatores críticos de sucesso que influenciaram iniciativas de implementação de melhoria de processo de software. No total, 66 códigos diferentes foram identificados por meio da análise dos questionários. Os dados codificados (achados) foram, então, analisados e categorizados. Essas categorias foram denominadas de propriedade de fator crítico de sucesso. A associação entre os achados e uma propriedade de fator crítico de sucesso foi classificada como um achado representando a presença ou a ausência de um fator crítico de sucesso em um contexto específico da análise. A teoria começa a tomar forma à medida que mais 266

288 relações são identificadas entre os achados e as propriedades de fator crítico de sucesso. Essa teoria foi refinada e mais conhecimento sobre os fatores críticos de sucesso foram integrados até que a coleta e análise de mais dados não agregavam nenhum novo conhecimento à teoria. Como resultado desse processo de refinamento e integração, chegou-se à categoria central denominada Fatores que facilitam e dificultam a condução de iniciativas de melhoria de processos de software. Esse conhecimento sobre fatores críticos de sucesso, suas propriedades e relacionamentos formam o que STRAUSS e CORBIN (STRAUSS e CORBIN, 1998) chamam de framework teórico. As técnicas de análise estatística MDS (STATSOFT, 2004) e PCA (KIM e MUELLER, 1978) foram aplicadas para derivar e agregar os fatores críticos de sucesso principais. O primeiro passo para executar a análise de MDS foi estabelecer um dicionário de conteúdo categorizado de todas as propriedades dos fatores críticos de sucesso. Em seguida, uma matriz de dados foi criada com base em quantas ocorrências das propriedades de fatores críticos de sucesso foram identificadas por cada um dos participantes do estudo. Essa matriz foi utilizada para calcular correlações multivariadas entre as propriedades dos fatores críticos de sucesso. Finalmente, essas correlações foram utilizadas para desenhar as distâncias geométricas entre os fatores críticos de sucesso no Gráfico MDS. A técnica PCA foi aplicada na matriz de dados de propriedades de fatores críticos de sucesso com o objetivo de identificar as propriedades com relacionamento estatisticamente significativo. Por meio da aplicação da técnica de análise PCA, as propriedades receberam um valor de carga final para cada um dos componentes (grupos) de fatores críticos de sucesso extraído. Neste estudo, foi considerado o valor 0,55 como o valor de corte dado o tamanho limitado das fontes de dados analisadas. A confiabilidade de relações entre variáveis e componentes extraídos utilizando a técnica de PCA pode ser realizada por meio do cálculo do coeficiente alpha de Cronbach (CRONBACH, 1951). Esta é uma medida comumente utilizada para avaliar a confiabilidade de escalas de medição subjetivas. O coeficiente alpha de Cronbach pode variar de 0 a 1, onde 1 é a confiabilidade perfeita e 0 é a máxima falta de confiabilidade. Nunnally sugere que para os estágios iniciais de uma pesquisa, um valor de coeficiente alpha de Cronbach próximo de 0,7 é aceitável (NUNNALLY, 1978). Nove componentes de fatores críticos de sucesso foram analisados utilizando o coeficiente alpha de Cronbach. Aproximadamente 85% da variação é explicada por esses nove componentes. Esse é um valor muito bom considerando a natureza exploratória deste estudo. Os fatores extraídos foram utilizados para construir componentes de fatores críticos de sucesso. O fator 1 possui um coeficiente alpha de Cronbach de valor 0,81 demonstrando que esse componente de fatores críticos de sucesso possui uma confiabilidade muito boa. Apesar do fator 2 ter poucas variáveis para calcular o coeficiente alpha de Cronbach, os altos valores de carga de rotação da análise de fator exploratória para esse componente indicam uma alta correlação entre as variáveis do fator 2. O fator 3 possui um coeficiente alpha de Cronbach de valor 0,56. Apesar deste número não ser muito alto, os altos valores de carga de rotação também indicam uma alta correlação entre as variáveis do fator 3. O fator 4 possui um coeficiente alpha de Cronbach de valor 0,81 demonstrando que esse componente de fatores críticos de sucesso tem uma 267

289 confiabilidade muito boa. O fator 5 tem o coeficiente alpha de Cronbach de valor 0,58. Apesar desse número não ser muito alto, é relativamente bom para um fator consistindo de apenas 3 variáveis. Esses cinco componentes de fator crítico de sucesso explicam 65% da variação total o que é um valor muito bom considerando o número reduzido de casos analisados. Os fatores 6 a 9 possuem muito poucas variáveis para calcular o valor do coeficiente alpha de Cronbach e não possuem valores de carga de rotação altos da análise de fator exploratória. Portanto, os fatores 1 a 5 foram considerados os componentes principais de fatores críticos de sucesso. A Figura 1 apresenta o gráfico desses componentes e as respectivas variáveis como resultado da aplicação da técnica MDS das correlações multivariadas calculadas para as propriedades dos fatores críticos de sucesso. Os componentes principais de fatores críticos de sucesso com confiabilidade estatística identificados por meio da aplicação de PCA são também destacados na Figura 1. Dimension 2 Scatterplot 2D Final Configuration, dimension 1 vs. dimension 2 1,6 1,4 1,2 P3 1,0 0,8 0,6 0,4 P2 0,2 P9 0,0 P12-0,2-0,4 P10-0,6 P6-0,8 P16-1,0-1,2 P15 P22 P24 P17 P5 P14 P4 P8 P7 P23 P20 P25 P1 P13 Fator 2 Fator 3 Fator 5 P21 P18 P11-1,4-1,6-1,4-1,2-1,0-0,8-0,6-0,4-0,2 0,0 0,2 0,4 0,6 0,8 1,0 Dimension 1 P19 Fator 1 Fator 4 Figura 1. Gráfico dos componentes principais de fatores críticos de sucesso. A composição dos componentes principais de fatores críticos de sucesso é descrita a seguir. O Fator 1 foi chamado de Ambiente e é composto das seguintes variáveis: (i) competências dos membros da organização (Grau de competências em engenharia de software dos membros da organização), (ii) conciliação de interesses (Grau de adequação da conciliação de interesses na implementação de processos), (iii) estrutura da organização (Grau de estabilidade interna na organização), (iv) motivação e satisfação dos membros da organização (Grau de satisfação dos membros da organização), (v) política de reconhecimento à colaboração na melhoria dos processos (Existência de política de reconhecimento à colaboração na melhoria dos processos) e (vi) respeito da consultoria pelos membros da organização (Grau de relacionamento dos membros da organização com a consultoria especializada). Todas estas variáveis medem a capacidade ambiental para estabelecer e manter iniciativas de melhoria de processo de software. Essas variáveis medem se existem condições favoráveis para 268

290 iniciar e manter uma iniciativa de melhoria sob dois pontos de vista: o indivíduo e a organização. As medidas do indivíduo estão relacionadas à satisfação dos membros da organização e ao relacionamento entre esses membros e a equipe de consultoria de melhoria de processo de software. As medidas da organização são relacionadas à conciliação entre os objetivos estratégicos e interesses da organização na melhoria de processo de software, e à estabilidade organizacional interna. O Fator 2 foi chamado de Estratégia e é composto das seguintes variáveis: (i) conscientização dos benefícios da implementação da melhoria dos processos (Grau de conscientização dos membros da organização quanto aos benefícios obtidos com a implantação dos processos) e (ii) estratégia de implementação de melhoria de processo de software (Grau de adequação da gerência do projeto de implementação da melhoria dos processos). Este fator indica que uma estratégia de melhoria de processo de software deve garantir que os membros da organização têm consciência dos benefícios que podem ser alcançados com a implementação da melhoria de processo de software. O Fator 3 foi chamado de Institucionalização e é composto das seguintes propriedades: (i) estratégia de implementação de melhoria de processo de software (Grau de adequação da relação push-pull na implementação dos processos), (ii) estrutura da organização (Grau de rotatividade de pessoal) e (iii) processos (Grau de adequação dos processos/procedimentos e Grau de institucionalização das melhorias implementadas nos projetos). Estas variáveis medem o grau de institucionalização das melhorias pela caracterização do grau de resistência da institucionalização dos processos e procedimentos a mudanças estruturais da organização, por exemplo, rotatividade de pessoal, e a dificuldades inerentes da implementação de melhoria de processo de software nos diferentes níveis organizacionais. O Fator 4 foi chamado de Comprometimento e é composto das seguintes propriedades: (i) apoio, comprometimento e envolvimento (Grau de apoio, comprometimento e envolvimento da alta gerência), (ii) competências dos membros da organização (Grau de competências em engenharia de software dos membros da organização) e (iii) recursos (Grau de disponibilidade de recursos financeiros dos membros da organização para atividades de melhoria de processo e Grau de disponibilidade de tempo dos membros da organização para atividades de melhoria de processo). Todas estas variáveis são consideradas indicadores de comprometimento para a melhoria de processo de software. Uma alta gerência comprometida para a melhoria de processo de software fornece recursos financeiros adequados desde a concepção do programa de melhoria e ao longo dos projetos de melhoria. Além do mais, uma gerência sênior comprometida garante que os membros da organização têm competências adequadas e tempo disponível para executar mudanças de processos eficientemente. O Fator 5 foi chamado de Motivação e aceitação e é composto das seguintes propriedades: (i) aceitação a mudanças (Grau de aceitação a mudanças), (ii) motivação e satisfação dos membros da organização (Grau de motivação dos membros da organização) e (iii) respeito da consultoria pelos membros da organização (Grau de confiança dos membros da organização na consultoria especializada). Este fator indica que a equipe de melhoria de processo de software é um facilitador da aceitação dos membros da organização para a institucionalização de mudanças nos processos promovidas pelas iniciativas de melhoria de processo de software. 269

291 4. Uma Abordagem para Condução de Iniciativas de Melhoria de Processos de Software Para apoiar organizações na gerência de seus programas de melhoria de processo de software de forma a tratar adequadamente questões que influenciam o sucesso desses programas, foi definida uma abordagem apoiada por uma infra-estrutura computacional baseada em um ambiente customizado de gerência de conhecimento centrado em processo. 4.1 Arquitetura da Abordagem A arquitetura da abordagem proposta é composta de diferentes componentes com objetivos e responsabilidades bem definidos, como pode ser observado na Figura 2 e explicado a seguir. Estudos Experimentais Artigos e Relatórios Técnicos Benchmarking de Projetos de Implementação de Melhoria de Processo de Software Identificação de Fatores Críticos de Sucesso Benchmarking de Projetos de Implementação Fatores Críticos de Sucesso Avaliação das Condições Organizacionais para Implementar Melhoria de Processo de Software Modelos de Referência de Processo Melhorias para serem implementadas Objetivos, características, necessidades e restrições da organização Definição de Estratégias de Implementação de Melhoria de Processos de Software Planejamento de Projetos de Implementação de Melhoria de Processo de Software Monitoração e Controle de Projetos de Implementação de Melhoria de Processo de Software Estratégias de Implementação Projetos de Implementação Figura 2. Componentes da Abordagem para Condução de Iniciativas de Melhoria de Processos de Software (MONTONI, 2007). O primeiro grupo de componentes aborda os conhecimentos sobre (i) os fatores críticos de sucesso que influenciam o resultados das iniciativas de melhoria e (ii) as estratégias de condução de implementação de melhorias de processos de software. Os componentes deste grupo são: Identificação de Fatores Críticos de Sucesso: este componente apóia a aquisição de conhecimento sobre os fatores críticos de sucesso que influenciam iniciativas de melhoria. O componente deve capturar conhecimento de diversas fontes, 270

292 como artigos, relatórios técnicos e estudos experimentais e auxiliar a aplicação da metodologia de identificação de fatores críticos de sucesso apresentada na Seção 3 deste trabalho. Definição de Estratégias de Implementação de Melhoria de Processos de Software: este componente apóia a aquisição de conhecimento sobre as estratégias de implementação de melhorias de processos de software em contextos específicos, considerando as características encontradas nas organizações que favorecem ou dificultam as iniciativas de melhoria. O componente deve permitir que diferentes instituições de consultoria armazenem (i) suas estratégias definidas com base em diferentes abordagens e modelos de referência de melhoria de processos, (ii) o contexto no qual estas estratégias são aplicáveis e (iii) diretrizes para adaptação das estratégias para apoiar a condução de iniciativas específicas de melhoria. Além disso, o componente deve permitir que uma organização de consultoria em melhoria de processos mantenha as suas estratégias de implementação com base no conhecimento adquirido a partir da condução de iniciativas anteriores de melhoria. O segundo grupo de componentes aborda a aplicação de técnicas de benchmarking em projetos de melhoria de processos de software. Os componentes deste grupo são: Benchmarking de Projetos de Implementação de Melhoria de Processo de Software: este componente apóia a identificação de melhores práticas de uma instituição de consultoria em melhoria de processos e a aplicação destas práticas em novas iniciativas de melhoria. Além disso, o componente mantém o conhecimento do desempenho dos projetos de melhoria de processos de software e os contextos encontrados nas organizações favoráveis ou não às iniciativas de melhoria, auxiliando as instituições de consultoria em implementação de melhoria de processos de software a determinarem o desempenho esperado em projetos com contextos similares atuais e futuros e a avaliarem o desempenho de seus projetos atuais com contextos similares. O terceiro grupo de componentes aborda a gerência e avaliação dos projetos de implementação de melhoria de processos de software. Os componentes deste grupo são: Planejamento de Projetos de Implementação de Melhoria de Processo de Software: este componente apóia o planejamento de projetos de implementação de melhoria de processos de software, auxiliando a seleção e adaptação de estratégias de implementação com base nas características encontradas nas organizações que favorecem ou dificultam as iniciativas de melhoria. Monitoração e Controle de Projetos de Implementação de Melhoria de Processo de Software: este componente apóia a monitoração das atividades executadas no contexto dos projetos de implementação de melhoria de processos de software, através de dados quantitativos e qualitativos, permitindo a identificação do desempenho dos projetos de melhoria. O componente deve apoiar também a monitoração e o tratamento de forma contínua dos fatores que podem influenciar significativamente o resultado das iniciativas. 271

293 Avaliação das Condições Organizacionais para Implementar Melhoria de Processo de Software: este componente apóia a identificação dos fatores que podem influenciar o sucesso de iniciativas de melhoria com base nas características encontradas nas organizações, no início da iniciativa de melhoria e durante a sua condução. 4.2 Os Conceitos de Processo Padrão e Estratégia de Implementação de Projetos de Melhoria de Processos de Software Dois conceitos utilizados neste trabalho são fundamentais e necessitam ser explicados. O primeiro conceito é o de processo padrão de melhoria de processos de software. Uma organização de consultoria em implementação de melhoria de processos de software pode possuir um ou mais processos padrão de melhoria, no qual as fases e subprocessos são definidos em alto nível. Os processos padrão de melhoria podem ser construídos com base em abordagens de implementação de melhoria de processos de software. Um exemplo seria um processo padrão definido com as fases e subprocessos encontrados no IDEAL (GREMBA e MYERS, 1997) ou no SPI-KM (SANTOS et al., 2007a). O segundo conceito é o de estratégia de implementação de melhoria de processos de software. Uma instituição de consultoria em implementação de melhoria de processos de software pode possuir uma ou mais estratégias de implementação de melhorias aplicáveis a cada um dos subprocessos de um ou mais processos padrão de melhoria de processos de software. As estratégias especializam e adaptam um subprocesso do processo padrão de melhorias, definindo as atividades a serem realizadas em cada subprocesso e gerando o processo definido para o projeto de melhoria. Uma estratégia de implementação de melhoria de processos de software aplicada a um subprocesso do processo padrão de melhoria define: (i) as atividades realizadas no subprocesso e suas descrições, como os artefatos requeridos e produzidos pelas atividades e os perfis normalmente responsáveis por suas execuções; (ii) os contextos encontrados nas organizações nos quais a estratégia pode ser aplicada; (iii) os conhecimentos necessários para a realização das atividades definidas pela estratégia; (iv) os recursos necessários para a realização das atividades definidas pela estratégia; (v) os riscos associados com a estratégia selecionada e observados em projetos anteriores; (vi) as ações de mitigação e contingência relacionadas com os riscos associados com a estratégia selecionada e os resultados obtidos nas suas execuções em projetos anteriores; (vii) o tempo e esforço normalmente demandados pelas atividades definidas pela estratégia, com base nas suas execuções em projetos anteriores; e (viii) a comunicação necessária para o sucesso das atividades definidas pela estratégia, baseada nas suas execuções em projetos anteriores. Como exemplo de estratégia, podemos pensar no subprocesso Estabelecer a Infra-estrutura definido na abordagem de implementação de melhoria de processos de software IDEAL (GREMBA e MYERS, 1997), na fase Iniciar. Dependendo do contexto encontrado nas organizações, as instituições de consultoria em implementação de melhoria de processos de software podem optar por fornecer ou indicar infra-estruturas diferentes. Caso as organizações não possuam o apoio ferramental necessário para alcançar as melhorias desejadas, por exemplo, as instituições de consultoria podem 272

294 sugerir várias ferramentas, de acordo com o contexto encontrado nas organizações, como facilidade de aprendizado, ferramentas já utilizadas pelas organizações e necessidades demandadas pelas melhorias almejadas. Dependendo do apoio ferramental sugerido, as instituições de consultoria em implementação de melhoria de processos de software podem realizar atividades específicas do apoio sugerido. Um exemplo é a utilização da Estação TABA (FERREIRA et al., 2006; MONTONI et al., 2006; MONTONI et al., 2007) fornecida pela COPPE/UFRJ para as organizações que a contratam para consultoria em processos de software. A COPPE/UFRJ precisa realizar customizações na Estação TABA para adaptá-la ao contexto das organizações que a utilizam, realizando atividades relacionadas com estas adaptações, como o cadastro do processo padrão de desenvolvimento das organizações na ferramenta. 4.3 Apoio Ferramental Um conjunto de ferramentas está sendo desenvolvido para apoiar a aplicação da abordagem apresentada acima. Essas ferramentas estão sendo integradas em um ambiente customizável de gerência de conhecimento centrado em processo chamado de CORE-KM (Customizable Organizational Resources Environment with Knowledge Management) (GALOTTA et al., 2004). Um ambiente de gerência de conhecimento foi customizado a partir do CORE- KM para a COPPE/UFRJ considerando suas características particulares e processos organizacionais. Esse ambiente está sendo utilizado para apoiar a aplicação da estratégia de implementação de melhoria de processo da COPPE/UFRJ, também chamada de SPI- KM, em organizações desenvolvedoras de software. A estratégia SPI-KM foi utilizada para coordenar inúmeras iniciativas de implementação de melhoria de processos de software em diversas organizações desenvolvedoras de software do Brasil (SANTOS et al., 2007a; SANTOS et al., 2007b). A realização de avaliações formais nessas organizações indicam que a estratégia da COPPE/UFRJ é eficaz e eficiente. No entanto, a aplicação da estratégia foi realizada sem nenhum apoio computacional, o que criou inúmeras dificuldades, por exemplo, a dificuldade de transferir o conhecimento sobre a estratégia para consultores em melhoria iniciantes. O conjunto de ferramentas definidas para apoiar a abordagem é o seguinte: Ferramenta de apoio à Gerência de Estratégia de Implementação de Melhoria de Processo: o objetivo desta ferramenta é fornecer apoio para (i) gerenciar informações sobre fatores críticos de sucesso que influenciam iniciativas de melhoria de processo de software e (ii) gerenciar informações de estratégias de implementação de melhoria de processo de software de uma organização de consultoria específica. Ferramenta de apoio à Benchmarking de Projetos de Implementação de Melhoria de Processo de Software: o objetivo desta ferramenta é fornecer apoio para (i) definir uma base de benchmarking de projetos de implementação de melhoria de processo de software coordenados por uma organização de consultoria específica, (ii) fornecer mecanismos de gerência de informações de projetos de implementação de melhoria de processo de software coordenados por uma organização de consultoria específica e (iii) fornecer mecanismos de consulta de informações de projetos similares de implementação de melhoria de processo de 273

295 software coordenados por uma organização de consultoria específica. A Figura 3 apresenta a tela desta ferramenta que consolida informações sobre o desempenho de diferentes estratégias de implementação de melhoria de processo de software. Ferramenta de apoio à Gerência de Projetos de Implementação de Melhoria de Processo de Software: o objetivo desta ferramenta é fornecer apoio para (i) planejar projetos de implementação de melhoria de processo de software coordenados por uma organização de consultoria específica, (ii) monitorar e controlar projetos de implementação de melhoria de processo de software coordenados por uma organização de consultoria específica e (iii) avaliar as condições organizacionais para implementar melhoria de processo de software. A Figura 4 apresenta a tela desta ferramenta que apóia a identificação de fatores críticos de sucesso que influenciam projetos de implementação de melhoria de processo de software. A partir desta tela, o gerente do projeto de implementação pode identificar fatores críticos de sucesso presentes em um projeto específico e definir um plano de gerência de risco constituído de ações de mitigação e contingenciamento para gerenciar os fatores avaliados negativamente como ameaças potenciais ao sucesso do projeto. Figura 3. Tela do relatório de Benchmarking. 274

296 Figura 4. Tela de identificação de fatores críticos de sucesso. 5. Conclusão Este trabalho apresentou uma abordagem para condução de iniciativas de melhoria de processo de software. Também foi apresentada uma metodologia para apoiar a identificação de fatores críticos de sucesso que influenciam iniciativas de melhoria de processo de software. O apoio ferramental desenvolvido para apoiar a abordagem proposta foi também discutido. Um estudo de casos de aplicação da abordagem apresentada está sendo planejado para avaliar a abordagem e identificar seus pontos fortes, pontos fracos e oportunidades de melhoria. A partir deste estudo, espera-se que seja verificado, em organizações de consultoria em melhoria de processo de software, os seguintes benefícios principais com o uso da abordagem proposta neste trabalho: (i) acumular conhecimento sobre fatores críticos de sucesso que influenciam iniciativas de melhoria de processos de software; (ii) acumular conhecimento sobre estratégias de implementação de melhoria de processos de software; (iii) facilitar a seleção e adaptação de estratégias de implementação de melhoria de processos de software em contextos específicos de implementação; (iv) facilitar a avaliação das condições organizacionais para implementar melhorias nos processos de software; (v) facilitar a gerência de iniciativas de melhoria de processos de software com base em estratégias de implementação mais eficientes e eficazes; (vi) aumentar a visibilidade dos resultados das iniciativas de melhoria e diminuir os custos, prazo e esforço na condução dessas 275

297 iniciativas; e (vii) preservar o conhecimento relacionado à condução de iniciativas de melhoria e facilitar a identificação de melhores práticas na implementação de melhoria de processos de software. Referências BADDOO, N., HALL, T., 2002a, "Motivators of Software Process Improvement: An analysis of practitioners' views", Journal of Systems and Software, v. 62, n. 2, pp BADDOO, N., HALL, T., 2002b, "Software process improvement motivators: An analysis using multidimensional scaling", Empirical Software Engineering, v. 7, n. 2, pp BADDOO, N., HALL, T., 2003, "De-motivators for software process improvement: An analysis of practitioners' views", Journal of Systems and Software, v. 66, n. 1, pp COLEMAN, G., O'CONNOR, R., 2006, "Software process in practice: A Grounded Theory of the irish software industry", v LNCS, pp , Joensuu, Finland. CRONBACH, L.J., 1951, "Coefficient Alpha and the Internal Consistency of Tests", Psychometrica, v. 16 (September), pp DYBA, T., 2000, "An Instrument for measuring the key factors of success in software process improvement", Empirical Software Engineering, v. 5, n. 4, pp EL-EMAM, K., GOLDENSON, D., MCCURLEY, J., et al., 2001, "Modelling the likelihood of software process improvement: An exploratory study", Empirical Software Engineering, v. 6, n. 3, pp FERREIRA, A.I.F., SANTOS, G., CERQUEIRA, R., et al., 2006, "Taba workstation: Supporting software process improvement initiatives based on software standards and maturity models", v NCS, pp , Joensuu, Finland. GALOTTA, C., ZANETTI, D., ROCHA, A.R., et al., 2004, "Organizational Learning Based on a Customizable Environment for Knowledge Management Using Intranet". In: E-LEARN 2004 World Conference on e-learning in Corporate, Government, Healthcare & Higher Education, v. 2, pp , Washington, EUA. GOLDENSON, D.R., HERBSLEB, J.D., 1995, After the Appraisal: A Systematic Survey of Process Improvement, its Benefits and Factors that Influence Success, CMU/SEI-95-TR-009, Software Engineering Institute. GREMBA, J., MYERS, C., "The IDEAL Model: A Practical Guide for Improvement ". In: KIM, J., MUELLER, C., 1978, Factor Analysis: Statistical Methods and Practical Issues, Sage Publications. MONTONI, M., 2007, Uma Abordagem para Condução de Iniciativas de Melhoria de Processos de Software, Exame de Qualificação para o Doutorado, COPPE, UFRJ, Rio de Janeiro. 276

298 MONTONI, M., ROCHA, A.R., 2007, "A Methodology for Identifying Critical Success Factors that Influence Software Process Improvement Initiatives: An Application in the Brazilian Software Industry", Lecture Notes in Computer Science (LNCS), LNCS 4764, EuroSPI - European Systems & Software Process Improvement and Innovation (Setembro), pp MONTONI, M., SANTOS, G., ROCHA, A.R., et al., 2006, "Taba workstation: Supporting software process deployment based on CMMI and MR-MPS.BR", v NCS, pp , Amsterdam, Netherlands. MONTONI, M., SANTOS, G., ROCHA, A.R., et al., 2007, "MPS Model and TABA Workstation: Implementing Software Process Improvement Initiatives in Small Settings". In: Software Quality, WoSQ'07: ICSE Workshops Fifth International Workshop on, pp NIAZI, M., WILSON, D., ZOWGHI, D., 2005, "A framework for assisting the design of effective software process improvement implementation strategies", Journal of Systems and Software, v. 78, n. 2, pp NIAZI, M., WILSON, D., ZOWGHI, D., 2006, "Critical success factors for software process improvement implementation: An empirical study", Software Process Improvement and Practice, v. 11, n. 2, pp NUNNALLY, J.C., 1978, Psychometric Theory, 2nd ed. New York, McGraw-Hill. SANTOS, G., MONTONI, M., FIGUEIREDO, S., et al., 2007a, "SPI-KM Lessons Learned from Appling a Software Process Improvement Strategy Supported by Knowledge Management". In: 8th International PROFES (Product Focused Software Development and Process Improvement), LNCS 4589, pp , Riga, Latvia, July. SANTOS, G., MONTONI, M., VASCONCELLOS, J., et al., 2007b, "Implementing Software Process Improvement Initiatives in Small and Medium-Size Enterprises in Brazil". In: 6th QUATIC (International Conference on the Quality of Information and Communications Technology), Lisboa, Portugal, Setembro. STATSOFT, 2004, "STATISTICA Electronic Manual", StatSoft Inc. STRAUSS, A., CORBIN, J.M., 1998, Basics of Qualitative Research: Techniques and Procedures for Developing Grounded Theory, 2nd ed., Sage Publications. WILSON, D.N., HALL, T., BADDOO, N., 2001, "A framework for evaluation and prediction of software process improvement success", Journal of Systems and Software, v. 59, n. 2, pp WU, M., YING, J., YU, C., 2004, "A methodology and its support environment for benchmark-based adaptable software process improvement", v. 6, pp , The Hague, Netherlands. ZAHARAN, S., 1998, Software Process Improvement Practical Guidelines for Business Success, Addison-Wesley. 277

299 278

300 identificadas pelos responsáveis pelos processos e demais ativos de processos. Neste momento, deve-se identificar os itens de configuração e as versões destes itens que compõem uma baseline e descrever esta baseline além das diferenças para com a anterior. Após criada, é possível Entregar Baseline aos interessados. Para isso, o responsável pelos ativos de processo deve em primeiro lugar selecionar a baseline a ser entregue, empacotá-la e em seguida entregá-la ao receptor, por exemplo, através da disponibilização em uma intranet ou diretamente através de . A atividade Relatar Situação tem por objetivo manter todos os envolvidos no projeto informados sobre as alterações ocorridas nos itens de configuração. Logo, informações como quem modificou um certo item, quem está modificando determinado item, quando uma modificação ocorreu, quais itens serão afetados por uma alteração, porque uma alteração foi necessária, quais são as versões de itens, quais baselines foram criadas, entre outras questões, devem ser mantidas. O acesso a estas informações deve ser rápido. Este relatório pode ser útil para divulgar modificações realizadas em um determinado ativo de processo e, também, durante a Auditoria da Configuração. Esta atividade visa assegurar que as alterações tenham sido implementadas corretamente e analisar a integridade dos itens de configuração e baselines. Essas auditorias são conduzidas de acordo com processos bem definidos que se constituem de vários papéis e responsabilidades de auditores. Logo, cada auditoria deve ser planejada cuidadosamente. Uma auditoria pode necessitar de certo número de indivíduos para realizar uma variedade de tarefas durante um período de tempo razoavelmente curto. O processo descrito não é completamente executado, de fato, seqüencialmente. A definição da estrutura da biblioteca de ativos deve ser executada num momento inicial e, logo após, deve-se cadastrar os itens na biblioteca. A partir deste momento a definição do plano de gerência de configuração pode ser realizada e, posteriormente, verificada sempre que necessário. As demais atividades podem ser executadas várias vezes ao longo do tempo, por exemplo, sempre que um usuário da biblioteca de ativos necessitar alterar um determinado ativo de processo. 4. Outras Abordagens O escopo do apoio ferramental para auxiliar na execução de iniciativas de melhoria de processos em organizações encontrados na literatura é variado. Um dos apoios relatados é o feito em relação ao processo de gerência de configuração ou a criação e gerência de uma biblioteca de ativos de processos. O SIR-CM [Park et al. 2007] é uma ferramenta de gerência de ativos de processo envolvidos em uma iniciativa de melhoria de processos de software. Esta ferramenta é um repositório que pode armazenar e gerenciar ativos heterogêneos e variados de processos de software. Permite a visualização de dados históricos e possui funcionalidades para disponibilização de métricas e gerência de documentos. O e-r&d [Ebert e De Man 2002] é um sistema de gerência de workflow e adaptação de processos com uma biblioteca de ativos com apoio de gerência de configuração utilizado para gerenciar a diversidade de processos dentro de uma corporação francesa. Segundo os autores, os benefícios conseguidos incluíram: melhoria da qualidade, redução do tempo de desenvolvimento, aumento da flexibilidade 285

301 de engenharia, redução de esforço para tarefas, melhoria na comunicação, melhoria no alinhamento de processos e ferramentas, maior facilidade de geração de planos de treinamento. WAGNER EPG/ER [Kurniawati e Jeffery 2004] é utilizado para a divulgação de processos numa organização através de um guia eletrônico de processos (EPG, do inglês Eletronic Process Guide) e baseado no framework WAGNER com apoio de um repositório de experiências (ER). O objetivo do sistema é divulgar os processos da organização, aumentando o seu uso e melhorando a institucionalização, além da criação de um repositório de experiências e, conseqüentemente, do aumento da memória organizacional. Dentre as abordagens estritamente comerciais, pode citar o Microsoft Solutions Framework for CMMI Process Improvement que encapsula uma abordagem para o desenvolvimento formal de software e melhoria contínua do processo [Hundhausen 2006]. Este framework é composto por um guia com processos básicos associados com papéis comuns no desenvolvimento de software (por exemplo, gerentes, testadores, desenvolvedores etc.) e templates que auxiliam a executar as tarefas destes processos. As ferramentas disponíveis no Visual Studio Team System (VSTS) [Microsoft 2008] podem ser utilizadas em conjunto com este framework. Em relação à gerência de configuração, a ferramenta VSTS provê sistema de controle de versão, criação de baselines diretamente relacionados a código e artefatos de engenharia de software e gerenciamento do fluxo de mudança nos itens de configuração; o SharePoint [Microsoft 2007] provê versionamento mais simples e armazenamento de artefatos (documentos principalmente) com controle de acesso. Estas ferramentas, no entanto, precisam ser configuradas adequadamente para uso e devem ser adaptadas ao processo em uso e ao fluxo de vida dos produtos de trabalho em cada organização individualmente. Outras ferramentas de gerência de configuração como o IBM Rational ClearQuest [IBM 2008], CVS [Ximbiot 2008] e SVN [Tigris 2008] também podem ser utilizadas como repositórios de arquivos e funcionar como uma biblioteca de ativos organizacionais. 5. Estudo de Caso Em janeiro de 2007 a Organização A começou a implementação de processos visando a uma avaliação no Nível F do MPS.BR. Esta organização está localizada no Rio de Janeiro e é especializada no desenvolvimento e comercialização de pacotes de soluções, principalmente para os ramos da saúde, educação e finanças. O principal objetivo de qualidade do programa de melhoria de processos de software da empresa foi o aumento da qualidade dos produtos e a diminuição do esforço de manutenção, devido à longa vida útil e adaptabilidade de seus produtos. Em outubro de 2007 a Organização A obteve o Nível F do MPS.BR. Apesar de o Nível F do MPS.BR não prever a definição de processos padrão fez parte da estratégia adotada a definição de um processo padrão para Desenvolvimento de Software além de processos padrão referente aos processos Gerência de Projetos, Gerência de Requisitos, Garantia da Qualidade, Gerência de Configuração e Medição, previstos pelo MPS.BR. Além destes processos, outros ativos organizacionais foram identificados: documento de nomeação do Grupo de Processos (que envolve os membros do Grupo de Garantia de Qualidade, Gerência de Configuração e Medição), 286

302 definição da política organizacional, plano de gerência de configuração organizacional e plano de medição organizacional. Uma estrutura compatível com estes ativos de processos foi definida na Estação Taba, como pode ser vista na Figura 2. Foi definida uma estrutura adequada para armazenar: (i) Política Organizacional; (ii) Nomeação do Grupo de Processos; (iii) Processo de Desenvolvimento; (iv) Processos (referentes a cada processo do Nível F do MPS.BR); (v) Plano de Gerência de Configuração Organizacional; e (vi) Plano de Medição e Análise Organizacional. Figura 2 Definição de Processos para a Organização A Figura 2 mostra a tela da ferramenta GConf responsável por elaborar o plano de gerência de configuração. Pode-se ver, nesta tela, a escolha dos itens da Biblioteca de Ativos que devem ser gerenciados. Note no lado direito da Figura as atividades do processo descrito na seção anterior (Definir Estrutura da Biblioteca de Ativos da Organização e Visualizar Estrutura da Biblioteca de Ativos da Organização). A figura 3 exibe a tela da ferramenta GConf que apóia o planejamento da Gerência de Configuração. O objetivo desta atividade é permitir que o Gerente de Configuração identifique os itens de configuração que terão suas alterações controladas em um determinada granularidade. Para os itens de configuração presentes em uma baseline, será necessário solicitar a alteração, ter a solicitação aprovada, alterar o item e ter a alteração aprovada. Em seguida, será gerada automaticamente uma nova versão do item de configuração referente ao artefato alterado. Para os itens de configuração que não estão presentes em nenhuma baseline, basta informar a alteração a ser realizada. Neste caso, uma nova versão do item de configuração também é gerada. 287

303 Figura 3 Definição do Plano de Configuração de Ativos de Processos A Figura 4 exibe a tela da ferramenta onde pode ser feito o cadastro das instâncias dos ativos de processos. Note que o item selecionado (Plano de Gerência de Configuração da Organização) é um item de configuração presente no Plano de Gerência de Configuração e está com a situação Aprovado, dessa forma, a alteração deste ativo de processo só pode ser feita com a utilização da ferramenta GConf. 288

304 Figura 4 Cadastro de Ativos de Processo A Figura 5 apresenta a tela de análise do pedido de alteração sob um ativo de processo. Neste caso, o Processo de Medição. Figura 5 Alteração de Ativo de Processo sob Gerência de Configuração Antes da avaliação na empresa foi criada uma baseline dos ativos organizacionais contendo: Nomeação do Grupo de Processos, Plano de Gerência de Configuração da Organização, Plano de Medição da Organização, Política Organizacional, Processo de Desenvolvimento, Processo de Garantia da Qualidade, Processo de Gerência de Configuração, Gerência de Projetos, Processo de Gerência de Requisitos, Processo de Medição. Devido a uma alteração no Plano de Medição da Organização os seguintes documentos necessitaram ser alterados, também: Processo de Desenvolvimento, Processo de Garantia da Qualidade, Processo de Gerência de Configuração, Gerência de Projetos, Processo de Gerência de Requisitos, Processo de Medição. Um outro documento, Nomeação do Grupo de Processos, também foi alterado devido a modificações na estrutura e participantes do Grupo de Processos. Todos os registros foram mantidos pela ferramenta GConf e o processo de alteração implementado por ela foi seguido. De posse destes documentos e dos registros na forma de um relatório gerado automaticamente, foi possível realizar uma auditoria no conteúdo da biblioteca de ativos antes da avaliação para evidenciar que a integridade das baselines dos documentos organizacionais era estabelecida e mantida através de auditoria da configuração e de registros da Gerência de Configuração. 289

305 O uso da abordagem descrita permitiu a gerência e controle dos ativos de processos e também facilitou a auditoria de configuração sob o conteúdo da biblioteca de ativos. Atualmente a Organização A está definindo uma nova versão dos processos de forma a atender toda a organização, englobando projetos de customização, integração e migração, além dos projetos de desenvolvimento. Devido a essa nova definição do processo de desenvolvimento será necessário, também, alterar os demais processos, o que deve ser feito com o auxílio das ferramentas já utilizadas. 6. Perspectivas Futuras O foco principal das ferramentas é a integração com as outras ferramentas da Estação Taba visando a automatização do maior número possível de tarefas do engenheiro de software com o maior nível de qualidade possível. O objetivo é diminuir as dificuldades inerentes do ciclo de vida de um software. O ponto principal da abordagem que deseja-se tornar transparente para o engenheiro de software é a atividade de auditoria da configuração. Atualmente, a abordagem apóia a execução desta atividade com informações sobre os itens de configuração e os baselines. Então, o auditor deve analisar estas informações a fim de avaliar os itens de configuração e os baselines em relação a critérios pré-estabelecidos pela organização. A nova proposta, que ainda será implementada, deve tornar a avaliação destes critérios automatizada, de modo que o engenheiro de software não utilize seu tempo avaliando os critérios que a ferramenta pode avaliar automaticamente. Como exemplo de critérios que poderão ser avaliados automaticamente pode-se citar: itens de configuração com pedidos de alteração pendentes a mais de X dias, itens de configuração que estão em alteração a mais de X dias, itens de configuração que deveriam estar na baseline mas não estão, artefatos que deveriam ter sido gerados mas que não foram e artefatos que deveriam estar sob controle da gerência de configuração mas que não estão. O auditor poderá escolher quais critérios devem estar presentes nas avaliações. Um outro esforço de melhoria a ser realizado é a integração da ferramenta de gerência de configuração e da biblioteca de ativos com ferramentas de gerência de configuração existentes no mercado, como por exemplo o cvs [CVS 2006], source safe [Microsoft 2008], e o subversion [Rooney 2005]. Normalmente as empresas já utilizam alguma ferramenta de gerência de configuração e acredita-se que a integração das ferramentas descritas neste artigo com as ferramentas utilizadas nas empresas possa facilitar a utilização da abordagem. Com a modificação a ser realizada, o engenheiro de software poderá efetuar controlar os pedidos de alteração dos itens de configuração e efetuar as auditorias através da Estaçao Taba e a Estação Taba delegaria para uma ferramenta de gerência de configuração externa o controle de versões dos itens de configuração e dos baselines, de forma transparante. 7. Considerações Finais Este artigo apresentou a estratégia de Gerência de Configuração de Ativos de Processos de Software em uso na Estação Taba. Apresentou também o estudo de caso de utilização dessa estratégia e, também, das duas ferramentas que a implementam numa empresa de software no Rio de Janeiro visando a criação de uma biblioteca de ativos de 290

306 processos utilizados durante a implementação de processos que culminou com uma avaliação no Nível F do MPS.BR. Atualmente a Estação Taba está sendo evoluída para apoiar a definição e construção de Ambientes de Engenharia de Software Orientados a Corporação [Santos 2005] visando prover o apoio computacional que possibilite a uma corporação, em relação aos processos de software, gerenciar a diversidade e os estágios de maturidade de cada uma das organizações que a compõem de forma adequada às suas necessidades. Do mesmo modo que a diversidade de processos no contexto corporativo é maior do que em uma organização isolada, a quantidade de ativos de processo relacionados a estes processos também é maior e também devem ser gerenciados e controlados. Os Ambientes Orientados a Corporação devem, portanto, possuir uma biblioteca de ativos de processos que garanta à corporação a gerência dos seus ativos de processos e, além disso, permitir à corporação um maior controle sobre a gerência e evolução do conteúdo das bibliotecas de ativos de processos de suas organizações subordinadas. Dessa forma, a Biblioteca de Ativos de Processos com apoio de Gerência de Configuração descrita neste artigo será alterada para permitir esse novo tipo de controle. Além disso, uma nova implementação da Estação Taba está sendo desenvolvida na Web. As ferramentas atuais serão migradas gradativamente. Dessa forma, uma nova implementação da Biblioteca de Ativos de Processo está prevista para Esta nova implementação, além dos benefícios que uma ferramenta Web proporciona, também abrangerá as melhorias descritas na seção anterior. Referências ANDRADE, J.M.S. (2005), Avaliação de Processos de Software em ADSOrg, Dissertação de M. Sc., COPPE, UFRJ, Rio de Janeiro, Brasil. Baddoo, N., Hall, T. (2003), "De-motivators for software process improvement: An analysis of practitioners' views", Journal of Systems and Software, v. 66, n. 1, pp Berger, P. (2003), Instanciação de Processos de Software em Ambientes Configurados na Estação TABA, Dissertação de M. Sc., COPPE, UFRJ, Rio de Janeiro, Brasil. Campos, F.B., Albuquerque, A.B., Andrade, J.M., et al. (2006), "Abordagem em Níveis para Avaliação e Melhoria de Processos de Software". In: V Simpósio Brasileiro de Qualidade de Software - SBQS 2006, pp , Vila Velha - ES. Chrissis, M.B., Konrad, M., Shrum, S. (2006), CMMI (Second Edition): Guidelines for Process Integration and Product Improvement, Addison Wesley Professional. CVS - Concurrent Versions System (2006). In: accessed in 13/03/2008. Ebert, C., De Man, J. (2002), "e-r&d - Effectively managing process diversity", v. 14, n. 1-4, pp Ferreira, A.I.F., Santos, G., Cerqueira, R., et al. (2007), "Applying ISO 9001:2000, MPS.BR and CMMI to Achieve Software Process Maturity: BL Informatica s Pathway". In: 29th Int. Conference on Software Engineering (ICSE), pp , Minneapolis, USA, May. Ferreira, A.I.F., Santos, G., Cerqueira, R., et al. (2006), "Taba workstation: Supporting software process improvement initiatives based on software standards and maturity 291

307 models". In: Lecture Notes in Computer Science (including subseries Lecture Notes in Artificial Intelligence and Lecture Notes in Bioinformatics), v LNCS, pp , Joensuu. Figueiredo, S., Santos, G., Rocha, A.R. (2004), "Gerência de Configuração em Ambientes de Desenvolvimento de Software Orientados a Organização". In: III Simpósio Brasileiro de Qualidade de Software - SBQS 2004, Brasília - DF. Hundhausen, R. (2006), Working with Microsoft Visual Studio 2005 Team System, 5th ed. Redmond, USA, Microsoft Press. IBM, "IBM Rational ClearQuest". In: ibm.com/software/awdtools/clearquest/, accessed in 13/03/2008. IEEE (1990), "Std ", IEEE Standard Glossary of Software Engineering Terminology, v. Std ISO/IEC (1998), "Tecnologia de Informação - Processos de ciclo de vida de Software", ABNT - ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS, v. ISO/IEC ISO/IEC-12207:Amd1 (2002), "Information Technology - Amendment 1 to ISO/IEC 12207", The International Organization for Standardization and the International Electrotechnical Commission, v. ISO/IEC-12207:Amd1. ISO/IEC-12207:Amd2 (2004), "Information Technology - Amendment 2 to ISO/IEC 12207", The International Organization for Standardization and the International Electrotechnical Commission, v. ISO/IEC-12207:Amd2. Kurniawati, F., Jeffery, R. (2004), "The long-term effects of an EPG/ER in a small software organisation". In: Proceedings of the Australian Software Engineering Conference, ASWEC, v. 2004, pp , Melbourne, Vic. Microsoft, "Microsoft Office Sharepoint Server 2007". In: Microsoft, "Visual Studio Team System 2005 Developer Center". In: Microsoft Visual SourceSafe Roadmap (2008). In: accessed in 13/03/2008. Montoni, M. (2003), Aquisição de Conhecimento: Uma Aplicação no Processo de Desenvolvimento de Software, Dissertação de M.Sc., COPPE, Dissertação, Rio de Janeiro, Rj, Brasil. MONTONI, M., SANTOS, G., FIGUEIREDO, S., et al. (2006), "Uma Abordagem de Garantia de Qualidade de Processos e Produtos de Software com Apoio de Gerência de Conhecimento na Estação TABA". In: V Simpósio Brasileiro de Qualidade de Software - SBQS 2006, pp , Vila Velha - ES. Montoni, M., Santos, G., Rocha, A.R., et al. (2007), "MPS Model and TABA Workstation: Implementing Software Process Improvement Initiatives in Small Settings". In: Fifth Workshop on Software Quality held in conjunction with the 29th Int. Conference on Software Engineering (ICSE), Minneapolis, USA, May. Niazi, M., Wilson, D., Zowghi, D. (2005), "A framework for assisting the design of effective software process improvement implementation strategies", Journal of Systems and Software, v. 78, n. 2, pp Park, E.-J., Kim, H.-K., Lee, R.Y. (2007), "Frameworks of Integration Repository for Software Process Improvement using SOA". In: Computer and Information Science, ICIS th IEEE/ACIS International Conference on, pp

308 Rocha, A.R.C., Maldonado, J.C., Weber, K.C. (2001), Qualidade de Software: Teoria e Prática, 1a ed., Prentice Hall. Rooney, G. (2005), Practical Subversion, ISBN , 1a ed., paperback. Santos, G. (2003), Representação da Distribuição do Conhecimento, Habilidades e Experiências através da Estrutura Organizacional, Dissertação de M. Sc., COPPE, UFRJ, Rio de Janeiro, Brasil. Santos, G. (2005), Ambiente de Engenharia de Software Orientado a Corporações, Exame de Qualificação, COPPE, UFRJ, Rio de Janeiro, Brasil. Santos, G., Montoni, M., Figueiredo, S., et al. (2007), "SPI-KM - Lessons Learned from Applying a Software Process Improvement Strategy Supported by Knowledge Management", Product-Focused Software Process Improvement. Santos, G., Villela, K., Montoni, M., et al. (2005), "Knowledge management in a software development environment to support software processes deployment", v NAI, pp , Kaiserslautern, Germany. Silva Filho, R.C. (2006), Uma Abordagem para Avaliação de Propostas de Melhoria em Processos de Software, Dissertação de M.Sc., COPPE, UFRJ, Rio de Janeiro, RJ, Brasil. SOFTEX (2007a), "MPS.BR Guia de Implementação - Parte 3". SOFTEX (2007b), "MPS.BR Guia Geral". SWEBOK, "Guide to the Software Engineering Body of Knowledge". In: accessed in 13/03/2008. Tigris, "SubVersion". In: accessed in 13/03/2008. Villela, K. (2004), Definição e Construção de Ambientes de Desenvolvimento de Software Orientados à Organização, Tese de D. Sc., COPPE, UFRJ, Rio de Janeiro, Brasil. VILLELA, K., SANTOS, G., MONTONI, M., et al. (2004), "Definição de Processos em Ambientes de Desenvolvimento de Software Orientados a Organização". In: III Simpósio Brasileiro de Qualidade de Software - SBQS 2004, pp. 4-18, Brasília - DF. Ximbiot, "Ximbiot - CVS Wiki". In: accessed in 13/03/2008. Zaharan, S. (1998), Software Process Improvement Practical Guidelines for Business Success, Addison-Wesley. 293

309 Farah, J. (2004) Changes: The Crossroads Between Project CM and Product CM. CM Crossroads, October, último acesso abril/2007. Fernandes, A. A. e Teixeira, D. S. (2004) Fábricas de Software: Implantação e Gestão de Operações. São Paulo Atlas, Guess, V. (1998). What s New in CM? Institute of Configuration Management Scottsdale, último acesso - junho/2007. Junk, W. S. (2000) The Dynamic Balance Between Cost, Schedule, Features, and Quality in Software Development Projects. Moscow, Kasse, T. e McQuaid, P. A. (2000) Software Quality Professional. American Society for Quality. September, último acesso junho/2007. Lim, N., Ang, S. K. J. e Pavri, F.N. (1999) Diffusing Software-based Technologies with a Software Factory Approach for Software Development: A Theoretical Framework. Department of Decision Sciences, Faculty of Business Administration, National University of Singapore, Republic of Singapore, Mantis Bug Tracker (2007). último acesso maio/2008. Oliveira, K. C. A. (2007) Um processo de Gerência de Configuração baseado no nível 2 do CMMI estagiado para Fábricas de Software Orientadas a Produto. Dissertação de Mestrado, Universidade Federal de Pernambuco, Agosto Software Engineering Institute - CMU/SEI-2002-TR-028 (2002) Capability Maturity Model Integration, Version 1.1 CMMI for Software Engineering (CMMI-SW, V1.1) Continuous Representation. Carnegie Mellon University, August Software Engineering Institute - CMU/SEI-2002-TR-029 (2002) Capability Maturity Model Integration, Version 1.1 CMMI for Software Engineering (CMMI-SW, V1.1) Staged Representation. Carnegie Mellon University, August The Standish Group International (2001) Extreme CHAOS February os.pdf, último acesso junho/2006. The Standish Group Web Site (2007), último acesso junho/2007. The Standish Group International (1995) Chaos Report (1994). último acesso junho/2007. Tachizawa, T. e Scaico, O. (1997) Organização Flexível: Qualidade na gestão por processos. São Paulo Atlas,

310 VII Simpósio Brasileiro de Qualidade de Software Relatos de Experiência

311

312

313 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 Gleison Santos, Mariano Montoni, Anne Elise Katsurayama, Reinaldo Cabral, Sávio Figueiredo, Ana Candida Natali, Cristina Cerdeiral, Jucele Vasconcellos, David Zanetti, Peter Lupo, Ana Regina Rocha COPPE/UFRJ - Universidade Federal do Rio de Janeiro Programa de Engenharia de Sistemas e Computação Av. Horácio Macedo, 2030, Prédio do Centro de Tecnologia, Bloco H, Sala 319 Caixa Postal CEP Rio de Janeiro, RJ {gleison, mmontoni, anneelisek, cabral, savio, anatali, cerdeiral, jucele, zanetti, darocha}@cos.ufrj.br Abstract. During the last 5 years, Brazilian software industry and universities are working cooperatively to develop and disseminate the MPS Model, aiming to improve the quality of Brazilian software processes and products. In order to cope with difficulties Small and Medium-size Enterprises (SMEs) face during SPI implementation and to facilitate the dissemination of the MPS Model, we developed an approach, named SPI-KM, supported by a Process-centered Software Engineering Environment. This paper presents the results and lessons learned of the application of the SPI-KM approach in a group of 5 Brazilian SMEs that implemented the MPS Model. Resumo. Nos últimos 5 anos, universidades e a indústria de software do Brasil têm trabalhado para desenvolver e disseminar o MPS.BR com o intuito de melhorar a qualidade dos produtos e processos de software brasileiros. Para melhor lidar com as dificuldades que pequenas e médias empresas enfrentam durante a implementação de programas de melhoria de processos de software e facilitar a disseminação do MPS.BR, foi desenvolvida uma abordagem, denominada SPI-KM, apoiada por um ambiente de engenharia de software centrado em processos. Este artigo apresenta os resultados e lições aprendidas pela aplicação desta estratégia num grupo de 5 empresas situadas no Rio de Janeiro durante a implementação dos níveis G e F do MPS.BR. 1. Introdução A melhoria de processos em pequenas empresas exige um tratamento diferenciado em virtude das restrições existentes em relação a recursos materiais e humanos. No entanto, para garantir sua sobrevivência, é essencial que estas empresas busquem superar estas dificuldades e aprimorar seu processo produtivo. Para apoiar este esforço para melhoria de processos em pequenas e médias empresas algumas abordagens têm sido propostas [Thiry et al. 2006]. O MPS.BR é um programa para Melhoria de Processo do Software Brasileiro que teve início em 2003, sob coordenação da Associação para Promoção da 311

314 Excelência do Software Brasileiro (Softex), cujo principal objetivo é viabilizar a implantação dos princípios de Engenharia de Software de forma adequada ao contexto das empresas brasileiras em consonância com as principais abordagens internacionais para definição, avaliação e melhoria de processos de software [Softex 2006]. O Software Engineering Institute (SEI) também tem demonstrado interesse em pesquisas com foco em melhoria de processos em pequenas empresas [SEI 2006]. A COPPE/UFRJ tem trabalhado em consultoria para implementação de melhoria de processos de software nas organizações de software brasileiras por mais de duas décadas. A partir de 2003, a COPPE/UFRJ incluiu em sua estratégia a utilização do ambiente de apoio a processos de engenharia de software TABA configurado para cada empresa, fato determinante para a conquista dos níveis 2 e 3 do CMMI, além dos níveis F, E e D do MR-MPS em diferentes organizações [LENS 2007]. Desde 2003, a equipe da COPPE/UFRJ tem implantado processos de software em grupos de pequenas e médias empresas no Rio de Janeiro organizados pela Riosoft (que integra o Programa Softex). A partir de 2004 o foco destes grupos passou a ser a implantação de processos aderentes ao MR-MPS [Rocha et al. 2005]. Este artigo relata lições aprendidas a partir da experiência de implementação de melhoria de processos em um grupo de empresas visando a obtenção dos níveis G e F do MR-MPS entre 2006 e O grupo de empresas formado pela Riosoft em 2006 foi composto por 7 empresas, sendo que a COPPE/UFRJ atuou como Instituição Implementadora em 5 destas empresas e a Riosoft, em outras 2, que não serão abordadas neste trabalho. A seção 2 apresenta um breve histórico da experiência da COPPE/UFRJ na implementação de processos em pequenas e médias empresas do Rio de Janeiro e é discutida a estratégia de implementação adotada. A seção 3 apresenta as empresas. Na seção 4 são apresentadas as lições aprendidas e na seção 5 as considerações finais. 2. Implementando Processos em Pequenas e Médias Empresas 2.1 Estratégia de Implementação da COPPE A implantação de processos de software em uma organização é fortemente baseada em conhecimento. Para a implantação de uma iniciativa de melhoria, é fundamental que os responsáveis por executar os processos sejam capacitados. Além disso, uma iniciativa de melhoria é normalmente considerada cara por muitas organizações, pois são necessários recursos significativos durante certo período de tempo. Desta forma, torna-se necessário desenvolver estratégias efetivas para implementar processos de software com sucesso. Com o objetivo de apoiar a implementação de iniciativas de implantação e melhoria de processos em organizações de software, foi desenvolvida, na COP- PE/UFRJ, uma estratégia de implementação fortemente baseada em conhecimento [Santos et al. 2007] [Barreto et al. 2006]. Essa estratégia tem demonstrado sua viabilidade e seus benefícios através de muitas avaliações de processo realizadas nos últimos anos. Esta abordagem pode e está sendo aplicada em implementações tanto em empresas individuais quanto nas que participam de algum grupo de empresas. A Figura 1 apresenta esta abordagem, denominada SPI-KM. Durante o passo inicial da estratégia ( Diagnóstico ) é realizada a seleção do modelo de maturidade e o nível pretendido pela organização, além de verificação da 312

315 cultura existente. Depois disso, a iniciativa de melhoria é planejada e um processo de desenvolvimento de software padrão é definido para 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. Plano de Melhoria do Processo de Sofware Relatório de Gap Analysis Lições Aprendidas Processos Padrão Ferramentas da Estação TABA Biblioteca de Ativos de Processo Lições Aprendidas Solicitações de Melhoria Planos de Melhoria Biblioteca de Ativos de Processo Execução de Projetos Diagnóstico Planejamento da Melhoria do Processo de Software Definição do Processo Treinamento Estabelecimento da Infra-estrutura de Apoio Mentoring Acompanhamento Coleta de Recomendações de Melhoria do Processo Avaliação das Recomendações de Melhoria do Processo Cultura e Necessidades Organizacionais e Objetivos de Melhoria do Processo de Software Padrões Internacionais e Modelos de Maturidade Aquisição de Conhecimento Lições Aprendidas Preparação da Organização para a Avaliação Avaliação do Processo Planos de Melhoria Figura 1. SPI-KM - Estratégia de Implementação de Processos da COPPE/UFRJ. Alguns pontos chave desta estratégia são: (i) 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 envolvida na iniciativa de melhoria; (ii) 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 nas atividades do processo definido; (iii) mentoring durante execução dos processos: os consultores da COPPE/UFRJ acompanham cada profissional envolvido na melhoria enquanto este realiza alguma atividade do processo; (iv) 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; (v) apoio ferramental da Estação Taba: permite que as atividades sejam mais facilmente assimiladas e executadas; (vi) 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 no rumo certo. Durante estas reuniões, estratégias de melhoria de processos são definidas para superar dificuldades inerentes à iniciativa de melhoria de processos que podem afetar o seu sucesso, como, por exemplo, resistência a mudanças por parte dos participantes. Para apoiar a execução desta abordagem, são utilizados os ambientes, a infra- 313

316 estrutura e as ferramentas da Estação TABA. A Estação TABA é capaz de gerar ambientes de desenvolvimento de software para apoiar atividades de gerência de projetos, melhoria da qualidade dos produtos e aumento da produtividade [Villela et al. 2004]. Durante os últimos anos, a Estação TABA evoluiu para apoiar atividades de gerência de conhecimento integradas aos processos de software com o objetivo de preservar o conhecimento organizacional e permitir a institucionalização de uma organização de software em contínuo aprendizado[oliveira et al. 2004] [Villela et al. 2004]. Uma das principais ferramentas no que diz respeito à gerência do conhecimento é a ferramenta ACKNOWLEDGE, onde são registradas as diretrizes, lições aprendidas e demais itens de conhecimento, sempre associados a atividades do processo. Essa ferramenta está integrada a todas as ferramentas e ambientes da Estação TABA [Montoni et al. 2004]. 2.2 Lições Aprendidas Durante a Aplicação da Estratégia SPI-KM Lições aprendidas podem facilitar a implantação de processos de software em outras organizações no futuro e, assim, aumentar as chances de sucesso de novas iniciativas de melhoria. Um estudo feito pela COPPE/UFRJ [Santos et al. 2007] identificou problemas comuns à implementação de processos, independente da empresa ou estratégia utilizada. A partir deste estudo foram extraídas 5 lições aprendidas. Naquele momento, várias iniciativas de melhoria de processos sob nossa coordenação estavam em andamento. Após a conclusão destas iniciativas, pôde-se não apenas confirmar a validade e aplicabilidade de tais lições, mas também identificar uma nova e importante lição a- prendida. Estas lições são apresentadas na Tabela 1. Tabela 1. Lições aprendidas pela aplicação da estratégia SPI-KM Título Descrição O foco de um programa de melhoria de processos, que define as estratégias, políticas, atividades e responsabilidades para condução da iniciativa, deve estar vinculado aos objetivos de negócio da organização. Iniciativas de melhoria de processos de software devem efetivamente melhorar os processos de software. Você não terá sucesso sem um líder. Comprometimento é crucial. Sem cérebro, sem ganhos. A melhoria de processos de software é facilitada pela infra-estrutura de processos de software. A descentralização do conhecimento sobre a implementação de processos de software é fundamental A melhoria de processos de software implica na adoção de novas práticas pela organização. Muitas barreiras são encontradas durante as iniciativas de melhoria, como por exemplo, políticas organizacionais, falta de apoio e recursos, falta de conhecimento e pressões de cronograma [Niazi et al. 2005]. Neste contexto, é muito importante contar com pessoas capazes de motivar, sensibilizar e orientar os membros da organização na realização de ações que permitam superar essas e outras dificuldades. Sem o comprometimento de todos os níveis organizacionais, os objetivos de melhoria dificilmente serão alcançados [Abrahamsson et al. 2001]. Dessa forma, as pessoas envolvidas com as iniciativas de melhoria devem perceber os benefícios derivados da melhoria e não somente seus custos. O desenvolvimento de software é uma atividade intensiva em conhecimento [Ye 2006], portanto, os resultados obtidos estão diretamente relacionados com o conhecimento e a habilidade dos colaboradores da organização. A maior parte das organizações com processos de software de baixa maturidade não possui infra-estrutura adequada para as iniciativas de melhoria. Zaharan (1998) define 2 tipos de infra-estrutura de apoio a atividades relacionada a processos e para sustentar ações de melhoria: (i) organizacional e gerencial, e (ii) técnica. A implementação de melhoria de processos é um projeto de longo prazo, dessa forma, também pode ser afetada pela rotatividade de pessoal. Para reduzir este e outros riscos relacionados às iniciativas de melhoria dentro de uma organização é fundamental que o conhecimento sobre a implemen- 314

317 para sustentar as iniciativas de melhoria de processos de software. 3. As Empresas do Grupo tação seja descentralizado. Dessa forma, mais pessoas na empresa serão capazes de disseminar as melhorias e, também, o apoio e o comprometimento dos colaboradores com os processos de software será maior. Nas cinco empresas do grupo Qualisoft 2006, todas localizadas na cidade do Rio de Janeiro, a estratégia de implementação utilizada foi a mesma, respeitando-se porém as características, experiência e maturidade de cada empresa. A Organização #1 é dedicada a fornecer soluções em sistemas para o mercado financeiro na área de investimentos. O objetivo de seu programa de melhoria de processos de software é aumentar a qualidade dos produtos, melhorar o controle dos projetos e diminuir os custos de produção e manutenção dos sistemas. A empresa já havia participado de outro esforço de melhoria que, apesar de não ter resultado em uma avaliação, trouxe maturidade para a organização em relação a conhecimento sobre processo e definição de objetivos de melhoria. O apoio da alta e média gerência, assim como dos colaboradores envolvidos nos projetos, é visível e sempre esteve presente. A empresa possui um grupo de processos atuante e qualificado para dar apoio aos projetos, que colaborou na definição de um processo bem adequado à realidade da empresa. A Organização #2 é especializada em prestação de serviços de informática, atuando na área de desenvolvimento de sistemas e processos customizados ao cliente e desenvolvimento de produtos próprios, para venda e uso interno. O objetivo do programa de melhoria de processos de software da empresa é aumentar a qualidade dos produtos e diminuir os custos de desenvolvimento. Os membros da organização envolvidos com o programa de melhoria bem como a alta gerência apóiam integralmente a iniciativa e observam resultados positivos. A Organização #3 fornece serviços em Business Intelligence, portais corporativos e soluções de sistemas de informação e gestão do conhecimento. A empresa estabeleceu como objetivo de qualidade o aprimoramento de seus processos e técnicas de desenvolvimento de software para aumentar a qualidade de seus produtos e diminuir o retrabalho existente. Os envolvidos e a alta gerência apóiam fortemente a iniciativa de melhoria e alegam que o programa, além de ser uma necessidade para aumentar a competitividade no mercado atual, representa uma questão de sobrevivência para a empresa. A organização trabalhou, paralelamente, na implantação da norma ISO 9001:2000. A Organização #4 é especializada no desenvolvimento e comercialização de pacotes de soluções, principalmente para os ramos da saúde, educação e finanças. O principal objetivo do programa de melhoria de processos de software da empresa é aumentar a qualidade dos produtos e diminuir o esforço de manutenção, devido à longa vida útil e adaptabilidade de seus produtos. Desde o início todos os envolvidos na implementação dos processos e a alta gerência da empresa apóiam a iniciativa e os resultados já são percebidos. A Organização #5 fornece serviços de desenvolvimento de software, integração de soluções, outsorcing de TI e modelagem de negócios. Tem como principal objetivo para o programa de melhoria de processos de software, melhorar a gerência dos projetos a fim de aumentar o controle de prazo, custo e esforço no desenvolvimento de software 315

318 e diminuir o retrabalho. A empresa apóia o programa de melhoria. Existe uma participação ativa da direção e da gerência que demonstra acreditar nos benefícios da implementação dos processos do MR-MPS. A Tabela 2 apresenta o nível desejado por cada empresa e o estágio atual de implantação dos processos. A Organização #2 já tinha participado de treinamento teórico no Qualisoft 2005 e por isso não participou do treinamento neste grupo. A Organização #4 optou por não ter treinamento teórico, no entanto, conceitos teóricos foram sendo introduzidos durante o acompanhamento nos projetos. A Organização #1 e a Organização #2 adaptaram a definição do processo segundo suas necessidades e isso aumentou o tempo da definição e configuração do Taba. Tabela 2. Caracterização e Estágio Atual das Organizações Organização #1 Organização #2 Organização #3 Organização #4 Organização #5 Nível MR-MPS F G G F G Início do Projeto Jul/2006 Jul/2006 Jul/2006 Jan/2007 Jul/2006 Definição do Processo e Configuração TABA Ago-Set/2006 Ago-Nov/2006 Jul/2006 Jan/2007 Jul/2006 Treinamento Teórico Set/ Jul/ Ago/2006 Início da Implantação Set/2006 Nov/2006 Ago/2006 Jan/2007 Ago/ % da Implantação Jul/2007 Mai/2007 Jan/2007 Jun/2007 Jun/2007 Avaliação Inicial (MA-MPS) Ago/2007 Mai/2007 Abr/2007 Ago-Set/2007 Set/2007 Avaliação Final (MA-MPS) Out/2007 Jun/2007 Mai/2007 Out/2007 Set/2007 Tempo total para a avaliação final a partir do início da implementação na empresa 15 meses 12 meses 11 meses 10 meses 14 meses 4. Lições Aprendidas Durante a implementação do programa de melhoria nestas empresas foram utilizadas as lições aprendidas durante a aplicação da abordagem SPI-KM (apresentada na seção 2) de forma a reduzir os riscos inerentes às iniciativas de melhoria de processos de software conduzidas sob nossa coordenação. Durante a execução destas iniciativas de melhoria, utilizando a estratégia SPI-KM, neste grupo de empresas também foi possível coletar outro conjunto de lições aprendidas. Estes dois conjuntos de lições não são concorrentes, mas sim complementares. A Tabela 3 apresenta lições aprendidas que podem ser úteis na definição de um plano estratégico para melhoria de processos de software. Tabela 3. Lições aprendidas # Lição aprendida A presença constante dos consultores favorece a conscientização das vantagens e dos benefícios da 1 implantação do programa de melhoria na organização. Entretanto isso só ocorre se os consultores também atuam visando a melhoria efetiva da organização e não apenas o sucesso da avaliação. Empresas que nunca seguiram um processo têm muita dificuldade para definir um, portanto, é importante que a consultoria defina uma versão inicial do processo a ser executado. Com a utilização deste 2 processo em um projeto a empresa passa a ter o conhecimento necessário para apoiar a definição de uma nova versão mais adequada à sua realidade. Além disso, as organizações aprendem bastante e ficam mais comprometidas com o programa de melhoria e com a aderência do processo aos projetos. 3 O primeiro projeto a utilizar o processo definido normalmente apresenta dificuldades, pois a equipe 316

319 está se adaptando às novas atividades e ferramentas que exigem uma mudança na forma como os projetos são conduzidos. Em alguns casos este projeto é encarado como um piloto para a implantação do processo e não é incluído no conjunto de projetos a fazerem parte da avaliação oficial do MPS.BR. Um importante ponto a ser considerado é a obtenção de comprometimento ao longo do projeto, pois nem sempre as empresas estão habituadas a registrar este comprometimento tanto interna como externamente. Pode haver resistências, principalmente do cliente, em relação ao estabelecimento for- 4 mal de comprometimento. Apoio ferramental adequado facilita o treinamento, desenvolvimento e institucionalização dos processos, ajudando a reduzir o tempo de implementação dos processos. Quando a organização já utiliza ferramentas adequadas para apoiar as atividades do processo, a resistência a mudanças diminui, fazendo com que a implementação não tenha impacto na curva de aprendizado de novas ferramentas. 5 No que tange o uso da Estação TABA, ainda que no futuro a empresa opte por outras ferramentas que considere mais adequadas à sua realidade, é importante o contato com a Estação Taba para sedimentar os novos conceitos e ajudar na definição dos requisitos para outras ferramentas que se deseje utilizar. A estratégia baseada na implantação gradativa de processos aderentes ao MR-MPS é adequada, pois 6 a organização percebe, aos poucos, os benefícios de disciplinar o desenvolvimento com base em processos. Empresas pequenas que pretendem implantar o nível G do MR-MPS, geralmente possuem recursos financeiros limitados, ocasionando problemas para o programa de melhoria. Quanto mais rápido os processos forem institucionalizados nestas empresas, menores serão os riscos de estes não serem 7 seguidos, pois nestas empresas, geralmente, surgem problemas que podem impactar no andamento da implementação. Partir de uma versão inicial e adaptá-la à empresa acelera esta implantação e institucionalização. Quando os membros responsáveis pela execução dos processos na organização possuem conhecimento em engenharia de software há uma demanda menor por acompanhamento da consultoria e a im- 8 plementação dos processos é agilizada, reduzindo, também os custos de implementação. Com o maior controle, tanto gerencial como dos requisitos, que inicia desde o nível G, as empresas 9 conseguem negociar novos prazos e custos com os clientes, principalmente quando ocorrem mudanças de requisitos, demonstrando quantitativamente o impacto das mudanças para o projeto. 5. Considerações Finais Este artigo discutiu a implementação do MR-MPS num grupo de pequenas e médias empresas do Rio de Janeiro. Foram apresentadas as principais características destas empresas, incluindo seus objetivos para o programa de melhoria de processos, caracterização e estágio da 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 a obtenção dos níveis G e F do MR-MPS.. Todas as empresas foram avaliadas e obtiveram os níveis pretendidos, o que comprova o sucesso da abordagem. Atualmente a Organização #4 definiu uma nova versão dos processos para atender toda a organização, englobando projetos de customização, integração e migração, além dos projetos de desenvolvimento. A Organização #3 definiu processos adequados ao Nível E do MPS visando uma avaliação ainda em Um projeto já foi iniciado seguindo este novo processo, os grupos de processos foram definidos com recursos da organização com apoio da consultoria. A Organização #5 continua usando os processos em projetos grandes e estuda adaptações para projetos pequenos. Além disso, está começando os preparativos para uma avaliação no Nível E do MPS em A Organização #1, também, continua seu esforço de melhoria em direção ao nível E do MPS. As lições aprendidas relatadas neste trabalho são importantes ativos que atuam 317

320 na retroalimentação e refinamento da estratégia adotada pela COPPE/UFRJ. Da mesma forma, espera-se que estes ativos também 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, a Márcio Pecegueiro do Amaral e à equipe de desenvolvimento da Estação TABA. Referências Abrahamsson, P. (2001), Commitment Development in Software Process Improvement: Critical Misconceptions, In: Proc. of the 23rd Int. Conf. on Sof. Eng., pp 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. LENS Laboratório de Engenharia de Software da COPPE/UFRJ (2007) < Montoni, M., Santos, G., Villela, K., Miranda, R., Rocha, A.R., Travassos, G.H., Figueiredo, S., Mafra, S.: Knowledge Management in an Enterprise-Oriented Software Development Environment. In.: Lecture Notes of Computer Science (LNCS), ISBN , pp , presented at the 5th Int. Conf of Practical Aspects of Knowledge Management, Vienna, Austria, (2004) Niazi, M., Wilson, D., Zowghi, D. (2005), A framework for assisting the design of effective software process improvement implementation strategies, In: J. of Systems and Software, v.78, n.2, pp Oliveira, K, Zlot, F., Rocha, A. R., Travassos, G., Galotta, C., Menezes, C. (2004), Domain Oriented Software Development Environment, Journal of Systems and Software, vol 72/2 pp Rocha, A. R., Montoni, M., Santos, G., Mafra, S., Figueiredo, S., Bessa, A., Mian, P. (2005) Estação TABA: Uma Infra-estrutura para Implantação do Modelo de Referência para Melhoria de Processo de Software, IV Simpósio Brasileiro de Qualidade de Software, SBQS'05, Porto Alegre, Brasil. 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, 8 th International Conference on Product Focused Software Process Improvement (PROFES 2007), Latvia. SEI Software Engineering Institute (2006) Improving Processes in Small Settings (IPSS) A White Paper, The International Process Research Consortium (IPRC), Software Engineering Institute, Pittsburgh. Softex, MPS.BR Melhoria de Processo do Software Brasileiro, Guia Geral (v. 1.1). Sociedade Softex, Brasil. (2006) Thiry, M., von Wangenheim, C. G., Zoucas, A., Pickler, K., Uma Abordagem para a Modelagem Colaborativa de Processos de Software em Micro e Pequenas Empresas, V SBQS'2006, Vila Velha, ES, Brasil. Villela, K., Santos, G., Montoni, M., Berger, P., Figueiredo, S, M., Mafra, S, N., Rocha, A, R, C., Travassos, G, H. (2004) Definição de Processos em Ambientes de 318

321 Desenvolvimento de Software Orientados a Organização, III SBQS, Brasília-DF. Ye, Y. (2006), Supporting software development as knowledge-intensive and collaborative activity, Proceedings of the 2006 International Workshop on Interdisciplinary Software Engineering Research, pp , Changai, China Zaharan, S. (1998), Software Process Improvement Practical Guidelines for Business Success, Addison-Wesley. 319

322 Aplicação dos Gráficos de Controle CUSUM Tabular para Avaliação da Aderência dos Projetos ao Processo de Software Paula Moreira 1, Lenilda Pinheiro 1, Jaciane Ribeiro 2, Cleidson de Souza 1, Rodrigo Quites 1 1 Programa de Pós-Graduação em Ciência da Computação (PPGCC-UFPA) Belém, PA Brasil 2 Programa de Pós-Graduação em Matemática e Estatística (PPGME-UFPA) Belém, PA Brasil {pdanni,jacianedocarmo,lenilda}@gmail.com, cdesouza@ufpa.br, quites@computer.org Abstract. This paper describes the experience of the authors in the usage of the technique CUSUM (Cumulative Sum) control charts to quantitatively evaluate software processes in a Level-2 CMM-SW certified Brazilian software development organization. This technique is used to evaluate to which extent the actual software processes of this organization match the prescribed software process. Resumo. Este artigo descreve o uso do gráfico de controle CUSUM Tabular para avaliar quantitativamente a aderência dos projetos de software ao modelo de processo definido em uma organização de desenvolvimento de software certificada CMM-SW nível 2. Esta técnica é utilizada para avaliar aderência dos projetos ao processo de desenvolvimento de software. 1. Introdução Em desenvolvimento de software, a qualidade pode ser entendida como um conjunto de características a serem satisfeitas de modo que o software atenda as necessidades explícitas e implícitas de seus usuários. Para avaliar a qualidade de um produto é necessário gerenciá-lo quantitativamente para obter medidas que quantifiquem o grau de uma característica da qualidade, sendo também necessária a utilização de um mecanismo para coleta e análise dessas medidas. Entretanto, a qualidade do produto depende fortemente da qualidade de seu processo de desenvolvimento (Fuggetta, 2000). Justamente por isso surgiram os modelos para avaliação dos processos de desenvolvimento de software. Estes estabelecem um conjunto de "melhores práticas" a serem seguidas para gerenciar o processo de desenvolvimento. Tais modelos surgiram a partir do sucesso de modelos de avaliação de processos propostos para indústria de manufatura. Dentre os principais modelos de avaliação de processo de software, destacam-se o CMMI (Chrissis et al, 2003) e o MPS.Br (SOFTEX, 2008). Apesar dos recentes esforços das organizações brasileiras para adotar modelos de maturidade de processo de software, o que se observa hoje na maioria dessas organizações é uma grande quantidade de dados coletados sobre o processo, mas que 321

323 não são utilizados para acompanhar o seu desempenho. Desta forma, não é possível determinar se os objetivos pretendidos pela organização estão sendo alcançados e se o processo de desenvolvimento é capaz de alcançá-los (Chrissis et al. 2003). Para dificultar ainda mais este quadro, os modelos de maturidade de processos de software, em seus níveis mais altos, exigem que o processo esteja sob controle estatístico, ou seja, que algum método estatístico seja utilizado para gerenciá-lo. Segundo Ramos (2003), um método estatístico eficiente para acompanhar o desempenho de processos é o Controle Estatístico de Processo, ou simplesmente CEP, uma metodologia que envolve sete ferramentas estatísticas: Estratificação, Folha de Verificação, Diagrama de Ishikawa, Gráfico de Pareto, Histograma, Diagrama de Correlação e Gráficos de Controle. Dentre essas ferramentas, as mais difundidas e fáceis de interpretar são os gráficos de controle. Existem diferentes tipos de gráficos de controle que podem ser aplicados a processos, todavia, para engenharia de software, esses métodos são considerados relativamente inexplorados (Card, 2004). Pesquisadores como Cerdeiral et al (2007) e Florac (2000) têm testado a utilização de CEP em processos de software obtendo resultados bastante positivos. Entretanto, estes autores utilizam apenas os gráficos de controle de Shewhart para observações individuais (XmR), para quantidade de não conformidades (gráfico u) ou para o gráfico das médias amostrais (X-bar). Estes gráficos têm baixa capacidade de detectar pequenas variações no processo (Montgomery, 2004) (Costa et al., 2005). Seguramente, melhorar o desempenho destes gráficos e/ou propor novas metodologias de construção e utilização dos mesmos, tornou-se um desafio para os pesquisadores e usuários do controle estatístico. Um problema comum identificado na utilização de gráficos de controle de Shewhart é o baixo poder que estes apresentam em detectar pequenas mudanças na característica de qualidade monitorada. Uma solução proposta para este problema é a utilização dos gráficos de controle CUSUM (Soma Acumulada) e/ou EWMA (Médias Móveis Ponderadas Exponencialmente), que são melhores em detectar pequenas mudanças no processo (Ramos, 2003), (Montgomery, 2004) (Costa et al., 2005). Dessa maneira, o objetivo deste trabalho é apresentar uma aplicação dos gráficos de controle CUSUM Tabular que permitem avaliar quantitativamente a estabilidade dos processos de desenvolvimento de software e que possam auxiliar a alta gerência na tomada de decisão. O artigo descreve a experiência dos autores ao aplicar os gráficos de controle CUSUM Tabular em uma organização de desenvolvimento de software federal certificada CMM- SW nível 2, a regional Belém do SERPRO Serviço Federal de Processamento de Dados. O restante deste artigo está organizado como segue. A Seção 2 discorre brevemente sobre a área Garantia da Qualidade de Processo e Produto do CMMI (Capability Maturity Model Integration), enquanto que a Seção 3 descreve a metodologia Controle Estatístico de Processo. A Seção 4 apresenta o Estudo de Caso e a utilização do gráfico de controle CUSUM Tabular, enquanto que a Seção 5 descreve a análise e os resultados obtidos. Finalmente, a Seção 6 apresenta a conclusão do artigo e os trabalhos futuros vislumbrados. 322

324 2. Garantia da Qualidade do Processo e Produto Segundo Montoni (2006), a utilização dos resultados da área de processo da Garantia da Qualidade do Processo e Produto de Software tem sido cada vez mais adotada pela alta gerência das organizações. Os objetivos desta utilização são obter visibilidade quanto à qualidade dos processos executados e dos produtos de software entregues ao cliente, além de apoiar a tomada de decisões estratégicas do negócio. Para garantir a correção dos resultados gerados por seus processos de negócios, algumas organizações baseiam-se nos modelos de maturidade de capacitação de referência internacional, tal como o CMMI, para definir seus processos. Neste modelo, existe a área de processo chamada Garantia da Qualidade de Processo e Produto cuja finalidade é fornecer à equipe e à gerência um entendimento objetivo dos processos e seus produtos de trabalho associados. Uma das metas desta área é avaliar quantitativamente os processos e produtos da organização. Tal avaliação é feita a partir de revisões que avaliam a aderência dos projetos de software às descrições de processo, padrões e procedimentos. Durante as quais, todos os artefatos elaborados são inspecionados por consultores da equipe de Garantia da Qualidade de Software (GQS) de acordo com checklists e experiência dos revisores designados para esta atividade. Os resultados das revisões podem revelar a presença de não conformidades nos artefatos. A metodologia utilizada para acompanhar o desempenho de processos de desenvolvimento de software será detalhada na seção a seguir. 3. Controle Estatístico de Processo Para Montgomery (2004) o controle estatístico de processos é uma poderosa coleção de ferramentas utilizada para resolução de problemas úteis na obtenção da estabilidade do processo e na melhoria da sua capacidade por meio da redução de sua variabilidade. CEP é uma metodologia utilizada para avaliar se um processo encontra-se sob controle estatístico, ou seja, se ele possui desempenho, custo e qualidade previsíveis, além de auxiliar na melhoria contínua da qualidade e do desempenho do processo gerenciado (Florac, 1999). Quando o processo não se encontra estável, devem-se estudar os pontos fora dos limites para determinar se as causas para tal fato são causas atribuíveis (especiais) ou causas comuns. As causas comuns traduzem as variações normais que ocorrem continuamente em qualquer processo, e são geradas pela interação entre os componentes do processo (pessoas, máquinas, ambiente, material, ambientes e métodos) sendo que são difíceis de ser controladas (Florac, 1999). As causas atribuíveis, entretanto, são geradas por alguma situação ou ação que pode justificar a variação ocorrida, sendo que tais causas podem ser controladas (Florac, 1999). Dentre as ferramentas utilizadas no CEP, os gráficos de controle são mais utilizados devido à facilidade da sua aplicação e interpretação dos resultados. Desta forma, a seção a seguir detalha os gráficos de controle, identificando as características dessa ferramenta e enfatizando o tipo de gráfico de controle que será aplicado neste estudo Gráficos de Controle 323

325 Os gráficos de controle são definidos a partir de estatísticas (como a média, o desvio padrão amostral, etc.) e baseiam-se em certas distribuições de probabilidade, principalmente na distribuição normal. O gráfico de controle idealizado por Shewhart (Bravo, 1995) consiste simplesmente em três linhas paralelas: uma linha central, que reflete o nível de operação do processo, e duas linhas externas denominadas limite superior de controle (LSC) e limite inferior de controle (LIC). Os limites de controle são estabelecidos por três desvios-padrão (σ), fazendo com que a probabilidade de um ponto estar dentro dos limites seja 99,74%. Assim, no estado de estabilidade, a probabilidade de um ponto situar-se fora dos limites de controle torna-se muito pequena (Montgomery, 2004). Quando há pontos além dos limites inferior e superior, considera-se o processo como instável, ou fora de controle estatístico, ou imprevisível. Fatos estes explicados pela presença de causas atribuíveis que atuam sobre o processo e que ocorrem de forma independente e sem controle. Todavia, quando todos os pontos estão distribuídos aleatoriamente, entre os limites inferior e superior, diz-se que o processo está estável, ou sob controle estatístico, ou ele é previsível. Assim, as variações se devem apenas por causas comuns. Por conseguinte, existem várias regras que explicam o comportamento do processo, que vão além da ocorrência de um valor excedendo os limites de controle Gráfico de Controle CUSUM Tabular Segundo Bravo (1995), o gráfico de controle de somas acumuladas indica rapidamente a ocorrência de pequenas mudanças em um processo. Além disso, o gráfico de controle de somas acumuladas não está restrito a controle estatístico de processos, uma vez que eles podem ser usados para monitorar, por exemplo, o consumo de combustível em veículos de transporte, a resposta de pacientes a um tratamento médico ou o desempenho de um sistema de previsão. Os gráficos CUSUM têm como principal característica detectar pequenas mudanças na distribuição da característica de qualidade e são aplicados tanto para observações individuais (n = 1) quanto para as médias das observações amostrais. No gráfico CUSUM, à medida que as amostras são retiradas, os desvios de X i em relação ao valor da média (µ 0 ) são acumulados, gerando a soma acumulada C i, para o i-ésimo período, dada por: n C = ( X µ ) = ( X µ ) + C i i 0 i 0 i 1 i= 1 Os gráficos CUSUM não são considerados gráficos de controle por não apresentarem os limites de controle. Dentre as várias maneiras de representar os CUSUM s, destaca-se o gráfico CUSUM Tabular, o qual é considerado um gráfico de controle, pois estabelece seu limite de controle igual a H e supõe que os dados coletados seguem distribuição normal com média µ e desvio padrão σ. O gráfico de controle CUSUM Tabular utiliza as estatísticas C + i (detecta mudanças positivas) e C - i (detecta mudanças negativas) denominadas de CUSUM s unilaterais superior e inferior, respectivamente, e ambas são calculadas a partir das equações abaixo: C = max[0, X ( µ + K) + C ] + + i i 0 i 1 e i 0 i i C = max[0,( µ K ) X + C ]

326 onde os valores iniciais C + 0 e C - 0 são iguais a zero; X i é a i-ésima observação amostral; 1 0 µ 0 é o valor da média e K = µ µ / 2 está relacionado à magnitude de mudança que se deseja detectar com o gráfico de controle de CUSUM. Como, observa-se, também, que C + i e C - i acumulam desvios em relação a µ 0 e são igualados a zero quando se tornam negativos. O intervalo de decisão ou limite de controle utilizado no gráfico de controle CUSUM Tabular é H. Se o valor de C + i ou C - i exceder esse intervalo, pode-se dizer que o processo encontra-se fora de controle estatístico, logo, é preciso encontrar as causas atribuíveis que levaram o processo a tal estado e estimar seu valor médio para que se possa fazer o ajuste adequado (Alves, 2003). Geralmente, utiliza-se um valor para H igual a cinco vezes o desvio padrão do processo (H = 5σ). Portanto, no algoritmo do gráfico de controle CUSUM Tabular, existem os contadores denominados N + i e N - i que indicam o número de períodos consecutivos em que os CUSUM s C + i e C - i assumem o valor zero. Costa et al. (2005) afirmam que esses indicadores são muito úteis para indicar o momento em que a média do processo alterou, sendo importante para auxiliar no diagnóstico dessa alteração. Para determinar o momento estimado da mudança, devese subtrair N + i ou N - i do número da observação que sinalizou um estado fora de controle estatístico. 4. Estudo de Caso A aplicação deste estudo de caso aconteceu em um pólo de desenvolvimento de software do SERPRO Serviço Federal de Processamento de Dados uma empresa pública de tecnologia da informação. Tal pólo foi certificado CMM-SW (Capability Maturity Model) nível 2 em dezembro de 2006 e possui três equipes com cerca de doze desenvolvedores cada. As amostras coletadas e utilizadas neste estudo referem-se às quantidades de não conformidades apontadas nos resultados de 128 revisões da Garantia da Qualidade de Software realizadas no pólo da Regional Belém no período de janeiro de 2005 a Fevereiro de 2008, ou seja, 38 observações normalmente distribuídas. Foram selecionados para a coleta 26 projetos de software de alta complexidade com esforço a partir de 150 homens-dia. Os períodos das coletas correspondem a três etapas de maturidades do pólo de software: a primeira de janeiro a dezembro de 2005 onde ocorreram estudos, treinamentos e disseminação do CMM-SW nível 2; a segunda etapa, de janeiro a dezembro de 2006, período onde ocorreram as avaliações corporativas do nível de maturidade do processo e a terceira etapa de janeiro de 2007 a fevereiro de 2008, período posterior a certificação CMM-SW nível 2. As quantidades de não conformidades são apontadas durante as revisões GQS, cujo objetivo é inspecionar o nível de aderência dos artefatos elaborados/atualizados durante a execução dos projetos de software ao Processo Serpro de Desenvolvimento de Soluções (PSDS), um modelo de processo institucionalizado na organização. Para que as revisões sejam realizadas, um Plano de GQS é elaborado pelo consultor GQS designado, no qual são planejadas todas as revisões GQS até o encerramento do projeto e o mesmo é elaborado baseando-se no plano de projeto, planejamento de esforço, custo, prazo e cronograma do projeto. Todas as revisões dos artefatos de software são cadastradas em um sistema chamado Revisa. Este sistema é responsável pelo agendamento das revisões e notificações das partes interessadas, além 325

327 de permitir o armazenamento dos resultados das revisões, acompanhamento das correções das não conformidades e disponibilização de relatórios e consultas gerenciais. As revisões previstas são realizadas mensalmente. As não conformidades encontradas são reportadas às equipes para correção e tomada de ação para melhoria da aderência do projeto ao processo. A partir da coleta das quantidades de não conformidades armazenadas no sistema Revisa aplicou-se o gráfico de controle CUSUM Tabular para observações individuais visando acompanhar se os projetos de software estão aderentes ao processo definido pela organização. A Figura 1 apresenta as estatísticas CUSUM Superior (C+i) e CUSUM Inferior (C-i) para a quantidade de não conformidades apontadas nos resultados das revisões GQS no período de janeiro de 2005 a fevereiro de O limite superior H igual a 5σ foi considerado, pois este é um valor condizente com a literatura da área. Como o valor do desvio padrão foi 6,25, o valor do limite superior H foi 31,25. Observa-se que com relação aos valores C + i, que a observação referente ao mês de maio de 2006 (observação 17), encontra-se acima do limite superior de controle (LSC=31,25), com N + i =17 (17-17 = 0). Com isso, estima-se que o aumento das não conformidades inicia desde janeiro de 2005 (observação 1), pois a subtração do número da observação que sinalizou o aumento de N + i indica o momento estimado da mudança. Isso é importante para que as causas atribuíveis sejam identificadas e a organização possa tomar decisões baseada não somente nos fatos ocorridos no período em que a observação referente ao mês de maio de 2006 excedeu os limites, mas que uma análise mais detalhada possa ser realizada, a partir do período de início da variação. Com relação aos valores do CUSUM Inferior (C - i), observa-se que a partir da observação referente ao mês de junho de 2007 (observação 30) a quantidade de não conformidades nas revisões GQS encontra-se acima do limite superior de controle, com N - i = 13 (30-13= 17). Logo, estima-se que essa redução inicia entre maio de 2006 (observação 17) e junho de 2006 (observação 18), pois a subtração do número da observação que sinalizou a diminuição de N - i indica o momento estimado da mudança. 60,00 50,00 40,00 Ci 30,00 H=LSC=31,25 20,00 10,00 0,00 jan/05 fev/05 mar/05 abr/05 mai/05 jun/05 jul/05 ago/05 set/05 out/05 nov/05 dez/05 jan/06 fev/06 mar/06 abr/06 mai/06 jun/06 jul/06 ago/06 set/06 out/06 nov/06 dez/06 jan/07 fev/07 mar/07 abr/07 mai/07 jun/07 jul/07 ago/07 set/07 out/07 nov/07 dez/07 jan/08 fev/08 Ci+ (aumento) Ci-(redução) Figura 1. Gráfico de Controle CUSUM Tabular para a quantidade de Não Conformidades Apontadas nos Resultados das Revisões GQS no Período de janeiro de 2005 a fevereiro de

328 5. Análise e Interpretação dos Resultados A partir do gráfico de controle CUSUM Tabular, observa-se um aumento na quantidade de não conformidades de janeiro de 2005 a maio de Entrevistas com os envolvidos na gerência das equipes de GQS foram realizadas e constatou-se que uma possível razão para o aumento na quantidade de não conformidades nesse período foi que a equipe de desenvolvimento estava em fase de aprendizado, portanto, os artefatos não eram bem elaborados/atualizados. Além disso, novas pessoas foram admitidas na organização, o que conseqüentemente trouxe dificuldade para os novos integrantes em seguir o processo de desenvolvimento utilizado pela empresa. Assim como os revisores adquiriam mais experiência a partir das medidas adotadas pela organização para melhorar a revisão (treinamentos, mentorias, etc.), os desenvolvedores e líderes de projetos também evoluíram na elaboração/atualização dos artefatos, uma vez que a organização estava investindo na certificação, o que motivou os desenvolvedores e gerentes a seguirem o processo definido. Com estas medidas, a quantidade de não conformidades diminuiu e a partir do gráfico CUSUM Tabular, observa-se que essa diminuição começa entre os meses de maio e junho de Uma observação importante foi que os projetos tiveram um aumento da aderência ao processo definido, já que a quantidade de não conformidades diminuiu. Em Dezembro de 2006, a organização conseguiu a certificação CMM-SW nível 2, quando a avaliação foi realizada, acreditava-se que os projetos estavam sendo seguidos de acordo com o estabelecido no processo, contudo, não se tinha uma forma de confirmar tal fato. Com a utilização da abordagem sugerida pôde-se perceber que a certificação poderia ter sido alcançada antes do período, pois desde junho de 2006 os projetos estavam mais aderentes ao processo. 6. Conclusão Este trabalho está alinhado com a noção do uso de técnicas estatísticas baseadas em controle de processo para avaliação e melhoria da qualidade de software. Deve-se ressaltar que a adoção destas técnicas tem crescido recentemente (Silva, 2005). O trabalho aqui apresentado trouxe resultados significativos, e destaca-se por permitir que a organização estabeleça ações corretivas ou adaptativas, a partir dos problemas identificados pelo gráfico de controle e, também, acompanhar se estas ações asseguraram melhores resultados à aderência do processo definido. Vale ressaltar que a os gráficos de controle padrões de Shewhart não conseguem mostrar desde quando o processo está fora de controle, o que dificulta as análises das possíveis causas de variação no processo. Além disso, a aplicação do CEP nas fases iniciais de definição dos processos de software tem o objetivo de identificar precocemente quais áreas do processo podem ser melhoradas, além de proporcionar a possibilidade de acompanhar estatisticamente o processo em suas fases iniciais, o que é uma das exigências estabelecidas pelos modelos de avaliação de processo em seus níveis mais altos. Alguns aspectos podem ser observados como trabalhos futuros, tais como: aplicação da técnica em outras áreas do processo, como o teste de software para que se consiga acompanhar o desempenho desta atividade e se possa encontrar problemas e procurar soluções para os mesmos e que as lições aprendidas pela empresa possam ser 327

329 compartilhadas. O nível de aderência ao processo pode ser medido também pelo índice de capacidade do processo (IC) que é utilizado quando os gráficos estão sob controle estatístico, ou seja, quando nenhuma causa atribuível ocorre. Em outras palavras, o IC ajuda a mensurar a capacidade do processo. De um modo geral, nos trabalhos futuros pretende-se utilizar os gráficos de controle com dois objetivos: monitorar o desempenho do processo na busca de causas de instabilidade e, caso o processo esteja sob controle, avaliar a capacidade do processo para verificar se as necessidades da organização foram alcançadas. Agradecimentos Ao SERPRO, por autorizar a publicação dos dados e resultados do estudo realizado. Referências Alves, Custódio C. Gráficos de Controle CUSUM: um enfoque dinâmico para a análise estatística de processos Dissertação (Mestrado em Engenharia de Produção) PPGEP/UFSC, Florianópolis, Santa Catarina, Brasil. Bravo, P. C. Controle Estatístico da Qualidade, In: 40a Reunião Anual da Região Brasileira da Sociedade Internacional de Biometria (RBRAS), Ribeirão Preto - São Paulo, 18-21/07/1995. Anais da 40ª RBRAS e 6º SEAGRO, Ribeirão Preto, Card, D.N. Statistical Techniques for Software Engineering Practice. Software Productivity Consortium. Proceedings of the 26th International Conference on Software Engineering, Cerdeiral, C., Figueiredo, S., Santos, G. Montoni, M. Pinto, R. Rocha, A. C. Uma Abordagem para Controle Estatístico do Processo e Gerência Quantitativa de Projetos. Simpósio Brasileiro de Qualidade de Software (SBQS), Chrissis, M. B., Konrad, M., Shrum, S. CMMI: Guidelines for Process Integration and Product Improvement, Addison Wesley, Costa, A. F.; Epprecht, E. K.; Carpinetti, L. C. R. Controle Estatístico de Qualidade. Atlas, 2005, 2a Edição. Florac, A. W., C., Barnard, A. D. Measuring the Software Process: Statistical Process Control for Software Process Improvement. Addison Wesley, Florac, A.W., C., Barnard, A.D.,, J.R. Statistical Process Control: Analyzing a Space Shuttle Onboard Software Process, IEEE Software, pp , Fuggetta, A. Software Processes: A Roadmap. Future of Software Engineering, Limerick, Ireland, Montgomery, D. Introdução ao Controle Estatístico da Qualidade. 4a. Ed. Rio de Janeiro: LTC, Montoni, M., Santos, G., Figueiredo, S., Cabral, R., Barcelos, R., Barreto, A., Barreto, A., Cerdeiral, C., Lupo, P., Rocha, A. R.. Uma Abordagem de Garantia de Qualidade de Processos e Produtos de Software com Apoio de Gerência de 328

330 Conhecimento na Estação TABA. V Simpósio Brasileiro de Qualidade de Software (SBQS'06). Vila Velha, Brasil, Ramos, E. M. L. S. Aperfeiçoamento e Desenvolvimento de Ferramentas do Controle Estatístico da Qualidade utilizando Quartis para estimar o Desvio Padrão. Tese de Doutorado, Universidade Federal de Santa Catarina, Abril, Silva, R. C. F., Rocha, A. R. C., Travassos, G. H. Uma Abordagem Experimental para a Avaliação da Melhoria de Processos. IV Simpósio Brasileiro de Qualidade de Software (SBQS'05). Porto Alegre, Brasil, SOFTEX - Associação para Promoção da Excelência do Software Brasileiro. MPS.BR - Guia Geral, v1.2, Disponível em 329

331 330

332 Avaliação de um Método para Estimativa de Esforço para Testes baseado em Casos de Uso Érika R. C. de Almeida 1, Bruno T. de Abreu 1, Regina Moraes 2, Eliane Martins 1 1 Instituto de Computação Universidade Estadual de Campinas (Unicamp) Caixa Postal Campinas SP Brasil 2 Centro Superior de Educação Tecnológica CESET Universidade Estadual de Campinas (Unicamp) Caixa Postal Limeira SP Brasil erikarca@gmail.com, brunotx@gmail.com, regina@ceset.unicamp.br, eliane@ic.unicamp.br Abstract. This experience report evaluates an effort estimation method for software testing, as well as the results from its application on three Brazilian Federal Revenue Service s software specifications. The methodology is based both on the software's use cases, usually developed before the software itself, and technical and environment factors. The results showed that the method was simple to be applied, but it had weaknesses that make its use not efficient on a real environment due to its high percent of error on the estimations. Resumo. Este relato de experiência avalia um método para estimar o esforço (em horas) para a atividade de testes de software, bem como os resultados obtidos após aplicá-lo em especificações de sistemas de software da Receita Federal do Brasil. O método utilizado é baseado tanto na especificação dos casos de uso do software, normalmente elaborada antes mesmo do software, quanto em fatores técnicos e de ambiente de testes. Os resultados mostraram que o método foi simples de ser utilizado, porém este apresentou deficiências que fazem com que seu uso seja inviável no ambiente real pelo fato de gerar estimativas com um grau elevado de erro. 1. Introdução Estimar esforço para testes é um processo pouco explorado, ainda mais quando comparado com a quantidade de opções existentes para estimar o tempo para o desenvolvimento de sistemas de software [Aranha e Borba 2007b]. Apesar de ser pouco explorada, ela não é menos importante, uma vez que os testes são essenciais para verificar se o software atende aos requisitos especificados. Cada vez mais é dada a devida importância para o procedimento de testar um sistema, pois as empresas, independente de seu tamanho, não querem colocar em risco seu prestígio, entregando para seus clientes produtos que têm grandes chances de não funcionar conforme especificado, ou apresentarem falhas de qualquer natureza [Aranha e Borba 2007a]. Para que a atividade de testes faça parte do ciclo de vida de um sistema, é necessário planejar e, conseqüentemente, obter uma estimativa de quanto tempo será necessário para realizá-la [Pressman 2004], para que os recursos sejam devidamente alocados e os prazos possam ser minimamente delineados. O planejamento também se faz necessário para que haja tempo suficiente para que os testes sejam realizados e o 331

333 produto entre no mercado suficientemente testado, evitando reações negativas nos consumidores e na imagem da empresa [Nageswaran 2001]. No entanto, estimar tempo e recursos a serem alocados para testes não é uma tarefa fácil, tanto que muitos especialistas em gerenciamento de projetos têm dificuldade com essa área [Black 2006]. Para ajudar na escolha do método adequado, existem modelos sobre o que deve ser analisado para estimar o esforço para testes como, por exemplo, os passos de testes [Aranha e Borba 2007a], regras e histórico da empresa [Cardoso 2002] e casos de uso do sistema [Nageswaran 2001]. Dessa forma, o objetivo deste trabalho é descrever os resultados obtidos por uma Equipe Independente de Verificação e Validação (EIVeV) ao aplicar um método para estimar esforço de testes a partir da especificação de casos de uso de sistemas de software da Receita Federal do Brasil (RFB). O método escolhido foi aplicado em três sistemas da RFB, e os resultados das estimativas foram comparados com os tempos efetivamente consumidos pela equipe para preparar e realizar os testes nos sistemas, oferecendo informações relevantes para analisar o método utilizado. O presente trabalho é organizado da seguinte forma: a Seção 2 descreve brevemente alguns trabalhos relacionados a estimativas de esforço para testes, enquanto a Seção 3 apresenta de forma detalhada o método escolhido para avaliação. A seção seguinte apresenta os resultados obtidos com a aplicação de tal método e, por último, são apresentadas as conclusões do trabalho e sugestões para trabalhos futuros. 2. Trabalhos Relacionados A criação de métodos de estimativa de tempo necessário para testar um sistema muitas vezes se baseia em métodos para estimativa de esforço de desenvolvimento do mesmo. Em meados dos anos 70, Allan Albrecht encontrava dificuldades para fazer medidas, em relação a desenvolvimento de software, utilizando linhas de código. Por isso, desenvolveu e publicou o método Function Point Analysis (FPA), que baseava suas métricas nas funções do software [Ferens e Gurner 1992]. Algum tempo depois, o FPA serviu de base para a criação de um método de estimativa de testes chamado Test Point Analysis (TPA) [Veenendaal e Dekkers 1999]. O TPA utiliza o FPA, pois precisa do resultado final dele, os Function Points (FPs), para obter seu próprio resultado. Além de utilizar os FPs, ele também leva em conta outros três elementos para a obtenção de uma variável importante, chamada de Test Points (TPs): (i) o tamanho do software, (ii) a estratégia de teste e (iii) o nível de produtividade da equipe de testes. Aranha e Borba desenvolveram uma outra abordagem que considera os passos de um caso de teste, descritos em linguagem natural, para a estimativa de esforço [Aranha e Borba 2007a]. Cada passo deve ser analisado conjuntamente a uma lista de características e, se o passo exercitar determinada característica, o impacto dela é verificado, resultando na atribuição de um valor chamado de Execution Point (EP). O valor de EP para um passo de teste é dado pela soma dos EPs após a verificação de todas as características. Já a estimativa de esforço total é obtida através da multiplicação de um fator de conversão, na forma tempo em segundos / EP, pela soma dos EPs dos passos de teste. Uma abordagem mais simplista envolve, primeiramente, cálculos simples 332

334 baseados no tempo que uma equipe de desenvolvimento necessitou para desenvolver o sistema [Cardoso 2002]. Num segundo momento, são impostas regras para esta estimativa, sendo que são considerados dados como o histórico da equipe e os requisitos do software. Este método não foi comparado neste artigo, pois ele não provê uma estimativa no início do projeto, já que depende do tempo gasto no desenvolvimento do sistema e faz considerações pouco refinadas e detalhadas, podendo interferir em sua aplicação em um estudo de caso. Finalmente, vale citar o trabalho de Nageswaran [Nageswaran 2001], cujo método foi o escolhido para este relato de experiência. Este método estima o esforço de testes utilizando informações contidas nos casos de uso do software. A idéia básica é separar as informações de cada caso de uso em informações sobre os atores envolvidos, o número de transações ou classes de análise, fatores técnicos e de ambiente. Tais informações são convertidas em pontos que, quando multiplicados por um fator de conversão, resultam em uma estimativa do tempo que será necessário para os testes do software. É importante comentar que este trabalho é uma adaptação da metodologia Use Case Points Method (UCPM) [Schneider 1998], proposta por Gustav Karner como um algoritmo de estimativa de esforço de desenvolvimento que emprega casos de uso como uma representação da complexidade do sistema [Merrick 2005]. 3. O Método de Nageswaran O método de Nageswaran se baseia nos casos de uso do sistema, permitindo que as estimativas sejam obtidas no início do ciclo de vida de um projeto, pois é o momento em que os casos de uso ficam disponíveis. O primeiro passo do método prevê a identificação e análise dos atores descritos em cada caso de uso do software. Os atores são classificados e pontuados de acordo com a interação que provê ao usuário, conforme ilustra a Tabela 1. Tabela 1. Classificação dos atores de casos de uso Tipo de Ator Descrição Peso Simples GUI (mais conhecidos como end-users, ou usuários finais) 1 Médio Interfaces interativas ou de protocolo; gerenciamento de 2 banco de dados Complexo API e interações de baixo nível 3 Nesta classificação, um ator simples é aquele que utiliza o sistema através de suas interfaces gráficas; por outro lado, um ator médio utiliza o sistema através de protocolos ou cuida do armazenamento dos dados. Já atores complexos realizam interações utilizando APIs 1. Ao final, cada caso de uso terá uma pontuação final (igual ao somatório dos pesos identificados para cada ator) que, somada, resultará em uma pontuação total chamada de Unadjusted Actor Weights (UAW). O segundo passo leva em conta a quantidade de cenários ou transações existentes em cada caso de uso do software para obter a pontuação associada ao peso dos casos de uso. Um cenário (ou transação) pode ser definido como um conjunto atômico de atividades que levam a um fluxo normal de uso do sistema ou a um fluxo excepcional (ou de exceção), no qual um erro se manifesta no software. A Tabela 2 1 Uma API é um conjunto de padrões para utilizar o software, normalmente composto por funções acessíveis somente por programação que permitem acesso a características menos evidentes ao usuário final. 333

335 mostra a correspondência entre a quantidade de cenários ou transações e o tipo do caso de uso. De acordo com o tipo identificado, um peso é considerado na classificação. Tabela 2. Classificação de caso de uso conforme a quantidade de cenários ou transações Tipo do Caso de Uso Descrição Peso Simples <= 3 transações / cenários 1 Médio 4-7 transações / cenários 2 Complexo >7 transações / cenários 3 Tal como para os atores dos casos de uso, a soma total dos pesos atribuídos para cada caso de uso também é avaliada e recebe o nome de Unadjusted Use Case Weights (UUCW). Dado que o UAW e UUCW foram obtidos, é possível calcular o Unadjusted Use Case Points (UUCP), que é igual à soma de UAW e UUCW. No terceiro passo do método, Nageswaran considera fatores técnicos e de ambiente no qual serão realizados os testes. Os fatores que são levados em conta são: ferramentas de teste, entradas documentadas, ambiente de desenvolvimento, ambiente de testes, reutilização de ferramenta de teste, sistema distribuído, objetivos de desempenho, atributos de segurança e interfaces complexas. No entanto, o autor não deixa claro quais são as diretrizes detalhadas para analisar estes fatores e escolher os valores adequados de uma maneira que não seja subjetiva. Sua proposta diz que um valor no intervalo [0-5] deve ser atribuído a cada fator, onde 0 (zero) significa que o fator é irrelevante e 5 (cinco) significa que tal fator é essencial. Além disso, cada fator recebe um peso no intervalo [0-5]. A multiplicação do valor atribuído ao fator pelo seu peso é chamada de valor estendido, e a soma total dos valores estendidos de todos os fatores é chamada de Technical Environment Factor (TEF). Já o quinto passo do método obtém o valor final de pontos de caso de uso, chamado de Adjusted Use Case Point (AUCP), a partir da fórmula descrita na Figura 1. Para chegar a um valor final de esforço em homens-hora, é necessário multiplicar o valor de AUCP por um fator do tipo homens-hora / ponto de caso de uso, conforme ilustra a Figura 2. Para que esse valor possa ser convertido em total de horas ou dias, deve ser feito um levantamento da disponibilidade das pessoas da equipe de testes. AUCP = UUCP * [0,65 + (0,01 * TEF)] Figura 1. Fórmula de cálculo de AUCP Esforço = AUCP * [homens-hora / ponto de caso de uso] Figura 2. Fórmula de cálculo do esforço (em horas) para testes O último passo do método prevê a adição de um percentual (aplicado no valor do esforço final) relativo à complexidade do projeto e ao esforço para coordenação e gerenciamento dos testes no software. Tal como na análise dos fatores técnicos, Nageswaran também não fornece diretrizes para obter o valor destes percentuais de maneira sistemática. 4. Aplicação do método e lições aprendidas Uma vez entendido o método, a EIVeV aplicou-o para estimar o esforço para os testes de três sistemas web da RFB, cujas características gerais são mostradas na Tabela

336 Uma vez que as informações a respeito de cada um dos sistemas não são públicas, estes serão chamados no decorrer desta seção de Software I, Software II e Software III. É relevante comentar que o passo-a-passo da aplicação do método será descrito somente para o Software I, uma vez que os mesmos procedimentos aplicados neste foram aplicados ao Software II e III. Todas as atividades realizadas pela equipe foram monitoradas em relação ao tempo consumido para executá-las e, ao final, o resultado real obtido foi comparado com a estimativa do método de Nageswaran. Tabela 3. Características dos sistemas onde o método foi aplicado Nome do software Número de casos de uso Número de LOCs (lines of Tipo de sistema code) Software I Web Software II Web Software III Web No primeiro passo, que é a identificação e classificação dos atores dos casos de uso, a equipe analisou cada um dos casos de uso do Software I. A partir deles, os seus respectivos atores foram obtidos e verificou-se em qual classificação, conforme a Tabela 1, eles se encaixavam. O resultado final deste passo encontra-se na Tabela 4, que cita o nome do ator, a quantidade de casos de uso em que ele participa, seu peso e o UAW parcial. Como dito anteriormente, a soma de todos UAW parciais resulta em UAW que, para o Software I, foi igual a 73 (setenta e três). Tabela 4. Identificação dos atores do Software I Nome do ator Número de casos de uso em que participa Peso UAW parcial Ator I Ator II Ator III Ator IV UAW (Unadjusted Actor Weights) 73 Em seguida, foram analisadas as quantidades de cenários em cada caso de uso e aplicada a classificação prevista na Tabela 2. De acordo com a análise, foram identificados no Software I 50 (cinqüenta) casos de uso, sendo 44 (quarenta e quatro) deles do tipo Simples (de 1 a 3 cenários / transações) e 6 (seis) do tipo Médio (de 4 a 7 cenários / transações). Como se atribui peso 1 (um) para um caso de uso do tipo simples e 2 (dois) para o médio, o valor obtido para UUCW foi de 56. Conseqüentemente, foi possível obter o valor de 129 para UUCP, igual à soma de UAW com UUCW. Dando seqüência à aplicação do método, a equipe teve grandes dificuldades no terceiro passo do método, relativo ao cálculo do fator de complexidade técnica ou TEF. Isto ocorreu devido à (i) falta de detalhes a respeito de como atribuir um valor e um peso para cada fator técnico especificado, além do (ii) próprio significado de cada fator. Em relação à primeira questão, a EIVeV adotou as seguintes definições: o valor atribuído ao fator se refere à disponibilidade dele no ambiente de testes, enquanto que o seu peso representa o grau de importância dele para os testes. A segunda questão, que trata do significado dos fatores, foi resolvida utilizando o conhecimento dos membros da EIVeV para se chegar um consenso em relação ao grau de importância de cada fator. Os valores atribuídos para cada fator no cálculo de TEF seguiram o que Nageswaran indicou em seu trabalho, uma vez que o software utilizado como exemplo 335

337 por ele possuía características semelhantes aos da RFB, avaliados neste trabalho. No entanto, os pesos atribuídos a cada fator foram diferentes, e seguiram o que é indicado na Tabela 5. Logo, o valor de TEF obtido foi 85 (oitenta e cinco). Tabela 5. Pesos dos fatores técnicos e de ambiente Fator Peso Fator Peso Ferramenta de Teste 3 Sistema Distribuído 3 Entradas Documentadas 5 Objetivos de Desempenho 1 Ambiente de Desenvolvimento 1 Atributos de Segurança 3 Ambiente de Testes 3 Interfaces Complexas 1 Reutilização de Ferramenta de Teste 1 O quarto passo do método tratou dos cálculos finais do esforço para testes. O cálculo do valor de AUCP, ilustrado na Figura 1, foi simples pelo fato dele ser obtido a partir dos valores de UUCP e TEF. No entanto, o cálculo final de esforço, apresentado na Figura 2, gerou dúvidas quanto ao valor do fator de conversão que deveria ser utilizado. O método diz que este valor deve ser 20 (vinte) no caso de software que faz uso da tecnologia Enterprise Java Beans (EJBs), pois é o tempo gasto para planejar, escrever e executar um ponto de caso de uso neste caso específico. No entanto, o autor não define como identificar este fator para o caso de software que faça uso de outras tecnologias, o que torna a escolha do fator muito subjetiva. Além disso, ele não faz considerações a respeito de como este fator pode ser adaptado caso a equipe de testes possua ferramentas para automação do processo de testes. Esta dificuldade foi considerada a mais crítica e de maior impacto na aplicação do método. A criticidade alta é devida ao que foi falado anteriormente sobre não explicar maneiras para adaptá-lo, pois a EIVeV possui várias soluções para automação dos testes (implicando em redução do esforço nos testes). Já o impacto foi considerado alto, pois a escolha inadequada do fator de conversão afeta diretamente o resultado da estimativa de esforço de testes. Os resultados obtidos para o Software I foram um valor total para AUCP de 193,5 e um valor de esforço de 3870 horas, conforme mostra a Figura 3. A este valor, foi acrescido um percentual devido à complexidade do projeto e sua coordenação e gerenciamento. Como Nageswaran não fornece diretrizes para a definição destes valores, a EIVeV chegou ao consenso que 10% do tempo total para os testes era consumido em coordenação e gerenciamento, enquanto que 15% era devido à complexidade do projeto. Dessa forma, a estimativa para testar o Software I foi de 4837,50 horas. AUCP = 129 * [0,65 + (0,01 * 85)] = 193,50 Esforço = 193,50 * 20 = 3870 Esforço final = Esforço * (1 + 0,10 + 0,15) = 4837,50 Figura 3. Cálculos finais do método de Nageswaran. Conforme dito no início desta seção, o método proposto também foi aplicado ao Software II e III da RFB. Além disso, o tempo real consumido na atividade de testes destes sistemas também foi registrado para fins de comparação com a estimativa obtida através do método de Nageswaran. A Tabela 6 mostra as estimativas de esforço obtidas para os outros dois sistemas testados pela EIVeV, bem como o tempo efetivamente consumido na atividade de testes para os três sistemas da RFB. 336

338 Tabela 6. Comparação entre o esforço estimado e o efetivamente consumido para os testes de três sistemas de software da RFB. Nome do Tempo estimado (em Tempo efetivamente gasto Margem de erro software horas) (em horas) Software I 4837, % Software II % Software III % Os dados apresentados mostram claramente que as estimativas providas pelo método de Nageswaran foram ruins, mesmo se a EIVeV considerasse uma margem de erro associada à estimativa de 20%. A aplicação desta margem de erro é comum, visto que ela provê um número a mais de horas para que a equipe consiga diagnosticar e resolver problemas de qualquer natureza durante os testes, minimizando o impacto ao resultado final do trabalho. Note também que, mesmo se o fator de conversão utilizado pela equipe fosse igual a 5 (ao invés de 20, conforme sugerido no método), o erro na estimativa ainda seria superior a 160 % (em média) para os três sistemas avaliados. Tal como foi comentado, o impacto pela escolha inadequada do fator de conversão é alto, podendo gerar um erro elevado na estimativa de esforço. Nageswaran não ofereceu sugestões de como adaptar este valor, o que dificultou a escolha de um valor adequado pela EIVeV. Além disso, a equipe percebeu ao final da execução dos testes que os cenários de uso do sistema que tratavam exceções consumiam menos tempo na execução dos testes do que os cenários de uso normais. Este detalhe indica que deveria existir uma maneira de distinguir os cenários durante a classificação dos casos de uso. A equipe também acredita que outra causa para o grande erro na estimativa é a ausência de detalhes a respeito do passo de atribuição de valores e pesos para os fatores técnicos e de ambiente de testes. Um último detalhe não ilustrado no método e que e ajudaria nas estimativas seria dividir o tempo total de esforço obtido nas disciplinas previstas no processo de testes. Por exemplo, o tempo total obtido poderia ser dividido entre as disciplinas básicas de planejamento, projeto, execução e análise de resultados dos testes. 5. Conclusão Este relato de experiência descreveu o método de Nageswaran [Nageswaran 2001], que utiliza dados obtidos nas especificações de casos de uso do software para obter o esforço para testes de software, e mostrou os resultados de sua aplicação prática em especificações de casos de uso de três sistemas de software da RFB. O método avaliado é bastante simples de ser entendido teoricamente. No entanto, sua aplicação prática não teve resultados satisfatórios, uma vez que as estimativas obtidas foram muito superestimadas com relação ao tempo consumido na prática por uma EIVeV nos testes dos três sistemas da RFB. Além disso, alguns outros problemas no uso do método foram a falta de explicação de como deveriam ser classificados alguns dados de fatores técnicos e de ambiente, afora a dificuldade na adaptação de um fator de conversão muito importante para obtenção do resultado final. Como trabalhos futuros, a equipe prevê o estudo sobre as possíveis diferenças entre cenários de uso normal e de exceção e seu impacto na estimativa dos testes, bem como a criação de definições mais precisas de como devem ser aplicados valores e pesos aos fatores técnicos e de ambiente de testes. Outras alterações que poderiam ser 337

339 avaliadas são as simplificações nas classificações de atores e de cenários, como Merrick [Merrick 2005] propõe para as estimativas de tempo de desenvolvimento. Agradecimentos Os autores agradecem ao CNPq e FAPESP pelo apoio parcial à realização deste trabalho, à Receita Federal do Brasil pelo apoio financeiro e estudos de caso oferecidos através do Projeto HARPIA, e à SOFIST, pelo apoio financeiro e sugestões para a elaboração do trabalho. Referências Aranha, E. e Borba, P. (2007a) An Estimation Model for Test Execution Effort. Em Proceeding of the First International Symposium on Empirical Software Engineering and Measurement, Setembro, Madri, Aranha E. e Borba, P. (2007b) "Empirical Studies of Test Execution Effort Estimation Based on Test Characteristics and Risk Factors." Em 2nd International Doctoral Symposium on Empirical Software Engineering, Setembro, Madri. Disponível em: a_final.pdf. Último acesso realizado em 21/03/2008. Black, R. (2006) Factors that Influence Test Estimation. Disponível em: jectid=5992. Último acesso realizado em 21/03/2008. Cardoso, A. (2002) The Test Estimation Process, Disponível em: jectid=3510. Último acesso em realizado em 27/02/2008. Ferens, D.V. e Gurner, R.B. (1992) An evaluation of three function point models for estimation of software effort. Em Proceeding of the Aerospace and Electronics Conference, NAECON 1992., Proceedings of the IEEE 1992 National, Maio, Dayton, , Volume 2. Merrick, P. J. (2005) Simplification of the UCPM, Disponível em: Último acesso realizado em 19/02/2008. Nageswaran, S. (2001) Test Effort Estimation Using Use Case Points. Em 14th International Internet Software Quality Week 2001, Junho, São Francisco. Disponível em: Estimation.pdf. Último acesso realizado em 27/02/2008. Pressman, R. S. (2004), Software Engineering: A Practitioner s Approach, McGraw- Hill Professional, 6ª ed. Schneider, G. e Winters, J. P. (1998), Applying Use Cases, Addison-Wesley, 1 a ed. Veenendaal, E. e Dekkers, T. (1999) Test Point Analysis: a Method for Test Estimation. Em Project Control for Software Quality. Editado por: Rob Kusters, Arian Cowderoy, Fred Heemstra e Erik van Veenendaal, Shaker Publishing. 338

340 Avaliação dos Efeitos da Utilização do TDD na Qualidade Interna do Produto Carlos H. Zacarias 1, Josué B. Santos 1, Reinaldo Cabral 2, Ana Regina Rocha 2 1 Departamento de Tecnologia da Informação Secretaria Executiva de Fazenda do Estado de Alagoas (SEFAZ-AL) CEP Maceió AL Brasil 2 Programa de Engenharia de Sistemas e Computação COPPE/UFRJ Caixa Postal CEP Rio de Janeiro RJ Brasil {josuesantos,carlossantos}@sefaz.al.gov.br, {cabral,darocha}@cos.ufrj.br Abstract. The search for efficiency and effectiveness in software development and maintenance is generally supported by the adoption of methods and technologies that may have a great impact in the organization. To prevent the organizations from unexpected results it is important to evaluate these technologies before their institutionalization. This paper presents the experience of the introduction of TDD at SEFAZ-AL and the results achieved. Resumo. A busca por mais eficiência e eficácia no desenvolvimento e manutenção de software geralmente é subsidiada pela adoção de tecnologias que podem causar grande impacto na forma como a organização trabalha. Para evitar resultados inesperados é imprescindível avaliar métodos e tecnologias antes de institucionalizá-las nas organizações. Este trabalho relata a introdução do TDD na SEFAZ-AL e os resultados obtidos com a experiência. 1. Introdução Com a disseminação dos métodos ágeis, o TDD (Test Driven Development Desenvolvimento Orientado a Testes) tem ganhado visibilidade e tem sido alvo de diversos estudos que procuram avaliar sua efetividade, especialmente com relação à produtividade dos programadores e à redução do número de defeitos [George e Williams 2003] [Geras et al. 2004] [Müller e Hagner 2002] [Williams et al. 2003]. Dados apresentados por Williams et al. (2003) apontam uma redução de 40% no número de defeitos capturados durante as atividades de verificação e testes de regressão, sem impactar na produtividade da equipe. Em contrapartida, o estudo conduzido por Müller e Hagner (2002) indicou que o benefício em utilizar a técnica é mínimo ou inexiste ao analisar aspectos relacionados à produtividade e confiabilidade. Devido à ausência de evidências que comprovem a efetividade do TDD e ciente do impacto potencial nas atividades cotidianas da organização, a Diretoria de Tecnologia da Informação (DTI) da Secretaria Executiva de Fazenda do Estado de Alagoas (SEFAZ-AL) decidiu realizar uma avaliação antes de institucionalizar a sua utilização nas atividades de desenvolvimento e manutenção de software. 339

341 Além desta breve introdução, o trabalho possui mais quatro seções: a segunda seção caracteriza sucintamente o TDD, a terceira seção descreve o contexto ao qual a tecnologia está sendo inserida, a seção quatro discorre sobre o estudo realizado e, por fim, uma breve conclusão é apresentada na seção. 2. Desenvolvimento Orientado a Testes (TDD) O TDD surgiu conjuntamente com a ascensão dos métodos ágeis, ambos possuindo raízes nos modelos de processo iterativo, incremental e evolucionário. Há indícios que a idéia tenha sido posta em prática há décadas [Janzen e Saiedian 2005]. Um bom exemplo é o Cleanroom [Mills et al. 1987], processo de engenharia de software introduzido nos anos 80 que utiliza verificação formal do design no início do processo de desenvolvimento. A primeira tentativa clara de definir o TDD como uma prática surgiu no XP (extreme Programming) [Beck 1999], sendo uma das suas práticas centrais aplicada durante a análise, projeto, especificação e testes [Janzen e Saiedian 2005]. No TDD, os testes que especificam a funcionalidade são escritos antes da própria funcionalidade [Williams et al. 2003]. Os testes guiam o projeto do software em construção e têm a finalidade de especificação, juntamente com às comumente atribuídas, de verificação e validação [Geras et al. 2004]. Cada funcionalidade só é considerada construída quando todos os testes, novos ou pré-existentes, são executados com sucesso. Este fato implica a existência de um entendimento prévio do requisito a ser construído para que seja possível escrever uma especificação que detalha um pequeno aspecto do comportamento de uma forma concisa, não ambígua e executável [Astels, 2007]. Para os que utilizam TDD, uma das grandes vantagens, e uma das prováveis causas do seu sucesso, é a possibilidade de diminuição da distância entre a decisão (design), e o feedback (resultado da implementação do design). Com TDD é possível diminuir esta distância o quanto se queira, uma vez que o ciclo testar-codificar fornece um feedback constante ao programador [Beck 2002], sendo esta a forma adotada nas metodologias ágeis [Beck 1999]. 3. A Diretoria de Tecnologia da Informação (DTI) da SEFAZ-AL Em 1997, a Secretaria Executiva de Fazenda do Estado de Alagoas (SEFAZ-AL), no intuito de ter maior controle sobre as informações fiscais, criou o PIF - Programa de Informatização Fazendária. Os sistemas que antes eram mantidos pelo IPD (Instituto de Processamento de Dados) passaram a ser mantidos por funcionários do próprio fisco. Na ocasião o setor de informática da SEFAZ-AL terceirizou quase todos os recursos humanos em termos de desenvolvimento. Há cerca de quatro anos a SEFAZ-AL realizou um concurso público para contratação de pessoal especializado na área de tecnologia da informação com o intuito de ter maior controle sobre suas aplicações, depender menos de terceirizações e melhorar a qualidade do serviço realizado, principalmente no que diz respeito à qualidade de software. Aos poucos, o setor de informática começou a ganhar status de departamento e, em 2005, foi transformado em Diretoria de Tecnologia da Informação 340

342 (DTI). Hoje a diretoria conta com três gerências: Gerência de Apoio ao Usuário, Gerência de Rede e Infra-estrutura e Gerência de Desenvolvimento, na qual está o foco neste trabalho. Uma das principais dificuldades da DTI reside na escassez de tempo para a realização de melhorias, uma vez que a maioria das pessoas está assoberbada com a manutenção dos sistemas existentes. Este fato tem sido acentuado devido à ausência de documentação, ausência de padrões de desenvolvimento e ausência de testes confiáveis e repetíveis, o que tem tornado a tarefa de manutenção ainda mais árdua. O Departamento conta hoje com cerca de 50 profissionais, dos quais 30 são desenvolvedores (na prática, não há distinção muito clara entre analistas e programadores) (vide Tabela 1). Tabela 1. Distribuição dos profissionais e soluções em produção por tecnologia JAVA FORMS PHP DELPHI PL/SQL NATURAL ASP Profissionais (%) 37,93 34,48 6,9 6,9 3,45 3,45 3,45 Soluções (%) 6,67 33,33 16,6 3,33 6,67 3,33 -- Atualmente a SEFAZ-AL possui 29 sistemas em produção, 79,5% desenvolvidos com o paradigma Estruturado, e três em desenvolvimento utilizando o paradigma O.O. Embora apenas 6,67% das soluções estejam na linguagem Java, 37,93% dos profissionais estão trabalhando com a tecnologia, devido à determinação da alta gerência, que decidiu adotar a tecnologia para todos os sistemas considerados críticos, sejam inéditos ou versões evolutivas. Embora a utilização de procedimentos comuns na DTI seja visível, não há processos definidos para orientar o desenvolvimento e a manutenção de software. Esta liberdade para execução das atividades tem levado a conseqüências indesejáveis, dentre elas: (i) ausência da especificação dos requisitos não-funcionais, que fica a critério dos desenvolvedores; (ii) alta taxa de inclusão de defeitos, tanto na fase de codificação quanto durante a manutenção; (iii) documentação desatualizada, antes mesmo de iniciar a codificação dos sistemas; (iv) decaimento da qualidade do código, o que dificulta o entendimento e torna as mudanças cada vez mais difíceis de serem realizadas; e (v) baixa cobertura de testes, a maior parte dos sistemas entra em produção com um conjunto reduzido de testes, além de ser comum que o desenvolvedor realize seus próprios testes exploratórios ad-hoc. Visando buscar um maior nível de qualidade nos softwares produzidos e mantidos pela SEFAZ-AL, foi designada uma equipe para elaborar propostas para a melhoria das atividades realizadas na DTI. Levando em conta as lições aprendidas com experiências anteriores, optou-se por uma estratégia visando à introdução paulatina de mudanças de forma a minimizar possíveis resistências da equipe. A prioridade era aumentar a manutenibilidade do software desenvolvido e mantido pela DTI. Desta forma, o uso de TDD se mostrou alinhado com as necessidades mais urgentes da DTI. 341

343 Em um primeiro momento foi fornecido um conjunto de treinamentos relacionados às tecnologias requeridas (Java, Programação OO, Design Patterns, Automação de Testes, Reestruturação de Código e TDD). Durante estes treinamentos foram apresentados diversos casos de sucesso na aplicação das tecnologias. Apesar disso, ainda havia desconfiança, na equipe, com relação às novidades apresentadas. Assim, frente às incertezas associadas à adoção da técnica, a equipe de melhoria propôs a adoção do TDD em caráter experimental, optando pela realização de um estudo, orientado por pesquisadores do Laboratório de Engenharia de Software da COPPE/UFRJ, conforme descrito na próxima seção. 4. Avaliação do TDD no Contexto da SEFAZ/AL Esta seção apresenta o estudo realizado com o intuito de avaliar a aplicação do TDD na SEFAZ. Para avaliação, foram selecionados quatro sistemas: o Cadsinc (C), desenvolvido com o uso de TDD e mais três que não utilizaram TDD. A pedido da gerência, estes terão seus nomes omitidos e serão chamados de sistemas F, S e E. A tabela 2 provê uma caracterização dos sistemas. Todos os projetos foram desenvolvidos em Java, para plataforma Web e utilizando o paradigma OO. Tabela 2. Caracterização sistemas utilizados no estudo C F S E Tamanho (Linhas de Código) Tamanho da Equipe 9 pessoas 25 pessoas 1 pessoa 1 pessoa Baseado no método GQM (BASILI et al., 1994) foram definidos para este estudo objetivos, questões e métricas, tal como descrito nas próximas seções Objetivo Analisar: a aplicação do TDD Com o propósito de: avaliar os benefícios obtidos com a aplicação do TDD Com respeito a: estrutura interna do código fonte Do ponto de vista do: desenvolvedor No contexto da: DTI- SEFAZ Questões e Métricas Chidamber e Kemerer (1994) afirmam que a estrutura interna do código fonte tem características que podem indicar a qualidade do software produzido. Esses autores preconizam que a qualidade da estrutura interna do código fonte diz respeito ao software (produto) e não leva em consideração o processo de construção e outros fatores que influenciam na construção do código. São exemplos dessas características: (i) Complexidade, medida através da complexidade ciclomática (CC); (ii) Acoplamento, representada pela medida Coupling Between Objects (CBO); (iii) Coesão, que neste contexto foi avaliada pela medida oposta, ou seja, a falta de coesão (LCOM); e (iv) Distância da Seqüência Principal, representando a reusabilidade (D). 342

344 Para atingir o objetivo declarado para o estudo, quatro questões de pesquisa foram definidas (vide Tabela 3). Tabela 3. Questões e Métricas Questões Métricas Premissas e Expectativas Q1. A aplicação do TDD melhorará a testabilidade e a confiabilidade? Q2. A aplicação do TDD aumentará a coesão entre as classes? Q3. A aplicação do TDD diminuirá o grau de acoplamento dos sistemas? Q4. A aplicação do TDD diminuirá a distância da seqüência principal? 4.3. Hipóteses Complexidade Ciclomática (CC) Falta de coesão (LCOM) Acoplamento (CBO) Distância da Seqüência Principal (D) A testabilidade e a confiabilidade final podem ser mensuradas através da complexidade ciclomática [Watson e McCabe 1996]. Portanto, espera-se que com o uso do TDD a métrica apresente um valor menor, isto é, que a testabilidade e a confiabilidade do código seja melhor do que de aquele produzido sem a adoção do TDD. Segundo Chidamber e Kemerer (1994) a falta de coesão aumenta a complexidade além de indicar possíveis erros de design e torna as classes mais difíceis de serem testadas. Espera-se que com o uso do TDD diminua a falta de coesão (aumente a coesão), diminuindo assim a complexidade do código. Chidamber e Kemerer (1994) afirmam que o acoplamento excessivo é ruim para modularidade e diminui o reuso, além de ser um indicativo de quão complexo pode ser testar. Espera-se que com o uso do TDD o reuso seja facilitado e a testabilidade seja ampliada, ou seja, diminua o acoplamento. Martin (2003) afirma que quanto mais próximo da Seqüência melhor é a relação entre abstração e estabilidade de um componente, fornecendo assim uma grande ajuda na definição de quais componentes possuem maior reusabilidade. A expectativa é que o uso do TDD auxilie na diminuição da distância, isto é potencialize o reuso. Hipótese Nula (H0): A qualidade da estrutura interna do código fonte dos sistemas desenvolvidos com TDD (CTDD) é menor do que a daqueles que foram desenvolvidos sem TDD (STDD). CTDD < STDD ( (CC C > CC F ) (CC C > CC S ) (CC C > CC E ) ) ( (LCOM C > LCOM F ) (LCOM C > LCOM S ) (LCOM C > LCOM E ) ) ( (CBO C > CBO F ) (CBO C > CBO S ) (CBO C > CBO E ) ) ( (D C > D F ) (D C > D S ) (D C > D E ) ) Hipótese Alternativa (H1): A qualidade da estrutura interna do código fonte dos sistemas desenvolvidos com TDD (CTDD) não é menor que a daqueles que foram desenvolvidos sem TDD (STDD). CTDD STDD ( (CC C CC F ) (CC C CC S ) (CC C CC E ) ) ( (LCOM C LCOM F ) (LCOM C LCOM S ) (LCOM C LCOM E ) ) ( (CBO C CBO F ) (CBO C CBO S ) (CBO C CBO E ) ) ( (D C D F ) (D C D S ) (D C D E ) ) 4.4. Coleta das Métricas Para este estudo foram pesquisadas diversas ferramentas proprietárias e de código aberto: JDepend 1 (open source), Borland Together 2 (trial), JavaNCSS 3 (open source), 1 JDepend: 343

345 Metrics 4 (open source) e Dependency Finder 5 (open source). Todas as ferramentas open source apresentaram dificuldades para serem instaladas e/ou configuradas. Apenas a ferramenta Together possuía todas as métricas selecionadas para este trabalho, no entanto, por razões desconhecidas, a distância da seqüência principal não estava sendo calculada. Esta ferramenta foi utilizada para obter os dados para as métricas LCOM, CBO e CC. A ferramenta JDepend foi utilizada apenas para o cálculo da métrica D. Todos os dados brutos coletados foram gerados em arquivo texto e processados em uma planilha eletrônica. As tabelas 4, 5, 6 e 7, apresentam uma síntese dos dados. Tabela 4. Complexidade Ciclomática (CC) Sistema Média Desvio Padrão Máximo Observação C 1,757 1, Os números obtidos estão dentro da E 2,243 2, expectativa inicial. O sistema C teve a menor S 1,832 1, complexidade ciclomática média dentre os F 2,665 5, sistemas analisados. Tabela 5. Grau de Acoplamento entre os Objetos (CBO) Sistema Média Desvio Padrão Máximo Observação C 9,528 10, Os números obtidos foram contrários às S 5,641 6, expectativas, a média mais alta de E 0,992 2, acoplamento foi a do projeto C, o único F 8,622 11, construído com TDD. Tabela 6. Falta de Coesão (LCOM) Sistema Média Desvio Padrão Máximo Observação C 153, , Os números obtidos foram contrários às S 66, , expectativas, a média mais alta da falta de E 119, , coesão foi a do sistema C, o único construído F 123, , com TDD. Tabela 7. Distância da Seqüência Principal (D) Sistema Média Desvio Padrão Máximo Observação C 0,240 0,240 0,960 Os números obtidos foram condizentes com S 0,242 0,275 0,960 as expectativas, a menor média da distância E 0,285 0,242 0,750 da seqüência principal foi a do projeto C, o F 0,255 0,214 0,750 único construído com TDD Teste das Hipóteses O teste das hipóteses pode ser realizado a partir da substituição direta dos resultados obtidos no estudo, compilados na Tabela 8. Teste da Hipótese Nula (H0): ( (CC C > CC F) (CC C > CC S) (CC C > CC E) ) = FALSO ( (CBO C > CBO F) (CBO C > CBO S) (CBO C > CBO E) ) = VERDADEIRO ( (LCOM C > LCOM F) (LCOM C > LCOM S) (LCOM C > LCOM E) ) = VERDADEIRO ( (D C > D F) (D C > D S) (D C > D E) ) = FALSO 2 Borland Together. Disponível em: 3 JavaNCSS - A Source Measurement Suite for Java: < 4 Metrics v : 5 Dependency Finder: 344

346 Portanto, H0: FALSOVERDADEIROVERDADEIROFALSO = FALSA Teste da Hipótese Alternativa 1 (H1): ( (CC C CC F) (CC C CC S) (CC C CC E) ) = VERDADEIRO ( (LCOM C LCOM F) (LCOM C LCOM S) (LCOM C LCOM E) ) = FALSO ( (CBO C CBO F) (CBO C CBO S) (CBO C CBO E) ) = FALSO ( (D C D F) (D C D S) (D C D E) ) = VERDADEIRO Portanto, H1: VERDADEIROFALSOFALSOVERDADEIRO = VERDADEIRA Tabela 8. Teste das Hipóteses SISTEMAS HIPÓTESES Metricas C S E F H0 H1 CC 1,756 2,242 1,832 2,664 Falso Verdadeiro CBO 9,52 5,641 0,992 8,622 Verdadeiro Falso LCOM 153,248 66, , ,279 Verdadeiro Falso D 0,24 0,242 0,285 0,255 Falso Verdadeiro Conclui-se que, no contexto da DTI, considerando amostra limitada de projetos, a qualidade da estrutura interna do código fonte dos sistemas desenvolvidos com TDD não é menor que a daqueles que foram desenvolvidos sem TDD. Embora tenha sido possível refutar a hipótese nula, é prudente realizar estudos adicionais em larga escala para minimizar as diversas influências, por exemplo, as diferenças em termos de tamanho do sistema, complexidade, experiência e tamanho da equipe, ferramentas utilizadas e pressões de cronograma. A próxima seção apresenta uma breve discussão sobre alguns dos fatores que influenciaram o estudo Fatores que Influenciaram o Estudo Heterogeneidade das Equipes: As equipes alocadas a cada um dos sistemas avaliados diferem consideravelmente em termos de tamanho e experiência. No tocante a experiência dos desenvolvedores, a equipe do projeto C era a que possuía menos experiência (experiência média em programação menor que dois anos). No projeto E o desenvolvedor possuía experiência de mais de cinco anos. Já o projeto S também contou com programador inexperiente (menos de dois anos experiência). Pressões de cronograma: Dos projetos que foram comparados apenas o C e F possuiam forte compromisso com prazos. Ou seja, os demais sistemas foram desenvolvidos sem ter data fixada para entregar o produto. A pressão exercida pela gerência de desenvolvimento e pelos gestores de negócio fez com que a equipe do projeto C abrisse mão de uma das práticas fundamentais do TDD, o refactoring (isto aconteceu em várias iterações a partir da iteração 12). Acredita-se que isto tenha sido refletido nos números relativos ao acoplamento (CBO). Natureza dos sistemas: Os projetos comparados são bem diferentes em termos da sua natureza e da complexidade do domínio, o que dificultou a avaliação através das métricas extraídas. Fatores importantes como a complexidade das regras de negócio não foram considerados. Decisões Arquiteturais: Algumas determinações arquiteturais também influenciaram nos números. Durante o desenvolvimento do projeto C havia uma determinação para que os objetos da camada de negócio e da camada de integração fossem obtidos a partir de um único local (Fábrica). Estas fábricas que centralizam a obtenção de vários objetos 345

347 distintos apresentam baixa coesão. Além disso, todas essas classes apresentam a média da complexidade ciclomática baixa, em torno de 1 (um), pois são classes muito simples. 5. Conclusão Pode-se perceber que os cursos práticos foram fundamentais para suprimir a resistência inicial. A DTI também pode contar com um especialista no assunto que fazia parte do quadro permanente, este aspecto foi decisivo para o sucesso da iniciativa. Os desenvolvedores que antes dos projetos estavam bastante céticos com relação ao desenvolvimento orientado a testes, agora não cogitam desenvolver sem a utilização do TDD. A despeito de algumas métricas de qualidade interna terem sido desfavoráveis todos os membros da equipe afirmaram que se fossem desenvolver outro sistema o fariam tendo os testes como guia. Essa confiança confirma um dos benefícios citados na literatura: a segurança trazida pelos testes. No projeto Cadsinc foram freqüentes as mudanças nas regras de negócio, o que acarretou modificações constantes no código. Neste caso, os testes propiciaram a segurança necessária para que as modificações fossem realizadas. É preciso ser cauteloso ao realizar qualquer análise sobre a aplicação de TDD na SEFAZ. Vários benefícios foram percebidos, mas não foram comprovados através de medições. Por isso, a gerência da DTI decidiu repetir a experiência em outros projetos. Espera-se coletar dados sobre a manutenibilidade destes sistemas e também sobre a produtividade no desenvolvimento e, a cada experiência, avaliar os efeitos da utilização de TDD. Referências Astels, D. (2007), A New Look At Test-Driven Development. Disponível em: < Acesso em 19 nov Beck, K. (1999) Extreme Programming Explained: Embrace Change, Addison-Wesley Beck, K. (2002) Test Driven Development: By Example, Addison-Wesley Basili, V.R.; Caldiera, G.; Rombach, H. D. (1994), The Goal Question Metric Approach. In: Encyclopedia of Software Engineering 1. pp Chidamber, S.; Kemerer, C. (1994), A Metrics Suite for Object Oriented Design. In: IEEE Transaction on Software Engineering. 20., pp Geras, A, Smith, M., Miller, J. (2004) A Prototype Empirical Evaluation of Test Driven Development, 10th International Symposium on Proceedings of the Software Metrics, IEEE Computer Society, pp , Chicago. George, B., Williams, L. (2003) An Initial Investigation of Test Driven Development in Industry, Proceedings of the 2003 ACM Symposium on Applied Computing, pp , ACM Press, Melbourne, Florida. Janzen, D., Saiedian, H. (2005) "Test-Driven Development: Concepts, Taxonomy, and Future Direction. IEEE Computer, September, pp Martin, R. C., (2003) Agile Software Development, Principles, Patterns, and Practices, Prentice-Hall Mills, H. D., Dyer, M., Linger, R. C, (1987) "Cleanroom Software Engineering", IEEE Software, pp

348 Müller, M., Hagner, O. (2002) Experiment about Test-first programming, IEE Proceedings Software, Vol. 149, Issue 5, pp Watson, A. H., McCabe, T. J. (1996) "Structured Testing: A Testing Methodology Using the Cyclomatic Complexity Metric", National Institute of Standards and Technology Special Publication , 123p. Williams, L., Maximilien, E. M., Vouk, M. (2003) Test driven development as a defect-reduction practice, 14th International Symposium on Software Reliability Engineering, pp IEEE Computer Society, Denver, Colorado. 347

349 Comparando a Implantação de Projetos Cooperados baseados no MR-MPS através da Replicação de um Instrumento de Avaliação: Análise Quantitativa sob a ótica das Empresas Rafael Prikladnicki 1, 2, Odisnei Galarraga 1, 3, Carlos Alberto Becker 1, 3 1 SOFTSUL Agente SOFTEX POA RS Brasil 2 Faculdade de Informática PUCRS POA RS Brasil 3 Software Process Consultoria POA RS Brasil rafaelp@pucrs.br, {odisnei, carlos.becker}@swprocess.com.br Abstract. In this paper we present quantitative results of a comparative evaluation conducted with ten companies from the first and second groups of companies implementing the MR MPS. The evaluation considered the companies point of view and two dimensions: the importance and the satisfaction of some selected criteria. The results are presented and discussed. We believe that the information in this paper can contribute to improve future projects with group of companies in Brazil. Resumo. Neste artigo são apresentados os resultados quantitativos de uma avaliação realizada com dez empresas do primeiro e segundo grupos de um projeto cooperado de implementação do MR MPS. A avaliação considerou a percepção das empresas sob duas dimensões: à importância e a satisfação de dos critérios identificados. Os resultados são apresentados e discutidos. Acredita-se que os dados apresentados neste artigo contribuem para melhorar a execução de futuros projetos cooperados no país. 1. Introdução Nos últimos anos, o Brasil tem vivenciado um crescimento bastante significativo em relação ao investimento na melhoria e qualidade dos produtos de software. Isto tem sido possível, entre outros fatores, pelo crescimento dos programas de melhoria de processo de desenvolvimento de software nas empresas. Diversas empresas vêm implantando melhorias nos seus processos, seguindo modelos de qualidade específicos (Moreira et. al., 2005; Nunes et. al., 2006). Um dos fatores que tem contribuído para este crescimento é o surgimento do programa MPS.BR e seu modelo de referência, o MR- MPS (Softex, 2006). Este modelo surgiu em dezembro de 2003, e foi criado a partir da necessidade de padrões de qualidade na indústria de software no Brasil, e que pudesse ser aplicado em empresas com menor poder aquisitivo se comparadas às empresas que investiam em modelos tais como o CMMI (Weber et. al., 2005). O MPS.BR, segundo Softex (2006) é um programa para melhoria de processo do software brasileiro, e é coordenado pela Associação para Promoção da Excelência do Software Brasileiro (SOFTEX), contando com apoio do MCT, da FINEP e do BID. Ele baseia-se nos conceitos de maturidade e capacidade de processo para a avaliação e 349

350 melhoria da qualidade e produtividade de empresas de software e serviços correlatos. Ele é composto por três componentes: Modelo de Referência (MR-MPS), Método de Avaliação (MA-MPS) e Modelo de Negócio (MN-MPS). O foco deste artigo é a avaliação comparativa da implantação do Modelo de Negócio Cooperado (MNC-MPS.BR) em dois grupos de cinco empresas cada (duas empresas nível G e três empresas nível F em um, e duas empresas nível F e três empresas nível G no outro), ambos coordenados pela Softsul (agente SOFTEX no RS), em um projeto de implantação do MR-MPS. Os resultados apresentados envolvem a avaliação, por parte das empresas, de um conjunto de itens sob duas dimensões: a importância destes itens para um projeto cooperado, e a satisfação da empresa em relação à execução do projeto. Na próxima seção, apresentam-se brevemente os conceitos de um projeto cooperado em grupo de empresas. Na seção 3 é apresentada a metodologia de pesquisa. A seção 4 apresenta os resultados da pesquisa e a seção 5 apresenta as conclusões. 2. Referencial Teórico Projetos em grupos cooperados têm sido bastante utilizados nos últimos anos no Brasil (Wangenheim et al, 2005). Vários grupos cooperados foram organizados, tendo por base o antigo SW-CMM, o CMMI, e agora o MR MPS (Prikladnicki et al, 2007). No MPS.BR, o MNC-MPS.BR prevê a organização de grupos de empresas para a implementação do MR-MPS. Neste modelo, o primeiro passo é a constituição de um grupo de empresas comprometidas com a implementação e avaliação do MR-MPS. Isto pode ocorrer, por exemplo, pela iniciativa de um agente SOFTEX, o que foi o caso deste artigo. Sempre que pertinente, a SOFTEX assina um convênio com a entidade gestora do grupo de empresas (IOGE). A partir de sua constituição, a IOGE assina um contrato com uma das Instituições Implementadoras (II) existentes (MN-MPS.BR, 2007). O modelo cooperado do MR MPS tem sido uma opção para diversas empresas no país. As empresas buscam alguns benefícios, entre os quais se destacam a divisão dos custos para determinadas atividades, além do compartilhamento de experiências entre as empresas participantes do projeto. Mas não se tem conhecimento, entre os grupos cooperados organizados até então, da execução de avaliações sistemáticas dos projetos, sob a ótica das empresas, conforme o relato apresentado nas próximas seções. 3. Metodologia de Pesquisa Para coletar a opinião das empresas, uma pesquisa do tipo survey (Oates, 2006) foi planejada e aplicada. Esta pesquisa foi aplicada no primeiro grupo, cujos dados foram apresentados em Prikladnicki et al (2007), e replicada no segundo grupo de empresas. O objetivo foi avaliar os itens de maior importância para um projeto cooperado e analisálos frente à satisfação percebida pelas empresas. Além disso, foi feita uma análise comparativa dos dois grupos, de forma a avaliar a evolução da condução de projetos cooperados coordenados pela Softsul, visando também propor um instrumento padrão de avaliação para ser utilizado por outros grupos cooperados em âmbito nacional. Para a coleta de dados, foi elaborado um questionário com diversos itens a serem avaliados (Anexo 1). Estes itens foram identificados após uma ampla pesquisa bibliográfica, e foram divididos em três 3 grandes grupos: itens relacionados à IOGE, II 350

351 e SOFTEX (I) - nos projetos avaliados, a IOGE e a II eram representadas pela mesma instituição (Softsul) - à empresa (E) e às atividades da cooperativa (C). Todas as questões eram fechadas, em escala Likert (Oates, 2006) variando de 1 (importância ou satisfação mínima) a 5 (importância ou satisfação máxima). Após a elaboração do questionário, o mesmo foi avaliado por três especialistas com conhecimento acadêmico e/ou profissional na área de qualidade de software e no modelo MR-MPS. Além disto, houve a aplicação de um pré-teste envolvendo três profissionais. Para a replicação da avaliação no segundo grupo, o questionário foi revisado por mais dois especialistas, que integram a equipe de implementadores credenciados vinculados a uma II. Como resultado, houve a revisão do instrumento de pesquisa e a correção de perguntas, de forma a identificar problemas e aumentar o efetivo significado para os respondentes, antes da coleta de dados (Frankfort-Nachmias, 1996). O questionário foi então enviado por para três representantes de cada empresa (o patrocinador, o coordenador do grupo de melhoria, e um integrante do grupo de melhoria). Ao todo, foram recebidas 24 respostas (11 do primeiro grupo e 13 do segundo grupo). Para a análise dos dados utilizou-se o software SPSS V10.0 (Statistical Package for the Social Sciences). Para efeitos de comparação das avaliações, foi utilizada a estatística descritiva, através do cálculo da média e do desvio padrão dos itens. 4. Resultados da Pesquisa A seguir apresentam-se os resultados comparativos das duas dimensões avaliadas Importância dos critérios para um projeto cooperado Em relação à importância dos itens avaliados para um modelo cooperado, a tabela 1 apresenta os dez mais importantes, na opinião das empresas de cada um dos grupos. Tabela 1. Itens considerados mais importantes para um projeto cooperado Grupo cooperado 1 Grupo cooperado 2 Dim Questões Média Média Questões Dim I Elaboração do plano de melhoria 5,00 5,00 Percepção interna das melhorias nos processos E I Mentoring presencial 5,00 4,92 Disponibilidade de recursos pela empresa E E Alinhamento entre processos baseados no MR- MPS e objetivos e estratégia da empresa 5,00 4,92 Equipe interna de implementação do projeto E I Treinamentos realizados 4,91 4,92 Subsídio financeiro existente I I Diagnóstico inicial 4,91 4,85 Diagnóstico inicial I E Equipe interna de implementação do projeto 4,91 4,85 Elaboração do plano de melhoria I E Retorno do investimento 4,91 4,85 Alinhamento entre processos baseados no MR MPS e objetivos e estratégia da empresa E E Execução de treinamento interno 4,91 4,77 Mentoring presencial I I Elaboração e assinatura do contrato 4,82 4,77 Conciliação do trabalho diário com a implementação dos processos E I Seminários oferecidos 4,82 4,77 Integração entre equipe interna de implementação e os demais colaboradores E Comparando as médias relativas à importância dos itens, obtidas nas duas pesquisas, observa-se que cinco itens que estavam entre os dez considerados mais importantes pelo primeiro grupo de empresas também estão entre os dez mais importantes para o segundo grupo pesquisado, quais sejam: Equipe interna de implementação do projeto; Elaboração do plano de melhoria; Alinhamento entre processos baseados no MR MPS e objetivos da empresa; 351

352 Diagnóstico inicial; e Mentoring presencial. É importante para que as instituições responsáveis pelo programa de melhoria (SOFTEX, IOGE e II) adotem ações que permitam melhorar o seu desempenho no que se refere a estas questões. Mesmo nos itens que são de responsabilidade da empresa (E), é interessante que os agentes externos envolvidos no programa cooperado orientem as empresas no sentido de dedicar atenção a estas questões, dada a importância atribuída a elas. Na outra ponta, têm-se os dez itens de menor importância (Tabela 2). Tabela 2. Itens considerados menos importantes para um projeto cooperado Grupo cooperado 1 Grupo cooperado 2 Dim Questões Média Média Questões Dim I Apresentação formal do projeto para empresas 4,10 4,00 Integração das empresas da cooperativa C C Integração das empresas da cooperativa 4,09 4,00 Workshops em grupo C I Equipe administrativa 4,00 4,00 Seminários em grupo C C Apoio ferramental disponibilizado 4,00 3,85 Mentoring remoto I I Equipe de suporte a eventos 3,91 3,62 Compartilhar expectativas entre as empresas C I Acesso às informações sobre grupos que atuam no modelo cooperado 3,91 3,46 Equipe administrativa I C Similaridade de níveis no grupo cooperado 3,91 3,38 Equipe de suporte a eventos I I Mentoring remoto 3,90 3,25 Similaridade na evolução das empresas C C Similaridade na evolução das empresas 3,80 3,00 Similaridade de níveis em um mesmo grupo cooperado C C Similaridade entre empresas da cooperativa (objetivos, negócio, etc.) 3,73 2, Similaridade entre empresas da cooperativa (objetivos, negócio, etc.) Sete itens aparecem entre os dez menos importantes nos dois grupos: Mentoring remoto; Equipe administrativa; Equipe de suporte a eventos; Integração das empresas da cooperativa; Similaridade na evolução das empresas; Similaridade de níveis em um mesmo grupo cooperado; e Similaridade entre empresas da cooperativa (objetivos, negócio, etc.). O conhecimento destes fatores permite que as mesmas instituições responsáveis pelo programa cooperado destinem maior esforço e recursos aos fatores considerados mais relevantes do ponto de vista das empresas. Por exemplo, o item mentoring presencial está entre os dez considerados mais importantes pelas empresas, enquanto que mentoring remoto é um dos dez percebidos como menos importantes. Neste caso, em um próximo grupo cooperado, poderia haver um planejamento de mais tempo dos consultores para os mentorings presenciais em relação aos atendimentos remotos Satisfação dos critérios nas Cooperativas 2006 e 2007 da Softsul Em relação à satisfação com os itens avaliados, a tabela 3 apresenta os dez itens que deixaram as empresas mais satisfeitas, em cada um dos grupos cooperados. Tabela 3. Itens com maior índice de satisfação Grupo cooperado 1 Grupo cooperado 2 Dim Questões Média Média Questões Dim E Momento escolhido pela empresa para a implementação do projeto 4,64 4,67 Execução da avaliação informal I C

353 Grupo cooperado 1 Grupo cooperado 2 Dim Questões Média Média Questões Dim E Apoio da alta gerência 4,64 4,55 Processo de adesão das empresas à cooperativa I E Adaptação ao modelo MR-MPS 4,64 4,46 Apoio da alta gerência E I Workshops organizados 4,55 4,45 Apresentação formal do projeto para as empresas I E Equipe interna de implementação do projeto 4,55 4,42 Diagnóstico inicial I I Equipe técnica 4,45 4,38 Horas de mentoring presencial I I Qualidade do mentoring presencial 4,45 4,25 Metas físicas estabelecidas para liberação dos recursos financeiros da Softex I C Realização dos seminários em grupo 4,45 4,23 Coordenação do projeto I I Qualidade do mentoring remoto 4,44 4,23 Entendimento interno dos benefícios da implementação E I Seminários oferecidos 4,36 4,23 Alinhamento entre processos do MR-MPS e objetivos e estratégia da empresa E Se no caso dos níveis de importância foram obtidos resultados semelhantes para os dois grupos pesquisados, o mesmo não ocorreu com os níveis de satisfação. Houve uma diferença considerável entre os resultados obtidos. Dos dez itens com maior índice de satisfação no primeiro grupo, apenas um aparece no segundo grupo: Apoio da alta gerência. Além disso, este item refere-se a questões internas das empresas. Isto significa que alguns itens de responsabilidade das instituições externas às empresas resultaram em uma menor satisfação percebida pelo segundo grupo. Os demais itens considerados pelo primeiro grupo de empresas entre aqueles com maior índice de satisfação tiveram um nível de satisfação mais baixo na percepção do segundo grupo pesquisado. Isto sugere que, no segundo grupo, várias questões consideradas pelo primeiro grupo como melhor encaminhadas tiveram um desempenho inferior. É importante, neste caso, que sejam investigadas as causas desta menor satisfação do segundo grupo de empresas em relação a estas questões, de forma que elas possam ser objeto de ações corretivas em um novo projeto cooperado. Na outra ponta, têm-se os dez itens de menor satisfação (Tabela 4). Tabela 4. Itens com menor índice de satisfação Grupo cooperado 1 Grupo cooperado 2 Dim Questões Média Média Questões Dim I Equipe administrativa 3,67 3,60 Qualidade do mentoring remoto I I Processo de adesão de empresas à cooperativa 3,63 3,58 Compartilhar expectativas entre empresas C I Elaboração e assinatura do contrato 3,63 3,54 Carga horária total do projeto I C Similaridade na evolução das empresas 3,40 3,46 Duração total do projeto I C Compartilhar dificuldades entre empresas 3,36 3,46 Conciliação do trabalho diário com a implementação dos processos E C Compartilhar expectativas entre empresas 3,20 3,46 Compartilhar soluções entre as empresas C C Integração das empresas da cooperativa 3,20 3,38 Compartilhar dificuldades entre as empresas C C Compartilhar soluções entre as empresas 3,18 3,33 Apoio ferramental disponibilizado C C Compartilhar experiências entre empresas 3,09 3,31 Integração das empresas da cooperativa C I Acesso às informações sobre grupos que atuam no modelo cooperado 2,33 3,18 Horas de mentoring remoto I Quatro itens percebidos pelo primeiro grupo como os de menor satisfação permaneceram entre os dez piores de acordo com o segundo grupo avaliado: Compartilhamento de expectativas entre as empresas; Compartilhamento de soluções entre as empresas; Compartilhamento de dificuldades entre as empresas; e 353

354 Integração das empresas da cooperativa. Todos os itens possuem em comum a integração e compartilhamento de informações entre empresas. Apesar da organização de eventos em conjunto, as empresas não se mostraram satisfeitas com as oportunidades e qualidade do compartilhamento de informação, o que sugere um esforço da IOGE para estimular esta integração em projetos futuros, ou entender os motivos da resistência das empresas Relação entre Importância e Satisfação Após a análise isolada de cada dimensão da pesquisa, foi feita uma análise cruzada, relacionando as duas dimensões. O objetivo desta análise foi identificar itens que possuíam altos níveis de importância e baixos níveis de satisfação entre os respondentes. A tabela 5 apresenta os itens onde a relação entre importância e satisfação mostrou-se mais crítica. A coluna I/S indica a razão entre a pontuação de importância e satisfação. A variação desta razão é de 0,2 a 5. Quando esta razão é maior do que 1, isto sinaliza que a questão merece atenção, pois possui nível de importância superior ao de satisfação. Isto é particularmente crítico para as questões cujo índice de importância é percebido como alto (média de importância 5 ou próxima deste valor). Tabela 5. Relação entre importância e satisfação Grupo cooperado 1 Grupo cooperado 2 Dim Questões I/S I/S Questões Dim I Acesso às informações sobre grupos que já trabalharam ou Conciliação do trabalho diário com a 1,68 1,38 trabalham no modelo cooperado implementação dos processos E C Compartilhamento de experiências entre as empresas 1,38 1,36 Recursos disponibilizados pela empresa E I Elaboração do plano de melhoria 1,35 1,27 Compartilhar soluções entre as empresas C C Compartilhamento de soluções entre as empresas 1,34 1,26 Subsídio Financeiro I I Elaboração e assinatura do contrato 1,33 1,26 Retorno do investimento E C Compartilhamento de expectativas entre as empresas 1,31 1,25 Apoio ferramental disponibilizado C C Integração das empresas da cooperativa 1,28 1,24 Elaboração do plano de melhoria I C Compartilhamento de dificuldades entre as empresas 1,27 1,23 Percepção por parte dos clientes E I Metas físicas estabelecidas para liberação dos recursos Compartilhamento de dificuldades entre as 1,27 1,23 financeiros da Softex empresas C I Diagnóstico inicial 1,26 1,23 Percepção interna das melhorias E As análises isoladas de importância e de satisfação são importantes para entender a percepção das empresas em relação a esses fatores. Entretanto, para melhorar a condução de programas com grupos de empresas, é fundamental saber se o que é considerado importante pelas empresas está sendo atendido de forma satisfatória. Caso sejam identificados fatores que apresentem uma razão muito alta entre percepção de importância e nível de satisfação das empresas, pode-se atuar sobre esses fatores de forma a dar-lhes mais atenção em programas futuros. Ao comparar-se a razão entre os dois índices nos dois grupos pesquisados, podese observar que no primeiro grupo todas as questões que apresentavam uma razão mais elevada entre importância e satisfação estavam sob responsabilidade dos agentes externos (I/C). Já no segundo grupo, estas questões aparentemente foram melhor encaminhadas, e metade das questões estavam sob responsabilidade da própria empresa (E), indicando alguma dificuldade interna na condução do programa. Além disso, a maior razão entre importância e satisfação caiu de 1,68 para 1,38 entre os dois grupos. Analisando os dados da tabela 5, também é possível concluir, por exemplo, que a existência do subsídio financeiro é considerada muito importante e que, no entanto, as 354

355 empresas provavelmente gostariam que ele fosse maior. Ou ainda, que o Plano de Melhoria, apesar de ser considerado importante, deveria ser melhor elaborado. 5. Considerações finais O relato apresentado neste artigo buscou avaliar, sob a ótica das empresas participantes de dois projetos no modelo cooperado, quais os itens considerados importantes e como os itens foram avaliados após a execução dos projetos. Em relação aos resultados, eles representam apenas dois dos diversos grupos cooperados atualmente em execução no país (Rocha, 2006; Wangenheim et al., 2006), mas inova ao apresentar uma análise quantitativa, bem como a replicação da avaliação, visando comparar e melhorar constantemente projetos desta natureza. Os resultados do estudo não podem ser generalizados para outros projetos cooperados. Apesar de trazer aspectos relevantes que podem ser aproveitados por outras iniciativas semelhantes, os resultados refletem a percepção e ação sob a ótica das empresas que fazem parte de apenas uma IOGE. Desta forma, uma conseqüência imediata deste estudo foi o planejamento de ações para serem colocadas em prática no terceiro grupo cooperado de empresas no RS, iniciado em Em relação a perspectivas futuras, entende-se que esta pesquisa apresenta-se como um instrumento importante para que os agentes responsáveis por programas cooperado possam melhorar a condução de outros projetos desta natureza. Neste sentido, acredita-se ser interessante a replicação desta pesquisa em outros projetos cooperados no país, através de uma iniciativa que poderia ser coordenada pela SOFTEX. Por este motivo, está sendo desenvolvida uma ferramenta para automatizar o processo de coleta e análise dos dados, visando não apenas comparar os grupos cooperados de uma forma mais abrangente, mas também buscar melhorias para o programa MPS.BR como um todo. 6. Agradecimentos Agradecemos à todos os profissionais que participaram do estudo, e às empresas que viabilizaram a execução dos dois grupos cooperados de implementação do MR MPS, coordenados pela Softsul. Este trabalho também foi submetido ao ciclo 2008 do PBQP- Software (Programa Brasileiro de Qualidade e Produtividade em Software). Referências Bibliográficas MN-MPS.BR (2007) Modelo de Negócio para Melhoria de Processo de Software, Disponível em Moreira, L. S. R., Samrsla, V. C, Mora, M. C., Prikladnicki, R., Bossle, R., Back, R. (2005) Uma Avaliação das Equipes de Projeto em um Momento Pré-Avaliação Oficial de um Programa de Melhoria de Processo de Software visando o CMMI nível 2, In: IV SBQS, Porto Alegre. Nunes, E. D., Pinto, R., Rocha, A. R., Santos, G. (2006) MPS.BR Nível E Uma Avaliação em Verde e Amarelo, In: V SBQS, Vila Velha. Oates, B. J. (2006) Researching Information Systems and Computing, Sage. 355

356 Prikladnicki, R., Furlanetto, T. M., Becker, C. A. (2007) Uma Análise Quantitativa da Implantação do MR MPS em Projetos Cooperados: Avaliação sob a ótica das Empresas, In: SIMPROS, São Paulo, Brasil. Rocha, A. R. (2006) Relatório Semestral da COPPE/UFRJ Instituição Implementadora MPS.BR Disponível em Softex (2006) MPS.BR Melhoria de Processo do Software Brasileiro Guia Geral versão 1.1, Sociedade SOFTEX, Maio de Disponível em Wangenheim, G. V. C., Pickler, K., Thiry, M., Zoucas, A (2006). Uma Abordagem para a Modelagem Colaborativa de Processos de Software em Micro e Pequenas Empresas In: V SBQS, Vila Velha, Brasil. Weber, K. C., Araújo, E., Machado, C. A. F., Scalet, D., Salviano, C. F., da Rocha, A. R. C. (2005) Modelo de Referência e Método de Avaliação para Melhoria de Processo de Software versão 1.0 (MR-MPS e MA-MPS), In: IV SBQS, POA. Frankfort-Nachmias, C.; Nachmias, D. (1996). Research Methods in the Social Sciences, 5. ed., Nova York: Sr. Martin s Press. 356

357 Anexo 1 Itens avaliados através do questionário 1 DIMENSÃO CRITÉRIOS N A I e/ou S IOGE Apresentação formal do projeto em um modelo cooperado I e S IOGE Processo de adesão de empresas I e S IOGE Elaboração e assinatura do contrato I e S IOGE Planejamento do projeto S IOGE Duração total do projeto S IOGE Carga horária total do projeto S IOGE Seminários I e S IOGE Workshops I e S IOGE Treinamento externo I e S IOGE Diagnóstico inicial I e S IOGE Definição de um plano de melhoria I e S IOGE Mentoring presencial I e S IOGE Mentoring remoto I e S IOGE Qualidade do mentoring presencial S IOGE Qualidade do mentoring remoto S IOGE Execução da avaliação informal S IOGE Reunião de lições aprendidas I e S IOGE Equipe técnica S IOGE Reuniões de acompanhamento técnico I IOGE Coordenação para o projeto I e S IOGE Equipe administrativa I e S IOGE Equipe de suporte a eventos I e S IOGE Metas físicas estabelecidas I e S IOGE Subsídio financeiro existente I e S IGOE Acesso às informações sobre experiências com modelo cooperado I e S EMPRESA Disponibilidade de recursos pela empresa I e S EMPRESA Equipe interna de implementação I e S EMPRESA Conciliação do trabalho diário com a implementação dos processos I e S EMPRESA Integração entre equipe interna de implementação e colaboradores I e S EMPRESA Alinhamento entre processos MR MPS e estratégia da empresa I e S EMPRESA Retorno do investimento I e S EMPRESA Percepção interna das melhorias nos processos I e S EMPRESA Percepção por parte dos clientes I e S EMPRESA Momento da empresa para a execução do projeto I e S EMPRESA Treinamento interno I e S EMPRESA Entendimento interno dos benefícios da implementação S EMPRESA Modelo cooperado S EMPRESA Comprometimento interno S EMPRESA Motivação dos colaboradores S EMPRESA Apoio da alta gerência S EMPRESA Adaptação ao modelo MR-MPS S EMPRESA Comunicação interna S EMPRESA Processo desenvolvido S Cooperativa Compartilhamento de expectativas entre empresas I e S Cooperativa Compartilhamento de dificuldades entre empresas I e S Cooperativa Compartilhamento de soluções entre empresas I e S Cooperativa Compartilhamento de experiências gerais entre empresas I e S Cooperativa Integração entre empresas de um projeto cooperado I e S Cooperativa Similaridade de níveis em um mesmo grupo cooperado I Cooperativa Similaridade entre empresas da cooperativa (objetivos, negócio, etc.) I Cooperativa Similaridade na evolução das empresas I e S Cooperativa Workshops em grupo I e S Cooperativa Seminários em grupo I e S Cooperativa Treinamentos em grupo I e S 1 Na última coluna, I indica que o item foi avaliado apenas na sua importância, S apenas na satisfação, e I e S indica que o item foi avaliado em ambos (e posteriormente comparado). 357

358 Cooperativa Apoio ferramental I e S 358

359 Desenvolvimento de um Processo de Software Aderente à ISO 9001:2000 Baseado no Processo Ágil Scrum Antônio F. dos Santos Jr. 1, Vandermi J. da Silva 1, Vicente F. de Lucena Jr. 1 1 CETELI Centro de Pesquisa e Desenvolvimento em Tecnologia Eletrônica e da Informação Universidade Federal do Amazonas (UFAM). Campus da Universidade Federal do Amazonas - Setor Norte - Faculdade de Tecnologia - Av. Gal. Rodrigo Octávio Jordão Ramos, nº 3000 CEP Bairro Aleixo Manaus AM Brasil ajunior.analista@ig.com.br, {vandermi, vicente}@ufam.edu.br Abstract. This paper describes how the research and development department of a mobile devices company developed a process compliant to ISO 9001:2000 for use in Scrum-based projects in software development, based on the experience and history in the use of this agile process in former projects, maintaining its quality system compliant to ISO 9001:2000, getting certified in this standard, and improving its projects performance. Resumo. Este artigo descreve como o departamento de pesquisa e desenvolvimento de uma empresa de dispositivos móveis desenvolveu um processo aderente à ISO 9001:2000 para uso em projetos que utilizam o processo Scrum no desenvolvimento de software, baseando-se na experiência e histórico do uso desse processo ágil em projetos antigos, mantendo seu sistema da qualidade aderente à ISO 9001:2000, obtendo a certificação neste padrão e melhorando o desempenho de seus projetos. 1. Introdução No mundo empresarial, qualidade e agilidade são princípios fundamentais para manter uma empresa competitiva. Ao unir o padrão de qualidade ISO 9001:2000 ao processo ágil Scrum, qualquer empresa de desenvolvimento de software estará dando um grande passo para utilizar estes princípios. A gestão da qualidade sempre foi um tema importante no departamento de pesquisa e desenvolvimento da empresa de dispositivos móveis objeto deste artigo, onde se implantou o Capability Maturity Model Integration (CMMI) [Chrissis, Konrad e Shrum 2005] de 2004 a 2006, a ISO 9001:2000 [ABNT 2001] e o processo Scrum [Schwaber e Beedle 2002] a partir de Sendo estes dois últimos o foco deste artigo. De acordo com [Land e Walz 2006], a ISO 9001 é um padrão genérico de gerenciamento da qualidade com uma abordagem baseada em gerenciamento de processos que tem como princípios: foco no cliente, liderança, envolvimento de pessoas, abordagem em processos, abordagem de gerenciamento sistemática, melhoria contínua, abordagem factual para tomada de decisão e relacionamento de benefício mútuo entre fornecedores. Esta norma é descrita em [ABNT 2001]. Segundo [Schwaber 359

360 e Beedle], o Scrum é um processo ágil que pode ser usado para gerenciar e controlar o desenvolvimento de softwares e produtos complexos utilizando práticas iterativas e incrementais. Este processo tem sido usado por projetos simples para mudar a forma como as corporações fazem negócios e aumentar a produtividade de forma significativa, enquanto facilita o desenvolvimento de sistemas empíricos e adaptativos. A empresa iniciou os trabalhos na área de qualidade no desenvolvimento de software em 2004, quando foi aberto um projeto para definição de processos aderentes ao modelo CMMI desenvolvido pela Siemens Corporate Tecnology [Siemens CT 2008], que, segundo [Messer et al 1998], é uma mistura dos modelos CMMI e BOOTSTRAP, junto com refinamentos e extensões específicos da Siemens, especialmente para as disciplinas de engenharia. Em 2005, a empresa obteve a certificação CMMI Nível 2.5, avaliada pela Siemens Corporate Research [Siemens USA 2008]. O trabalho para obter esta certificação é relatado em [Santos Jr. e Yellayi 2007]. Em 2006, a empresa obteve a certificação ISO 9001:2000 utilizando os processos aderentes ao CMMI. Nesta época, aproximadamente 400 profissionais de 7 institutos trabalhavam em projetos de desenvolvimento de software para dispositivos móveis. Apesar de a empresa ter processos aderentes ao CMMI, a certificação na ISO 9001:2000 foi necessária por dois motivos: (1) deixar claras as interfaces de comunicação entre os processos do departamento de pesquisa e desenvolvimento e os de outros departamentos da empresa; (2) exigências do órgão regulamentador da área de dispositivos móveis, a ANATEL (Agência Nacional de Telecomunicações). Em 2006, devido a mudanças estratégicas que tornaram os processos existentes impraticáveis, a empresa passou a utilizar métodos ágeis no desenvolvimento de software, em especial o processo Scrum, com o objetivo de ganhar agilidade e manter a qualidade do software. Foram realizados vários treinamentos a respeito deste método e 17 profissionais obtiveram o certificado CSM (Certified Scrum Master) [Ruby 2007]. Todos os novos projetos da empresa passaram a trabalhar com base no processo Scrum, e a maioria desses projetos (71%) obteve resultados expressivos em ganho de produtividade, realizando entregas em prazos mais curtos, comparado aos prazos praticados anteriormente. Entretanto, não havia padronização no uso do processo Scrum, em especial nos artefatos, e o processo não estava documentado. Sendo assim, um novo projeto para definir processos baseados no Scrum e aderentes à ISO 9001:2000 foi iniciado, com o apoio do diretor do departamento de pesquisa e desenvolvimento que o considerou de alta prioridade. Neste artigo é apresentado o procedimento usado pelo departamento de pesquisa e desenvolvimento de uma empresa de dispositivos móveis para desenvolver um processo que une as cláusulas 7.2.x e 7.3.x do padrão ISO 9001:2000 ao processo ágil Scrum, a partir da experiência em 13 projetos utilizando este método ágil, aumentando sua produtividade em desenvolvimento de software e obtendo 100% de aderência ao padrão. Na seção 2 é descrito o procedimento utilizado para desenvolver o processo, bem como os resultados obtidos em cada ação do procedimento, na seção 3 são apresentados os resultados alcançados após a institucionalização do processo, as conclusões e recomendações. Por simplicidade, os termos usados no processo Scrum serão mantidos em inglês. Por não haver espaço, o processo resultante do procedimento 360

361 aqui descrito não será apresentado neste artigo, o mesmo será tema de outro artigo no futuro. 2. Desenvolvimento do Processo Nesta seção será apresentado o procedimento usado para definir o novo processo de desenvolvimento de software aderente à ISO 9001:2000, baseando-se na experiência do departamento de pesquisa e desenvolvimento da empresa no uso do processo ágil Scrum. Para atingir esse objetivo, foi aberto um projeto de melhoria de processos tendo como participantes: (a) CGI (Coordenador de Gestão Integrada): líder do projeto e responsável pela definição de processos aderentes à ISO 9001:2000 e pela manutenção do Sistema de Gestão Integrada dentro de seu departamento; (b) Scrum masters: responsáveis por assegurar que os valores, práticas e regras do processo Scrum sejam cumpridos, gerenciando as ações de cada membro da equipe. O Scrum master compara o real progresso da produção de software com o planejado e também identifica e resolve as necessidades do time [Schwaber and Beedle 2002]; e (c) Diretor do Departamento: responsável pela definição e cumprimento dos objetivos do departamento. O projeto iniciou-se com uma reunião de kick-off, na qual foram abordados os seguintes tópicos: Importância e motivação para buscar a ISO 9001:2000: era fundamental que todos os participantes estivessem alinhados quanto à importância deste projeto, já que a empresa poderia perder sua licença para produzir dispositivos móveis caso não fosse certificada no padrão ISO 9001:2000. Macro processo aderente às cláusulas 7.2.x e 7.3.x da ISO 9001:2000: percebeu-se que o macro processo existente, aderente à ISO 9001:2000 e ao CMMI, poderia ser reaproveitado, visto que era simples e fazia conexão das atividades gerais de desenvolvimento a 14 processos aderentes ao CMMI. Sugestão de mudanças no macro processo: observou-se que a conexão para os processos aderentes ao CMMI deveria ser retirada, pois estes processos já não eram mais necessários após as mudanças na empresa. Ações sugeridas para o projeto: após um brainstorming sobre as ações a serem tomadas, foram apresentadas várias sugestões para atingir a ISO 9001:2000, entre elas: (a) escrever novas instruções de trabalho para detalhar as atividades do macro processo com base nas atividades já desempenhadas nos projetos; (b) escrever uma instrução de trabalho contendo o processo Scrum; (c) fazer uma análise crítica, em relação à ISO 9001:2000, das atividades desempenhadas em todos os 13 projetos dos Scrum masters presentes à reunião. Durante o desenvolvimento do novo processo, foi utilizado o procedimento descrito na Figura

362 Figura 1. Procedimento usado para a definição do novo processo Nas subseções a seguir, cada uma das ações definidas nesse procedimento é apresentada em mais detalhes, bem como os resultados alcançados. Aqui será utilizado o termo ação, ao invés de atividade, para que não haja confusão com as atividades definidas para o novo processo de desenvolvimento de software Ação 1: Identificar as atividades e os artefatos relacionados ao macro processo O CGI elaborou um documento, mostrado na Tabela 1, contendo as atividades macro de desenvolvimento de software, e suas respectivas fases. Este documento foi enviado aos Scrum masters para que preenchessem as colunas referentes a projetos com os artefatos que evidenciavam a execução das atividades correspondentes, devolvendo-as ao CGI em seguida. Este deu assistência aos Scrum masters no preenchimento das tabelas, quando necessário, e as revisou quanto a inconsistências. As inconsistências foram resolvidas pelos Scrum masters assim que informadas. A compilação desses dados é descrita na próxima subseção. Tabela 1. Formulário de aderência dos projetos ao macro processo Scrum master: Fase Entrada de projetos Análise Crítica Planejamento do Projeto João da Silva Atividade P&D recebe requisitos internos ou externos para um novo projeto Análise de Requisitos Estudo de viabilidade do projeto Estimativa inicial de custo e prazo Solicita aprovação da realização do projeto Recebe aprovação para realização do projeto Planejamento do Projeto Requisitos do projeto são detalhados e aceitos Acompanhamento das etapas e atividades previstas no Análise de Projeto plano de projeto Aceitação Final e Entrega do produto Saída, Verificação Teste de Componenetes e Validação Teste de Sistemas Implementação e Correção de Bugs Recebe solicitação de alteração no Projeto Alteração de Avaliação de Impacto projeto Decisão com Change Control Board (CCB) Realização alterações e adequações necessárias Projetos 2.2. Ação 2: Obter a freqüência das atividades e artefatos identificados Com base na compilação das tabelas enviadas pelos Scrum masters, o CGI elaborou a Tabela 2 com o objetivo de identificar a freqüência de uso dos artefatos e a aderência dos projetos às atividades do macro processo, e consequentemente à ISO 9001:2000. Tabela 2. Artefatos mais usados em cada atividade e sua respectiva freqüência 362

363 Fase Atividade Aderência Artefatos mais usados Freqüência Entrada de P&D recebe requisitos internos ou externos para um novo projetos projeto 77% Product Backlog 46% Análise de Requisitos 100% Product Backlog 54% Estudo de viabilidade do projeto 38% 0% Análise Crítica Estimativa inicial de custo e prazo 46% Proposta 31% Solicita aprovação da realização do projeto 77% Gforge/ 62% Recebe aprovação para realização do projeto 62% Gforge/ 54% Planejamento Planejamento do Projeto 92% Sprint Backlog 62% do Projeto Requisitos do projeto são detalhados e aceitos 92% Product Backlog 62% Análise de Acompanhamento das etapas e atividades previstas no Projeto plano de projeto 92% Sprint Backlog 69% Saída, Verificação e Validação Alteração de projeto Aceitação Final e Entrega do produto 85% 31% Teste de Componenetes 46% Informal/Não realizado 54% Teste de Sistemas 38% Informal/Não realizado 62% Implementação e Correção de Bugs 85% Gforge 62% Recebe solicitação de alteração no Projeto 69% Informal 31% Avaliação de Impacto 62% Informal 31% Decisão com o Change Control Board (CCB) 0% 0% Realização alterações e adequações necessárias 69% Sprint Planning 31% Na Tabela 2, a coluna aderência identifica o percentual de projetos que realizaram a atividade, já a coluna freqüência identifica a freqüência com que os artefatos mais usados são usados nos projetos. A análise desses dados e as ações tomadas para solucionar os gaps encontrados são descritas na próxima subseção Ação 3: Fazer análise crítica do uso dessas atividades nos projetos Para fazer a análise crítica, foram realizadas três reuniões com duração média de 1,5h cada, tendo a presença do CGI, dos Scrum masters e de um representante da área de testes. O objetivo foi identificar os gaps entre as atividades realizadas pelos projetos e as atividades do macro processo, bem como definir as ações para cobrir os gaps, e, desta forma, obter 100% de aderência à ISO 9001:2000. O resultado da análise crítica do processo são os itens de ação mostrados na Tabela 3. Tabela 3. Itens de ação resultantes da análise crítica e comparação das atividades do processo com a ISO 9001:2000 e o processo ágil Scrum Atividade Itens de ação Cláusula ISO Scrum P&D recebe requisitos internos ou - Armazenar a requisição ( ). externos para um novo projeto 7.2.3, Análise de Requisitos - Usar o product backlog + documento para a análise de requisitos. Este último documento será chamado "Requirement Specification" com três capítulos: , X Introduction; 2. Requirements 3. Supporting information. Estudo de viabilidade do projeto - Usar um documento de estudo de viabilidade, chamado "Feasibility Study", com pelo menos dois capítulos: 1. Study Information; 2. Recommendations , Estimativa inicial de custo e prazo - Usar o documento "Feasibility Study". No capítulo 2 acrescentar os seguintes subcapítulos: cost, schedule e effort , 7.3.1, Solicita aprovação da realização do - Criar o documento "Project Approval", que será enviado ao requisitante para projeto aprovação do projeto, com o estudo de viabilidade em anexo Recebe aprovação para realização do - Receber o documento "Project Approval" assinado pelo requisitante e armazená-lo projeto numa pasta , Planejamento do Projeto - Usar sempre o product backlog 7.2.3, X Requisitos do projeto são detalhados e - Usar o product backlog. Quando o product owner escolhe os requisitos a serem aceitos realizados em um sprint, ele está aceitando os mesmos , X Acompanhamento das etapas e - Usar o sprint backlog , 7.3.1, atividades previstas no plano de projeto X Aceitação Final e Entrega do produto - Criar um template de "Software/Product Approval", com assinatura do solicitante. - Requisitos do product backlog escritos como 'done' ou 'cancelados' , 7.3.3, Teste de Componenetes - Não usar teste de componentes. Unir com teste de sistema. - Teste de Sistemas - Utilizar planilha "Test Management", contendo os casos de testes e o resultado da execução dos testes e a ferramenta Bug Tracker do Gforge para cadastrar os bugs , Implementação e Correção de Bugs - O próprio código fonte e exeutável é evidência de implementação. - Usar a ferramenta Bug Tracker do Gforge para acompanhar a correção de bugs Recebe solicitação de alteração no - O Scrum cobre esta atividade. O product owner pode a qualquer momento acrescentar 7.2.3, 7.3.2, Projeto requisições novas ao product backlog X Avaliação de Impacto - O Scrum cobre esta atividade. Durante a sprint planning meeting, o time avalia o 7.2.2, 7.3.3, impacto dos product backlog items no projeto X Decisão com o Change Control Board (CCB) - CCB será eliminado. Durante o sprint planning, o time indica os product backlog items que se comprometem a realizar durante o sprint e isso é aprovado ou não pelo product owner - X Realização alterações e adequações necessárias - Atividade feita dentro de um sprint , 7.3.4, X

364 Nas reuniões, o CGI apresentou, um a um, todos os itens descritos na Tabela 2, mostrando os pontos fortes e fracos encontrados, bem como sugestões de ação para cobrir os gaps. Os pontos fortes e fracos e as ações sugeridas eram discutidos por todos os participantes e, ao fim das discussões, definia-se a ação a ser tomada (coluna Itens de ação, da Tabela 3), com base no consenso. O critério adotado para chegar ao consenso era de que os itens de ação fossem simples de implementar e que gerassem processos e artefatos úteis e fáceis de usar. Para as atividades parcialmente ou não cobertas pelo Scrum, o CGI responsabilizou-se por elaborar os novos formulários: Especificação de Requisitos, Estudo de Viabilidade, Aprovação do Projeto, Aprovação do Produto/Software e Gerência de Testes, cabendo aos Scrum masters a tarefa de revisálos. Para gerenciar os bugs, foi utilizada a ferramenta [GForge 2008], especificamente seu módulo bug tracker. Para gerenciar o product backlog e sprint backlog [Schwaber e Beedle 2002], foi utilizada a ferramenta ScrumWorks Basic Edition [Scrumworks 2000]. Adicionalmente foram acrescentadas à tabela original as colunas Cláusula ISO e Scrum. A primeira mostra as cláusulas da ISO 9001:2000 atendidas pelas atividades, de acordo com a avaliação feita pelo CGI, e a segunda aponta as atividades já cobertas pelo processo Scrum. É válido destacar que o processo Scrum descrito por [Schwaber e Beedle 2002] não define documentos, mas de acordo com [Larman 2004] este processo permite o uso de documentos padrão, desde que seja uma necessidade apontada pelo cliente. As ações de descrição dos processos são apresentadas na próxima subseção Ação 4: Elaborar e apresentar proposta de processo baseada na análise crítica No Sistema Integrado de Gestão (SIG) da empresa já estavam definidos o processo de aprovação de processos e os formulários padrão para descrevê-los. Os formulários de descrição de processos são: (a) Manual de Processos (MP): descreve objetivos, estrutura e processos internos de um departamento; (b) Instrução de Trabalho (IT): descreve em detalhes atividades específicas de cada departamento; (c) Indicadores: apresentam as métricas do departamento, bem como as metas a serem alcançadas. O MP do departamento de pesquisa e desenvolvimento foi atualizado com o novo macro processo, novos formulários e referências às ITs (descritas a seguir), de acordo com os resultados da análise crítica. Na IT Testes de Sistema, a equipe de testes e o CGI descreveram em detalhes as atividades de testes, desde a especificação até a apresentação dos resultados, passando pela execução dos testes. Também foram descritos os formulários e ferramentas utilizados. Na IT Desenvolvimento de Software com o Processo Scrum, o CGI escreveu o processo exatamente como descrito por [Schwaber e Beedle 2002], acrescentando os formulários e ferramentas utilizados pela empresa. Quanto aos indicadores, foram mantidos os de Desvio de Custo e Desvio de Prazo, para acompanhamento. A meta definida foi que os projetos só tivessem 10% de desvio, sendo tomadas ações corretivas caso a meta não fosse alcançada. Depois de elaborados, os três documentos foram enviados aos Scrum masters e à equipe de testes para revisão, retornando ao CGI para correção e posterior envio ao departamento de Garantia da Qualidade para aprovação e divulgação, que são os assuntos da próxima subseção. 364

365 2.5. Ação 5: Revisar, aprovar e divulgar o novo processo O Sistema Integrado de Gestão (SIG) da empresa já definia o processo de aprovação e divulgação dos Manuais de Processos e Instruções de Trabalho, sendo assim, o mesmo foi utilizado para este fim. Após a revisão das Instruções de Trabalho e do Manual de Processos pelos Scrum masters e a equipe de testes, os mesmos foram enviados para o departamento de Garantia da Qualidade (que controla o SIG), que revisou os documentos quanto a conflitos com outros departamentos e inconsistências. Em seguida, os documentos foram enviados para o Diretor do departamento de Pesquisa e Desenvolvimento para revisão final e aprovação, seguida da divulgação dos documentos no Portal do SIG ferramenta da intranet contendo todas as informações para divulgação e controle do Sistema Integrado de Gestão. Após a divulgação dos documentos, iniciaram-se as atividades de treinamento, descritas na próxima subseção Ação 6: Realizar treinamentos do novo processo A experiência do ano anterior no treinamento de Gestão da Qualidade e Ambiental mostrou que era mais produtivo ter no máximo seis participantes por turma, portanto foram oferecidas 10 sessões de treinamento com duração de duas horas cada, todas com o mesmo conteúdo: o Sistema Integrado de Gestão (SIG), a ISO 9001:2000 e todos os processos do departamento. Neste treinamento foram usados o Portal do SIG, uma apresentação em PowerPoint sobre a ISO 9001:2000, o Manual de Processos, as Instruções de Trabalho e os formulários relativos ao departamento de pesquisa e desenvolvimento. Para realizar o treinamento, o instrutor, neste caso o CGI, seguiu o procedimento relativo a treinamentos do departamento de Recursos Humanos (RH). Após os treinamentos, o CGI passou a acompanhar os projetos quanto ao uso dos novos processos, o que será descrito na próxima subseção Ação 7: Acompanhar o uso do processo nos projetos O acompanhamento dos projetos pelo CGI diz respeito à consultoria no uso dos processos e à revisão dos artefatos gerados. O CGI participou das reuniões sprint planning e de algumas daily meetings dos projetos Scrum para orientar as equipes no uso dos novos processos. A revisão dos artefatos se dava sempre após sua conclusão pelo autor, seguida de sua correção, antes de sua publicação. Durante as revisões foram avaliadas a aderência dos artefatos ao processo, consistência com o objetivo a ser alcançado, sintaxe e gramática. O acompanhamento foi de fundamental importância para a institucionalização do novo processo, visto que através desta atividade os desenvolvedores puderam identificar e corrigir suas falhas no uso do processo, e, consequentemente, a aderência dos projetos ao processo aumentou significativamente. Os projetos em andamento após a publicação do novo processo realizaram um retrabalho para adaptá-los aos novos processos, visto que todos já tinham a informação descrita em outros documentos. O CGI realizou a ação 7 em todos estes projetos. 3. Conclusão e recomendações O desenvolvimento do processo envolveu um grupo de nove Scrum masters (incluindo o CGI) e partiu da premissa de que, no Scrum, o time é responsável por definir as atividades necessárias para cumprir os objetivos que lhes foram endereçados, portanto o 365

366 procedimento pode ser utilizado em qualquer instituição de desenvolvimento de software que já utilize o Scrum e que pretenda padronizar ou documentar seus processos de uma forma rápida e sistemática. O novo processo foi desenvolvido e institucionalizado em dois meses, obtendo alta aceitação pelos desenvolvedores. [McMichael e Lombardi 2007] também desenvolveram um processo usando o processo Scrum e a ISO 9001:2000, no prazo de 1 ano mas sem o objetivo de obter a certificação neste padrão. Após a institucionalização do novo processo, a equipe de desenvolvimento ganhou novos artefatos úteis para documentar seus trabalhos, utilizando-os em todos os novos projetos. O desempenho dos projetos já era alto antes da padronização dos processos e se manteve após a institucionalização, o que foi comprovado pelos indicadores Desvio de Prazo e Desvio de Custo. Na auditoria interna da ISO 9001:2000, o departamento de pesquisa e desenvolvimento obteve aderência de 92%, sendo as não conformidades corrigidas em menos de uma semana. Na auditoria externa, a empresa obteve a re-certificação ISO 9001:2000, tendo o departamento de pesquisa e desenvolvimento alcançado 100% de aderência nas cláusulas 7.2.x e 7.3.x da norma, que fazem parte de seu escopo. As instituições que desejam obter o certificado ISO 9001:2000 utilizando este procedimento devem implementar processos aderentes às outras cláusulas, o que já estava implementado na empresa de dispositivos móveis. Referências ABNT (2001) NBR ISO 9001 Sistemas de Gestão da Qualidade Requisitos. ABNT CE-25: Comissão de Estudos de Sistemas da Qualidade, Brasil. Chrissis, M., Konrad, M. e Shrum, S. (2003) CMMI(R): Guidelines for Process Integration and Product Improvement. 2nd Edition. The SEI Series in Software Engineering. Addison Wesley Press, United States. GForge (2008) GForge Collaborative Development Environment. Março, Land, S. e Walz (2006) Practical Support for ISO 9001 Software Project Documentation. IEEE Computer Science, John Wiley and Sons Inc., United States. Larman, Craig (2004) Agile and Iteractive Development: a manager s guide, Pearson Education Inc., United States. McMichael, B. e Lombardi, M (2007) ISO 9001 and Agile Development, In Agile 2007 Conference (Agile 2007), pp , IEEE Computer Society, ISBN Messer, T. et Al (1998) Siemens Process Assessment and Improvement Approaches: Experiences and Benefits, In Computer Software and Applications Conference, COMPSAC '98 Proceedings. The Twenty-Second Annual International Aug. 1998, pp , DOI /CMPSAC Ruby, K. (2007) Scrum Alliance Certifications, Março,

367 Santos Jr., A. F. e Yellayi, S. (2007) Software Process Improvement in an outsourced EPG environment, In SEPG th annual SEPG, United States. Schwaber, K. e Beedle, M. (2002) Agile Software Development with Scrum, Prentice Hall. United States. Scrumworks (2008) ScrumWorks - Scrum Lifecycle Management Tools, Danube Technologies. Março, Siemens CT (2008) Siemens AG Corporate Technology. Março, Siemens USA (2008) Siemens USA Siemens Corporate Research, Março,

368 368

369 Inspeção de Usabilidade em Organizações de Desenvolvimento de Software Uma Experiência Prática Verônica T. Vaz 1, Tayana Conte 2, Andrew Bott³, Emilia Mendes 4, Guilherme H. Travassos 1 1 PESC COPPE/UFRJ, Cx Postal , CEP , Rio de Janeiro, RJ, Brasil 2 DCC UFAM, CEP , Manaus, AM, Brasil ³Fundação COPPETEC, Ilha do Fundão , Rio de Janeiro, RJ, Brasil 4 Computer Science Department, The University of Auckland, Private Bag 92019, Auckland, New Zealand veronica.taquette@ufrj.br, {tayana, ght}@cos.ufrj.br, andrew@coppetec.coppe.ufrj.br, emilia@cs.auckland.ac.nz Abstract. Users acceptability of Web applications relies strictly on these applications usability, which can be improved through the use of inspections. This paper reports an industrial case study of usability inspection, where developers and requirements assessors applied an inspection technique to evaluate the usability of newly developed modules. The results of this case study indicate the feasibility of performing usability inspections with the participation of a software project s stakeholders, even when stakeholders are not usability experts. Resumo. A aceitabilidade das aplicações Web por seus usuários depende diretamente da usabilidade da aplicação, que pode ser melhorada através da realização de inspeções. Neste artigo relatamos um caso prático de inspeção de usabilidade, no qual desenvolvedores e avaliadores de requisitos utilizaram uma técnica de inspeção para a avaliação de módulos recém-desenvolvidos. Os resultados desta experiência indicam a viabilidade de se realizarem inspeções de usabilidade com os próprios stakeholders de um projeto de software, mesmo que estes não sejam especialistas em usabilidade. 1. Introdução A norma ISO/IEC 9126 (1999) classifica usabilidade como um dos seis atributos de qualidade de software e a define como capacidade que o software tem de ser entendido, usado e aprendido, e também sua capacidade de agradar ao usuário, quando utilizado sob condições específicas. No caso específico de aplicações Web, a importância da usabilidade é ainda maior se comparada à maioria das aplicações de software tradicionais, devido às suas próprias características, pois aplicações Web são aplicações interativas, centradas no usuário e baseadas em hipermídia, onde a interface com o usuário desempenha um papel central [Olsina et al., 2006]. De acordo com Matera et al. (2006) a aceitabilidade de aplicações Web pelos usuários depende estritamente da usabilidade da aplicação. Caso seja difícil alcançar um objetivo qualquer devido à baixa usabilidade da aplicação Web, provavelmente ela será rapidamente substituída por outra mais usável, assim que sua existência for conhecida pelo público alvo [Mendes et al., 2006]. Devido à relevância da usabilidade, a indústria de desenvolvimento de software está investindo em projetos e avaliações que ajudem a melhorar esse quesito de qualidade em suas aplicações Web [Dix et al., 2004]. Neste sentido, este artigo 369

370 apresenta e relata a experiência com uma técnica de inspeção de usabilidade específica para aplicações Web chamada WDP, que pode ser empregada pelos próprios stakeholders de projetos de software na avaliação de usabilidade do software produzido. O artigo relata uma experiência prática de inspeção de usabilidade, no qual desenvolvedores e avaliadores de requisitos utilizaram a técnica em questão para a avaliação de módulos recém-desenvolvidos. O objetivo deste artigo é descrever como foi executada essa inspeção e analisar seu custo-eficiência, de forma a fornecer informações que possam incentivar outras empresas de desenvolvimento a realizar avaliações de usabilidade, e utilizar a técnica WDP. O restante do artigo está organizado da seguinte forma: a Seção 2 apresenta um breve referencial teórico sobre avaliações de usabilidade, assim como a técnica de inspeção utilizada nesse estudo de caso. A Seção 3 descreve a inspeção de usabilidade executada, detalhando suas etapas e papéis envolvidos. A Seção 4 discute os resultados obtidos com a inspeção. Por fim, a Seção 5 apresenta as conclusões e lições aprendidas com essa experiência prática. 2. Avaliações de Usabilidade e a Técnica WDP Os métodos de avaliação de usabilidade podem ser divididos em duas grandes categorias: (1) Inspeções de Usabilidade, que são métodos de avaliação baseados em análises de especialistas, que utilizam técnicas para descobrir os possíveis problemas que um usuário terá ao utilizar a aplicação em questão; e (2) Métodos de avaliação baseados na participação direta de usuários (também chamados de Testes de Usabilidade), tais como: Estudos em Laboratórios de Usabilidade, Think Aloud, Avaliação Cooperativa, Monitoração de Respostas Fisiológicas [Dix et al., 2004]. Inspeções de usabilidade são naturalmente menos custosas do que os métodos de avaliação baseados na participação do usuário, uma vez que não são necessários equipamentos ou laboratórios especiais para sua realização, apenas profissionais com bom conhecimento de usabilidade [Garzotto et al. 1999]. Diferentes técnicas de inspeção de usabilidade têm sido propostas, tais como: Avaliação Heurística [Nielsen 1994], Walkthrough Cognitivo [Polson et al., 1992], Checklists [Dix et al., 2004] e UBR [Zhang et al., 1999]. De acordo com Zhang et al. (1999), é difícil para cada inspetor detectar todos os diferentes problemas de usabilidade ao mesmo tempo. Por esta razão, Zhang et al. (1999) propuseram uma técnica de inspeção de usabilidade baseada em perspectiva (UBR), na qual cada sessão de inspeção foca em um subconjunto de questões de usabilidade cobertas por uma perspectiva de usabilidade. A suposição ao se utilizar inspeções baseadas em perspectiva é que, graças ao foco, cada sessão de inspeção possa detectar um maior percentual de problemas relacionados à perspectiva utilizada e que a combinação de diferentes perspectivas possa encontrar mais problemas que a combinação do mesmo número de sessões de inspeção utilizando uma técnica de inspeção geral [Zhang et al., 1999]. Com base nesses fatos, elaboramos nova proposição na qual testamos se a adoção de perspectivas também torna a avaliação heurística [Nielsen 1994] mais eficiente para a inspeção de usabilidade de aplicações Web. Para isto propomos a utilização de perspectivas próprias de projeto Web: Apresentação, Conceituação e Navegação [Conte et al., 2007b], e as empregamos como um guia para interpretar as 370

371 heurísticas de Nielsen com foco específico em aplicações Web. Esta técnica derivada é denominada Web Design Perspectives-based Usability Evaluation (WDP). A Tabela 1 apresenta as definições de cada perspectiva de projeto Web e o foco relacionado nas avaliações de Usabilidade. Em adição, a Figura 1 mostra um exemplo de um extrato da técnica WDP em sua versão atual. Tabela 1- Perspectivas de Projeto Web utilizadas na Avaliação de Usabilidade Perspectivas de Projeto Web Conceituação Representação dos elementos conceituais (negócio, problema, etc) que compõem o domínio da aplicação. Apresentação Representa as características relativas à programação visual e ao layout da interface, definindo como as informações serão apresentadas aos usuários. Navegação Representa o espaço navegacional, definindo os elementos de acesso e suas associações usados na exploração das informações. Foco na Usabilidade Foco na clareza e concisão dos elementos do domínio do problema. Sob essa perspectiva, a usabilidade é satisfatória se a representação é facilmente compreendida pelo usuário e não o leve a cometer erros por causa de termos ambíguos, inconsistentes ou desconhecidos. Foco na consistência da apresentação de informações ao usuário. Sob essa perspectiva, a usabilidade é satisfatória caso a programação visual e o layout da interface permitam ao usuário realizar suas tarefas de maneira eficaz, eficiente e agradável. Foco na acessibilidade das funcionalidades do sistema pelos diferentes tipos de usuários. Sob essa perspectiva, a usabilidade é satisfatória se as opções de navegação do sistema permitem aos usuários realizarem suas tarefas de maneira eficaz, eficiente e agradável. Excluído: Tab Excluído: Figu [...] Perspectiva: Apresentação A.4 Consistência e padrões Avalie se a terminologia, gráficos e símbolos da interface estão consistentes. Avalie se há aderência a convenções de plataforma e padrões de interface adotados em relação a layout, formatação e controles. Avalie se há consistência de interfaces para tarefas que são equivalentes. Figura 1 - Extrato da Técnica WDP v4 A técnica WDP tem sido desenvolvida através de uma metodologia baseada em experimentação [Shull et al., 2001], [Mafra et al., 2006]. Esta metodologia propõe uma seqüência de estudos experimentais e atividades de refinamento da técnica com o objetivo de facilitar a transferência da técnica da academia para a indústria de forma segura. Até o presente momento, já foram executados cinco estudos experimentais no escopo do desenvolvimento da WDP: um estudo secundário (uma revisão sistemática) [Conte et al., 2005], dois estudos de viabilidade [Conte et al., 2007a], [Conte et al., 2007b], um estudo de observação e um estudo de caso de ciclo de vida real. Os resultados dos estudos indicam a necessidade de abordagens para garantia de qualidade de aplicações Web e a viabilidade e possibilidade da técnica WDP ser duas vezes mais eficaz e tão eficiente quanto a Avaliação Heurística [Nielsen 1994]. O presente artigo relata parte dos resultados obtidos com o estudo de caso de ciclo de vida real. 3. Caracterização do Projeto e da Inspeção de Usabilidade 3.1. Projeto de Desenvolvimento Incremental do SiGIC O SiGIC Sistema de Gerenciamento Integrado COPPETEC, objeto do estudo descrito neste artigo, é um projeto de desenvolvimento de um novo sistema Web para 371

372 gerenciamento das atividades da Fundação COPPETEC 1. Este projeto foi estruturado em um modelo de desenvolvimento incremental, com a liberação parcial de funcionalidades, de forma a substituir gradualmente o atual sistema em operação na Fundação. A especificação deste sistema se baseia na descrição de casos de uso. Atualmente o sistema é composto de 58 casos de uso, estando dividido em três módulos: o MGU Módulo de Gestão de Usuários (7 casos de uso), o MSL Módulo de Solicitações (27 casos de uso) e o MPT Módulo de Protocolo (24 casos de uso). Estes três módulos foram objeto do processo de inspeção de usabilidade Executando a Inspeção de Usabilidade O processo de inspeção foi dividido em cinco atividades, tendo por base o processo sugerido por Sauer et al. (2000). As atividades e os papéis que compõem o processo de inspeção de usabilidade utilizado são apresentados resumidamente a seguir: Planejamento Detecção Coleção Discriminação Análise e priorização Líder da Inspeção (ou Moderador) Responsável pelo Sistema Inspetores Tabela 2 - Atividades e papéis do Processo de Inspeção Atividade onde é feita a definição do escopo da inspeção (escolha das principais interações nos módulos), preparação do material para a inspeção, seleção dos inspetores, treinamento dos inspetores na técnica WDP e atribuição das tarefas a cada inspetor. Cada inspetor executa individualmente essa atividade, a qual consiste na busca de problemas de usabilidade nas interações selecionadas. Eliminação de discrepâncias repetidas (encontradas por mais de um inspetor), gerando uma lista de discrepâncias únicas (sem duplicatas). Classificação das discrepâncias em defeitos reais. As discrepâncias não classificadas como defeitos são consideradas falso-positivos. Análise da gravidade dos defeitos e definição de prioridades de correção. Responsável pela execução do processo de inspeção como um todo e por atividades específicas, como a coleção. Esse papel foi exercido por um desenvolvedor da equipe do projeto, com conhecimento sobre avaliações de usabilidade e com experiência no uso da técnica WDP. Papel do gerente técnico do projeto. Este papel não participa da detecção das discrepâncias, porém atua decisivamente na classificação dos defeitos e falsopositivos (discriminação) e na análise e priorização dos defeitos. Responsáveis pela detecção das discrepâncias. Foram selecionados como inspetores 04 desenvolvedores da equipe do projeto (com experiência em desenvolvimento entre 6 meses e 7 anos) e 02 avaliadores de requisitos do mesmo (ambos com mais de 20 anos de experiência na organização). Eles também participam da etapa de discriminação. Planejamento - Primeiramente foram selecionadas as opções do sistema que seriam objeto da avaliação de usabilidade. A seleção das opções a serem inspecionadas foi baseada na especificação dos casos de uso do sistema. Os critérios de seleção tinham por base o tipo de interação do caso de uso e por qual ator este é executado. Além disso, foram eliminados casos de uso com interação muito semelhante. Para os três módulos do sistema foram selecionados no total 19 casos de uso (aproximadamente 33% do total) divididos em três grupos, de acordo com o tipo de funcionalidade. Foram atribuídos dois inspetores para realizar a detecção de discrepâncias em cada grupo de funcionalidades. A divisão dos inspetores por grupo foi realizada de forma que um mesmo caso de uso fosse inspecionado por perspectivas complementares na identificação de defeitos. Outro critério utilizado foi evitar que um desenvolvedor inspecionasse um caso de uso por ele implementado. Em seguida, o líder preparou 1 Fundação Coordenação de Projetos, Pesquisas e Estudos Tecnológicos

373 descrições de alto nível das interações para cada caminho crítico dos casos de uso selecionados, tendo como base o documento de especificação dos casos de uso que já havia sido previamente avaliado a partir da apresentação de protótipos de interação. Essas descrições foram feitas de forma a guiar minimamente o inspetor, simulando a utilização do sistema em condições reais. Não se utilizou a própria descrição dos casos de uso por estas serem muito detalhadas e informarem previamente ao inspetor como o sistema irá se comportar para cada ação. Acreditamos que a utilização dessas descrições pudesse resultar em um pior desempenho na detecção de discrepâncias. O líder também fez a preparação da base de dados de inspeção, com os dados que seriam necessários às interações avaliadas. Por fim foi feita a capacitação dos inspetores na utilização da técnica WDP. Como os inspetores possuíam diferentes perfis, esta capacitação foi dividida em dois treinamentos, um para os desenvolvedores e outro para os avaliadores de requisitos. Cada treinamento teve duração de uma hora. Detecção - Nesta atividade, os inspetores executavam as interações descritas, e relatavam as discrepâncias encontradas numa planilha, preenchendo as seguintes informações: Atividade (denominação da Interação descrita), Passo da atividade, Par Heurística x Perspectiva (HxP) relacionado ao problema, Descrição do problema e Grau de Severidade (seguindo a escala proposta por Nielsen (1994)). Um dos avaliadores de requisitos não realizou a inspeção, devido à necessidade de executar outras atividades profissionais durante o período da detecção. Coleção - Após receber as planilhas com as discrepâncias enviadas por cada inspetor, o líder da inspeção comparou as planilhas dos inspetores do mesmo grupo, verificando a existência de duplicatas, ou seja, uma mesma discrepância sendo reportada por mais de um inspetor. Muitas vezes foram reportadas discrepâncias semelhantes, mas que se referiam a casos de uso diferentes. Estas não foram consideradas duplicatas. Discriminação - Foi realizada uma reunião de discriminação para cada grupo, onde estavam presentes: o líder de inspeção, o responsável pelo sistema e os inspetores do grupo em questão. Nessas reuniões, as interações avaliadas eram re-executadas, sendo assim possível verificar in-loco cada discrepância relatada. Após discussão da equipe, o responsável pelo sistema classificava a discrepância em defeito ou falso-positivo. Durante essas reuniões, surgiram discussões de como os defeitos seriam solucionados, gerando propostas de solução. Análise e priorização dos defeitos - Os defeitos foram analisados e priorizados da seguinte forma: resolução imediata, resolução postergada (por decisão de projeto) e resolução indefinida (defeitos cuja solução não havia sido proposta durante a reunião). Os defeitos de resolução imediata foram relatados em uma ferramenta de acompanhamento de defeitos, e estão sendo corrigidos. Os demais defeitos foram registrados para posterior solução. 4. Resultados Obtidos Um dos objetivos ao executar essa experiência foi observar se seria possível ter um bom aproveitamento da inspeção tendo como inspetores de usabilidade os próprios desenvolvedores e avaliadores de requisitos do projeto, dado que nenhum desses inspetores é um especialista em usabilidade. Quatro dos cinco inspetores que realizaram a detecção já possuíam experiência anterior em execução de algum tipo de inspeção. No 373

374 entanto apenas dois inspetores possuíam experiência prévia em execução de avaliações de usabilidade, havendo um deles já utilizado a técnica WDP. O resultado em relação a esse objetivo foi positivo, como pode ser constatado ao analisar as Tabelas 3 e 4. A Tabela 3 mostra para cada inspetor os tipos de experiência prévia que ele possuía (em relação a inspeções, avaliações de usabilidade e utilização da técnica WDP), o número de discrepâncias relatadas e quantas dessas discrepâncias foram classificadas como defeitos ou falso-positivos. E a Tabela 4 mostra os resultados gerais da inspeção. Inspetor Tabela 3 Caracterização dos Inspetores e Resultados da Inspeção Experiência inspeções Experiência avaliações usabilidade Experiência Técnica WDP Número Discrepâncias Número Falso- Positivos Número Defeitos 1 Não Não Não Sim Não Não Sim Sim Não Sim Não Não Sim Sim Sim Tabela 4 - Resultados Gerais da Inspeção de Usabilidade Resultados relacionados Total Percentual Discrepâncias Falso-Positivos 11 6,63% Defeitos ,37% Avaliando as Tabelas 3 e 4, é possível observar o baixo percentual de falsopositivos. Além dos resultados quantitativos, também foram realizadas entrevistas semiestruturadas com os inspetores, para que estes expressassem suas impressões com relação à inspeção de usabilidade e à utilização da técnica WDP. Os cinco inspetores afirmaram ter considerado a técnica fácil de aplicar e adequada à avaliação de usabilidade. Embora os resultados de uma única experiência não possam ser generalizados para outros contextos, o resultado qualitativo e quantitativo dessa inspeção é um indicador da viabilidade de utilização dos próprios membros da equipe de um projeto como inspetores em uma avaliação de usabilidade, utilizando-se a técnica WDP. A Figura 2 mostra a distribuição dos defeitos, após a classificação realizada na atividade de análise e priorização. Excluído: Tab Excluído: Tab Excluído: Figu Figura 2 - Distribuição dos Defeitos após Priorização de Resolução Como explicado anteriormente, os defeitos de resolução indefinida foram classificados como tal, por não terem surgido propostas de solução para estes durante as reuniões de discriminação. Observamos então, com base na Figura 2, que os defeitos de resolução indefinida representam apenas 5% do total, ou seja, para 95% dos defeitos foram feitas propostas de solução durante a própria reunião de discriminação. 374

375 Em termos de tempo e esforço, o período dado aos inspetores para a execução da detecção de discrepâncias foi de três dias úteis. Este prazo considera que todos os inspetores estavam envolvidos em outras atividades paralelas à inspeção, não sendo possível exigir que todos realizassem a detecção em um horário pré-determinado. O esforço médio efetivamente gasto por cada inspetor foi de aproximadamente 3 horas e 20 minutos. Em relação ao esforço na atividade de discriminação, foram realizadas três reuniões, sendo uma para cada grupo. As duas primeiras reuniões tiveram duração de duas horas cada, com a participação de quatro pessoas: o líder, o responsável e dois inspetores. Já a terceira reunião teve duração de 1 hora e meia, com a participação do líder, o responsável e um inspetor (já que um dos inspetores não realizou a detecção). Sobre os benefícios ao próprio projeto de desenvolvimento, além da melhora da usabilidade dos módulos inspecionados, a inspeção proporcionou uma melhoria do padrão de interação adotado, o que acarreta automaticamente benefícios em relação à usabilidade dos futuros módulos a serem desenvolvidos. E como resultado indireto, acreditamos que ocorreu aumento do conhecimento dos inspetores sobre usabilidade. 5. Considerações Finais Este trabalho apresentou o relato da execução de uma inspeção de usabilidade em um projeto de desenvolvimento de software. Pode-se observar que é viável realizar uma inspeção de usabilidade com os próprios desenvolvedores e avaliadores de requisitos de um projeto de software. O treinamento em uma técnica de inspeção que auxilie os inspetores a encontrar os defeitos de usabilidade diminui a dependência da expertise do inspetor, sendo esta dependência um dos maiores problemas ao aplicar inspeções de usabilidade [Garzotto et al. 1999]. Nessa experiência o custo da inspeção se mostrou baixo, pois o esforço médio de um inspetor, somando o esforço na atividade de detecção (3 horas e 20 minutos) e discriminação (1 hora e 50 minutos) foi de 5 horas e 10 minutos, e na detecção foram encontrados em média 31 defeitos por inspetor. A relação custo/ eficiência da inspeção foi de 9,3 defeitos/hora de inspeção por inspetor. Além disso, mesmo tendo ocorrido apresentações de protótipos de interação em etapas anteriores do projeto, a técnica WDP guiou os inspetores na identificação de problemas de usabilidade não capturados anteriormente, destacando assim a importância de sua utilização. Seria interessante comparar este resultado em termos de custo-eficiência com outras técnicas de avaliação de usabilidade. No entanto, é importante ressaltar a dificuldade de realizar tal comparação, uma vez que não faz sentido que um inspetor reinspecione um mesmo caso de uso, sendo necessário mudar o inspetor e/ou o objeto da inspeção, dificultando uma possível comparação dos resultados. Uma importante lição aprendida foi sobre a importância de realizar avaliações de usabilidade a partir do primeiro módulo pronto ou mesmo a partir do primeiro protótipo de interação definido. Quanto mais cedo se avalia a usabilidade, maior ganho; uma vez que o sistema siga um padrão de interação. No caso desta experiência que envolveu a avaliação de três módulos do sistema, podemos observar que em muitos casos o mesmo defeito foi encontrado em diferentes atividades. Isso aconteceu porque o defeito estava no padrão de interação adotado e não em uma interface específica de um módulo. No total, 29% dos defeitos relatados foram repetições de defeitos similares reportados ao executar outra atividade. 375

376 A condução dessa experiência nos levou a duas questões que devem ser observadas em novos estudos. A primeira questão é se a utilização da técnica WDP facilita a elaboração de propostas para a correção dos defeitos apontados. Essa questão já havia sido sugerida por alguns inspetores ao utilizar a técnica em inspeções anteriores. Nesta experiência, observamos que para 95% dos defeitos foram feitas propostas de solução durante a própria reunião de discriminação. No entanto é preciso avaliar o quanto o uso da técnica WDP efetivamente contribuiu nessas propostas. A segunda questão de pesquisa é se o aprendizado dos conceitos de usabilidade adquiridos pelos desenvolvedores durante a inspeção faz com que eles apliquem esse novo conhecimento em futuros desenvolvimentos. Caso seja possível obter uma resposta positiva para essa questão, então a técnica de inspeção de usabilidade também se mostraria eficiente como diretriz, colaborando diretamente para o projeto de interface. Agradecimentos Os autores agradecem a todos os profissionais que participaram das inspeções e ao pesquisador Ulysses Vilela por suas contribuições à versão da WDP utilizada nessa experiência. Agradecemos a Fundação COPPETEC, CNPq, FAPERJ e à FAPEAM pelo apoio financeiro. Referências Conte, T. U., Mendes, E., Travassos, G. H. (2005) Processos de Desenvolvimento para Aplicações Web: Uma Revisão Sistemática, WebMedia 2005, Poços de Caldas, Brasil. Conte T., Massolar, J., Mendes, E., Travassos, G. (2007a) "Usability Evaluation Based on Web Design Perspective", ESEM 2007, Madrid, Spain, September. Conte T., Massolar, J., Mendes, E., Travassos, G. (2007b) "Web Usability Inspection Technique Based on Design Perspectives ". SBES 2007, João Pessoa, PB, Brasil, Outubro. Dix, A., Finlay, J., Abowd, G., Beale, R. (2004) Human-Computer Interaction (Ed. Pearson/ Prentice Hall, Third Edition, 2004). Garzotto F., Matera M., Paolini P. (1999). "Abstract Tasks: a tool for the inspection of Web sites and off-line hypermedia. In: Proc. of the 10 th ACM Conference on Hypertext and Hypermedia. ISO/IEC , International Organization for Standardization. Information Technology Software Product Quality. Part 1: Quality Model Mafra, S. N., Barcelos, R. F., Travassos, G. H. (2006) Aplicando uma Metodologia Baseada em Evidência na Definição de Novas Tecnologias de Software. SBES 2006, Florianópolis, SC, Brasil, Outubro. Matera, M., Rizzo, F., Carughi, G. (2006) Web Usability: Principles and Evaluation Methods, in Mendes, E., Mosley, N. (Eds): Web Engineering (Springer, 2006). Mendes, E., Mosley, N., Counsell, S. (2006) The Need for Web Engineering: An Introduction, in Mendes, E., Mosley, N. (Eds): Web Engineering (Springer, 2006). Nielsen, J. (1994) Heuristic evaluation, In Nielsen, J., and Mack, R.L. (Eds.), Usability Inspection Methods (John Wiley & Sons, 1994). Olsina, L., Covella, G., Rossi, G. (2006) Web Quality, in Mendes, E., Mosley, N. (Eds): Web Engineering (Springer, 2006). Polson, P., Lewis, C., Rieman, J., Wharton, C. (1992) Cognitive Walkthroughs: a method for theory-based evaluation of users interfaces, Int. Journal of Man-Machine Studies. Sauer, C., Jeffery, D.R., Land, L., Yetton, P. (2000) The Effectiveness of Software Development Technical Review: A Behaviorally Motivated Program of Research, IEEE TSE, 26 (1): 1-14, January, Shull, F., Carver, J., Travassos, G. (2001) An Empirical Methodology for Introducing Software Processes, ACM SIGSOFT Software Engineering Notes, 2001, 26 (5). 376

377 Zhang, Z., Basili, V. and Shneiderman, B. (1999) Perspective-based Usability Inspection: An Empirical Validation of Efficacy, Empirical Software Engineering: An International Journal, 1999, vol. 4, (1). 377

378 Institucionalização de processo aderente ao CMMI-DEV ML3 em uma empresa exportadora de software Cesar A. Rodrigues, Álvaro F. Santos 1, Thiago L. Paiva 1, Marcelo W. Barbosa 1 1 Vetta Technologies LTDA. Alameda da Serra 400 conjunto Nova Lima MG Brasil {cesar,alvaro,thiagolp,mwerneck}@vettatech.com Abstract. This paper describes the use of effective institutionalizaton mechanisms applied to processes aligned to CMMI-DEV Maturity Level 3 in an organizational unit of Vetta, a software exporting company. The main activities performed to institutionalize the software processes are presented and analyzed according to the company s reality. Resumo. Este artigo apresenta a experiência da aplicação de mecanismos para institucionalização efetiva de processos alinhados ao Nível 3 de Maturidade do CMMI-DEV em toda unidade organizacional da Vetta, empresa exportadora de software. As principais atividades realizadas para institucionalização dos processos de software são apresentadas e avaliadas do ponto de vista da realidade da empresa. 1. Introdução As exportações brasileiras de softwares crescem de forma significativa. Segundo a Associação Brasileira das Empresas de Software (ABES), em 2006, o país exportou US$ 247 milhões em softwares e serviços, 39,7% a mais que em Em 2007, a expectativa era repetir o ritmo de crescimento, de forma que as exportações chegassem ao patamar de US$ 350 milhões [ABES 2007]. Do volume de exportação de 2006, José Curcelli, presidente da ABES, avalia que menos de 10% do valor seja proveniente de pequenas e médias empresas. "Exportar demanda estratégia e fôlego financeiro. Não há incentivo. São poucas as pequenas empresas que conseguem", diz o executivo [Zaparolli 2007]. Contrária a essa tendência, a Vetta é uma empresa de médio porte (aproximadamente 75 pessoas) voltada ao mercado externo. Fundada em 2001 com o intuito de atender a uma demanda que existia nos Estados Unidos, a empresa já expandiu seus negócios para outros países: Canadá, Finlândia, Alemanha, França, Suíça e Portugal. Hoje, com sede em Nova Lima, MG, a Vetta possui também escritórios nos Estados Unidos e em São Paulo [Coutinho 2008]. Em reconhecimento à sua atuação como exportadora, a Vetta recebeu o prêmio Destaque de Comércio Exterior, concedido pelo Ministério do Desenvolvimento, Indústria e Comércio em parceria com a Associação de Comércio Exterior do Brasil, em

379 Em 2007, a Vetta conquistou o Nível 3 de Maturidade do CMMI for Development [Chrissis, Konrad e Shrum 2006][Bush, Dunaway 2005]. O CMMI (Capability Maturity Model Integration) é um Modelo para orientar a Melhoria de Processos em Organizações. Definido pelo SEI (Software Engineering Institute) da Universidade de Carnegie Mellon, é um dos modelos mais reconhecidos no mundo. Para atingir o Nível 3 de Maturidade do CMMI, a Vetta atendeu 17 diferentes áreas de processo definidas pelo modelo. Hoje no Brasil pouco mais de 20 empresas possuem ao menos o Nível 3 de Maturidade [SEI 2008]. A escolha do CMMI como modelo de melhoria para os processos da Vetta foi automática devido ao seu caráter exportador e ao reconhecimento internacional do CMMI. Menos óbvia que a escolha do modelo, no entanto, foi a decisão da empresa de não acelerar o processo de avaliação CMMI. Tendo iniciado o processo de melhoria em 2004, a Vetta buscou investir na melhoria dos seus processos de engenharia de software e atingir, como conseqüência natural, o Nível 3 [West 2004]. Um ponto decisivo na escolha da estratégia de melhoria dos processos foi a constatação de que toda a unidade de desenvolvimento e manutenção de software deveria ser avaliada. A Vetta, por ser uma empresa de médio porte, precisa ter toda a sua equipe preparada para trabalhar em projetos de exportação para atender adequadamente ao mercado externo. Desta forma, a institucionalização da melhoria dos processos deveria ocorrer em toda a unidade organizacional, deixando-a 100% apta para a execução de um processo alinhado ao CMMI-DEV ML3. Caso contrário, a Vetta, já avaliada, teria que atender ao mercado externo com parte de sua equipe ainda não totalmente capacitada nos processos, o que poderia acarretar em problemas de imagem, confiabilidade do mercado externo, dentre outros prejuízos. O presente artigo relata a experiência da Vetta como empresa exportadora na busca pelo CMMI-DEV ML3 e algumas das atividades de institucionalização aplicáveis a toda unidade organizacional. O restante do relato é organizado da seguinte forma: A seção 2 descreve brevemente os trabalhos de ajuste do processo de software. A seção 3 apresenta as principais iniciativas na busca pela institucionalização por completo. A seção 4 apresenta resultados obtidos do processo e a seção 5 apresenta as considerações finais acerca do processo de melhoria. 2. Implementação da melhoria de software Desde sua fundação, a Vetta já possuía processos de software. Seu processo, denominado VSDP Vetta Software Development Process, foi criado com base no Rational Unified Process (RUP) [Kruchten 2003] e mantém similaridades quanto à estrutura de fases e disciplinas do RUP. Em meados de 2004, a Vetta iniciou o alinhamento de seu processo ao CMMI- SW integrando-se a um grupo de empresas organizadas pela Fumsoft no projeto Rumo ao CMMI. Para esse projeto, foi contratada a empresa ASR Consultoria, responsável pelos treinamentos, consultorias e avaliações preliminares e simuladas. O trabalho de consultoria foi desenvolvido normalmente. Ao final de 2004, o VSDP já se encontrava alinhado ao CMMI ML2. No segundo semestre de 2006 foi 380

380 realizada pela consultoria a avaliação simulada final (pré-assessment), que levantou os últimos pontos de ajuste para permitir a aderência definitiva do VSDP ao CMMI ML3. A partir dos ajustes decorrentes da avaliação simulada final, a Vetta estava apta para realizar sua avaliação CMMI-DEV ML3 com base em projetos-piloto. Entretanto, com foco no atendimento com qualidade ao mercado externo, iniciou-se o programa para capacitar toda a unidade organizacional de Desenvolvimento e Manutenção de Software, que corresponde a 90% do faturamento da empresa. Esse programa de institucionalização do VSDP perdurou até a avaliação oficial, realizada em Programa de institucionalização O programa de institucionalização dos processos de software da Vetta consistiu em uma série de atividades voltadas para a capacitação da equipe e da institucionalização dos processos. Durante o programa, algumas atividades de capacitação já existentes na Vetta foram intensificadas, enquanto outras novas foram aplicadas. Dentre todas as medidas adotadas, as seguintes merecem destaque: Projeto Vetterano, investimento em identificação com os processos, Aprendiz Vetta e treinamentos diretos Projeto Vetterano O Projeto Vetterano é um mecanismo criado com o intuito de garantir a transferência de conhecimentos técnicos e de cultura organizacional dos membros mais antigos e experientes da equipe para os mais jovens e inexperientes. Desde sua admissão, cada colaborador da Vetta é apresentado ao seu Vetterano, que é um colaborador mais antigo e com maior grau de senioridade que possui por responsabilidade transferir o conhecimento e orientar o afilhado em suas decisões e busca do crescimento organizacional. Os Vetteranos não são necessariamente os profissionais mais seniores da empresa. Um Vetterano sênior pode, por exemplo, ser responsável por um colaborador pleno, que por sua vez pode ser Vetterano de um colaborador júnior. Essa distribuição hierárquica permite que exista um limite saudável do número de afilhados que cada Vetterano consegue orientar tipicamente entre dois e cinco, valores que garantem atenção adequada no treinamento e acompanhamento realizado pelo Vetterano. A estrutura hierárquica ainda permite que Vetteranos intermediários possam praticar suas habilidades de comunicação e liderança gradativamente, à medida que ganham experiência profissional. A lista que contém os Vetteranos de cada membro da equipe da Vetta é formalmente definida no plano de capacitação organizacional. Essa lista é revisada a cada seis meses, quando ocorrem as revisões globais do plano de capacitação. Durante esse período, os objetivos de carreira de cada colaborador são reavaliados e as mudanças dos objetivos de médio e longo prazo de cada pessoa podem acarretar na escolha de um Vetterano mais adequado. Além de colaborar no atendimento aos requisitos da área de processo OT (Organizational Training) do CMMI-DEV, o Projeto Vetterano foi de extrema importância para a institucionalização, uma vez que ele potencializa exponencialmente a transmissão de conhecimento da equipe mais sênior para a equipe mais júnior. Essa 381

381 transferência de conhecimento ainda torna-se mais valiosa em um ambiente de crescimento da empresa, no qual novos colaboradores precisam estar aptos ao trabalho o mais cedo possível e, nem sempre, é possível ministrar um treinamento formal individual. É importante destacar também que alguns dos Vetteranos mais seniores colaboraram na definição dos processos, o que facilita a transmissão dos conhecimentos do VSDP para toda a equipe Identificação da equipe com os processos O investimento com a identificação da equipe com os processos consiste no esforço da Vetta em apresentar o VSDP como ferramenta natural de trabalho. A percepção do processo como parte do trabalho tem por objetivo torná-lo um hábito, de forma a fazer com que a equipe naturalmente busque o processo para executar os projetos e, sob a percepção da importância do mesmo, não consiga executar suas atividades sem ele apenas de uma forma melhor. Uma das maiores dificuldades na transformação do uso do processo em um hábito encontra-se na motivação da equipe em acessar o processo e lê-lo. Para isso, foram feitas duas medidas: a criação da identificação do processo com as pessoas e a adoção de ferramenta de descrição de processos. A identificação do processo com as pessoas foi realizada através da criação de representações gráficas do VSDP, seus papéis e suas disciplinas cuja representação dos executores das atividades era feita de forma estilizada baseada nos colaboradores da própria empresa (Figura 1). Simples na concepção, os diagramas estilizados formataram a identidade visual do VSDP. Os conceitos de processos, papéis e disciplinas foram amplamente assimilados pela equipe. Sentindo-se mais próximos do processo de melhoria, os colaboradores se tornaram mais ativos no conhecimento do processo e na busca das informações relacionadas. Em paralelo com a criação da identidade visual do processo, foi realizado o investimento em melhores formas para a sua apresentação. Desde o início do alinhamento dos processos ao CMMI, a Vetta percebeu a necessidade de se ter uma ferramenta para escrita estruturada de processos e para a apresentação para a equipe. Essa necessidade advém tanto da complexidade de se escrever processos de software corretos em forma textual, quanto da dificuldade e indisposição da equipe na obtenção de informações a partir dos processos escritos nos documentos de texto. Por isso, em 2005, a Vetta iniciou a criação de uma ferramenta para a definição estruturada de processos, denominada WARP. Algum tempo depois foi lançado o Eclipse Process Framework (EPF) [EPF 2008] uma ferramenta para registro estruturado de processos de software com base na Plataforma Eclipse [Eclipse 2008]. Após avaliação interna, ficou decidida a utilização do EPF como ferramenta para a descrição do VSDP. A adoção do EPF como ferramenta de descrição de processos, além de colaborar no atendimento aos requisitos da área de processo OPD (Organizational Process Definition), facilitou o acesso da equipe ao processo. Ao invés de estar descrito em documentos textuais, o VSDP tornou-se disponível para acesso remoto, via internet. Além disso, sua apresentação possuía um grau de navegabilidade apropriado para o rápido aprendizado e uso simplificado. Essas vantagens tornavam-se ainda mais significativas para os colaboradores que faziam trabalhos de exportação de software e 382

382 que eventualmente poderiam estar em outros países. Em caso de mudanças no VSDP, elas eram refletidas diretamente no site e seriam automaticamente disponibilizadas para pessoas em qualquer parte do mundo com acesso a um navegador Web. Figura 1. Fluxo geral de atividades e exemplo de detalhes do VSDP, com identificação aos membros da equipe O Aprendiz O Aprendiz Vetta (Figura 2) foi um treinamento estruturado, no formato de competição, que envolveu toda a equipe da unidade organizacional para reforçar o contato com o processo. O objetivo do treinamento era permitir que todos os membros da unidade organizacional pudessem vivenciar a execução de um projeto completo aderente ao VSDP e ressaltar a importância de cada papel. A unidade organizacional foi dividida em grupos. Cada grupo continha pessoas de diferentes papéis, de forma que os grupos ficariam equilibrados do ponto de vista de experiência e conhecimento técnico. Foi definido um problema, que seria a base para os trabalhos dos grupos. Uma versão simplificada do VSDP, alinhada aos principais conceitos, artefatos e papéis do VSDP completo, foi utilizada. O treinamento foi organizado em quatro módulos: um para cada fase do ciclo de vida do VSDP (Concepção, Elaboração, Construção e Transição), tendo sido executado em um total de quatro semanas. A cada módulo, os membros das equipes precisariam 383

383 alterar seus papéis no VSDP, de forma que nenhum integrante do grupo repetisse o mesmo papel durante todo o treinamento. Cada grupo deveria resolver o problema seguindo o processo em todo o seu ciclo de vida. Ao final de cada módulo o grupo era avaliado, recebendo pontos por critérios envolvendo a aderência ao processo, o tempo, a qualidade do resultado, dentre outros critérios. Figura 2. Divulgação interna do programa de treinamentos Aprendiz, com manutenção da identidade visual do processo. O formato do treinamento apresentou ótimos resultados quanto à ampliação do conhecimento acerca das atividades, papéis, artefatos e comunicações realizadas dentro do VSDP. A leve competição motivou as equipes a lerem proativamente o processo e zelar pela qualidade e o tempo gasto. Esse aprendizado foi percebido mais tarde, durante a execução dos projetos reais. Ao final da competição, a melhor equipe foi premiada, embora tanto as equipes quanto a Vetta tenham ganhado com o treinamento Treinamentos diretos Os treinamentos diretos, por fim, são aqueles realizados diretamente através da preparação de material e divulgação a toda unidade organizacional. Os treinamentos eram realizados após revisões significativas do VSDP como, por exemplo, a versão 100% aderente ao CMMI-DEV ML3. Cada treinamento era constituído de três principais etapas: treinamento expositivo, estudo dirigido e entrevista. O treinamento expositivo é a primeira etapa do treinamento direto. Nessa etapa, são ministrados cursos referentes às disciplinas, atividades e técnicas do VSDP, realizados pela equipe interna por instrutores selecionados que podem ser os Vetteranos com mais experiência e didática. O objetivo dessa primeira etapa consiste em capacitar a equipe na busca por mais informações sobre o tópico treinado. O treinamento expositivo não é eficiente sozinho. Como a equipe treinada recebe as informações passivamente, a retenção do conteúdo ministrado nesse treinamento isoladamente não é suficiente. Após o treinamento expositivo, a equipe treinada recebia um estudo dirigido individual. O estudo dirigido consiste de uma série de questões, exercícios e trabalhos que fazem com que os treinados sejam forçados a investigar o material do processo na busca pelas respostas. O estudo dirigido serve de complemento para o treinamento 384

384 expositivo, uma vez que possibilita a fixação dos conceitos através do esforço na busca por respostas. Após período adequado, o estudo dirigido é corrigido e discutido, de forma que as dúvidas referentes à execução do exercício possam ser sanadas. A terceira e última etapa do treinamento é uma entrevista. Realizada por grupos de executores do mesmo papel, a entrevista é realizada pela equipe que elaborou os treinamentos e serve para atestar a efetividade de todo o ciclo de treinamentos ou recomendar um novo estudo dirigido para a pessoa. O resultado do treinamento direto em três etapas foi extremante significativo, uma vez que não foi recomendada nenhuma reaplicação de estudo dirigido. Todas as atividades de treinamento direto auxiliam no atendimento aos requisitos da área de processo OT (Organizational Training) do CMMI-DEV. 4. Resultados Obtidos O investimento em treinamento, a capacitação dos colaboradores, o tempo para a execução e ganho de maturidade dos processos permitiram que toda unidade organizacional estivesse preparada para a execução proficiente do VSDP no momento da avaliação CMMI-DEV ML3. Após quase um ano de investimentos, a unidade organizacional estava pronta para ser avaliada e assumir as conseqüências dessa avaliação, materializada através de projetos solicitados por clientes exigentes do mercado externo. O processo de institucionalização bem sucedido tem o resultado da avaliação do CMMI ML3 como sua conseqüência direta. Durante o processo de avaliação, tanto os projetos avaliados quanto as entrevistas da equipe foram bem sucedidos. Não foi identificado nenhum ponto fraco, o que acarretou no resultado satisfatório no alcance do CMMI-DEV ML3. 5. Considerações finais O mercado de exportação possui uma dinâmica diferente dos mercados locais. Em primeiro lugar, existe maior exigência pelas referências de qualidade. Enquanto no Brasil uma empresa CMMI-DEV ML3 apresenta diferencial de qualidade, em alguns mercados de outros países (como nos Estados Unidos), o CMMI-DEV ML3 vem se tornando o patamar mínimo de referência de qualidade aceitável. Apenas os níveis mais altos (ML4 e ML5) são considerados diferenciais. Dentro desse contexto, para uma empresa CMMI-DEV ML3 poder atuar nos mercados externos mais competitivos, é necessário que a implementação do CMMI seja eficiente, de forma a demonstrar a aplicação de facto, com resultados de produtividade adequados. 385

385 Uma empresa de porte médio, como a Vetta, não pode restringir à utilização das metodologias da qualidade a um pequeno subconjunto de sua equipe. Para competir no mercado externo, é necessário que toda a unidade organizacional execute os processos de forma eficiente e precisa, uma vez que o atendimento inadequado de um cliente pode acarretar no fechamento de portas a todo um segmento de mercado, conseqüência da visibilidade em grupo reduzido de empresas exportadoras de software brasileiras. A institucionalização eficiente dos processos de software necessita de esforços significativos na capacitação da equipe e disseminação da importância da execução dos processos. Os programas realizados pela Vetta para a institucionalização dos processos buscaram enfoque em diferentes aspectos de capacitação: atividades com foco específico (Aprendiz Vetta e identificação gráfica com o VSDP) x atividades de aplicação geral (treinamentos, provas, entrevistas e programa Vetterano); aprendizado por transferência (treinamentos, provas) x aprendizado por prática de execução das atividades (mentoring, o Aprendiz Vetta, estudos dirigidos); formalismo (treinamentos, provas) x atividades lúdicas (o Aprendiz Vetta). Essa multiplicidade de meios, formatos e técnicas de transferência de conhecimento foi apontada por membros da equipe da Vetta durante a avaliação CMMI-DEV ML3 como fundamental no aprendizado do processo e no grau de institucionalização obtido. A experiência advinda de todo o processo de institucionalização foi importante para preparar a empresa para o crescimento com qualidade. Mesmo após a avaliação CMMI ML3, a experiência de institucionalização permite que a empresa possa continuar a crescer mantendo os padrões de qualidade: a estimativa é que a empresa dobre de tamanho até o final de 2009 e ainda mantenha o mesmo padrão de qualidade. Sob os aspectos apresentados anteriormente, a institucionalização eficiente e eficaz do processo torna-se fator crítico para a manutenção da Vetta como empresa de destaque na exportação de software. Referências ABES (2007). Mercado Brasileiro de Software. Panorama e Tendências Associação Brasileira das Empresas de Software. Acessado em 10/03/2008. Bush, M.; Dunaway, D. (2005). CMMI(R) Assessments: Motivating Positive Change. SEI Series in Software Engineering. Addison Wesley Professional. Coutinho, C. (2008). Vetta foca no Mercado Externo. Diário do Comércio, Belo Horizonte, 31/01/2008, Negócios, p 15. Chrissis, M. B.; Konrad, M.; Shrum, S. (2006) CMMI (Second Edition): Guidelines for Process Integration and Product Improvement. SEI Series in Software Engineering. Addison Wesley Professional. Eclipse (2008), Eclipse an open development platform. Disponível em Acessado em 10/03/

386 EPF (2008), Eclipse Process Framework Composer. Disponível em Acessado em 10/03/2008. Kruchten, P. (2003). The Rational Unified Process: An Introduction. Addison Wesley. SEI (2008). Published Appraisal Results. Software Engineering Institute, Carnegie Mellon. Disponível em Acessado em 11/05/2008. West, M. (2004). Real Process Improvement Using The CMMI. Auerbach, 1 st Edition. Zaparolli, D. (2007). Corrida de Obstáculos. Valor Econômico, São Paulo, 27/08/2007, Micro e Pequenas Empresas, p. F1. Disponível em acessado em 10/03/

387 388

388 Uma Experiência de Melhoria de Processo utilizando a Análise Causal de Defeitos Daniela C. C. Peixoto 1, Vitor A. Batista 1, Gustavo M. Rocha 1, Clarindo Isaías P. S. Pádua 1, Rodolfo F. Resende 2 1 Synergia Universidade Federal de Minas Gerais 2 Departamento de Ciência da Computação Universidade Federal de Minas Gerais Av. Antônio Carlos CEP Belo Horizonte MG - Brasil {cascini, vitor, gustavom, clarindo, rodolfo}@dcc.ufmg.br Abstract. In this paper we describe a software process improvement experience using the defect casual analysis method. The goal of this approach is to reduce systematic errors during the project development cycle. The identification and analysis of defect causes are used to achieve this goal. In particular, the application of this method has been shown effective for quality improvement and rework reduction. Resumo. Neste artigo relatamos uma experiência com melhoria de processo de software utilizando o método de análise causal de defeitos. Esta técnica tem por objetivo evitar que os defeitos ocorram repetidamente no ciclo de desenvolvimento do projeto a partir da detecção e análise das suas causas. A aplicação deste método mostrou-se efetiva para a melhoria da qualidade e redução do retrabalho no projeto. 1. Introdução A crescente demanda por produtos com um alto nível de qualidade força as organizações atuais a adotarem processos que dêem suporte ao desenvolvimento de softwares que atendam os atributos de qualidade requeridos pelos clientes. Uma forma de reduzir o número de defeitos do produto final e, respectivamente, melhorar a sua qualidade, consiste na utilização de processos adequados de verificação e validação incluindo a detecção e prevenção de defeitos [Kan, 2003]. Aliado a esta demanda por qualidade, as organizações de desenvolvimento de software também devem lidar com a crescente competitividade do mercado atual, que exige, cada vez mais, produtos com um maior número de funcionalidades e que sejam entregues em prazos mais curtos. Assim, resta a essas organizações investirem em métodos e técnicas que permitam reduzir o retrabalho e o tempo de desenvolvimento. Neste contexto, a detecção e prevenção efetiva de defeitos têm um papel crucial para alcançar estas metas de prazo, custo e qualidade. Em particular, técnicas de prevenção e detecção de defeitos como inspeção de software [Gilb & Graham, 1993], medição de defeitos [McGarry et al., 2001] e análise causal de defeitos [Card, 1998] antecipam a detecção dos defeitos e permitem reduzir o custo da sua detecção, já que evitam a propagação deste defeitos para as fases posteriores do desenvolvimento do software, em que o custo de correção é bem mais alto. No contexto de melhoria de processos, este trabalho caracteriza a utilização do método de análise causal de defeitos. Uma primeira contribuição deste trabalho é uma 389

389 discussão da aplicação deste método na Organização dos autores para a prevenção de defeitos durante o ciclo de desenvolvimento de um produto de software. Uma segunda contribuição deste trabalho é a apresentação do impacto na qualidade, nesse escopo, produzido pela implantação das ações resultantes da utilização deste método. Este trabalho está organizado conforme descrito a seguir. A Seção 2 apresenta de forma sucinta algumas características do processo de desenvolvimento de software utilizado na Organização dos autores. Maiores detalhes do processo podem ser obtidas em trabalhos anteriores, como [Pimentel et al., 2006], [Filho, 2006]. A Seção 3 apresenta um resumo da metodologia de Análise Causal de Defeitos. A Seção 4 apresenta as etapas seguidas para a melhoria do processo. A Seção 5 mostra alguns dos resultados obtidos com a implantação das ações de melhoria de processo e a Seção 6 apresenta as conclusões. 2. O processo de desenvolvimento de software da Organização A Organização dos autores utiliza uma personalização do processo Praxis [Filho, 2003] de desenvolvimento de software que por sua vez é derivado do Processo Unificado. O processo Praxis está direcionado para o desenvolvimento de aplicativos gráficos interativos, baseados na tecnologia de orientação a objetos. Na Organização dos autores, as equipes são organizadas por fluxos (ou disciplinas). Os fluxos de Requisitos e Análise foram agrupados em uma única equipe, devido à grande interseção das suas atividades durante os projetos. O mesmo ocorre com Desenho e Implementação. Uma diferença entre o Praxis Padrão e o processo adotado na Organização dos autores consiste na criação da disciplina de Usabilidade. Uma característica do processo Praxis, mantida na personalização, é a forte orientação a caso de uso, que é dividido em estados, ou marcos de controle durante o projeto. Cada evolução de estado do caso de uso passa por um ou mais procedimentos de controle de qualidade, como inspeções, revisões gerenciais ou testes. Durante a execução desses procedimentos o registro de defeitos injetados no produto é efetuado, para posterior análise. A Tabela 1 lista os estados do caso de uso e os procedimentos de qualidade executados em cada um. 3. Análise Causal de Defeitos (Defect Causal Analysis - DCA) A Análise Causal de defeitos, ou DCA, é uma metodologia de melhoria de processos criada pela IBM na década de Segundo Card [Card, 1998], o DCA oferece um método simples, de baixo custo para melhoria sistemática da qualidade de software no nível da equipe, projeto ou organização. O principal insumo para o método é o relatório de problemas de software, que é relativamente simples de ser produzido. O DCA é dirigido por 3 pilares: reduzir defeitos para aumentar a qualidade, usar o conhecimento interno e focar nos erros sistemáticos. Ainda segundo Card, o DCA precisa de poucos pré-requisitos para ser implantado: existência de defeitos, os defeitos precisam estar documentados, a organização deve almejar evitar defeitos em seus projetos e deve documentar e estabelecer o seu processo de desenvolvimento. A ferramenta recomendada para uso nas reuniões de análise causal é o diagrama de causa e efeito, ou também conhecido como Ishikawa ou o diagrama de espinha de 390

390 peixe, que procura identificar, de forma estruturada, as causas de cada um dos problemas em análise. Tabela 1 - Critérios de aprovação dos estados dos casos de uso Nome Descrição Critérios de aprovação 1 Identificado Recebeu nome e descrição sucinta. Inspeção de identificação de requisitos. Detalhado Descrição completa dos fluxos e das interfaces de usuário. Inspeção de detalhamento de requisitos. Analisado Os fluxos foram realizados em termos de classes do modelo de análise. Inspeção de análise. Desenhado Os fluxos dos casos de uso de desenho derivados tiveram o desenho externo estático e dinâmico completo. Inspeção de desenho externo. Especificado Realizado Implementado Verificado Os respectivos procedimentos e casos de teste foram completamente especificados. Codificação das classes de fronteira, controle e entidade, além dos testes de unidade A realização dos casos de uso de desenho foi completamente implementada e integrada com o restante do produto. Os testes de integração foram executados com sucesso pela equipe de testes e os defeitos encontrados foram todos corrigidos. Inspeção da especificação dos testes. Inspeção de testes de unidade e de código fonte. Execução manual dos testes de implementação pelo implementador (um subconjunto da especificação de testes de integração). Inspeção de usabilidade. Re-execução dos testes de implementação pela equipe de testes. Testes de integração manuais, inclusive testes destrutivos. Validado Foi aprovado na avaliação dos usuários. Avaliação pelos usuários. Completo As classes que o realizam e possível material correlato foram aprovados em auditoria da qualidade. Auditoria da qualidade. Lauesen [Lauesen & Vinter, 2001] descreve um método, bastante similar ao DCA, para a redução do número de defeitos de requisitos detectados nos produtos em desenvolvimento. A principal diferença entre este método e o DCA, é que este método propõe uma avaliação dos defeitos de requisitos por uma equipe que não possua tanto conhecimento da implementação do sistema. Leszak [Leszak et al., 2000] propõe um método de análise causal da raiz do problema (RCA- Root Cause Defect Analysis). Este método é compatível com o DCA. A principal diferença consiste no momento em que ocorre a aplicação do método, ocorrendo apenas após a conclusão do desenvolvimento do sistema. 4. Aplicação do DCA Os benefícios da utilização do método DCA podem ser observados, principalmente, em termos da melhoria da qualidade e redução do retrabalho. A melhoria da qualidade é obtida ao se eliminar as causas que geram os defeitos. A redução do retrabalho, e, conseqüentemente, a redução dos custos, é obtida diretamente da redução do número de defeitos. Este trabalho apresenta a aplicação do DCA como um método de melhoria de processos. Este método foi utilizado em um projeto de construção o qual consiste em um sistema WEB que provê informações e serviços para a execução de um processo de 1 Ver o detalhamento do escopo das inspeções em [Filho, 2003] 391

391 compras para um órgão do Governo do Estado. O sistema possui aproximadamente Pontos de Função não ajustados e está sendo desenvolvido em plataforma Java por uma equipe de aproximadamente 50 colaboradores. O DCA foi escolhido por ser um método simples, de fácil implantação e que permite obter melhorias em um curto intervalo de tempo [Card, 2006]. Além disso, foi identificado prontamente o atendimento aos pré-requisitos listados na Seção 3, como descrito abaixo. Processo de desenvolvimento de software definido: conforme descrito na Seção 2, o processo de desenvolvimento de software da Organização é uma personalização do processo Praxis. Com isto, é possível identificar as atividades nas quais os defeitos foram injetados (local) e o motivo da inserção de tais defeitos (causa). Execução de Inspeções e Testes de software: devem ser utilizados processos de verificação e validação durante o desenvolvimento do software que permitam a detecção dos defeitos. Neste trabalho, os defeitos foram detectados através de inspeções, que utilizam listas de conferência [Gilb & Graham, 1993], e testes de software. Ambas as atividades são executadas por especialistas, seguindo padrões do IEEE [IEEE, 1997], [IEEE, 1998]. Classificação dos defeitos: todos os defeitos detectados durante o ciclo de desenvolvimento dos projetos foram documentados e classificados de acordo com o padrão do IEEE [IEEE, 1993]. Além disso, os defeitos são registrados indicando o item da lista de conferência associado. Coleta de dados: após o registro, deve ser realizada a coleta dos dados para a análise e identificação de defeitos recorrentes. Todos os defeitos detectados foram registrados em ferramentas apropriadas. Análise de dados: a coleta e análise dos defeitos, realizada na organização, seguem a metodologia definida em [McGarry et al., 2001]. Além de atender aos pré-requisitos técnicos, listados acima, um fator crucial para o sucesso da implantação deste processo de melhoria foi o apoio dado pela Diretoria e pelos Gerentes de Projeto. Sem este apoio, não seria possível mobilizar a equipe técnica para participar das reuniões e implantar as ações de melhorias. As seções a seguir descrevem as atividades executadas no processo de melhoria. 4.1 Identificação de erros sistemáticos De acordo com Boehm e Basili [Boehm & Basili, 2001], 80% do retrabalho é originário de 20% dos defeitos. Ao se eliminar esses defeitos obtém-se um impacto significativo na melhoria da qualidade e na redução dos custos do projeto [Card, 1998]. A primeira atividade realizada durante o processo de melhoria foi a identificação dos defeitos sistemáticos. Esta atividade foi realizada pelo Grupo de Garantia da Qualidade que utilizou como insumo as informações dos defeitos injetados nos produtos e que foram detectados pelas inspeções, revisões e testes executados durante o ciclo de desenvolvimento do projeto. Os seguintes questionamentos serviram de base para a seleção dos erros sistemáticos que foram tratados nas reuniões de análise causal. Tipos de defeitos mais 392

392 recorrentes: este dado foi obtido a partir dos indicadores que apresentavam a distribuição dos tipos de defeitos detectados. Local dos defeitos: o local de inserção do defeito e o de sua detecção foram coletados a partir do registro dos defeitos mais recorrentes, permitindo que fosse dado um maior enfoque aos principais aspectos a serem melhorados. Os procedimentos de qualidade avaliados, e conseqüentemente os defeitos identificados, foram agrupados de acordo com as disciplinas do processo. Utilizando este critério, foi possível distribuir a análise dos problemas entre as diversas equipes, permitindo uma avaliação mais ampla dos fluxos do processo de desenvolvimento utilizado na Organização. 4.2 Seleção dos grupos de análise causal Os grupos foram divididos de acordo com as disciplinas do processo: Usabilidade, Testes e Desenho & Implementação. Os grupos possuíam 8 pessoas cada, sendo 5 participantes das equipes representativas do fluxo do processo e 3 das demais equipes envolvidas. As pessoas que foram escolhidas possuem conhecimento profundo do processo utilizado na Organização e são especialistas nas suas áreas. Um moderador (representante do fluxo) foi designado para cada grupo. O motivo deste número reduzido de participantes foi tentar evitar efeitos negativos de reuniões com muitas pessoas, como por exemplo, dispersão e inércia cognitiva [Nunamaker et al., 2003]. A inclusão de pessoas de outras equipes consistiu em uma adaptação do DCA original; o objetivo foi auxiliar na identificação precisa das causas dos problemas e na proposição de soluções que representassem melhoria efetiva do ponto de vista de todos os envolvidos. Com isso, evitou-se que uma melhoria proposta para solucionar problemas específicos de um fluxo (equipe) gerasse impactos negativos nos demais fluxos (equipes). Assim, as análises das causas e soluções seriam avaliadas em todo o contexto da organização. 4.3 Preparação dos participantes Foram realizadas palestras de apresentação do método de análise causal para toda a Organização e foi elaborado um documento com a descrição detalhada do método, reforçando a motivação para a sua utilização e os benefícios esperados. Esse documento foi distribuído para toda a equipe da Organização. Em seguida, foram realizados treinamentos específicos para os moderadores, que seriam os responsáveis pela condução das reuniões, apresentando em detalhes as etapas a serem seguidas e os problemas já identificados pela Gerência de Qualidade, que deveriam ser tratados durante a reunião. No início de cada reunião, o Moderador respondia a todas as dúvidas que os integrantes ainda possuíam em relação à aplicação do método. A duração das reuniões foi de 2 horas. 4.4 Identificação das causas e propostas de soluções Cada grupo recebeu um conjunto de 4 problemas para serem discutidos durante as reuniões. A identificação das causas desses problemas foi realizada através da técnica de brainstorming. As causas da inserção dos defeitos e os motivos da sua detecção tardia foram estruturados em relação aos fatores de tecnologia, processos, insumos e pessoas. A ferramenta utilizada como apoio para a identificação das causas foi o diagrama de causa e efeito. Cada grupo também identificou um conjunto de ações que 393

393 poderiam ser realizadas para evitar a ocorrência dos problemas. Os resultados foram entregues ao Grupo de Ação, que, em seguida, realizaria a priorização das ações e o acompanhamento da sua implantação. 4.5 Priorização e acompanhamento da implantação das ações O Grupo de Ação é formado por representantes dos grupos de Garantia da Qualidade e de Engenharia de Processos da Organização. As suas responsabilidades consistem em: consolidar as propostas, priorizar as ações, planejar a implementação das ações e alocar recursos, monitorar o progresso da implantação e comunicar os resultados a toda a Organização. As ações foram agrupadas em ações que deveriam ser implantada em um curto prazo (algumas de imediato), médio e longo prazo. Em seguida, foram alocados esforços e designado responsáveis para a execução de todas as ações de curto e algumas ações de médio prazo. 5. Resultados obtidos Os resultados obtidos com a aplicação do método de análise causal foram medidos após um período de seis meses da sua implantação. De acordo com Card [Card, 1998], embora os benefícios da aplicação do método demorem algum tempo para serem observados, os benefícios da implantação de ações no nível de projeto podem ser obtidas dentro de alguns meses. Foram realizadas 3 sessões de análise da causa dos defeitos. O investimento total para o levantamento e análise dos defeitos foi de 177 PH (pessoashora). As ações de curto prazo (algumas de imediato) foram implantadas, trazendo consigo benefícios. A seguir listaremos alguns dos problemas recorrentes, as causas identificadas pelas equipes técnicas, as soluções propostas e seus benefícios. As Tabelas 2 e 3 exemplificam alguns problemas abordados pelos grupos de Implementação e Desenho respectivamente. Problema Causa Solução Benefícios Tabela 2 - Exemplo de problema abordado pelo Grupo de Implementação Muitos casos de uso reprovados na re-execução dos Testes de implementação ao passarem pelos procedimentos de qualidade do estado Implementado (ver Tabela na Seção 2). Implementadores não executavam corretamente o roteiro de testes antes de entregar o caso de uso para os procedimentos de qualidade e eventualmente faziam pequenos ajustes na execução dos roteiros de testes quando estes possuíam erros ou estavam inválidos ou ambíguos. Implantação de uma ferramenta de testes que obriga o Implementador registrar cada um dos passos que executa da especificação de testes. Um log da ferramenta é avaliado pela equipe de testes com o intuito de garantir que o implementador executou esses testes manuais adequadamente, antes de iniciar os testes de integração. O índice de aprovação nessa inspeção passou de 49% (de um total de 61) para 63% (de um total de 48) após a implantação da ferramenta. Além disso, observou-se uma redução média de 10,15 h/inspeção em retrabalho com correção e verificação de defeitos, totalizando uma economia de 487 h nas 48 inspeções realizadas. O benefício dessa ação correspondeu a 217% do investimento realizado no levantamento e sessões de análise dos defeitos. Para verificar o efeito das soluções apresentadas, foram medidos alguns indicadores antes e depois da aplicação do DCA. Esses indicadores foram construídos a partir da aplicação da metodologia do Practical Software Measurement (PSM) [McGarry et al., 2001]. Os resultados obtidos com a utilização do método DCA podem ser 394

394 observados, principalmente, em termos da melhoria da qualidade (eliminação das causas que geram os defeitos) e redução do retrabalho. Problema Causa Solução Tabela 3 - Exemplo de problema abordado pelo Grupo de Desenho Grande quantidade de defeitos de modelagem anotados durante a inspeção de desenho, principalmente com gravidade menor, que poderiam ser evitados. Alguns Desenhistas (ou projetistas) não estavam verificando se o caso de uso atendia aos itens mínimos de qualidade exigidos para a liberação do artefato para a revisão. O processo orienta os desenhistas a utilizarem uma lista de conferência preliminar. Entretanto, quando a lista de conferência era utilizada, ocorriam problemas de entendimento (faltavam padrões para alguns comportamentos e descrições), por conta de itens muito genéricos (ou até não aplicáveis). Foram atualizadas todas as listas de conferência e materiais de insumo utilizados para a confecção do artefato (desenho do caso de uso). Benefícios Após a revisão dos artefatos e listas de conferência e atualização da documentação do processo, observou-se uma redução de 1,45 h/inspeção com retrabalho, o que totalizou uma economia de 50,7 h de retrabalho em 35 inspeções realizadas após as alterações. Outro resultado significativo foi a redução do número médio de defeitos encontrados: Defeitos Críticos: redução média de 0,49 defeitos por inspeção. Defeitos Maiores: redução média de 3,06 defeitos por inspeção. Defeitos Menores: redução média de 4,14 defeitos por inspeção. Um aspecto a ser melhorado na próxima execução do método DCA é a definição dos indicadores a serem monitorados para avaliar os benefícios de cada proposta de ação identificada pelos grupos. Para algumas ações não foi possível identificar os indicadores mais adequados para a avaliação dos resultados, como, por exemplo, para a ação Promover a conscientização da equipe com o objetivo de utilizar a comunicação informal para divulgação de informações de interesse de todos. 6. Conclusão Atualmente, o desenvolvimento de produtos complexos de software é desafiador. O que se observa é que os clientes esperam que os produtos atendam a cada vez mais requisitos de qualidade e, ainda assim, sejam desenvolvidos no mesmo intervalo de tempo ou, até mesmo, em intervalos de tempo mais reduzidos. Assim, desenvolver produtos de software com o nível de qualidade esperado, atendendo aos requisitos de escopo, prazo e custo é uma chave para o sucesso. Uma das formas de atender a essas restrições consiste em utilizar técnicas de prevenção e detecção de defeitos. Este trabalho relata a experiência de utilização do método de Análise Causal de Defeitos (DCA) com o objetivo de melhorar a qualidade do projeto e reduzir o retrabalho. O DCA mostrou-se uma ferramenta útil para a prevenção de defeitos sistemáticos. Na Organização dos autores este método foi utilizado para evitar que defeitos detectados nos testes e nas inspeções realizadas pelas equipes de Testes, Usabilidade, Desenho e Implementação, fossem novamente inseridos no ciclo de desenvolvimento do produto. Um fator importante para o sucesso desta iniciativa foi o apoio dado pela Diretoria e pelos Gerentes de Projeto. Outro aspecto, não menos importante, foi envolvimento e o interesse demonstrado pelos participantes dos grupos de análise causal. 395

395 Os resultados obtidos com a aplicação do DCA demonstram que após um curto intervalo de tempo já foi possível observar melhorias pontuais na qualidade e na redução do retrabalho. Com este resultado tão positivo, o DCA foi incorporado ao conjunto de processos da organização e, será aplicado a todos os projetos de desenvolvimento de software de maneira sistemática como parte do processo. Referências [Boehm & Basili, 2001] Boehm, Barry, & Basili, Victor R Software Defect Reduction Top 10 List. IEEE Computer, vol. 34(Jan), pp [Card, 1998] Card, David N Learning from our mistakes with defect causal analysis. IEEE Software, vol.15(no.1), pp [Card, 2006] Card, David N (October). Myths and Strategies of Defect Causal Analysis. In: Pacific Northwest Software Quality Conference. [Filho, 2003] Filho, Wilson P. Paula Engenharia de Software: Fundamentos, Métodos e Padrões. LTC. [Filho, 2006] Filho, Wilson P. Paula Quality gates in use-case driven development. Pages of: WoSQ '06: Proceedings of the 2006 international workshop on Software quality. New York, NY, USA: ACM Press. [Gilb & Graham, 1993] Gilb, Tom, & Graham, D Software Inspection. Addison-Wesley. [IEEE, 1993] IEEE IEEE Standard for Classification for Software Anomalies, Std [IEEE, 1997] IEEE IEEE Standard for Software Reviews, Std [IEEE, 1998] IEEE IEEE Standard for Software Test Documentation, Std [Kan, 2003] Kan, Stephen H Metrics and Models in Software Quality Engineering. second edition. Addison-Wesley. [Lauesen & Vinter, 2001] Lauesen, Soren, & Vinter, Otto Preventing Requirement Defects: An Experiment in Process Improvement. Requirements Engineering, Volume 6 (Number 1). [Leszak et al., 2000] Leszak, Marek, Perry, Dewayne E, & Stoll, Dieter (June). A case study in root cause defect analysis. In: Proceedings of the 22nd International Conference on Software Engineering. [McGarry et al., 2001] McGarry, John, Card, David, Jones, Cheryl, Layman, Beth, Clark, Elizabeth, Dean, Joseph, & Hall, Fred Practical Software Measurement: Objective Information for Decision Makers. Addison-Wesley Professional. [Nunamaker et al., 2003] Nunamaker, J. F, Denis, A. R., Valacich, J. S., Vogel, D. R., & George, J.F Group Support Systems Research: Experience from the Lab and Field. MacMillan Publishing Company. [Pimentel et al., 2006] Pimentel, Bruno, Filho, Wilson P. Paula, Pádua, Clarindo, & Machado, Fabiana T Synergia: a software engineering laboratory to bridge the gap between university and industry. Pages of: SSEE '06: Proceedings of the 2006 international workshop on Summit on software engineering education. New York, NY, USA: ACM Press. 396

396 Uso da Ferramenta de Análise Estática Klocwork na Motorola Relato de experiência Rachel C. D. Reis, Denise P. Prado, Maria G. S. M. Fernandes Departamento de Software Básico - Instituto de Pesquisas Eldorado Rod. SP340 KM 118,5 s/n Bairro Fazenda Pau D Alho CEP Campinas SP Brasil {rachel.pereira,denise.prado,maria.fernandes}@eldorado.org.br Abstract. This paper describes the relevance and benefits due to the use of static analysis technique as an important helper to guarantee software quality. It presents the experience gained in working with a static analysis tool usage, called Klocwork, integrated into Motorola development environment. Resumo. Este artigo discorre sobre a relevância e benefícios decorrentes do uso da técnica de análise estática como importante aliada para garantir a qualidade de software. Apresenta a experiência adquirida com o uso da ferramenta de análise estática, chamada Klocwork, integrada no ambiente de desenvolvimento da Motorola. Introdução Nos últimos anos, as empresas cujos produtos são compostos por hardware e software têm buscado atingir a qualidade em seus produtos de forma que isso as torne mais competitivas em um mercado cada vez mais exigente. Os métodos e técnicas para garantir a qualidade de hardware estão num patamar de estabilidade delineados por suas características físicas quase que imutáveis. Já não se pode dizer o mesmo com relação à estabilidade do software, pois este possui uma flexibilidade similar à mente humana, em que não há limites para variações de suas criações [Pemmaraju 1998]. Neste contexto, as organizações maduras estão gastando esforços para aprimorar seus conhecimentos em técnicas, métodos e processos de qualidade de software que garantam a distribuição de um produto e/ou serviço com rapidez, qualidade e custo reduzido. A empresa Motorola [Motorola 1947], considerada uma das gigantes do mercado de telefonia celular, adquiriu ao longo de sua existência, conhecimentos de que durante o ciclo de desenvolvimento de software, um pequeno erro de código poderia resultar em uma vulnerabilidade crítica, que comprometeria o funcionamento de todo um sistema, no caso, o telefone celular. Para evitar tais ocorrências, foi fundamental a escolha e a implementação de mecanismos de revisão do código fonte, que facilitassem a detecção dos erros em fases iniciais de desenvolvimento. Como um dos mecanismos mais recomendados pelos especialistas de segurança e qualidade de código é a análise estática [Graff and Van 2003], a Motorola selecionou a ferramenta Klocwork [Klocwork 1996]. 397

397 Este artigo tem como objetivo discorrer sobre a experiência da empresa Motorola na utilização da Klocwork, mostrando os benefícios encontrados com a implementação e uso da ferramenta na divisão de telefonia celular. Análise Estática de Código Análise estática em software é uma técnica que varre o código fonte de um programa, percorrendo-o linha a linha, à procura de erros, e produz um relatório que descreve os defeitos que potencialmente podem existir. Em sistemas com milhões de linhas de código e que são desenvolvidos em ambientes multisite, onde o desenvolvimento é realizado paralelamente por times de projeto geograficamente distribuídos, apenas a utilização de técnicas tradicionais como a revisão manual [Teixeira et al. 2007] para verificar um código desta dimensão seria custoso e ineficiente. A aplicação desta técnica em grandes empresas globalizadas se tornou possível devido ao desenvolvimento de ferramentas de análise estática de código. O emprego das ferramentas de análise estática nas fases iniciais de desenvolvimento, onde há mais oportunidades de injeção de erros, é um dos modos mais efetivos para reduzir os custos de correção e conseqüentemente elevar as taxas de ROI (Return of Investment) das empresas que as utilizam. Segundo [Gordon 2006] um defeito encontrado em fases posteriores ao ciclo de desenvolvimento, ou seja, quando o produto está em fase final de teste ou mesmo já disposto ao mercado, é entre 50 a 1000 vezes mais caro de ser corrigido, do que se fosse detectado em fases iniciais de desenvolvimento, Figura 1. Figura 1. Custo para correção de defeitos no ciclo de desenvolvimento de código. Dentre as diversas ferramentas comerciais existentes [Feiman and MacDonald 2007a] [Feiman and MacDonald 2007b] [MacDonald and Feiman 2007], a Motorola selecionou a ferramenta Klocwork, pois ela provê os tipos de erros que a empresa 398

398 estava interessada em analisar, e não havia necessidade de modificar o código fonte. Além disso, a Klocwork é capaz de entender o código através de uma base de conhecimento que é alimentada recursivamente com informações do sistema analisado, não se restringindo apenas à procura de padrões. A ferramenta Klocwork foi projetada para análise estática de códigos C, C++ e Java visando atender empresas que produzem sistemas de software em larga escala, tipicamente sistemas com ou mais linhas de código. Ela possibilita a identificação precoce de erros potenciais que poderiam provocar a indisponibilidade da aplicação, bem como graves falhas de segurança que poderiam ser exploradas por agentes maliciosos. A ferramenta disponibiliza uma interface gráfica, chamada Insight, para visualização do código facilitando a compreensão da arquitetura do sistema (Figura 2), a navegação e análise dos defeitos e a coleta de dados para a criação de gráficos de tendências de ocorrências dos tipos de erros (Figura 3). Figura 2. Insight - Visão da Arquitetura do Sistema. 399

399 Figura 3. Insight - Categorias de defeitos encontrados em um sistema. Klocwork na Motorola O Projeto A Motorola iniciou a utilização da ferramenta Klocwork como uma iniciativa de prover uma ferramenta de análise estática durante o ciclo de desenvolvimento de código na divisão Mobile Devices. Tinha como perspectiva identificar e corrigir erros encontrados no time zero, ou seja, na fase inicial de desenvolvimento. A divisão Mobile Devices é a responsável pela criação e desenvolvimento de software básico e aplicações para os telefones celulares da Motorola. Os fatores chaves que levaram à sua escolha para a utilização de uma ferramenta de análise estática foram: o apesar da existência de um processo de qualidade já implementado e incorporado no ciclo de desenvolvimento de software, a grande dimensão e complexidade do sistema dão margem à maior possibilidade de injeção de erros durante o ciclo de desenvolvimento, notadamente na fase de codificação; o a percepção da alta gerência da divisão e do time de qualidade, de que muitos erros eram encontrados em fases finais, próximas às datas de entrega dos produtos, aumentam consideravelmente o custo de correção; o os tipos de erros mais comuns poderiam ser facilmente detectados por ferramentas de análise estática e, se corrigidos no momento próximo de onde são injetados, são de fácil correção, minimizando o impacto no planejamento de esforço e prazo de entrega do produto. 400

400 Durante o processo de implantação da ferramenta Klocwork algumas dificuldades foram identificadas e contornadas para tornar viável o sucesso do projeto. Dentre as principais podemos destacar: o uniformizar o uso da ferramenta para os grupos de desenvolvimento geograficamente separados. Devido ao grande número de usuários espalhados em vários sites da divisão de Mobile Devices era importante que fosse estabelecido um processo bem definido, centralizado e claro de utilização da ferramenta pelos usuários e administração pelo time de suporte; o customizar a ferramenta para atendimento das necessidades da Motorola; o disseminar o conhecimento do uso da ferramenta sem treinamentos específicos para cada desenvolvedor. O real sucesso dessa iniciativa foi alcançado nos últimos 2 anos, quando o uso da ferramenta Klocwork foi integrado oficialmente no processo de desenvolvimento de software e um time de especialistas no uso da ferramenta foi criado para dar todo o suporte aos usuários. O time foi formado com a proposta de disseminar conhecimentos sobre as melhores práticas de programação e sobre a melhor forma de usar a ferramenta Klocwork: como executá-la, como interpretar os erros apontados, indicar a melhor forma de corrigí-los, etc. Além disso, os membros do time deveriam conhecer profundamente o ambiente de desenvolvimento e manter a infraestrutura necessária para o uso transparente da ferramenta pelos desenvolvedores. A proposta original foi amplamente atendida e extendida para explorar as funcionalidades complementares oferecidas pela Klocwork. Além da análise estática, esta também oferece análise de uso de memória local (stack analysis) [Regehr 2004a] [Regehr 2004b], análise de complexidade do código [IEEE 1990] [McCabe and Watson 1994], análise de arquitetura e métricas sobre a densidade de defeitos [Klocwork 1996]. Portanto, atualmente as atividades do time são: Analisar os defeitos encontrados e reportá-los aos times de desenvolvedores, de forma a ajudá-los a entender a melhor maneira de corrigí-los; Manter a infraestrutura da ferramenta atualizada; Participar de fóruns de discussão técnica e prover suporte aos usuários orientando-os no uso da ferramenta; Analisar a complexidade do código e sugerir melhorias; Analisar o gerenciamento de memória local das aplicações dos celulares, de forma a sugerir otimizações, visto ser esse um dos recursos mais críticos, pela sua escassez; Fornecer à alta gerência informações sobre a quantidade e tipos dos defeitos encontrados no código de cada produto. Os Ganhos Como participantes do time de suporte à ferramenta Klocwork, percebemos que os ganhos obtidos através da experiência no uso de uma ferramenta de análise estática em código de celulares, são vários. 401

401 O mais evidente, e amplamente ilustrado na literatura especializada [Gordon 2006], diz respeito à redução no custo do produto quando a correção de erros é realizada nas fases iniciais de desenvolvimento de código, conforme ilustrado na Figura 1. O desenvolvedor que faz uma parte de um componente de software de um telefone celular só tem conhecimento da pequena porção sob a sua responsabilidade. Muitas vezes ele não tem a noção de que uma alteração na sua parte pode afetar o sistema como um todo. Usando a ferramenta Klocwork este problema é minimizado, porque a ferramenta oferece a possibilidade de analisar uma porção de código ou uma aplicação inteira, onde as relações entre as diversas partes também são analisadas. O uso da ferramenta além de facilitar a identificação e correção de erros em uma fase precoce, tem ainda um caráter educativo, porque os desenvolvedores aprendem com os erros e tendem a adotar boas práticas de programação, conseqüentemente errando menos no futuro. A alta gerência recebe informações freqüentes sobre o real estado da qualidade de seus produtos durante o período de construção, o que permite a tomada de decisões rápidas para sanar possíveis pontos fracos. Por exemplo, é possível verificar quais são os tipos de erros mais freqüentes e, com base nesta informação, organizar treinamentos específicos para que os desenvolvedores aprendam a evitá-los. Conclusão A ferramenta Klocwork oferece um conjunto de funcionalidades muito útil para auxiliar na construção de software com mais qualidade, por atuar num momento crucial onde ocorre a maior possibilidade de injeção de erros, durante a fase de codificação. Uma das constatações mais importante da experiência adquirida, na divisão Mobile Device da Motorola, foi a de que é imprescindível ter um grupo ou um profissional com profundo conhecimento sobre a ferramenta e sobre o ambiente onde ela será utilizada. Por possuir várias funcionalidades, além da análise estática, e com a característica de reconhecimento de código e não apenas padrões, ela é complexa e exige uma boa administração para ter os seus benefícios maximizados. É importante que o uso da ferramenta seja um item inserido no processo de qualidade de software. A experiência mostra que os usuários, quando pressionados por prazos e demandas, tendem a evitar passos adicionais que sejam opcionais. Além disso, é importante que ela seja oferecida ao desenvolvedor para ser incorporada ao seu cotidiano como um instrumento que vai ajudá-lo e não como um obstáculo a mais a ser superado. Isso ocorreria se ele não tivesse suporte imediato sempre que encontrasse dificuldades no uso da ferramenta. Portanto, o uso da ferramenta deve ser transparente para o desenvolvedor, ou seja, executar a análise estática deve ser tão simples quanto executar uma compilação. A atuação do time de Klocwork tornou-se tão efetiva na divisão Mobile Devices que outras divisões estão requisitando a ajuda para implementação do uso da ferramenta como parte de seu processo. Isso demonstra além da boa aceitação dos resultados 402

402 obtidos até agora, o desejo de utilizar as melhores práticas para construir produtos com mais qualidade. Referências Feiman, J. and MacDonald, N. (2007a), Static Application Security Testing: Vendors and Products, Part1, Doc ID: G , January, available at: (último acesso: 10 de março de 2008) Feiman, J. and MacDonald, N. (2007b), Static Application Security Testing: Vendors and Products, Part3, Doc ID: G , August, available at: (último acesso: 10 de março de 2008) Gordon, I. (2006) Automated Source Code Analysis: Reduce Customer and QA Defects to Save Time and Money!, September, available at: (último acesso: 10 de março de 2008) Graff, M. G. and Van Wyk, K. R. (2003) Secure Coding: Principles and Practices. Cambridge, MA: O'Reilly. Institute of Electrical and Electronics Engineers. (1990) IEEE Standard Computer Dictionary: A Compilation of IEEE Standard Computer Glossaries. New York, NY. Klocwork, Inc. (1996) MacDonald, N. and Feiman, J. (2007), Static Application Security Testing: Vendors and Products, Part2, Doc ID: G , August, available at: (último acesso: 10 de março de 2008) McCabe, T. J. and Watson, A. H. (1994) Software Complexity. Crosstalk, Journal of Defense Software Engineering 7, p Motorola, Inc. (1947) Pemmaraju, K (1998) The Quest for Software Quality (último acesso: 10 de março de 2008). Regehr, J.(2004a) Using Static Analysis to Bound Stack Depth, October, available at: (último acesso: 10 de março de 2008) Regehr J.(2004b) Say no to stack overflow. Embedded Systems Programming, 17(10), October. Teixeira, M. et al. (2007) Avaliação de Ferramentas de Análise Estática de Código para Detecção de Vulnerabilidades., disponível em: (último acesso: 10 de março de 2008) 403

403 404

404 VII Simpósio Brasileiro de Qualidade de Software Concurso de Teses e Dissertações em Qualidade de Software Prêmio Prof. Arnaldo Dias Belchior

405

406 Geração de Metadados para o Apoio ao Teste Estrutural de Componentes Vânia Somaio Teixeira 1,2, Marcio Eduardo Delamaro 1 1 Programa de Pós-graduação em Ciência da Computação (PPGCC) Centro Universitário Eurípides de Marília (UNIVEM) Marilia, SP 2 Faculdade Gennari&Peartree (FGP) Pederneiras, SP vania@fgp.com.br, delamaro@pesquisador.cnpq.br Abstract. The use of components in the software development brings benefits in terms of quality and productivity. On the other hand, it has added complexity to a few activities like software testing. In this context, there are two different perspectives: one from the component developer and other from the component user. Among the main problems related to the test of component-based applications is the lack of information exchanged between these two perspectives. The developer does not know the contexts where the component will be used and the user ignores how the component was validated or what its validation requirements are. In this work we propose the use of structural coverage measures produced by the developer as an aid to the integration of the component in a user application. Such information is appended to the component code as metadata generated by a tool that automatizes this process. Resumo. O uso de componentes no desenvolvimento de software traz benefícios, em termos de qualidade e produtividade, mas, por outro lado, acrescenta complexidade em algumas atividades, em particular, para a atividade de teste. Nesse contexto, podem-se destacar as perspectivas do desenvolvedor e do usuário do componente. Dentre os principais problemas relacionados ao teste de aplicações baseadas em componentes está a falta de informação. O desenvolvedor não conhece os contextos de utilização do componente e o usuário ignora os requisitos e a forma de validação do componente. Propõe-se neste trabalho a utilização de medidas de cobertura de teste estrutural, fornecidas pelo desenvolvedor, para auxiliarem na integração do componente nas aplicações do usuário. Tais informações são agregadas ao componente na forma de metadados e geradas por meio de uma ferramenta que auxilia na automatização deste processo. 1. Introdução O objetivo da Engenharia de Software é a construção de software com qualidade e com baixo custo. Para tanto, diversos métodos, técnicas e ferramentas têm sido propostos e utilizados buscando o aumento da produtividade no desenvolvimento de software. Uma das formas para tal foi o reaproveitamento de artefatos de software. Assim, em vez de iniciar-se sempre um projeto de software do zero, são reutilizadas soluções e experiências adquiridas em projetos anteriores. É o que se costuma chamar de reúso de software. 405

407 Brereton e Budgen (2000) argumentam que o desenvolvimento baseado em componentes tende a trazer grandes benefícios na produção de software, favorecendo o reúso. Entretanto, eles apontam diversas questões que precisam ser tratadas, principalmente, pelos desenvolvedores. Dentre essas questões estão: 1) a descrição do componente favorecendo sua localização, entendimento e avaliação; 2) o suporte automatizado visando ao desenvolvimento de ferramentas para apoiar as atividades de busca, entendimento, avaliação e visualização das decisões no uso de componentes; e 3) a avaliação de componentes fornecendo mecanismos para facilitar a sua avaliação e comparação. Embora o reúso de software não seja uma prática recente, a adoção do paradigma de desenvolvimento baseado em objetos popularizou a adoção de novas técnicas de reúso como o desenvolvimento de software baseado em componentes, que é a reutilização de software por meio do encapsulamento de funcionalidades em unidades de software que são independentes e podem ser acopladas a um sistema por meio de uma interface conhecida. Beydeda e Gruhn (2003) reafirmam os benefícios no uso de componentes, mas, por outro lado, admitem que existam dificuldades que precisam ser transpostas, principalmente na fase de testes. Dificuldades essas, como a falta de informação sentida tanto pelo desenvolvedor quanto pelo usuário do componente, para que a atividade de teste seja realizada de forma sistemática e com qualidade. O desenvolvedor do componente não conhece todos os contextos de utilização do componente e, portanto, o componente pode ter um comportamento em determinados ambientes conforme o esperado e em outros não. O usuário sofre com a falta de documentação adequada sobre o componente e como ele foi validado, agravada, em geral, pelo fato de o código fonte não lhe estar disponível. A troca mais efetiva de informações entre desenvolvedor e usuário do componente pode colaborar para se definir uma estratégia de teste adequada para o desenvolvimento baseado em componentes. Neste contexto, o foco deste trabalho é estabelecer uma estratégia de teste, na qual o desenvolvedor teste o componente e forneça ao usuário as informações sobre como essa atividade foi desenvolvida, na forma de metadados. Propõe-se, para isso, a utilização da técnica de teste estrutural, e a geração de metadados que sumarizem a cobertura de requisitos estruturais alcançados pelo desenvolvedor. Essa informação deve auxiliar o usuário do componente a avaliar a adequação dos seus próprios conjuntos de testes em exercitar os requisitos estruturais do componente. Para viabilizar essa estratégia, propõe-se, também, uma ferramenta para geração (pelo desenvolvedor) e utilização (pelo usuário) desses metadados. Na próxima seção são destacados alguns trabalhos relacionados ao teste de componentes, em particular aqueles que abordam a geração e utilização de algum tipo de informação extra que facilite o teste de aplicações baseadas em componentes. A Seção 3 descreve a estratégia de teste proposta. A Seção 4 resume as funcionalidades da ferramenta FATEsC (Ferramenta de Apoio ao Teste Estrutural de Componentes), que apóia a aplicação da estratégia. A Seção 5 discute o estudo de caso realizado e a Seção 6 contém as considerações finais deste artigo. 2. Trabalhos relacionados Partindo-se da constatação de que a falta de informação é um entrave para a atividade de teste de componentes, encontram-se na literatura diversas abordagens que procuram solucionar ou minimizar esse problema. Dentre elas, Liu e Richardson (1998) propõem 406

408 o retro-component, que fornece informações por meio de um mecanismo chamado retrospector, que tem por objetivo incorporar ao componente, dados estáticos e dinâmicos sobre os testes e execuções do mesmo. O retrospector é uma entidade de software que tem a capacidade de comunicar-se com as ferramentas usadas pelo desenvolvedor, testador e usuário do componente, captando informações sobre os testes realizados, recomendações de testes para o usuário do componente, critérios utilizados, histórico dos testes, casos de teste, parâmetros utilizados na execução e essas informações podem estar gravadas e disponíveis para o desenvolvedor e usuário do componente. Orso et al. (2000) propõem que informações adicionais (metadados), de vários tipos, sejam fornecidas pelo desenvolvedor ao usuário do componente. Três propriedades básicas dos metadados são definidas: i) o desenvolvedor do componente deve estar envolvido na produção dos metadados; ii) os metadados devem ser empacotados com o componente e; iii) o desenvolvimento e a apresentação dos metadados devem ser apoiados por ferramentas. Também propõem para cada tipo de metadado que seja criada uma identificação única (DTD Document Type Definition) para facilitar sua utilização. Bundell et al. (2000), da mesma forma, propõem que se forneçam informações adicionais sobre o componente para apoiar as atividades de análise e teste. Para isso, sugerem preparar uma especificação de teste que descreva implementações do componente, interfaces fornecidas para cada implementação e um conjunto de teste apropriado para testar as interfaces. Essa especificação de teste deve ser armazenada em arquivos XML (Extensible Markup Language), pois esse tipo de arquivo é facilmente processado por várias ferramentas, de modo que a especificação de teste possa ser lida, interpretada e modificada. Edwards (2001) propõe que informações sejam empacotadas pelo desenvolvedor do componente utilizando a técnica de wrapper e fornecidas para o usuário do componente. O funcionamento da técnica wrapper está baseado na definição de um componente, denominado de wrapper, que encapsula o componente original e atua como filtro para as requisições recebidas, determinando o comportamento do componente como desejado. As informações seriam sobre a especificação do componente e as ações de garantia da qualidade executadas pelo desenvolvedor. Nenhum desses trabalhos, porém, explicita quais informações devem ser fornecidas pelo desenvolvedor, ou como o usuário do componente pode utilizar essas informações. Dessa forma, o trabalho corrente contribui ao definir uma estratégia de utilização de informações de cobertura, resultantes do teste estrutural conduzido pelo desenvolvedor, que seriam disponibilizadas ao usuário, juntamente com o componente, na forma de metadados. 3. Estratégia de teste estrutural para aplicações baseadas em componentes A técnica de teste estrutural, conhecida também por teste caixa-branca tem, tradicionalmente, como requisito básico a necessidade do uso do código fonte, visto que seu objetivo é exercitar as estruturas internas do programa. Os casos de teste derivados dessa técnica visam a garantir que estruturas de um programa (comandos, caminhos, variáveis, etc) sejam exercitadas de maneira a garantir alguma propriedade que indique certa qualidade do conjunto de teste utilizado. Sabe-se que nenhuma das técnicas de teste é completa, no sentido que a cada uma podem-se associar características específicas em termos de efetividade em revelar defeitos. No contexto de teste de 407

409 componente isso não muda; assim, a existência de outras estratégias de teste que utilizem, por exemplo, a técnica de teste funcional, não invalida a estratégia aqui proposta, pelo contrario, a complementa. Tradicionalmente, para se utilizar a técnica de teste estrutural é requisito básico que o código fonte esteja disponível e isso é uma contraposição para desenvolvimento baseado em componente se olharmos pela ótica do usuário do componente, pois na maioria das vezes o código fonte não está disponível. Pela ótica do desenvolvedor do componente a atividade de teste é muito parecida com as desempenhadas em desenvolvimento tradicional [VINCENZI et al., 2005]. Para que a estratégia proposta seja viável faz-se necessária a análise de cobertura estrutural mesmo sem a disponibilidade do código fonte, quando realizada pelo usuário do componente. Isso é possível em alguns cenários por meio da análise do código objeto, como faz a ferramenta JaBUTi [VINCENZI et al., 2006], que foi desenvolvida para apoiar o teste estrutural em programas Java. Com o uso desta ferramenta, que efetua toda a análise estática e dinâmica do programa em teste a partir do bytecode Java, é permitido ao usuário do componente avaliar a cobertura do seu conjunto de teste sobre o código do componente, sem que o código-fonte lhe esteja disponível Premissa Considere um critério de teste estrutural C, um componente k e um conjunto de teste T 1 = {t 1, t 2,..., t 5 }, C-adequado 1 para k. Se uma aplicação A reutiliza o código do componente k, pode-se utilizar as medidas de cobertura do código k para avaliar o nível de integração obtido por um conjunto T 2 = {t 1, t 2 } utilizado para testar a aplicação A. Isso implica que se T 1 está adequado, segundo o critério utilizado, para o código do componente k, e T 2 tem as mesmas medidas de cobertura obtidas por T 1, então pode-se supor que T 2 também é bom para exercitar a integração do componente na aplicação A. Porém, é preciso lembrar que muitas vezes não é possível que o usuário do componente obtenha a mesma cobertura conseguida pelo desenvolvedor do componente utilizando um critério C, visto que nem sempre todas as funcionalidades do componente são utilizadas pela aplicação do usuário. Um resumo dessa idéia pode ser visto na Figura 1. No lado do desenvolvedor, um driver de teste é usado para cobrir um conjunto de requisitos do componente. Os requisitos pontilhados são os que o desenvolvedor conseguiu cobrir com seus casos de teste. Do lado do usuário, esses requisitos aparecem como círculos contínuos e serão utilizados para avaliar a cobertura obtida por um conjunto de teste do usuário. Certamente o usuário não cria um conjunto de teste para o componente, mas sim para sua aplicação. Porém, a cobertura obtida indiretamente por seus casos de teste sobre o código do componente dá a idéia de integração entre sua aplicação e o componente. 1 Dado um conjunto de teste T e um critério C, caso T contenha casos de teste capazes de exercitar todos os requisitos de teste exigidos por C, diz-se que T é adequado ao critério de teste C, ou, em outras palavras, T é C-adequado. 408

410 Figura 1 Utilização de dados de teste gerados pelo desenvolvedor Proposta Para a realização desta estratégia propõe-se que o desenvolvedor do componente forneça metadados empacotados com o componente ao usuário. Nesse contexto, entendem-se metadados como sendo as informações de: 1) medidas de cobertura obtidas para cada caso de teste, por método público para os critérios de teste estrutural; e 2) uma descrição das características de cada caso de teste. Para facilitar a compreensão, apresenta-se a seguir um exemplo simples considerando a classe Fat um componente, que faz o cálculo do fatorial de um número e a classe Agrupamentos uma aplicação, que faz o cálculo de combinação simples, utilizando o componente Fat. A Figura 2 mostra o código fonte da classe Fat e a Figura 3 o código fonte da classe Agrupamentos. Considera-se neste exemplo o critério Todos-Arcos, que gera 12 requisitos de teste para o método Fat, ou seja, possui 12 desvios (branchs) numerados de 0 a 11, conforme apresentado na Figura 4 e que devem ser cobertos pelos casos de teste. Pressman (2002) explica que os critérios baseado no fluxo de controle usam apenas características de controle de execução do programa, como comandos ou desvios, para determinar quais estruturas são requeridas. O critério Todos-Arcos requer que cada aresta do grafo (desvios) seja executada pelo menos uma vez. public class Fat { /* calcula o fatorial de um número inteiro. O valor passado deve ser >= 0 e <= 20. O valor retornado é um long */ } { } public long fat(int x) if ( x < 0 x > 20 ) return -1; if ( x == 0 ) return 1; if ( x <= 2 ) return x; long s = 1; while ( x > 1 ) { s *= x; x--; } Figura 2. Código fonte do componente Fat 409

411 public class Agrupamentos { /* Calcula o número de combinações de k elementos n a n. Os valores passados devem ser >=1 e de deve ser >= n */ } public long combinacao(int k, int n) { Fat f = new Fat(); if (k < 1 n < 1 k < n ) throw new IllegalArgumentException("Argumento invalido"); long s = f.fat(k); s /= f.fat(n); s /= f.fat(k-n); return s; } Figura 3. Código fonte do aplicação Agrupamentos que utiliza o componente Fat Figura 4. Grafo do método fat do componente gerado pela ferramenta JaBUTi Com o apoio da ferramenta FATEsC (descrita posteriormente) o desenvolvedor associa casos de teste ao método Fat, conforme mostra a Tabela 1. Os casos de teste são definidos utilizando-se o formato JUnit (framework para desenvolvimento de teste de unidade em Java) [MASSOL e HUSTED, 2005] e os dados de cobertura são obtidos com a sua execução pela ferramenta JaBUTi. O desenvolvedor pode também associar a cada caso de teste uma descrição textual que mostre qual o comportamento que se espera do componente, como mostra a Tabela 2. Os dados de cobertura e as descrições dos casos de teste são empacotados juntamente com o código do componente e, então, disponibilizados ao usuário. O usuário do componente, por sua vez, define um conjunto de teste para sua aplicação e, de posse das informações descritas acima, pode avaliar sua adequação também em relação aos requisitos do componente ou, de forma mais precisa, pode 410

412 avaliar a correta integração do próprio código do componente. Suponhamos, por exemplo, que tenha definido um conjunto de quatro casos de teste conforme mostra a Tabela 3. Tabela 1 Exemplo de medidas de cobertura fornecidas como metadados. Nome dos casos de teste Requisitos cobertos para o método Fat testfat1 7 testfat2 4 e 5 testfat3 0, 3 e 5 testfat4 1, 3, 5 e 10 testfat5 1, 2, 3, 5, 6, 8, 9 e 11 Tabela 2 Exemplo dos descritivos dos testes fornecidos como metadados. Conjunto de teste testfat1 testfat2 testfat3 testfat4 testfat5 Descrição informal dos testes Passado o valor -1 como argumento para o método Fat, pois esse trata de modo particular valores de entrada negativos. Passado o valor 25 como argumento para o método Fat, pois esse trata corretamente valores de entrada inteiros até 20 apenas. Para esse valor passado o resultado deveria ser -1, conforme especificado na interface do componente. Passado o valor 0 como argumento para o método Fat: valor com tratamento especial. Passado o valor 2 como argumento para o método Fat, pois esse trata de modo particular valores maiores que zero e menores ou iguais a 2. Passado o valor 15 como argumento para o método Fat para efetuar o cálculo do seu fatorial. Tabela 3 Exemplo de medidas de cobertura obtidas pelo usuário do componente. Conjunto de teste Dados de teste Requisitos cobertos para o método Fat testagrupamentos1 k = 0, n = 1 - testagrupamentos2 k = 1, n = 0 - testagrupamentos3 k = 5, n = 7 - testagrupamentos4 k = 10, n = 3 1, 2, 3, 5, 6, 8, 9 e 11 Ao comparar as coberturas dos requisitos obtidas pelo desenvolvedor e usuário do componente, é constatado que em alguns casos a cobertura não foi a mesma. Por exemplo, testfat3 cobriu 3 requisitos, dos quais os casos de teste do usuário cobriram apenas 2, conforme apresentado na Tabela 4. Tabela 4 Sumário dos dados de cobertura obtidos pelo usuário e desenvolvedor do componente. Conjunto de Quantidade de requisitos Quantidade de requisitos Porcentagem de teste cobertos no componente cobertos na aplicação cobertura testfat % testfat % testfat % testfat % testfat % 411

413 De posse dessas informações o usuário do componente deve analisar cada caso onde a cobertura não foi a mesma obtida pelo desenvolvedor, utilizando para apoiá-lo as descrição dos casos de testes disponibilizados como metadados. Em sua avaliação o usuário do componente pode chegar a essas conclusões: Os testes testfat1 e testfat3 não podem ser reproduzidos para sua aplicação, visto que ela não aceita valores negativos e nem menores ou igual a 1; Para o teste testfat2 o usuário do componente perceberá que o componente tem o limite de cálculo do fatorial para números até 20, portanto, deveria ter tratado essa situação em sua aplicação; Para alcançar a mesma cobertura do teste testfat4, bastaria que o usuário acrescentasse um caso de teste que passasse, por exemplo, 10 e 2 como argumento, visto que o fatorial de 2 é tratado de forma diferenciada. Essas análises mostram como a estratégia adotada por esse trabalho ajuda a revelar defeitos e como o usuário pode verificar a adequação de seus casos de teste em exercitar a integração do componente em sua aplicação e com isso melhorá-la. 4. FATEsC Ferramenta de Apoio ao Teste Estrutural de Componentes Apresenta-se a seguir, utilizando o mesmo exemplo acima, as funcionalidades da ferramenta FATEsC. A partir de um arquivo jar contendo o bytecode do componente, cuja estrutura hierárquica é apresentada na parte esquerda (1) da Figura 5, o desenvolvedor do componente pode criar casos de teste para cada interface pública do componente. Os casos de teste são exibidos na parte direita da tela (3), podendo a qualquer tempo ser selecionado. Após a seleção o código fonte do caso de teste, que está no formato JUnit, bem como sua descrição podem ser vistos e editados na parte central da tela (2). Após a geração dos casos de teste, a FATEsC disponibiliza a funcionalidade de juntar todos os casos de testes em um arquivo único e compilá-lo. Os casos de teste devem então ser executados na Ferramenta JaBUTi. As informações de cobertura dos testes, realizados na Ferramenta JaBUTi, são capturadas pela Ferramenta FATEsC e disponibilizadas no formato XML, ou seja, para cada caso de teste utilizado para testar uma determinada interface pública do componente, obtém-se os requisitos cobertos separados por critério de teste. Um requisito coberto pode ser um comando, um desvio, uma associação definição-uso ou outro elemento estrutural, definido pelo critério de teste que está sendo usado pelo desenvolvedor. Antes de liberar o componente, os dados de cobertura dos casos de testes e as descrições dos casos de testes são disponibilizados junto ao componente, o que significa adicionar metadados XML gerados pela FATEsC ao arquivo contendo o bytecode do componente no formato.jar, que será usado pelo usuário do componente. O usuário do componente, por sua vez, também utiliza a FATEsC para criar os casos de testes para a sua aplicação que utiliza o componente, o processo é semelhante ao executado pelo desenvolvedor do componente, conforme Figura 6. Após a obtenção dos dados de cobertura dos seus casos de testes executados na Ferramenta JaBUTi, o usuário do componente, poderá fazer a análise da adequação de seus casos de testes, comparando-os com os dados de cobertura obtidos pelo desenvolvedor do componente. O usuário seleciona o critério e a interface pública do componente para o qual os resultados serão comparados, conforme apresentado na Figura 7. Na primeira coluna são listados os casos de testes gerados pelo desenvolvedor do componente. Na segunda coluna, são apresentados os dados de cobertura do componente, ou seja, quantidade de 412

414 requisitos cobertos pelo caso de teste. Na terceira coluna são apresentadas as quantidades de requisitos cobertos pelos casos de teste do usuário em relação à cobertura obtida pelo desenvolvedor do componente e na quarta coluna o cálculo da porcentagem de cobertura obtida pelo usuário do componente em relação à cobertura obtida pelo desenvolvedor do componente. No exemplo, o caso de teste testfat5 cobriu 8 requisitos e os casos de teste do usuário também cobriram os mesmos requisitos, portanto, a cobertura foi de 100%. Os requisitos cobertos, neste exemplo, referem-se a desvios do programa, visto que o critério escolhido é Todos-arcos. Já nos outros casos de testes, a cobertura não foi a mesma, ou seja, os casos de testes do usuário do componente, não conseguiram cobrir os mesmos requisitos cobertos pelos casos de testes do desenvolvedor do componente. Nesse caso é necessário que se faça uma análise com o objetivo de verificar se os casos de teste do usuário não estão adequados, ou se os casos de teste do componente não podem ser reproduzidos no contexto da aplicação Figura 5. Tela principal da FATEsC: (1) hierarquia do componente, (3) lista de casos de teste e (2) código fonte do caso de teste testfat1. Figura 6. Tela principal da FATEsC: hierarquia da aplicação, lista de casos de teste e código fonte do caso de teste testagrupamentos4. 413

415 Figura 7. Apresentação dos dados de cobertura obtidos pelo usuário e pelo desenvolvedor do componente. Para ajudar o usuário do componente em sua avaliação, é possível visualizar as descrições dos casos de testes disponibilizadas pelo desenvolvedor, bastando para isso selecionar o caso de teste desejado. Para o caso de teste testfat1, conforme apresentado na Figura 8, a descrição diz que foi passado um argumento negativo para o método fat e como a aplicação do usuário não faz acesso à interface pública do componente para parâmetros k < 1, n < 1 e k < n conclui-se que esse caso de teste não pode ser reproduzido para a aplicação. Nesse caso marca-se infeasible na tela de apresentação da descrição do caso de teste e o caso de teste é apresentado com uma cor diferente (cinza) representando a avaliação feita, conforme mostrado na Figura 9. Figura 8. Apresentação da descrição do caso de teste testfat1. Figura 9. Aparência de um caso de teste (testfat1) que não poderá ser reproduzido na aplicação do usuário do componente. Ao analisar o caso de teste testfat4, verificando a descrição do caso de teste apresentado na Figura 10, o usuário do componente perceberá que poderá alcançar a mesma cobertura que o caso de teste do componente, necessitando apenas criar um novo caso de teste que passe como parâmetros k = 10 e n =

416 Figura 10. Apresentação da descrição do caso de teste testfat4. Ao analisar o caso de teste testfat2, verificando a descrição do caso de teste apresentado na Figura 11, o usuário do componente perceberá que o cálculo do fatorial de 25 não é -1, então poderá se lembrar que o componente calcula o fatorial até o número 20 e que esta limitação deverá ser tratada em sua aplicação, isso mostra como a estratégia adotada por esse trabalho ajuda a revelar defeitos. Assim, o usuário do componente deveria continuar suas análises até que as coberturas se igualassem ou se concluísse que alguns casos de testes não poderiam ser reproduzidos para a aplicação. Figura 11. Apresentação da descrição do caso de teste testfat2. 5. Estudo de caso Para o estudo de caso utilizou-se o pacote Lookup da ferramenta JaBUTi como componente e desenvolveu-se uma aplicação que utiliza algumas funcionalidades do componente. O componente Lookup é composto por quatro classes: 1) Program que é uma abstração de um programa com vários arquivos.class; 2) As classes de interesse dentro do programa são representadas pelo objeto RClassCode; 3) as classes periféricas aparecem como objetos RClass; 4) a classe ClassClosure é usada para explorar a estrutura do programa e contém alguns métodos para procurar as dependências de classes do programa. O objetivo deste estudo de caso foi validar, com dados mais substanciais, as funcionalidades da ferramenta FATEsC e verificar se a estratégia de teste apresentada por esse trabalho apresenta benefícios. Neste estudo, a mesma pessoa que elaborou os casos de teste para o componente foi quem desenvolveu a aplicação e seus casos de teste. O componente Lookup tem 803 linhas de código e foram criados 82 casos de teste na ferramenta FATEsC para exercitar os requisitos de teste, segundo o critério de teste 415