SlideShare uma empresa Scribd logo
1 de 41
Baixar para ler offline
Abordagem conceitual sobre Casos de Uso e
     realização de estimativas com o uso de
                               Casos de Uso
                             Marcelo Schumacher
                               Novembro de 2012
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;
Pauta
   Requisitos de Software;
   UML;
   Casos de Uso;
   Estimativas baseadas em ponto de Caso de Uso (Use
    Case Point)
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.
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).
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
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 ou
Linguagem 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 ou
Limite 30s de tempo de Resposta     Produto
                                                                         Req. Eficiência > Desempenho
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.
UML: Diagramas
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);
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.
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;
Casos de Uso: Elemento Central
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.
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;
Casos de Uso: Modelagem - Exemplo
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.
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.
Casos de Uso: Modelagem - Elementos
   Cenário Principal como Elemento Central
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.
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:
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;
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;
Casos de Uso: Modelagem - Elementos
•   Generalização: Quando há uma semelhança entre
    atores ou casos de uso;
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.
Casos de Uso: Modelagem - Exemplo
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
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.
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.
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.
Casos de Uso: Modelagem - Elementos
   Cenário Principal como Elemento Central
Casos de Uso: Modelagem



Perguntas?
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.
Casos de Uso: Use Case Point
   Parâmetros Objetivos de Entrada: Atores
Casos de Uso: Use Case Point
   Parâmetros Objetivos de Entrada: Casos de Uso
Casos de Uso: Use Case Point
   Parâmetros Subjetivos de Entrada:TCF (Ajuste de
    Fatores Técnicos)
Casos de Uso: Use Case Point
   Parâmetros Subjetivos de Entrada: EF (Ajuste de
    Fatores Ambientais)
Casos de Uso: Use Case Point
   Cálculo do Tamanho do Projeto
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).
Casos de Uso: Use Case Point



Perguntas?




                     Marcelo Schumacher
                     marcelo.schumacher@gmail.com
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.

Mais conteúdo relacionado

Mais procurados

Aula 02 - Engenharia de Requisitos
Aula 02 - Engenharia de RequisitosAula 02 - Engenharia de Requisitos
Aula 02 - Engenharia de RequisitosAlberto Simões
 
Especificação de Requisitos de Software
Especificação de Requisitos de SoftwareEspecificação de Requisitos de Software
Especificação de Requisitos de SoftwareRalph Rassweiler
 
10 Techniques for Gathering Requirements
10 Techniques for Gathering Requirements10 Techniques for Gathering Requirements
10 Techniques for Gathering Requirementsz-999
 
Uml diagrama de sequencia
Uml diagrama de sequenciaUml diagrama de sequencia
Uml diagrama de sequenciaItalo Costa
 
Sistemas Distribuídos e PHP - Darkmira Tour BR 2016
Sistemas Distribuídos e PHP - Darkmira Tour BR 2016Sistemas Distribuídos e PHP - Darkmira Tour BR 2016
Sistemas Distribuídos e PHP - Darkmira Tour BR 2016Diana Ungaro Arnos
 
Análise de Sistemas - Requisitos (Revisão e Requisitos Suplementares)
Análise de Sistemas - Requisitos (Revisão e Requisitos Suplementares)Análise de Sistemas - Requisitos (Revisão e Requisitos Suplementares)
Análise de Sistemas - Requisitos (Revisão e Requisitos Suplementares)Rosanete Grassiani dos Santos
 
Modelo de documento para levantamento de requisitos de software
Modelo de documento para levantamento de requisitos de softwareModelo de documento para levantamento de requisitos de software
Modelo de documento para levantamento de requisitos de softwareFrancilvio Roberto Alff
 
Sistema De GestãO De ClíNica VeterináRia
Sistema De GestãO De ClíNica VeterináRiaSistema De GestãO De ClíNica VeterináRia
Sistema De GestãO De ClíNica VeterináRiaguest4f7dd23
 
