domingo, 2 de março de 2008

O Modelo SQuaRE

Organizações com interesse na área de Engenharia de Software e que utilizam as normas das séries ISO/IEC 9126 e ISO/IEC 14598 (ou na versão ABNT NBR ISO/IEC 9126 e 14598) como referência para especificação e avaliação da qualidade de produto de software devem estar recebendo informações sobre o modelo SQuaRE. Este modelo, que é um acrônimo de Software Quality Requirements and Evaluation, foi desenvolvido pelo grupo de trabalho WG6 do Subcomitê de Sistemas e Software (SC7) da ISO/IEC. O grupo de trabalho WG6 é responsável pela elaboração de normas internacionais que tratam da especificação, medição e avaliação da qualidade de produtos de software. A definição da arquitetura de normas SQuaRE teve início em 1999 e vem orientando a revisão das normas já publicadas pela ISO, bem como a criação de novas normas que atendem aos requisitos do mercado e a evolução da Engenharia de Software.

O núcleo principal do SQuaRE é composto de cinco divisões de normas, conforme a seguir:

  • ISO/IEC 2500n – Divisão Gestão da Qualidade;
  • ISO/IEC 2501n – Divisão Modelo de Qualidade;
  • ISO/IEC 2502n – Divisão Medição da Qualidade;
  • ISO/IEC 2503n – Divisão Requisitos de Qualidade; e
  • ISO/IEC 2504n – Divisão Avaliação da Qualidade.

Estas divisões são compostas de normas, harmonicamente integradas, que detalham os tópicos relacionados à especificação e avaliação da qualidade de produtos de software.

Além deste núcleo principal, o SQuaRE contempla uma extensão, que trata de temas específicos, e que atualmente é composta pelas normas internacionais ISO/IEC 25051 e ISO/IEC 25062.


As normas do SQuaRE que já estão publicadas pela ISO são as seguintes:

  • ISO/IEC 25000 - Software engineering - Software product Quality Requirements and Evaluation (SQuaRE) - Guide to SQuaRE;
  • ISO/IEC 25001 - Software engineering — Software product Quality Requirements and Evaluation (SQuaRE) — Planning and management;
  • ISO/IEC 25020 - Software engineering - Software product Quality Requirements and Evaluation (SQuaRE) - Measurement reference model and guide;
  • ISO/IEC TR 25021 - Software Engineering: Software product Quality Requirements and Evaluation (SQuaRE) - Quality measure elements;
  • ISO/IEC 25030 - Software engineering — Software product Quality Requirements and Evaluation (SQuaRE) — Quality requirements;
  • ISO/IEC 25051 Software Engineering – Software product Quality Requirements and Evaluation (SQuaRE) – Requirements for quality of Commercial Off-The-Shelf (COTS) software product and instructions for testing; e
  • ISO/IEC 25062, Software engineering: Software product Quality Requirements and Evaluation (SquaRe) - Common Industry Format (CIF) for Usability Test Reports.

Além destas normas já publicadas, há várias outras normas em elaboração pelo WG6.

A ABNT vem trabalhando na preparação das normas brasileiras equivalentes às normas do SQuaRE por meio da Comissão de Estudos de Requisitos e Avaliação da Qualidade de Software. Atualmente está em fase de revisão final o texto da norma brasileira ABNT NBR ISO/IEC 25000, que já passou pelo estágio de Consulta Nacional pela ABNT.

Danilo Scalet

segunda-feira, 4 de fevereiro de 2008

Qualidade em uso

Tomada a decisão de criar este Blog para tratar de qualidade de software e serviços, onde espero poder discutir diversos aspectos relacionados ao tema, era necessário definir um tema inicial que estivesse à altura deste evento inaugural. Após avaliar algumas possibilidades, surgiu a opção mais óbvia – tratar da qualidade pelo seu aspecto fundamental, que é o atendimento às necessidades. Para adotar esta abordagem, creio que o tema ‘Qualidade em Uso’ pode ser de grande valia.

Inicialmente, é conveniente definir o termo qualidade, e me valho da norma ISO/IEC 25000 Software engineering - Software product Quality Requirements and Evaluation (SQuaRE) – Guide to SQuaRE, que é o Guia Geral da série de normas ISO/IEC 25000 que tratam da qualidade de produto de software (o SQuaRE será objeto de uma postagem específica no futuro). Esta norma define qualidade de software como a ‘capacidade de um produto de software de satisfazer necessidades explícitas e implícitas quando utilizado sob condições especificadas’. Por esta definição, qualidade de software (que pode ser extrapolada para outros produtos e serviços) significa atender necessidades declaradas ou, mesmo, não declaradas. Complementando, necessidades expressam resultados esperados, como conseqüência de ações empreendidas, tais como, projetos, mudanças organizacionais ou a compra ou desenvolvimento de um produto de software. Note-se que uma pessoa ou uma organização não necessita meramente um produto ou um serviço e sim os efeitos do uso deste produto ou serviço – estes efeitos correspondem às suas necessidades.

