ferramenta para avaiação de aderência de softwares em processos
TRANSCRIPT
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],
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,
Universidade do Estado de Santa Catarina
Centro de Educação Superior do Alto Vale do Itajaí
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
Universidade do Estado de Santa Catarina
Centro de Educação Superior do Alto Vale do Itajaí
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).
Universidade do Estado de Santa Catarina
Centro de Educação Superior do Alto Vale do Itajaí
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
Universidade do Estado de Santa Catarina
Centro de Educação Superior do Alto Vale do Itajaí
4. Aceitar o S&SC
Quadro 1 - Atividades e tarefas do Guia de Aquisição do MPS.BR (adaptado de Softex, 2013)
Universidade do Estado de Santa Catarina
Centro de Educação Superior do Alto Vale do Itajaí
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
Universidade do Estado de Santa Catarina
Centro de Educação Superior do Alto Vale do Itajaí
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
Universidade do Estado de Santa Catarina
Centro de Educação Superior do Alto Vale do Itajaí
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.
Universidade do Estado de Santa Catarina
Centro de Educação Superior do Alto Vale do Itajaí
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)
Universidade do Estado de Santa Catarina
Centro de Educação Superior do Alto Vale do Itajaí
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
Universidade do Estado de Santa Catarina
Centro de Educação Superior do Alto Vale do Itajaí
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
RF04: O sistema deverá permitir ao avaliador manter
requisitos complementares para uma avaliação UC03
RF05: O sistema deverá permitir ao avaliador definir o
peso dos requisitos cadastrados UC03
RF06: O sistema deverá permitir ao avaliador manter
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
Universidade do Estado de Santa Catarina
Centro de Educação Superior do Alto Vale do Itajaí
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.
Universidade do Estado de Santa Catarina
Centro de Educação Superior do Alto Vale do Itajaí
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.
Universidade do Estado de Santa Catarina
Centro de Educação Superior do Alto Vale do Itajaí
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.
Universidade do Estado de Santa Catarina
Centro de Educação Superior do Alto Vale do Itajaí
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.
Universidade do Estado de Santa Catarina
Centro de Educação Superior do Alto Vale do Itajaí
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.
Universidade do Estado de Santa Catarina
Centro de Educação Superior do Alto Vale do Itajaí
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.
Universidade do Estado de Santa Catarina
Centro de Educação Superior do Alto Vale do Itajaí
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
Universidade do Estado de Santa Catarina
Centro de Educação Superior do Alto Vale do Itajaí
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
2 – Possui; 0 – Não possui
Ambiente de desenvolvimento com
recurso de documentação
automática
2 – Possui; 0 – Não possui
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)
Universidade do Estado de Santa Catarina
Centro de Educação Superior do Alto Vale do Itajaí
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”.
Campo Tipo Descrição Observação
id int Id sequencial para o registro. Chave primária
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”.
Campo Tipo Descrição Observação
id int Id sequencial para o registro. Chave primária
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”.
Campo Tipo Descrição Observação
id int Id sequencial para o registro. Chave primária
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"
Universidade do Estado de Santa Catarina
Centro de Educação Superior do Alto Vale do Itajaí
No Quadro 11 pode-se observar o dicionário de dados da tabela “requirement_technicals”.
Campo Tipo Descrição Observação
id int Id sequencial para o registro. Chave primária
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"