ferramenta para avaiação de aderência de softwares em processos

Universidade do Estado de Santa Catarina

Centro de Educação Superior do Alto Vale do Itajaí

FERRAMENTA PARA AVALIAÇÃO DE ADERÊNCIA DE

SOFTWARES EM PROCESSOS DE AQUISIÇÕES DE

SOFTWARE BASEADA NA NORMA NBR ISO/IEC 9126-1

Robson Ricardo Giacomozzi1, Carlos Alberto Barth

2

Pós-Graduação em Engenharia de Software – PGES

Centro de Educação Superior do Alto Vale do Itajaí – CEAVI

Universidade do Estado de Santa Catarina - UDESC [email protected],

[email protected]

Resumo

Nos processos de aquisição de Software e Serviços Correlatos (S&SC), comumente têm-se a fase

de seleção de fornecedores, que identifica e avalia os fornecedores e seus produtos. Muitos

projetos de aquisição S&SC estão falhando, pois estão se tornando operações complexas, além

de serem difíceis para organizações com pouca experiência nas disciplinas da Engenharia de

Software. Este artigo apresenta o desenvolvimento de uma ferramenta web para apoiar os

processos de aquisição de software, através da avaliação de aderência de software baseado na

norma NBR ISO/IEC 9126-1. Essa norma estabelece características e requisitos para qualidade

de um produto de software, que juntamente com uma forma de medição apropriada, fornece

atributos para avaliar tecnicamente os softwares. A ferramenta se torna relevante por possibilitar

o gerenciamento dos requisitos e fornecer um método simples e eficaz de avaliação. Ao longo

deste artigo serão demonstradas as fundamentações teóricas, trabalhos correlatos, o processo

proposto para avaliação de aderência de softwares e o desenvolvimento da ferramenta.

Palavras-chave: NBR ISO/IEC 9126-1. Aquisição Software. Qualidade de Software.

Abstract

In the process of acquisition of Software and Related Services (S&SC), commonly have to

supplier selection phase, which identifies and evaluates the vendors and their products. Many S

& SC acquisition projects are failing because they are becoming complex operations, and are

difficult for organizations with little experience in the disciplines of software engineering. This

paper presents the development of a web tool to support software acquisition processes through

software compliance assessment based on the standard NBR ISO/IEC 9126-1. This standard

establishes requirements for features and quality of a software product, which along with a form

of proper measurement, provides attributes to technically evaluate the software. The tool is

relevant because it allows the management of requirements and provides a simple and effective

method of assessment. Throughout this article will be demonstrated theoretical foundations,

related work, the proposed process for software compliance assessment and development tool.

Keywords: NBR ISO/IEC 9126-1. Software Acquisition. Software Quality.

1. Introdução

Sabe-se que a terceirização de S&SC – que inclui as atividades de contratação e gestão do

processo de aquisição – é uma tarefa complexa e necessária para as organizações, principalmente

na identificação dos requisitos necessários ao desenvolvimento de software e às condições

envolvidas na contratação como, a qualidade esperada e gestão de mudanças, entre outros

aspectos (MIRANDA, 2009).

Segundo Jobs (2009), algumas empresas terceirizam todo o processo de desenvolvimento e

ficam apenas com a gestão. Outras empresas ficam com a elaboração e a implantação e

terceirizam a construção. Com o aumento no volume em aquisição de software na última década,



a escolha de um produto que auxilie na condução dos negócios traz sempre muita preocupação

para as empresas.

Uma aquisição de S&SC acontece quando uma empresa (cliente) contrata externamente toda

ou parte das atividades de desenvolvimento do software em outra empresa (fornecedor) com

níveis de acordo de remuneração (KHAN et al., 2008).

De acordo com Nunes (2011), muitos projetos de aquisição estão falhando, pois estão se

tornando operações complexas, abrangendo vários sistemas e processos, e representa uma grande

transferência de ativos, funções e pessoas que estão sujeitas às regulamentações do país do

fornecedor. O MPS.BR (SOFTEX, 2013) aponta como principais razões de falhas nesses

projetos os problemas no gerenciamento, definições incompletas de requisitos, seleção

inadequada de fornecedor e de processo de contratação, procedimento de seleção de tecnologia

inadequado, falta de controle de mudança dos requisitos, falta de integração entre os processos

de aquisição e de desenvolvimento e também por deficiência no processo de desenvolvimento,

entre outros aspectos. SOFTEX (2013) complementa ainda que a definição de um processo de

aquisição minimiza riscos que podem comprometer os resultados esperados, como o não

cumprimento de prazos, a falta de qualidade no produto adquirido, a falta de compatibilidade do

produto adquirido com a arquitetura tecnológica definida, as dificuldades de integração e os

problemas de suporte.

Dentre os principais modelos, práticas e processos relevantes que são utilizados em todo o

mundo para resolver os problemas na aquisição de S&SC, têm-se as normas ISO 12207

(equivalente a NBR ISO/IEC 12207, aqui no Brasil) e IEEE STD 1062:1998; e os modelos de

maturidade CMMI para Aquisição (CMMI-ACQ) e o MPS.BR - Guia de Aquisição. De acordo

com SOFTEX (2013), os processos de aquisição garantem, entre outros pontos, que o fornecedor

selecionado seja capaz de conduzir o projeto dentro do orçamento e atender as exigências

combinadas (satisfazer a necessidade expressa pelo cliente).

Entretanto, segundo Furtado (2014), a implantação desses processos é dificultosa para

organizações com pouca ou nenhuma experiência nas disciplinas da Engenharia de Software. É

comum, em pequenas e médias empresas, os gestores imaginarem que ao realizar um

investimento de aquisição de S&SC, estejam adquirindo um sistema completo e adequado,

transferindo para o fornecedor toda a responsabilidade de conseguir que esse sistema satisfaça as

