Estimandoatributosdequalidadede software ... · Catalogação: [email protected] M538e Mendes,...

Universidade Federal de Ouro PretoDepartamento de Computação e SistemasColegiado de Engenharia de Computação

Estimando atributos de qualidade de softwareutilizados e desejados pelas empresascertificadas no MPS-SW no Brasil

Flaviana Pereira Mendes

Trabalho de Conclusãode CursoORIENTAÇÃO:Prof. MSc. Igor Muzetti Pereira

Fevereiro, 2018João Monlevade/MG

Flaviana Pereira Mendes

Estimando atributos de qualidade de softwareutilizados e desejados pelas empresascertificadas no MPS-SW no Brasil

Orientador: Prof. MSc. Igor Muzetti Pereira

Monografia apresentada ao curso de Engenharia deComputação do Departamento de Computação e Sis-temas da Universidade Federal de Ouro Preto comorequisito parcial para obtenção do grau de Bacharelem Engenharia de Computação

Universidade Federal de Ouro PretoJoão MonlevadeFevereiro de 2018

Catalogação: [email protected]

M538e Mendes, Flaviana Pereira. Estimando atributos de qualidade de software utilizados e desejados pelasempresas certificadas no MPS-SW no Brasil [manuscrito] / Flaviana PereiraMendes. - 2018.

44f.: il.: color; grafs; tabs.

Orientador: Prof. MSc. Igor Muzetti Pereira.

Monografia (Graduação). Universidade Federal de Ouro Preto. Instituto deCiências Exatas e Aplicadas. Departamento de Computação e Sistemas deInformação.

1. Engenharia de software. 2. Software - Verificação. I. Pereira, Igor Muzetti.II. Universidade Federal de Ouro Preto. III. Titulo.

CDU: 004.415.5

Agradecimentos

Agradeço a Deus, por todo o cuidado depositado em mim. Aos meus pai, MariaEunice e Vonair, que sempre acreditam e torcem por mim. À minha irmã, Flávia, peloapoio, presença e carinho. Aos meus irmãos, pela confiança e companheirismo. Família,obrigada por entender todos os momentos que estive longe nesta minha caminhada pelagraduação. Amo vocês.

Agradeço aos amigos da faculdade que fizeram o curso ser mais leve e os meus diasmais alegres. À Osmara, que não mediu esforços para que tudo acontecesse da melhorforma possível. Obrigada pela paciência e pelo ensinamento diário do quão é necessáriotermos coragem.

Agradeço à minha família de coração, República Doce Cabana, que foi meu portoseguro e palco do meu enorme crescimento pessoal. Amo todas e viveria tudo isso milvezes se fosse com vocês.

Agradeço ao Prof. Igor Muzetti, por ser um orientador e pessoa magnífica. Obrigadapor todo o conhecimento, paciência e incentivo. Ao laboratório iMobilis pela oportunidadede fazer parte deste grupo e assim crescer profissionalmente.

Por último, agradeço todos que, direta ou indiretamente, estiveram presente nessaetapa da minha vida e ajudaram para que fosse completada com sucesso.

É preciso tentar não sucumbir sob o peso de nossas angústias e continuar a lutar.(J. K. Rowling)

ResumoPor se tratar de um produto abstrato, mensurar a qualidade de um software é uma tarefaárdua. A fim de contribuir para isso as métricas de software são uma forma de realizar ocontrole da qualidade. Métricas de produto e processo são utilizadas para relevar anomaliasque podem estar ligadas com a qualidade. O presente trabalho visa estabelecer os atributosinternos e externos utilizados e desejados por empresas brasileiras atualmente avaliadas nomodelo de referência MPS-SW. Através de um Survey aplicado à essas empresas, foramcoletados dados relevantes e, após um período determinado de tempo, esses dados foramanalisados e catalogados. Por fim, após análises realizadas, foi possível determinar umpadrão de modelo de qualidade que abrange todo o contexto brasileiro.

Palavras-chaves: Qualidade de software. MPS.Br. Métricas. MPS-SW.

AbstractAs an abstract product, measure the software quality is a very difficult task. In order tocontribute to that the software metrics are a way to control the quality. Products metricsand process are used to relieve anomalies that may be connected with the quality. Thepresent work aim to establish the internal and external attributes used and wished bybrazilian enterprises currently evaluated in the reference model MPS-SW. Through asurvey applied to these companies, important data were collected and, after a set periodof time, these data were analyzed and cataloged. In the end, after analyzes performed, astandard model of quality to all brazilian context was set.

Key-words: Software quality. MPS.Br. Metrics. MPS-SW.

Lista de ilustrações

Figura 1 – Metodologia utilizada . . . . . . . . . . . . . . . . . . . . . . . . . . . 22Figura 2 – Métricas de produto utilizadas pelas empresas avaliadas no MPS-SW . 24Figura 3 – Métricas de processo utilizadas pelas empresas avaliadas no MPS-SW . 25Figura 4 – Atributos externos desejados pelas empresas avaliadas no MPS-SW . . 27Figura 5 – Modelo de qualidade das empresas vigentes no MPS-SW . . . . . . . . 28

Lista de tabelas

Tabela 1 – Exemplos de métricas de produto . . . . . . . . . . . . . . . . . . . . . 17Tabela 2 – Exemplos de métricas de processo e projeto . . . . . . . . . . . . . . . 18Tabela 3 – Níveis de maturidade do MPS-SW . . . . . . . . . . . . . . . . . . . . 20

Lista de abreviaturas e siglas

MPS.Br Melhoria de Processo do Software Brasileiro

MPS-SW Modelo MPS para Software

MPS-SV Modelo MPS para Serviços

MA-MPS Método de Avaliação

MN-MPS Modelo de Negócio

CMMI Capability Maturity Model Integration

P-CMM People Capability Maturity Model

TFS Team Foundation Server

LOC Linhas de Código

PF Ponto de Função

Sumário

1 INTRODUÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2 REFERENCIAIS TEÓRICOS . . . . . . . . . . . . . . . . . . . . . . 162.1 Conceitos Básicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.1.1 Métricas de Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.1.1.1 Métricas de Produto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.1.1.2 Métricas de Processo e Projeto . . . . . . . . . . . . . . . . . . . . . . . . . 172.1.2 ISO 25010 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182.1.3 Programa MPS.Br . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192.1.3.1 Modelo de Referência MPS para Software (MPS-SW) . . . . . . . . . . . . . 192.2 Trabalhos Correlatos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3 METODOLOGIA . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

