UM ESTUDO SOBRE MÉTRICAS PARA ACOMPANHAMENTO DE PROCESSOS DE REUSO DE SOFTWARE

Prévia do material em texto

UM ESTUDO SOBRE MÉTRICAS PARA 
ACOMPANHAMENTO DE PROCESSOS 
DE REUSO DE SOFTWARE 
 
 
 
 
 
 
 
 
Tiago Morais Ferreira 
 
 
 
 
 
 
 
 
 
[ 2 ] 
 
[ 3 ] 
Prefácio ........................................................................................................................................................................... 5 
1. Introdução ........................................................................................................................................................... 6 
2. Reuso de software ........................................................................................................................................... 7 
2.1. Benefícios do reuso .................................................................................................................................... 7 
2.2. Desafios na implementação de reuso sistêmico ........................................................................ 8 
2.3. Fatores críticos de sucesso .................................................................................................................... 9 
3. Processos e o reuso ........................................................................................................................................ 9 
3.1. MPS.BR e a melhoria da qualidade de software ....................................................................... 10 
3.2. Processo de reuso ..................................................................................................................................... 10 
4. Métricas e indicadores para reuso de software ............................................................................ 11 
4.1. Métricas orientadas à economia e custo/benefício ................................................................ 12 
4.2. Métricas orientadas à estrutura ........................................................................................................ 14 
4.3. Métricas de repositório .......................................................................................................................... 15 
5. FRRT – Fórmula real de reuso t .............................................................................................................. 15 
5.1. Interpretações e limitações ................................................................................................................. 18 
5.2. Validação da métrica ............................................................................................................................... 18 
6. Proposta de melhoria no processo de reuso de software ........................................................ 21 
7. Considerações finais ..................................................................................................................................... 22 
Referências ................................................................................................................................................................. 23 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Dedico este livro a Zeilane P. Guedes, sem seu apoio, a publicação deste livro não seria 
possível. 
 
 
 
Um estudo sobre métricas para acompanhamento de processos de reuso de software, por Tiago de Morais Ferreira 
 
 
[ 5 ] 
Prefácio 
 
 
O reuso de software vem para aperfeiçoar a produção de sistemas como um todo, visto 
que o mercado atual exige o desenvolvimento de projetos de qualidade no menor tempo 
possível, o que é inexequível sem o aproveitamento de peças desenvolvidas anteriormente. 
Apesar de atraente, a reutilização de ativos pode ser desastrosa se realizada sem 
observação aos preceitos descritos na bibliografia, trazendo mais problemas que soluções. 
 
Este livro aborda os conceitos básicos para iniciação de um processo de reuso e como este 
pode ser elaborado de modo a maximizar as chances de sucesso. Apresenta também um 
estudo sobre as métricas disponíveis e a proposta de uma nova métrica, Formula Real de 
Reuso T. Para validação, foi elaborado um estudo de aplicação da métrica em um cenário 
real, que demonstra sua eficiência através da comparação com um modelo de maturidade 
de processo de software. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Um estudo sobre métricas para acompanhamento de processos de reuso de software, por Tiago de Morais Ferreira 
 
 
[ 6 ] 
1. Introdução 
 
 
Empresas de desenvolvimento de software atravessam períodos de alta competitividade de 
mercado, com clientes cada vez mais exigentes e atentos a prazos, à qualidade dos 
produtos de software e aos custos envolvidos na aquisição de um sistema. Um fator 
relevante para o setor é aumentar sua capacidade de entregar software de qualidade, e os 
processos que levam ao desenvolvimento de softwares são pontos chave para obtenção do 
sucesso. 
 
No comércio, Time To Market (TTM) é o tempo entre o início da concepção de um produto 
até sua disponibilização ao mercado. O TTM é importante para as indústrias em que 
o produto se torna obsoleto rapidamente, ou existe a possibilidade de a concorrência 
oferecer um produto similar em determinado momento. 
 
Segundo Krueger (1992), uma das abordagens de desenvolvimento de software visando à 
redução do time to market, ao aumento da qualidade dos sistemas elaborados e à redução 
dos custos é o desenvolvimento voltado ao reuso de software. O reuso amplia a qualidade 
dos sistemas e aumenta a eficiência da empresa na obtenção de resultados. 
 
Desde o início do conceito de reuso de software em 1968 até os dias atuais, o que se vê é 
uma reutilização não padronizada. São aproveitados ativos de projetos anteriores de modo 
ad hoc, sem que sejam respeitadas etapas de identificação, análise ou gerenciamento dos 
ativos ou do processo de desenvolvimento, causando acréscimos dos custos produção e a 
perda da competitividade da organização, como descrito por Almeida (2007). 
 
Atualmente pesquisas são realizadas em todo o globo. Uma das mais promissoras 
iniciativas é a Component Industry Promotion (CIP), realizada pelo governo coreano. Visa 
fomentar a inclusão do reuso de software no ciclo de vida dos sistemas computacionais, 
criando padrões relevantes e desenvolvimento de bibliotecas de componentes. O 
conhecimento é distribuído entre mais de cem empresas parceiras. 
 
Arquitetura, Processos e Plataformas para Famílias de Software (ESAPS), projeto europeu 
que tem por objetivo melhorar a abordagem de famílias de software através da parceria 
entre a indústria e as universidades. De modo colaborativo, empresas do conglomerado 
oferecem seu know-how buscando fomentar o avanço do reuso de software para o 
compartilhamento dos benefícios entre as instituições parceiras. 
 
Este trabalho tem o intuito de explanar sobre as métricas existentes na bibliografia para o 
controle do processo de reuso de software, além de propor uma métrica para 
acompanhamento da porcentagem de reutilização empregada nos projetos de uma 
organização em determinado período, dando subsídios para que o processo possa ser 
medido e controlado. O conteúdo foi elaborado através de pesquisa bibliográfica e 
documental. Nos procedimentos de coleta de dados, buscou informações através da 
aplicação de questionários e estudo dos projetos realizados pela empresa analisada. 
Um estudo sobre métricas para acompanhamento de processos de reuso de software, por Tiago de Morais Ferreira 
 
 
[ 7 ] 
2. Reuso de software 
 
 
O conceito de reuso de software data de 1968, quando McIlroy (1968) divulgou à 
sociedade de desenvolvedores um artigo intitulado Mass Produced Software Components 
ou Produção de Componentes de Software em Massa, que defendia a ideia de reuso de 
software tal qual a reutilização de componentes eletrônicos, que uma vez criados, possuem 
aplicabilidade em diversos circuitos. 
 