necessidades da empresa e seja aderente ao negócio (VIDAL, 2015).

De acordo com Aurum (2013), existem algumas maneiras de avaliar a capacidade de um

fornecedor de S&SC, através do estudo do tempo de mercado, quem são seus clientes, quantos

profissionais trabalham na empresa, qual o grau de satisfação dos clientes, qual o respaldo e o

que a empresa oferece. Além de avaliar a empresa desenvolvedora, existe também a necessidade

de avaliar o produto: quais são os recursos oferecidos pelo produto, a qualidade e o quão

aderente e acessível o produto é para o seu negócio. O Guia de Aquisição do MPS.BR destaca

atividades específicas para essa seleção do fornecedor, como avaliar a capacidade e selecionar o

fornecedor, além de preparar e negociar um contrato (SOFTEX, 2013).

Para avaliar um S&SC com mais detalhes, é necessário especificar os requisitos essenciais e

desejáveis, além de suas funções (atendimento das necessidades) e atributos (aspectos de

qualidade). Esses requisitos permitem avaliar a aderência e qualidade do S&SC e comparar o

resultado entre os fornecedores pré-selecionados. Pressman (2011) comenta que diversos

esforços foram feitos para desenvolver medições precisas da qualidade de software, e essas, às

vezes, se frustraram pela natureza subjetiva da atividade.

Diante disto e visando avaliar a qualidade de produto de software, são criadas normas

internacionais e nacionais, que possuem atualizações periódicas (ALMEIDA, 2010). A norma

NBR ISO/IEC 9126-1, por exemplo, estabelece seis características que descrevem a qualidade de

um produto de software: funcionalidade, confiabilidade, usabilidade, eficiência,

manutenibilidade e portabilidade. Essas características podem ser aplicadas em qualquer tipo de



software e fornecem uma base de qualidade no qual se deseja avaliar (NBR ISO/IEC 9126-

1:2003).

Processos de aquisição de S&SC, em sua maioria, iniciam com a decisão de adquirir o

software, seleção dos fornecedores, construção do contrato, implantação do software e se

encerram com a aceitação do cliente. Porém, para esta proposta de artigo, será abordado apenas

os processos e atividades relacionadas à seleção de fornecedores e, em específico, e avaliações

técnicas (aderência funcional e técnica dos requisitos) dos softwares selecionados.

Neste cenário, o objetivo deste artigo é o desenvolvimento de uma ferramenta para apoiar a

seleção de fornecedores, através da avaliação de aderência de software, baseado nas diretrizes de

qualidade da norma NBR ISO/IEC 9126-1, com a finalidade de: a) definir e gerenciar os

requisitos; b) avaliar a aderência do software do fornecedor conforme os requisitos

estabelecidos; e c) fornecer uma visão geral da aderência dos fornecedores avaliados através de

uma matriz de comparação (requisitos versus aderência).

Este artigo está organizado e dividido nas seguintes seções: 1) compreende a introdução; 2)

apresenta a revisão teórica, compreendendo (i) qualidade de software, (ii) MPS.BR, (iii) norma

NBR ISO/IEC 9126 e (iv) trabalhos correlatos; 3) demonstra o processo de avaliação de

fornecedor de software, unindo as práticas do MPS.BR, a norma NBR ISO/IEC 9126-1 e

metodologia MAAS; 4) descreve o desenvolvimento da ferramenta; 5) demonstra um cenário

real da aplicação da ferramenta; e 6) apresenta as considerações finais.

2. Revisão teórica

Neste tópico serão apresentados os principais conceitos teóricos utilizados para o

desenvolvimento do trabalho.

2.1. Qualidade de software

É comum existir reclamações de problemas e erros em relação aos produtos de software, apesar

de estes serem imprescindíveis na execução de diversas tarefas de uma organização. A

complexidade dos sistemas desenvolvidos tem aumentado, bem como a concorrência entre as

empresas fornecedoras de software (LEAL, 2011).

A indústria de software vem ocupando um importante espaço na economia mundial e é

importante que tenha um foco no desenvolvimento de produtos de qualidade. O problema é que,

segundo Almeida (2010), em geral, a qualidade do software não é satisfatória, por não atender as

necessidades dos usuários e apresentarem falhas.

A maioria das definições teóricas define que qualidade de software é o atendimento às

necessidades do cliente. Ou seja, o software deve estar em conformidade com os requisitos

estabelecidos e satisfazer as expectativas do cliente para se considerar de qualidade (CAROSIA,

2004).

No entanto, a qualidade de software pode ser entendida de diversas formas e utilizando

diferentes abordagens (RIBEIRO, 2012), para isso existem duas visões principais: a visão de

processo e a visão de produto.

A visão de processo, apoiada em modelos de referência como CMMI, MPS.BR e normas

ISO/IEC 12207 e série ISO 9000, entre outras, que trata da avaliação e melhoria dos processos

utilizados para o ciclo de vida do software. Na visão de produto, fundamentada na série de

normas ISO/IEC 9126, 14598 e 12119, trata da avaliação de um produto de software para

verificação de sua qualidade. As duas visões são distintas quando utilizam técnicas e métodos

específicos e são complementares, uma vez que a visão do processo dá uma expectativa de

geração de produtos melhores, embora não garanta a qualidade do produto final (ANJOS e

MOURA, 2013).



Neste contexto, a qualidade de um produto de software é resultante das atividades realizadas

no processo de desenvolvimento do mesmo. Avaliar a qualidade de um produto de software é

verificar, através de técnicas e atividades operacionais o quanto os requisitos são atendidos.

Esses requisitos, de maneira geral, expressam as necessidades do cliente, explicitados em termos

quantitativos ou qualitativos, e têm por objetivo definir as características do software

(TSUKUMO et al., 1997).

2.2. MPS.BR

O MPS.BR é um programa para Melhoria de Processo do Software Brasileiro,