4 RESULTADOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

5 CONSIDERAÇÕES FINAIS . . . . . . . . . . . . . . . . . . . . . . . 295.1 Conclusão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295.2 Limitações e trabalhos futuros . . . . . . . . . . . . . . . . . . . . . . 29

REFERÊNCIAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

APÊNDICE A – QUESTIONÁRIO AOS REPRESENTANTES DASEMPRESAS ATUALMENTE AVALIADAS NOMPS-SW . . . . . . . . . . . . . . . . . . . . . . . . . . 33

APÊNDICE B – QUESTIONÁRIO AOS IMPLEMENTADORES DOMPS-SW . . . . . . . . . . . . . . . . . . . . . . . 37

APÊNDICE C – QUESTIONÁRIO AOS AVALIADORES DOMPS-SW . . . . . . . . . . . . . . . . . . . . . . . . . . 41

14

1 Introdução

A qualidade é um atributo de difícil contextualização devido ao fato de ser relativa.Julgá-la, torna-se portanto, uma questão complexa quando não se tem um padrão (KOS-CIANSKI; SOARES, 2007). Tratando-se de sistemas de software, os quais são imateriais,é ainda mais complexo para as empresas estabelecerem o que pode ser levado em consi-deração quando deseja-se alcançar melhorias na qualidade dos softwares desenvolvidos.Uma possibilidade de melhorar o controle da qualidade é realizar a medição do software,utilizando-se de métricas especificas para tal. Como relata Sommerville (2011), as métricassão dividas em métricas de controle e previsão, sendo habitualmente encontradas comométricas de processo e produto, respectivamente.

Para a medição, são utilizados como dados os atributos internos de qualidade,que estão associados aos atributos externos de qualidade (SOMMERVILLE, 2011). Osatributos internos são características referentes ao desenvolvimento do processo ou aoproduto e os atributos externos são particularidades não funcionais que referem-se aospontos de qualidade desejados. As particularidades que estão inseridas no contexto dequalidade tornam-se passíveis de medição a partir da aplicação correta das métricas emdeterminados atributos internos.

Devido à grande preocupação das empresas com a qualidade dos seus produtos, oinvestimento em melhorias é fundamental. O MPS-Br, definido pela SOFTEX (2016), é umprograma de melhoria de processos de software constituído por quatro vertentes: Modelode Referência MPS para Software (MPS-SW), Modelo de Referência MPS para Serviços(MPS-SV), Método de Avaliação (MA-MPS) e Modelo de Negócio (MN-MPS). O programaé uma modificação do Capability Maturity Model Integration (CMMI), resultando emum modelo de mais fácil implementação para as empresas brasileiras já que, os níveisoriginais do CMMI foram fragmentados em menores (CORGOSINHO, 2006). Atualmenteo MPS-SW possui 690 avaliações realizadas no Brasil, sendo 128 em vigor, o que o torna omodelo mais utilizado na melhoria da capacidade de desenvolvimento de software no país.

Apesar do crescente avanço das empresas brasileiras em relação à melhoria dos seusprocessos, ainda não foi apresentado nenhum modelo de qualidade que caracteriza o cenáriobrasileiro, fazendo com que o presente trabalhado seja viável. Um modelo de qualidade quefoi considerado neste trabalho é exemplificado por Sommerville (2011) como uma relaçãoentre os atributos internos de qualidade com os atributos externos de qualidade.

O objetivo deste trabalho é estimar quais são as métricas de produto e processomonitoradas pelas empresas certificadas no MPS.Br, no modelo de referência para software,e as correlacionar com os atributos externos de qualidade desejados por elas. Assim, será

Capítulo 1. Introdução 15

formado um esboço inicial do que poderia ser um modelo de qualidade que represente asempresas certificadas pelo MPS-SW no Brasil.

Este trabalho encontra-se dividido em mais quatro capítulos: referenciais teóricos,metodologia, resultados e considerações finais. O capítulo 2 refere-se a revisão bibliográficae é subdivido em conceitos básicos, que traz conteúdos relevantes para o entendimento dotrabalho e trabalhos correlatos, onde alguns estudos que são utilizados como base para estetrabalho são apresentados. O capítulo 3 apresenta a metodologia adotada para a realizaçãodeste trabalho. No capítulo 4 denominado resultados, a análise dos dados é realizada ecatalogada para que seja possível uma visão geral das empresas. Por último, o capítulo 5 éde considerações finais e encontra-se dividido em conclusão, limitações e trabalhos futuros.

Ao final da pesquisa é possível visualizar que o atributo externo de “Usabilidade” éo mais desejado pelas empresas, tais quais os caminhos percorridos para que esse resultadotenho o melhor aproveitamento.

16

2 Referenciais teóricos

2.1 Conceitos BásicosEsta seção apresenta noções necessárias para o entendimento do trabalho.

2.1.1 Métricas de Software

As métricas são utilizadas para mensurar o software e assim demonstrar noçõessobre processos, projetos ou produtos (PRESSMAN, 2011). Deste modo, é necessário queestas obtenham a propriedade de serem medidas. Com a utilização correta e constantedas métricas, é possível obter uma posição sobre a qualidade do sistema que foi estudado(SOMMERVILLE, 2011). Para tal, Ejiogu (1991) instrui atributos que são esperados parao correto funcionamento das métricas, tais como: ser de fácil entendimento, ter o objetivoclaro, ser condizente com relação ao que foi medido e não ser acoplada a linguagens deprogramação. As métricas de software são exemplificadas (PRESSMAN, 2011) em duasvertentes conhecidas como: Métricas de Produto e Métricas de Processo e Projeto.

2.1.1.1 Métricas de Produto

As métricas de produto ou métricas de previsão (SOMMERVILLE, 2011), sãoutilizadas para que o desenvolvedor, a partir da medição dos atributos internos, possa obterdados futuros sobre o comportamento do sistema que está sendo desenvolvido, evitandoassim grandes possíveis defeitos (PRESSMAN, 2011). Métricas dinâmicas e estáticas sãosubdivisões das métricas de produto, ambas diferem-se entre si a partir de como é realizadaa coleta, sendo, respectivamente, por meio da execução do programa e de representaçõesdo sistema.

