RiSE reference model for software reuse adoption in brazilian companies

Texto

(1)“RiSE Reference Model for Software Reuse Adoption in Brazilian Companies” By. Vinicius Cardoso Garcia Ph.D. Thesis. Universidade Federal de Pernambuco posgraduacao@cin.ufpe.br www.cin.ufpe.br/~posgraduacao. RECIFE, MAY/2010.

(2) Universidade Federal de Pernambuco Centro de Informática Pós-graduação em Ciência da Computação. Vinicius Cardoso Garcia. “RiSE Reference Model for Software Reuse Adoption in Brazilian Companies”. Trabalho apresentado ao Programa de Pós-graduação em Ciência da Computação do Centro de Informática da Universidade Federal de Pernambuco como requisito parcial para obtenção do grau de Ph.D. em Ciência da Computação.. A Ph.D. Thesis presented to the Federal University of Pernambuco in partial fulfillment of the requirements for the degree of Ph.D. in Computer Science.. Advisor: Silvio Romero de Lemos Meira Co-Advisor: Eduardo Santana de Almeida. RECIFE, MAY/2010.

(3) Garcia, Vinicius Cardoso RiSE reference model for software reuse adoption in brazilian companies / Vinicius Cardoso Garcia. - Recife: O Autor, 2010. xvi, 184 folhas : il., fig., tab. Tese (doutorado) – Universidade Federal de Pernambuco. CIn. Ciência da computação, 2010. Inclui bibliografia e apêndices. 1. Engenharia de software. 2. Reuso de software. I. Título. 005.1. CDD (22. ed.). MEI2010 – 082.

(4)

(5) I dedicate this dissertation to all my family, my future wife, my adviser and co-adviser, friends and professors who gave me all necessary support to get here..

(6) Agradecimentos É extremamente difícil resumir os agradecimentos por um trabalho de 5 anos. Foram muitos desafios, muitas horas de dedicação, muitas vitórias, sonhos alcançados e caminhos trilhados. Muitas pessoas participaram direta e indiretamente desta conquista, das mais variadas maneiras. Neste espaço, vou tentar destacar alguns pontos na certeza de que jamais conseguirei citar todos que colaboraram neste meu crescimento profissional e pessoal. Em primeiro lugar agradeço a Deus e a Nossa Senhora pela oportunidade e capacidade de aprender e onde eu sempre busquei forças e coragem para enfrentar os desafios e buscar meus sonhos, nunca deixando que eu me abatesse pelas quedas e tristezas durante a caminhada. Amém. Gostaria de agradecer a todos os professores da Universidade Salvador (UNIFACS) e da Universidade Federal de São Carlos (UFSCar), em especial Antonio Atta e Antonio Francisco do Prado pela paciência, conselhos, orientação e por abrirem as portas do mundo acadêmico e da pesquisa científica para mim. Sem estes ensinamentos, eu não teria a capacidade de trilhar este caminho. Agradeço também a todos os funcionários da Universidade Federal de Pernambuco, desde as recepcionistas, ao time de suporte, secretárias (os) que sempre me atenderam com simpatia, graciosidade e principalmente paciência. Incluo também todos os demais alunos de Mestrado e Doutorado com quem dividi os laboratórios e áreas comuns de pesquisa, pelas conversas técnicas e não técnicas durante estes anos. Definitivamente a UFPE é um lugar fantástico para se desenvolver um ótimo trabalho. Ao C.E.S.A.R (Centro de Estudos e Sistemas Avançados do Recife) por me fornecer um ambiente perfeito para meus estudos, onde pude identificar, definir, formalizar, evoluir, confrontar, experimentar, testar problemas e soluções relacionados com os diferentes aspectos do reúso de software, em especial sobre as melhores práticas para sua adoção, e principalmente aprender muito sobre Engenharia de Software além de me possibilitar ter acesso a profissionais em diferentes áreas. Gostaria de agradecer a todos os colaboradores, incluindo a área de suporte, marketing, controladoria, recursos humanos, capital humano, negócios, qualidade, engenharia e principalmente a diretoria, que sempre me deu todo suporte para o desenvolvimento do meu trabalho. Agradeço também a toda equipe do CESAR.edu, por todos os momentos e projetos desenvolvidos em conjunto, em especial Catarina, Reginaldo Valadares e Simone Pires. Este trabalho contou com o financiamento da Fundação de Amparo à Pesquisa do Estado da Bahia (FAPESB) e do Conselho Nacional de Desenvolvimento Científico e Tecnológico (CNPq). Some key researchers in the software reuse area offered valuable feedback for this work. Bill Frakes, Charles W. Krueger, Dirk Muthig, Ivica Crnkovic, Ruben PrietoDíaz, Wayne Lim, Maurizio Morisio, David Weiss, Klaus Schmid, Kyo C. Kang, Paul Clements, Rob van Ommering, Michalis Anastasopoulos, Paulo Merson, Jan Bosch, John McGregor, Frank van der Linden, John Favaro and David Rine spent important time discussing the key developments in the field of software reuse. It is really great to see important researchers spending their time with our ideas trying to improve the field. iv.

(7) as a whole. Additionally, I would like to thank Colin Atkinson for receiving me as a visiting researcher in his group and offering all the conditions for doing a good job. This was of great help to the conclusion of this work. Aos professores Alexandre Vasconcelos e Carina Alves da Universidade Federal de Pernambuco (UFPE), Jones Albuquerque da Universidade Federal Rural de Pernambuco (UFRPE), Alessandro Garcia da Pontifícia Universidade Católica do Rio de Janeiro (PUC-RIO) e a Claudia Werner da Universidade Federal do Rio de Janeiro (UFRJ) que contribuíram com valiosos comentários, sugestões e críticas com diferentes pontos de vista durante minha tese. Os resultados alcançados neste trabalho só foram possíveis graças ao apoio dos membros do grupo Reuse in Software Engineering (RiSE). Neste grupo encontrei a atmosfera ideal para discutir os diversos aspectos do reúso de software, e de tantas outras áreas correlatas. Tenho certeza absoluta que este será um dos principais grupos de pesquisa em reutilização de software do mundo (se já não está entre eles). Meus agradecimentos para todos os membros do RiSE, pela paciência em ouvir minhas idéias, discutir minhas opiniões e apoiar no desenvolvimento do meu trabalho. Sinto um imenso orgulho por fazer parte dessa história. Agradeço também, em especial, a Liana Barachisio pelas incontáveis revisões dos meus artigos e tese. A Paulo, Ivan, Leandro, Eduardo Cruz, Kellyton, Yguaratã e Róbson obrigado por toda ajuda nos eventos, encontros, desafios, projetos e tudo o mais que sempre inventávamos. Aos demais membros, por todos os momentos que partilhamos, o meu muito obrigado. Para validar este trabalho, o estudo experimental e o estudo de caso foram tarefas difíceis de serem realizadas e, durante estes processos, muitas pessoas foram importantes. Inicialmente gostaria de agradecer a todos os envolvidos no estudo de caso nas empresas, em especial Alexandre Martins, Alexandre Alvaro, Ivan Patriota, Ricardo Araújo e Helaine Lins. David Weiss, David Rine, Frank Van der Linden, John Favaro and Mauricio Morisio were also important in the survey implementation. Adicionalmente, durante este período alguns companheiros foram muito importante. Alexandre Alvaro, amigo antigo desde os tempos da UFSCar. Morfético, sem palavras para agradecer suas críticas sempre construtivas no meu trabalho, sua participação constante na evolução do mesmo e principalmente pelos diversos momentos de lazer por terras nordestinas (Recife, Natal e Salvador). Daniel Lucrédio, meu “co-co-orientador”, sua ajuda foi fundamental na formatação e consolidação do trabalho. Seu suporte foi algo imensurável e de grande valor técnico e pessoal. O meu muito obrigado a vocês dois, tenho muito orgulho por nossa amizade e por tudo que desenvolvemos juntos. Eduardo Almeida, meu co-orientador oficial e meu grande amigo. Muitos anos, muitos quilômetros percorridos por terra, água e ar. É uma satisfação enorme chegar a este momento e poder lhe agradecer por tudo o que compartilhamos e por todos os momentos que passamos. Aprendi e sempre aprendo muito com nossas conversas e você sabe da sua importância na realização dos nossos sonhos e mais ainda, na minha formação como profissional e como pessoa. Ainda temos muito o que fazer e conquistar, e tenho também muito orgulho de tudo que construímos ao longo desses 12 anos de parceria. A você meu amigo, o meu muito obrigado.. v.