Aula UML - Unified Modeling Language
Aula UML - Unified Modeling LanguageAula UML - Unified Modeling Language
Aula UML - Unified Modeling LanguageCloves da Rocha
 
UML - Criando Diagramas Eficientes
UML - Criando Diagramas EficientesUML - Criando Diagramas Eficientes
UML - Criando Diagramas EficientesRodrigo Cascarrolho
 
Bab 2 Aljabar Relasional
Bab 2   Aljabar RelasionalBab 2   Aljabar Relasional
Bab 2 Aljabar RelasionalRatzman III
 
Analise de Requisitos
Analise de RequisitosAnalise de Requisitos
Analise de Requisitoselliando dias
 
Sadcw 7e chapter03-done(1)
Sadcw 7e chapter03-done(1)Sadcw 7e chapter03-done(1)
Sadcw 7e chapter03-done(1)LamineKaba6
 

Mais procurados (20)

Aula 02 - Engenharia de Requisitos
Aula 02 - Engenharia de RequisitosAula 02 - Engenharia de Requisitos
Aula 02 - Engenharia de Requisitos
 
Especificação de Requisitos de Software
Especificação de Requisitos de SoftwareEspecificação de Requisitos de Software
Especificação de Requisitos de Software
 
10 Techniques for Gathering Requirements
10 Techniques for Gathering Requirements10 Techniques for Gathering Requirements
10 Techniques for Gathering Requirements
 
Uml diagrama de sequencia
Uml diagrama de sequenciaUml diagrama de sequencia
Uml diagrama de sequencia
 
Aula 7 - Modelagem de Software
Aula 7 - Modelagem de SoftwareAula 7 - Modelagem de Software
Aula 7 - Modelagem de Software
 
Apresentação da UML
Apresentação da UMLApresentação da UML
Apresentação da UML
 
Sistemas Distribuídos e PHP - Darkmira Tour BR 2016
Sistemas Distribuídos e PHP - Darkmira Tour BR 2016Sistemas Distribuídos e PHP - Darkmira Tour BR 2016
Sistemas Distribuídos e PHP - Darkmira Tour BR 2016
 
A Linguagem UML
A Linguagem UMLA Linguagem UML
A Linguagem UML
 
Análise de Sistemas - Requisitos (Revisão e Requisitos Suplementares)
Análise de Sistemas - Requisitos (Revisão e Requisitos Suplementares)Análise de Sistemas - Requisitos (Revisão e Requisitos Suplementares)
Análise de Sistemas - Requisitos (Revisão e Requisitos Suplementares)
 
Introdução à linguagem UML
Introdução à linguagem UMLIntrodução à linguagem UML
Introdução à linguagem UML
 
Modelo de documento para levantamento de requisitos de software
Modelo de documento para levantamento de requisitos de softwareModelo de documento para levantamento de requisitos de software
Modelo de documento para levantamento de requisitos de software
 
Caso De Uso
Caso De UsoCaso De Uso
Caso De Uso
 
Sistema De GestãO De ClíNica VeterináRia
Sistema De GestãO De ClíNica VeterináRiaSistema De GestãO De ClíNica VeterináRia
Sistema De GestãO De ClíNica VeterináRia
 
Diagrama de Casos de Uso
Diagrama de Casos de UsoDiagrama de Casos de Uso
Diagrama de Casos de Uso
 
Aula UML - Unified Modeling Language
Aula UML - Unified Modeling LanguageAula UML - Unified Modeling Language
Aula UML - Unified Modeling Language
 
UML - Criando Diagramas Eficientes
UML - Criando Diagramas EficientesUML - Criando Diagramas Eficientes
UML - Criando Diagramas Eficientes
 
Apostila UML
Apostila UMLApostila UML
Apostila UML
 
Bab 2 Aljabar Relasional
Bab 2   Aljabar RelasionalBab 2   Aljabar Relasional
Bab 2 Aljabar Relasional
 