coordenado pela Associação para Promoção da Excelência do Software Brasileiro

(SOFTEX), com apoio do Banco Interamericano de Desenvolvimento (BID),

Financiadora de Estudos e Projetos (FINEP) e Ministério da Ciência e Tecnologia

(MCT) (SOFTEX, 2013).

O MPS.BR baseia-se nos conceitos de maturidade e capacidade de processo para a avaliação e

melhoria da qualidade e produtividade de produtos de S&SC. Nesse contexto, o MPS.BR possui

quadro componentes: Modelo de Referência MPS para Software (MR-MPS-SW), Modelo de

Referência MPS para Serviços (MR-MPS-SV), Método de Avaliação (MA-MPS) e Modelo de

Negócio para Melhoria de Processo de Software e Serviços (SOFTEX-MPS, 2012).

O MR-MPS-SW está descrito através de documentos em formato de guias (SOFTEX, 2013):

Guia Geral: contém a descrição geral do MPS.BR e detalha o MR-MPS.

Guia de Aquisição: descreve um processo de aquisição de software e serviços

correlatos (S&SC).

Guia de Avaliação: descreve o processo e o método de avaliação MA-MPS, os

requisitos para avaliadores líder, avaliadores adjuntos e Instituições Avaliadoras.

O Guia de Aquisição do MPS.BR descreve um processo de aquisição de S&SC, baseado na

norma internacional ISO/IEC 12207:2008 e complementado pela norma IEEE STD 1062:1998

(SOFTEX, 2013).

De acordo com Nunes (2011), o propósito do guia de aquisição é ajudar na obtenção de

S&SC que satisfaçam a necessidade do cliente. O guia não contém requisitos do MR-MPS, mas

boas práticas para a aquisição de S&SC. O processo começa na identificação da necessidade do

cliente e encerra com a aceitação do produto ou serviço adquirido. Neste processo são descritas

quatro atividades, cada uma com tarefas específicas, conforme mostra a Quadro 1.

Atividades Tarefas

Preparação da aquisição

1. Estabelecer a necessidade

2. Definir os requisitos

3. Revisar os requisitos

4. Desenvolver uma estratégia de aquisição

5. Definir os critérios de seleção de fornecedores

Seleção do fornecedor

1. Avaliar a capacidade dos fornecedores

2. Selecionar o fornecedor

3. Preparar e negociar um contrato

Monitoração do contrato

1. Estabelecer e manter comunicações

2. Trocar informação sobre o progresso técnico

3. Revisar o desempenho do fornecedor

4. Monitorar a aquisição

5. Obter acordo quanto às alterações

6. Acompanhar problemas

Aceitação pelo cliente

1. Preparar a aceitação

2. Avaliar o S&SC entregue

3. Manter conformidade com o contrato



4. Aceitar o S&SC

Quadro 1 - Atividades e tarefas do Guia de Aquisição do MPS.BR (adaptado de Softex, 2013)



2.3. Norma NBR ISO/IEC 9126

A norma ISO/IEC 9126 (que no Brasil recebe a sigla NBR no início da nomenclatura), de forma

genérica, engloba modelos de qualidade e métricas. A série ISO/IEC 9126 consiste em quarto

partes (NBR ISO/IEC 9126-1:2003):

NBR ISO/IEC 9126-1: Parte 1 - Modelo de qualidade;

NBR ISO/IEC 9126-2: Parte 2 - Métricas externas;

NBR ISO/IEC 9126-3: Parte 3 - Métricas internas;

NBR ISO/IEC 9126-4: Parte 4 - Métricas de qualidade de uso.

Dessas, será destacada a parte 1, dando origem a NBR ISO/IEC 9126-1. Essa norma,

portanto, focada em qualidade de software, propõe Atributos de Qualidade, que são distribuídos

em seis características principais, com cada uma delas divididas em sub características, que

descrevem a qualidade de software (TSUKUMO et. al., 1997). Almeida (2010) comenta que

essas características são aplicáveis a qualquer tipo de software. Nos Quadros 2 e 3 são

apresentadas as características e sub características dessa norma, além de perguntas chaves

propostas por Anjos e Moura (2013) para auxiliar o entendimento e avaliação dos itens.

Característica Descrição Pergunta chave

Funcionalidade

Evidencia o conjunto de funções que atendem ás

necessidades explícitas e implícitas para a finalidade a que

se destina o produto.

Satisfaz às necessidades?

Confiabilidade

Evidencia a capacidade do produto de manter seu

desempenho ao longo do tempo e em condições

estabelecidas.

É imune a falhas?

Usabilidade Evidencia a facilidade para a utilização do produto. É fácil de usar?

Eficiência

Evidencia o relacionamento entre o nível de desempenho do

produto e a quantidade de recursos utilizados, sob condições

estabelecidas.

É rápido e “enxuto”?

Manutenibilidade Evidencia o esforço necessário para realizar modificações no

produto. É fácil de modificar?

Portabilidade Evidencia a capacidade do produto de ser transferido de u

ambiente para outro.

É fácil de usar em outro

ambiente?

Quadro 2 – Características da qualidade de software segundo a norma NBR ISO/IEC 9126-1 (adaptado de

Anjos e Moura, 2013; Tsukumo et al., 1997)

Característica Sub característica Descrição Pergunta chave

Funcionalidade

Adequação

Presença de conjunto de

funções e sua apropriação para

as tarefas.

Propõe-se a fazer o que é

apropriado?

Acurácia Geração de resultados ou

efeitos corretos.

Faz o que foi proposto de forma

correta?

Interoperabilidade Capacidade de interagir com

outros sistemas.

Interage com os sistemas

especificados?

Conformidade Estar de acordo com normas,

conversões e regulamentações.

Está de acordo com as normas,

leis, etc.?

Segurança de acesso

Capacidade de evitar acesso

