Slide sem t

1
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)

2
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

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

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

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

7
ISO/IEC 9126 - Características
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?

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

9
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 É fácil instalar?
• ser instalado
• Conformidade Está de acordo com
  padrões de portabilidade?
• Capacidade para É capaz substituir por um
  outro software?
• substituir

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

12
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
  Usabilidade
• Usuário Final
  

13
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

14
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

15
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

16
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

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
(No Transcript)
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
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 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)
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 lt 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
(No Transcript)
37
O Processo de Engenharia de Requisitos

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

38
(No Transcript)
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.