O relacionamento das métricas e os atributos internos de qualidade na visão deSommerville (2011) são caracterizados da seguinte maneira:

Métricas dinâmicas ajudam a avaliar a eficiência e a confiabilidade deum programa. Métricas estáticas ajudam a avaliar a complexidade, acompreensibilidade e a manutenibilidade de um sistema ou componentesde um sistema de software. (SOMMERVILLE, 2011)

A Tabela 1 contém exemplos de métricas de produto.

Capítulo 2. Referenciais teóricos 17

Tabela 1 – Exemplos de métricas de produto

Métricas DescriçãoFan in/Fan out Relação entre chamadas de funções. Fan-

in é a quantidade de funções que cha-mam uma mesma função qualquer. Fan-out é o número de funções que determi-nada função chama.

Comprimento de código Tamanho do programa dado a partir daquantidade de linhas de código

Complexidade ciclomática Medida da complexidade de controle deum programa

Comprimento de identificadores Média obtida pelos comprimentos dosidentificadores

Profundidade de aninhamento condicional Medida do quão profundo as declarações“if’s” são

Índice Fog Média dos comprimentos das palavrasque existem nos documentos

Métodos ponderados por classe Quantidade de métodos existentes emcada classe pela complexidade damesma

Árvore de profundidade de herança Tamanho da profundidade da árvore deherança

Número de filhos Quantidade total de subclasses existen-tes em uma classe

Acoplamento entre classes Medida do acoplamento existente entreas classes

Resposta para uma classe Quantidade de métodos possíveis de se-rem executados a partir de uma classe

Falta de coesão em métodos Diferença entre os métodos com e sematributos compartilhados

Fonte: Sommerville (2011)

2.1.1.2 Métricas de Processo e Projeto

As métricas de processo têm impacto de longo prazo e seu objetivo é melhorar opróprio processo de desenvolvimento. As métricas de projeto muitas vezes contribuempara o desenvolvimento de métricas de processo.

Dentro das possibilidades de métricas existentes, há três moldes fundamentais paraas mesmas: número de ocorrências, tempo e recurso necessário (SOMMERVILLE, 2011).O número de ocorrências é a medição de quantas vezes determinada situação ocorreu,influenciando assim a qualidade do software. Tempo e recursos necessários são as medidasque relatam como as mudanças aplicadas estão surtindo efeito. Abaixo, na Tabela 2 épossível visualizar exemplos de métricas de processo e projeto.


Tabela 2 – Exemplos de métricas de processo e projeto

Métricas DescriçãoBurndown Quantidade de itens abertos no backlog

por tempo de sprintBurnup Quantidade de itens abertos no projeto

como um todoVelocidade Quantidade de estórias de usuários en-

tregues com sucesso em determinadosprint

Throughput Quantidade de estórias de usuários en-tregues com sucesso em uma semana

Densidade de defeitos Quantidade de defeitos existentes docódigo desenvolvido durante a sprint

Lead Time Tempo gasto entre a abertura do pedidoaté o trabalho estar disponível

Cycle Time Tempo total gasto no desenvolvimentoProblemas e Itens bloqueados Identificação dos riscos ao projeto

Fonte: Elaborada pelo autor

2.1.2 ISO 25010

A ISO (2011) define um modelo de qualidade do produto que é encarregado porditar quais atributos externos de qualidade são padronizados. Baseada na ISO/IEC 9126,a ISO 25010 possui 8 (oito) características que são:

• Funcionalidade: o sistema atua do jeito condizente com o que é esperado (ISO, 2011).

• Confiabilidade: atributo responsável por medir a probabilidade de falhas no sistema(KOSCIANSKI; SOARES, 2007).

• Usabilidade: o quão satisfatório e usual é o sistema de acordo com os usuários (ISO,2011).

• Manutenibilidade: característica que implica em mostrar o nível de dificuldadeaplicada ao sistema em relação a modificação do mesmo (KOSCIANSKI; SOARES,2007).

• Portabilidade: atributo que indica a funcionalidade do sistema independentementeda plataforma (KOSCIANSKI; SOARES, 2007).

• Segurança: qualidade em que o sistema protege as informações dos usuários, direcio-nando as mesmas apenas para pessoas autorizadas (ISO, 2011).

• Compatibilidade: atributo em que a partir da intervenção de outros componentes, osistema continua a exercer a sua funcionalidade (SOMMERVILLE, 2011).


• Eficiência e desempenho: comportamento do sistema em relação ao tempo e autilização de recursos (PRESSMAN, 2011).

2.1.3 Programa MPS.Br

O MPS.Br é um programa baseado na melhoria de processo de software e deserviços (SOFTEX, 2016). Sob a coordenadoria da Softex, o MPS.Br teve início em 2003tendo como base as normas e modelos internacionais: ISO, CMMI e P-CMM. A criaçãode um modelo de qualidade do Brasil se fez necessária em virtude das empresas brasileirasvivenciarem uma realidade diferente dos moldes internacionais. A ideia de criação demais níveis tornou este programa mais acessível, pois é menos custoso de se alcançarprincipalmente os níveis menores (CORGOSINHO, 2006). O programa tem como objetivoacarretar um aumento considerável na melhoria de processo das empresas e assim fomentara área de desenvolvimento de software no Brasil (SOFTEX, 2016).

2.1.3.1 Modelo de Referência MPS para Software (MPS-SW)

O MPS-SW, como o Guia Geral do MPS-SW (SOFTEX, 2016) expressa, é res-ponsável por executar, no processo e produto, as práticas, ferramentas e métodos quea engenharia de software certifica. Isso deve ser feito de acordo com a situação real daempresa para que seja possível gerar um aperfeiçoamento no serviço. Atualmente podemser encontradas 128 empresas com avaliação em dia referente ao modelo MPS-SW. Segundoa Softex, nos 14 anos de existência do programa foram avaliadas 690 empresas no Brasil.O modelo, como descrito no Guia Geral (SOFTEX, 2016), é segmentado por sete níveishierárquicos de maturidade que proporcionam um avanço gradativo na melhoria, com ajunção de processos e capacidades do mesmo.

Os níveis, que podem ser visualizados na Tabela 3, possuem as propriedadesacumulativas logo, a partir do momento que ocorre uma mudança no nível de maturidade,todos os processos previamente implementados devem se adequar para que se tornemcompatíveis com o que é exigido no nível atual.