não autorizado a programas e

dados.

Evita acesso não autorizado aos

dados?

Confiabilidade

Maturidade Frequência de falhas. Com que frequência apresenta

falhas?

Tolerância a falhas Manter nível de desempenho

em caso de falha.

Ocorrendo falhas, como ele

reage?

Recuperabilidade Capacidade de se restabelecer

e restaurar dados após falha.

É capaz de recuperar dados em

caso de falha?

Usabilidade Inteligibilidade Facilidade de entendimento É fácil entender o conceito e a



dos conceitos utilizados. aplicação?

Apreensibilidade Facilidade de aprendizado. É fácil aprender a usar?

Operacionalidade Facilidade de operar e

controlar a operação. É fácil de operar e controlar?

Eficiência

Comportamento em

relação ao tempo

Tempo de resposta de

processamento.

Qual é o tempo de resposta, a

velocidade de execução?

Comportamento em

relação a recursos

Quantidade de recursos

utilizados.

Quanto recurso usa? Durante

quanto tempo?

Manutenibilidade

Analisabilidade

Facilidade de diagnosticar

deficiências e causas de

falhas.

É fácil de encontrar uma falha,

quando ocorre?

Modificabilidade Facilidade de modificação e

remoção de defeitos. É fácil modificar e adaptar?

Estabilidade Ausência de riscos de efeitos

inesperados.

Há grande risco quando se faz

alterações?

Testabilidade Facilidade de ser testado. É fácil testar quando faz

alterações?

Portabilidade

Adaptabilidade Capacidade de ser adaptado a

ambientes diferentes.

É fácil adaptar a outros

ambientes?

Capacidade para ser

instalado Facilidade de instalação.

É fácil instalar em outros

ambientes?

Conformidade Acordo com padrões ou

convenções de portabilidade.

Está de acordo com padrões de

portabilidade?

Capacidade para

substituir Substituir outro software.

É fácil usar para substituir

outro?

Quadro 3 – Sub características da qualidade de software segundo a norma NBR ISO/IEC 9126-1 (adaptado

de Anjos e Moura, 2013; Tsukumo et al., 1997)

2.4. Trabalhos correlatos

Os trabalhos correlatos avaliados apresentam, em sua maioria, sugestões de processos de

aquisição e adaptações de modelos de avaliação da qualidade de software. Nenhum desses

trabalhos tratava especificamente sobre a avaliação técnica (como identificar e avaliar os

requisitos) de um software/fornecedor. Nesse contexto, foram identificados os trabalhos que se

assemelham com a proposta deste artigo.

Almeida (2010) propôs, em sua monografia de TCC, a avaliação da qualidade de produto de

um software de Planejamento de Recursos Empresariais (Enterprise Resource Planning – ERP)

de acordo com a norma ISO/IEC 9126. Para isso, o trabalho identificou um produto ERP e um

método de avaliação. O método de avaliação de qualidade de software escolhido foi o MEDE-

PROS. O trabalho apresentou também, melhorias nos requisitos que não atenderam os padrões

de qualidade, a fim de ampliar e garantir a aderência do produto com o modelo de avaliação.

No trabalho de Anjos e Moura (2013), foi definido um modelo de avaliação para produtos de

software baseado nas normas da ISO 9126, 14598 e 12119, que busca avaliar a qualidade do

software como um todo, enfatizando a importância da definição dos requisitos em ambas as

visões de processo e produto de software. Além disto, o modelo propõe a participação de um

avaliador especialista no domínio. Esse profissional especializado seria capaz de verificar o

cumprimento de todos os requisitos definidos e identificar as necessidades implícitas, garantindo

assim a conformidade dos requisitos, acurácia e adequação.

Nunes (2011) apresenta um estudo da literatura sobre processos de aquisição, onde apontou

que a falta de um processo adequado às necessidades da organização é uma das principais causas

dos problemas existentes quando se adquire software. O trabalho apresenta um processo de

aquisição de software utilizando técnicas de reutilização, através da definição de requisitos,

componentes, linhas e características de processos para o domínio Aquisição de Software,

permitindo que os processos atendam aos diversos cenários das organizações. A definição desse



processo está aderente a normas e modelos de referência para melhoria de processo de software,

integrando a gestão do processo de desenvolvimento do software com aquisição.

3. Processo de avaliação de aderência de um software

O processo de aquisição descrito pelo MPS.BR, através do Guia de Aquisição, estabelece

atividades e tarefas específicas para avaliação e seleção de um fornecer. Porém, o guia não

especifica os requisitos e critérios que podem ser usados na avaliação de aderência de um

software.

A fim de complementar esse processo, pode-se adotar as características de qualidade da

norma NBR ISO/IEC 9126-1 para avaliar a aderência do software. No entanto, a norma não

define como medir as características e sub características. Diante disso, existe a necessidade de

definir um método de avaliação que deverá ser aplicado nas características e sub características

para conseguirmos mensurá-las.

Portanto, como forma de avaliação dos requisitos funcionais (funcionalidades), técnicos

(características de qualidade) e complementares (requisitos fora do escopo funcional e técnico),

será aplicada a análise de aderência de sistemas proposta pela Secretaria da Administração do

Estado da Bahia, através da Coordenação de Tecnologias Aplicadas à Gestão Pública – CTG,

que desenvolveu a Metodologia de Análise de Aderência de Sistemas – MAAS (MAAS, 2009).

Neste cenário, usaremos a norma NBR ISO/IEC 9126-1 como guia técnico – definindo o que

deve ser avaliado (as características e sub características de qualidade) – e a metodologia MAAS

como método de avaliação (aderência).

As subseções a seguir, apresentam um detalhamento dessa proposta, demonstrando a

identificação dos requisitos, avaliação de aderência e a comparação dos resultados.

3.1. Identificação dos requisitos