Analise de Requisitos
Analise de RequisitosAnalise de Requisitos
Analise de Requisitos
 
Sadcw 7e chapter03-done(1)
Sadcw 7e chapter03-done(1)Sadcw 7e chapter03-done(1)
Sadcw 7e chapter03-done(1)
 

Destaque

Estimativa de Software em Pontos de Caso de Uso
Estimativa de Software em Pontos de Caso de UsoEstimativa de Software em Pontos de Caso de Uso
Estimativa de Software em Pontos de Caso de UsoE-NOVAR Solutions
 
Plano de Projeto de Implantação de Software ERP Vertical de Saúde integrado c...
Plano de Projeto de Implantação de Software ERP Vertical de Saúde integrado c...Plano de Projeto de Implantação de Software ERP Vertical de Saúde integrado c...
Plano de Projeto de Implantação de Software ERP Vertical de Saúde integrado c...Marcelo Schumacher
 
Cinco motivos para você não adotar metodologias ágeis - Rafael Prikladnicki F...
Cinco motivos para você não adotar metodologias ágeis - Rafael Prikladnicki F...Cinco motivos para você não adotar metodologias ágeis - Rafael Prikladnicki F...
Cinco motivos para você não adotar metodologias ágeis - Rafael Prikladnicki F...Flávio Steffens
 
Estacionamento Inteligente
Estacionamento InteligenteEstacionamento Inteligente
Estacionamento InteligenteMarco Coghi
 
Gerenciamento de Requisitos como Alternativa de Otimização na Manutenção de S...
Gerenciamento de Requisitos como Alternativa de Otimização na Manutenção de S...Gerenciamento de Requisitos como Alternativa de Otimização na Manutenção de S...
Gerenciamento de Requisitos como Alternativa de Otimização na Manutenção de S...Marcelo Schumacher
 
Produtividade em Desenvolvimento de Software
Produtividade em Desenvolvimento de SoftwareProdutividade em Desenvolvimento de Software
Produtividade em Desenvolvimento de SoftwareRildo (@rildosan) Santos
 
Análise Orientada a Objetos com UML
Análise Orientada a Objetos com UMLAnálise Orientada a Objetos com UML
Análise Orientada a Objetos com UMLEliseu Castelo
 
Estrutura de Dados e Algoritmos com Java #01: Introducao
Estrutura de Dados e Algoritmos com Java #01: IntroducaoEstrutura de Dados e Algoritmos com Java #01: Introducao
Estrutura de Dados e Algoritmos com Java #01: IntroducaoLoiane Groner
 
Estrutura de Dados e Algoritmos com Java #02-12: Vetores e Arrays
Estrutura de Dados e Algoritmos com Java #02-12: Vetores e ArraysEstrutura de Dados e Algoritmos com Java #02-12: Vetores e Arrays
Estrutura de Dados e Algoritmos com Java #02-12: Vetores e ArraysLoiane Groner
 
Estimativa de software usando pontos de função
Estimativa de software usando pontos de funçãoEstimativa de software usando pontos de função
Estimativa de software usando pontos de funçãoClaudio Martins
 
Especificação de requisitos
Especificação de requisitosEspecificação de requisitos
Especificação de requisitosFernando Palma
 
Análise Orientada a Objetos - Casos de Uso
Análise Orientada a Objetos - Casos de UsoAnálise Orientada a Objetos - Casos de Uso
Análise Orientada a Objetos - Casos de UsoCursoSENAC
 
Aula de Analise e Projetos - Diagramas UML - prof. Rudson Kiyoshi S. Carvalho
Aula de Analise e Projetos - Diagramas UML - prof. Rudson Kiyoshi S. CarvalhoAula de Analise e Projetos - Diagramas UML - prof. Rudson Kiyoshi S. Carvalho
Aula de Analise e Projetos - Diagramas UML - prof. Rudson Kiyoshi S. CarvalhoRudson Kiyoshi Souza Carvalho
 