Tabela 3 – Níveis de maturidade do MPS-SWNível Nome ProcessosA Em Otimização -B Gerenciado Quantitativamente -C Definido DRU – Desenvolvimento para Reutiliza-

ção; GDE – Gerência de Decisões; GRI– Gerência de Riscos

D Largamente Definido DRE - Desenvolvimento de Requisitos;ITP -Integração do Produto; PCP - Pro-jeto e Construção do Produto; VAL –Validação; VER - Verificação

E Parcialmente Definido AMP - Avaliação e Melhoria do ProcessoOrganizacional; DFP -Definição do Pro-cesso Organizacional; GRH - Gerênciade Recursos Humanos; GRU - Gerênciade Reutilização

F Gerenciado AQU – Aquisição; GCO - Gerência deConfiguração; GQA -Garantia da Qua-lidade; MED -Medição

G Parcialmente Gerenciado GPR - Gerência de Projetos; GRE -Gerência de Requisitos

Fonte: SOFTEX (2016)

No Guia Geral MPS-SW (SOFTEX, 2016) é informado que cada nível possuiatributos de processos que são os responsáveis por descrever e constatar que a capacidaderequerida foi atendida. O foco do programa encontra-se nos processos pela convicção queproblemas nos mesmos geram produtos defeituosos. O contrário, ou seja, o fato de queprodutos defeituosos são gerados pelo processo com problema, não pode ser consideradototalmente verdadeiro uma vez que o produto também depende de fatores externos, comopor exemplo o usuário ou o desenvolvedor (SOMMERVILLE, 2011).

2.2 Trabalhos CorrelatosO método denominado métricas de software é o tema principal do trabalho de

Magalhães e Rodrigues (2016). A partir da definição do que esta técnica implica, apesquisa utilizou-se do estudo das métricas de Linhas de Código (LOC) e Ponto de Função(PF) para interligar métricas com a qualidade do produto. A escolha apenas destas duasmétricas se deu pelo fato de possuírem uma maior utilização nas empresas. Após todo oprocedimento de aplicação das métricas de software, os autores obtiveram como conclusãoque a utilização das métricas resulta em uma diminuição dos defeitos no processo, o quenão implica assegurar um produto com qualidade. O trabalho apresentado ao longo dessa


pesquisa utiliza-se, assim como neste trabalho correlato, de conceitos acerca de métricasde software e a influência das mesmas no resultado final requerido.

O trabalho de Gouveia et al. (2016) informa, a partir das empresas que possuemavaliação nível F no programa MPS.BR, quais as métricas ágeis mais utilizadas e comoé materializado o processo das mesmas. Utilizando a metodologia de surveys aplicadospara os representantes das empresas, avaliadores e implementadores do MPS.Br, obteve-sea indicação das seguintes métricas ágeis: Burndown, Velocidade, Densidade de Defeitos,Lead Time (Tempo de aprovisionamento), Cycle Time (Tempo de ciclo), Problemas e ItensBloqueados, Número Acumulado de Defeitos e Running Tested Features (Funcionamentodo recurso testado). O trabalho (GOUVEIA et al., 2016) apresenta semelhança com oqual está sendo desenvolvido a partir da necessidade de mapear o cenário brasileiro emrelação às empresas avaliadas no modelo de referência MPS-SW, mas a atual pesquisausará das métricas mais indicadas pelas empresas em nível geral, não sendo direcionadopara o nível F do modelo, e também realizará o estudo das métricas de produto.

A pesquisa de Almendra et al. (2014) estipula quais os requisitos funcionais neces-sários em determinados ambientes de apoio, que são ferramentas para coleta e análise dasmétricas, para que as empresas avaliadas no nível G do MPS-SW consigam um melhorsuporte. O trabalho evidencia a necessidade de que, de acordo com os resultados esperados,a escolha do ambiente de apoio seja exata pois assim os resultados apresentam maisfidelidade. A presente pesquisa assemelha-se ao trabalho explicado anteriormente poisvisa relacionar o ambiente de apoio com os resultados esperados a partir das métricas desoftware utilizadas.

A ligação entre a utilização de métricas com os atributos externos de qualidadedesejados é avaliada em Couto, Valente e Bigonha (2011). Para tal pesquisa foi utilizadoem cinco sistemas o estudo da causalidade e métricas de código-fonte. O resultado obtidofoi que avaliando os sistemas como um todo, os defeitos reportados pelas métricas emalgumas classes não influenciavam naqueles que foram citados pelos usuários, ou seja, asmesmas podem não apresentar defeitos imediatamente. Levando em consideração apenasclasses que já deram defeitos, observou-se que os resultados analisados exibem relação decausalidade com os valores baixos em métricas de código-fonte. A existência de valoresbaixos demonstra um efeito no aumento dos defeitos. A pesquisa realizada possui umdos pontos essenciais para o trabalho que está em desenvolvimento, pois ao estruturar ocenário das empresas avaliadas é levado em consideração se as métricas que são utilizadascondizem com os atributos de qualidade desejados.

22

3 Metodologia

Figura 1 – Metodologia utilizada


A metodologia adotada para este trabalho foi dividida em 4 etapas, como mostradona Figura 1. A primeira foi a escolha das empresas que estariam aptas a responder apesquisa. A segunda deu-se por determinar o projeto e pesquisa do survey. A terceira foi arealização da aplicação dos surveys nas empresas escolhidas e por último, a realização daconsolidação dos resultados.

Para a escolha das empresas foi levado em consideração aquelas que possuema avaliação em dia do modelo de referência MPS-SW. A escolha por empresas apenasvoltadas para a área de software se deu pelo MPS ser um programa consolidado no Brasil,com grande respeito na área de qualidade e o de maior avaliações no Brasil. O contato das128 empresas brasileiras que atualmente estão com a avaliação em vigência fora obtido nopróprio site da Softex.

A pesquisa em forma de survey é um tipo quantitativo que é utilizado quandodeseja-se obter dados referentes a determinado grupo sobre algum assunto (FREITASet al., 2000). A utilização da mesma se dá principalmente por questionários e de acordocom (PINSONNEAULT; KRAEMER, 1993) o formato survey pode ter como pressupostoser: explanatório, em que são testadas hipóteses; exploratório, em que o foco é um maiorconhecimento sobre determinado tema; e descritivo, onde estabelecer características epadrões são o ponto principal.

