Essa é uma revisão anterior do documento!

Regras de Classificação de Complexidade

CASO DE USO SIMPLES (peso 5): - a partir de 1 a 3 transações ou de 1 a 4 classes de análise.

CASO DE USO MÉDIO (peso 10): - a partir de 5 a 7 transações ou de 5 a 10 classes de análise.

CASO DE USO COMPLEXO (peso 15): - a partir de 8 transações ou mais de 10 classes de análise.

Conceitos

Como identificar os Atores?

ATORES

O que é Transação?

“É um conjunto de atividades atômicas, as quais são executadas completamente ou não”;
“É um evento que ocorre entre o ator e o sistema”;
“São passos dos fluxos de eventos de casos de uso, que deve ser executado por completo, ou a realização de algum processamento complexo”;

O que contar?

passos que contenham campos de entrada possuindo valores passíveis de escolha originados de leitura de dados (listas de opções, combos e grids);
passos que apresentem retorno de consultas com filtros preenchidos por buscas em bancos de dados
passos que proporcionem validações complexas de negócio;
passos que contenham uma geração de relatório são considerados como uma transação, e cada filtro originado da leitura de dados das consultas será considerado uma outra transação;
passos que apresentem funcionalidades de consultas auxiliares como casos de uso a parte (pop-up);
passos onde existirem validações simples de campo de entrada de dados são considerados como uma única transação se a quantidade de validações for menor ou igual a 10. Se a quantidade de validações for maior que 10, conta-se uma transação a cada grupo de 5 validações;

O que NÃO contar?

passos que descrevam o início e o fim do caso de uso, por exemplo, “O caso de uso se inicia…” ou “o caso de uso se encerra…” ;
passos que detalhem a interação entre o sistema e o ator, por exemplo, “O usuário pressiona confirmar” ou “o sistema solicita ao usuário informar a operação (incluir, alterar, excluir)”;
passos que solicitem escolhas com valores fixos (sem leitura de dados);
passos que façam leituras auxiliares de dados que já tenham sido realizadas em outros fluxos do mesmo caso de uso;
fluxos alternativos que contenham mensagens de erro.

Distribuição do Esforço por Fases do Projeto

- O método de estimativa de pontos por casos de uso, que passa pela contagem dos atores e casos de uso com a suas complexidades, cálculo dos PCUs não ajustados, determinação do fator de complexidade técnica e ambiental e o cálculo dos PCUs ajustados. Isso tudo resulta no Ponto por Caso de Uso que para ser convertido em horas, necessita que se trabalhe com uma taxa de produtividade convencionada para que se estabeleça o produto destas duas variáveis. Logo, em termos gerais, a estimativa em horas será o Ponto por Caso de Uso multiplicado pela taxa de produtividade.

Diante das especificidades dos projetos de software, percebeu-se a necessidade de estabelecer uma distribuição desse esforço resultante entre as fases do projeto, logo considera-se as seguintes fases:

LEVANTAMENTO: Compreende a fase de definição da visão do produto. Nesse momento as aspectos mais relevantes do negócio são levantados para que todos os envolvimentos, especialmente os stakeholders, compreendam o que irão receber e possam confrontar o resultado com sua expectativa, especialmente em decorrência da frequente necessidade em se ajustar o objetivo diante dos impactos das mudanças em outras áreas relevantes do processo. Nessa fase os requisitos também são levantados e discutidos. Diante da avaliação do histórico das entregas e do impacto dessa fase em nossos projetos, convencionamos que ela corresponde a 15% da estimativa total do projeto.
PROJETO OU ESPECIFICAÇÃO: Nesta fase, o time de projeto já recebeu a proposta com a visão aprovada e precisa trabalhar as entregas em nível de caso de uso. Nesta fase o especialista documenta as alterações no nível necessário para que o especialista em desenvolvimento possa promover os ajustes e implementar as novas funcionalidades. Convencionamos que esta fase corresponde a 20% da estimativa total do projeto.
DESENVOLVIMENTO: Como o nome indica, nesta fase o time de projeto atua na escrita do código das funcionalidads levantadas e especificadas nas fases anteriores. Questões relevantes no tocante a arquitetura do sistema também são tratadas nessa fase. Convencionamos que esta fase corresponde a 30% da estimativa total do projeto.
TESTE: No teste, temos o esforço estimado para que seja garantida a qualidade esperada conforme acordo estabelico em tempo de requisitos. Logo, nessa fase não somente os testes funcionais são realizados, mas os testes em nível de análise e desenvolvimento também são realizados e, especialmente, o esforço necessário para realizar os cenários levantados conforme construção das massas de teste. Convencionamos que esta fase corresponde a 30% da estimativa total do projeto.
IMPLANTAÇÃO: A estimativa na fase de IMPLANTAÇÃO absorve o tempo gasto em atividades que viabilizam a transição do produto de uma fase de desenvolvimento ou homologação para sua operação de fato. Com isso, as tarefas necessárias para garantir uma transição estável não está limitada, somente, ao processo de acompanhamento e/ou treinamento do cliente final, esta fase inclui, não se limitando somente a estas, as seguintes abaixo:
- Treinamento;
- Documentação;
- Geração da Versão;
- Criação do Realese Notes;
- Disponibilização da Versão;
- Acompanhamento pós-implantação;
- Geração dos Scripts de Banco de Dados;
- Orientações remotas, pós-implantação, para esclerecimentos do processo de negócio;
- Parametrizações de Funções para a realidade do cliente;
- Acessos assistidos virtuais para apoiar o cliente no processo de treinamento e uso do produto, dentre muitas outras questões.

Convencionamos que esta fase corresponde a 5% da estimativa total do projeto. Perceba que ao somar a ponderação de cada fase do projeto teremos o total de 100%.

Referências

KARNER, Gustav. Resource estimation for objectory projects. Objective Systems SF AB, v. 17, 1993.

UFPR Material de Referência