Caso De Uso E Use Case Point

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.

 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).

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

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
Linguagem de Programação .NET Produto Req. Confiabilidade
Interfaces devem seguir Padrão Produto Req. Usabilidade
Necessário 400gb de Espaço Produto Req. Eficiência > Req. Espaço
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.

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.

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

 Cenário Principal como Elemento Central

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

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

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

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

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

 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

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

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


 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

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.

 Parâmetros Objetivos de Entrada: Atores

 Parâmetros Objetivos de Entrada: Casos de Uso

 Parâmetros Subjetivos de Entrada:TCF (Ajuste de
Fatores Técnicos)

 Parâmetros Subjetivos de Entrada: EF (Ajuste de
Fatores Ambientais)

 Cálculo do Tamanho do Projeto

 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).


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.

Caso De Uso E Use Case Point

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (18)

Similaire à Caso De Uso E Use Case Point

Similaire à Caso De Uso E Use Case Point (20)

Caso De Uso E Use Case Point