FACULDADE INDEPENDENTE DO NORDESTE – FAINOR CURSO DE ENGENHARIA DA COMPUTAÇÃO
JAIRO LÚCIO MENDES GUSMÃO JUNIOR
FERRAMENTA PARA AVALIAR QUALIDADE DE SOFTWARE: QUALITYSOFT-FAINOR
VITÓRIA DA CONQUISTA - BA MAIO 2010
G982f
Gusmão Junior, Jairo Lucio Mendes Ferramenta para avaliar qualidade de Software: qualitysoftFAINOR. / Jairo Lúcio Mendes Gusmão Junior._ _ Vitória da Conquista: FAINOR, 2009. 69 f; Ilus.
Monografia (Graduação em Engenharia da Computação) Orientador: Prof. Francisco Carvalho Qualidade de Software – ISO/IEC – 9126 2. Ferramenta QUALITYSOFT – FAINOR I Direito.
CDD 005.1
Catalogação na fonte: Biblioteca da Fainor
JAIRO LÚCIO MENDES GUSMÃO JÚNIOR
FERRAMENTA PARA AVALIAR QUALIDADE DE SOFTWARE: QUALITYSOFT-FAINOR
Monografia apresentada como um dos requisitos para obtenção do titulo de bacharel em engenharia. do curso de Engenharia da computação da Faculdade Independente do Nordeste, Unidade de Vitória Da Conquista-Ba. Orientador: Francisco Carvalho
VITÓRIA DA CONQUISTA - BA MAIO-2010
JAIRO LÚCIO MENDES GUSMÃO JÚNIOR
FERRAMENTA PARA AVALIAR QUALIDADE DE SOFTWARE: QUALITYSOFT-FAINOR
Aprovado em: ____/____/____. VITÓRIA DA CONQUISTA - BA BANCA EXAMINADORA
______________________________________________ Francisco dos Santos Carvalho - Orientador
______________________________________________ Rogério Gusmão Marinho
_______________________________________________ Alexandre gama de Souza
Aos meus pais por sempre acreditarem em mim, sempre me apoiando atĂŠ o ultimo momento. A minha querida noiva Amanda, pela extrema compreensĂŁo e apoio no decorrer deste trabalho.
AGRADECIMENTO
Em primeiro lugar agradeço a Deus, que me deu inspiração, perseverança e coragem para chegar ao término deste trabalho. Ao orientador Francisco Carvalho, pela atenção e auxilio destinados a esse trabalho. A minha noiva Amanda pelas palavras de incentivo e pelo companheirismo e paciência nas horas de maior dificuldade. À minha mãe, Janete, e ao meu pai, Jairo, que com certeza torceram por mim e acreditaram no meu potencial não só agora, durante este trabalho, mas durante toda a minha vida. Ao meu querido irmão Fred que mesmo distante, sempre me apoiou.
RESUMO
Este trabalho trata de um estudo relacionado à qualidade de software, abordando a necessidade de um software de qualidade, buscando uma maneira criteriosa de avaliação de acordo com as especificações do software a ser avaliado, tendo por referência a norma ISO/IEC 9126, sendo analisadas suas características, subcaracterísticas e métricas, com o intuito de desenvolver uma ferramenta que proporcione uma avaliação que seja feita de forma minuciosa e coerente com a norma citada, englobando assim um dos objetivos determinados. A ferramenta desenvolvida possui recursos fáceis de serem usados, tendo como propósito trazer usabilidade ao usuário/avaliador. O usuário poderá estabelecer seu critério de avaliação, tendo como resultado final gráficos gerados pela ferramenta QUALITYSOFT-FAINOR indicando o nível de qualidade do software avaliado.
Palavras - Chave: ISO/IEC – 9126. Qualidade de Software. Avaliação de Software.
ABSTRACT
This article discusses a study related to software quality by addressing the need for quality software, seeking a way of careful evaluation in accordance with the specifications of the software to be assessed by reference to ISO / IEC 9126, and analyzed characteristics, sub-characteristics and metrics, in order to develop a tool that provides an assessment is made in detail and consistent with the standard cited, thus encompassing one of the goals established. The developed tool includes features easy to use, and its goal to bring usability to the user / evaluator. The user can establish their evaluation criteria, resulting in final graphs generated by the toolQUALITYSOFT FAINOR indicating the level of software quality assessed.
Key - words: ISO / IEC - 9126. Software Quality. Software Evaluation.
LISTA DE FIGURAS
Figura 1 - os cinco níveis da maturidade do processo de software ........................ 20 Figura 2 - Nível 1 do CMM .................................................................................. 21 Figura 3 - Nível 2 do CMM .................................................................................. 21 Figura 4 - Nível 3 do CMM .................................................................................. 22 Figura 5 - Nível 4 do CMM .................................................................................. 22 Figura 6 - Nível 5 do CMM .................................................................................. 23 Figura 7 - As duas representações do CMMI ....................................................... 23 Figura 8 - Utilização da ISO/IEC 15504 ............................................................... 25 Figura 9 - Níveis de capacidade SPICE. .............................................................. 25 Figura 10 - Modelo de qualidade ISO 9126-1 ....................................................... 27 Figura 11 - Diagrama ER do banco de dados....................................................... 42 Figura 12 - Diagrama de caso de uso da aplicação .............................................. 43 Figura 13 - Tela de apresentação da ferramenta .................................................. 46 Figura 14 - Tela de visualização do cadastro de empresas ................................... 47 Figura 15 - Tela de apresentação do cadastro de softwares ................................. 48 Figura 16 - Tela para cadastro dos avaliadores .................................................... 48 Figura 17 - Tela de apresentação dos tipos de características .............................. 49 Figura 18 - Tela de descrição das características ................................................. 50 Figura 19 - Tela da descrição das sub-características .......................................... 51 Figura 20 - Tela de apresentação dos dados gerais referentes as sub-cacterísticas 52 Figura 21 - Tela de apresentação das respostas referente as sub-características .. 52 Figura 22 - Tela de apresentação dos métodos de avaliação ................................ 53 Figura 23 - Tela de pesos referente aos métodos de avaliação ............................. 53 Figura 24 - Tela de resultados referentes aos métodos de avaliação ..................... 54 Figura 25 - Tela de avaliações e geração de questionário..................................... 55 Figura 26 – Gráficos das características funcionalidade e confiabilidade. ............... 56 Figura 27 – Características de Usabilidade e Eficiência ........................................ 57 Figura 28 – Gráfico das características Portabilidade e Manutenbilidade ............... 58 Figura 29 – Gráfico da Avaliação das Métricas Internas e Externas ....................... 59 Figura 30 – Gráficos das Características Eficácia e Produtividade ........................ 60
Figura 31 – Gráfico das Características de Segurança e Satisfação ...................... 61 Figura 32 – Gráfico da Avaliação de Métricas de qualidade de uso ....................... 62 Figura 33 – Gráfico do Resultado Final da Avaliação ............................................ 63
LISTA DE QUADROS
Quadro 1 - Características da Qualidade de Software .......................................... 28 Quadro 2 – Sub-características da Qualidade de Software ................................... 29 Quadro 3 – Métricas de qualidade de uso ............................................................ 30
LISTA DE ABREVIATURAS E SIGLAS
ISO - International Organization for Standardization IEC - International Electrotechnical Comission SPICE - Software Process Improvement and Capability dErtermination CMM - Capability Maturity Model CMMI - Capability Matury Model Integrated SEI - Software Engineering Institute NBR - Norma Brasileira de Regulamentação DER - Diagrama Entidade Relacionamento RUP - Processo Unificado da Rational UML - Uniefied Modeling Langage XP - eXtreme Programming ABNT - Associação Brasileira de Normas Técnicas PSC - Peso da Sub-Caracteristica VNSC - Valor da nota da Sub-Característica NSC - Nota da Sub-Caracteristica PC - Peso da Característica NC - Nota da Característica NTC - Nota do tipo de Característica QTC - Quantidade de Tipos de Características NF - Nota Final
SUMÁRIO
1
INTRODUÇÃO........................................................................................... 14
1.1 PROBLEMA DE PESQUISA ....................................................................... 14 1.2 HIPÓTESES .............................................................................................. 14 1.3 OBJETIVO GERAL .................................................................................... 15 1.4 OBJETIVOS ESPECÍFICOS ....................................................................... 15 1.5 JUSTIFICATIVA ......................................................................................... 15 1.6 ESTRUTURA DA MONOGRAFIA ............................................................... 15 2
REVISÃO BIBLIOGRÁFICA ....................................................................... 17
2.1 IMPORTÂNCIA DA QUALIDADE DE SOFTWARE ....................................... 17 2.2 EVOLUÇÃO DOS CONCEITOS DE QUALIDADE ........................................ 18 2.3 AVALIAÇÃO DE PROCESSOS DE SOFTWARE ......................................... 19 2.3.1 CMM E CMMI....................................................................................... 20 2.3.2 ISO/IEC-15504 - (spice) ....................................................................... 24 2.3.3 ISO
.......................................................................................................... 26
2.4 AVALIAÇÃO DE PRODUTOS – ISO 9126 ................................................... 26 2.5 OUTRAS NORMAS PARA A AVALIAÇÃO DE PRODUTOS ......................... 31 2.6 PROCESSOS DE ENGENHARIA DE SOFTWARE ...................................... 31 2.6.1 Modelagem De Negócio ...................................................................... 32 2.6.2 Especificação De Requisitos .............................................................. 32 2.6.3 Projeto De Software ............................................................................ 33 2.6.4 Codificação ......................................................................................... 34 2.6.5 Testes ................................................................................................. 34 2.6.6 Implantação ........................................................................................ 36 2.6.7 Manutenção ........................................................................................ 36 3
METODOLOGIA ........................................................................................ 38
3.1 TIPOS DE PESQUISA QUANTO AOS OBJETIVOS ..................................... 38 3.2 TIPO DE PESQUISA QUANTO AOS PROCEDIMENTOS TÉCNICOS .......... 38 3.3 TIPOS DE PESQUISA QUANTO Á ABORDAGEM....................................... 38 3.4 ETAPAS DA PESQUISA ............................................................................ 39 3.5 INSTRUMENTOS DA PESQUISA ............................................................... 39 4
CONSTRUÇÃO DA FERRAMENTA ........................................................... 40
4.1 DESCRIÇÃO DA FERRAMENTA ................................................................ 40 4.1.1 Banco de Dados ................................................................................. 41 4.1.2 UML (Uniefied Modeling Langage) ...................................................... 43 4.1.3 Linguagem .......................................................................................... 46 4.2 INTERFACES DA FERRAMENTA............................................................... 46 5
ANÁLISE DOS RESULTADOS .................................................................. 56
6
CONCLUSÃO............................................................................................ 64
REFERÊNCIAS ................................................................................................. 66
14 1
INTRODUÇÃO
Há 50 anos o software era utilizado apenas em maquinas de efetuar cálculos. Atualmente o software possui um papel muito importante na sociedade, pois está presente na maioria dos produtos e /ou serviços das organizações. O conceito de qualidade de software está ligado a satisfação do usuário e a sua confiança em manusear o produto, ou, segundo Crosby (1979) a noção de qualidade tem sido a de que o produto desenvolvido deve cumprir com sua especificação. Observa-se que atualmente a qualidade é essencial pra o sucesso de uma empresa de software, sendo que essa qualidade deve ser avaliada a partir de normas que foram criadas para estabelecer um padrão para essa avaliação. Segundo a norma ISO/IEC – 9126, qualidade é a totalidade de características de uma entidade que lhe confere a capacidade de satisfazer as necessidades explicitas que são os fatores externados pelos clientes e implícitas, que são os fatores que dizem respeito a qualidade do software. Alguns fatores dentre muitos outros devem ser levados em consideração, principalmente na visão do cliente, que é a facilidade do uso, a confiabilidade que o software oferece e eficiência que o mesmo possui.
1.1 PROBLEMA DE PESQUISA
Existe uma ferramenta capaz de avaliar a qualidade do software? E como desenvolver uma ferramenta que proceda na avaliação do software?
1.2 HIPÓTESES
Como desenvolver uma ferramenta para avaliação de qualidade de software com usabilidade e sem custos para o usuário?
15 1.3 OBJETIVO GERAL
Desenvolver uma ferramenta de avaliação de qualidade de software, tendo por base os critérios definidos pela norma ISO 9126.
1.4 OBJETIVOS ESPECÍFICOS
Especificar os requisitos e elaborar um projeto de software para a ferramenta de avaliação; Desenvolver gráficos de desempenho do software, baseados na IS0 9126 , para se determinar a qualidade do software.
1.5 JUSTIFICATIVA
A importância de um software de qualidade é um tema atual e vem sendo abordada por varias pesquisas, a avaliação hoje é determinante para a venda dos produtos atendendo a satisfação dos usuários. Existe um interesse pessoal de compreender se realmente é possível tornar mais prático um processo tão complexo e como tornar essa avaliação mais fácil de ser entendida e operacionalizada.
1.6 ESTRUTURA DA MONOGRAFIA
Capitulo 1 - Composto pela introdução do trabalho com definição de alguns conceitos e outros pontos importantes na delineação da pesquisa; Capítulo 2 - Composta pela revisão bibliográfica, onde foi realizado um apanhado geral sobre a importância e a história do surgimento e evolução do
16 conceito de qualidade e aplicabilidade do software; fala um pouco também da avaliação dos processos de software (CMM e o CMMI; ISO/IEC-15504, Isso – 9126, entre outros), dos processos propriamente ditos, etc. Capítulo 3 - Descreve a metodologia empregada para realização da pesquisa; Capítulo 4 - Trata das etapas necessárias para a construção da ferramenta; Capitulo 5 - É feita a conclusão sobre o trabalho desenvolvido.
17 2
REVISÃO BIBLIOGRÁFICA
2.1 IMPORTÂNCIA DA QUALIDADE DE SOFTWARE
Software, ou “suporte lógico” não se trata tão somente de um programa mas de uma seqüência de instruções a serem seguidas e/ou executadas, na manipulação, redirecionamento ou modificação de um dado/informação ou acontecimento, necessários para que o programa opere corretamente. Software também é o nome dado ao comportamento exibido por essa seqüência de instruções quando executada em um computador ou máquina semelhante. É também um produto e é desenvolvido pela Engenharia de software, e inclui não só o programa de computador
propriamente
dito,
mas
também
manuais
e
especificações
(SOMMERVILLE, 2007). Ainda segundo Sommerville, (2007, p. 5) “Engenharia de software é uma disciplina de engenharia relacionada com todos os aspectos da produção de software, desde os estágios iniciais de especificação até sua manutenção, depois que este entrar em manutenção”. Para Pressman, (1995, p. 724) qualidade de software está definido como: Conformidade a requisitos funcionais e de desempenho explicitamente declarados, a padrões de desenvolvimento claramente documentados e a características implícitas que são esperadas de todo software profissionalmente desenvolvido.
Um software tem qualidade quando está adequado à organização, ao cliente, ou usuário e atende a padrões de qualidade predefinidos; quando prontos este também terá qualidade se gerar informações adequadas, úteis, precisas, confiáveis, claras, personalizadas e oportunas (REZENDE, 2005). A qualidade de um software está associada a vários atributos que caracterizam os aspectos de uso do mesmo; um programa deve ser fácil de usar, fazer exatamente o que se espera, ser fácil de manter e ter um bom desempenho.
18 2.2 EVOLUÇÃO DOS CONCEITOS DE QUALIDADE
O primeiro grande marco da história da qualidade nos tempos modernos foi a Revolução Industrial. A partir da década de 20, a produção industrial passou a ter um processo de qualidade, com a finalidade de impedir que chegassem prod utos com defeito às mãos dos clientes. Na década de 40 são criados os órgãos ligados à qualidade como a ABNT e a ISO (SODRÉ, 2006). W. Edwards Deming, conhecido como o percussor do movimento da qualidade em nível mundial definiu a qualidade como conformidade de um produto com as especificações técnicas que lhe foram atribuídas. No início da II Grande Guerra sugeriu a aplicação dos princípios do controle estatístico da qualidade à produção de material de guerra. Em 1946 criou uma empresa de consultoria em controle estatístico da qualidade. Em 1947, Deming foi recrutado pelos Supremo Comando das Forças Aliadas para apoiar o desenvolvimento de um recenseamento no Japão. Ao mesmo tempo, formou-se no Japão a União de Cientistas e Engenheiros Japoneses (JUSE), responsável pela difusão dos princípios de qualidade para industria japonesa. Em 1950, Deming foi convidado para uma série de seminários sobre o controle estatístico da qualidade destinados a engenheiros e chefes de produção de empresas japonesas. Em 1951, Joseph Juran que teve um forte impacto no pensamento japonês sobre sistemas de qualidade publicou o livro Quality Control Handbook, onde apresentou o modelo de custos da qualidade, ele definiu qualidade em termos da adequação de um produto à sua utilização pretendida. Esta definição aproximou o conceito de qualidade à perspectiva do cliente ou utilizador (GOMES, 2004). Ainda segundo Gomes (2004), p.12. Em 1956, Armand Feigenbaum propôs a expressão "controle da qualidade total", um reforço da idéia que a qualidade resulta de um esforço de todos os indivíduos que colaboram com uma organização e não de apenas um grupo de projeto. FEIGENBAUM vem dar ênfase à melhoria da comunicação entre departamentos funcionais, em particular a nível de controle de design, controle de materiais e produção, como forma de promover melhorias da qualidade.
Em 1979 Phillip CROSBY trouxe contribuição fundamental para a teoria da qualidade ao defender o conceito de zero defeitos ou produção sem defeito.
19 CROSBY define qualidade em termos de conformidade do produto com as suas especificações técnicas, introduz a idéia de que a qualidade é grátis (GOMES, 2004). Nos anos 80 Kaoru ISHIKAWA teve contribuição importante no desenvolvimento de um conjunto de ferramentas da qualidade, métodos d e apoio à resolução de problemas de qualidade, entre as quais o famoso diagrama de causa-efeito, é também atribuído a ISHIKAWA a idéia de círculos de qualidade, isto é, formação de grupos de trabalho que reúnem periodicamente para discutir e resolver problemas de qualidade que afetam o seu dia-a-dia. ISHIKAWA define gestão de qualidade como o desenvolvimento, produção e serviço de um produto, da forma mais econômica, útil e satisfatória para o consumidor (GOMES, p. 14, 2004).
Segundo Sodré, (2006, p. 14) “Atualmente a satisfação do cliente e a gestão empresarial moderna são as bases da qualidade, mas os bons resultados ainda dependem do uso correto das metodologias pelos desenvolvedores”.
2.3 AVALIAÇÃO DE PROCESSOS DE SOFTWARE
A Avaliação do Processo de Software é empregada para definir o estágio real de um processo de software de uma organização, para determinar os assuntos de mais alta prioridade relacionados ao processo e obter o apoio organizacional para a melhoria do processo de software; são realizadas em um ambiente aberto e colaborativo, seu sucesso depende de um compromisso entre a gerência e seus profissionais de melhorar a organização, o objetivo é levantar problemas e ajudar os gerentes e engenheiros de software a aperfeiçoar sua organização. Para isso é utilizado o questionário que visa focar a equipe de avaliação em pontos dos níveis de maturidade, as entrevistas, estruturadas ou não, funcionam como uma ferramenta para entender o processo de software da organização, além disso, a identificação de questões relacionadas com o processo de software da organização, a “compra da idéia da melhoria”, o foco da organização sobre processo e a motivação e entusiasmo em executar um plano de ação são os resultados mais importantes numa avaliação de processo de software (LINS, 2000).
20 2.3.1 CMM E CMMI
O CMM (Capability Maturity Model) é uma norma criada pelo SEI (Software Engineering Institute) que surgiu para melhorar e avaliar a capacitação de organizações que produzem software, propondo uma melhoria dessas organizações no sentido de aprimoramento contínuo em busca de soluções de problemas relacionadas ao desenvolvimento sistemático e funcional do software (BARRETO, 1999; FIORINE, et. al.; 1998; HUMPHREY, 1997; SEI, 1997; PAULK, et. al., 1995; apud REZENDE, 2005). Com a criação de outros modelos de capacitação, o modelo CMM passou a ser chamado SW-CMM, que propõe a evolução do processo de desenvolvimento de software, a partir de níveis de maturidade a serem atingidos pelas empresas que desejam certificação CMM (SALVIANO, s.d.). O modelo CMM classifica os processos de software em cinco níveis:
Figura 1 - os cinco níveis da maturidade do processo de software Fonte: blogspot.com, 2009
Característica de cada nível segundo Silva e Nascimento, (s,d,): Nível 1 - Inicial: O processo de software é caracterizado como ad hoc. E ocasionalmente até mesmo caótico. Poucos processos são definidos e o sucesso depende do esforço individual (ver figura 2). Não há áreas chave.
21
Figura 2 - Nível 1 do CMM Fonte: Sodré, 2006
Nível 2 - Repetível: Processos básicos de gerenciamento de processo são definidos para se descobrir os custos, o cronograma e as funcionalidades. A disciplina necessária aos projetos está na repetição de sucessos recentes alcançados com aplicações semelhantes, conforme mostra a figura 3. As áreas-chave são: Gerenciamento de requisitos; Planejamento de projeto de software; Acompanhamento de projeto de software; Gerenciamento de subcontrato de software; Garantia de qualidade de software; Gerenciamento da configuração de software (SODRÉ, 2006).
Figura 3 - Nível 2 do CMM Fonte: Sodré, 2006
Nível 3 - Definido: O processo de software tanto para a gerência como para as atividades de engenharia são documentados, padronizados e integrados num processo de software padrão para a organização. Há sete áreas-chave: Enfoque no processo da organização; Definição do processo da organização; Programa de treinamento; Gerenciamento integrado de software; Engenharia de produto de software; Coordenação intergrupos; Revisão (SODRÉ, 2006).
22
Figura 4 - Nível 3 do CMM Fonte: Sodré, 2006
Nível 4 - Gerenciado: Medições detalhadas do processo de software e da qualidade do produto são coletadas. Tanto o processo de software quanto os produtos são entendidos e controlados quantitativamente. Suas
áreas-chave
são:
Gerenciamento
quantitativo
do
processo;
Gerenciamento da qualidade de software (SODRÉ, 2006).
Figura 5 - Nível 4 do CMM Fonte: Sodré, 2006
Nível 5 - Otimização: O melhoramento contínuo do processo torna-se possível devido ao quantitativo feedback do processo e da condução das tecnologias e idéias inovadoras. As três áreas-chave do nível 5 são: Prevenção de defeito; Gerenciamento de mudanças tecnológicas; Gerenciamento de mudanças no processo (SODRÉ, 2006).
23
Figura 6 - Nível 5 do CMM Fonte: Sodré, 2006.
O CMMI (Capability Maturity Model Integration), foi criado pelo SEI em 2002 como um modelo evolutivo em relação a vários modelos CMMs. O CMMI possui uma arquitetura basicamente composta pela definição de um conjunto de áreas de processo, formadas em duas representações diferentes: um modelo por estágio, e um modelo contínuo, como pode ser visto na figura 7; tem por objetivo representar metas e recomendações comuns para orientar a melhoria de processos
em
geral,
não
existindo
soluções
prontas
para
serem
institucionalizadas (LOPES. 2006).
Figura 7 - As duas representações do CMMI Fonte: blogspot, 2008.
O CMMI por estágios não apresenta mudanças em relação ao CMM. Ou seja, a idéia é ir implementando os processos conforme a seqüência dada pelo modelo CMMI DEV. Já a representação contínua possibilita que uma organização tenha sua capacidade avaliada por processos e que cada um tenha níveis diferentes de capacidade (RINCON, 2009).
A versão atual do modelo CMMI 1.2, publicada em 2006, possui 22 áreas de processo distribuídas em 4 níveis de maturidade (CMMI, 2010) e apresenta
24 três modelos: CMMI for Development (CMMI-DEV) publicada em agosto de 2006, dirige-se ao processo de desenvolvimento de produtos e serviços; CMMI for Acquisition (CMMI-ACQ) publicada em novembro de 2007, dirige-se aos processos de aquisição e terceirização de bens e serviços e CMMI for Services (CMMI-SVC) publicada em fevereiro de 2009, dirige-se aos processos de empresas prestadoras de serviços (SÉZIO, 2009). Nos dois modelos (CMM e CMMI), a Garantia da Qualidade envolve diversos papéis e grupos, tais como Equipes de Qualidade, Equipes de Desenvolvimento, Grupo de Engenharia de Processo, Líderes de projeto e Gerente sênior. Todos estes papéis participam de um conjunto extenso de atividades. Portanto, é muito grande a utilidade de um sistema de informação que auxilie na realização das atividades de GQS (garantia de qualidade de software) (POSSA, s.d.).
2.3.2 ISO/IEC-15504 - (spice)
A International Organization for Standardization/International Electrotechnical Commission (ISO/IEC) – 15504 também conhecida como Software Process Improvement and Capability determination (SPICE) representa um guia para avaliação da maturidade, tem uma disposição semelhante a representação contínua do CMMI, onde a avaliação é separada por processos (ver figura 8) (PAULA FILHO, 2009). Esta norma define um modelo bi-dimensional que tem por objetivo a realização de avaliações dos processos de software com foco na melhoria desses processos, gerando um perfil dos mesmos e identificando seus pontos fracos e fortes, que serão utilizados para a elaboração de um plano de melhorias e a determinação da capacidade dos processos, viabilizando a avaliação de um fornecedor em potencial, gerando o seu perfil de capacidade para decidir contratar seus serviços (BERNADO e BECERRA, 2005).
25
Figura 8 - Utilização da ISO/IEC 15504 Fonte:.blogspot, 2008.
A abordagem em duas dimensões do SPICE possibilita uma forma de avaliação mais detalhada, permitindo estabelecer um nível de capacitação diferente para cada processo dentro de uma organização. Devido às suas dimensões de processo e de capacidade de processo, o SPICE é muito mais flexível e acomoda o conceito de evolução do nível de capacidade de qualquer processo, conforme mostrado na figura 9. Pode-se dizer inclusive que um dos preços desta flexibilidade se traduz na inexistência de um roteiro claro para a melhoria (COPYRIGHT, 2003).
Níveis de Capacidade: Otimizando
Métrica para avaliação e Previsível
roteiro para melhoria, ... Estabelecido Gerenciado Executado Incompleto
1
0 Processo não existe ou geralmente falha
Processo atinge os objetivos, porem sem padrão de qualidade e sem controle de prazos e custos
Figura 9 - Níveis de capacidade SPICE. Fonte: Sodré, 2006.
Processo planejado e acompanhando, e satisfaz requisitos definidos de: qualidade, prazo, e custos, e seus produtos de trabalho são gerenciados
4
3
2 Processo executado e gerenciado com uma adaptação de um processo padrão definido, eficaz e eficiente
5
Processo executado dentro de limites de controle definidos e com medições detalhadas e analisadas
Processo melhorado continuamente de forma disciplinada
... baseados na capacidade do processo
26 O spice pode ser usado por organizações envolvidas no planejamento, gestão, monitoramento, controle e melhoria de processos para aquisição, fornecimento, desenvolvimento, operação, evolução e suporte de software, o propósito de uso destina-se
a
autocompreensão
do
estado
de
processos
de
software,
autodeterminação de adequabilidade, de processos para determinados requisitos e determinação da adequabilidade dos processos de uma organização no atendimento a um contrato particular (FERNANDES, 2004).
2.3.3 ISO
A ISO (Organização Internacional para Padronização) tem por objetivo promover o desenvolvimento de normas, testes e certificação, com a finalidade de encorajar o comércio de bens e serviços. Esta organização é composta por representantes de 91 países, cada um, representado por um mecanismo de normas, testes e certificação. A ISO 9000 é uma série de cinco normas internacionais sobre o gerenciamento e a garantia da qualidade, que compreende a ISO 9000, ISO 9001, ISO 9002, ISSO 9003 e ISO 9004 (HUTCHINS, 1994).
2.4 AVALIAÇÃO DE PRODUTOS – ISO 9126
A Norma ISO/IEC 9126 trata da avaliação de um produto de software para verificação de sua qualidade, essa verificação é feita através de técnicas e atividades operacionais, que vêem o quanto os requisitos são atendidos; esses requisitos são demonstrados a partir das necessidades, explicitados em termos quantitativos ou qualitativos, e têm como objetivo a definição de características de um software, permitindo assim a análise de seu entendimento (ANJOS e MOURA, s.d.). Esta norma é composta das seguintes partes (SOUZA, 2006):
ISO/IEC 9126-1: Modelo de Qualidade;
ISO/IEC 9126-2: Métricas Externas;
27
ISO/IEC 9126-3: Métricas Internas;
ISO/IEC 9126-4: Métricas de Qualidade em Uso.
A avaliação do produto de software é um dos processos no ciclo de vida de desenvolvimento de software. A sua qualidade pode ser avaliada pela medição dos atributos internos, ou pela medição dos atributos externos, e ainda pela medição dos atributos de qualidade em uso e tem por objetivo que o produto tenha o efeito desejado em um contexto particular de uso, como pode ser visto na figura 10 (MACHADO e SOUZA, s.d.).
Modelo de Qualidade
Produto de Software
Processo influencia Qualidad e de processo
influencia
Atributos de qualidade interna
depende de
Atributos de qualidade externa
depende de
influencia
Atributos de qualidade no uso
depende de Contextos de uso
Medidas do processo
Medidas internas
Medidas externas
Medidas de qualidade no uso
19 Maio 2006
Figura 10 - Modelo de qualidade ISO 9126-1 Fonte: Souza, 2006
A Norma ISO / IEC 9126-1 define seis características de qualidade de software que devem ser avaliadas e são mais bem explicadas na tabela 1:
Funcionalidade;
Usabilidade;
Confiabilidade;
Eficiência;
Manutenibilidade;
Portabilidade.
Para Machado e Souza, (s.d.) “A qualidade do produto de software deve ser decomposta para um modelo de qualidade com características e subcaracterísticas
6
28 que podem ser usadas como um checklist de assuntos relacionados à qualidade”, essas características podem ser vistas nos quadros 1 e 2 descrita abaixo.
Característica
Significado
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. Evidencia a capacidade do produto de manter seu desempenho ao longo do tempo e em condições estabelecidas. Evidencia a facilidade para a utilização do produto
Satisfaz às necessidades? É imune a falhas? É 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 um ambiente para outro
É fácil de usar em outro ambiente?
Confiabilidade Usabilidade
Quadro 1 - Características da Qualidade de Software Fonte: Anjos e Moura, s.d.
A NBR ISO/IEC 9126 permite que a qualidade do produto de software seja especificada e avaliada em diferentes perspectivas pelos envolvidos com aquisição, requisitos, desenvolvimento, uso, avaliação, apoio, manutenção, garantia de qualidade e auditoria de software. Ela pode, por exemplo, ser utilizada por desenvolvedores, adquirentes, pessoal de garantia de qualidade e avaliadores independentes, particularmente os responsáveis por especificar e avaliar qualidade do produto de software (NBR 9126, 2003)
29 Característica Subcaracterística Funcionalidade
Confiabilidade
Usabilidade
Eficiência
Manutenibilidade
Portabilidade
Pergunta chave para a subcaracterística
Adequação Acurácia Funcionalidade
Propõe-se a fazer o que é apropriado? Faz o que foi proposto de forma correta? Interoperabilidade Interage com os sistemas especificados?
Conformidade
Está de acordo com as normas, leis etc?
Segurança de acesso Maturidade
Evita acesso não autorizado aos dados? Com que freqüência apresenta falhas?
Tolerância a falhas Recuperabilidade Inteligibilidade
Ocorrendo falhas, como ele reage? É capaz de recuperar dados em caso de falha? É fácil entender o conceito e a aplicação?
Apreensibilidade
É fácil aprender a usar?
Operacionalidade Tempo
É fácil de operar e controlar? Qual é o tempo de resposta, a velocidade de execução?
Recursos
Quanto recurso usa? Durante quanto tempo?
Analisabilidade
É fácil de encontrar uma falha, quando ocorre?
Modificabilidade Estabilidade
É fácil modificar e adaptar? Há grande risco quando se faz alterações?
Testabilidade
É fácil testar quando faz alterações?
Adaptabilidade Capacidade para ser instalado Conformidade
É fácil adaptar a outros ambientes? É fácil instalar em outros ambientes?
Capacidade para substituir
É fácil usar para substituir outro?
Está de acordo com padrões de portabilidade?
Quadro 2 – Sub-características da Qualidade de Software Fonte: Anjos e Moura, s.d.
Métricas de software são medidas associadas ao processo ou ao produto de software, incluindo à sua documentação elas permitem a quantificação, que por sua vez produz a avaliação da qualidade e comparação entre técnicas e processos. Tem como objetivo (SOUZA, 2004): •
Definir requisitos de qualidade
•
Medir e melhorar a qualidade de produtos intermediários
•
Controlar a qualidade do produto
•
Permiti tomar decisões quanto a aceitação ou não do produto
As métricas externas podem ser usadas para medir a qualidade do produto de software através da medição de seu comportamento em um sistema do qual ele faça parte podem ainda ser usadas apenas durante os estágios de teste do processo de
30 ciclo de vida ou durante qualquer estágio operacional. Consegue-se isso executando o software no ambiente de sistema ao qual ele pretende se encaixar (MACHADO e SOUZA, s.d). As métricas internas segundo Machado e Souza, (s.d., p.10) podem ser aplicadas a um produto de software não executável, durante os seus estágios de desenvolvimento. Elas proporcionam ao usuário a habilidade de medir a qualidade nas fases intermediárias e, assim, predizer a qualidade final do produto. Isso permite ao usuário detectar falhas e tomar as ações corretivas durante os estágios iniciais de desenvolvimento.
As métricas de qualidade em uso medem o quanto que o produto agrega das necessidades de usuários específicos, para a obtenção dos resultados esperados com efetividade, produtividade, segurança e satisfação, em um contexto de uso estabelecido. (MACHADO e SOUZA, s.d). MÉTRICAS DE QUALIDADE DE USO Eficácia nas tarefas Eficácia
Qual a proporç ão da tarefa está completa correctamente? Qual a proporç ão da tarefa que está completa?
Conclus ão da tarefa
Qual a frequência com a qual aparecem erros ?
Frequência de erros Saúde e segurança do utilizador Segurança
Segurança de pessoas afectadas pelo uso do sistema
Qual a incidência de problemas de saúde dos utilizadores que utilizam o sistema? Qual a incidência de perigo para as pessoas que utilizam o sistema? Qual a incidência de danos económicos? Qual a incidência de corrupção no software?
Danos económicos Danos do Software Quanto tempo demora a completar a tarefa? Proporção de produtividade
Quanto tempo, espera o utilizador pela resposta do sistema?
Produtividade/Economia
Qual a eficiência dos utilizadores?
Eficiência da tarefa Produtividade Tempo de espera Tempo da tarefa
Quais os custos com os utilizadores? Qual a proporç ão de tempo que o utilizador gasta a desenvolver acções produtivas? Qual a frequência com que se utiliza a ajuda do software?
Trequência de ajuda Qual a satisfaç ão do utilizador? Escala de satisfação Satisfação
Questionário de satisfação Uso do sistema
Quadro 3 – Métricas de qualidade de uso
O utilizador está satisfeito com as características do software? Qual a proporç ão de potenciais utilizadores do sistema?
31 2.5 OUTRAS NORMAS PARA A AVALIAÇÃO DE PRODUTOS
Os aspectos técnicos para avaliação da qualidade do produto de software estão alicerçados em três Normas descritas abaixo por Anjos e Moura, (s.d.): ISO/IEC 9126 – Características de Qualidade de Software (NBR13596); ISO/IEC 14598 – Guias para Avaliação de Produto de Software (ISO14598); e ISO/IEC 12119 – Requisitos de Qualidade e Testes de Pacotes de Software [NBR12119]. A visão de processo, apoiada nos modelos de referência SPICE, CMMI, e normas ISO/IEC 12207 e série ISO 9000, trata da avaliação e melhoria dos processos utilizados para o ciclo de vida do software. A 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 (ANJOS; MOURA, p. 2 s.d.).
Segundo Anjos e Moura, (s.d.) essas normas, geradas e constantemente revisadas pelo ISO/IEC, são traduzidas para a versão brasileira, através da ABNT Associação Brasileira de Normas Técnicas, e em alguns casos, assumem códigos diferentes, a exemplo da Norma ISO/IEC 9126 que foi traduzida com o código NBR 13596.
2.6 PROCESSOS DE ENGENHARIA DE SOFTWARE
Um modelo de processo de software é uma representação abstrata de um processo de software. Cada modelo de processo representa um processo a partir de uma perspectiva particular, de uma maneira que proporciona apenas informações parciais sobre o processo (SOMMERVILLE 1995 apud LESSA e JUNIOR, 2002). Um modelo para um processo de desenvolvimento é uma proposta teórica que junto ao planejamento deve determinar quais atividades devem ser realizadas, enquanto isso, o processo deve determinar ações práticas a serem realizadas pela equipe como prazos definidos e o resultado do planejamento que precisa ser gerenciado no decorrer de sua execução.
32 Segundo Sommerville, (2007, p. 43) “Não existe processo ideal, e várias organizações
desenvolveram
abordagens
inteiramente
diferentes
para
o
desenvolvimento de software. [...] Os processos de software podem ser aprimorados por meio de padronização de processos, no qual a diversidade de processos de software ao longo da organização é reduzida. Alguns dos mais conhecidos modelos do processo de desenvolvimento são o modelo Cascata, o modelo Evolutivo, o modelo Incremental, o modelo Espiral, o modelo Transformação, o modelo XP (eXtreme Programming), e RUP (Processo Unificado da Rational) (LEITE, 2004).
2.6.1 Modelagem De Negócio
A modelagem de negócio é uma técnica que veio pra auxiliar os analistas, na coleta exata de requisitos de uma empresa, afim de suprir todas as necessidades da mesma. A finalidade de modelar um negócio é criar uma abstração, que é uma visão simplificada do negócio, um modelo de negócio mostra qual é o ambiente da organização e como a organização age em relação a este ambiente. Por ambiente entende-se tudo com o que a organização interage para realizar os seus processos de negócio, tais como clientes, empregados, parceiros (TEXEIRA; RAMOS; ZARU, 2004).
2.6.2 Especificação De Requisitos
Carpena e Kirner, (1998, p.1) relatam que “A especificação de requisitos é uma etapa essencial do processo de desenvolvimento de software, que compreende uma definição completa do comportamento externo do sistema de software”, tem como objetivo obter produtos de software de melhor qualidade que satisfaçam às reais necessidades dos clientes dentro de prazo e orçamento adequados. Pode-se entender requisito como uma função, restrição ou propriedade que deve ser fornecida, encontrada ou atendida para satisfazer às necessidades do usuário do sistema. Especificar um requisito implica em compreender exatamente o que deve ser feito e o que se espera receber como resultado.
33 Os requisitos podem ser classificados em funcionais - descrevem as funcionalidades do sistema desejadas pelos clientes ou seja o que se espera que o software faça; e não-funcionais - São as qualidades e restrições globais do sistema relacionados
com
manutenção,
uso,
desempenho,
custo ,
interface,
etc.
(MACORATTI, 2007). Existem ainda segundo Sommerville (2007, p. 80, 85 e 87), os requisitos de usuário, que “são declarações, em uma linguagem natural com diagramas, de quais serviços são esperados do sistema e as restrições sob as quais ele deve operar [...], devem descrever os requisitos funcionais e não funcionais, de modo q ue eles sejam compreensíveis pelos usuários do sistema que não possuem conhecimento técnico detalhado”. E os requisitos de sistema, “que definem detalhadamente, as funções, os serviços, e as restrições operacionais do sistema, deve ser preciso e deve definir exatamente o que será implantado [...] são versões expandidas dos requisitos de usuário pelos engenheiros de software, como ponto de partida para o projeto do sistema”.
2.6.3 Projeto De Software
O projeto de uma aplicação, expressa como a aplicação deve ser construída, ela descreve as partes envolvidas e como elas devem ser montadas; um projeto é construído
a
partir
de requisitos.
Uma
notação
extremamente
útil
para
documentação de projeto é a linguagem unificada de modelagem (UML – Unified Modeling Language) (BRAUD, 2004). Segundo Braud, (2004, p.43) Um projeto de software é um conjunto de documentos cuja base, uma aplicação de software, pode ser totalmente programada, ou seja, um projeto de software completo deve ser explicito o suficiente para que o programador possa codificar a aplicação a partir dele, sem a necessidade de quaisquer outros documentos.
O projeto de software é a fase técnica mais importante do processo de engenharia de software e é aplicado independentemente do paradigma de desenvolvimento usado, seu inicio se dá tão logo os requisitos de software tenham sido analisados e especificados, sua importância se estabelece a partir da qualidade
34 que deve estar presente durante todo processo de desenvolvimento. O projeto é a primeira dentre as três atividades técnicas – projeto, codificação e teste (PRESSMAN, 1995).
2.6.4 Codificação
A codificação, uma implementação criptográfica, consiste na conversão de dados numa combinação aparentemente incompreensível de caracteres que, quando visualizados, impedem a leitura dos dados como texto simples, na codificação de armazenamento, as cifras mais comuns incluem a substituição aleatória, substituindo todas as letras numa mensagem esta forma de codificação é muito utilizada, devido à sua simplicidade e fiabilidade. (CODIFICAÇÃO, s.d.). Quando considerada como um passo do processo de engenharia de software, a codificação é vista como uma conseqüência natural do projeto, porém, as características da linguagem de programação e o estilo de codificação podem afetar profundamente a qualidade e a manutenibilidade do software. A qualidade de um projeto de software é estabelecida independente das características da linguagem de programação, porém os atributos da linguagem desempenham um papel na qualidade um projeto implementado e afetam a maneira segundo o qual o projeto é especificado (PRESSMAN, 1995). Por codificação entende-se digitar o código fonte comentado, interpretá-lo completamente antes da copilação para assegurar que ele faz o que é concebido para fazer, copilá-lo para então executá-lo com outro código com base nos casos de teste informais. As palavras “implementação e “programação” também são usadas para codificação (BRAUD, 2004, p. 29).
2.6.5 Testes
Desde os primeiros computadores comerciais, os softwares lançados no mercado, tem se caracterizado por apresentarem um grande número de defeitos que afetam sua usabilidade, confiabilidade, funcionalidade e segurança, o que gerou um
35 grande impacto na decisão dos negócios, resultando, na maioria das vezes em prejuízos, devido a perda de participação no mercado (RIOS; MOREIRA, s.d.). A fase de teste consiste em fornecer entrada a aplicação e em comparar a saída com aquela determinada pela especificação de software (BRAUD, 2004). Portanto “teste de software é um processo que visa a sua execução de forma controlada, com objetivo de avaliar o seu comportamento baseado no que foi especificado. A execução dos testes é considerada uma avaliação” (RIOS e MOREIRA, s.d.). O teste é indispensável porque ajuda a descobrir defeitos; prova a presença de erros (Bugs), e nunca a sua ausência. (BRAUD, 2004). A atividade de teste é uma das mais utilizadas para fornecer evidências da confiabilidade do software em complemento a outras atividades, como por exemplo o uso de revisões e de técnicas formais e rigorosas de especificação e de verificação. O conjunto de informação proveniente da atividade de teste é significativo para as atividades de depuração, manutenção e estimativa de confiabilidade de software (BARBOSA; MALDONADO; VICENZI, et.al. 2000). Ainda segundo Barbosa, Maldonado e Vicenzi et.al. (2000, p. 02) O teste de produtos de software envolve basicamente quatro etapas: planejamento de testes, projeto de casos de teste, execução e avaliação dos resultados dos testes. Essas atividades devem ser desenvolvidas ao longo do próprio processo de desenvolvimento de software, e em geral, concretizam-se em três fases de teste: de unidade, de integração e de sistema.
O teste de software envolve algumas estratégias de teste elas incluem um teste estático x o teste dinâmico e um teste de caixa branca x o de caixa preta. O teste de análise dinâmica requer que o software seja executado com os dados de teste é baseado na utilização de provas inseridas em um programa; o teste estático não requer que o software seja executado com dados de tempo, abrange uma demonstração do programa, além de uma execução simbólica, análise de irregularidades, inspeção e revisão de código, seu objetivo é analisar um sistema de software e deduzir a operação atual correspondente como conseqüência lógica das decisões do projeto; os testes caixa preta também denominada teste funcional tem como ponto de partida uma especificação ou código fonte, sendo código, os dados de teste estimulam o software a verificar se são fornecidas as funções desejadas, as respostas produzidas são específicas e o conteúdo da caixa é oculto, tem uma
36 abordagem que enfatiza entradas, saídas e princípios funcionais de um modulo de software; já o teste caixa branca também conhecido como teste estrutural, enfatiza o projeto detalhado do software, nesse tipo de teste as instruções, os caminhos, e as ramificações são executados para fins de execução correta, o teste estrutural trata da estrutura de código para um módulo de software (PETERS, 2001).
2.6.6 Implantação
Segundo Sommerville, (2003, p. 47) “O estágio de implementação do desenvolvimento de software é o processo de conversão de uma especificação de sistema em sistema executável. Esse estágio sempre envolve processos de projeto e programação de software” [...] “Um projeto de software é uma descrição de estrutura de software a ser implementada, dos dados que são parte do sistema, das interfaces entre os componentes do sistema e, algumas vezes, dos algoritmos utilizados”. A implementação realiza o desenho de um sistema em termos de diversos tipos de código fonte e código binário, conforme as tecnologias escolhidas. Classes e outros elementos de desenho internos são transformados, de maneira mais ou menos automatizada, em unidades de implementação, geralmente construídas de arquivos de códigos fonte (PAULA FILHO, 2009, p. 410).
2.6.7 Manutenção
De acordo com Brusamolin (2004, p. 10) “Manutenção de software é a totalidade de atividades necessárias para prover minimizando o custo suporte a um software”. As atividades são desenvolvidas tanto nos estágios pré entrega quanto no pós entrega. Peters, (2001, p. 568) relata que “Durante o desenvolvimento de software, um engenheiro adota uma sequência de atividades que produzem uma variedade de documentos que culminam na versão de um programa de computador executável”. Ainda segundo Peters, “Para os grandes sistemas de software, a fase de
37 manutenção tende a ser mais duradoura do que a combinação das fases de ciclo de vida anteriores”. São identificados três tipos de tarefas de manutenção: Correção, onde a tarefa de manutenção tem como objetivo efetuar reparos no código, decorrentes de erros no sistema; Adaptação, onde a tarefa de manutenção resulta em mudanças no ambiente no qual o sistema irá operar; e aperfeiçoamento, onde a manutenção ocorre de modo a envolver todas as mudanças, inserções, exclusões, modificações, extensões e aprimoramentos efetuados em um sistema de forma a satisfazer às novas necessidades do usuário (PETERS, 2001).
38 3
METODOLOGIA
3.1 TIPOS DE PESQUISA QUANTO AOS OBJETIVOS
Trata-se de uma pesquisa do tipo descritivo exploratório, para Gil, (2002), a pesquisa descritiva tem como objetivo descrever as características de certa população ou acontecimento ou o estabelecimento de relações entre variáveis, a pesquisa exploratória tem por objetivo fazer com que o pesquisador se torne mais intimo do problema a ser investigado fazendo com que ele consiga aprimorar suas idéias ou fazer novas intuições. Para Lakatos e Marcone, (2007), trata-se de investigações empíricas, que tem como objetivo formular questões ou problemas, tendo como finalidade desenvolver hipóteses, aumentar a familiaridade do pesquisador com o ambiente, fato ou fenômeno pesquisado para realização de uma pesquisa mais precisa.
3.2 TIPO DE PESQUISA QUANTO AOS PROCEDIMENTOS TÉCNICOS
Com relação aos procedimentos técnicos, esse estudo se caracteriza por ser uma pesquisa do tipo experimental. É experimental, pois, determina um objeto de estudo e seleciona variáveis no qual poderiam influenciar o resultado desse mesmo estudo, e, além disso, define maneiras de se observar os efeitos que essas variáveis podem produzir no objeto de estudo (GIL, 2002).
3.3 TIPOS DE PESQUISA QUANTO Á ABORDAGEM
Quanto à abordagem, trata-se de uma pesquisa qualitativa e quantitativa. Segundo Lakatos e Marcone, (2010, pg. 269) na pesquisa qualitativa o autor preocupa-se em “analisar e interpretar aspectos mais profundos, descrevendo a
39 complexidade do comportamento humano. Fornece análise mais detalhada sobre as investigações, hábitos, atitudes, tendências de comportamento etc.”. Já na pesquisa quantitativa, Minayo (1994) diz que o autor se preocupa em utilizar a questão da objetividade traduzindo em dados matemáticos e utilizando a linguagem de variáveis para especificar atributos e qualidades do objeto do qual se está investigando.
3.4 ETAPAS DA PESQUISA
Primeiramente foi feita uma pesquisa em busca de alguma ferramenta de avaliação de qualidade de software no mercado, porém foi encontrado apenas ferramentas de avaliação de software especifico como, por exemplo: ferramenta para avaliar software educacional, com isso não pode ser abstraído nenhum conteúdo dessa busca. Em seguida foi feito um estudo da norma ISO/IEC 9126, visando utilizar suas características e métricas no critério de ava liação da ferramenta. Por fim, a ferramenta foi criada seguindo esses padrões da norma. A Elaboração da pesquisa se deu no período de março à maio onde foi definido o problema a ser investigado, os objetivos da pesquisa e a busca por bibliografias que desse sustentabilidade a idéia abordada. Nesse período foi realizada também a construção da ferramenta tendo por base a norma ISO/IEC – 9126, verificando as interfaces que melhor se adequaram ao projeto proposto visando usabilidade ao sistema.
3.5 INSTRUMENTOS DA PESQUISA
Para o desenvolvimento da ferramenta foram utilizados:
Banco de dados: PostgreSQL (conforme figura 11);
UML: Ferramenta jude (conforme figura 12);
Linguagem: Java (Swing)
Sistema Operacional: Multiplataforma
40 4
CONSTRUÇÃO DA FERRAMENTA
4.1 DESCRIÇÃO DA FERRAMENTA
A ferramenta QUALITYSOFT-FAINOR tem como principal objetivo avaliar a qualidade de um software de qualquer área, analisando-se as características, subcaracterísticas e métricas contidas na ISO/IEC (9126). Após um estudo detalhado da norma ISO/IEC 9126 foi desenvolvida uma ferramenta para avaliação da qualidade de software. Conforme a norma ISO/IEC 9126 (ABNT, 1996), ainda existe poucas métricas de aceitação geral, o que torna possível estabelecer modelos próprios de processo de avaliação e métodos para a criação e validação de métricas relacionadas com as características dessa norma para atender as diversas áreas de aplicação. Com essa informação, a criação da ferramenta foi embasada em modelos próprios de avaliação, analisando sempre a necessidade em especifico do avaliador em relação ao software. A QUALITYSOFT-FAINOR foi desenvolvida visando trazer usabilidade do sistema. Todas as opções de cadastro e operações podem ser alteradas de acordo com os critérios e as necessidades do usuário. Visando uma avaliação minuciosa, o usuário terá a “liberdade” de cadastrar seu próprio critério de avaliação, atribuindo valores aos quesitos aplicados, determinando o peso de todas as características e métricas, de acordo com as especificações e necessidades do software avaliado. Após todos os quesitos devidamente respondidos serão gerados gráficos determinando a qualidade do software. A fórmula utilizada pela QUALITYSOFT-FAINOR para avaliar a qualidade do software, leva em consideração todas as características e sub-caracteristicas presentes na norma ISO/IEC 9126. O cálculo foi feito da seguinte forma:
PSC = Peso da Sub-Característica (Atribuído pelo Usuário) Obs.: A soma dos Pesos das Sub-características de uma Característica deve ser igual a 100.
41 VNSC = Valor da nota da Sub-Característica (0<=VNSC<1) (Atribuído pelo usuário) NSC = Nota da Sub-Característica NSC = PSC*VNSC
PC = Peso da Característica (Atribuído pelo usuário) Obs.: A soma dos Pesos das Características de um tipo de Características deve ser igual a 100.
NC = Nota da Característica NC = Soma da NSC´s
NTC = Nota do tipo de Característica NTC = Soma dos NC´s
QTC = Quantidade de Tipos de Características
NF = Nota Final NF = ( SOMA dos NTC´s )/QTC
Diante do exposto, serão apresentadas as interfaces gráficas da ferramenta detalhadamente explicadas (ver figuras da seção 4.3) sendo gerados gráficos (relatórios de avaliação) (ver Apêndice).
4.1.1 Banco de Dados
O banco de dados é uma coleção de dados que estão relacionados entre si tendo um significado implícito. Por exemplo, considere nomes, telefones e endereços de pessoas que você conhece onde estes dados serão gravados no celular ou num computador pessoal. Esta coleção de dados que foram relatados de forma implícita é um banco de dados. Resumindo, o banco de dados é onde nós guardamos todos os dados que pertencem ao nosso sistema. Existem muitas
42 estratégias para a sua organização facilitando o acesso e manipulação dos dados. Um sistema de gerenciamento de banco de dados (Database Management System) disponibiliza de mecanismos para armazenar, organizar, recuperar e modificar os dados (ELMARST 2008). Os sistemas populares de hoje são os bancos de dados relacionais. A linguagem SQL (Structured Query Language) é uma linguagem-padrão internacional utilizada quase universalmente com banco de dados relacionais para realizar consultas e manipular dados. Para a construção da ferramenta foi utilizado o banco de dados PostgreSQL por possuir muitos recursos que só são encontrados em grandes bancos de dados que custam caro. Além de ser gratuito, possui o código fonte aberto, ou seja, pode ter suporte por outras empresas alem dos desenvolvedores, podendo ser alterado de acordo aos ajustes necessários para a sua melhora. A figura 11 mostra o Diagrama ER (Entidade-Relacionamento) referente ao Banco de Dados da QUALITYSOFT-FAINOR.
Figura 11 - Diagrama ER do banco de dados
43 4.1.2 UML (Uniefied Modeling Langage)
Segundo gilleanes (2004), a UML (Linguagem De Modelagem Unificada) é uma linguagem visual utilizada para modelar sistemas computacionais orientados a objeto. A figura 12 ilustra o digrama de caso de uso da aplicação. Logo em seguida será apresentada a descrição de cada caso de uso.
Figura 12 - Diagrama de caso de uso da aplicação
Manter Empresa : Fluxo básico
Usuário acessa o menu cadastro, selecionando o item “empresas”;
Sistema exibe interface de cadastro de empresas;
Usuário acessa a seção de cadastro da empresa;
Usuário fornece dados cadastrais;
Sistema responde a confirmação do cadastro.
44 Manter software: Fluxo básico
Usuário acessa o menu cadastro, selecionando o item “softwares”;
Sistema exibe interface de cadastro de softwares;
Usuário acessa a seção de cadastro de softwares;
Usuário fornece dados cadastrais;
Usuário seleciona empresa cadastrada associando ao software;
Sistema responde a confirmação do cadastro.
Manter Avaliador: Fluxo básico
Usuário acessa o menu cadastro, selecionando o item “ Avaliadores”;
Sistema exibe interface de cadastro de avaliadores;
Usuário acessa a seção de cadastro de avaliadores;
Usuário fornece dados cadastrais;
Sistema responde a confirmação do cadastro.
Manter tipos de características: Fluxo básico
Usuário acessa o menu cadastro, selecionando o item “Tipos de
características”;
Sistema exibe interface de cadastro de Tipos de características;
Usuário acessa a seção de cadastro de Tipos de características;
Usuário fornece dados cadastrais;
Sistema responde a confirmação do cadastro.
Manter Métodos de Avaliação: Fluxo básico 1. Usuário acessa o menu avaliações, selecionando o item “Método de Avaliação”; 2. Sistema exibe interface de Método de Avaliação; 3. Usuário acessa a seção de Método de Avaliação; 4. Usuário fornece dados cadastrais na aba “Dados Gerais”; 5. Sistema responde a confirmação do cadastro;
45 6. Usuário acessa seção alterar dados gerais; 7. Usuário fornece dados cadastrais na aba “pesos”; 7.1. Usuário seleciona o tipo de método avaliativo; 7.2. Usuário
seleciona
a
aba
“características”,
fornecendo
a
característica do método avaliativo e seu respectivo peso 7.3. Usuário seleciona a aba” sub-características” e informa os dados cadastrais; 8. Usuário fornece dados cadastrais na aba “Resultados”; 9. Sistema responde a confirmação dos dados. Avaliar Software: Fluxo básico Usuário
acessa
o
menu
avaliações,
selecionando
o
item
“Avaliações”; Sistema exibe interface de avaliações ; Usuário acessa a seção de avaliações; Usuário seleciona software a ser avaliado; Usuário seleciona método para avaliação; Usuário seleciona avaliador; Sistema exibe data da avaliação; Usuário acessa a seção do questionário e responde as perguntas; Usuário acessa a seção e solicita o relatório; Sistema exibe relatório final de avaliação.
Conforme a descrição dos casos de uso, vale ressaltar que não foram detalhados fluxos alternativos e exceções, para apresentar uma melhor forma de entendimento da ferramenta. Todas as interfaces gráficas referentes aos casos de uso descritos serão apresentadas na seção 4.2.
46 4.1.3 Linguagem
A linguagem de programação utilizada foi Java, por ser uma linguagem totalmente independente de plataforma e ter suporte a Modelagem OO (Orientação a Objetos) trazendo menos trabalho ao programador além de facilitar a manutenção do software. Foi utilizada a API Java Swing por ser destinada a interface gráfica.
4.2 INTERFACES DA FERRAMENTA
Ao executar o aplicativo, será apresentada a tela inicial da QUALITYSOFTFAINOR, que possui o menu cadastro , com as opções de cadastrar Empresas,Softwares,Avaliadores,Tipos de Características,Características e subcaracterísticas. Contém o menu Avaliações onde se cadastram as opções Método de Avaliação e Avaliações, e finalmente o menu Ajuda com o e-mail do desenvolvedor da ferramenta, caso haja duvidas em relação a aplicação da mesma. (Conforme figura 13).
Figura 13 - Tela de apresentação da ferramenta
47 Ao acessar o menu cadastro e selecionar a opção “Empresas”, o usuário poderá cadastrar a empresa do software a ser avaliado através do item “Novo”, e logo em seguida armazená-lo com a opção “Salvar”. Caso queira modificar o nome da empresa, basta ao usuário acessar o item “Alterar” e para excluir o item “Excluir”. (Conforme figura 14).
Figura 14 - Tela de visualização do cadastro de empresas
Ao acessar o menu cadastro e selecionar a opção “Softwares”, o usuário poderá cadastrar o software a ser avaliado através do item “Novo”, e logo em seguida armazená-lo com a opção “Salvar”. Caso queira modificar o nome do software, basta ao usuário acessar o item “Alterar” e para excluir o item “Excluir”. (Conforme figura 15).
48
Figura 15 - Tela de apresentação do cadastro de softwares
Ao acessar o menu cadastro e selecionar a opção “Avaliadores” , o usuário poderá cadastrar o avaliador através do item “Novo”, e logo em seguida armazenálo com a opção “Salvar”.Caso queira modificar o nome do avaliador , basta ao usuário acessar o item “Alterar” e para excluir o item “Excluir”. Conforme figura 16.
Figura 16 - Tela para cadastro dos avaliadores
49 Ao acessar o menu cadastro e selecionar a opção “Tipos de Características”, o usuário irá visualizar os tipos de métricas existentes (conforme figura-17) , que serão utilizadas na avaliação final do software. As métricas citadas fazem parte da norma IS0/IEC 9126, portanto não devem ser alteradas, para não perder o critério avaliativo.
Figura 17 - Tela de apresentação dos tipos de características
Ao acessar o menu cadastro e selecionar a opção “Características” , o usuário irá visualizar as características existentes na ISO/IEC 9126 e suas respectivas métricas (conforme figura - 18). As características citadas fazem parte da norma IS0/IEC 9126, portanto não devem ser alteradas, para não perder o critério avaliativo.
50
Figura 18 - Tela de descrição das características
Ao acessar o menu cadastro e selecionar a opção “Sub-características” , o usuário irá visualizar as sub-características contidas dentro de cada característica existente
na ISO/IEC 9126 e suas respectivas métricas (conforme figura-19). O
usuário poderá selecionar todas as sub-características (uma por vez) e acessar o item “Alterar”, logo após será aberta uma janela com as opções “Dados Gerais” contendo o nome e a pergunta referente à sub-característica selecionada (conforme figura 20), e a opção “Respostas” onde o usuário poderá cadastrar a nota através do item “Valor:”, e a descrevê-la através do item ”Descrição:” para cadastrar esses dois itens o usuário deve selecionar a opção “Adicionar” e logo em seguida em “Salvar” (conforme figura 21). Com isso o usuário poderá fazer o cadastro de pontuação da forma que melhor lhe convier em relação ao software avaliado.
51
Figura 19 - Tela da descrição das sub-características
52
Figura 20 - Tela de apresentação dos dados gerais referentes as sub-cacterísticas
Figura 21 - Tela de apresentação das respostas referente as sub-características
Ao acessar o menu “Avaliações”, o usuário deverá definir o método de avaliação selecionando a opção
“Métodos de Avaliação”, inserindo o método
desejado através do item “Novo” (conforme figura 22).
53
Figura 22 - Tela de apresentação dos métodos de avaliação
Após a definição do método de avaliação, o usuário inicia o processo de cadastro dos pesos de todas as características e sub-caracteristicas, distribuindo o valor de 100% entre elas, selecionando o item “Peso”, digitando o valor desejado, cadastrando através do item “Adicionar”e finalmente armazenando através do item “Salvar”. Para realizar essa etapa o usuário seleciona o método cadastrado, e logo em seguida o item “Alterar”, com isso uma nova janela será aberta com todas as opções descritas acima (conforme figura 23).
Figura 23 - Tela de pesos referente aos métodos de avaliação
54 Ao selecionar a aba “Resultados”, o usuário irá fazer o cadastro da avaliação final do software, determinando o inicio da faixa de pontuação através do item “Inicio Faixa”, sua descrição pelo item “Descrição” e seu respectivo comentário pelo item “Comentário”. Após o preenchimento dessas opções o usuário seleciona o item “Adicionar” e logo em seguida em “Salvar” cadastrando os resultados (conforme figura 24).
Figura 24 - Tela de resultados referentes aos métodos de avaliação
55
Figura 25 - Tela de avaliações e geração de questionário
Com o término de todo o cadastro necessário, o usuário finalmente estará apto a avaliar o software acessando a opção “Avaliações” e selecionando o software a ser avaliado. Em seguida o usuário irá visualizar uma janela com as opções cadastradas anteriormente, e irá selecionar o item “Questionário” onde responderá as perguntas referentes ao software que está sendo avaliado (conforme figura 25). Após esse procedimento o usuário selecionará o item imprimir visualizando a avaliação final através de gráficos de desempenho, determinando a qualidade do software avaliado, Esses gráficos irão especificar todas as características e sua referentes subcaracterísticas mostrando a avaliação de todas as métricas internas e externas e de qualidade de uso. (ver seção analise de resultados).
56 5
ANÁLISE DOS RESULTADOS Após responder o questionário, o usuário ira visualizar a opção imprimir
(conforme figura 25), ao selecionar essa opção obterá a visualização dos gráficos dos resultados da avaliação da qualidade da ferramenta. O primeiro gráfico gerado pela ferramenta demonstra o nome do software, da empresa e do avaliador do sistema os resultados obtidos em relação às características funcionalidade e confiabilidade, com os respectivos gráficos de suas sub-caracteristicas que foram gerados através das perguntas cadastradas referente a cada sub-caracteristica e os resultados obtidos através da pontuação determinada anteriormente (conforme figura 26).
Figura 26 – Gráficos das características funcionalidade e confiabilidade.
57 A figura 27 demonstra os resultados obtidos em relação às características usabilidade e eficiência, com os respectivos gráficos de suas sub-caracteristicas que foram gerados através das perguntas cadastradas referente a cada subcaracteristica e os resultados obtidos através da pontuação determinada anteriormente.
Figura 27 – Características de Usabilidade e Eficiência
58 A figura 28 demonstra os gráficos de avaliação das características portabilidade e manutenbilidade, com os respectivos gráficos de suas subcaracteristicas que foram gerados através das perguntas cadastradas referente a cada sub-caracteristica e os resultados obtidos através da pontuação determinada anteriormente .
Figura 28 – Gráfico das características Portabilidade e Manutenbilidade
59 A figura 29 demonstra a avaliação final das métricas internas e externas , analisando-se todas as suas características em um só gráfico, baseado nas pontuações anteriores de cada característica, gerando assim um gráfico do resultado final em relação as métricas internas e externas onde se classificam as características avaliadas.
Figura 29 – Gráfico da Avaliação das Métricas Internas e Externas
60 A figura 30 demonstra os resultados obtidos em relação às características eficacia e produtividade, com os respectivos gráficos de suas sub-caracteristicas que foram gerados através das perguntas cadastradas referente a cada subcaracteristica e os resultados obtidos através da pontuação determinada anteriormente .
Figura 30 – Gráficos das Características Eficácia e Produtividade
61 A figura 31 demonstra os resultados obtidos em relação às características segurança e satisfação, com os respectivos gráficos de suas sub-caracteristicas que foram gerados através das perguntas cadastradas referente a cada subcaracteristica e os resultados obtidos através da pontuação determinada anteriormente .
Figura 31 – Gráfico das Características de Segurança e Satisfação
62 A figura 32 demonstra a avaliação final das métricas de qualidade de uso , analisando-se a pontuação adquirida por cada característica anteriormente, gerando assim um gráfico com a pontuação de cada uma, e finalmente o grafico final do resultado das métricas de qualidade em uso.
Figura 32 – Gráfico da Avaliação de Métricas de qualidade de uso
63 Finalmente é demonstrada a avaliação final da qualidade do software através da média de pontuação retirada entre as métricas internas e externas e as métricas de qualidade em uso,gerando assim um gráfico de avaliação final determinando a qualidade do software e um breve comentário em relação a mesma (conforme figura 33).
Figura 33 – Gráfico do Resultado Final da Avaliação
64 6
CONCLUSÃO
Esse trabalho teve o objetivo de demonstrar a importância de um software de qualidade, fazendo um estudo da norma ISO/IEC 9126 que trata da qualidade de um produto de software. A norma ISO/IEC 9126 torna avaliação da qualidade de software mais simples e prática, pois disponibiliza ao avaliador características e métricas de avaliação, trazendo eficácia a avaliação da qualidade do software. Em relação à ferramenta, pode-se afirmar que possui usabilidade, trazendo ao usuário facilidade para avaliar o software. Outra vantagem da ferramenta é a sua flexibilidade, pois o usuário poderá configurar a avaliação da maneira que melhor lhe convir, cadastrando pontuação, descrições e comentários. Essa configuração se foi “salva” pelo usuário poderá ser usada em avaliações posteriores de outros softwares. Uma das limitações encontradas em relação ao desenvolvimento da ferramenta deu-se através da ausência de outras ferramentas de avaliação de qualidade de software no mercado, fazendo com que não pudesse ser feita comparações visando o aprimoramento da ferramenta. Conforme pesquisas constatou-se que a ferramenta QUALITYSOFT-FAINOR foi a pioneira para avaliação de qualidade de software baseada na ISO/IEC 9126, trazendo assim uma grande contribuição não só para área acadêmica bem como para as empresas que necessitam avaliar seus softwares. Os objetivos desse trabalho foram alcançados, visto que, ao estudar a norma ISO/IEC 9126 foi possível estabelecer um padrão para avaliar a qualidade de um produto de software. Usando UML, foram especificados os requisitos através dos casos de uso. A avaliação final da ferramenta foi demonstrada através de gráficos de desempenho, indicando a qualidade do software avaliado. Diante do exposto fica a sugestão do estudo de outras normas relacionadas a qualidade de software para aprimoramento e criação de novas ferramentas de avaliação de qualidade de software. Finalmente, conclui-se que a norma ISO/IEC 9126 possibilita através de suas métricas e características avaliar vários tipos de software, sendo isso colocado em prática através da ferramenta criada.
65
66 REFERÊNCIAS SOMMEVILLE, Ian; engenharia de software; Pearson Addisonwsley, 2007. GOMES, Paulo J. P.; A evolução do conceito de qualidade: dos bens manufaturados aos serviços de informação. Cadernos BAD, 2004. Disponível em: <http://www.apbad.pt/CadernosBAD/Caderno22004/GomesBAD204.pdf>. acesso em: 23/03/2010. SODRÉ, Cibele Cristina Pelizer. Norma ISO/IEC 9126: Avaliação de Qualidade de Produtos de Software. 2006. 53f. Monografia (trabalho de conclusão de curso) Bacharelado em ciência da computação. Universidade Estadual de Londrina – UEL. Londrina. REZENDE Denis Alcides. Engenharia de Software e sistemas de informação / Denis Alcides Rezende. – 3 ed. Ver. E ampl. – Rio de Janeiro: Brasport, 2005. SALVIANO, Clénio F., Contribuição da melhoria de processo e gerência de projetos: Transformando boas idéias em resultados. Gerenciamento de projetos. Disponível em: <http://www.bfpug.com.br/isligrio/Downloads/Contribuicoes_da_Melhoria_de_Proces sos.pdf>. Acesso em: 05 de Abril de 2010. POSSA, Rodrigo Montenegro. Requisitos para Ferramentas de Suporte à Garantia da Qualidade de Software; Departamento de Ciência da Computação – Universidade Federal de Minas Gerais (UFMG) –Pampulha – Belo Horizonte – MG. S.d. LOPES, Elias. CMMI, um dos Principais Modelos da Qualidade e o MPS.Br, Modelo Adaptado à Realidade Brasileira, Artigos.com. 2006. Disponével em: <http://www.artigos.com/artigos/exatas/tecnologia/cmmi,-um-dos-principais-modelosda-qualidade-e-o-mps.br,-modelo-adaptado-a-realidade-brasileira-1200/artigo/>. Acesso em 10 de abril de 2010. CMMI, Qualidade de software com. Disponível em: <http://www.augustovespermann.com/2010/04/qualidade-de-software-com-cmmi/>. Acesso em: 10 de abril de 2010. RINCON, André Mesquita. Qualidade de Software. In: XI Encontro de Estudantes de Informática do Tocantins, 2009, Palmas. Anais do XI Encontro de Estudantes de Informática do Tocantins. Palmas: Centro Universitário Luterano de Palmas, 2009. p. 75-86. Disponível em: <http://tinyurl.com/yj8f4kh>. Acesso em: 16 de abril de 2010. SÉZIO, Paulo. CMMI - Modelo de Processo de Melhoria Corporativo, 2009. Disponível em: <estruturar.blogspot.com/2009/10/cmmi-modelo-d>. Acesso em: 16 de abril de 2010. PAULA FILHO, Wilson de Pádua. Engenharia de Software: fundamentos, métodos e padrões/ Wilson de Pádua Paula Filho. – 3º Ed. – Rio de Janeiro: LTC, 2009.
67 BERNARDO, Cláudio Gonçalves; BECERRA, Jorge Luis Risco. APS-FINAN - Um Método baseado no SPICE para Avaliação do Processo de Software de Instituições Financeiras. VII Simpósio Internacional de Melhoria de Processos de Software . 2005, São Paulo, SP – Brasil. Disponível em:< www.simpros.com.br> Acesso em: 10/04/2010. COPYRIGHT, Carlos Videira. Qualidade nos Sistemas de Informação, 2003 – 2004. SPICE = Software Process Improvement and Capability dEtermination. Disponível em: <http://arenga.net/UAL/3%BA%20Ano%20%201%BA%20Semestre/PSI/Trabalho%2 0Pesquisa%20-%20Spice/Pesquisas/SPICE%20%282%29.pdf>. Acesso em:15/04/2010. HUTCHINS, Greg. ISO 9000 Um Guia Completo para o Registro, as Diretrizes da Auditoria e a Certificação . São Paulo : Makron Books, 1994. ANJOS, Lúcio André Mendonça dos; MOURA Hermano Perrelli de. Um Modelo para Avaliação de Produtos de Software Centro de Informática - Universidade Federal de Pernambuco (UFPE) – Recife – PE – Brasil, s.d. Disponível em: <http://php.cin.ufpe.br/~laps/laps/arquivo/arquivo_13.pdf>. Acesso em: 20/04/2010. NBR ISO/IEC 9126-1 Engenharia de software - Qualidade de Produto Parte 1: Modelo de qualidade JUN 2003. LEITE, Jair C. Engenharia de Software, 2004. Disponível em: <http://www.dimap.ufrn.br/~jair/ES/slides/Processo.pdf>.Acesso em: 10/05/2010. LESSA, Rafael Orivaldo; JUNIOR, Edson Orivaldo Lessa. Modelos de Processos de Engenharia de Software: Princípios da Engenharia de Software – Universidade do Sul de Santa Catarina (UNISU) – Palhoça – SC – Brasil, 2002. Disponível em: <http://inf.unisul.br/~pacheco/princ_eng_sw/02_Artigo.pdf >. Acesso em: 10/05/2010. TEIXEIRA, Alan Santana; RAMOS, Victor; ZARU, Makuxe. Uma Visão do Desenvolvimento de Software a partir da Modelagem de Negócio. 2004. 75f. Monografia (trabalho de conclusão de curso) Bacharelado em ciência da computação. Universidade da Amazônia(Unama), Belém – PA. MACORATTI, José Carlos. Conceitos : Especificação de requisitos. 2007. Disponível em: <http://www.macoratti.net/07/12/net_fer.htm>. Acesso em 12/m05/2010. CARPENA, Flávio Ricardo; KIRNER, Tereza Gonçalves; Especificação de Requisitos de Software com o Método SCR. 1998. Departamento de Computação Universidade Federal de São Carlos São Carlos (UFSCar), SP. Disponível em: <http://wer.inf.puc-rio.br/WERpapers/artigos/artigos_WER98/carpena.pdf>. Acesso em: 12/05/2010. CODIFICAÇÃO. Livro Branco da LaCie:, s.d. Disponível em: <http://www.lacie.com/download/whitepaper/WPEncryption_pt.pdf >. Acesso em: 13/05/2010.
68 BARBOSA, Ellen Francine; MALDONADO, José Carlos; VINCENZI; Auri Marcelo Rizzo et.al.. Introdução ao Teste de Software. 2000. Apostilausp.pdf. Disponível em: <HTTP://www.inf.ufpr.br>. Acesso em: 13/05/2010. BRAUD, Eric. Projeto de Software da programação à arquitetura: Uma abordagem baseada em Java. Artimed, editora S. A. Posto Alegre – RS, 2004. SILVA, Elizabeth Maria de Morais; NASCIMENTO, Rogério Patrício Chagas do. Modelo de Maturidade da Capacitação para software.s.d. Disponível em: <www.cin.ufpe.br/~qualisoft/documentos/diversos/cmm/cmm.doc>. Acesso em: 10/03/2010. FERNANDES,por Jorge H C. SPICE e ISO-15504, Set/2004. Disponível em: <http://www.cic.unb.br/~jhcf/MyBooks/iess/SPICE/SPICE-26slides.pdf >. Acesso em: 15/05/2010. BRUSAMILIN, Valério. Manutenibillidade de software. 2004, Instituto Cientifico e de Ensino Superior e Pesquisa – ICESP. Revista digital, vol. 02, Janeiro de 2004 Disponível em:< http://revdigonline.com/revistas_download/revista_2.pdf#page=10>. Acesso em: 10/03/2010. GIL, Antônio Carlos. Como elabora projetos de pesquisa, 4° Edição, editora Atlas, S.A., São Paulo, 2002. LAKATOS, Eva Maria. Metodologia Científica / Marina de Andrade Marcone, Eva Maria Lakatos – 5. Ed. – 4.reimpr. – São Paulo: Atlas 2010. LAKATOS, Eva Maria. Fundamentos da metodologia científica / Marina de Andrade Marcone, Eva Maria Lakatos – 6. Ed. – 5.reimpr. – São Paulo: Atlas 2007. MINAYO, M. C. S. (org.). pesquisa social:teoria, métodos e criatividade. 22. Ed. Petrópolis – Rio de Janeiro: vozes, 1994 RIOS, Emerson; MOREIRA, Trayahú. Testes de software. - 2° Ed.- Rev. e Ampl. – Rio de Janeiro: Alta Books s.d. PETERS, James F. Engenharia de software/ James F. Peters, Witold Pedrycz; Tradução de Ana Patrícia Garcia. – Rio de Janeiro: Campus, 2001. SOMMERVILLE, Ian. Engenharia de Software; tradução: André Maurício de Andrade; revisão Técnica: Kechi Hirama. – São Paulo: Addison Wesley, 2003. MACHADO, Marcio P.; SOUZA, Sotério F..Métricas e Qualidade de Software Mestrado em Informática Departamento de Informática – Universidade Federal do Espírito Santo. SOUSA, João Eduardo Soares de TQS - Teste e Qualidade de Software Métricas de qualidade de produtos de software e a norma ISO/IEC 9126. 2004. mei06004@fe.up.pt _