Basili e Rombach (1991) definem reutilização de software como o uso de tudo associado a 
um projetode desenvolvimento, incluindo o conhecimento. Para Frakes e Isoda (1994), 
reutilização de software é definida como o uso do conhecimento de engenharia ou de 
artefatos a partir de sistemas existentes para construção de novos. 
 
Ezran (2002) considera que a reutilização de software é a prática sistemática de 
desenvolvimento a partir de um estoque de blocos de construção; as semelhanças em 
requisitos e ou arquitetura entre as aplicações podem ser exploradas para alcançar 
benefícios substanciais de produtividade, qualidade e desempenho dos negócios. 
 
Desde a publicação de McIlroy (1968), é crescente a complexidade dos sistemas, a 
necessidade por ofertar produtos de maior qualidade, com custos reduzidos e num menor 
período tempo. Na década de 70, estes objetivos não eram atingidos pela falta de 
processos bem definidos e escassa informação sobre a engenharia de software, culminando 
na crise do software, assim chamada pelos pesquisadores da época pela quantidade de 
atrasos na entrega dos projetos, alta complexidade de manutenção dos sistemas e baixa 
produtividade. Desde então, o reuso passou a ser considerado um dos maiores objetivos da 
engenharia de software. 
 
Consultas à bibliografia remetem a diversas formas de reuso, como a engenharia de 
domínio, a utilização de padrões de projeto, desenvolvimento a partir de modelos, 
desenvolvimento baseado em componentes, linhas de produto de software. 
 
Segundo D’Souza e Wills (2001), artefatos, sejam eles quais forem, podem ser reutilizados. 
Não apenas o código, mas programas inteiros e a própria documentação como: casos de 
teste, diagramas, projetos, frameworks de aplicação, sistemas orientados a serviço, entre 
outros. No reuso de software, quanto mais informação um ativo possuir, maior é seu valor 
agregado e, consequentemente, maior o retorno de sua reutilização. 
 
Como abordado por Almeida (2007), 75% das funcionalidades desenvolvidas são comuns a 
mais de um sistema. Em termos gerais, de 40 a 60% da codificação poderia ser reutilizada 
em outras aplicações, sendo 15% do código exclusivo para uma determinada aplicação. 
 
2.1. Benefícios do reuso 
 
 
Esta Subseção apresenta os principais benefícios do reuso na engenharia de software, 
segundo Almeida (2007), a saber: 
Um estudo sobre métricas para acompanhamento de processos de reuso de software, por Tiago de Morais Ferreira 
 
 
[ 8 ] 
 
A reutilização de software resulta em melhorias na qualidade, produtividade e 
confiabilidade. O lançamento de revisões para um determinado ativo eleva o nível de 
qualidade do software produzido, pois se acumulam as correções a cada versão. 
Um ganho de produtividade é alcançado devido ao menor número de artefatos a serem 
desenvolvidos, resultando em menor esforço em testes, análises e mão-de-obra, 
restringindo custos e o tempo necessário para comercialização. 
A utilização de componentes bem testados aumenta a confiabilidade do software. Elaborar 
cada sistema de zero significa desenvolvimento redundante, como a especificação de 
requisitos, casos de uso, arquitetura etc. 
 
Embora a documentação seja muito importante para a manutenção de um sistema, muitas 
vezes é negligenciada. A reutilização de componentes reduz a quantidade de 
documentação a ser escrita a cada projeto, sendo necessária apenas a elaboração da 
documentação referente aos novos recursos. 
Menos defeitos podem ser esperados quando a qualidade do software é comprovada e 
existe o amadurecimento dos componentes utilizados. 
Após a elaboração de componentes para determinados domínios, a realocação de 
profissionais em outros projetos se torna facilitada. Quando existem recursos disponíveis 
para reutilização de software, o desenvolvimento é propiciado. 
 
2.2. Desafios na implementação de reuso sistêmico 
 
 
Os benefícios citados na Subseção anterior levam à pergunta: Qual o motivo do reuso 
ainda não ter sido adotado em larga escala pelas fabricantes de software? A resposta pode 
estar na complexidade para obtenção destas benfeitorias. “Os fatores que influenciam 
direta ou indiretamente a reutilização de software pelas organizações são: econômicos, 
sociais, conceituais, técnicos ou de gestão” (SAMETINGER, 1997, p. 275). A reutilização de 
software não é apenas algo técnico, é um processo que depende do apoio da alta gerência 
e do comprometimento dos envolvidos para obtenção de resultados. 
Os custos iniciais de elaboração de um conjunto de ativos, especificação, testes, 
homologação, logística de armazenagem e recuperação elevam os custos iniciais de 
desenvolvimento, o que pode influenciar negativamente quanto ao apoio da gerência e dos 
desenvolvedores. 
 
Frakes e Isoda (1994) salientam quanto à necessidade de reestruturação do ciclo de vida 
para que o reuso seja parte relevante do processo de produção de software. São 
imprescindíveis alterações no processo de desenvolvimento a fim de que a identificação, 
especificação de requisitos, documentação e definição de ativos a serem utilizados 
constituam o cerne do planejamento de projetos de software. 
 
Uma equipe de profissionais para identificação, desenvolvimento e certificação de ativos é 
recomendada, o que acarreta em redução da equipe alocada aos projetos de software ou 
na contratação de novos colaboradores para fomentarem estas etapas. 
 
A organização pode ter de arcar com os custos de treinamento, elaboração da metodologia, 
o processo de reutilização, desenvolvimento e certificação de ativos, ferramentas, etc, e 
Um estudo sobre métricas para acompanhamento de processos de reuso de software, por Tiago de Morais Ferreira 
 
 
[ 9 ] 
estes custos podem se mostrar um impeditivo, mesmo que em longo prazo a empresa 
venha a se beneficiar com ganhos na produtividade. 
 
Há ainda outros desafios a serem superados, como o controle do processo de reuso no 
ciclo de vida do software, assunto que será abordado na Seção 3. 
 
2.3. Fatores críticos de sucesso 
 
 
Frakes e Isoda (1994) listam seis fatores críticos de sucesso para que seja implantado um 
processo sistêmico de reuso de software, sendo um dos principais o apoio da alta gerência. 
Isso porque o reuso de software tende a necessitar de demasiado tempo para 
planejamento, desenvolvimento e testes de componentes, o que depende de apoio dos 
gestores com visão de retorno do investimento que será demandado no primeiro momento. 
 