Como demonstrar ROI das entregas de valor com Business Case
Como demonstrar ROI das entregas de valor com Business Case Como demonstrar ROI das entregas de valor com Business Case
Como demonstrar ROI das entregas de valor com Business Case Rildo (@rildosan) Santos
 

Destaque (17)

Estimativa de Software em Pontos de Caso de Uso
Estimativa de Software em Pontos de Caso de UsoEstimativa de Software em Pontos de Caso de Uso
Estimativa de Software em Pontos de Caso de Uso
 
Plano de Projeto de Implantação de Software ERP Vertical de Saúde integrado c...
Plano de Projeto de Implantação de Software ERP Vertical de Saúde integrado c...Plano de Projeto de Implantação de Software ERP Vertical de Saúde integrado c...
Plano de Projeto de Implantação de Software ERP Vertical de Saúde integrado c...
 
Cinco motivos para você não adotar metodologias ágeis - Rafael Prikladnicki F...
Cinco motivos para você não adotar metodologias ágeis - Rafael Prikladnicki F...Cinco motivos para você não adotar metodologias ágeis - Rafael Prikladnicki F...
Cinco motivos para você não adotar metodologias ágeis - Rafael Prikladnicki F...
 
Estacionamento Inteligente
Estacionamento InteligenteEstacionamento Inteligente
Estacionamento Inteligente
 
Gerenciamento de Requisitos como Alternativa de Otimização na Manutenção de S...
Gerenciamento de Requisitos como Alternativa de Otimização na Manutenção de S...Gerenciamento de Requisitos como Alternativa de Otimização na Manutenção de S...
Gerenciamento de Requisitos como Alternativa de Otimização na Manutenção de S...
 
servlet-introducao
servlet-introducaoservlet-introducao
servlet-introducao
 
Rastreabilidade de Requisitos
Rastreabilidade de RequisitosRastreabilidade de Requisitos
Rastreabilidade de Requisitos
 
Produtividade em Desenvolvimento de Software
Produtividade em Desenvolvimento de SoftwareProdutividade em Desenvolvimento de Software
Produtividade em Desenvolvimento de Software
 
Análise Orientada a Objetos com UML
Análise Orientada a Objetos com UMLAnálise Orientada a Objetos com UML
Análise Orientada a Objetos com UML
 
Estrutura de Dados e Algoritmos com Java #01: Introducao
Estrutura de Dados e Algoritmos com Java #01: IntroducaoEstrutura de Dados e Algoritmos com Java #01: Introducao
Estrutura de Dados e Algoritmos com Java #01: Introducao
 
Estrutura de Dados e Algoritmos com Java #02-12: Vetores e Arrays
Estrutura de Dados e Algoritmos com Java #02-12: Vetores e ArraysEstrutura de Dados e Algoritmos com Java #02-12: Vetores e Arrays
Estrutura de Dados e Algoritmos com Java #02-12: Vetores e Arrays
 
Estimativa de software usando pontos de função
Estimativa de software usando pontos de funçãoEstimativa de software usando pontos de função
Estimativa de software usando pontos de função
 
Especificação de requisitos
Especificação de requisitosEspecificação de requisitos
Especificação de requisitos
 
Análise Orientada a Objetos - Casos de Uso
Análise Orientada a Objetos - Casos de UsoAnálise Orientada a Objetos - Casos de Uso
Análise Orientada a Objetos - Casos de Uso
 
Aula de Analise e Projetos - Diagramas UML - prof. Rudson Kiyoshi S. Carvalho
Aula de Analise e Projetos - Diagramas UML - prof. Rudson Kiyoshi S. CarvalhoAula de Analise e Projetos - Diagramas UML - prof. Rudson Kiyoshi S. Carvalho
Aula de Analise e Projetos - Diagramas UML - prof. Rudson Kiyoshi S. Carvalho
 