Antes mesmo de se definir os fornecedores que serão avaliados, deve-se identificar todos os

requisitos necessários e desejados. Essa atividade se faz necessária para padronizar as avaliações

e estabelecer parâmetros de comparação entre os fornecedores.

Diante disso, o primeiro passo, portanto, é o levantamento dos requisitos e a atribuição de

peso para cada um deles. Os requisitos serão identificados como:

a) Funcionais – identificam as funcionalidades e necessidades que o software avaliado

deverá atender;

b) Técnicos – definem as necessidades de qualidade, segundo as diretrizes da norma

NBR ISO/IEC 9126-1;

c) Complementares.

Para os requisitos técnicos, é necessário definir também, critérios de avaliação. Esses critérios

serão utilizados na avaliação de aderência. O Apêndice A apresenta os critérios propostos pela

metodologia MAAS.

Na sequência, deve-se definir a prioridade de cada requisito funcional como Obrigatória,

Importante ou Desejável. Para os requisitos técnico e complementares, deve-se atribuir um peso,

variando entre 1 (um) e 4 (quatro). O Quadro 4 apresenta as definições de prioridades com sua

descrição e peso associados.



Prioridade Peso Descrição

Obrigatória 3 Tem que existir na solução avaliada; caso contrário,

inviabiliza a sua escolha.

Importante 2 Espera-se que esteja disponível, porém pode ser atendida por

outra funcionalidade semelhante.

Desejável 1 Enriquece a solução, porém caso não tenha, não inviabiliza a

escolha da mesma.

Quadro 4 – Prioridades e pesos para os requisitos funcionais (adaptado de MAAS, 2009)

3.2. Avaliação de aderência

Para a avaliação de aderência do software, deve-se pontuar com uma nota cada requisito

identificado. Para os requisitos funcionais, pontua-se com nota 2 (dois), caso a funcionalidade

exista no software; e com nota 0 (zero) para os casos que não existe. Nos requisitos técnicos e

complementares, as notas variam de 0 (zero) a 2 (dois) e são pontuadas conforme os critérios de

avaliação definidos no requisito.

A pontuação final de cada requisito é calculada através fórmula “pontuação = A x B”. Onde

“A” é o peso definido para o requisito e “B” é a nota (critério) pontuada para o mesmo. A Figura

1 apresenta um exemplo de avaliação de um requisito técnico.

Figura 1 – Exemplo da avaliação de requisitos técnicos (adaptado de MAAS, 2009)

3.3. Comparação dos resultados

Para identificar o fornecedor mais adequado à situação e aos requisitos estabelecidos

inicialmente, deve-se criar uma matriz de comparação. A matriz de comparação fornece uma

visão agrupada das pontuações realizadas em cada software, demonstrando a aderência de cada

um nos aspectos avaliados. A Figura 2 apresenta um exemplo de matriz de comparação de

resultados.

Figura 2 – Exemplo da matriz de comparação de resultados (adaptado de MAAS, 2009)



4. Desenvolvimento da ferramenta

Esta seção apresenta as técnicas utilizadas, a especificação dos requisitos e o detalhamento da

implementação da ferramenta.

4.1. Técnicas utilizadas

Para a especificação foram utilizados serviços online gratuitos, como Cacoo (http:// cacoo.com)

– para o diagrama de caso de uso, e Vertabelo (http://vertabelo.com) – para modelagem do banco

de dados. No desenvolvimento, foi utilizada a plataforma Linux (Ubuntu 15.04) e os softwares:

Apache 2.4.10 – como servidor de aplicação web; PHP 5.6.4 – como linguagem de programação;

MySQL 5.6.25 – como banco de dados; e CakePHP 2 – como framework de desenvolvimento.

Foi utilizada também, como camada front-end, o framework Bootstrap 3.3.4, onde o mesmo foi

incorporado como plugin no CakePHP.

Na codificação de classes, métodos, atributos, variáveis e comentários do sistema e para o

bando de dados, foi utilizado o idioma inglês. A escolha do inglês deu-se pela facilidade e

comodidade no desenvolvimento, além do fato de que, tanto os comandos do PHP como o

CakePHP, foram escritos em inglês.

4.2. Especificação

Os requisitos, para a ferramenta proposta, foram levantados com base no processo descrito na

seção 3 e compreendem a criação e configuração de uma avaliação, pontuação de requisitos e a

comparação dos resultados das avaliações. A Figura 3 apresenta os casos de uso identificados

considerando as funcionalidades esperadas na ferramenta. Já o Quadro 5, são definidos os

requisitos funcionais.

Figura 3 – Diagrama de casos de uso (produção do próprio autor, 2015)

Requisitos funcionais Caso de uso

RF01: O sistema deverá permitir ao administrador cadastrar

requisitos técnicos UC01



RF02: O sistema deverá permitir ao avaliador cadastrar

avaliações UC02

RF03: O sistema deverá permitir ao avaliador manter

requisitos funcionais para uma avaliação UC03


requisitos complementares para uma avaliação UC03

RF05: O sistema deverá permitir ao avaliador definir o

peso dos requisitos cadastrados UC03


fornecedores em uma avaliação UC04

RF07: O sistema deverá permitir ao avaliador pontuar os

requisitos para um fornecedor UC04

RF08: O sistema deverá permitir ao avaliador consultar o

resultado da avaliação UC05

Quadro 5 – Requisitos funcionais com os casos de uso relacionados

O Diagrama Entidade-Relacionamento (DER) é um diagrama que descreve o modelo de

dados de um sistema, com alto nível de abstração. A Figura 4 apresenta o DER com as entidades

que serão persistidas no banco de dados da ferramenta.

Figura 4 – Diagrama entidade-relacionamento (produção do próprio autor, 2015)

O dicionário de dados está descrito no Apêndice B. Entretanto, a seguir é apresentada uma

breve descrição das entidades utilizadas para o desenvolvimento da ferramenta:

a) assessments: armazena as avaliações;

b) assessment_requirements: armazena as avaliações dos requisitos;