A medição da utilização de ativos é fator crucial para identificação de gaps e melhorias no 
processo de reuso. Medidas como a quantidade de tempo poupado e a quantidade de 
falhas antes e depois da execução do processo são informações de grande relevância para 
a gerência da organização. 
 
Outro ponto importante descrito por Frakes e Isoda (1994) é a definição das questões 
legais quanto à responsabilidade de manutenção de componentes adquiridos, garantindo a 
cobertura legal quanto a problemas oriundos do uso de componentes terceirizados no 
projeto. 
 
O desenvolvimento voltado ao reuso deve ser previamente estudado, visando elencar as 
funcionalidades recorrentes a serem providas e os ativos existentes capazes de atendê-las. 
Estudos levantados por Frakes e Isoda, (1994) dão conta de que componentes elaborados 
devem ser reutilizados ao menos duas vezes para que o investimento em sua concepção 
seja justificado. 
 
Por fim, o desenvolvimento voltado para reuso deve considerar como basilar sua execução 
de forma sistêmica, envolvendo o planejamento, elaboração, catalogação, documentação, 
testes e disponibilização para utilização de ativos reutilizáveis em projetos futuros. 
 
3. Processos e o reuso 
 
 
A palavra processo vem do latim procedere, que se refere à ação de avançar, andar para 
frente. Um processo é formado por um conjunto de ações que são realizadas para se 
atingir um determinado objetivo. 
 
Na engenharia de software, Fuggeta (2000) define como processo de desenvolvimento um 
conjunto de estruturas organizacionais, tecnologias, procedimentos e metodologias a serem 
seguidas para a confecção de um sistemacomputacional. Sommerville (2007) caracteriza o 
processo de desenvolvimento de software como um conjunto de atividades criativas e 
intelectuais, sendo dependentes do raciocínio humano e variáveis entre as organizações. 
Um estudo sobre métricas para acompanhamento de processos de reuso de software, por Tiago de Morais Ferreira 
 
 
[ 10 ] 
 
É ratificado por Griss (1995) e Bauer (1993) que o modo mais eficaz para a obtenção do 
sucesso na seleção e adequação da reutilização de software é através de um processo 
definido. No entanto, cada organização deve aplicar o reuso de forma a se adaptar ao seu 
processo de desenvolvimento, elencando os principais objetivos que se deseja alcançar, 
definindo métricas de acompanhamento e gerenciando os riscos, como dito por Frakes 
(1996). 
 
3.1. MPS.BR e a melhoria da qualidade de software 
 
 
O MPS.BR, Modelo de Referência para Melhoria do Software Brasileiro, criado em 2003 pela 
Softex, Associação para Promoção da Excelência do Software Brasileiro, tem o intuito de 
melhorar os processos de software e de serviços no Brasil. O Modelo de Referência MPS 
para Software (MR-MPS-SW) tem como base técnica a NBR ISO/IEC 12207 e o CMMI-DEV. 
Define níveis de maturidade que são uma combinação entre processos e capacidades. 
 
A definição dos processos segue os requisitos para um modelo de referência de processo 
apresentados na ISO/IEC 15504-2, declarando o propósito e os resultados esperados de 
sua execução. Isso permite avaliar e atribuir graus de efetividade na execução dos 
processos. “Os níveis de maturidade são cumulativos e classificados por letras, o que 
significa dizer que cada nível de maturidade engloba todos os aspectos dos antecessores e 
adiciona outros requisitos para que o próximo nível seja atingido, iniciando com o nível G 
até o A” (SOFTEX, 2013, p. 17). A Figura 1, abaixo, ilustra os níveis de maturidade: 
 
 
Figura 1: Níveis de Maturidade do MPS.BR. 
Fonte: Elaborado pelo autor. 
 
 
3.2. Processo de reuso 
 
 
No que tange ao reuso de software e controle do processo, o modelo de referência MPS.BR 
define o processo MED - Medição, a ser executado já no nível F - Gerenciado. “O propósito 
do processo Medição é coletar, armazenar, analisar e relatar os dados relativos aos 
produtos desenvolvidos e aos processos implementados na organização e em seus 
Um estudo sobre métricas para acompanhamento de processos de reuso de software, por Tiago de Morais Ferreira 
 
 
[ 11 ] 
projetos, de forma a apoiar os objetivos organizacionais. ” (SOFTEX, 2013, p 32). O 
processo tem como resultados esperados: 
 
 
MED 1. Objetivos de medição são estabelecidos e mantidos a partir dos objetivos de 
negócio da organização e das necessidades de informação de processos técnicos e 
gerenciais; 
MED 2. Um conjunto adequado de medidas, orientado pelos objetivos de medição, é 
identificado e definido, priorizado, documentado, revisado e, quando pertinente, 
atualizado; 
MED 3. Os procedimentos para a coleta e o armazenamento de medidas são 
especificados; 
MED 4. Os procedimentos para a análise das medidas são especificados; 
MED 5. Os dados requeridos são coletados e analisados; 
MED 6. Os dados e os resultados das análises são armazenados; 
MED 7. Os dados e os resultados das análises são comunicados aos interessados e são 
utilizados para apoiar decisões 
(SOFTEX, 2013, p. 32). 
 
No nível E – Parcialmente Definido, deve ser implantado o processo GRU - Gerência de 
Reutilização, que visa gerenciar o ciclo de vida dos ativos reutilizáveis. Como resultados 
esperados na implantação deste processo, são listados: 
 
 
GRU 1. Uma estratégia de gerenciamento de ativos é documentada, contemplando a 
definição de ativo reutilizável, além dos critérios para aceitação, certificação, classificação, 
descontinuidade e avaliação de ativos reutilizáveis; 
GRU 2. Um mecanismo de armazenamento e recuperação de ativos reutilizáveis é 
implantado; 
GRU 3. Os dados de utilização dos ativos reutilizáveis são registrados; 
GRU 4. Os ativos reutilizáveis são periodicamente mantidos, segundo os critérios 
definidos, e suas modificações são controladas ao longo do seu ciclo de vida; 
GRU 5. Os usuários de ativos reutilizáveis são notificados sobre problemas detectados, 
modificações realizadas, novas versões disponibilizadas e descontinuidade de ativos. 
(SOFTEX, 2013, p. 36). 
 
