1 / 23

Ferramenta para Captura e Representação de Design Rationale Aplicado a Requisitos de Software

Ferramenta para Captura e Representação de Design Rationale Aplicado a Requisitos de Software. Aluna: Carolina Paloma Gasperoni Orientador: Prof. Dr. Elias Canhadas Genvigir Cornélio Procópio 2011. ROTEIRO. Introdução Design Rationale Justificativa Objetivos Arquitetura do Sistema

marie
Download Presentation

Ferramenta para Captura e Representação de Design Rationale Aplicado a Requisitos de Software

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Ferramenta para Captura e Representação de Design RationaleAplicado aRequisitos de Software Aluna: Carolina Paloma Gasperoni Orientador: Prof. Dr. Elias CanhadasGenvigir Cornélio Procópio 2011

  2. ROTEIRO • Introdução • Design Rationale • Justificativa • Objetivos • Arquitetura do Sistema • Tecnologias • Escopo do Trabalho • Metodologia de Desenvolvimento • Metodologia de Pesquisa • Cronograma

  3. INTRODUÇÃO • Engenharia de Requisitos; • Requisitos; Representação das Fases da Engenharia de Requisitos (KOTONYA, 1997).

  4. Tem-se as primeiras fases da Engenharia de Requisitos como as mais importantes de todo o processo de desenvolvimento, pois requisitos mal especificados ou levantados de forma errada são apontados como os grandes causadores de atrasos, retrabalhos e falhas em projetos (CHRISTEL; KANG, 1992; LEITE, 1987). • O finalidade deste trabalho é desenvolver uma ferramenta para Gerenciar o DesignRationale dos Requisitos de Software durante a fase de Análise e Negociação.

  5. DESIGN RATIONALE • É o registro e a representação explicita das informações que deram suporte ao o processo para tomada de decisões de projeto. Processo de decisão

  6. Inclui as razões e justificativas por trás de uma decisão, as alternativas consideradas ou descartadas, as soluções avaliadas e os argumentos que conduziram a decisão final de projeto (LEE, 1997). • Pode ser aplicado em diversas fases do processo de desenvolvimento.

  7. VANTAGENS • Suporte ao desenvolvimento do projeto (LEE, 1997); • Suporte à Verificação (BURGE; BROWN, 1998); • Suporte à Manutenção do projeto (BURGE; BROWN, 1998); • Suporte à Documentação (BURGE; BROWN, 1998); • Suporte à Rastreabilidade dos Requisitos;

  8. É COMPOSTO POR: • Métodos para Captura; • Modelos para Representação.

  9. MÉTODOS PARA CAPTURA • Reconstrução; • Subproduto Metodológico; • Aprendiz;

  10. REPRESENTAÇÃO • Formal; • Informal; • Semi-formal.

  11. MODELOS PARA REPRESENTAÇÃO • IBIS (IssueBasedInformation System)

  12. QOC (Question, OptionandCriteria)

  13. JUSTIFICATIVA • Durante o projeto, os requisitos mudam por diversas razões. • A mudança em uma decisão de projeto, como a alteração em um requisito, pode gerar impactos no sistema (HAN, 1997). • Para analisar o impacto das mudanças de forma eficaz, é necessário que a fonte de cada requisito seja conhecida e as razões (rationales) para qualquer alteração também seja documentada (CMMI, 2001).

  14. O Design Rationale auxilia em manter um histórico do processo de tomada de decisão. Fornece um maior controle sobre os artefatos alterados. • O Design Rationalede requisitos fornece meios para identificar conflitos, inconsistências e diagnosticar o impacto das alterações (BURGE et al., 2008). • Benefícios a longo prazo, como maior satisfação do cliente e menor custo de desenvolvimento.

  15. OBJETIVOS • Desenvolver uma ferramenta para a captura e representação de Design Rationale para requisitos de software. • Primeiramente deverá ser feito um estudo sobre os requisitos de software para definir regras sobre o que capturar. • Em um segundo momento se dará a construção da ferramenta para a captura e representação de DesignRationale.

  16. ARQUITETURA DO SISTEMA

  17. TECNOLOGIAS • Java; • JEE • JavaScript; • AJAX; • JSP; • NetBeans; • PostgreSQL; • TortoiseSVN; • Astah;

  18. MODELO ARQUITETURAL GERAL

  19. ESCOPO DE TRABALHO

  20. METODOLOGIA DE DESENVOLVIMENTO • Adaptado; • Modelo Iterativo Incremental;

  21. METODOLOGIA DE PESQUISA • Objetivo Exploratório: • Proporcionar maior familiaridade com o problema; • Acompanhadas e aprofundadas na pesquisa bibliográfica ; • Fundamentar teoricamente a pesquisa; • Teórico-bibliográfica • Identificação das fontes seguras; • Localização dessas fontes; • Compilação das informações; • Abordagem Qualitativa: • Descrições; • Comparações e Interpretações; • As informações obtidas não podem ser quantificáveis.

  22. CRONOGRAMA

  23. REFERÊNCIAS • CHRISTEL, M. G.; Kang, K. C. Issues in Requirement Elicitation. Software Engineering Institute. Carnegie Mellon University, Pittsburgh, Pennsylvania, 1992. • CMMI - Requirements Managements. Disponível em: <http://www.software-quality-assurance.org/cmmi-requirements-management.html#sp13>. Acesso em: 19 jun. 2011. • LEE, J. Design rationale systems: Understanding the issues. IEEE Expert/Intelligent Systems and Their Applications, 1997. • BURGE, J.E.; CARROLL, J.M., MCCALL, R., MISTRÍK, I. Rationale-Based Software Engineering. Computer Science, 2008. • BURGE, J. E.; BROWN, D. C. Design Rationale Types and Tools. Technical Report. Worchester Polytechnic Institute, Computer Science Dept., 1998. • LEITE, J.C.S.P. A Survey on Requirements Analysis. Advanced Software Engineering Project Technical Report RTP-071, University of California at Irvine, Department of Information and Computer Science, 1987. • SOMMERVILLE, I. Software Engineering. England: Addison-Wesley Publishers, 1998.

More Related