A Norma ISO/IEC 9126 define seis características de qualidade de software que devem ser avaliados: –Funcionalidade (finalidade do produto) –Usabilidade.

Apresentação em tema: "A Norma ISO/IEC 9126 define seis características de qualidade de software que devem ser avaliados: –Funcionalidade (finalidade do produto) –Usabilidade."— Transcrição da apresentação:

1 A Norma ISO/IEC 9126 define seis características de qualidade de software que devem ser avaliados: –Funcionalidade (finalidade do produto) –Usabilidade (esforço para utilizar, aprender o produto) –Confiabilidade (freqüência de falhas, recuperabilidade) –Eficiência (desempenho) –Manutenibilidade (esforço necessário para modificar) –Portabilidade (capacidade de transferir o produto para outros ambientes) ISO/IEC 9126

2 Baseada em 3 níveis: Características, Subcaracterísticas e Métricas Cada característica é refinada em um conjunto de subcaracterísticas e cada subcaracterística é avaliada por um conjunto de métricas ISO/IEC 9126

3 O QUE Funcionalidade QUANDO e COMO Confiabilidade Usabilidade Eficiência Manutenibilidade Portabilidade ISO/IEC 9126 - Características

4 FUNCIONALIDADE - Satisfaz as necessidades? SUBCARACTERÍSTICA PERGUNTA CHAVE Adequação Propõe-se a fazer o que é apropriado? Acurácia Faz o que foi proposto de forma correta? Interoperabilidade É capaz de interagir com os sistemas especificados? Conformidade Está de acordo com as normas, leis, etc.? Segurança e ctrl de Acesso Evita acesso não autorizado a programas e dados? ISO/IEC 9126 - Características

5 CONFIABILIDADE - É imune a falhas? SUBCARACTERÍSTICA PERGUNTA CHAVE Maturidade Com que freqüência apresenta falhas por defeitos no software? Tolerância a Falhas Ocorrendo falhas, como ele reage? Recuperabilidade É capaz de recuperar dados em caso de falhas? ISO/IEC 9126 - Características

6 USABILIDADE - É fácil de usar? SUBCARACTERÍSTICA PERGUNTA CHAVE Inteligibilidade É fácil entender o conceito lógico e sua aplicabilidade? Apreensibilidade É fácil aprender a usar? Operacionalidade É fácil operar e controlar? ISO/IEC 9126 - Características

7 EFICIÊNCIA - É rápido e “enxuto” ? SUBCARACTERÍSTICA PERGUNTA CHAVE Comportamento em Qual o tempo de resposta, tempo de Relação ao Tempo processamento a velocidade na execução de suas funções? Comportamento em Quanto de recursos usa? Durante quanto Relação aos Recursos tempo? ISO/IEC 9126 - Características

8 MANUTENIBILIDADE - É fácil de modificar? SUBCARACTERÍSTICA PERGUNTA CHAVE Analisabilidade É fácil de encontrar uma falha, quando ocorre? Modificabilidade É fácil modificar e adaptar? Estabilidade Existe risco de efeitos inesperados quando se faz alterações? Testabilidade É fácil validar o software modificado? ISO/IEC 9126 - Características

9 PORTABILIDADE - É fácil de usar em outro ambiente? SUBCARACTERÍSTICA PERGUNTA CHAVE Adaptabilidade É fácil adaptar a ambientes diferentes? Capacidade para É fácil instalar? ser instalado Conformidade Está de acordo com padrões de portabilidade? Capacidade para É capaz substituir por um outro software? substituir ISO/IEC 9126 - Características

10 Exemplos de Requisitos Não Funcionais Manutenibilidade –A tabela de desconto de imposto de renda sofre alterações freqüentes Disponibilidade –O sistema deve estar disponível 99.99% do tempo 24 horas do dia Eficiência –Uma consulta aos clientes deve ocorrer em menos do que 3segs 95 % do tempo Usabilidade –O sistema deve possuir um help organizado por tópicos para sanar dúvidas do usuário

11 Requisitos não funcionais normalmente possuem métricas associadas Existem poucas métricas de aceitação geral para as características Grupos ou organizações podem estabelecer seus próprios modelos de: –processo de avaliação –métodos para a criação e validação de métricas relacionadas com as características Requisitos não funcionais têm conflito –Métricas auxiliam na escolha de requisitos conflitantes ISO/IEC 9126 - Métricas