4. Métricas e indicadores para reuso de software 
 
 
Segundo Almeida, (2007) as principais questões a serem respondidas pela engenharia de 
software são: quanto de reuso de software deve haver em um projeto? Quanto o reuso de 
software melhora o meu time to market? A máxima do que não pode ser medido não pode 
ser controlado é fundamental na engenharia de software, principalmente na gerência do 
reuso. Os indicadores são as ferramentas para obter informações quanto à execução dos 
processos, os quais suportam as tomadas de decisão. 
 
Almeida (2007) define que as métricas para controle do processo de reuso podem ser de 
três categorias principais: i) métricas de reuso orientada à economia, relacionadas ao 
retorno de investimento e aos aspectos financeiros; ii) métricas orientadas à estrutura do 
software, que buscam analisar tecnicamente o quê e como está sendo reutilizado no 
Um estudo sobre métricas para acompanhamento de processos de reuso de software, por Tiago de Morais Ferreira 
 
 
[ 12 ] 
projeto e; iii) métricas de repositório de ativos reutilizáveis que buscam prover informações 
gerenciais sobre a reutilização de ativos na organização. 
 
Frakes e Terry (1996) categorizam as métricas em seis modalidades, sendo elas: análises 
de custo/benefício, medição de maturidade, quantidade de reuso, análises de falhas, 
avaliação de reutilização e métricas de biblioteca de reuso. Estas subdivisões são 
importantes para o entendimento e seleção das métricas de acordo com os resultados que 
se deseja obter em relação aos dados levantados. 
 
Entre as diferentes formas de categorização, é evidente a relação entre elas, tendo ambas 
as formas de categorização métricas financeiras em geral, métricas de repositório e 
métricas técnicas em relação à aplicação e desenvolvimento para o reuso de software. As 
subseções seguintes discutem algumas métricas dividas por estas categorias. 
 
4.1. Métricas orientadas à economia e custo/benefício 
 
 
São indicadores e métricas que buscam mensurar o retorno do investimento em reuso, o 
custo de desenvolvimento de ativos reutilizáveis, os ganhos obtidos com a redução do 
tempo de desenvolvimento e custos envolvido com a definição de um processo sistêmico 
de reuso de software. O lucro é um dos principais objetivos das organizações ao implantar 
o reuso no ciclo de vida. Faz-se necessário justificar o investimento inicial de implantação 
para obtenção do patrocínio da alta gerência das organizações, como exposto por Frakes e 
Terry (1996). 
 
4.1.1. Custo de Desenvolvimento Evitado (DCA) 
 
O Custo de Desenvolvimento Evitado ou Development Cost Avoided (DCA), descrito por 
Frakes e Terry (1996), é utilizado para analisar o custo, em moeda corrente, poupado pela 
reutilização de código. Para utilização do modelo é necessário ter conhecimento quanto ao 
custo por linhas de código (LOC). E como o DCA é baseado em linha de código, é o único 
artefato de software capaz de ser medido. Utiliza-se a unidade de medida real (R$). Abaixo 
estão as medidas envolvidas na métrica: 
 
RSI = Total de linhas de código incluídas no projeto provenientes de ativos desenvolvidos 
anteriormente que não demandaram alterações para sua utilização. 
RCR = Custo relativo de reutilização, esforço para reutilizar um componente sem a 
realização de alterações em seu código. Pode-se considerar como exemplo o valor de 0,2. 
 
Calcula-se o DCA multiplicando o custo identificado para desenvolvimento de código com 
base em projetos legados pela quantidade de código reutilizado (RSI) e ajustando com 
base no custo relativo de reutilização, Relative Cost of Reuse (RCR),segundo a fórmula: 
DCA = RSI x (1-RCR) x Custo de nova linha de código. 
 
Por exemplo, com um RCR = 0,2, o DCA representa uma economia de 80% em relação ao 
novo desenvolvimento. Custos de manutenção evitados por este modelo são denominados 
como custos de serviço. Estes custos levam em consideração taxas de erro e número de 
erros ocorridos após o novo artefato ter sido utilizado. 
Um estudo sobre métricas para acompanhamento de processos de reuso de software, por Tiago de Morais Ferreira 
 
 
[ 13 ] 
 
4.1.2. Custo de Serviço Evitado (SCA) 
 
Segundo Frakes e Terry (1996), O Custo de Serviço Evitado ou Service Cost Avoided, 
representa o custo que a organização evitou durante a fase de manutenção dos projetos de 
software, o SCA, combina com o Custo de Desenvolvimento Evitado (DCA). Calcula-se o 
SCA multiplicando a taxa de erro histórica dos projetos pelo custo histórico de correção dos 
erros identificados e pela quantidade de código reutilizado (RSI). Utiliza-se a unidade de 
medida real (R$): 
 
RSI = Total de linhas de código incluídas no projeto proveniente de ativos desenvolvidos 
anteriormente que não demandaram alterações para sua utilização. 
ER = Taxa de erros relatados durante manutenção / serviço. 
EC = Custo envolvido na identificação erros, comunicação, correções e testes. 
 
A fórmula para cálculo do SCA é conforme segue: 
SCA = RSI x ER x EC 
 
4.1.3. Custo Evitado pelo Reuso (RCA) 
 
É o benefício financeiro total para uma empresa proveniente da reutilização de software. 
Considerando o desenvolvimento e a manutenção dos ativos reutilizáveis, a RCA é igual à 
soma de DCA e SCA. Utiliza-se como unidade de medida o Real (R$) e as medidas 
envolvidas são as seguintes: 
 
DSA= Custo de Desenvolvimento Evitado. 
SCA= Custo de Serviço Evitado. 
 
Fórmula: 
RCA = DSA + SCA 
 
Estudos realizados por Poulin (1993) despontam que os custos envolvidos na reutilização 
de um ativo equivalem a 20% do custo de desenvolvimento do mesmo, além de identificar 
que o benefício financeiro da reutilização de software gira em torno de 80% em relação ao 
desenvolvimento de novo código. 
 
4.1.4. Qualidade do Investimento 
 
Analisando o reuso de software, Barns e Bollinger (1991) dividiram as atividades de reuso 
em dois tipos: produção e consumo, sendo a produção um investimento e o consumo dos 
ativos um benefício. Utilizando um modelo analítico, encontra-se a relação entre o 
investimento a ser realizado no desenvolvimento de ativos e quanto pode ser economizado 
com a reutilização em outros projetos. 
 