(8) A Silvio Meira, meu mestre, amigo e exemplo de profissional. Seu legado foi uma inspiração (e transpiração) para mim durante esta jornada. Sua dedicação, motivação e visão do futuro da pesquisa/indústria/tecnologia e sobre os rumos que o mundo toma é fora do comum. “Nada resiste ao trabalho”, foi o que você me disse no dia em que nos conhecemos, e essa frase norteou todos estes anos e faz muito sentido para mim. Até mais do que o próprio significado destas palavras. Muitíssimo obrigado por todos os momentos de aprendizado que você me proporcionou, seja nas discussões sobre minha tese, meus artigos, projetos no C.E.S.A.R, oportunidades de vendas e negócios, sobre o RiSE ou até mesmo sobre a vida, seja na sua sala, nos corredores do CIn, do C.E.S.A.R, em caminhadas pelo Recife Antigo ou ainda nos bares da capital Pernambucana; por todos estes momentos e por ter acreditado em mim, serei eternamente grato. Durante estes anos em Recife, tive o privilégio de sempre contar com ótimos amigos no meu caminho. Não posso esquecer jamais de todo o suporte e companhia de Cinthya Roberta. CR você foi muito importante na minha chegada a Recife, sem o seu acolhimento, a transição teria ido bem mais complicada. Aos meus companheiros de república, Alexandre Alvaro, Eduardo Almeida, Ricardo Ramos, Ricardo Afonso, Leobino, Rogério, Yguaratã, Róbson e Geovane o meu muito obrigado por todos os momentos. Aos outros tantos amigos feitos em Recife, em especial Manuela e família e Emanoel Barreiros e família, o meu muito obrigado. a todos vocês. Heline Juliana Lins, meu amor. Nossos caminhos terem se cruzado só me faz agradecer a Deus por ter aceito o desafio de vir para Recife. Viver estes anos ao seu lado tem sido maravilhoso, e você teve (tem) um papel fundamental na minha vida. Sua paciência, carinho, atenção, companheirismo, respeito, e amor me ajudou na condução deste trabalho. Espero que possamos seguir caminhando juntos por muitos e muitos anos. Muito obrigado pela sua presença na minha vida, você é a minha luz. Agradeço também a sua família, por todo carinho e atenção que todos sempre tiveram por mim, me acolhendo como um membro da família. Finalmente mas não menos importante, gostaria de agradecer a minha família. Mesmo distantes fisicamente, a presença de vocês é constante na minha vida, na minha mente e no meu coração. Cada coisa que faço, faço graças a toda educação, força, fé e amor que recebo de todos vocês. A meu pai, minha mãe, minha irmã e minha sobrinha, esta vitória também é de vocês. Pai e mãe, admiro muito vocês por todos os esforços empregados na minha educação, para que eu tivesse sempre acesso ao que tinha de melhor. Me orgulho muito de vocês, pelo exemplo que vocês são para mim e espero poder ser um exemplo como este para meus filhos no futuro. Thaly minha irmã querida. . . com quem eu finjo não morrer de preocupação, você também me enche de orgulho pela forma como encara a vida, com seus desafios e inúmeros obstáculos. Você é um exemplo de superação. Nunca desista dos seus sonhos, a vida é muito para ser desperdiçada. Lute, batalhe, corra atrás porque no final você vai sair vencedora, tenho certeza. Aos meus avós, tios, tias e sobrinho, muito obrigado por estarem sempre presentes na minha vida e por todas as orações. Amo muito todos vocês! Finalmente, a todos aqueles que colaboraram direta ou indiretamente na realização deste trabalho. Meus sinceros agradecimentos.. vi.

(9) . . . a vitória de um homem às vezes se esconde num gesto forte que só ele pode ver . . . —O RAPPA, LADO B LADO A (1999).

(10) Resumo. Muitas organizações estão planejando investir ou já investiram dinheiro, tempo e recursos no reúso de software. Com esse investimento, essas organizações esperam melhorar a sua competitividade no mercado por meio da redução de custos e esforço, aumento da produtividade e melhoria da qualidade e da confiabilidade dos produtos de software desenvolvidos. Um problema comum é que as abordagens de reúso nas organizações são consideradas, normalmente, como um problema de adoção tecnológica (ambientes e ferramentas) e de processos, que focam nos aspectos técnicos do reúso. Neste cenário, processos de adoção de reúso - ou estratégias, modelos ou programas - têm se destacado na área como um facilitador para obter os benefícios associados ao reúso de software. No entanto, os processos existentes apresentam alguns problemas cruciais, como, por exemplo, serem fortemente relacionados a tecnologias específicas; demandarem um alto investimento inicial; além de não definirem de forma sistemática e suficientemente detalhada as atividades, papéis, entradas e as saídas de todo o processo. Assim, este trabalho propõe um modelo de referência de reuso de software para auxiliar nos processos de adoção e avaliação da capacidade de reúso nas organizações, baseado no estado da arte e da prática da área. Essa definição foi embasada por estudos detalhados sobre processos de adoção de reúso, modelos de referência de reúso e métodos de avaliação de capacidade em reutilização, envolvendo pesquisas informais, estudos empíricos e relatos de empresas. Com esta tese, pretende-se demonstrar que é possível estabelecer, para as empresas que desejam adotar reúso, um caminho mais seguro e com menores riscos e custos do que uma estratégia de reúso ad-hoc. Neste cenário, espera-se alcançar os seguintes objetivos: (i) aperfeiçoar o desempenho de alguns aspectos do desenvolvimento por meio de práticas de reúso (custo, qualidade, produtividade, competitividade da organização, entre outros); e (ii) redução dos riscos na adoção e/ou aperfeiçoamento de um programa de reúso, dando suporte a um processo incremental. Palavras-chave: Adoção de Reúso de Software, Avaliação de Reúso de Software, Modelo de Maturidade, Transferência de Tecnologia. viii.

(11) Abstract. Several companies are planning to invest, or have already invested, money, time and resources in software reuse. Through this investment, these companies expect to improve their competitiveness in the market through reduction of costs and effort, increase their productivity and improvement in the quality and reliability in the software products development. A common problem is that the reuse approaches in the companies are usually considered as technological (environments and tools) and process adoption problem that focus on technical aspects of reuse. In this scenario, reuse adoption processes - or strategies, models or programs - have been deployed in the area as a facilitator for the benefits associated to software reuse. However, existing processes present some critical problems such as, are strongly related to specific technologies; demand a high initial investment; and do not define in a systematic and sufficient detailed way the activities, roles, inputs and outputs of the whole process. Thus, this thesis proposes a reuse reference model to aid in reuse assessment and adoption process, based on the state of the art and practice of the area. This definition was based on detailed studies on the reuse adoption processes, reuse reference models and reuse capability assessment methods involving informal surveys, empirical studies and companies reports. This thesis seeks to demonstrate that it is possible to establish, for companies wishing to adopt reuse, a more secure way and with lower risks and costs than an ad-hoc reuse strategy. In this scenario, this thesis wants to achieve the following objectives: (i) improve the performance of various aspects of development through reuse practices (cost, quality, productivity, competitiveness of the company, among others); and (ii) reduce risks in the adoption and/or improvement of a reuse program, by providing support to an incremental process. Keywords: Software Reuse Adoption, Software Reuse Assessment, Maturity Model, Technology Transfer. ix.