12 Cada tipo de software tem seus próprios requisitos de qualidade A importância de cada característica de qualidade varia dependendo da Classe de software CLASSE CARACTERÍSTICA Sistema de Missão Crítica Confiabilidade Software de Sistema em Tempo Real Manutenabilidade Software Interativo em relação ao Usabilidade Usuário Final ISO/IEC 9126 - Importância das características

13 Exemplo em Sistemas de missão crítica Requisitos de Confiabilidade (Dependability) Requisitos Funcionais = definem checagem de erros e facilidades de recuperação e proteção contra falhas no ambiente externo Requisitos Não Funcionais = definem as necessidades de confiabilidade e disponibilidade do sistema ISO/IEC 9126-Importância das características

14 A importância de cada característica depende também do ponto de vista considerado Visão do Usuário –estão interessados principalmente no uso do software, no seu desempenho, e nos efeitos do uso do software –avaliam o software sem conhecer seus aspectos internos: confiabilidade, portabilidade, manutenibilidade ISO/IEC 9126 – Importância de cada característica 1/3

15 Visão da Equipe de Desenvolvimento Visão da Equipe de Desenvolvimento - Características de qualidade consideradas pelo usuário mais características internas - Qualidade dos produtos intermediários do processo de desenvolvimento do software ISO/IEC 9126 – Importância de cada característica 2/3

16 Visão do Gerente Visão do Gerente - Pode ter que balancear as melhorias na qualidade com critérios gerenciais, tais como atraso de cronograma ou estouro de orçamento - Deseja otimizar a qualidade dentro das limitações de custo, recursos humanos e prazos ISO/IEC 9126 – Importância de cada característica 3/3

17 Exercício 3 Com base no sistema de emissão de passagens de trem –Elabore uma regra de negócio –Elabore três requisitos funcionais –Elabore um requisito não funcional para cada uma das cinco características de qualidade –Identifique quais são requisitos de negócio e quais são de produto

18 Introdução a Elicitação e Gerência de Requisitos

19 Engenharia de Requisitos

20 Produção de Requisitos Também denominada de descoberta de requisitos Envolve pessoal objetivando descobrir o domínio de aplicação, serviços que devem ser fornecidos bem como restrições Deve envolver usuários finais, gerentes, pessoal envolvido na manutenção, especialistas no domínio, etc. (stakeholders) Uso de técnicas de elicitação Requisitos vão para um processo de modelagem Requisitos são validados

21 Gerência de Requisitos Objetivos: –estabelecer uma visão comum entre o cliente e a equipe de projeto em relação aos requisitos que serão atendidos pelo projeto de software –registrar e acompanhar requisitos ao longo de todo o processo de desenvolvimento Objetivos Específicos: –os requisitos são gerenciados e as inconsistências entre os planos do projeto e os produtos de trabalho são identificadas

22 “An effective requirements management process reduces project risks by systematically collecting, managing, and communicating the changing requirements of any project. The purpose of requirements management is to establish a common understanding between your team and your customer on what you will build for that customer. A well- implemented requirements management process not only helps your team deliver a quality product on time and within budget, but it can also ensure the viability of the entire project.” (IBM, 2003) Gerência de Requisitos

23 Documento de Requisitos Proposta de Estrutura da IEEE/ANSI (830-1998) 1/3 1. Introdução 1.1 Propósito do documento 1.2 Escopo do sistema 1.3 Definições, acrônimos e abreviaturas 1.4 Referências 1.5 Descrição do resto do documento

24 Documento de Requisitos Proposta de Estrutura da IEEE/ANSI (830-1998) 2/3 2. Descrição geral 2.1 Perspectiva do produto 2.2 Funções do produto 2.3 Características dos usuários 2.4 Restrições gerais 2.5 Assertivas e dependências

25 Documento de Requisitos Proposta de Estrutura da IEEE/ANSI (830-1998) 3/3 3. Requisitos específicos requisitos funcionais, não-funcionais, interface com o usuário: funcionalidade, interfaces externas, desempenho, restrições, atributos do sistema, características de qualidade,... Apêndices Índice

