Caso De Uso E Use Case Point

3,866
-1

Published on

Apresentação de Casos de Uso e Estimativas por Pontos de Caso de Uso (Use Case Point)

0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
3,866
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
104
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Caso De Uso E Use Case Point

  1. 1. Abordagem conceitual sobre Casos de Uso e realização de estimativas com o uso de Casos de Uso Marcelo Schumacher Novembro de 2012
  2. 2. Objetivos Aproximar a visão de negócio da área de análise de sistemas; Melhorar a definição de nossas estimativas/esforços de trabalho; Facilitar a compreensão das expectativas dos clientes por parte dos analistas; Melhorar a qualidade de nosso processo de desenvolvimento; Melhorar a qualidade de nosso produto de software; Minimizar a mudança de escopo durante o andamento dos trabalhos de construção; Reduzir os retrabalhos;
  3. 3. Pauta Requisitos de Software; UML; Casos de Uso; Estimativas baseadas em ponto de Caso de Uso (Use Case Point)
  4. 4. Requisitos de Software Requisitos de software nada mais são do que um conjunto de atividades que o software deve desempenhar, com suas limitações e restrições, além de características não ligadas diretamente às funções desempenhadas pelo software (SOMMERVILLE, 2003); Quanto mais compreensível, precisa e rigorosa for a descrição de um requisito de sistema, maior será a proporção quanto ao grau de qualidade do produto resultante (PETERS, 2001); Os requisitos de sistema são normalmente categorizados como funcionais, não funcionais ou requisitos de domínio. A seguir, abordaremos cada uma destas categorias.
  5. 5. Requisitos de Software Funcionais: Tratam de funções que o sistema deve fornecer, como o sistema deve se comportar a estradas e a determinadas situações (PRESSMAN, 2001). Em outras palavras, descrevem a funcionalidade ou serviço que se espera que o sistema forneça. Dependendo do tipo de software do requisito a ser descrito é possíveis criar subgrupos de requisitos funcionais (SOMERVILLE, 2001); Não-funcionais: Dizem respeito às restrições sobre os serviços ou funções do sistema. Por exemplo, restrição de tempo, restrição do processo de desenvolvimento, usabilidade, confiabilidade, desempenho, suporte, padrões, etc. (PRESSMAN, 2001); Requisitos de Domínio: Os Requisitos de Domínio originam-se do domínio da aplicação do sistema, refletindo as características deste domínio (SOMMERVILLE, 2003). Podem ser funcionais ou não (PRESSMAN, 2001).
  6. 6. Requisitos de Software Req. Usuário Requisitos Funcionais Req. Sistema ISO 9126 Req. Usabilidade Req.Requisitos Desempenho Req. Qualidade Req. Eficiência ou Produto Req. Espaço Req. Confiabilidade Requisitos Não Funcionais Req. Req. Gestão do Organizacionais Projeto Req. Externos Req. Integração Classificação Características
  7. 7. Requisitos de Software Requisito Classificação Característica Manter Alunos Funcional > Req. Usuário Matricular Aluno Funcional > Req. Usuário Emitir Diário de Classe da Turma Funcional > Req. Usuário Configurar Cálculo de Notas Funcional > Req. Usuário Registrar Notas Funcional > Req. Usuário Calcular Notas Funcional > Req. Sistema Relatório de Histórico do Aluno Funcional > Req. Usuário Não Funcional > Req. Qualidade ou Banco de Dados Oracle Produto Req. Confiabilidade Não Funcional > Req. Qualidade ouLinguagem de Programação .NET Produto Req. Confiabilidade Não Funcional > Req. Qualidade ou Interfaces devem seguir Padrão Produto Req. Usabilidade Não Funcional > Req. Qualidade ou Necessário 400gb de Espaço Produto Req. Eficiência > Req. Espaço Não Funcional > Req. Qualidade ouLimite 30s de tempo de Resposta Produto Req. Eficiência > Desempenho
  8. 8. UML A Unified Modeling Language (UML) é uma linguagem de modelagem não proprietária de terceira geração. A UML não é uma metodologia de desenvolvimento, o que significa que ela não diz para você o que fazer primeiro e em seguida ou como projetar seu sistema, mas ela lhe auxilia a visualizar seu desenho e a comunicação entre objetos; Basicamente, a UML permite que desenvolvedores visualizem os produtos de seus trabalhos em diagramas padronizados. Junto com uma notação gráfica, a UML também especifica significados, isto é, semântica. É uma notação independente de processos, embora o RUP (Rational Unified Process) tenha sido especificamente desenvolvido utilizando a UML; Os objetivos da UML são: especificação, documentação, estruturação para sub-visualização e maior visualização lógica do desenvolvimento completo de um sistema de informação. A UML é um modo de padronizar as formas de modelagem.
  9. 9. UML: Diagramas
  10. 10. Casos de Uso Conjunto de cenários que descreve a seqüência de eventos que um ator segue numa interação com o SsD (Sistema sob Desenvolvimento) para atingir um objetivo; É uma técnica de modelagem usada para descrever o que o novo sistema deve fazer sob ponto de vista comportamental; Ele é construído através de um processo interativo no qual as discussões entre o cliente e os envolvidos do sistema conduzem a uma especificação do sistema da qual todos estão de acordo, funcionando como um contrato; Utilizado para capturar requisitos funcionais através da perspectiva dos interessados no sistema (stakeholders);
  11. 11. Casos de Uso Ao utilizar a UML, um caso de uso pode ser considerado o elemento central de todo o desenvolvimento; Um caso de uso representa a especificação de uma sequência de ações, incluindo variantes, que o sistema pode executar quando interagindo com os atores do sistema. Um ator representa qualquer entidade que interage com o sistema; O caso de uso permanece válido desde a análise de requisitos até os testes do sistema; O valor do caso de uso reside no seu texto; Técnica de escrita de bons casos de uso não é trivial; Princípio KISS (Keep it Simple, Stupid): Um bom caso de uso é fácil de ler.
  12. 12. Casos de Uso: Objetivos Decidir e descrever os requisitos funcionais do sistema; Fornecer uma descrição clara e consistente do que o sistema deve fazer; Um Caso de Uso pode agregar um ou mais requisitos; Os Casos de Uso podem representar os requisitos funcionais do sistema numa perspectiva comportamental;
  13. 13. Casos de Uso: Elemento Central
  14. 14. Casos de Uso: Modelagem Constitui de 2 partes:  1. Um diagrama que fornece uma visão geral dos atores e os UCs bem como suas interações;  2. A descrição dos UCs detalhando os requisitos e documentando o fluxo de eventos entre os atores e o sistema.  Um cenário representa uma sequência específicade de ação ilustrando um comportamento - ilustra uma interação de uma instância do UC.
  15. 15. Casos de Uso: Modelagem - Objetivo O Diagrama de Caso de Uso é um diagrama da UML cujo objetivo é representar um recurso de sistema que será automatizado. Um recurso de sistema trata-se da necessidade/expectativa que precisa ser atendida para satisfazer o cliente; Para construí-los usamos Atores para representar as entidades que interagem com o Sistema. Atores podem ser usuários, máquinas, sensores, impressoras, etc. Um ator representa um papel no Sistema, mas um papel pode ser representado por vários atores;
  16. 16. Casos de Uso: Modelagem - Exemplo
  17. 17. Casos de Uso: Modelagem - Elementos Ator: é uma coisa (pessoa, objeto, outro sistema, etc.) que utiliza o sistema e tem um objetivo.  Primário: é um stakeholder que chama o sistema para entregar um de seus serviços. Em geral, é o ator que aciona o caso de uso. Usuário  Secundário: ator externo que fornece um serviço ao SsD (Sistema sob Discussão). Ex: Fazer Login impressora, serviço de internet. Atenção: SsD não é ator primário ou de suporte para nenhum caso de uso.
  18. 18. Casos de Uso: Modelagem - Elementos Cenários: conjunto de passos que o ator segue para atingir um objetivo. Documento narrativo que descreve a seqüência de eventos feitos por um ator no uso do sistema.  Principal: caminho de sucesso, quando tudo Usuário ocorre como deveria;  Alternativo: caminho de sucesso, porém Fazer Login alternativo;  Exceção: quando pode ocorrer um erro.
  19. 19. Casos de Uso: Modelagem - Elementos Cenário Principal como Elemento Central
  20. 20. Casos de Uso: Modelagem - Elementos Pré-condições: o que precisa ser atendido ou o que é pré-requisito para que a execução do Caso de Uso seja efetuada. São os parâmetros de Entrada; Pós-condições: Trata-se do conjunto de informações resultantes de determinada tarefa.
  21. 21. Casos de Uso: Modelagem - Elementos Atores: É um papel que um usuário desempenha em relação ao sistema. Um caso de uso pode ter vários atores. Os atores não precisam ser humanos, o ator pode ser um sistema externo que necessita de alguma informação do sistema atual; Usuário Associações: Além das associações entre atores e casos de uso, você pode ilustrar vários tipos de associações entre casos de uso. Destacam-se três tipos de associações:
  22. 22. Casos de Uso: Modelagem - Elementos Inclusão (Include): Ocorre quando há uma parte do comportamento que é semelhante em mais casos de uso. Ou seja, quando um caso de uso “usa” o outro. Não se justifica o seu uso para modelar sequências;
  23. 23. Casos de Uso: Modelagem - Elementos• Extensão (Extends): Usado quando há uma variação em um comportamento normal. Ou seja, quando um caso de uso “estende” o outro. Isto é, quando o segundo caso de uso acrescenta novos comportamentos ao primeiro já modelado;
  24. 24. Casos de Uso: Modelagem - Elementos• Generalização: Quando há uma semelhança entre atores ou casos de uso;
  25. 25. Casos de Uso: Modelagem - Observações• O nome dos casos de uso deve ser um verbo que facilite a identificação da funcionalidade;• O uso de extends, includes e generalizações deve ser usado somente quando agregar valor à modelagem e, portanto, deve-se evitar o seu uso de forma indiscriminada;• A UML define apenas o diagrama de casos de uso, mas não a forma de escrita. O texto do caso de uso é o elemento mais importante e deve ser padronizado de acordo com o seu uso;• Um caso de uso deve ser fácil e simples de ler, por qualquer stakeholder. Casos de uso complexos, com muitos passos, linguagem difícil e com jargões, devem ser evitados ao máximo;• O processo de escrita de casos de uso é, necessariamente, colaborativo e iterativo-incremental. Revisão em pares também são importantes para melhorar a escrita. Não existe caso de uso certo ou errado, mas sim aqueles que atingem o seu objetivo de maneira melhor que outros.
  26. 26. Casos de Uso: Modelagem - Exemplo
  27. 27. Casos de Uso: Modelagem - Exemplo Estacionar Veículo Resumo O Cliente chega com o seu veículo e para na cancela na entrada do estacionamento. O sistema aguarda que ele ative a solicitação de emissão de ticket, fornecendo o comprovante de entrada do veículo. O cliente pega o ticket e procura uma vaga para estacionar. Ator: Cliente Pré-condições: cancela disponível para retirada de ticket Pós-condições: cliente com ticket registrado com data/hora de entrada
  28. 28. Casos de Uso: Modelagem - Exemplo Estacionar Veículo Fluxo Principal 1. O cliente para o seu veículo em frente a cancela de entrada; 2. O sistema lhe dá as boas-vindas, tira uma fotografia de frente do veículo e pede ao cliente que solicite o ticket; 3. O cliente solicita o ticket, o sistema gera o ticket contendo a data e hora de entrada, bem como um identificador e pede ao cliente para pegar o ticket de estacionamento; 4. O cliente retira o ticket, a cancela se abre e o cliente estaciona o seu veículo; 5. O caso de uso é encerrado.
  29. 29. Casos de Uso: Modelagem - Exemplo Estacionar Veículo Fluxo Alternativo: Cliente não Retira Ticket 4.a) O sistema aguarda 5 segundos pelo cliente e repete a mensagem para que retire o ticket por 3 vezes. Em cada uma das vezes, o volume do aviso é aumentado em 25%; 4.b) O sistema emite um aviso ao posto de atendimento, que por sua vez informa ao supervisor para que este verifique a situação, e fica esperando pelo comando do atendente, que deve reiniciar a operação. A qualquer momento, se o cliente retirar o ticket, o caso de uso prossegue no passo 3 do cenário de sucesso.
  30. 30. Casos de Uso: Modelagem - Exemplo Estacionar Veículo Fluxo de Exceção: Estacionamento Esgotado 4.a) O sistema, ao detectar que a capacidade de estacionamento foi atingida, informa ao cliente que o estacionamento está esgotado e que há uma tolerância de 15 minutos para o cliente deixar o estacionamento sem pagar; 4.b) O cliente retira o ticket e dirige-se a saída do estacionamento.
  31. 31. Casos de Uso: Modelagem - Elementos Cenário Principal como Elemento Central
  32. 32. Casos de Uso: ModelagemPerguntas?
  33. 33. Casos de Uso: Use Case Point Conceitos  Método de estimativa baseado em estimativa por ponto de função;  Criado por Gustav Karner em 1993 na Objectory (depois Rational, IBM);  Unidade de Medida: UCP (Use Case Points – Pontos de Caso de Uso);  Cada ponto de caso de uso deve ser multiplicado pelo índice de produtividade da equipe. Karner sugere uma média de 20 horas por ponto de caso de uso. Segundo estudos posteriores, cada ponto de caso de uso gasta entre 15 e 30 horas para ser desenvolvido (podendo sofrer variações de acordo com o projeto, tecnologia e time envolvidos);  É possível realizar estimativas confiáveis numa etapa inicial do projeto, de levantamento de requisitos, sem necessariamente avançar para as etapas de análise de sistemas e projeto de software, diferente do método de pontos de função.
  34. 34. Casos de Uso: Use Case Point Parâmetros Objetivos de Entrada: Atores
  35. 35. Casos de Uso: Use Case Point Parâmetros Objetivos de Entrada: Casos de Uso
  36. 36. Casos de Uso: Use Case Point Parâmetros Subjetivos de Entrada:TCF (Ajuste de Fatores Técnicos)
  37. 37. Casos de Uso: Use Case Point Parâmetros Subjetivos de Entrada: EF (Ajuste de Fatores Ambientais)
  38. 38. Casos de Uso: Use Case Point Cálculo do Tamanho do Projeto
  39. 39. Casos de Uso: Use Case Point Vantagens e Desvantagens  Forma de escrita de casos de uso entre mais de um analista pode influenciar nas estimativas do projeto;  Valor-hora por UCP é um parâmetro a ser refinado de acordo com a tecnologia em uso, equipe, requisitos, etc;  A vantagem de UCP é que, em tese, requisitos representados por casos de uso tendem a ser menos modificáveis ou, ao menos, mais fáceis para uma rápida reestimativa de casos de uso;  Permite chegar a um resultado de estimativa mais assertiva ainda na etapa de planejamento, minimizando problemas de estimativa que ocorrem na fase de desenvolvimento;  Em alguns casos, casos de uso podem ocultar a real complexidade de um processo de software, especialmente quando ocorre algum esforço técnico acima do normal (exemplo: integrações entre sistemas).
  40. 40. Casos de Uso: Use Case PointPerguntas? Marcelo Schumacher marcelo.schumacher@gmail.com
  41. 41. Referências Cockburn, Alistair. Escrevendo Casos de Uso Eficazes. Fowler, Martin. Scott, Kendall. UML Essencial. RUP: http://www.wthreex.com/rup. Introdução à UML: www2.ufpa.br/cdesouza/teaching/cedai/4-uml- introduction.pdf. http://pt.wikipedia.org/wiki/UML/. http://www.aspercom.com.br/. OMG: http://www.uml.org/. http://www.agilemodeling.com/artifacts/ Calculando Estimativas: o Método de Pontos de Caso de Uso: http://www.scribd.com/doc/4484908/Pontos-de-Caso-de-Uso. PRESSMAN, R. S. Software Engineering: A Practitioner’s Approach. 5th ed. New York: McGraw-Hill, 2001. SOMMERVILLE, Ian. Engenharia de Software. 6ª ed. São Paulo: Pearson Addison Wesley, 2003.
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×