Frakes e Terry (1996), referenciando Barns e Bollinger (1991) define a Qualidade do 
Investimento através da fórmula: Q=B/R, onde Q é a qualidade do investimento, B são os 
benefícios da reutilização de determinado ativo e R o esforço para reutilizar o mesmo. Se o 
valor de Q for superior a 1, houve lucro pelo desenvolvimento do ativo, caso contrário 
Um estudo sobre métricas para acompanhamento de processos de reuso de software, por Tiago de Morais Ferreira 
 
 
[ 14 ] 
significa um prejuízo financeiro para a empresa. Frakes (1996) elenca como sendo as três 
principais estratégias para melhoria da qualidade do investimento i) a redução do custo de 
reutilização do ativo; ii) o aumento de reutilização de software no desenvolvimento do ativo 
e iii) a redução do investimento para o alcance de determinado objetivo. 
 
4.2. Métricas orientadas à estrutura 
 
 
As métricas orientadas para a estrutura do software visam analisar a relação entre o código 
reutilizado e o novo código desenvolvido. Para Frakes e Terry (1996), as métricas de 
reutilização têm o objetivo de avaliar e monitorar a melhoria na aplicação de ativos 
seguindo percentagens de reutilização dos objetos do ciclo de vida de software ao longo do 
tempo. A principal fórmula é: 
Quantidade de objetos do ciclo de vida que foram reutilizados / Quantidade total de objetos 
do ciclo de vida. 
 
4.2.1. Nível de Reuso, (RL) Reuse Level. 
 
É a relação entre o número de ativos reutilizados e o número total de ativos. As partes 
internas podem também ser consideradas como reutilizadas, quando se faz referência a 
elas. Neste caso, RL pode ser dividido em RL interno (IRL), RL externo (ERL) e Total RL 
(TRL), fórmula descrita por Frakes e Terry (1994). 
 
Fórmula: 
Quantidade de ativos reutilizados = IRL + ERL. 
RL=Quantidade de ativos reutilizados / TRL. 
 
4.2.2. Frequência de Reutilização 
 
Segundo Frakes e Terry (1994) a frequência de reutilização (FR) é definida como a razão 
entre o número de peças reutilizadas para o número total de referências. Similarmente a 
RL, RF pode ser dividido em: RF interno (IRF), RF externo (ERF) e RF total (TRF). 
 
A métrica de frequência de reutilização contabiliza as referências (tokens) aos componentes 
reutilizados em vez de contar apenas os componentes como na métrica anterior: 
 
IUF = Número de referências de objetos de alto nível reutilizados internamente por objetos 
de baixo nível. 
EUF = Número de referências a objetos de alto nível reutilizados externamente por objetos 
de baixo nível. 
TF = Número de referências para objetos de menor nível em objeto de maior nível tanto 
interna quanto externamente. 
 
Fórmula: 
Frequência de reutilização interna: IUF/TF. 
Frequência de reutilização externa: EUF/TF. 
Frequência total de reutilização: (IUF + EUF)/TF. 
 
Um estudo sobre métricas para acompanhamento de processos de reuso de software, por Tiago de Morais Ferreira 
 
 
[ 15 ] 
 
4.3. Métricas de repositório 
 
 
Prieto-Diaz e Freeman (1987) são grandes colaboradores da abordagem de criação e 
classificação de repositórios de ativos reutilizáveis. Seu trabalho propôs a classificação de 
componentes baseando-se em facetas, possibilitando que um mesmo componente fosse 
identificado em mais de um domínio, e igualmente por disponibilizar várias funcionalidades. 
Um conjunto limitado de possíveis palavras-chave é associada a cada faceta. Para 
descrever um componente, uma ou mais palavras-chave são escolhidas. 
 
Abordagens anteriores remetiam ao esquema de árvore, o que impedia que ativos 
participassem simultaneamente de vários domínios de aplicação ou então se proliferavam 
as duplicações de ativos para que pudessem ser mais facilmente recuperados, como 
exposto por Prieto-Diaz e Freeman (1987). 
Apesar da contribuição do sistema de repositório e seus já conhecidos ganhos quando bem 
elaborado e implantado, apenas um sistema de repositório por si só não garante o sucesso 
na reutilização de software. No entanto, estes sistemas associados com componentes 
certificados, armazenados em domínios específicos, com mecanismos eficientes de 
pesquisa e recuperação, podem oferecer resultados significativos. 
 
Após a revisão das principais métricas encontradas na literatura para reuso de software, 
este trabalho apresenta, na próxima Seção, a elaboração de um novo indicador para 
mensuração do reuso. Os objetivos deste indicador são os de atingir os benefícios da 
prática sistêmica do reuso abordados na Seção 2, atendendo às recomendações de 
utilização de um processo de reuso definido e controlado como descrito por Frakes e Isoda 
(1994), de fornecer informações requeridas pelos processos do modelo de referência 
MPS.BR no que tange ao controle do processo de Gerência de Reutilização. 
 
5. FRRT – Fórmula real de reuso t 
 
 
A Fórmula Real de Reuso T (FRRT) enquadra-se na categoria Métricas para o Repositório 
de Reuso, ou Reuse Repository Metrics (RRM), que visa tornar o repositório um assistente 
na gestão do reuso a nível organizacional. 
 
Segundo Banker (1993), o repositório assume o papel de barramento de comunicação 
entre os desenvolvedores e consumidores de ativos. Este canal deve ser monitorado 
buscando analisar o reuso em diferentes projetos da organização. “[...] o repositório de 
reutilização deve oferecer serviços que permitam aos gerentes monitorar o reuso de 
software em vários projetos, e para fazer isso é necessário que o repositório possua um 
conjunto de métricas”(ALMEIDA, 2007, p.172). 
 
A métrica FRRT foi elaborada com o intuito de identificar a efetiva utilização dos ativos 
disponibilizados no repositório entre os diversos projetos de software de uma organização, 
identificando o nível de reuso geral alcançado num determinado período, obtendo-se uma 
visão macro da reutilização de ativos após a implantação do processo de reuso, em que: 
Um estudo sobre métricas para acompanhamento de processos de reuso de software, por Tiago de Morais Ferreira 
 
 
[ 16 ] 
 
QUA = Quantidade de reutilizações dos ativos disponibilizados no repositório considerando 
todos os projetos. 
QAR = Total de ativos existentes no repositório. 
QP = Total de projetos em desenvolvimento. 
 