Considerando-se que, para atender necessidades, é necessário compreender e suprir os efeitos esperados de um produto ou serviço, destaca-se a importância da utilização da abordagem da qualidade em uso. Qualidade em uso, definida na mesma norma citada anteriormente, representa ‘o quanto um produto, utilizado por usuários específicos, atende às necessidades desses usuários para que eles atinjam metas específicas com eficácia, produtividade, segurança e satisfação, num contexto de uso específico’. Este conceito é totalmente focado nos resultados do uso de um produto (podendo ser extrapolado para serviços). A qualidade em uso pode ser desdobrada em quatro características: eficácia, produtividade, segurança e satisfação. Estas características estão definidas na norma brasileira NBR ISO/IEC 9126-1 Engenharia de software - Qualidade de produto Parte 1: Modelo de qualidade (versão equivalente à norma internacional ISO/IEC 9126-1) como:
Eficácia: Capacidade do produto de software de permitir que usuários atinjam metas especificadas com acurácia e completitude, em um contexto de uso especificado.
Produtividade: Capacidade do produto de software de permitir que seus usuários empreguem quantidade apropriada de recursos em relação à eficácia obtida, em um contexto de uso especificado.
Segurança: Capacidade do produto de software de apresentar níveis aceitáveis de riscos de danos a pessoas, negócios, software, propriedades ou ao ambiente, em um contexto de uso especificado.
Satisfação: Capacidade do produto de software de satisfazer usuários, em um contexto de uso especificado.
No desenvolvimento ou aquisição de software, as necessidades a serem atendidas pelos projetos devem ser especificadas, desdobrando-as em características, como as citadas anteriormente e, posteriormente, refinando-as em termos de medidas que possam definir quantitativamente as respectivas características (por exemplo, qual o tempo esperado para realizar uma determinada operação de negócio com o apoio do novo software). Complementarmente, convém que sejam efetuadas avaliações (parciais e final) da qualidade em uso, para que seja aferido o quanto o produto de software pode contribuir, efetivamente, para o atendimento aos resultados esperados (as necessidades). Note-se que muitos projetos de desenvolvimento de software ignoram estes conceitos e ações. Como conseqüência, não surpreende que os resultados obtidos muitas vezes se situem muito aquém do esperado pelas organizações adquirentes destes produtos de software.
A utilização do conceito de qualidade em uso na especificação das necessidades e requisitos, bem como na avaliação de produto de software está razoavelmente especificada em normas internacionais, e teremos oportunidade de aprofundar este tema em novas postagens.
Avaliando-se o conceito de qualidade em uso para outras áreas de serviços, além do software, percebe-se que as definições são aplicáveis para uma grande diversidade de serviços, requerendo adaptações que levem em consideração aspectos específicos de cada tipo de serviço. Numa análise geral, percebe-se que os conceitos de eficácia e produtividade são aplicáveis para serviços em geral, praticamente da mesma forma que para produtos de software. Com relação à característica segurança, deve-se avaliar se um serviço, que tenha como foco principal eficácia ou produtividade, pode vir a aumentar o risco de comprometer aspectos relacionados à segurança. O caso de segurança ambiental é típico, à medida que os requisitos desta natureza são cada vez mais rigorosos. Neste sentido, é necessário que os requisitos das características eficácia e produtividade estejam compatíveis com aqueles referentes à segurança. Finalmente, com relação à característica satisfação, é importante que sejam levados em conta fatores de estima que possam ser afetados pela prestação do serviço. Alguns aspectos de destaque relacionados à satisfação são: prazer, estímulo, felicidade, conforto, status, entre outros. Por outro lado, o foco dos serviços nas outras características (principalmente eficácia e produtividade) pode levar à geração de fatores colaterais que contribuam para a não satisfação de grupos envolvidos ao serviço (por exemplo, calor, redução de espaço, ruído, estresse, entre outros). É importe analisar a relação entre o custo e os benefícios dos requisitos estabelecidos para cada característica, buscando o equilíbrio que seja mais adequado à organização.
Resumindo, organizações que pretendam obter qualidade ao desenvolver software ou realizar serviços, ou seja, atender às necessidades de seus clientes, podem utilizar os conceitos relacionados à qualidade em uso como forma de atingir a estes objetivos. É importante ressaltar que a não especificação de objetivos de qualidade é uma forma bastante eficaz de se realizar projetos que fracassam.
Danilo Scalet