ISOIEC 9126 A Norma ISOIEC 9126 define seis

ISO/IEC 9126 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 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 - Características O QUE Funcionalidade QUANDO e COMO Confiabilidade Usabilidade Eficiência Manutenibilidade Portabilidade

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

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

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 3 segs 95 % do tempo Usabilidade – O sistema deve possuir um help organizado por tópicos para sanar dúvidas do usuário

ISO/IEC 9126 - Métricas 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 - Importância das características 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 Usuário Final Usabilidade

ISO/IEC 9126 -Importância das características 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 de cada característica 1/3 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 2/3 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 3/3 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

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

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

Engenharia de Requisitos

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

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

Gerência de Requisitos “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 wellimplemented 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)

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

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

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

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

Exemplo de Documentação de Requisitos

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

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

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

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

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

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

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

O Processo de Engenharia de Requisitos

O Processo de Engenharia de Requisitos Administrador do projeto clientes Plano de projeto de software analista Espec. requisitos desenvolvedores protótipo • A meta é o reconhecimento dos elementos básicos do problema, conforme percebidos pelo cliente

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

O processo de Engenharia de Requisitos

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

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?

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?

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

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