Aspectos da qualidade para software

Quando se aborda o tema qualidade, mesmo dentro de um contexto específico de software, faz-se necessário resgatar resultados de pesquisas, normas e outros materiais científicos que forneçam fundamentos e conceitos consagrados para a sustentação do trabalho.

Qualidade é o grau no qual um conjunto de características inerentes satisfaz a necessidade ou expectativa geralmente expressa, implícita ou obrigatória através de requisitos. Os tipos de requisitos são distinguidos pelo uso de um qualificador como, por exemplo, requisito do produto, requisito da gestão da qualidade, requisito do cliente (NBR ISO/IEC 9000, 1993).

Característica é uma propriedade diferenciadora. Pode ser inerente ou atribuída, qualitativa ou quantitativa. Uma característica pode ser física, sensorial, comportamental, temporal, ergonômica ou funcional (NBR ISO/IEC 9000, 1993). As características de qualidade estão relacionadas a requisitos inerentes a produto, processo ou sistema.

Gerir qualidade é uma ação voltada para o sistema, processo ou produto, e garantir qualidade é prover confiança em que os requisitos da qualidade estão sendo atendidos. Um sistema pode ser entendido como um conjunto de elementos inter-relacionados ou interativos, enquanto pode entender-se um processo como um conjunto de atividades inter-relacionadas ou interativas, que transformam insumos (entradas) em produtos (saídas). Um processo deve agregar valor ao produto. Procedimento é a execução de uma atividade ou um processo, de forma especifica (NBR ISO/IEC 9000, 1993).

Produto é o resultado de um processo, podendo ser classificado em 4 categorias: serviço (p.ex.: transporte); informações (p.ex.: dicionário, uma ata); materiais e equipamentos, e materiais processados (NBR ISO/IEC 9000, 1993).

Um programa é enquadrado, pela NBR ISO 9000, como produto do tipo informação. Um software, segundo Sommerville (2003), não é só um programa, mas também toda a documentação a ele associada, além dos dados de configuração necessários para sua correta operação.

Produto de software, diferente de outros produtos, como os manufaturados, possui propriedades que justificam grande parte da dificuldade para se obter qualidade. Segundo Tsumuko (1985), um produto de software é complexo, invisível, de produção única, não desgasta, funciona com múltiplos usuários ao mesmo tempo e possui um cálculo de custo centrado no custo do seu desenvolvimento.

Um sistema de software consiste em uma série de programas separados, arquivos de configuração, documentação da estrutura do sistema, e a documentação do usuário, explicando como utilizar. Produtos de software também incluem a presença de informações sobre procedimentos de atualização de versões (Sommerville, 2003).

Em síntese, um software composto por um ou mais programas possui características diferenciadas dos produtos manufaturados. Um produto de software é aquele que pode ser vendido a um cliente e deve possuir, além de todos os componentes de um sistema de software, atributos que norteiem o relacionamento adquirente-fornecedor.

Falando em aquisição de produto ou sistema de software, Sommerville (2003) pondera que ele não é uma entidade independente, mas existe em um ambiente que afeta o seu funcionamento.

Um ambiente, às vezes, pode ser considerado um sistema em si mesmo, mas em geral, ele consiste em uma série de outros sistemas que interagem entre si. Assim, há duas razões principais pelas quais o ambiente de um sistema deve ser compreendido num processo de aquisição: o sistema pode ser concebido para modificar o ambiente; e o funcionamento de um sistema pode ser afetado por mudanças de um ambiente.

que o uso do sistema atinja seu objetivo, temos as mudanças no processo mudanças de tarefas, mudanças organizacionais.

A norma NBR 9000 (NBR ISO/IEC 9000, 1993) identifica características de qualidade distintas para processo, produto e sistema, mas sempre relacionadas a requisitos. A engenharia de software aprimora as definições desses conceitos, acomodando sua compreensão para os aspectos da qualidade de software.

Qualidade do processo é o grau com que ele garante a qualidade dos respectivos produtos de software, enquanto a qualidade do produto é o grau de conformidade com os respectivos requisitos (Paula F, 2001). A totalidade das características do produto de software lhe confere a capacidade de satisfazer às necessidades explícitas e implícitas (NBR ISO/IEC 9126-1, 2001).

Quando o foco é usar tecnologia da informação - TI, devem ser consideradas três instâncias para definir qualidade: o ambiente, o sistema de informação e o produto de software, em que uma instância está estreitamente relacionada às outras, influenciando a qualidade final do uso de TI. Para o ambiente, os elementos básicos relacionados são o local físico, o hardware, a telecomunicação/rede, o sistema de informação e o peopleware. Os aspectos de sistema de informação relacionam-se a integração de sistemas, produtos de software, nível de integridade, arquivo de configuração, estrutura de base de dados e documentação de sistema.

