O UML é restrito no sentido de que ele pressupõe que o analista e o cliente sejam completamente lúcidos e racionais. Todos nós sabemos que isso nunca acontece.
O cliente não sabe o que é importante para seu negócio, principalmente porque, na maioria das vezes, o cliente do analista não é o dono do negócio. Ele pode até ser um bom funcionário, leal ao seu chefe e tudo mais, mas ele nunca pensa como o dono do negócio. Logo, os sistemas saem com algumas deficiências.
Um tipo de caso de uso muito comum é o descaso de uso. O descaso de uso é um elemento inútil do sistema, mas que, mesmo assim, é o mais popular entre os usuários. Por exemplo, numa intranet, invariavelmente, as páginas mais usadas são: a lista de aniversariantes do mês e o cardápio da cafeteria.
O descaso de uso é como o pato de borracha na banheira. Água, sabonetes e toalhas são essenciais para o banho, mas o pato de borracha é o que o torna realmente divertido (ouvi dizer, pelo menos). Então, o descaso de uso é representado dessa maneira:
O caso de uso pato de borracha (descaso de uso para os mais formais) é proximamente relacionado ao caso de desuso. Ambos são inúteis para o negócio, mas o caso de desuso ainda é pior, porque não serve para nada mesmo. Em geral, o caso de desuso toma a forma de um relatório obscuro, difícil de interpretar e que ninguém lembra quem pediu.
Por exemplo, um gerente num surto psicótico pode solicitar um relatório de vendas realizadas por funcionários com filhos de menos de 10 anos. Ou de notas emitidas para cidades do noroeste catarinense, exceto por aquelas de colonização alemã. O analista logo vê a inutilidade da criatura, mas não consegue convencer o cliente a tentar algo mais abrangente (e útil), como um relatório por região ou uma ferramenta de Data Warehouse, para que o gerente possa brincar sem perturbar sua equipe.
O caso de desuso é representado por uma teia de aranha:
Finalmente, temos o frankencaso. É o caso de uso com múltiplas personalidades. Ele provavelmente reflete a personalidade do cliente que o solicitou. Ou sua taxa de glicose. Um relatório de vendas que, quando disparado na segunda-feira antes das 10h, dispara um workflow que atualiza a tabela de comissões é um ótimo exemplo de frankencaso. Os usuários acabarão aprendendo a disparar o relatório quando quiserem atualizar suas comissões, numa reação pavloviana, mas nunca serão capazes de explicar aos novatos por que a coisa funciona dessa maneira.
O frankencaso é representado assim:
No exemplo que segue, vê-se um ator paranóico usando a página de aniversários para descobrir se não esqueceu de dar um tapinha nas costas do chefe.
Um Método Lúdico leva a ánalise de sistemas a um novo patamar de realismo, aproximando o analista ao cliente e eliminando formalismos bestas.
segunda-feira, 8 de fevereiro de 2010
Assinar:
Postar comentários (Atom)
Nenhum comentário:
Postar um comentário