(12) Contents. Acronyms. 1. 1 Introduction 1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 5 6. 1.2 1.3 1.4. Contextualizing Software Reuse in this Thesis . . . . . . . . . . . . . . Problem Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . Out of Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 8 10 11. 1.5 1.6. Statement of the Contributions . . . . . . . . . . . . . . . . . . . . . . Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 13 13. 2 Reuse Adoption Programs Survey. 15. 2.1 2.2 2.3. The Beginning of the Reuse Adoption Programs . . . . . . . . . . . . . The Second Age of the Reuse Adoption Programs . . . . . . . . . . . . Summary of the Study . . . . . . . . . . . . . . . . . . . . . . . . . .. 15 20 22. 2.4 2.5. Requirements for a Reuse Adoption Program . . . . . . . . . . . . . . Summary of this Chapter . . . . . . . . . . . . . . . . . . . . . . . . .. 24 27. 3 Reuse Maturity Models Survey 3.1 3.2. 28. Background on Maturity Models . . . . . . . . . . . . . . . . . . . . . The Reuse Maturity Models Survey . . . . . . . . . . . . . . . . . . . 3.2.1 Holibaugh et al., 1989 . . . . . . . . . . . . . . . . . . . . . .. 28 36 36. 3.2.2 3.2.3. Koltun and Hudson, 1991 . . . . . . . . . . . . . . . . . . . . Cusumano, 1991 . . . . . . . . . . . . . . . . . . . . . . . . .. 36 37. 3.3. 3.2.4 Martin Griss’ Model . . . . . . . . . . . . . . . . . . . . . . . 3.2.5 Software Productivity Consortium (SPC) Model . . . . . . . . Software Product Lines Maturity Levels . . . . . . . . . . . . . . . . .. 39 41 43. 3.4 3.5. Summary of the Study . . . . . . . . . . . . . . . . . . . . . . . . . . Summary of this Chapter . . . . . . . . . . . . . . . . . . . . . . . . .. 46 49. 4 RiSE Reference Model. 50. 4.1. RiSE-RM: The RiSE Reference Model . . . . . . . . . . . . . . . . . . 4.1.1 Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.1.2 Model Structure . . . . . . . . . . . . . . . . . . . . . . . . .. 52 52 53. 4.2. Overview of the RiSE Reference Model Levels . . . . . . . . . . . . .. 54. x.

(13) 4.2.1 4.3 4.4. 4.5. Processes specification . . . . . . . . . . . . . . . . . . . . . .. 57. Starting point for the RiSE-RM application . . . . . . . . . . . . . . . RiSE Reference Model Levels Definition . . . . . . . . . . . . . . . . 4.4.1 Level G - Informal Reuse . . . . . . . . . . . . . . . . . . . . .. 60 62 63. 4.4.2 4.4.3. Level F - Basic Reuse . . . . . . . . . . . . . . . . . . . . . . Level E - Planned Reuse . . . . . . . . . . . . . . . . . . . . .. 63 65. 4.4.4 4.4.5 4.4.6. Level D - Managed Reuse . . . . . . . . . . . . . . . . . . . . Level C - Family-Oriented Reuse . . . . . . . . . . . . . . . . Level B - Reuse . . . . . . . . . . . . . . . . . . . . . . . . . .. 67 68 71. 4.4.7 Level A - Pro-Active Reuse . . . . . . . . . . . . . . . . . . . Summary of this Chapter . . . . . . . . . . . . . . . . . . . . . . . . .. 72 73. 5 RiSE-RM Survey Based on Expert Opinion. 75. 5.1 5.2 5.3. Expert Opinion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . The number of experts . . . . . . . . . . . . . . . . . . . . . . . . . . Expert selection in this study . . . . . . . . . . . . . . . . . . . . . . .. 76 77 78. 5.4 5.5. Expert bias and calibration in this study . . . . . . . . . . . . . . . . . Experts opinion aggregation in this study . . . . . . . . . . . . . . . .. 79 79. 5.6. Research approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.6.1 The survey . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.6.2 The questions . . . . . . . . . . . . . . . . . . . . . . . . . . .. 80 80 81. 5.6.3 5.6.4. Data collection and analysis . . . . . . . . . . . . . . . . . . . Collected data . . . . . . . . . . . . . . . . . . . . . . . . . . .. 81 81. The survey results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.7.1 Role in Reuse Projects . . . . . . . . . . . . . . . . . . . . . . 5.7.2 RiSE-RM organization . . . . . . . . . . . . . . . . . . . . . .. 82 82 83. 5.7.3 5.7.4. RiSE-RM Specification . . . . . . . . . . . . . . . . . . . . . . A natural path from informal reuse to systematic reuse . . . . .. 84 85. 5.7.5 5.7.6 5.7.7. Level G . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Level F . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Level E . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 86 86 89. 5.7.8 Level D . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.7.9 Level C . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.7.10 Level B . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 92 94 97. 5.7. 5.7.11 Level A . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 5.7.12 Gaps in the evolution through the maturity levels . . . . . . . . 102. xi.

(14) 5.7.13 The most difficult level transition . . . . . . . . . . . . . . . . 103 5.8. 5.7.14 Benefits of reuse in the earlier levels . . . . . . . . . . . . . . . 104 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 5.8.1 Summary of the findings . . . . . . . . . . . . . . . . . . . . . 105 Organization and Specification . . . . . . . . . . . . . . . . . . 106 Level G . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108 Level F . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108 Level E . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108 Level D . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108 Level C . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108 Level B and A . . . . . . . . . . . . . . . . . . . . . . . . . . 109. 5.9. 5.8.2 Possible threats to validity . . . . . . . . . . . . . . . . . . . . 109 Summary of this Chapter . . . . . . . . . . . . . . . . . . . . . . . . . 110. 6 RiSE-RM Case Study in Companies 111 6.1 Case Study Context . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112 6.2 6.3. Minimize the Effect of Confounding Factors . . . . . . . . . . . . . . . 115 Planning the Case Study . . . . . . . . . . . . . . . . . . . . . . . . . 116 6.3.1 6.3.2 6.3.3. 6.4 6.5. 6.3.4 RiSE-RM Assessment Spreadsheet . . . . . . . . . . . . . . . 117 Brazilian Software Companies . . . . . . . . . . . . . . . . . . . . . . 118 The Analysis and Results Reported . . . . . . . . . . . . . . . . . . . . 118 6.5.1 Question 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119 6.5.2 Question 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124 6.5.3 6.5.4. 6.6 6.7. Context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116 Measures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116 Data Collection Procedures . . . . . . . . . . . . . . . . . . . . 116. Question 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129 Question 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134 Summary of this Chapter . . . . . . . . . . . . . . . . . . . . . . . . . 136. 7 Summary and Outlook 137 7.1 Research Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . 139 7.2 7.3 7.4. Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140 Lessons Learned . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141 Limitations and Future Works . . . . . . . . . . . . . . . . . . . . . . 142. xii.

(15) 7.5. Concluding Remarks . . . . . . . . . . . . . . . . . . . . . . . . . . . 143. Bibliography. 145. Appendices. 159. RiSE Reference Model (RiSE-RM) - Levels Definition. 160. xiii.

