Introdução
A chave para o êxito do desenvolvimento iterativo é garantir que a equipe de desenvolvimento maximize o valor aos
analistas de negócios e minimize os riscos no início do ciclo de vida, minimizando ao mesmo tempo o retrabalho
posterior. Isto impõe algumas restrições sobre a forma como desenvolvemos o modelo de caso de uso.
Em um dos extremos existe a abordagem clássica em cascata, que tenta detalhar todos os requisitos antes do design e da
implementação. Esta abordagem atrasa a entrega de valor aos analistas de negócios e a redução dos riscos
desnecessariamente.
No outro extremo está o início do desenvolvimento antes do entendimento do que o sistema deve fazer. Esta abordagem
resulta em significativo, e dispendioso, retrabalho ao final do ciclo de vida.
A melhor abordagem consiste em detalhar apenas os requisitos que serão o foco do desenvolvimento na próxima iteração
(ou na seguinte). A seleção destes requisitos é motivada pelo valor e risco, e, portanto, exige no mínimo um
entendimento abstrato da visão contextual.
A discussão a seguir irá descrever o método utilizado para evoluir o modelo de caso de uso, para alcançar essas metas.
A abordagem recomendada para a evolução do modelo de caso de uso baseia-se no método "abranger antes de aprofundar".
Nesta abordagem, alguém identifica os atores e casos de uso e descreve-os rapidamente. Baseado neste conhecimento
pode-se então realizar uma primeira avaliação dos riscos e prioridades e, então, concentrar os esforços de detalhamento
dos casos de uso nas áreas certas.
Concepção
O objetivo da Concepção é entender o escopo do sistema. Temos que compreender o principal objetivo do sistema, o que
está dentro do escopo do sistema, e o que é externo ao sistema. Devemos nos esforçar para relacionar todos os
principais atores e casos de uso, entretanto, não devemos nos dar ao luxo de detalhar todos os requisitos neste
momento. Esforce-se no sentido de identificar, pelo nome, aproximadamente 80% dos principais atores e casos de uso e
fornecer uma descrição resumida (de uma a três linhas) para cada um.
Identifique os Stakeholders
Comece relacionando todos os Stakeholders externos ao sistema. Estas pessoas serão a fonte dos requisitos.
Identifique os Atores
Nomeie e descreva os principais atores. Veja Guideline: Encontrar e Descrever Atores e Casos de Uso.
Identifique os Casos de Uso
Para cada ator, pergunte: "o que este ator quer conseguir com o sistema"? Isto revelará os principais casos de uso
do sistema. Nomeie e descreva cada um dos casos de uso à medida que você for descobrindo-os.
Atualize o Modelo de Caso de Uso
Atualize o modelo de caso de uso para registrar os nomes e as descrições resumidas dos atores e casos de uso.
Capture os relacionamentos entre os atores e os casos de uso.
Descreva os Fluxos Básicos no Caso de Uso
Para os casos de uso considerados de alta prioridade pelos Stakeholders, ou de alto risco pela equipe de
desenvolvimento, capture uma descrição passo-a-passo do Fluxo Básico. Não se preocupe com a estruturação do fluxo
neste momento. Concentre-se em captar o diálogo entre o ator e o sistema e os requisitos fundamentais para o
sistema.
Identifique os Fluxos Alternativos no Caso de Uso
À medida que estiver trabalhando nos Fluxos Básicos, pergunte: "O que pode dar errado?"; "Que opções estão
disponíveis neste momento?"; Etc. Estes tipos de pergunta irão revelar os fluxos alternativos. Capture-os,
dando-lhes um nome e uma descrição resumida. Não detalhe estes fluxos alternativos neste momento.
Refatore o Modelo de Caso de Uso
Baseado nos Fluxos Básicos que você identificou, determine se existem comportamentos comuns que poderiam ser
fatorados em casos de uso <<include>>. Refatore o Modelo de Caso de Uso de acordo com o necessário.
Priorize os Casos de Uso
Dada a descrição abstrata que agora você tem dos requisitos, trabalhe com os analistas de negócios para priorizar
os casos de uso. Esta será a principal entrada para o planejamento da iteração.
Elaboração
A finalidade da elaboração é demonstrar a viabilidade da solução antes de comprometer recursos adicionais. Para ser
bem sucedida, alguém deve demonstrar que o valor aos analistas de negócios pode ser entregue e que o risco de
continuar é aceitável. Devemos nos esforçar em detalhar e implementar aproximadamente 20% dos cenários. Estes
cenários devem ser selecionados para alcançar uma boa cobertura da arquitetura (por exemplo, uma fatia vertical
através da arquitetura, tocando tantos componentes e interfaces quanto possível, é preferível ao invés de elaborar
somente a Interface de Usuário).
Detalhe o Fluxo Básico
Para os Casos de Uso selecionados para a próxima iteração, invista o tempo detalhando o fluxo básico agora. Veja Guideline: Encontrar e Descrever Atores e Casos de Uso.
Detalhe o Fluxo Alternativo
Para os fluxos alternativos selecionados para a próxima iteração, invista o tempo detalhando os fluxos agora.
Atualize o Modelo de Caso de Uso
Atualize o Modelo de Caso de Uso para capturar qualquer aperfeiçoamento que tenha resultado de seu trabalho.
Dependendo da complexidade do sistema, você pode agrupar, de forma lógica, os casos de uso em pacotes para
simplificar a comunicação, o planejamento da iteração e o desenvolvimento em paralelo.
Construção
A finalidade da construção é entregar gradativamente a funcionalidade (e o valor). Trabalhando com base no plano de
iteração, continue detalhando os requisitos restantes. Almeje a conclusão de aproximadamente 90 a 95% dos casos de
uso, até o final da construção.
Detalhe os Fluxos Básicos
Para os Casos de Uso selecionados para a próxima iteração, invista o tempo detalhando o fluxo básico agora. Veja Guideline: Encontrar e Descrever Atores e Casos de Uso.
Detalhe os Fluxos Alternativos
Para os fluxos alternativos selecionados para a próxima iteração, invista o tempo detalhando os fluxos agora.
Atualize o Modelo de Caso de Uso
Atualize o Modelo de Caso de Uso para capturar qualquer aperfeiçoamento que tenha resultado de seu trabalho.
Transição
A finalidade da transição é tornar o sistema operacional em seu ambiente alvo. Alguns requisitos ainda não estarão
cobertos até este momento, mas se fizemos as coisas certas, eles não devem afetar o design. Os casos de uso restantes,
aproximadamente de 5% a 10%, devem ser detalhados e implementados nesta fase.
Uma armadilha comum para os novatos em modelagem de caso de uso é realizar uma decomposição funcional do sistema. Isto
resulta em muitos "casos de uso" pequenos, que isoladamente não entregam o "resultado de valor observável" para o ator.
Para evitar isso, preste atenção nos seguintes sintomas:
-
Pequenos casos de uso, significando que a descrição do fluxo de eventos tem apenas uma ou poucas
sentenças.
-
Muitos casos de uso, significando que a quantidade de casos de uso conta-se as centenas, e não as
dezenas.
-
Nomes de casos de uso tais como "executar esta operação nestes determinados dados" ou "executar esta função com
esses dados". Por exemplo, "Entrar com a Senha num Caixa Eletrônico (ATM)" não deve ser modelado como um caso de
uso separado para o Caixa Eletrônico (ATM), porque ninguém usará o sistema para fazer somente isso. Um caso de uso
é um fluxo de eventos completo que resulta em algo de valor para um ator.
Para evitar a decomposição funcional, certifique-se que o modelo de caso de uso responde a estas perguntas:
-
Qual é o contexto do sistema?
-
Porque você está construindo este sistema?
-
O que o usuário deseja que o sistema faça?
-
Como os usuários se beneficiarão do sistema?
Existem três razões principais para estruturar o modelo de caso de uso:
-
Para tornar os casos de uso mais fáceis de entender.
-
Para compartilhar o comportamento comum descrito em vários casos de uso.
-
Para tornar o modelo de caso de uso mais fácil de manter.
Entretanto, a estruturação não é a primeira coisa a ser feita. Não existe vantagem em estruturar os casos de uso até
que você conheça um pouco mais de seus comportamentos, além de uma descrição de uma-sentença. Você deve ter feito, pelo
menos, uma descrição passo-a-passo do fluxo de eventos do caso de uso para ter certeza que suas decisões são baseadas
em uma compreensão exata do comportamento.
Existem vários conceitos avançados de modelagem disponíveis na literatura para a estruturação do modelo de caso de uso,
entretanto, seguindo o princípio de "simplicidade" o mais útil deles é o relacionamento <<include>>,
discutido neste processo. Este relacionamento permite fatorar o comportamento comum em um caso de uso separado que é
"incluído" em outros casos de uso. Veja Concept: Modelo de Caso de Uso para mais detalhes.
Outro aspecto da estruturação do modelo de caso de uso para facilitar a compreensão, é o agrupamento dos casos de uso
em pacotes. O modelo de caso de uso pode ser organizado como uma hierarquia de pacotes de casos de uso. Para obter mais
informações sobre os pacotes de casos de uso, veja Concept: Modelo de Caso de Uso.
A execução de cada caso de uso inclui a comunicação com um ou mais atores. Uma instância de um caso de uso é sempre
iniciada por um ator pedindo ao sistema para fazer algo. Isto implica que cada caso de uso deve ter associações de
comunicação com os atores. A razão para esta regra é assegurar que o sistema forneça somente a funcionalidade que os
usuários necessitam e nada mais. A existência de casos de uso que ninguém tenha solicitado é um indício de que algo
está errado no modelo de caso de uso ou nos requisitos.
Entretanto, existem algumas exceções a esta regra:
-
Um caso de uso <<include>> não pode interagir com um ator, se o caso de uso base o fizer.
-
Um caso de uso pode ser iniciado de acordo com um agendamento (por exemplo, uma vez por semana ou uma vez por dia),
o que significa que o relógio do sistema é quem inicia. O relógio do sistema é interno ao sistema; portanto, o caso
de uso não é iniciado por um ator, mas por um evento interno do sistema. Se nenhuma interação de outro ator ocorrer
no caso de uso, ele não terá qualquer associação com atores. No entanto, por uma questão de clareza, você pode usar
o "tempo" como um ator para mostrar como o caso de uso é iniciado nos seus diagramas de caso de uso.
ATENÇÃO: se você tiver vários atores "tempo" no seu modelo, questione-os. Talvez você não tenha
notado a existência de um ator verdadeiro, tal como um administrador responsável pelo agendamento de informes, etc.
|