O tipo de survey abrangido neste trabalho é o descritivo, no qual foi realizado umquestionário online através da ferramenta Google Docs que ficou disponível para respostasdurante cinco meses, entre setembro de 2017 e janeiro de 2018. O Apêndice A, ApêndiceB e Apêndice C referenciam, respectivamente, o modelo do questionário aplicado para osrepresentantes das empresas atualmente avaliadas no MPS-SW, os implementadores e osavaliadores do MPSW-SW. O questionário foi disponibilizado não apenas às empresas,mas também aos avaliadores e implementadores do MPS-Br para que fosse coletado o

Capítulo 3. Metodologia 23

maior número possivel de características referentes ao processo do MPS-SW nas empresasfossem levantadas. Os contatos referentes aos implementadores e avaliadores tambémforam retirados do site da Softex.

A autora entrou em contato com as empresas, para a aplicação dos questionários,através de e-mail e telefonemas pois, por se tratar de uma pesquisa de âmbito nacional, apossibilidade de uma aplicação pessoal é restrita.

A consolidação dos resultados se deu através da análise e classificação das respostasrecebidas. A área de atuação de cada empresa, tal como os atributos internos e externosforam extraídos e catalogados, resultando no estudo das mesmas e num modelo de qualidadecomo produto final.

24

4 Resultados

Classificando os dados colhidos após quatro meses de coleta tem-se um total de48 respostas associadas ao survey aplicado, sendo a quantia de 37 referente às empresasavaliadas pelo MPS-SW, seis associadas aos avaliadores e cinco pertencentes aos implemen-tadores do modelo de referência MPS-SW. O questionário foi respondido por representantesque, a partir do contato com companhias, nomearam-se como encarregados da equipe desoftware, o que é necessário para que tenha um conhecimento amplo do funcionamentodos processos e produto final podendo assim, representar efetivamente a empresa comrespostas que condizem com a realidade.

Os maiores níveis de maturidade do MPS-SW informados foram os níveis F e Gsendo que cada um obteve 15 respostas, ou seja 40.5%. Logo após temos o nível C comcinco respostas (13,5%) e os níveis A e E com uma empresa cada. Apesar do processo demedição estar presente a partir do nível F, as empresas que possuem o nível G informaramjá seguir determinadas métricas.

Ao questionar os domínios dos projetos de software, entre as mais escolhidas obteve-se em primeiro, com 11 empresas no total, o ramo de “PDI (Pesquisa, Desenvolvimento eInovação)”. Em seguida os “Governamentais” com o total de 10 companhias. Os domíniosde “Gestão Financeira”, “Controle de Estoque”, “E-commerce” e “Sistema integrado degestão empresarial” estão presentes em oito, sete, seis e cinco empresas, respectivamente.

A Figura 2 refere-se a um gráfico de barras que contém as métricas de produto nasquais as empresas exercem um maior foco no monitoramento.

Figura 2 – Métricas de produto utilizadas pelas empresas avaliadas no MPS-SW


Capítulo 4. Resultados 25

O gráfico exibido na Figura 2 demonstra o atributo interno “Comprimento de código”como métrica de produto mais monitorada pelas empresas. Isso ocorre devido à junçãoda confiabilidade da métrica e facilidade de medição quando são utilizadas ferramentasautomatizadas para realizar a coleta. Em segundo aparece a “Complexidade ciclomática”que, de acordo com Pressman (2011), possui grande importância por mostrar a quantidadede caminhos percorridos pelo código do produto, sendo que cada caminho é responsávelpor apresentar uma nova possibilidade ao software aumentando a sua complexidade. O“Comprimento de identificadores” é o terceiro mais utilizado e mostra que quanto melhordetalhada a variável mais fácil será no entendimento da sua função.

Além das métricas expostas na Figura 2, outras métricas foram identificadas apartir da categoria “Outros”. São métricas que envolve atributos de medições relacionadasàs conformidades dos requisitos implementados, a qualidade de uso, o tempo de respostadas funcionalidades diante da interação com os usuários ou empresas que não fazem usodessas métricas.

Apesar da medição e análise das métricas de produto não serem cobradas comoum resultado esperado no modelo de referência do MPS-Br, a escolha de medição dessasmétricas pode ter sido influenciada por 80% das empresas que foi a quantidade total deempresas que disseram utilizar determinados ambientes de apoio. Isso se dá pelo fatodessas empresas utilizarem de diversas ferramentas para a coleta, sendo que as métricas deproduto as vezes são coletadas de forma automatizada. O RedMine, Sonar e ferramentasinternas não especificadas foram as mais citadas para realizar a coleta e análise das métricasde produto.

A Figura 3 corresponde às métricas de processos mais acompanhadas pelas empresas.

Figura 3 – Métricas de processo utilizadas pelas empresas avaliadas no MPS-SW



De acordo com o gráfico existente na Figura 3 é possível verificar que a métrica deprocesso mais utilizada entre as empresas é o “BurnDown”. A utilização deste atributo é degrande importância devido à necessidade de verificar o que está sendo realizado ao decorrerdos dias nas companhias e, consequentemente, obter-se uma visão geral do andamento doprocesso, além da praticidade de coleta. O atributo “Número acumulado de defeitos”, queé a segunda métrica em evidência, mede a quantidade de defeitos encontrados durante umperíodo de tempo estipulado (GOUVEIA et al., 2016), fazendo com que os responsáveispelo procedimento consigam ponderar entre o que é aceitável e o que está acima. Osatributos “Cycle Time”, “Densidade de defeitos”, “Velocidade”, “Lead Time”, “BurnUp”,“Cumulative Flow Diagram”, “Running Tested Features”, “Problemas e Itens Bloqueados”,“Throughput” e “Outros” estão respectivamente na ordem da utilização das métricas. Acategoria “Outros” englobou medições relacionadas a produtividade e que realizam o índicede desempenho entre prazo e custo.

Os representantes das empresas informaram no questionário que a coleta e análisedas métricas de processo se dão em todas as etapas da concepção do produto. A maioriadas empresas utiliza diversas ferramentas, como por exemplo: RedMine, Microsoft Excel,Team Foundation Server e outras internas. Os responsáveis por manipular as métricas sãoos gerentes de projeto ou o setor de qualidade.