(16) List of Figures. 1.1. Approaches to Software Reuse . . . . . . . . . . . . . . . . . . . . . .. 5. 1.2 1.3. RiSE Labs Influences . . . . . . . . . . . . . . . . . . . . . . . . . . . RiSE Labs Current Projects and Directions . . . . . . . . . . . . . . . .. 8 9. 2.1. Reuse adoption programs timeline . . . . . . . . . . . . . . . . . . . .. 23. 2.2. Relation among the reuse adoption programs the main requirements . .. 24. 3.1. Structure of IEEE Std 1517-1999 . . . . . . . . . . . . . . . . . . . . .. 31. 3.2 3.3 3.4. Reuse Maturity Framework (Koltun and Hudson, 1991) . . . . . . . . . Bumps in the road to systematic reuse (Griss, 1995b) . . . . . . . . . . Reuse maturity models timeline . . . . . . . . . . . . . . . . . . . . .. 38 40 46. 3.5. Relation among the reports and the key factors . . . . . . . . . . . . . .. 48. 4.1. RiSE-RM overview . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 55. 4.2 4.3. Relation among RiSE-RM process areas and the key factors . . . . . . . RiSE-RM starting point . . . . . . . . . . . . . . . . . . . . . . . . . .. 56 61. 5.1. Role of the Experts . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 82. 5.2 5.3. RiSE-RM organization is suitable for evaluating reuse maturity . . . . . RiSE-RM specificationis suitable for evaluating reuse maturity . . . . .. 83 84. 5.4 5.5 5.6. RiSE-RM as a natural path from informal to a systematic reuse . . . . . Level F process areas . . . . . . . . . . . . . . . . . . . . . . . . . . . Considerations about Level F process areas . . . . . . . . . . . . . . .. 85 87 88. 5.7 5.8. Level F results and work products . . . . . . . . . . . . . . . . . . . . Level E process areas . . . . . . . . . . . . . . . . . . . . . . . . . . .. 88 89. 5.9 Considerations about Level E process areas . . . . . . . . . . . . . . . 5.10 Level E results and work products . . . . . . . . . . . . . . . . . . . . 5.11 Level D process areas . . . . . . . . . . . . . . . . . . . . . . . . . . .. 90 91 92. 5.12 Considerations about Level D process areas . . . . . . . . . . . . . . . 5.13 Level D results and work products . . . . . . . . . . . . . . . . . . . .. 93 94. 5.14 Level C process areas . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.15 Considerations about Level C process areas . . . . . . . . . . . . . . . 5.16 Level C results and work products . . . . . . . . . . . . . . . . . . . .. 95 95 97. 5.17 Level B process areas . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.18 Considerations about Level B process areas . . . . . . . . . . . . . . .. 98 98. xiv.

(17) 5.19 Level B results and work products . . . . . . . . . . . . . . . . . . . .. 99. 5.20 Level A process areas . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 5.21 Considerations about Level A process areas . . . . . . . . . . . . . . . 101 5.22 Level A results and work products . . . . . . . . . . . . . . . . . . . . 102 6.1 6.2. Measurement Framework . . . . . . . . . . . . . . . . . . . . . . . . . 113 Overall Results of Question 1 . . . . . . . . . . . . . . . . . . . . . . . 119. 6.3 6.4 6.5. Results of Question 1 for Company A . . . . . . . . . . . . . . . . . . 120 Results of Question 1 for UDCE-Dataprev . . . . . . . . . . . . . . . . 121 Results of Question 1 for Makesys . . . . . . . . . . . . . . . . . . . . 121. 6.6 6.7. Results of Question 1 for Meantime . . . . . . . . . . . . . . . . . . . 122 Overview of RiSE-RM process areas completeness . . . . . . . . . . . 124. 6.8 Overall Results of Question 2 . . . . . . . . . . . . . . . . . . . . . . . 125 6.9 Results of Question 2 for Company A . . . . . . . . . . . . . . . . . . 126 6.10 Results of Question 2 for UDCE-Dataprev . . . . . . . . . . . . . . . . 126 6.11 Results of Question 2 for Makesys . . . . . . . . . . . . . . . . . . . . 127 6.12 Results of Question 2 for Meantime . . . . . . . . . . . . . . . . . . . 128 6.13 Overall Results of Question 3 . . . . . . . . . . . . . . . . . . . . . . . 129 6.14 Results of Question 3 for Company A . . . . . . . . . . . . . . . . . . 130 6.15 Results of Question 3 for UDCE-Dataprev . . . . . . . . . . . . . . . . 130 6.16 Results of Question 3 for Makesys . . . . . . . . . . . . . . . . . . . . 131 6.17 Results of Question 3 for Meantime . . . . . . . . . . . . . . . . . . . 132 7.1. Aircraft Software Size Chronology . . . . . . . . . . . . . . . . . . . . 137. xv.

(18) List of Tables. 4.1. Six Levels of Process Capability (ISO/IEC, 2003a) . . . . . . . . . . .. 58. 5.1 5.2. List of experts that participate in the study . . . . . . . . . . . . . . . . 79 Overall results related to the Process Areas analysis . . . . . . . . . . . 106. 6.1. Case study summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 118. 6.2. Overall Results of the assessment . . . . . . . . . . . . . . . . . . . . . 134. 1. External dependencies of Level F . . . . . . . . . . . . . . . . . . . . . 160. 2 3 4. External dependencies of Level E . . . . . . . . . . . . . . . . . . . . 165 External dependencies of Level D . . . . . . . . . . . . . . . . . . . . 170 External dependencies of Level C . . . . . . . . . . . . . . . . . . . . 173. 5 6. External dependencies of Level B . . . . . . . . . . . . . . . . . . . . 180 External dependencies of Level A . . . . . . . . . . . . . . . . . . . . 182. xvi.

