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

1. Modelagem i* da norma NBR ISO/IEC 9126-1:2001 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

2. ROTEIRO • INTRODUÇÃO • OBJETIVO • NBR ISO/IEC 9126-1:2001 • REQUISITOS NÃO FUNCIONAIS (NFR’S) • SOBRE i* • MODELO SR

3. 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.

4. 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).

5. 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].

6. Esta 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 NBR ISO/IEC 9126 • ISO 9126 é dividida em quatro partes:

7. NBR ISO/IEC 9126 • 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.

8. NBR ISO/IEC 9126-1:2001 • 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.

10. 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.

12. SOBRE i*

13. 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.

14. 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).

15. 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.

16. 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.