Como demonstrar ROI das entregas de valor com Business Case
Como demonstrar ROI das entregas de valor com Business Case Como demonstrar ROI das entregas de valor com Business Case
Como demonstrar ROI das entregas de valor com Business Case
 
Analise de Requisitos Software
Analise de Requisitos SoftwareAnalise de Requisitos Software
Analise de Requisitos Software
 

Semelhante a Casos de Uso para estimativas

Processo Unificado(RUP)
Processo Unificado(RUP)Processo Unificado(RUP)
Processo Unificado(RUP)elliando dias
 
requisitos de software.pptx
requisitos de software.pptxrequisitos de software.pptx
requisitos de software.pptxAlanCunha14
 
Engenharia Requisitos - Aula4 06 03 2006
Engenharia Requisitos - Aula4 06 03 2006Engenharia Requisitos - Aula4 06 03 2006
Engenharia Requisitos - Aula4 06 03 2006Luís Fernando Richter
 
Prodemge WTQS - Minicurso técnicas de verificação de requisitos
Prodemge WTQS - Minicurso técnicas de verificação de requisitosProdemge WTQS - Minicurso técnicas de verificação de requisitos
Prodemge WTQS - Minicurso técnicas de verificação de requisitosGustavo Lopes
 
Este trabalho trata
Este trabalho trataEste trabalho trata
Este trabalho trataRoni Reis
 
Palestra introdução a uml e casos de uso final_parte1
Palestra introdução a uml e casos de uso final_parte1Palestra introdução a uml e casos de uso final_parte1
Palestra introdução a uml e casos de uso final_parte1marcosdcmartinsss
 
Aula 01 - UML e Padrões de Projeto
Aula 01 - UML e Padrões de ProjetoAula 01 - UML e Padrões de Projeto
Aula 01 - UML e Padrões de ProjetoVinícius de Paula
 
Noções em teste de software e introdução a automação
Noções em teste de software e introdução a automaçãoNoções em teste de software e introdução a automação
Noções em teste de software e introdução a automaçãoSandy Maciel
 
Es capítulo 4 - engenharia de requisitos
Es   capítulo 4  - engenharia de requisitosEs   capítulo 4  - engenharia de requisitos
Es capítulo 4 - engenharia de requisitosFelipe Oliveira
 
Teste de Performance - 3º Encontro da ALATS
Teste de Performance - 3º Encontro da ALATSTeste de Performance - 3º Encontro da ALATS
Teste de Performance - 3º Encontro da ALATSFabrício Campos
 
Engenharia de Requisitos
Engenharia de RequisitosEngenharia de Requisitos
Engenharia de RequisitosTiago Barros
 
Processo Unificado de Desenvolvimento de Software
Processo Unificado de Desenvolvimento de SoftwareProcesso Unificado de Desenvolvimento de Software
Processo Unificado de Desenvolvimento de Softwareelliando dias
 

Semelhante a Casos de Uso para estimativas (20)

Processo Unificado(RUP)
Processo Unificado(RUP)Processo Unificado(RUP)
Processo Unificado(RUP)
 
requisitos de software.pptx
requisitos de software.pptxrequisitos de software.pptx
requisitos de software.pptx
 
Engenharia Requisitos - Aula4 06 03 2006
Engenharia Requisitos - Aula4 06 03 2006Engenharia Requisitos - Aula4 06 03 2006
Engenharia Requisitos - Aula4 06 03 2006
 
Prodemge WTQS - Minicurso técnicas de verificação de requisitos
Prodemge WTQS - Minicurso técnicas de verificação de requisitosProdemge WTQS - Minicurso técnicas de verificação de requisitos
Prodemge WTQS - Minicurso técnicas de verificação de requisitos
 
Este trabalho trata
Este trabalho trataEste trabalho trata
Este trabalho trata
 