26 Documento de Requisitos Proposta de Estrutura do Sommerville –Introdução –Glossário –Definição dos requisitos do usuário –Arquitetura do sistema –Especificação dos requisitos do sistema –Modelos do sistema –Evolução do sistema –Apêndices –Índice

27 Exemplo de Documentação de Requisitos

28 Plano de Gerência de Requisitos Documento de Visão Glossário Documento de Especificação de Caso de Uso Documento de Especificação Suplementar Documento de Regras de Negócio

29 Plano de Gerência de Requisitos Documento que serve de guia para o gerenciamento de requisitos Define o processo implantado na empresa Define os documentos, tipos de requisitos e rastreabilidade no projeto de requisitos

30 Documento de Visão Este documento apresenta uma visão gerencial do produto a ser desenvolvido em termos de: –requisitos de negócio apresenta aqueles que estão direta/indiretamente envolvidos com o sistema contém os requisitos em um nível mais abstrato É a base contratual para a obtenção dos requisitos mais detalhados do sistema

31 Glossário Este documento possui as definições dos termos importantes utilizados no projeto

32 Especificação de Caso de Uso Este documento traz a especificação detalhada de cada caso de uso Captura os requisitos funcionais do Documento de Visão

33 Especificação Suplementar Este documento traz as especificações do sistema que não foram capturadas pelos casos de uso, tais como itens de qualidade, incluindo usabilidade, segurança e desempenho, ou outras questões como sistema operacional e ambiente Captura os requisitos não funcionais do Documento de Visão

34 Regras de Negócio Neste documento são apresentadas as regras de negócio do sistema Regra de Negócio tem por objetivo descrever os aspectos do negócio –Exemplo de regra de negócio de um banco: A operação de transferência deve ser <= R$ 1000,00 por dia por cliente –Exemplo de regra de negócio para áreas de desenvolvimento de software: novos desenvolvimentos de software devem ser atendidos por projeto ou Ordem de Serviço com Documento de Solução É um documento opcional

35 O Processo de Engenharia de Requisitos

36 A meta é o reconhecimento dos elementos básicos do problema, conforme percebidos pelo cliente clientes Administrador do projeto analista desenvolvedores Plano de projeto de software Espec. requisitosprotótipo

37 O Processo de Engenharia de Requisitos 1.Reconhecimento do Problema Planejamento 2.Obtenção e Análise dos Requisitos Avaliação do problema e síntese da solução Elaboração de Modelos 3.Especificação dos requisitos Documento que detalha os requisitos coletados  funcionais (normalmente detalhados nos modelos elaborados na fase 2)  não funcionais 4.Validação Revisão

38 O processo de Engenharia de Requisitos

39 1. Reconhecimento do problema Antes de iniciar o desenvolvimento é necessário elaborar um plano –Um plano necessita considerar o futuro O Plano de Projeto de Software –Reconhecimento do problema  Documento de Visão Um levantamento preliminar de requisitos –Anteprojeto  Documento de Solução Soluções possíveis e a escolhida Análise de risco Estudo de viabilidade Custo e prazo

40 Estudo de Viabilidade Breve e direcionado O sistema contribui para os objetivos gerais da organização? O sistema pode ser implementado com a utilização de tecnologia atual e com as restrições de prazo e custo? Pode ser integrado a outros sistemas já em operação?

41 Estudo de Viabilidade Envolve coletar informações e redigir relatórios Exemplos de questões a responder: –Como a organização se comportaria se o sistema não fosse implementado? –Quais os problemas com os processos atuais e como o novo sistema ajudaria a diminuí-los? –Que contribuição direta trará para os objetivos da empresa? –As informações poderão ser empregadas em outros sistemas? –Requer nova tecnologia? risco associado ao desenvolvimento –O que precisa e o que não precisa ser compatível?

42 Estudo de Viabilidade Fontes de informação –Gerentes de departamentos e usuários –Engenheiros de software familiarizados com esta classe de sistema –Peritos em tecnologia –Usuários finais Importância de esclarecer o objetivo do sistema nos níveis –Estratégico – o quanto a empresa será mais competitiva –Tático – o quanto vai ganhar –Operacional – como ficará a operação

43 Estudo de Viabilidade Exercício: Desenvolver um estudo de viabilidade para o sistema de venda de passanges.