Os resultados mostram que as métricas de processo utilizadas são, na sua maioria,de característica ágil apesar do modelo de processo ágil não conduzir para o uso dedocumentações, o que parte do oposto desejado pelo modelo MPS. Aproximadamente 87%das empresas fazem uso de algum modo deste processo, sendo 56,8% a utilização híbrida e29,7% apenas ágil. Este fato ocorre pela necessidade das empresas, de pequeno ou médioporte, não consumirem muito tempo ou custo nas medições dos seus processos e mesmoassim conseguirem realizar um controle referente a qualidade do desenvolvimento. A partirda documentação correta dessas métricas, de acordo com o que é esperado pelo MPS, épossível que a união do modelo MPS-SW e ágil funcione e agregue valor para a empresa.

A Figura 4 esboça o gráfico em barras referente aos atributos externos desejadospelas empresas.


Figura 4 – Atributos externos desejados pelas empresas avaliadas no MPS-SW


O atributo externo mais desejado de acordo com a Figura 4 é a “Usabilidade”,que demonstra a preocupação que as empresas possuem do seu produto ser entendido eutilizado pelo usuário. Esse fato justifica-se uma vez que, se o funcionamento do softwarenão é aprendido, o mesmo se torna obsoleto. O atributo de “Confiabilidade”, segundolugar em relação a preferência, demonstra que um sistema sem falhas possibilita que ousuário consiga empregar todo o potencial do mesmo em qualquer situação. A “Segurança”,escolhida no terceiro lugar como desejada, é um dos temas mais citados atualmente pelanecessidade do usuário ter seus dados seguros em um espaço completamente expostocomo a internet. A “Manutenibilidade” e “Eficiência e Desempenho” estão mais ligadasaos desenvolvedores do sistema do que cliente final, ficaram empatadas em quarto lugar.Os atributos “Adequação Funcional”, “Portabilidade” e “Compatibilidade” obtiveram,respectivamente, o quinto, sexto e sétimo lugar na preferência das empresas.

Ao verificar os atributos externos desejados e compará-los com quais ramos deatuação as empresas se dedicam, foi possível verificar um padrão quando o domínio doprojeto de software era comum entre as companhias, assim como uma diferença nosatributos principais de acordo com as mudanças de áreas. A diferença entre as principaisescolhas se dá por cada funcionalidade que se é esperada e necessária em determinada área,motivando assim diferentes focos para o desenvolvimento. Um exemplo são os softwares“Governamentais” que, por serem do governo, entende-se possuírem como característicasbásicas: funcionamento independentemente da localidade (Confiabilidade), segurança emrelação aos dados existentes (Segurança) e fácil aprendizado para todos (Usabilidade),uma vez que são vários os usuários.

As métricas de processo escolhidas, sendo de caráter ágil, condizem com a “Usabili-


dade” ser o atributo externo mais desejado, pois o modelo ágil tem o usuário como umparticipante da equipe de desenvolvimento e é indispensável que primeiramente, o mesmose sinta extremamente satisfeito com o produto final. A Figura 5, exibe uma relação entreos atributos internos e externos, ou seja, um modelo de qualidade.

Figura 5 – Modelo de qualidade das empresas vigentes no MPS-SW


Estudando o modelo da Figura 5 é notório que a maioria das métricas utilizadas sãoreferentes a “Manutenibilidade”, apesar desta estar em quarto lugar quanto a preferência dasempresas. Como dito anteriormente, isso pode estar relacionado às ferramentas utilizadaspara a coleta e análise das métricas, o que evidencia a utilização mas a falta de preocupaçãoinicial com os atributos. A “Confiabilidade” foi a segunda mais escolhida como atributoexterno desejado e em quantidade de métricas relacionadas, essa escolha indica um possívelacerto das empresas em relação a quais métricas utilizar de acordo com qual atributo dequalidade é desejado.

A categoria “Outras” nos atributos internos foi a mais citada por incluir métricasrelacionadas a “Usabilidade”, “Compatibilidade”, “Eficiência e Desempenho”, “AdequaçãoFuncional”, “Portabilidade” e “Segurança”. Para um melhor resultado em relação a “Usa-bilidade” é aconselhável que as empresas não apenas realizem uma avaliação em relação asua usabilidade, como também estudem análise e projeto de interfaces, em que é necessárioverificar quais usuários são o foco do sistema, quais tarefas vão ser realizadas e como estasserão exibidas.

29

5 Considerações Finais

5.1 ConclusãoEste trabalho exibiu um modelo de qualidade baseado nas empresas brasileiras que

possuem a avaliação em dia no modelo de referência MPS-SW. O modelo de qualidade é orelacionamento entre os atributos internos utilizados e os externos desejados. Percebeu-sepela análise dos resultados que a medição de métricas de produto apesar de não obrigatóriaé realizada e resulta na Manutenibilidade como o atributo externo com o maior número deligações aos atributos internos. As métricas de processos mais utilizadas são referentes aométodo ágil devido ao fato de este ser o modelo mais utilizado pelas empresas pesquisadas,seja sozinho ou em junção com o tradicional. O objetivo da maioria das empresas, pelainfluência dos métodos ágeis, é manter o foco no usuário e assim ter um produto comusabilidade. Este atributo externo é o responsável por quão usual e de fácil aprendizado oproduto é para o usuário. Para um melhor alcance da usabilidade é aconselhável uma maiorutilização de métricas referentes ao projeto de interface. Também foi possível verificar quea utilização das métricas de processo se dá em maior escala devido a qualidade do processoser o objetivo principal no programa MPS.Br. Isso ocorre pelo princípio de que o processoé um dos responsáveis pela qualidade do produto. Para finalizar, foi visto que a coleta eanálise das métricas se dão pela utilização de ferramentas que existem no mercado, comoo Sonar ou de próprio desenvolvimento.

5.2 Limitações e trabalhos futurosA principal limitação encontrada no decorrer desta pesquisa foi a omissão das

empresas em relação a resposta do questionário enviado. Outro obstáculo foi a dificuldadeem obter e-mails válidos dos contatos via telefone pois, em uma população de 128 empresas,apenas 37 responderam, ou seja, 29% aproximadamente. Um possível contato pessoalpoderia aumentar a quantidade de respostas mas torna-se inviável devido ao fato de apesquisa abranger várias localidades do país. Algumas dúvidas da parte dos responsáveissurgiram durante o preenchimento do questionário, mas o contato, pelo e-mail e telefone,foi rapidamente realizado e as dúvidas sanadas. O escopo inicial do questionário possuia aparticipação dos avaliadores e implementadores do MPS-SW, mas devido ao não retorno damaioria e a desatualização dos dados no site da Softex, os resultados não foram analisadosnesse trabalho.