c) assessment_suppliers: armazena os fornecedores;

d) requirements: armazena os requisitos funcionais, técnicos e complementares que serão

pontuados na avaliação;

e) requirement_technicals: armazena os requisitos técnicos padrões da ferramenta.

4.3. Implementação

A ferramenta foi dividida em duas visões, que representam os usuários: 1) administrador e 2)

avaliador. Como administrador, é possível cadastrar e realizar a manutenção dos requisitos



técnicos. Acessando a ferramenta como avaliador, é possível criar avaliações, configurar os

requisitos que serão pontuados na avaliação, incluir e avaliar os fornecedores e consultar o

resultado das avaliações. No decorrer desta seção, serão apresentadas todas as funcionalidades

implementadas na ferramenta.

Na tela inicial da ferramenta, conforme Figura 5, são apresentadas as opções de acesso.

Figura 5 – Tela inicial da ferramenta (produção do próprio autor, 2015)

Acessando como Administrador, será possível gerenciar os requisitos técnicos cadastrados na

ferramenta e que poderão ser utilizados nas avaliações. A Figura 6 apresenta a tela de cadastro de

um requisito técnico.

Figura 6 – Tela de cadastro de um requisito técnico (produção do próprio autor, 2015)

Ao acessar a ferramenta como Avaliador tem-se a listagem das avaliações criadas, conforme

demostra a Figura 7. Na criação uma avaliação, o avaliador deverá selecionar os requisitos

técnicos que farão parte da mesma. Depois de criada a avalição, será possível incluir os demais

requisitos (funcionais e complementares) e configurar seus os respectivos pesos.



Figura 7 – Tela de listagem das avaliações já criadas (produção do próprio autor, 2015)

Na Figura 8, é apresentada a tela com os detalhes da avaliação, que disponibiliza o acesso as

outras funcionalidades da ferramenta, como a configuração dos requisitos, inclusão e avaliação

de fornecedores e acesso ao relatório de aderências.

Figura 8 – Tela de configuração dos requisitos (produção do próprio autor, 2015)

Com a definição e configuração dos requisitos pronta, o avaliador poderá iniciar o processo

de avaliações. Para isso, deverá incluir um fornecedor, na tela de detalhes da avaliação. Após a

inclusão do fornecedor, o avaliador conseguirá pontuar os requisitos definidos, selecionando uma

nota para cada requisito e nas três (3) guias (requisitos funcionais, técnicos e complementares).

O valor final da pontuação do requisito é calculado automaticamente pela ferramenta, conforme

nota a escolhida. As Figuras 9 e 10 apresentam as telas de pontuação dos requisitos funcionais e

técnico.



Figura 9 – Tela de pontuação dos requisitos funcionais (produção do próprio autor, 2015)

Figura 10 – Tela de pontuação dos requisitos técnicos (produção do próprio autor, 2015)

Realizada a pontuação dos requisitos para o fornecedor, o avaliador poderá incluir mais um

fornecedor ou encerrar a avaliação. Ao salvar as pontuações, a ferramenta já calcula a pontuação

total do fornecedor, disponibilizando o resultado da aderência dos fornecedores (acesso pela tela

de detalhes da avaliação). A Figura 11 apresenta o relatório de aderência.



Figura 11 – Tela da matriz de resultados (produção do próprio autor, 2015)

Com o relatório de aderência, o avaliador conseguirá visualizar o percentual atingido de cada

fornecedor de forma geral (total) ou pelas categorias. A ferramenta irá identificar, através de uma

cor de fundo diferenciada, o fornecedor com a maior porcentagem total de aderência.



5. Considerações finais

Este artigo apresentou o desenvolvimento de uma ferramenta para apoiar avaliações de aderência

de softwares, aplicada em processos de aquisição de S&SC. A ferramenta buscou suprir uma

carência dos trabalhos correlatos, que não avaliam tecnicamente os produtos (softwares) dos

fornecedores ou não exploram esse tipo de avaliação em seus processos.

A ferramenta disponibiliza um ambiente para definir os requisitos desejados para a avaliação

de aderência, além de permitir o ajuste das métricas (pesos e critérios de avaliação) desses

requisitos. Os requisitos funcionais e complementares são identificados conforme as

necessidades do negócio a ser avaliado. Já os requisitos técnicos, são definidos segundo a norma

NBR ISO/IEC 9126-1. Na opção de avaliar um fornecedor, a ferramenta lista todos os requisitos

definidos para a avaliação, e para cada um deles é possível pontuar a sua aderência conforme os

critérios de avaliação do requisito. Como resultado das pontuações e avaliações, a ferramenta

disponibiliza uma matriz de comparação desses resultados, demonstrando a aderência geral de

cada fornecedor avaliado em relação aos requisitos.

Dessa forma, os objetivos propostos neste trabalho foram atendidos, pois foi implementada

uma ferramenta web para apoiar o processo de avaliação de aderência de softwares de forma

fácil e aderente aos requisitos da norma NBR ISO/IEC 9126-1.

Para complementar este artigo, e de alguma forma validar a ferramenta implementada, a

mesma foi utilizada em um dos trabalhos da Spezzi Tecnologia LTDA. A empresa – que

disponibiliza serviços de assessoria em TI, aplicou o processo de aquisição definido pelo

MPS.BR em um de seus clientes. Através da norma NBR ISO/IEC 9126-1 e da metodologia

MAAS, foi possível avaliar os produtos dos fornecedores selecionados. Inicialmente, para cada

fornecedor, tinha-se uma planilha que armazenava a avaliação dos requisitos (pontuação e

aderência). Ao final das avaliações, outra planilha era usada para consolidar, manualmente, os