Cabe ao produto de software apresentar qualidade externa, qualidade em uso, documentação para o usuário e, principalmente, função ou aplicação com informações relacionadas ao propósito e desempenho esperado.

Assim, os requisitos de aquisição de um produto de software devem especificar, além dos requisitos funcionais do produto, incluindo leis e praxes da área, os requisitos de facilidade de uso e os requisitos de sistema, como o nível de integridade e integração requerido e os aspectos do ambiente (NBR ISO/IEC 12207, 1998).

Definir requisitos, geralmente, é expressar, em forma de documento, quais características uma entidade deve possuir para ser aceita (Paula F, 2001). Um requisito é:

• Explícito, se descrito num documento que arrola os requisitos, ou seja, um documento

• Implícito, quando não é documentado, porém cobrado em decorrência de sua experiência no momento de utilização.

• Normativo, quando decorre de lei, regulamentos, padrões e outros tipos de regras que

devem ser obedecidas. O requisito normativo define as condições em que a entidade deverá ser utilizada, seu objetivo, sua função e expectativa de desempenho.

Quando se definem requisitos para um ambiente, um sistema de informação ou um produto, devem ser levadas em consideração as três formas de apresentação de um requisito. Em geral, as necessidades explícitas são expressas na definição de requisitos propostos após o levantamento das necessidades. O enfoque da qualidade centrado no atendimento a esses requisitos é denominado "conformidade com os requisitos” (ISO/IEC 9126-2, 2001). Necessidades implícitas são percebidas quando o produto é utilizado em condições particulares (NBR ISO/IEC 14598-1, 1999), e são imprescindíveis no uso do software. Um produtor de software experiente tem mais facilidade para identificar requisitos implícitos, geralmente relacionados à "adequação ao uso".

Um software é considerado de qualidade se estiver correto, consistente, compreensível e testável. Para garantir a qualidade do software, são necessárias avaliações que podem envolver: verificação, validação e testes do produto (NBR ISO/IEC 14598-1, 1999).

Qualificar é demonstrar a capacidade que um produto ou processo tem de atender a requisitos específicos. Qualificar é designar uma situação correspondente, associada a pessoas, processos e produtos (NBR ISO/IEC 9000, 1993).

Para qualificar um produto ou um processo de software, faz-se necessária uma avaliação. A avaliação da qualidade de um produto de software é um exame sistemático que evidencia a capacidade do produto em atender os requisitos especificados (NBR ISO/IEC 14598-1, 1999). Ela pode ser aplicada a um produto intermediário ou final, resultante de uma atividade do processo de desenvolvimento de software (Scope, 1993).

A avaliação da qualidade de processo de software consiste no exame dos procedimentos operacionais e gerenciais, métodos e técnicas utilizados nas fases de desenvolvimento (Tsukumo, 1996a). O objetivo é identificar práticas que possam provocar problemas na qualidade do produto

geração de produtos melhores, entretanto, não garante a qualidade do produto final. Os dois tipos de avaliação são necessários e complementares; embora distintos, com técnicas e métodos próprios, eles têm como objetivo comum garantir a qualidade do produto final (Sant’Ana, 2002).

Um produto de software deve ser avaliado quanto a sua qualidade. Entre outros motivos, para identificar e entender as razões técnicas das deficiências e limitações manifestadas através de problemas operacionais ou problemas de manutenção, assim como para comparar produtos, mesmo que indiretamente; e/ou para formular-se um plano de ação para evoluí-lo.

O tema qualidade de software vem sendo aprofundado em suas diferentes visões: qualidade de processo, qualidade de produto e qualidade em uso, as quais são, por consenso, consideradas complementares (SSQP/SW, 2002).

As propostas de avaliação da qualidade de processos e de produtos, intermediários ou finais, têm como objetivo comum melhorar a qualidade do produto em uso. Qualidade em uso é o grau em que o produto pode ser usado por usuários específicos, num contexto específico de uso (ISO/IEC 9126-4, 2001).

Para permitir a correta avaliação de qualidade de software, tanto de produtos quanto de processos, muitas instituições vêm fornecendo informações em forma de normas, padrões e modelos. Uma experiência da aplicação das normas de qualidade de produto de software realizada no Brasil é apresentada por Tsukumo (1995 e 1996b) em seus artigos sobre o tema. Trata-se da avaliação de produto de software no Prêmio “Melhor software do ano”, realizado em 1994 pelo CenPRA e pela ASSESPRO, quando foi criado o método de avaliação de produto de software – MEDEPROS®.

Nos próximos tópicos deste capítulo, serão mostradas algumas das principais informações disponíveis para as visões de qualidade de processo e produto, incluindo, neste último, aspectos da qualidade em uso.