Para a realização de trabalhos futuros é interessante tentar realizar uma entrevistapessoalmente com os responsáveis das empresas para que assim um maior número de dados

Capítulo 5. Considerações Finais 30

seja obtido, acrescentado e a análise mais completa. A pesquisa pode ser incrementadacom informações referentes aos avaliadores e implementadores do modelo de referênciaMPS-SW.

31

Referências

ALMENDRA, C. C. et al. Requisitos funcionais para ambientes de apoio ao nível g domps. br. X Simpósio Brasileiro de Sistemas de Informação. Londrina, PR, 2014. Citadona página 21.

CORGOSINHO, C. C. Como iniciar e acompanhar um programa de implantação do mps.br. ProQualiti–Qualidade na Produção de Software, p. 23, 2006. Citado 2 vezes naspáginas 14 e 19.

COUTO, C.; VALENTE, M. T.; BIGONHA, R. da S. Avaliaç ao de causalidade entremétricas de qualidade interna e defeitos. Simpósio Brasileiro de Qualidade de Software(SBQS), 2011. Citado na página 21.

EJIOGU, L. Software Engineering with Formal Metrics. [S.l.]: QED, 1991. Citado napágina 16.

FREITAS, H. et al. O método de pesquisa survey. Revista de Administra&ccdeil; ão daUniversidade de São Paulo, v. 35, n. 3, 2000. Citado na página 22.

GOUVEIA, V. et al. Avaliando as métricas ágeis utilizadas pelas empresas certificadas nonível f do mps. br. Workshop Anul do MPS.Br (WAMPS), 2016. Citado 2 vezes naspáginas 21 e 26.

ISO, O. I. de N. ISO/IEC 25010: 2011 Systems and Software Engineering-Systems andSoftware Quality Requirements and Evaluation (SQuaRE)-System and Software QualityModels. [S.l.]: ISO, 2011. Citado na página 18.

KOSCIANSKI, A.; SOARES, M. dos S. Qualidade de software:aprenda as metodologias etécnicas mais modernas para o desenvolvimento de software. 2. ed. São Paulo: Novatec,2007. ISBN ISBN: 978-85-7522-112-9. Citado 2 vezes nas páginas 14 e 18.

MAGALHÃES, E. J.; RODRIGUES, J. do C. Análise comparativo do uso de métricascomo fator de qualidade no desenvolvimento de software. Simpósio Unificado do Curso deSistemas de Informação da UEG, 2016. Citado na página 20.

Microsoft Excel. 2018. Disponível em: <https://products.office.com/pt-br/excel>. Citadona página 26.

PINSONNEAULT, A.; KRAEMER, K. Survey research methodology in managementinformation systems: an assessment. Journal of management information systems, Taylor& Francis, v. 10, n. 2, p. 75–105, 1993. Citado na página 22.

PRESSMAN, R. S. Engenharia de Software: uma abordagem profissional. 7. ed. PortoAlegre: AMGH, 2011. Tradução de Ariovaldo Griesi. Revisão Técnica de Reginal Arakaki,Julio Arakaki e Renato Manzan de Andrade. ISBN ISBN: 978-85-8055-044-3. Citado 3vezes nas páginas 16, 19 e 25.

RedMine. 2018. Disponível em: <https://www.redmine.org/>. Citado 2 vezes naspáginas 25 e 26.

https://products.office.com/pt-br/excel

https://www.redmine.org/

Referências 32

SOFTEX. Guia Geral MPS de Software. [S.l.]: SOFTEX, 2016. Citado 3 vezes naspáginas 14, 19 e 20.

Softex. 2018. Disponível em: <https://www.softex.br/mpsbr/>. Citado 4 vezes naspáginas 19, 22, 23 e 29.

SOMMERVILLE, I. Engenharia de Software. 9. ed. São Paulo: Pearson Prentice Hall,2011. Tradução de Ivan Bosnic e Kalinka G. de O. Gonçalves. Revisão Técnica de KechiHirama. ISBN ISBN: 978-85-7936-108-1. Citado 5 vezes nas páginas 14, 16, 17, 18 e 20.

Sonar. 2018. Disponível em: <https://www.sonarqube.org/>. Citado 2 vezes nas páginas25 e 29.

Team Foundation Server. 2018. Disponível em: <https://www.visualstudio.com/tfs>.Citado na página 26.

https://www.softex.br/mpsbr/

https://www.sonarqube.org/

https://www.visualstudio.com/tfs

33

APÊNDICE A – Questionário aosrepresentantes das empresas atualmente

avaliadas no MPS-SW

Esse questionário é voltado para os representantes das empresas certificadas noMR-MPS-SW.

1. Nome da empresa:

Informe o nome da empresa na qual você representa sendo esta, a base para asrespostas desse questionário.

2. Estado em que a empresa está situada:

3. Nível da empresa no MR-MPS-SW:

() A

() B

() C

() D

() E

() F

() G

4. Informe qual o tipo de modelo de processo utilizado na empresa:

() Tradicional

() Ágil

() Híbrido

5. Quais eram os domínios dos projetos de software?

() E-commerce

() Embarcado

() Governamental

() PDI - Pesquisa, Desenvolvimento e Inovação

() Médico

APÊNDICE A. Questionário aos representantes das empresas atualmente avaliadas no MPS-SW 34

() Bancário

() Geoprocessamento

() Mineração

() Agricultura

() Pecuária

() Gestão Financeira

() Controle de Estoque

6. Informe quais as métricas de produto mais monitoradas pela empresa naimplementação do MPS-SW:

Métricas de produto são medidas quantitativas utilizadas para prever qual será onível de qualidade do produto.

() Fan in/Fan out - Fan-in é o número de funções que chamam outra função X.Fan-out é o número de funções que são chamadas pela função X.

() Comprimento de código - Medida do tamanho de um programa.

() Complexidade ciclomática - Medida da complexidade de controle de um programa.

() Comprimento de identificadores - Medido do comprimento médios dos identifica-dores.