resultados. Considerando esse cenário, a utilização da ferramenta para gerenciar os requisitos e

critérios de avaliação, além de apresentar o resultado das avaliações ao cliente de forma fácil e

rápida, foi muito útil e importante. A empresa conseguiu garantir a integridade e eficiência das

avaliações, uma vez que não precisou manter várias planilhas.

Como sugestão para trabalhos futuros, pode-se adicionar na ferramenta as demais atividades e

tarefas que um processo de aquisição estabelece, como por exemplo, a pré-seleção de

fornecedores, gestão do contrato e condições de aquisição e monitoramento da implantação do

software adquirido.

Referências

ALMEIDA, K. P. M. Avaliação da qualidade de software ERP de acordo com a norma

ISO/IEC 9126. 100f. Monografia de graduação – Bacharelado em Ciência da Computação –

Departamento de Ciência da Computação. Universidade Federal de Lavras - Lavras, 2010.

ANJOS, L. A. M.; MOURA, H. P. Um modelo para avaliação de produtos de software.

Centro de Informática – Universidade Federal de Pernambuco – UFPE, [2013].

AURUM. Como avaliar e fazer uma boa aquisição de um software jurídico. [S.l.], 2013.

CAROSIA, J. S. Levantamento da qualidade do processo de software com foco em

pequenas organizações. 158f. Dissertação de Mestrado – Curso da Pós-Graduação em

Computação Aplicada. INPE - São José dos Campos, 2004.

FURTADO, J. Uma Metodologia Ágil para Gestão da Aquisição de Software e Serviços

Correlatos. Projeto de pesquisa – DCET/UNIFAP, 2014.



JOBS, M. F. Construção de software: interna ou terceirizada? [S.l.], 2009.

KHAN, S.; NIAZI, M.; AHMAD, R. A readiness model for software development

outsourcing vendors. Bangalore, India, 2008.

LEAL, A. B. Relato de experiência da implantação de boas práticas de engenharia de

software em um ambiente heterogêneo. Dissertação de Mestrado – Programa de Pós-

Graduação em Informática. Pontifícia Universidade Católica do Rio de Janeiro – PUC-Rio - Rio

de Janeiro, 2011.

MAAS. Metodologia de Análise de Aderência de Sistemas - Versão 2.0. SAEB - Secretaria da

Administração do Estado da Bahia. CTG - Coordenação de Tecnologias Aplicadas à Gestão

Pública. [S.l.], 2009.

MIRANDA, A. J. Aquisição de serviços de TI como um processo de qualidade no

fornecimento de software – Estudo de caso de terceirização em medicina transfusional.

Dissertação de Mestrado – Instituto de Tecnologia, Programa de Pós-Graduação em Engenharia

Elétrica. Universidade Federal do Pará, Belém, 2009.

NBR ISO/IEC 9126-1:2003. Engenharia de software – Qualidade de produto Parte 1:

Modelo de qualidade. [S.l.], Jun 2003.

NUNES, E. D. Definição de processos de aquisição de software para reutilização. [S.l.],

2011.

PRESSMAN, R. S. Engenharia de software: uma abordagem profissional. Tradução

Ariovaldo Griesi – 7ª edição. Porto Alegre: AMGH, 2011.

RIBEIRO, R. Padrões de Qualidade - ISO/IEC 9126 (NBR 13596). [S.l.], 2012.

SOFTEX-MPS. MPS.BR - Guia Geral MPS de Software. [S.l.], 2012.

TSUKUMO, A. N.; RÊGO, C. M.; SALVIANO, C. F.; AZEVEDO, G. F.; MENEGHETTI, L.

K.; COSTA, M. C. C.; CARVALHO, M. B. de C.; COLOMBO, R. M. T. Qualidade de

software: Visões de produto e processos de software. ATAQS – CTI – Fundação Centro

Tecnológico para Informática. Campinas, SP, 1997.

VIDAL, A. G. R. Aquisição de software e serviços de informática na pequena e média

empresa. [S.l.], [2015]. Faculdade de Economia, Administração e Contabilidade da USP.



APÊNDICE A – Critérios de avaliação para os requisitos técnicos

Este apêndice apresenta critérios de avaliação propostos pela metodologia MAAS (2009). No

Quadro 6, têm-se as categorias, os requisitos e seus critérios de avalição (nota) aplicáveis.

Categoria Requisito técnico Critérios (nota e descrição)

Funcionalidade

Segurança da aplicação

2 – Muito seguro (criptografia explícita de login e

senha, mínimo de 128 bits; informação de login e

senha de usuários fora do BD da aplicação; todos os

tráfegos de dados das transações criptografados,

mínimo de 128 bits; e senha criptografada com

algoritmo de mão única).

1 – Seguro (criptografia explícita de login e senha,

mínimo de 128 bits e senha criptografada com

algoritmo de mão única).

0 – Pouco seguro (não atende aos requisitos acima)

Controle de acesso

2 – Possui controle de perfis, grupos e níveis de

acesso com definição de áreas restritas

0 – Não possui

Segurança de dados

2 – Muito seguro (arquitetura da aplicação com

tipologia utilizando VPN, firewalls e redundância;

criptografia opcional).

1 – Seguro (arquitetura da aplicação com tipologia

monolítica; criptografia obrigatória; acesso aos dados

exclusivo a aplicação).

0 – Pouco seguro (não atende aos requisitos acima)

Integração

2 – Forma de integração on-line

1 – Módulo de exportação/importação

0 – Não permite integração

Manual do usuário 2 – Possui

0 – Não possui

Manual do sistema 2 – Possui

0 – Não possui

Help online 2 – Possui

0 – Não possui

Confiabilidade

Possui trilha de auditoria 2 – Possui

0 – Não possui

Disponibilidade da aplicação

2 – Alta (possui balanceamento dos servidores

principais e redundância de fonte de alimentação)

