Capítulo 10 – Qualidade de Produtos de Software Escrito por: Renata Araújo {rbsa@cin.ufpe.br}...

Capítulo 10 – Qualidade de Produtos de Software

Escrito por: Renata Araújo {rbsa@cin.ufpe.br}

Vírginia Chalegre {vcc@cin.ufpe.br}

Apresentado por: Cleice Souza

2010

Modelagem i* da norma NBR ISO/IEC 9126-1:2001

ROTEIRO

I. INTRODUÇÃO

II. OBJETIVO

III. NBR ISO/IEC 9126-1:2001

IV.REQUISITOS NÃO FUNCIONAIS (NFR’S)

V. SOBRE i*

VI. MODELO SR

I. INTRODUÇÃO

• A indústria busca continuamente aprimorar seus produtos e alinhar critérios com os padrões mais rigorosos em uso no mundo.

• A qualidade, atualmente, é percebida como um objetivo de negócio.

• Maior qualidade afinal significa cliente satisfeito.

• Sob a perspectiva de software, o assunto qualidade é bastante extenso.

II. OBJETIVO

• Modelar características e sub-características da norma NBR ISO/IEC 9126 com intuito de

relacionar Qualidade de Uso em Requisitos não Funcionais (NFR’s).

III. NBR ISO/IEC 9126

• A norma 9126 é um conjunto de atributos que têm impacto na capacidade do software de manter o seu nível de desempenho dentro de condições estabelecidas por um dado período de tempo [Cortes 2009].

• ISO 9126 é dividida em quatro partes:

III. NBR ISO/IEC 9126Esta parte da norma é referente

ao Modelo de qualidade que foca nas diretrizes de uso e

características de qualidade de produto de software que serão apresentadas a seguir. neste

capítulo

• Esta norma pode ser aplicada nas seguintes situações:• Definição dos requisitos de qualidade de um produto de software;

• Avaliação da especificação de software para verificar se ele irá satisfazer aos requisitos de qualidade durante o desenvolvimento;

• Descrição de particularidades e atributos do software implementados, por exemplo, em manuais de usuário;

• Avaliação do software desenvolvido antes da entrega ao cliente; e

• Avaliação do software desenvolvido antes da aceitação pelo cliente.

III. NBR ISO/IEC 9126

• Características e sub-características de qualidade de software:

Os modelos de qualidade, geralmente, representam a totalidade dos atributos do software classificados em uma estrutura de árvore hierárquica de características e sub-características. O nível mais alto dessa estrutura é composto pelas características de qualidade e o nível mais baixo é composto pelos atributos de qualidade do software.

III. NBR ISO/IEC 9126-1:2001

CARACTERÍSTICAS SUB-CARACTERÍSTICAS

Funcionalidade (satisfação das necessidades) Adequação - execução do que é apropriadoAcurácia - execução de forma corretaInteroperabilidade - interação com outros sistemasConformidade - aderência às normasSegurança de acesso - bloqueio de uso não autorizado

Confiabilidade (imunidade a falhas) Maturidade - freqüência das falhasTolerância a falhas - reação a falhasRecuperabilidade - capacidade de se recuperar das falhas

Usabilidade (facilidade de uso) Intelegibilidade - facilidade de entendimentoApreensibilidade - facilidade de aprendizadoOperacionalidade - facilidade de operação

Eficiência (rápido e "enxuto") Tempo - tempo de resposta, velocidade de execuçãoRecursos - quais recursos são utilizados

Manutenibilidade (facilidade de manutenção) Analisabilidade - facilidade de encontrar falhaModificabilidade - facilidade de modificarEstabilidade - baixo risco de alteraçõesTestabilidade - facilidade de testar

Portabilidade (uso em outros ambientes) Adaptabilidade - facilidade de se adaptar a outros ambientesCapacidade para ser instalado - facilidade de instalar em outros ambientesConformidade - aderência a padrões de portabilidadeCapacidade para substituir - facilidade de ser substituído por outro

IV. REQUISITOS NÃO FUNCIONAIS

• Requisitos não-funcionais são difíceis de descrever porém tratá-los durante o processo de desenvolvimento pode ser vital para o sucesso de sistemas.

• Não existe uma definição formal ou uma lista completa de requisitos não-funcionais.

V. SOBRE i*

• Esta abordagem se centra nos stakeholders do sistema e nas suas relações

Atores dependem uns dos outros para alcançarem os

seus objetivos

• Responder a questões tais como: Por que um requisito é de um tipo e não de outro?

Por que um determinado requisito é necessário?

• Permite não só perceber os requisitos do sistema, como também ajuda-nos a prepará-lo para mudanças futuras.

V. SOBRE i*

• Ator – É uma entidade ativa que realiza ações que lhe permitam atingir objetivos.

• Podem ser agentes (humanos ou não), papéis (funções) ou posições (locais de trabalho/cargos).

V. SOBRE i*

• i* consiste em dois modelos básicos:

Modelo de Dependência Estratégica (SD – Strategic Dependency) : descreve relações de dependência entre os atores.

Modelo de Razão Estratégica (SR- Strategic Rationale) :explica como os atores atingem as suas metas.

V. SOBRE i*

VI. MODELO SR

• O modelo SR modela as relações de intenção dentro do ator.

• Elementos intencionais.

• Relações de meio-fim, relações de decomposição de tarefa e relações de contribuição.