(19) Acronyms. ADMIRE. Asset Development Metrics-based Integrated Reuse Environment. API. Application Programming Interface. B.A.R.T. Basic Asset Retrieval Tool. BPR. Business Process Reengineering. BAST. Bug Report Analysis and Search Tool. BTT. Bug Report Tracker Tool. CAD. Computer-Aided Design. CARDS. Central Archive for Reusable Defense Software. CASE. Computer-Aided Software Engineering. CBA-IPI. CMM-Based Appraisal for Internal Process Improvement. CBD. Component-Based Development. CBSE. Component-Based Software Engineering. CEO. Chief Executive Officer. C.E.S.A.R. Recife Center For Advanced Studies and Systems C.E.S.A.R.. (http://www.cesar.org.br) is a CMMi level 3 company with around 700 employees CFRP. Conceptual Framework for Reuse Processes. CMM. Capability Maturity Model. CMMI. Capability Maturity Model Integration. CMMI-ACQ CMMI for Acquisition CMMI-DEV CMMI for Development CMMI-SVC CMMI for Services CORBA. Common Object Request Broker Architecture. 1.

(20) CORE. Component Repository. COTS. Commercial Off-The-Shelf. CPI. Continuous Process Improvement. DA. Domain Analysis. DE. Domain Engineering. DoD. US Department of Defense. DOE. US Department of Energy. DRU. Desenvolvimento para Reutilização. EIA. Energy Information Administration. ERP. Enterprise Resource Planning. FORM. Feature-Oriented Reuse Method. GO. Goals. GOTS. Government Off-The-Shelf. GQM. Goal Question Metric. GRU. Gerência de Reutilização. IDE. Integrated Development Environment. IEC. International Electrotechnical Commission. IEEE. Institute of Electrical and Electronics Engineers. IPD-CMM. Integrated Product Development Capability Maturity Model. IRM. Incremental Reuse Method. IRR. Internal Rate of Return. ISO. International Organization for Standardization. KP. Key Practices. 2.

(21) LIFT. Legacy InFormation retrieval Tool. MA-MPS. MPS.BR Assessment Model. MPS.BR. Melhoria de Processos do Software Brasileiro. MR-MPS. MPS.BR Reference Model. NDI. Non-Developmental Item. OID. Organizational Innovation & Deployment. OSD. Office of the Secretary of Defense. OSGi. Open Services Gateway initiative. PA. Process Areas. PLE. Product Line Engineering. PMI. Project Management Institute. RAIP. Reuse Adoption/Improvement Proposal. RAP. Resultados dos Atributos de Processo. RCM. Reuse Capability Model. RiSE. Reuse in Software Engineering. RiSE-AM. RiSE Assessment Method. RiSE-APF RiSE Adoption Process Framework RiSE-RM. RiSE Reference Model. RiSE-TCM RiSE Technology Change Management RiPLE. RiSE Process for Product Line Engineering. RMI. Remote Method Invocation. RMM. Reuse Maturity Model. ROI. Return-On-Investment. 3.

(22) RRM. Reuse Reference Model. RSRG. Reusable Software Research Group. RSM. Reuse Strategy Model. RUP. Rational Unified Process. SCAMPI. Standard CMMI Appraisal Method for Process Improvement. SC7. ISO committee responsible to develop ISO standards in the area of Software and Systems Engineering. SECM. System Engineering Capability Model. SEE. Software Engineering Environment. SEI. Software Engineering Institute. SOFTEX. Associação para Promoção da Excelência do Software Brasileiro. SOPLE. Service-Oriented Product Line Engineering. SPC. Software Productivity Consortium. SPI. Software Process Improvement. SPICE. Software Process Improvement and Capability Determination. SPL. Software Product Lines. SPMN. Software Program Manager Network. STARS. Software Technology for Adaptable, Reliable Systems. SW-CMM. Capability Maturity Model for Software. SWEBOK Software Engineering Body of Knowledge TCM. Technology Change Management. TI. Technology Insertion. ToolDAy. Tool for Domain Analysis. WISR. Workshop on Institutionalizing Software Reuse. WP. Work Products. 4.

(23) 1. The basic difference between an ordinary man and a warrior is that a warrior takes everything as a challenge, while an ordinary man takes everything as a blessing or a curse. Carlos Castaneda, American writer (1925-1998). Introduction. The Software Engineering Body of Knowledge (SWEBOK, 2007) describes software reuse as a key factor in maintaining and improving productivity and competitiveness in the acquisition and development of software. It goes on to say that effective software reuse requires a strategic vision that reflects the “unique power and requirements” of reuse techniques. The implementation of software reuse embodies more than just the creation and use of asset libraries. The successful implementation of reuse requires its techniques to be formalized by integrating reuse processes and activities into the overall software life cycle. By necessity, effective software acquisition and development strategies must consider the influence of reuse on overall project and organization risks and costs. There are a number of different approaches to software reuse, summarized in Figure 1.1, based on (Sommerville, 2006).. Figure 1.1 Approaches to Software Reuse. 5.

(24) 1.1. MOTIVATION. This thesis will goes into significant detail on how to perform reuse1 , highlighting the benefits, obstacles and challenges associated with it and mainly, an effective path towards systematic reuse.. 1.1 Motivation For many companies systematic, large-scale reuse of software artifacts seems to be an intuitively promising concept for meeting some critical needs such as, reducing cost, effort and time-to-market of software products. The development effort is reduced by building new application on the basis of pre-existing elements instead of developing everything from scratch. A reduction of effort is also a reduction of cost because software cost is normally dominated by staff salaries, and a reduction of effort may also shorten project duration and, thus, also reduces the time-to-market of the software product (Muthig, 2002). Implementing systematic reuse involves risk. Not doing it is also risky. Trying systematic reuse unsuccessfully can cost a company precious time and resources and may make management skeptical of trying it again. On the other hand, if your competitors do it successfully and you do not, it may mean the loss of market share and possibly the loss of an entire market (Frakes and Isoda, 1994). According to Muthig (2002), the possibility that reuse may help a company to meet its challenges holds especially for the software product line approach (Clements and Northrop, 2002; Pohl et al., 2005), which is a reuse approach that views a company software system as a line of variants within an application domain (Neighbors, 1980). In fact, the software product line approach is a way to achieve a systematic reuse performance, and to do this, its necessary a high capability level of a set of issues such as: knowledge, culture, infrastructure, development techniques, methods, processes and tools. In order to reach this higher capability level, that means systematic reuse, it is needed to implement a well-defined reuse program (or strategy). The ability to successfully implement a reuse program, which implies a careful, strategic balancing of reuse risks and costs, can result in the following qualitative benefits (Krueger, 1992; Frakes and Isoda, 1994; Lim, 1998): • Increased dependability through reused software that has been tried and tested in working systems; 1 In this case, perform reuse is related to how the company can adopt reuse through existent methods, processes, techniques and technologies, environments and tools. 6.

(25) 1.1. MOTIVATION. • Reduced process risks resulting from less uncertainty in the costs of reused software vs. new development software; • Reduced product risks by reusing proven components (performance, quality, reliability) and through development consistency; • Effective use of specialists who develop reusable software that captures their knowledge for all projects, not just specific projects; • Compliance to standards, e.g., user interface standards that can be implemented as a set of standard reusable components; • Accelerated development that allows systems/products to be brought to market as early as possible, leveraging reductions from decreased development and validation time through strategic reuse; and, • Economies of scale in product-line reuse become achievable through domain models, reusable components and common environments. The transition, however, from a traditional system-by-system development to a full product-line organization (systematic level of capability), as described by the popular product line methods (Bayer et al., 1999; Weiss and Lai, 1999; Kang et al., 2002) requires sometimes a drastic conceptual and intellectual shift. This shift requires significant up-front investments to change the company and to build up the reuse infrastructure. Moreover, only a few experience reports (Cusumano, 1991a; Bauer, 1993; Joos, 1994; Griss, 1995a; Andrews and Blechar, 2004) have been published about this shift and, thus, there is only little support for a company in systematically planning and implementing it (Muthig, 2002). Hence, the reuse adoption, not necessarily in a direct way to a product line approach, today is a big and risk endeavor that relies on the expertise and capabilities of individuals. The current situation regarding the transfer of reuse technology is the subject of Chapter 2. Despite these obstacles, which motivate many companies to follow other approaches that also promise to meet the reuse adoption challenges but that provide better means for a controlled and systematic adoption, some companies still attempt to go for systematic reuse (Muthig, 2002). These companies believe that the shift is indeed a crucial but necessary step in their current situation. From a researcher’s point of view however, such drastic and uncontrolled changes are not helpful because they do not provide data that allow their results to be systematically analyzed. Hence, they do not contribute to. 7.

(26) 1.2. CONTEXTUALIZING SOFTWARE REUSE IN THIS THESIS. the process of packaging and provide experiences on the transfer of systematic reuse technology and, thus, also do not help in planning future transfers. In this context, this thesis focuses on the shift, done incrementally, from a traditional system-by-system development approach to a reuse driven development according to levels of capability, composed by process areas, purposes, results and work products. Software reuse is analyzed to identify the essential concepts that must be transferred. Additionally, possibilities are explored for improving the probability of a systematic and successful transfer of software reuse technology into software development organization, as well as for systematically collecting experience and data on their application to support these transfers.. 1.2 Contextualizing Software Reuse in this Thesis This thesis is part of the RiSE (Reuse in Software Engineering) Labs2 (Almeida et al., 2004), formerly called RiSE Project, whose goal is to develop a robust framework for software reuse in order to enable the adoption of an effective reuse program. However, it is influenced by a series of areas, such as software measurement, architecture, quality, environments and tools, and so on, in order to achieve its goal. The influence areas are depicted in Figure 1.2.. Figure 1.2 RiSE Labs Influences 2. http://www.rise.com.br/research. 8.

(27) 1.2. CONTEXTUALIZING SOFTWARE REUSE IN THIS THESIS. Based on these areas, the RiSE Labs is divided in several projects, as shown in Figure 1.3. As it can be seen in the Figure, this framework embraces several different projects related to software reuse, such as:. Figure 1.3 RiSE Labs Current Projects and Directions. • RiSE Framework: Involves reuse processes (Almeida, 2007; Nascimento, 2008), component certification (Alvaro, 2005, 2009) and the reuse adoption process (Garcia et al., 2007, 2008a,b). • RiSE Tools: Research focused on software reuse tools, such as the CORE (Component Repository) (Burégio et al., 2008), ADMIRE Environment (Mascena, 2006), the Basic Asset Retrieval Tool (B.A.R.T) (Santos et al., 2006), which was enhanced with folksonomy mechanisms (Vanderlei et al., 2007) semantic layer (Durão, 2008), facets (Mendes, 2008) and data mining (Martins et al., 2008), the Tool for Domain ANalysis (ToolDAy) (Lisboa, 2008) and the Legacy InFormation retrieval Tool (LIFT) (Brito et al., 2008). • RiPLE: It involves the development of a methodology for Software Product Lines (Filho et al., 2008). • SOPLE: It involves the development of a methodology for Software Product Lines based on services. • MATRIX: Investigates the area of measurement in reuse and its impact on quality and productivity. • BTT: Research focused on tools for detection of duplicated change requests (Cavalcanti et al., 2008).. 9.

(28) 1.3. PROBLEM STATEMENT. • Exploratory Research: It investigates new research directions in software engineering and its impact on reuse. • CX-Ray: Focused on understanding C.E.S.A.R3 , its processes and practices in software development. The Process Framework for Software Reuse Adoption practices, proposed in this thesis, is one of the cornerstones of the RiSE Framework.. 1.3 Problem Statement Technology Insertion is the process of taking advantage of technology opportunities to improve the performance or reduce the cost of the system by replacing existing system components with newer technology components (DoD, 2002). The term “technology insertion” (TI) emerged in the 90s, partially in response to the emphasis on COTS (DoD, 2002) but nowadays it is used with varying focus in the literature. Thus the boundaries of its definitions are evolving and it has close ties and some overlap with all of the terms in the technology-related knowledge area. In some instances, some of these terms have been used interchangeably with TI, moreover could also include technology “adoption”, “transfer”, and “evolution”. In the context of software reuse, important research including company reports (Bauer, 1993; Endres, 1993; Griss, 1994; Joos, 1994; Griss, 1995a), informal research (Payton, 1993b,a; Frakes and Isoda, 1994; Frakes and Kang, 2005; Lucrédio et al., 2008) and empirical studies (Rine, 1997; Rine and Nada, 2000a,b; Morisio et al., 2002; Rothenberger et al., 2003) have highlighted the relevance of a process framework to aid in the reuse adoption, since several companies naively associate software reuse with the adoption of certain technologies, such as the object-oriented programming. The software reuse literature focuses on two directions towards a systematic reuse: Domain Engineering and Software Product Lines. Although the software reuse community does not present a well-defined, standardized and known software reuse adoption process to guide the companies to achieve this systematic reuse level, this thesis focuses on a software reuse adoption process framework. Existing reuse adoption processes (Griss, 1994; Joos, 1994; Frakes and Isoda, 1994; Rine, 1997; Frakes and Kang, 2005; Lucrédio et al., 2008) present crucial problems, such as not being independent of such technologies and start with a high investment; 3 Recife. Center for Advanced Studies and Systems, http://www.cesar.org.br. 10.

(29) 1.4. OUT OF SCOPE. besides, they do not define clearly activities, tasks, assessment rules, constraints, roles, inputs, outputs of each step incrementally towards a systematic reuse performance. The problem increase when we consider Brazilian companies, with serious limitations related to investment capability, market environment, competitors and the high costs involved in a systematic reuse program adoption. Thus, the goal of the work described in this thesis can be stated as: This work defines and refines a reference model to aid in performing software reuse adoption, based on a set of maturity levels, capabilities, process areas, purposes, results and work products, mainly to micro, small and medium size companies in order to meet their business needs. Moreover, the reference model is based on the state of the art in the area and its foundations and elements are discussed in details.. 1.4 Out of Scope Once the proposed reuse adoption process framework is part of a broader context, a set of related aspects will be left out of its scope. Nevertheless, as these aspects were envisioned since the initial definitions of the framework, they can be added in future with some adjustments. Thus, the following issues are not directly addressed by this work: ⊲ Reuse Assessment Method. We also believe that consistent and good evaluation results can only be achieved by following a high quality and consistent evaluation process (ISO/IEC, 2003a). A reuse assessment allows a company to understand its current status (related to reuse practices), the benefits and costs of reuse, its alignment and influence upon business strategy and, in the case of large companies, identify company units with high reuse potential (Lim, 1998); ⊲ Reuse Technology Improvement Management. A Technology Improvement Management is the process of developing a planned approach to the replacement of a legacy technology by a new one in a company (SEI/CMU, 2008). The structured approach comprises the procedures and management activities for planning and monitoring the transition from one organizational structure, or business process, to another when a new technology is introduced, and it is used for efficient and prompt handling of all changes; ⊲ Metrics. Measurement activities are essential in any process. The software reuse metrics field is a wide road that encompasses aspects related to benefits in productivity, quality, reusability and return on investment obtained with a reuse adoption program effort, for example (Almeida, 2007). However, even with some metrics being used in. 11.

(30) 1.4. OUT OF SCOPE. development process, in a way of measuring some attributes of developing software with reusable assets, there are more specific reuse metrics (Poulin, 1996) that could be incorporated into the reference model use; ⊲ Reuse environment and tools. Reuse tools are broadly defined as those instruments which facilitate the reuse of products or by products during the software life cycle, including reuse libraries, application templates and generators which, in turn may be categorized into compositional or generative reuse techniques. However, this aspect can be as complex as reuse adoption, involving the definition of architectures, infrastructure, patterns and a lot of technologies decisions; ⊲ Reuse process (Software Product-Lines Process). Reuse oriented processes represent those systematic procedures that are to be implemented in producing, brokering and consuming reusable assets and software. However, this aspect can be as complex as reuse adoption, involving the definition of activities, sub-activities, inputs, outputs, and roles and is the scope of several work (Neighbors, 1980; Weiss and Lai, 1999; Muthig, 2002; Almeida, 2007); ⊲ Process Adaptation. Each company has its own software development process and it is known that a well-defined process can bring substantial benefits. Thus, in order to decrease the impacts and risks of a reuse adoption through a process changes or adaptations, it is important to define how to do the tailoring for an existing process toward a new one with some reuse practices and other improvements. Morisio et al. (2002) show that this adaptation is a critical point in a reuse project, however this issue is not considered in reuse processes, which can present barriers to companies interested in adopting it; ⊲ Reengineering and Reverse Engineering Process. A difficult and often necessary issue for a company is to reengineer systems to be reused, since most companies develop or have developed similar systems in the same domain without any presence of future reuse concern (Almeida, 2007). However, due to its complexity, this can be seen as a sub-area or discipline of software engineering, and there are no efforts to integrate reengineering aspects in software reuse processes, even it being important. Krueger (1992) has presented some directions in this area, but not connected to a reuse process; ⊲ Quality and Certification of Reusable Assets and Process. Quality is important because since the end of 1980s (Bauer, 1993), companies develop and manage repository systems with reusable artifacts. Thus, if a developer reuses an asset with defects, this may be a future inhibitor for reuse. Additionally, to produce reusable assets, quality is one of the main concerns in order to improve the return on investment through the cost. 12.

(31) 1.5. STATEMENT OF THE CONTRIBUTIONS. and effort development reduction. However, the available reuse processes do not discuss, for example, ways to test, inspect and certify the produced assets (Alvaro et al., 2007; Alvaro, 2009); and, ⊲ Economics and Legal Issues. Business aspects are an important instrument to aid managers to start a reuse adoption program. Economics and Legal Issues addresses the production, brokering and consumption of reuse goods and services, where cost/benefit analysis determines the economic worthiness of pursuing a reuse program or creating a reusable asset finance related to the funding of a reuse program (Lim, 1998); and accounting deals with tracking/controlling a reuse program (Nazareth and Rothenberger, 2004). Nevertheless, it is not a trivial issue. This can be verified, for example, by the fact that no reuse adoption process has a way of addressing it.. 1.5 Statement of the Contributions As a result of the work presented in this thesis, the following contributions can be enumerated: ⋄ A survey on Reuse Adoption Programs and Strategies in an attempt to analyze this research area and identify trends to follow; ⋄ An extensive survey on Reuse Maturity Models in order to understand and identify the weak and strong points of existing maturity models; ⋄ The formalization and definition of the reuse reference model (Garcia et al., 2007) in this thesis; ⋄ The definition, planning, operation, analysis, interpretation, and packaging of a survey with experts and a case study which evaluates the viability of the proposed reference model.. 1.6 Outline In this introduction, the reuse adoption problem has been presented, mentioning some success cases, industrial reports and the main problems related to this approach. After presenting this subject in general, the main obstacles and motivation for real-world software reuse adoption were introduced. The Chapter 2 discusses the main approaches for transferring reuse technology in software development companies. From this discussion, requirements for a software reuse adoption approach that may improve this situation are derived.. 13.

(32) 1.6. OUTLINE. Chapter 3 discusses the main approaches and proposes to an effective reuse maturity model to aid in the reuse assessment and adoption. Chapter 4 describes the reference model that captures the main reuse concepts and practices regarding to successfully implementing a reuse program in a software development company. Chapter 5 validates the reuse reference model against some experts in the reuse community through a questionnaire with questions related to the organization and specification of the model, its levels, process area, results and work products. Chapter 6 describes a case study conducted in private and public Brazilian companies to evaluate the reuse reference model. Chapter 7 summarizes the main contributions of this work, identifies open issues and questions, and discussing possible future work and research areas. Finally, the Appendix describes in detail the RiSE Reference Model.. 14.

(33) Simple things should be simple, complex things should be possible. Alan Curtis Kay, Computer scientist (1940). 2. Reuse Adoption Programs Survey. In order to identify plausive answers and insights for the questions in Chapter 1, this Chapter presents a survey about the main research on software reuse adoption programs (or strategies, processes, approaches, etc.), trying to establish a relationship between them, and presents a set of requirements that should be dealt with in an effective software reuse adoption program, that can be used by companies as a guide to some technological and non technological transitions towards obtaining the benefits of reuse-based software development. Some of these programs were designed for specific types of companies and may not be effective in all situations. Thus, particular reuse adoption programs need to be specified taking in account the environment, features and issues for each company. In addition, existing literature is not rich in reports related to practical software reuse adoption experience, but some relevant research work explore the theory of software reuse adoption programs in academic scenarios. In this sense, this Chapter presents a survey of software reuse adoption programs, from the middle 80’s until today.. 2.1 The Beginning of the Reuse Adoption Programs A large number of strategies, models and programs have been proposed to face the reuse adoption problem. In this section we present a survey on these approaches, with the objective of defining a common set of requirements that should be considered in an effective approach. Doe and Bersoff (1986) presented an industry initiative to increase software productivity and quality. In 1983 the executive committee of a group formed by the main aerospace companies began the studies to determine the viability to form a consortium to deal with the relative problems at the software costs, since the problems related to. 15.

(34) 2.1. THE BEGINNING OF THE REUSE ADOPTION PROGRAMS. the software production were (and still are today) huge and continued growing. In August 1984 seven companies signed the understanding memo and created the Software Productivity Consortium (SPC) (Pyster and Barnes, 1988). Starting from Doe and Bersoff (1986) work, it is possible to identify a clear concern with the creation of an environment, composed by techniques and tools to aid in the productivity and quality increase, obtained through software reuse. Another interesting data in this work is the concern of the SPC with the technology transfer developed by the consortium, for, and with, the companies that are part of the conglomerate as well as the transfer of technological products to the members of the companies. Thus, a special area, called Software System Engineering Area, was created. In this context, the consortium called for a special attention for complementary programs, in terms of transfer of technologies related to reuse, i.e., Software Technology for Adaptable, Reliable Systems (STARS)1 , Software Engineering Environment (SEE) (one of the six areas of larger impact of STARS is the Software Engineering Environment) and the Software Engineering Institute (SEI). According to Pyster and Barnes (Pyster and Barnes, 1988) and SPC, to systematically provide support to reuse in its development process, a company should have: (i) tools that work together with the repository system in order to manage and access the reusable assets; (ii) a relevant set (library) of reusable assets of the business domain target (or area) of the company; and, (iii) a methodology that guides the reutilization process indicating “when” and “how” to reuse the assets to compose new assets or to update old assets. SPC assisted these three requirements through three projects (STARS, SEE and SEI), plus one more project of Metrics Evaluation, seeking to evaluate the reuse viability, the cost of establishing a reusable assets repository, the cost of reusing an asset, the cost in the development process, among other metrics. SPC started with a great structure and covered the main problems related to a reuse adoption program. The problem related to Pyster and Barnes work is the strong technology dependence and the high investment cost to start the project. Besides, it is not clear why this project stopped or did not generated a standardized process, composed by tools, library of reusable assets, a methodology to guide reuse and a evaluation process. Holibaugh et al. (1989) outlined a life cycle for the adoption of reuse. The life cycle consists of seven steps, beginning with business planning. At this level, company’s goals and current business processes are examined and evaluated within the context 1 Sponsored. by the US Department of Defense (DoD), this program was aimed at stimulating software technology research and development to improve development productivity for mission-critical systems. 16.

(35) 2.1. THE BEGINNING OF THE REUSE ADOPTION PROGRAMS. of reuse. Include opportunities and plans for business in the domain; stability of the domain-specific technology; availability of domain expertise within the company; depth of experience in the domain; availability of resources to commit to reuse; and the expected benefit of reuse. The second step is called life cycle and methodology. Its goal is to develop a reuse methodology to identify, develop, and apply reusable resources. Activities in this step include using a domain model and software architecture as a roadmap through the life cycle; identifying reusable resources early; including reuse in each phase of the life cycle; looking ahead for reusable components in later phases to ensure that they are used; including reuse in planned reviews to ensure reusable assets are used; and monitoring through code reviews. The third step is domain analysis. In this step, activities include defining the domain; identifying and collecting information and resources; selecting a representation mechanism; organizing, representing, and analyzing the information; and reviewing and validating the results. The fourth step, domain engineering, is concerned with producing the reusable assets which include designs, components, and tools. In the fifth step, library construction, a library is constructed with the goal of making the assets easily accessible to the consumers. This includes selecting the classification scheme and representation structure. The sixth step, systems construction, involves the identification of reuse goals for any system to be created with reusable assets. Metrics are also collected to measure the achievement of these goals as well as to compare the use of reusable assets against development without reusable assets. The seventh and final step involves feedback results to the previous steps. This is done through the collection and analysis of data from each life cycle phase. Such analysis identifies the impact of reuse on factors such as quality, personnel, and schedules. The main problem in the Holibaugh et al. (1989) work, is the fact that it is mandatory to the company the migration to a systematic reuse level and this maynot be the best solution. Some companies, because of the specific issues of their environment, structure and business domain, do not need to go towards a systematic reuse level. It must be possible to go to a better level of reuse capability, but not necessarily the highest one. An important work was developed by Apte et al. (1990), who present their experience in the design and implementation of a strategy for a bank information system, based on reuse concepts. According to Apte et al., the experience with the implemen-. 17.

(36) 2.1. THE BEGINNING OF THE REUSE ADOPTION PROGRAMS. tation confirmed that applying the reuse concepts in all software development life cycle stages results in strategic and operational benefits. The strategic benefits are: increase in the engineers’ productivity and considerable improvement in time-to-market. The operational benefits include the reduction and control of the costs in the systems development and maintenance. In terms of investment in the reuse strategy, the bank invested about $1 million in five years. On the other hand, the benefits reached in this same period, in costs avoided, were approximately $2 millions, with an annual saving of $1.5 million only in 1989. Through Apte et al.’s work, some inhibitors for the reuse adoption were identified, where the main factors were the lack of an effective strategy of reuse (Biggerstaff and Richter, 1987) and the lack of support of the companies management, that can influence in the project managers and engineers’ resistance (Tracz, 1987). In agreement with Apte et al. (1990), the largest challenge is not technical but administrative. To persuade the managers and engineers to “buy” the reuse idea involves implementing a change in the traditional practices of work. That change should not be automatic and it is more probable to fail for a lack of company management commitment or for the lack of the engineers’ interest than for technical reasons. One of the main success factors pointed by Apte et al. was the construction of a consistent software development environment to store and maintain all of the reusable assets. Starting from his experience and the best features of four success cases, PrietoDíaz defined an incremental model for the implementation of software reuse programs (Prieto-Díaz, 1991). The approach was practical, effective and with potential to turn reuse into a regular practice in the software development process. Prieto-Díaz also pointed out the support of the high administrative management as one of the main factors for the success in reuse programs, because those programs demanded changes in the way software is developed. One of the most interesting features in Prieto-Díaz’s model is the definition of an essential organizational structure for the success of the program, containing teams for: assets management; assets identification and qualification; assets maintenance; development; support to the reuse program through consultancy and training; and classification of the assets in the repository system. This list defines the basic roles in the reuse program. Buxton and Malcolm (1991) provide a generic high-level model not specifically for reuse but relating primarily to the transfer of software process technology. They noted that in software development, a company faces “two innovation issues at the same time:. 18.

(37) 2.1. THE BEGINNING OF THE REUSE ADOPTION PROGRAMS. the introduction of software technology into well established products and the potential introduction of software engineering techniques”. This observation clearly applies to software reuse. The Buxton and Malcom’s view of the phases that take place within a company involved in technology transfer include: (1) awareness; (2) assessment and choice; (3) adoption for real use; and, (4) assimilation into a new organizational orthodoxy. In the awareness phase, they point out that awareness of new technology may begin with management or a new technologist who assumes the role of a “gatekeeper” person who stays in touch with new developments and plays a key part in the identification of promising technologies. In the assessment and choice phase, the gatekeeper chooses the plausible new technology and advances with a “demonstrator” (pilot) project. If the pilot project is successful, the adoption for real use phase is pursued. This phase, which is the “first real application of the new technology” will meet the greatest resistance from personnel. Top management must take a proactive role and provide the necessary resources. Training for all personnel is crucial for this phase. The final phase occurs only after the technology has been used successfully. Education gradually takes place as an apprenticeship within the normal working environment. Buxton and Malcom believe that in order to a technology to be transferred successfully, it must be visible and its value to the company must be quantified. The problem in Buxton and Malcom work is the lack of information in the activities, tasks, roles, inputs and outputs descriptions. Some transitions among the steps are not clear as well as some roles and their respective responsibilities in the process. Caldiera (1991) describes a four-step process for use in a domain factory for implementing reuse: plan, execute, analyze and formalize. These steps are described as follow: 1. Plan: (i) Characterize the domain and the environment; (ii) Set the goals and refine them into a measurable form; (iii) Choose the execution process model, the product models, the application engineering environment, and the associated control measurement. 2. Execute: (i) Supply the domain specific units to the project organization and perform or support their adaptation; (ii) Control the process while executing, using the chosen measurement (the process during its execution is controlled by both the project organization and the domain factory); (iii) Provide immediate feedback on the process to the project organization.. 19.

(38) 2.2. THE SECOND AGE OF THE REUSE ADOPTION PROGRAMS. 3. Analyze the results and compare them to the goals defined in the planning phase. 4. Formalize: (i) Synthesize the results into new process and product models, quality models, measurements, etc., or updates of the existing ones; (ii) Package processes products and experience into domain-specific units.. 2.2 The Second Age of the Reuse Adoption Programs After the first age of work intended to specify an effective way to adopt reuse, the second age starts with more mature strategies, well-defined and evolved from the first work. In November 1992, the Workshop on Institutionalizing Software Reuse (WISR) was helded and Creps presented the STARS Conceptual Framework for Reuse Processes (CFRP) (Creps, 1992). CFRP was developed by the STARS project (Davis, 1991; Payton, 1993b,a) aiming to define a context taking into account software development processes related with reuse, their inter-relationships, compositions and integrations among themselves and among processes not related with reuse, to form reuse-oriented life cycle process models. The main elements of CFRP are two processes: (i) Reuse Management, focused on planning processes, managing and learning about reuse inside the company; and (ii) Reuse Engineering, focused on the processes involved in creating, maintaining and using reusable assets. CFRP defines how those languages and their constructions, family and categories of processes are linked together, and provides a series of rules to compose those elements, facilitating the plan and the process of reuse adoption in a company. The lack of guides to evaluate the current company situation and to aid in planning the target situation and practices to be implemented is the main problem in CFRP. Besides, the lack of information, mainly in the roles and responsibilities for the steps transition in the framework make it difficult its application. Bongard et al. (1993) describe a four step strategy for introducing software reuse. The first step, called “Feasibility study for reuse introduction”, is responsible to: (i) study current software practice; (ii) identify and estimate the reuse potential; (iii) evaluate return on investment; and, (iv) propose an implementation plan. The second step, “Preparation for reuse introduction”, is responsible to: (i) select or adapt methods and tools; (ii) modify organizational structures for reuse; and, (iii) get personnel involved. The third step, “Introduction of reuse to the company”, is responsible to: (i) define generic architectures; (ii) select and build reusable components; (iii) instruct and. 20.

(39) 2.2. THE SECOND AGE OF THE REUSE ADOPTION PROGRAMS. motivate personnel; and, (iv) assist developers. The fourth and last step, Tracking of the reuse introduction process, is responsible to: (i) measure benefits; (ii) evaluate reuse behavior; and, (iii) correct and improve reuse behavior. In Bongard et al. (1993) work, some issues are not clear, such as how to estimate the reuse potential and evaluate the return on investment. The proposition of an implementation plan also requires more detailed information. The steps need more detailed information to guide its application. In spite of the great amount and variety of methods that detail the systematic software reuse process, as presented in this section, very few companies can materialize the promises made by the technology and their advocates. Sherif et al. (2006) presented an economical view for the systematic software reuse implementation in the companies and described that the success of systematic reuse will depend on the change of resources between the developers and users of reusable software. Organizational incentives to promote the development and the use of software reusable assets may or may not be needed, depending on the perceptions of developers regarding the availability of resources. Sherif et al. developed a model for the systematic software reuse and tested it using collected data of four different reuse programs in three multinational companies. Sherif et al. (2006) economic model allows studying the organizational dynamics behind the systematic software reuse in the companies. The analysis of the model reveals that allocation of resources to build a reuse infrastructure is important to motivate developers to exert the required additional efforts. Contrary to what has been proposed in the reuse literature, the work suggests that huge investments are not always necessary for the success of reuse. By prioritizing and allocating resources to those areas, which have been identified as critical reuse success factors, a company will not only make a difficult reuse scheme feasible but also improve the outcome of reuse adoption that will be acceptable to all divisions. Thus, an economic view to resource allocation can significantly and positively affect the plans of a reuse program in a company. The contributions of this study are multifold. In the literature area, no other study has applied exchange economics to explain how insufficient resources allocated to the systematic software reuse program can lead to the collapse of the program. Sherif et al. proposed a useful perspective, strongly grounded in literature and theory, on how the problems inhibiting systematic software reuse implementation are indeed a function of resource allocation decisions and resource management initiatives.. 21.

(40) 2.3. SUMMARY OF THE STUDY. The applicability of the proposed model was tested in companies that are prominent advocates of systematic software reuse. Besides, the study was not just restricted to studying companies where systematic software reuse has been successful, in this work Sherif et al. included one case where systematic software reuse adoption failed to obtain insights regarding the applicability of the proposed conceptual model. Llorens et al. (2006) proposed an incremental approach, with low costs, to reuse adoption based on artifacts retrieval by content called Incremental Reuse Method (IRM), founded on incremental adoption to allow costs reduction, which can solve severe obstacles to introducing software reuse, allowing their application in several companies. IRM minimizes these obstacles in order to offer an attractive set of conditions for a company “jump into” reuse, such as: (i) it must be possible to introduce reuse based on the argument that investment should be minimal, almost zero; (ii) the reuse introduction must not impact the internal software development process; (iii) reuse introduction does not have to imply heavy training; (iv) it must be possible to introduce reuse incrementally, the artifacts from the finished projects become the reusable artifacts for the new ones; (v) the software reuse process must be robust against business dynamics (domain changes); (vi) return on investment does not have to be the most important decision factor, the companies should be able to consider other criteria such as well quality improvement issues, time to market, among others. The reuse community agrees (Rine, 1997; Morisio et al., 2002; Lucrédio et al., 2008) that characterizing reuse with adoption processes is a clear sign of progress towards making reuse a natural part of development. As showed in this survey, we have some experiences and projects about reuse adoption strategies and programs. However, the companies are still afraid of adopting a reuse program because there is not a strategy widely accepted, the need of high initial investment, the high risks and there are uncertainty in return on investment. Thus, through this survey we identified the main requirements, or features, of some reuse adoption models or programs to specify an effective reuse program adoption, that will be presented in the next section.. 2.3 Summary of the Study Figure 2.1 summarizes the timeline of research on the software reuse adoption programs area, where the dotted line marks the main change in this research area, from 1986 to 2007. Besides, the main works are marked by an “X”. We divide the research area in two ages. The first age, Beginning of the Reuse Adop-. 22.