FRRT é a razão entre a quantidade de reutilizações dos ativos em todos os projetos pela 
quantidade de ativos existentes no repositório e a razão pela quantidade de projetos sendo 
gerenciados, multiplicado por cem para se chegar à porcentagem de reuso. 
 
A métrica pode variar de 0% a 100% de reuso no período e a fórmula para cálculo é a 
seguinte: 
 
QUA = Somatório de ativos reutilizados no projeto 1 +...+ Somatório de ativos reutilizados 
no projeto N. 
QAR = Total de ativos no repositório. 
QP = Total de projetos em curso. 
FRRT = ( ( QUA / QAR ) / QP ) * 100. 
 
Exemplo 1: Em janeiro, uma determinada empresa verificou a existência de quinze ativos 
reutilizáveis disponíveis em seu repositório. No mesmo período, estavam em curso seis 
projetos de software e foram registradas trinta reutilizações de ativos no total dos projetos. 
 
FRRT = ((30 / 15) / 6) * 100. 
FRRT= (2 / 6) * 100. 
FRRT = 0,33 * 100. 
FRRT = 33% de reutilização de software para o mês de janeiro. 
 
Exemplo 2: Na Figura 2 é apresentado um exemplo contendo gráficos elaborados a partir 
de dados fictícios sobre o consumo de componentes reutilizáveis, a quantidade de ativos 
disponíveis no repositório, a quantidade de projetos por mês e a métrica FRRT calculada. 
Um estudo sobre métricas para acompanhamento de processos de reuso de software, por Tiago de Morais Ferreira 
 
 
[ 17 ] 
 
Figura 2: Gráficos com dados fictícios para o período de um ano. 
Fonte: Elaborada pelo autor. 
 
Um estudo sobre métricas para acompanhamento de processos de reuso de software, por Tiago de Morais Ferreira 
 
 
[ 18 ] 
 
5.1. Interpretações e limitações 
 
 
Quando você coleta dados quantitativos sobre software e processos de software, precisa 
analisar esses dados para entender seu significado. É fácil interpretar dados 
erroneamente e fazer inferências incorretas. Você não pode simplesmente olhar os dados 
per se — você também deve considerar o contexto em que eles são coletados. 
(SOMMERVILLE, 2011, p. 487). 
 
Na avaliação dos resultados, devem-se considerar os domínios de conhecimento que estão 
sendo abordados pelos projetos da organização. Iniciativas de software em áreas até então 
não exploradas farão com que a métrica FRRT retorne uma quantidade de reuso inferior 
em comparação a outros períodos onde tais projetos não existiam. A falta de ativos 
reutilizáveis pertinentes a estes novos domínios reduz o índice de reuso, observe que no 
mês de julho (ver Figura 2), a taxa de reuso caiu apesar do aumento de projetos e de 
reutilizações dos ativos. Situações como esta devem ser analisadas caso a caso. 
 
5.2. Validação da métrica 
 
 
Nesta Subseção a métrica FRRT é avaliada a partir de estudo de caso real com uma 
empresa de desenvolvimento de software. 
 
5.2.1. Cenário 
 
Para validação da eficácia do indicador proposto foi selecionada uma empresa do ramo de 
desenvolvimento de sistemas web e, inicialmente, foi realizada a análise do seu processo 
de desenvolvimento e verificação do nível de maturidade à luz do MPS.BR, a fim de 
categorizar a organização quanto à capacidade e maturidade. 
 
Em respeito ao acordo de confidencialidade firmado, não serão disponibilizadas 
informações capazes de identificar a organização pesquisada. 
 
5.2.2. Descrição da metodologia para coleta de dados na instituição 
 
Foi realizado o levantamento de informações junto aos gestores e profissionais da operação 
a respeito de dez projetos, analisando os processos pertinentes ao ciclo de vida do 
desenvolvimento de software através da aplicação de questionários e entrevistas com base 
no guia MPS.BR SW. Foram consideradas apenas as definições para o tipo de instituição 
descrito como fábrica de software. 
 
Nos procedimentos de coleta, a pesquisa é documental, pois foram analisados projetos de 
desenvolvimento de software e seus respectivos ativos. Para fins de exibição dos 
resultados, considerou-se a definição: 
Sim: De 90% a 100% dos projetos apresentaram resultado positivo, com ao menos AP 1.1 
satisfeito. 
Um estudo sobre métricas para acompanhamento de processos de reuso de software, por Tiago de Morais Ferreira 
 
 
[ 19 ] 
Na maioria dos projetos: 60% a 89% dos projetos apresentaram resultado positivo, com ao 
menos AP 1.1 satisfeito. 
Na minoria dos projetos: 21% a 59% dos projetos apresentaram resultado positivo, com ao 
menos AP 1.1 satisfeito. 
Não: De 0% a 20% dos projetos apresentaram resultado positivo, com ao menos AP 1.1 
satisfeito. 
 
5.2.3. Resultados quanto à identificação do nível de maturidade 
 
Para galgar o primeiro nível estabelecido pelo MPS.BR, nível G, a organização precisa 
atender aos requisitos definidos para os processos: Gerência de Projetos - GPR e Gerência 
de Requisitos - GRE. Os resultados coletados na empresa em questão são apresentados 
nos quadros 1 e 2. 
 
Nos procedimentos de coleta, a pesquisa é documental, pois foram analisados projetos de 
desenvolvimento de software e seus respectivos ativos. Para fins de exibição dos 
resultados, considerou-se a definição: 
Sim: De 90% a 100% dos projetos apresentaram resultado positivo, com ao menos AP 1.1 
satisfeito. 
Na maioria dos projetos: 60% a 89% dos projetos apresentaram resultado positivo, com ao 
menos AP 1.1 satisfeito. 
Na minoria dos projetos: 21% a 59% dos projetos apresentaram resultado positivo, com ao 
menos AP 1.1 satisfeito. 
Não: De 0% a 20% dos projetos apresentaram resultado positivo, com ao menos AP 1.1 
satisfeito. 
 
Resultados quanto à identificação do nível de maturidade 
 
Para galgar o primeiro nível estabelecido pelo MPS.BR, nível G, a organização precisa 
atender aos requisitos definidos para os processos: Gerência de Projetos - GPR e Gerência 
de Requisitos - GRE. Os resultados coletados na empresa em questão são apresentados 
nos quadros 1 e 2. 
 
