Mauricio   Puc Rio (Er)   Aula 7   Primeiro Artigo
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

Mauricio Puc Rio (Er) Aula 7 Primeiro Artigo

on

  • 604 views

 

Statistics

Views

Total Views
604
Views on SlideShare
582
Embed Views
22

Actions

Likes
0
Downloads
1
Comments
0

1 Embed 22

http://transparenciadesoftware.wordpress.com 22

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Mauricio Puc Rio (Er) Aula 7 Primeiro Artigo Presentation Transcript

  • 1. Representing and Using Nonfuctional Requirements: A Process-Oriented Approach Aluno: Maurício Serrano Abril 2008 Análise do Artigo Pontifícia Universidade Católica do Rio de Janeiro (PUC-Rio)
  • 2. Índice
    • Introdução
    • Trabalhos Relacionados
    • Abordagem Orientada a Processo
    • Framework proposto pelos Autores
    • Exemplos:
      • Requisito Não-Funcional de Precisão ( Accuracy )
      • Requisito Não-Funcional de Performance ( Performance )
    • Conclusão
    • Referência
    Pontifícia Universidade Católica do Rio de Janeiro (PUC-Rio)
  • 3. Introdução Pontifícia Universidade Católica do Rio de Janeiro (PUC-Rio) Transparência de Software
  • 4. Introdução
    • A complexidade em Sistemas de Informação é dada por FRs e NFRs ;
    • NFRs são utilizados como critérios de seleção;
    • Erros em NFRs são os mais caros e mais difíceis de serem corrigidos; e
    • NFRs recebem menos atenção que os FRs e outros fatores menos importantes.
    Pontifícia Universidade Católica do Rio de Janeiro (PUC-Rio)
  • 5. Introdução
    • NFRs são tratados informalmente na fase de requisitos;
    • NFRs são normalmente contraditórios;
    • NFRs são difíceis de se garantir durante o Desenvolvimento de Software;
    • NFRs são difíceis de se validar junto ao usuário final; e
    • NFRs não possuem uma definição formal ou mesmo uma lista completa.
    Pontifícia Universidade Católica do Rio de Janeiro (PUC-Rio)
  • 6. Trabalhos Relacionados Pontifícia Universidade Católica do Rio de Janeiro (PUC-Rio) Transparência de Software
  • 7. Trabalhos Relacionados Abordagem Informal Em um relatório publicado em Rome Air Development Center ( RADC ) [7], NFRs são classificados em: Pontifícia Universidade Católica do Rio de Janeiro (PUC-Rio) Technically-Oriented Consumer-Oriented
  • 8. Trabalhos Relacionados Abordagem Formal As abordagens formais podem ser divididas em: Pontifícia Universidade Católica do Rio de Janeiro (PUC-Rio) Product-Oriented Process-Oriented
  • 9. Trabalhos Relacionados – Product-Oriented
    • Existe um overview publicado em [26];
    • Boehm et al. [5] considera características de qualidade de software e percebe que a experiência do designer aumenta a qualidade do produto final; e
    • Basili e Musa [3] propõem modelos e métricas (quantitativas) para o processo de engenharia de software sob o ponto de vista da gerência.
    Pontifícia Universidade Católica do Rio de Janeiro (PUC-Rio)
  • 10. Trabalhos Relacionados – Base para a Proposta
    • Sistemas de apoio à decisão [19] [28] [29];
    • Modelos para representar Design Rationales [38];
    • Ambientes para desenvolvimento de Sistemas de Informação DAIDA [23]:
      • Framework para o desenvolvimento de software com notações para modelagem de requisitos, design , implementação e apoio à decisão;
      • Ponto de partida para o tratamento de requisitos não-funcionais;
      • A especificação dos requisitos restringe a especificação do design;
      • A especificação do design restringe a implementação; e
      • Utiliza dependency links .
    Pontifícia Universidade Católica do Rio de Janeiro (PUC-Rio)
  • 11. Abordagem Orientada a Processo Pontifícia Universidade Católica do Rio de Janeiro (PUC-Rio) Transparência de Software
  • 12. Abordagem Orientada a Processo
    • É a abordagem utilizada pelos autores;
    • Justifica decisões de design durante o Processo de Desenvolvimento de Software;
    • Evita avaliar o produto;
    • As decisões de design podem afetar positivamente ou negativamente NFRs particulares; e
    • Utiliza essas contribuições como base para questionar se o software contempla um certo NFR .
    Pontifícia Universidade Católica do Rio de Janeiro (PUC-Rio)
  • 13. Abordagem Orientada a Processo
    • Pode ser quantitativa ou qualitativa;
    • A proposta dos autores é qualitativa;
    • Uma abordagem quantitativa poderia, por exemplo, medir a visibilidade do software em desenvolvimento;
    Pontifícia Universidade Católica do Rio de Janeiro (PUC-Rio) Qualitativa Quantitativa X
  • 14. Framework proposto pelos Autores Pontifícia Universidade Católica do Rio de Janeiro (PUC-Rio) Transparência de Software
  • 15. Framework proposto pelos Autores Pontifícia Universidade Católica do Rio de Janeiro (PUC-Rio)
    • O framework proposto pelos autores utiliza cinco componentes:
    • Goals;
    • Link Types;
    • Methods;
    • Correlation Rules; e
    • Labelling Procedure.
  • 16. Framework proposto pelos Autores - Goals Pontifícia Universidade Católica do Rio de Janeiro (PUC-Rio)
    • Três classes mutuamente exclusivas de goals :
    • Nonfunctional Requirement Goals (NFRGoals):
      • Compreende o espaço dos vários NFRs.
      • Exemplo: Accuracy[attributes(Employee)]
    • Satisficing Goals (SatGoals):
      • Compreende as decisões de design que podem ser adotadas para satisfazer NFRGoals .
      • Exemplo: Validation[attributes(Employee)]
    • Argumentation Goals (ArgGoals);
      • Compreende afirmações formais ou informais.
      • Exemplo:
  • 17. Framework proposto pelos Autores – Link Types Pontifícia Universidade Católica do Rio de Janeiro (PUC-Rio)
    • O framework utiliza links para refinar um goal em outros goals :
      • AND : equivalente a árvores AND/OR ;
      • OR : idem;
      • sup : supergoal ;
      • sub : subgoal ;
      • eql : equivalente;
      • und : indeterminado.
  • 18. Framework proposto pelos Autores – Link Types Pontifícia Universidade Católica do Rio de Janeiro (PUC-Rio)
    • Satisficing Link:
      • Utilizado para “ligar” goals.
    • Dependency Link:
      • Utilizados para mapear objetos.
    • Justification-for-selection Link.
      • Utilizados para justificar dependências através de SatGoals .
  • 19. Framework proposto pelos Autores – Link Types Pontifícia Universidade Católica do Rio de Janeiro (PUC-Rio)
    • O framework define formalmente esses links e os seguintes predicados:
      • Proposition ;
      • Satisficed ;
      • Denied ;
      • Satisficeable ; e
      • Deniable .
  • 20. Framework proposto pelos Autores – Methods Pontifícia Universidade Católica do Rio de Janeiro (PUC-Rio)
    • O framework proposto pelos autores utiliza três métodos, um para cada tipo de goal :
    • Goal Decomposition Methods:
      • Decompõem um goal em outros goals ;
      • Links do tipo AND e OR.
    • Goal Satisficing Methods:
      • Decompõem um NFRGoal em SatGoals;
      • Links do tipo und, eql, sup e sub.
    • Argumentation Methods:
      • Refinam um goal ou um link em um ArgGoal, indicando evidência ou contra-evidência para satisfação desse goal ;
      • Links do tipo AND .
  • 21. Framework proposto pelos Autores – Correlation Rules Pontifícia Universidade Católica do Rio de Janeiro (PUC-Rio)
    • Regras de correlação detalham ou restringem as interações entre goals . Essas regras têm as seguintes características:
      • São regras expressas formalmente;
      • Podem inferir novas regras de correlação;
      • Pode-se aplicar um procedimento de expansão, expandindo goals e aplicando regras de correlação.
  • 22. Framework proposto pelos Autores – Labelling Procedure Pontifícia Universidade Católica do Rio de Janeiro (PUC-Rio)
    • Pode-se atribuir os seguintes rótulos aos goals :
      • Satisficed;
      • Denied;
      • Conflicting; e
      • Undertermined.
    • Como poucas informações estão inseridas formalmente, o designer pode ter que determinar o rótulo.
  • 23. Framework proposto pelos Autores – Labelling Procedure Pontifícia Universidade Católica do Rio de Janeiro (PUC-Rio)
    • Um procedimento de rotulação interativo é utilizado de forma a obter rótulos para todos os goals ;
    • Regras de propagação também são utilizadas;
    • O procedimento pode ser comparado com os utilizados em Sistemas de Manutenção de Fatos que mantêm crenças, justificativas e suposições;
    • Não é automático.
  • 24. Exemplo: Requisito Não-Funcional de Precisão Pontifícia Universidade Católica do Rio de Janeiro (PUC-Rio) Transparência de Software
  • 25.  
  • 26.  
  • 27. Exemplo: Requisito Não-Funcional de Performance Pontifícia Universidade Católica do Rio de Janeiro (PUC-Rio) Transparência de Software
  • 28.  
  • 29. Conclusão Pontifícia Universidade Católica do Rio de Janeiro (PUC-Rio) Transparência de Software
  • 30. Conclusão
    • O framework :
      • é um framework concreto para integrar requisitos não-funcionais no Processo de Desenvolvimento de Software;
      • ainda está sendo refinado;
      • possui uma ferramenta protótipo.
      • precisa ser aplicado em outros requisitos não-funcionais;
      • precisa ser utilizado em exemplos mais reais;
      • precisa de uma base teórica com semântica para NFRs e uma teoria de prova.
    Pontifícia Universidade Católica do Rio de Janeiro (PUC-Rio)
  • 31. Referência Pontifícia Universidade Católica do Rio de Janeiro (PUC-Rio) Transparência de Software
  • 32. Referência
    • John Mylopoulos, Lawrence Chung, and Brian Nixon. “ Representing and Using Nonfuctional Requirements: A Process-Oriented Approach .” IEEE TRANSACTIONS ON SOFTWARE ENGINEbRING, VOL. 18. NO. 6, pp. 483-497, JUNE 1992.
    Pontifícia Universidade Católica do Rio de Janeiro (PUC-Rio)