modelagem i* da norma nbr iso/iec 9126-1:2001
DESCRIPTION
Modelagem i* da norma NBR ISO/IEC 9126-1:2001. Capítulo 10 – Qualidade de Produtos de Software Escrito por: Renata Araújo {[email protected]} Vírginia Chalegre {[email protected]} Apresentado por: Cleice Souza 2010. ROTEIRO. INTRODUÇÃO OBJETIVO - PowerPoint PPT PresentationTRANSCRIPT
Capítulo 10 – Qualidade de Produtos de Software
Escrito por: Renata Araújo {[email protected]}
Vírginia Chalegre {[email protected]}
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.