Quadro 1: Análise de resultados esperados para o processo de Gerência de 
Projetos GPR. 
Resultados esperados Realizado 
GPR1 - O escopo do trabalho para o projeto é definido. Sim 
GPR2 - As tarefas e os produtos de trabalho do projeto são dimensionados 
utilizando métodos apropriados. 
Sim 
GPR3 - O modelo e as fases do ciclo de vida do projeto são definidos. Sim 
GPR4 - O esforço e o custo para a execução das tarefas e dos produtos de 
trabalho são estimados com base em dados históricos ou referências 
técnicas 
Sim 
GPR5 - O orçamento e o cronograma do projeto, incluindo a definição de 
marcos e pontos de controle, são estabelecidos e mantidos. 
Sim 
GPR6 - Os riscos do projeto são identificados e o seu impacto, 
probabilidade de ocorrência e prioridade de tratamento são, determinados 
Sim 
Um estudo sobre métricas para acompanhamento de processos de reuso de software, por Tiago de Morais Ferreira 
 
 
[ 20 ] 
e documentados. 
GPR7 - Os recursos humanos para o projeto são planejados considerando 
o perfil e o conhecimento necessários para executá-lo. 
Sim 
GPR8 - Os recursos e o ambiente de trabalho, necessários para executar o 
projeto são planejados. 
Sim 
GPR9 - Os dados relevantes do projeto são identificados e planejados 
quanto à forma de coleta, armazenamento e distribuição. Um mecanismo 
é estabelecido para acessá-los, incluindo, se pertinente, questões de 
privacidade e segurança. 
Sim 
GPR10 - Um plano geral para a execuçãodo projeto é estabelecido com a 
integração de planos específicos. 
Sim 
GPR11 - A viabilidade de atingir as metas do projeto é explicitamente 
avaliada considerando restrições e recursos disponíveis. Se necessário, 
ajustes são realizados. 
Sim 
GPR12 - O Plano do Projeto é revisado com todos os interessados e o 
compromisso com ele é obtido e mantido. 
Sim 
GPR13 - O escopo, as tarefas, as estimativas, o orçamento e o cronograma 
do projeto são monitorados em relação ao planejado. 
Não 
GPR14 - Os recursos materiais e humanos bem como os dados relevantes 
do projeto são monitorados em relação ao planejado. 
Não 
GPR15 - Os riscos são monitorados em relação ao planejado. Não 
GPR16 - O envolvimento das partes interessadas no projeto é planejado, 
monitorado e mantido. 
Na minoria 
dos projetos 
GPR17 - Revisões são realizadas em marcos do projeto e conforme 
estabelecido no planejamento. 
Na maioria 
dos projetos 
GPR18 - Registros de problemas identificados e o resultado da análise de 
questões pertinentes, incluindo dependências críticas, são estabelecidos e 
tratados com as partes interessadas. 
Sim 
Fonte: Elaborado pelo autor. 
 
Quadro 2: Análise de resultados esperados para o processo de Gerência de 
Requisitos GRE. 
Resultados esperados Realizado 
GRE1 - O entendimento dos requisitos é obtido junto aos fornecedores 
de requisitos. 
Sim 
GRE2 - Os requisitos são avaliados com base em critérios objetivos e um 
comprometimento da equipe técnica com estes requisitos é obtido. 
Na maioria dos 
projetos 
GRE3 - A rastreabilidade bidirecional entre os requisitos e os produtos de 
trabalho é estabelecida e mantida. 
Não 
GRE4 - Revisões em planos e produtos de trabalho do projeto são 
realizadas visando identificar e corrigir inconsistências em relação aos 
requisitos. 
Na minoria dos 
projetos 
GRE5 - Mudanças nos requisitos são gerenciadas ao longo do projeto. Sim 
Fonte: Elaborado pelo autor. 
 
 
 
Um estudo sobre métricas para acompanhamento de processos de reuso de software, por Tiago de Morais Ferreira 
 
 
[ 21 ] 
 
 
 
6. Proposta de melhoria no processo de reuso de software 
 
 
Nesta seção é apresentado o diagnóstico baseado nos resultados levantados quanto à 
capacidade de execução do processo de gerenciamento de projetos, e na definição: “Os 
níveis são acumulativos, ou seja, se a organização está no nível F, esta possui o nível de 
capacidade do nível F que inclui os atributos de processo dos níveis G e F para todos os 
processos relacionados no nível de maturidade F (que também inclui os processos do nível 
G) ” (SOFTEX, 2013, p. 17). 
 
Assim, a empresa não está apta possuir o MPS.BR nível G, mas busca a melhoria na 
gerência dos processos existentes na organização, especificamente quanto ao processo de 
reuso de software em seu aspecto de medição da quantidade de reuso. Para isso, propõe-
se a utilização da métrica FRRT, tendo como base os dez projetos verificados e o 
repositório de ativos reutilizáveis. 
 
Até a elaboração deste trabalho, a empresa entrevistada já possuía uma cultura de reuso 
de software para dinamizar o desenvolvimento de aplicações e um processo de reuso 
contemplando o planejamento e a execução do reuso de software já era esquematizado, 
porém, a análise e acompanhamento do processo não eram realizados. Dessa forma, a 
empresa não era capaz de obter informações quanto à redução de custos, redução do 
tempo de desenvolvimento, quais ativos são mais relevantes no que se refere à quantidade 
de aplicações em projetos da organização. 
 
A métrica FRRT foi aplicada nos projetos analisados, sendo um início para o 
acompanhamento do processo de reuso existente. Essa iniciativa possibilita a criação de 
metas e análises sobre os ativos reutilizáveis e posteriores ações quanto à melhoria na 
execução do processo. 
 
No repositório, a empresa conta hoje com 26 ativos reutilizáveis. Para identificá-los, 
explorou-se um file server com estrutura de pastas especificada pela empresa, utilizando o 
modelo em árvore para busca de ativos. O repositório foi desenvolvido pelos próprios 
funcionários. O sistema funciona a contento, mas causa falta de clareza para armazenagem 
de ativos que poderiam vir a pertencer a mais de um diretório. Não existe o levantamento 
de métricas. 
 
