Você está na página 1de 3

Caso de Uso: ajuda ou atrapalha?

Por: Roberto Alencar

Depende do tipo de software que você irá desenvolver. Antes de discutirmos se um


documento de caso de uso é realmente necessário no processo de desenvolvimento
de alguns tipos de sistema, vamos entender numa breve descrição, o que é e pra que
serve o caso de uso (ou use case).

O que é e pra que serve?


Pesquisando por definições na internet encontrei essa explicação um pouco
complicada da Wikipédia: “Na Engenharia de Software, um caso de uso (ou use
case) é um tipo de classificador representando uma unidade funcional coerente
provida pelo sistema, subsistema, ou classe manifestada por seqüências de
mensagens intercambiáveis entre os sistemas e um ou mais atores.”; traduzindo, caso
de uso é um canal de comunicação entre os usuários e os desenvolvedores onde se
tem uma “tentativa” de criar uma especificação funcional do sistema. Foi criado na
década de 80 por Ivar Jacobson, e é uma das técnicas mais populares para
descrever os requisitos de um dado sistema. (Vide Wikipédia/Caso_de_uso).

Depois de mais de vinte anos de criação e com a crescente demanda de projetos


usando metodologias ágeis, começam a surgir vários questionamentos a respeito da
sua importância. Será que os casos de uso são realmente importantes para projetos
de pequeno e médio porte? Será que tanta “burocracia” e processos extremamente
complexos garantem o sucesso do projeto?

O ultrapassado modelo cascata e o sapo de papel


Após entendermos o conceito de caso de uso, vamos questioná-lo levando em
consideração o contexto no qual ele é inserido. Baseado em várias discussões que
observei sobre a eficácia dos casos de uso, tive a impressão de que pelo menos da
maneira como nos conhecemos hoje, eles não funcionam como deveriam funcionar.
Como já dito no começo desse artigo, casos de uso servem para especificar os
requisitos do sistema, e o que acontece na grande maioria das empresas é que se
perde um enorme tempo na fase de requisitos do projeto e quando conseguimos
chegar à fase de codificação do produto, grande parte da documentação é dúbia e
confusa, sempre precisamos corrigi-la e acabamos tendo um enorme esforço para
manter esse amontoado de artefatos, além disso, precisamos entender que devemos
sempre entregar algum valor ao cliente desde o começo do projeto (Vide Blog do
Borba).

Numa das experiências citadas por um amigo de trabalho, na qual ele participou de
um projeto que tinha aproximadamente 700PF (pontos de função), e durante o
projeto foi convidado para ministrar um treinamento de Scrum para o cliente (que era
um departamento de TI de uma grande instituição pública), ele descobriu que a fase
de levantamento de requisitos e escrita dos casos de uso desse projeto durou nada
menos que dois anos. Ao final de dois anos produzindo papel e nenhum valor concreto
para o cliente, finalmente começou a fase de implementação do produto que já estava
atrasado, necessitando um enorme esforço da equipe para implementar o produto o

http://www.javafree.org/ A voz Java no Brasil – Pág. 1


mais rápido possível. Como acontece na maioria dos projetos de qualquer empresa
que usa a metodologia cascata tradicional, é que a documentação sempre estava com
vários “furos” de especificação, e toda semana tinha uma baseline nova, ou seja, toda
semana encontravam-se falhas na documentação produzida durante dois anos, e por
isso tinha-se que gastar esforço para corrigi-la e entendê-la. O mais impressionante,
no final do curso, foi a resposta do grupo a seguinte pergunta: vocês acham que se
tivéssemos começado a implementar o projeto desde o início, aos poucos, e usando
Scrum, como estaria o projeto ao final desses dois anos? Resposta: acabado.
Problemas na documentação como esse citado acima, ainda são comuns na
empresas de hoje. É importante salientar que o problema desse e de muitos outros
projetos não está nas pessoas que escreveram os casos de uso, ou no tempo que
elas tiveram, mesmo que colocasse o melhor profissional do mundo em especificação
de caso de uso com o tempo de sobra, ainda sim se teria problemas. O problema está
no processo, não nas pessoas.

Outra experiência relatada foi uma dinâmica realizada


num treinamento de Scrum onde os participantes
deveriam fazer um sapo de papel (Origami). As
regras eram o seguinte:

 Os participantes devem montar duplas e dividir