1 – Média (possui um dos recursos listados acima)

0 – Baixa (não possui nenhum dos recursos acima)

Possui manutenção remota 2 – Possui

0 – Não possui

Possui rotinas para recuperação dos

dados (backup e restore)

2 – Possui

0 – Não possui

Usabilidade

Interface com os usuários

2 – Muito amigável

1 – Amigável

0 – Pouco amigável

Gerador de relatório

2 – Possui gerador de relatório

1 – Relatórios suficientes

0 – Insuficiência de relatórios

Possui help on-line sensível a

contexto de campo, tela, módulo e

função

2 – Possui

0 – Não possui

Possui help on-line sensível a

passagem do mouse sobre o campo

ou botão

2 – Possui

0 – Não possui

Permite o usuário interromper ou

cancelar o processamento de uma

2 – Permite

0 – Não permite



função de longa duração

Reaproveitamento de entrada de

dados (valores default)

2 – Reaproveita

0 – Não reaproveita

Eficiência

Performance da aplicação 2 – Alta; 1 – Média; 0 – Baixa

Recurso de rede 2 – Pouco tráfego de rede

0 – Muito tráfego de rede

Consumo de processado

2 – Baixo consumo

1 – Médio consumo

0 – Alto consumo

Consumo de memória

2 – Baixo consumo

1 – Médio consumo

0 – Alto consumo

Volume de transações no banco de

dados

2 – Suporta grande volume

1 – Suporta médio volume

0 – Suporta baixo volume

Performance no acesso aos dados

2 – Alta

1 – Média

0 – Baixa

Manutenibilidade

Manutenção da aplicação

2 – Fácil (documentação completa no código;

documentação escrita da localização dos códigos que

executam as rotinas)

1 – Média (possui apenas uma das documentações)

0 – Difícil (não possui nenhuma documentação)

Profissional mantenedor

2 – Abundante no mercado

1 – Difícil

0 – Raro

Codificação em banco (stored

procedures / triggers)

2 – Não tem

0 – Tem

Matriz de rastreabilidade 2 – Não tem; 0 – Tem

Manutenção do banco de dados

2 – Fácil (clareza nas definições do Dicionário de

Dados para tabelas, atributos e relações)

1 – Média (ausência de uma das definições acima)

0 – Difícil (ausência total das definições acima)

Mensagens de erro descrevendo seu

tipo e localização no código fonte

(ex. módulo, programa, objeto e

linha)

2 – Possui; 0 – Não possui

Ambiente de

desenvolvimento/customização

com depurador on-line


Ambiente de desenvolvimento com

recurso de documentação

automática


Portabilidade

Estrutura de desenvolvimento

(camadas)

2 – Possui camadas distintas

0 – Não possui

Independência de produtos de

terceiros para seu pleno

funcionamento (ex. geradores de

relatórios, brokers, conversores,

conectores de bancos, etc.)

2 – Possui independência

0 – Não possui

Aplicação multiplataformas 2 – Sim; 0 – Não

Comunicação e acesso remoto

2 – Fácil (não necessita de nenhuma configuração

adicional para execução da aplicação)

0 – Difícil (necessita intervenção no ambiente do

usuário para utilização da aplicação)

Quadro 6 – Critérios de avaliação para os requisitos técnicos (adaptado de MAAS, 2009)



APÊNDICE B – Dicionário de dados

Este apêndice apresenta a descrição detalhada das entidades da modelagem de banco de dados

previstas no diagrama da seção 4.1. Os tipos de dados de cada campo são descritos a seguir:

a) varchar: tipo de campo para armazenamento de strings de caracteres e seu tamanho é

definido em bytes com largura variável, os valores entre parênteses definem o

comprimento máximo em bytes de caracteres;

b) int: tipo de campo para armazenamento de números inteiros;

c) date: tipo de campo para armazenamento de datas;

d) text: tipo de campo para armazenamento de grandes strings ou binários.

No Quadro 7 pode-se observar o dicionário de dados da tabela “assessments”.

Campo Tipo Descrição Observação

id int Id sequencial para o registro. Chave primária

cliente_name varchar(200) Nome do cliente.

appraiser_name varchar(200) Nome do avaliador.

date date Data da avaliação.

Quadro 7 – Dicionário de dados da tabela "assessments"

No Quadro 8 pode-se observar o dicionário de dados da tabela “assessment_requirements”.



requirement_id int Id do requerimento vinculado. Chave estrangeira.

assessment_supplier_id int Id do fornecedor vinculado. Chave estrangeira.

nota int Nota dada ao requisito.

score int Pontuação calculada para o requisito.

Quadro 8 – Dicionário de dados da tabela "assessment_requirements"

No Quadro 9 pode-se observar o dicionário de dados da tabela “assessment_suppliers”.



assessment_id int Id da avaliação vinculada. Chave estrangeira.

name varchar(200) Nome do fornecedor.

product varchar(200) Nome do produto do fornecedor.

Quadro 9 – Dicionário de dados da tabela "assessment_suppliers"

No Quadro 10 pode-se observar o dicionário de dados da tabela “requirements”.



assessment_id int Id da avaliação vinculada. Chave estrangeira.

type int Tipo do requisito (1=funcional;

2=técnico; 3=complementar).

category int Categoria do requisito.

name varchar(200) Nome do requisito.

criteria text Critérios de avaliação para o requisito.

weight int Peso do requisito.

Quadro 10 – Dicionário de dados da tabela "requirements"



No Quadro 11 pode-se observar o dicionário de dados da tabela “requirement_technicals”.



category int Categoria do requisito.

name varchar(200) Nome do requisito.

criteria text Critérios de avaliação para o requisito.

weight int Peso do requisito.

Quadro 11 – Dicionário de dados da tabela "requirement_technicals"

ferramenta para avaiação de aderência de softwares em processos

Documents