a norma iso/iec 9126 define seis características de qualidade de software que devem ser avaliados:...

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

O QUEO QUE

FuncionalidadeQUANDO e COMOQUANDO e COMO

Confiabilidade

Usabilidade

Eficiência

Manutenibilidade

Portabilidade

ISO/IEC 9126 - Características

FUNCIONALIDADE - Satisfaz as necessidades?FUNCIONALIDADE - Satisfaz as necessidades?

SUBCARACTERÍSTICA PERGUNTA CHAVESUBCARACTERÍ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?


CONFIABILIDADE - É imune a falhas?CONFIABILIDADE - É imune a falhas?


• 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?


USABILIDADE - É fácil de usar?USABILIDADE - É fácil de usar?


• Inteligibilidade É fácil entender o conceito lógico e sua aplicabilidade?

• Apreensibilidade É fácil aprender a usar?

• Operacionalidade É fácil operar e controlar?


EFICIÊNCIA - É rápido e “enxuto” ?EFICIÊNCIA - É rápido e “enxuto” ?


• 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?


MANUTENIBILIDADE - É fácil de modificar?MANUTENIBILIDADE - É fácil de modificar?


• 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?


PORTABILIDADE - É fácil de usar em outro ambiente?PORTABILIDADE - É fácil de usar em outro ambiente?


• 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


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

Requisitos não funcionais normalmente possuem métricas associadasExistem poucas métricas de aceitação geral para as característicasGrupos 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

Cada tipo de software tem seus próprios requisitos de qualidadeA 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

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

A importância de cada característica depende também do ponto de vista considerado

Visão do UsuárioVisã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

Visão da Equipe de DesenvolvimentoVisã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


Visão do GerenteVisã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 requisitosEnvolve pessoal objetivando descobrir o domínio de aplicação, serviços que devem ser fornecidos bem como restriçõesDeve envolver usuários finais, gerentes, pessoal envolvido na manutenção, especialistas no domínio, etc. (stakeholders)Uso de técnicas de elicitaçãoRequisitos vão para um processo de modelagemRequisitos 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

“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

Documento de Requisitos

Proposta de Estrutura da IEEE/ANSI (830-1998) 1/3

1. Introdução1.1 Propósito do documento1.2 Escopo do sistema1.3 Definições, acrônimos e abreviaturas1.4 Referências1.5 Descrição do resto do documento



2. Descrição geral2.1 Perspectiva do produto 2.2 Funções do produto2.3 Características dos usuários2.4 Restrições gerais2.5 Assertivas e dependências



3. Requisitos específicosrequisitos 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


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 RequisitosDocumento de Visão GlossárioDocumento de Especificação de Caso de UsoDocumento de Especificação SuplementarDocumento de Regras de Negócio

Plano de Gerência de Requisitos

Documento que serve de guia para o gerenciamento de requisitosDefine o processo implantado na empresaDefine 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 usoCaptura 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 ambienteCaptura 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 sistemaRegra 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


•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. requisitos protótipo


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 direcionadoO 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?


Envolve coletar informações e redigir relatóriosExemplos 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?


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


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

a norma iso/iec 9126 define seis características de qualidade de software que devem ser avaliados:...

Documents