() Profundidade de aninhamento condicional - Medida da profundidade de declaraçõesif.

() Índice Fog - Medida do comprimento médio de palavras em documentos.

() Métodos ponderados pro classe - Número de métodos em cada classe pela comple-xidade de cada.

() Árvore de profundidade de herança - Medida da profundidade na árvore de herança.

() Número de filhos - Medida do número de subclasses imediatas em uma classe.

() Acoplamento entre classes - Medida de quanto acoplamento existe entre as classes.

() Resposta para uma classe - Medida do número de métodos que podem ser execu-tados a partir de uma resposta.

() Falta de coesão em métodos - Diferença entre o número de pares de métodos sematributos compartilhados para os que possuem atributos compartilhados.

() Outras

7. Informe como se deu a coleta e analise das métricas de produto:

Qual ferramenta foi utilizada, em que etapa foi realizada a coleta, pessoas partici-pantes, duração da coleta, entre outros.


8. Informe quais as métricas de processo mais monitoradas pela empresa naimplementação do MPS-SW:

Métricas de processo são medidas adotadas ao longo do desenvolvimento de umproduto visando a melhora da qualidade do mesmo.

() Burndown - Representação da quantidade de itens de backlog em aberto por tempode sprint.

() Burnup - Representação do projeto como um todo. não apenas dividido em sprints.

() Velocidade - Soma das estimativas das estórias de usuários entregues com sucessoem uma sprint.

() Throughput - Soma das estimativas das estórias de usuários entregues com sucessopor semana.

() Densidade de defeitos - Numero de defeitos identificados no codigo que foi produzidodurante a sprint.

() Lead Time - Tempo de abertura do pedido até a disponibilização do trabalhorealizado.

() Cycle Time - Tempo do inicio do desenvolvimento da funcionalidade até finalizar.

() Problemas e Itens Bloqueados - Representação gráfica dos impedimentos reportadospara identificar riscos ao projeto.

() Numero acumulado de defeitos - Total de defeitos encontrados em determinadoperíodo.

() Running Tested Features - Numero de funcionalidades que foram disponibilizadascom sucesso para o cliente.

() Cumulative Flow Diagram (CFD) - Diagrama que exibe o status do desenvolvimentodo produto: o que tem que fazer, o que está sendo feito e o que já foi realizado.

() Outra opção.

9. Informe como se deu a coleta e análise das métricas do processo:


10. Indique quais atributos externos de qualidade são mais desejados na or-ganização:

Atributos de qualidade são particularidades que fazem parte da qualidade de umsoftware.

() Confiabilidade.

() Segurança.


() Manutenibilidade.

() Portabilidade.

() Adequação Funcional.

() Eficiência e Desempenho.

() Compatibilidade.

() Usabilidade.

37

APÊNDICE B – Questionário aosimplementadores do MPS-SW

Esse questionário é voltado para os implementadores certificados no MR-MPS-SW.

1. Informe como foi realizada sua participação na implementação junto coma empresa:

Quantidade de visitas, tempo médio das visitas, etc.

2. Informe quais as dificuldades mais perceptíveis na implementação doMPS-SW:

3. Na empresa que você está considerando nas respostas deste questionário,indique o nível pretendido do MR-MPS-SW:

() A

() B

() C

() D

() E

() F

() G

4. Quais eram os domínios dos projetos de software na empresa implemen-tada?

() E-commerce

() Embarcado

() Governamental


() Médico

() Bancário

() Geoprocessamento

() Mineração

() Agricultura

APÊNDICE B. Questionário aos implementadores do MPS-SW 38

() Pecuária



5. Informe quais as métricas de produto mais monitoradas pela empresaque você implementou o MPS-SW:














() Outras

6. Informe qual era o meio geral utilizado para a coleta e analise das métricasde produto na implementação do MPS-SW:

Qual ferramenta foi utilizada, em que etapa foi realizada a coleta, pessoas partici-pantes, duração da coleta, entre outros

7. Informe quais as métricas de processo mais monitoradas pela empresaque você implementou o MPS-SW:














() Outra opção.

8. Informe qual era o meio geral para a coleta e analise das métricas deprocesso na implementação do MPS-SW:


9. Informe quais atributos externos de qualidade eram desejados pela em-presa que você prestou apoio na implementação do MPS-SW:


() Confiabilidade.

() Segurança.



() Portabilidade.



() Compatibilidade.

() Usabilidade.

41

APÊNDICE C – Questionário aosavaliadores do MPS-SW

Esse questionário é voltado para os avaliadores certificadas no MR-MPS-SW.

1. Informe a sua opinião sobre o método de avaliação do MPS-SW

() Ótimo

() Bom

() Regular

() Ruim

() Péssimo

2. A partir da resposta anterior, informe quais pontos da avaliação poderiamser melhorados:

3. Informe quais os problemas mais perceptíveis na empresa que foi avaliadano modelo MPS-SW:

4. Na empresa que você está considerando nesta avaliação, indique o nívelpretendido do MR-MPS-SW:

() A

() B

() C

() D

() E

() F

() G

5. Quais eram os domínios dos projetos de software na empresa avaliada?

() E-commerce

() Embarcado

() Governamental


() Médico

APÊNDICE C. Questionário aos avaliadores do MPS-SW 42

() Bancário

() Geoprocessamento

() Mineração

() Agricultura

() Pecuária



6. Informe quais as métricas de produto mais monitoradas pela empresaavaliada no MPS-SW:














() Outras

7. Informe como era realizada a coleta e analise das métricas de produto naimplementação do MPS-SW na empresa:

Qual ferramenta foi utilizada, em que etapa foi realizada a coleta, pessoas partici-pantes, duração da coleta, entre outros


8. Informe quais as métricas de processo mais monitoradas pela empresaavaliada no MPS-SW:













() Outra opção.

9. Informe como era realizada a coleta e analise das métricas de processona empresa avaliada no MPS-SW:


10. Informe quais atributos externos de qualidade eram desejados pela em-presa que você avaliou no MPS-SW:


() Confiabilidade.


() Segurança.


() Portabilidade.



() Compatibilidade.

() Usabilidade.

Estimandoatributosdequalidadede software ... · Catalogação: [email protected] M538e Mendes,...

Documents

Transcript of Estimandoatributosdequalidadede software ... · Catalogação: [email protected] M538e Mendes,...