[quote=fggs]Boa noite caros amigos,
Para quem já leu outros posts meus sabem o quanto já batalhei pelo meu objetivo, mas se eu continuar desse jeito vou rachar a cabeça antes de cumpri-lo.
Após pensar muito, creio que devo focar 100% na modelagem, pois independe de qual linguagem vou programar, correto?
Procurei livros sobre Casos de Uso, pelo que vi o “Escrevendo Casos de Uso Eficazes” parece ser bem recomendado, mas estou na dúvida entre livro, curso online ou curso presencial.
Qualquer dica, qualquer sugestão é muito bem-vinda! Inclusive alguns xingamentos, por eu ser tão cabeça dura e burro por não entender uma coisa que parece ser tão simples como casos de uso, mas gosto de me informar bastante para fazer uma coisa técnica e não algo “nas coxas” por assim dizer.
Obrigado desde já,
Flávio
[/quote]
Primeiro, é preciso que vc entenda que “Casos de Uso” não é um documento UML. Antes de ser um documento UML, os casos de uso são contos que os usuários lhe vão explicar que querem realizar. Depois que eles lhe contarem e vc entender, tem ainda que simplificar o processo, diminuir o numero de inputs, de telas e de cliques ( tudo isso para evitar erros de entrada). Depois disso bem entendido e seco é que vai para UML.
O trabalho de analise, levantamento, ou seja lá como quiser chamar é primeiro a tudo o resto. Começa com os stakeholders principais com perguntas do tipo “porque vc quer o sistema?” “pq o sistema atual não atender”, etc… se ha investimento de dinheiro é suposto haver retorno e vc precisa entender isso. É assim que vc entende porque o sistema existe. Depois vai para os outros stakeholders , os usuários finais , os genrentes deles, etc… Depois de tudo isso coletado, analisado, filtrado, secado vc ainda volta nos stakholders principais e mostra o que descobriu. Eles vão arranjar alguns detalhes e depois disso vc tem uma clara noção do que o sistema tem que fazer do ponto de vista do uso que será feito dele. Dai o nome “Casos de uso”. O “uso” não é porque o “usuário” vai interagir com o sistema. Pode ter qualquer tipo de ator, ou até mesmo nenhum ( casos em que o sistema é que envia os dados para fora ). Durante as entrevistas vc vai perceber outras demandas além do uso. Algumas tecnologicas, algumas de negocio e alguma até politicas. Controle de acesso. Tipo de deploy ( web VS dektop VS outra coisa). Etc… tudo isso são os requisitos. Todos os requisitos devem ser documentados. Qual foi o requisito, quando foi levantado, quem o levantou e quem o pediu ( stakeholder). Todos esses requisitos tb têm que ser analisados, sintetizados ( alguns são repetidos, incompletos ,etc… ) e colocados num documento. Existem muitos requisitos que não se referem ao uso ou que são subentendidos durante o uso ( tipo, CPF será formatado e validado, ou “o sistema tem um login”) . Nunca assuma nada. Se é falado, é requisito. Coloque no documento. Mais tarde vc irá priorizar esses requisitos junto com os stakeholders. Os casos de uso tb são requisitos mas que dizem mais respeito a navegação, mas permite entender a divisão de tarefas e politicas.
Fazer Software é transforma esses requisitos em algo que os realiza.
Não menospreze a analise e sintetize de requisitos, mas também não se perca nela. Existe umcaminho minimo, um “software minimo” que os stakewholders irão aceitar para começo. Encontre qual ele é. Coloque todos os requisitos que pertencem a ele, com máxima prioridade e o resto com menos. Ficarão para outra altura, mas não os perca de vista, pois sua arquitetura, design e implementação vão depender deles. Tenha tb em atenção o risco. Alguns requisitos são mirabolantes. Se o cliente não os prioriza à partida isso é excesso de confiança ou de eles realmente não são tão importantes assim. Deixe claro para o cliente o risco, e peça que ele se comprometa consigo.
Caos de uso não, por se, a forma correta de começar. A forma correta é entrevistas. Seguido de analise, síntese e mais entrevistas. Se possivel com RFC (Request for Comments) em cima do documento final que vc vai produzir.
Vai vir alguem aqui dizer que isto não é ágil e bla bla bla… bem pelo contrário. A agilidade está em apenas documentar o que é certeza, o que é real. E não documentar toda e qualquer balela que lhe contarem. A entrevista deve ser informal. E depende muito do nivel das pessoas que vc está conversando. Erros de requisitos são mais raros que erros de implementação mas podem custa de 3 a 30 vezes mais para corrigir. às vezes impossibilitando o progresso do projeto ou levando a que os usuários não fiquem satisfeitos e não usem o software, provocando prejuizo na empresa, que investiu no software exactamente para ter algun retorno. O sucesso do software não é ele ficar pronto, é alguém o usar por muito tempo. As fábricas de software esquecem disto, e os clientes esquecem que pagaram. Não cai nessa.
)