Palestra introdução a uml e casos de uso final_parte1
Palestra introdução a uml e casos de uso final_parte1Palestra introdução a uml e casos de uso final_parte1
Palestra introdução a uml e casos de uso final_parte1
 
Introdução à UML com Casos de Uso
Introdução à UML com Casos de UsoIntrodução à UML com Casos de Uso
Introdução à UML com Casos de Uso
 
UML1.pdf
UML1.pdfUML1.pdf
UML1.pdf
 
Aula 01 - UML e Padrões de Projeto
Aula 01 - UML e Padrões de ProjetoAula 01 - UML e Padrões de Projeto
Aula 01 - UML e Padrões de Projeto
 
Aula 04
Aula 04Aula 04
Aula 04
 
Engenharia Software
Engenharia SoftwareEngenharia Software
Engenharia Software
 
Definição e classificação dos requisitos
Definição e classificação dos requisitosDefinição e classificação dos requisitos
Definição e classificação dos requisitos
 
Noções em teste de software e introdução a automação
Noções em teste de software e introdução a automaçãoNoções em teste de software e introdução a automação
Noções em teste de software e introdução a automação
 
Modelagem 16102006
Modelagem 16102006Modelagem 16102006
Modelagem 16102006
 
Aula 6 -_casos_de_uso
Aula 6 -_casos_de_usoAula 6 -_casos_de_uso
Aula 6 -_casos_de_uso
 
Es capítulo 4 - engenharia de requisitos
Es   capítulo 4  - engenharia de requisitosEs   capítulo 4  - engenharia de requisitos
Es capítulo 4 - engenharia de requisitos
 
Teste de Performance - 3º Encontro da ALATS
Teste de Performance - 3º Encontro da ALATSTeste de Performance - 3º Encontro da ALATS
Teste de Performance - 3º Encontro da ALATS
 
Engenharia de Requisitos
Engenharia de RequisitosEngenharia de Requisitos
Engenharia de Requisitos
 
Objectory
ObjectoryObjectory
Objectory
 
Processo Unificado de Desenvolvimento de Software
Processo Unificado de Desenvolvimento de SoftwareProcesso Unificado de Desenvolvimento de Software
Processo Unificado de Desenvolvimento de Software
 

Casos de Uso para estimativas

  • 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. 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. Pauta  Requisitos de Software;  UML;  Casos de Uso;  Estimativas baseadas em ponto de Caso de Uso (Use Case Point)
  • 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. 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. 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. 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 ou Linguagem 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 ou Limite 30s de tempo de Resposta Produto Req. Eficiência > Desempenho
  • 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.
  • 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. 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. 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. Casos de Uso: Elemento Central
  • 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. 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. Casos de Uso: Modelagem - Exemplo
  • 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. 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. Casos de Uso: Modelagem - Elementos  Cenário Principal como Elemento Central
  • 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. 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. 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. 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. Casos de Uso: Modelagem - Elementos • Generalização: Quando há uma semelhança entre atores ou casos de uso;
  • 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. Casos de Uso: Modelagem - Exemplo
  • 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. 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. 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. 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. Casos de Uso: Modelagem - Elementos  Cenário Principal como Elemento Central
  • 32. Casos de Uso: Modelagem Perguntas?
  • 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. Casos de Uso: Use Case Point  Parâmetros Objetivos de Entrada: Atores
  • 35. Casos de Uso: Use Case Point  Parâmetros Objetivos de Entrada: Casos de Uso
  • 36. Casos de Uso: Use Case Point  Parâmetros Subjetivos de Entrada:TCF (Ajuste de Fatores Técnicos)
  • 37. Casos de Uso: Use Case Point  Parâmetros Subjetivos de Entrada: EF (Ajuste de Fatores Ambientais)
  • 38. Casos de Uso: Use Case Point  Cálculo do Tamanho do Projeto
  • 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. Casos de Uso: Use Case Point Perguntas? Marcelo Schumacher marcelo.schumacher@gmail.com
  • 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.