6.1. Análise de ativos reutilizados e cálculo da métrica FRRT 
 
 
O Quadro 3 exibe os dados referentes à quantidade de ativos empregados nos projetos 
elaborados no período de fevereiro a agosto de 2016 pela empresa analisada (ver Quadro 
3). Com base nos dados coletados, tornou-se possível identificar a quantidade de 
reutilização de cada ativo e da quantidade de ativos em cada projeto, considerando o total 
Um estudo sobre métricas para acompanhamento de processos de reuso de software, por Tiago de Morais Ferreira 
 
 
[ 22 ] 
de vinte e seis ativos disponíveis no repositório e dez projetos analisados, foi possibilitada a 
aplicação da métrica FRRT. 
 
 
Quadro 3: Projetos analisados 
Período: 02/01/2016 a 01/08/2016 
Projeto Ativos 
reutilizados 
Projeto Ativos 
reutilizados 
Projeto1– Site Profissional 10 Projeto6 – Foto blog 8 
Projeto2 – Site Imobiliária 6 Projeto7 – Site Corretor 6 
Projeto3 – eCommerce 20 Projeto8 – Portal 13 
Projeto4 – Site Profissional 9 Projeto9 – Site Institucional 16 
Projeto5 – App Totem 6 Projeto10 – Vlog 14 
Fonte: Elaborado pelo Autor. 
 
Realizando o cálculo a partir da fórmula FRRT = ((Quantidade de reutilizações de ativos / 
Total de ativos existentes no repositório) / Total de projetos em desenvolvimento) * 100, 
obtém-se: 
 
FRRT = ((108 / 26) / 10) * 100. 
FRRT = (4,15 / 10) * 100. 
FRRT = 0,4153 * 100. 
FRRT = 41,53% 
 
O resultado evidenciado significa que a quantidade de reutilização de software para o 
período de fevereiro a agosto de 2016 foi de 41,53%, porcentagem dos recursos 
reutilizados, enquanto 58,47% dos ativos desenvolvidos referem-se a novos conteúdos. 
Tomando como base o descrito por Almeida (2007), evidenciado na Seção 2 deste 
trabalho, onde se estima que de 40% a 60% dos componentes desenvolvidos podem ser 
reutilizados em outros projetos de software, o resultado pode ser considerado satisfatório. 
 
7. Considerações finais 
 
 
A reutilização de software é necessária para o aprimoramento da qualidade das aplicações 
desenvolvidas. A adoção de modelos como o MPS.BR SW, que definem processos e 
entregas para galgar níveis padronizados de maturidade, possibilita a adoção das melhores 
práticas de desenvolvimento e pode auxiliar as organizações a atingir graus mais elevados 
na qualidade de seus produtos, como descrito por Softex (2013). Segundo Almeida (2007), 
o reuso de software, embora recente, vem para dinamizar a produtividade das fábricas de 
software, aplicando soluções já consagradas e fomentando a cultura do desenvolvimento 
de sistemas com qualidade. 
 
Após a conclusão do levantamento dos dados e apresentação dos mesmos, a empresa 
entrevistada considerou a métrica FRRT relevante, pois segundo ela: “Mostrou-se eficiente 
no acompanhamento do processo de reuso e da utilização de ativos em diversos projetos”. 
Um estudo sobre métricas para acompanhamento de processos de reuso de software, por Tiago de Morais Ferreira 
 
 
[ 23 ] 
A empresa adotará a métrica e definirá metas a serem cumpridas em seus projetos visando 
a redução de custos e melhoria na qualidade dos sistemas. 
 
Apensar de evidenciado o não atendimento ao nível G do modelo MPS.BR pela empresa 
pesquisada, este fato não se torna impeditivo para busca da melhoria da qualidade do 
software. O processo de reuso pode auxiliar as organizações nesta tarefa, desde que 
observadas as boas práticas descritas na bibliografia. A métrica proposta atende ao 
demandado por Banker (1993) e Almeida (2007) no sentido de fornecer dados gerenciais 
sobre o reuso de software em diversos projetos da organização, mostrando-se uma 
ferramenta de auxílio à gestão do processo de reuso. 
 
Referências 
 
 
ALMEIDA, E.S, ALVARO, A. GARCIA,V.C, MARCENA, J.C, BURÉGIO, V.A, NASCIMENTO, L. 
M, LUCRÉDIO D. e MEIRA, S.R. C.R.U.I.S.E. Component Reuse In Software Engineering. 
Recife: Gráfica Dom Bosco, 2007. 
BARNS, B. H. e BOLLINGER T.B. Making reuse cost-effective. IEEE Software, 1991 
BANKER, R. D., KAUFFMAN R. J., ZWEIG D. Repository Evaluation of Software Reuse, IEEE 
Software, 1993. 
BAUER, D. A Reusable Parts Center, IBM Systems Journal, 1993 
BASILI, V.R, ROMBACH, H.D. Support for comprehensive reuse. Software. Eng J, 1991. 
D'SOUZA, D.; WILLS, A. C. Objects, Components, and Frameworks with UML - The 
Catalysis Approach. Addison-Wesley, 2001. 
EZRAM, M., MORISIO, M. e TULLY, C. Practical software reuse. England: Springer, 2012. 
FRAKES, W. and ISODA, S. Success factors of systematic reuse. IEEE Software, 1994. 
FRAKES W. TERRY, C. Software Reuse: Metrics and Models. ACM Computing Surveys, 
1996. 
FUGGETTA, A., Software Process: A Roadmap, Limerick, Ireland, 2000. 
GRISS, M. Pilot Project in incremental adoption of systematic reuse, Object Magazine, 
1995. 
MCILROY, M. D. Mass produced software components. NATO Software Engineering 
Conference Report, 1968. 
PRIETO-DIAZ, R, FREEMAN, P. Classifying Software for Reusability. IEEE Software, 1987. 
POULIN, CARUSO, and HANCOCK. The business case for software reuse. IBM. 1993. 
POULIN. Measuring software reuse: Principles, practices, and economic models. Boston, 
MA, USA: Addison-Wesley Longman Publishing Co. Inc, 1996. 
KRUEGER, C.W. Software reuse. ACM Computing Surveys, 1992. 
SAMETINGER, J. Software Engineering with reusable components. Springer, 1997. 
SOFTEX. MPS.BR – Melhoria de Processo do Software Brasileiro: Guia Geral, 2013. 
Disponível em: < www.softex.br/mpsbr > Acesso em: 20/10/2016. 
SOMMERVILLE, Ian. Engenharia de software. 9 ed. São Paulo: Pearson Prentice Hall, 2011 
http://www.softex.br/mpsbr