as duplas em três grupos, grupo 1, 2 e 3;
 Todas as duplas iriam receber uma folha de
papel contendo a especificação (tipo um caso
de uso) de como fazer o sapo origami;
 O grupo 1 deveria seguir a seguinte regra: um pessoa da dupla dobra o papel e
a outra dita com devem ser as dobras seguindo a especificação fornecida.
Restrição: as duas pessoas devem ficar de costas uma para a outra e não
podem se virar, quem esta ditando não pode olhar o sapo em construção e
quem esta fazendo o sapo não pode olhar a especificação, apenas escutar.
 O grupo 2 deveria seguir a mesma regra do grupo um só que com restrições
diferentes. As pessoas podem estar de frente um para a outra, quem está
montando o sapo pode olhar a especificação mais não pode tocá-la, quem está
ditando a especificação não pode tocar no sapo que a outra pessoa esta
construindo.
 O grupo 3 também deveria montar o sapo só que as duas pessoas poderiam
dobrar o papel e ler a especificação. Esse grupo, não tinha regras e poderiam
fazer do jeito que quisessem contanto que no fim chegassem ao mesmo
resultado, montar o sapo de papel origami.

Os resultados foram reveladores. O grupo 1 não conseguiu fazer o sapo, saiu de tudo,
menos um sapo. O grupo 2 teve muita dificuldade, chegaram perto mais não
conseguiram fazer um sapo igual ao especificado no documento. O grupo 3 foi o que
obteve maior êxito e a maioria da duplas conseguiram fazer o sapo. Qual a mensagem
que essa dinâmica da construção do sapo nos passa? A mensagem que ela nos
passa é que devemos trabalhar mais juntos. No grupo 3, as duas pessoas colocavam
a mão na massa, um ajudava o outro, a responsabilidade era a mesma para os dois,
as habilidades de um completava as habilidades do outro, os dois estavam no mesmo
barco. Devemos trabalhar como o grupo 3. O que acontece hoje em várias empresas,
é elas ainda estão trabalhando como o grupo 1, cada um tem responsabilidades
diferentes, chagamos a escutar pessoas do grupo 1 falando: “eu fiz a minha parte, ele
que não soube dobrar o papel, e a outra pessoa rebateu dizendo: você que não leu o
papel corretamente por isso que eu não consegui fazer”, ou seja, parece que eles
tinham objetivos diferentes e um empurrava a responsabilidade do fracasso para o

http://www.javafree.org/ A voz Java no Brasil – Pág. 2


outro. O que aconteceu nesse experimento foi o mesmo que aconteceu no primeiro, as
pessoas do grupo 3 não eram nem melhores nem piores que a do grupo 1, o fator
decisivo para o fracasso do grupo foi o processo que eles estavam inseridos.
Podemos fazer uma analogia desse segundo experimento com o nosso dia a dia, a
especificação de construção do sapo, são as nossas especificações de caso de uso
de hoje, em que os analistas ficam um longo tempo escrevendo e depois nos enviam
como se o problema não fossem mais deles. Podemos trabalhar como o grupo 1 sim,
estando o mais próximo possível do cliente e desburocratizando um processo que
deveria ser simples e nós mesmo o complicamos.

Qual a solução?
Com certeza não é o ultrapassado modelo cascata com os complicados casos de uso
que usamos hoje. Casos de uso podem ser úteis sim, para sistemas extremamente
complexos ou sistemas de segurança, mas na maioria dos sistemas que
desenvolvemos, nos quais produzimos funcionalidades simples como inclusão,
alteração, listagem, relatórios e etc. não são necessários. E qual seria a alternativa? A
proposta desse artigo é levantar esse questionamento para tentarmos buscar formas
mais eficientes de construir nossos projetos. Uma possível solução poderia ser
estórias de usurários, prática sugerida pelas metodologias ágeis. Recomendo
fortemente o estudo dessa técnica através do livro User Stories Applied de Mike
Conhn para podermos visualizar um futuro com mais sapos e menos papeis
amassados.

Sobre o autor
Roberto Luiz Sena de Alencar, graduado em desenvolvimento de software pela
Unibratec/PE e mestrando em engenharia de software pelo Cesar.edu. Atualmente
trabalhando como desenvolvedor de sistemas Java.

http://www.javafree.org/ A voz Java no Brasil – Pág. 3