Base de Conhecimento de Gestão Comercial de Saneamento

Essa página está em modo somente de leitura. Você pode visualizar a fonte, mas não alterá-la. Informe-se com o administrador do Wiki, caso você ache que isso está incorreto.
====== Regras de Classificação de Complexidade ======

<WRAP left round info 80%>
**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 4 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.

</WRAP>

===== Conceitos =====

<WRAP left round info 80%>
**Como identificar os Atores?**
  * **[[:casos_de_uso: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 devem ser executados por completo, ou a realização de algum processamento complexo//.
</WRAP>


<WRAP left round info 80%>
**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 é́ considerado uma outra transação;
  - Passos que apresentem funcionalidades de consultas auxiliares como casos de uso à parte (pop-up);
  - Passos nos quais 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;

</WRAP>
\\ \\ \\ \\

<WRAP left round important 80%>
**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.

</WRAP>

<WRAP left round info 80%>
**Distribuição do Esforço por Fases do Projeto**

<columns>
O método de estimativa de pontos por casos de uso abrange: a) a contagem dos atores e casos de uso com suas complexidades; b) o cálculo dos PCUs não ajustados; c) a determinação do fator de complexidade técnica e ambiental e; d) o cálculo dos PCUs ajustados. Tudo isso resulta no **Ponto por Caso de Uso**. Para ser convertido em horas, o **Ponto por Caso de Uso** necessita que se trabalhe com uma taxa de produtividade convencionada, para que se estabeleça o produto dessas 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, veio a necessidade de se estabelecer uma distribuição desse esforço resultante entre as fases do projeto, considerando as seguintes fases:

  - **LEVANTAMENTO:** Compreende a fase de definição da visão do produto. Nesse momento, os aspectos mais relevantes do negócio são levantados para que todos os envolvidos, especialmente os //stakeholders// diretos, compreendam o que irão receber, podendo confrontar o resultado com sua expectativa, especialmente em decorrência da frequente necessidade de 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 corresponda 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 corresponda 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 funcionalidades levantadas e especificadas nas fases anteriores. Questões relevantes, relacionadas à arquitetura do sistema, também são tratadas nessa fase. Convencionamos que esta fase corresponda a **30% da estimativa total do projeto**.
  - **TESTE:** No teste, temos o esforço estimado para que seja garantida a qualidade esperada conforme acordo estabelecido em tempo de requisitos. Logo, não somente os testes funcionais são realizados nessa fase, mas os testes em nível de análise e desenvolvimento também são realizados; especialmente, o esforço necessário para realizar os cenários levantados conforme construção das massas de teste. Convencionamos que esta fase corresponda 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ão limitadas ao processo de acompanhamento e/ou treinamento do cliente final. Esta fase inclui as seguintes abaixo (mas não se limita somente a estas):
    - Treinamento;
    - Documentação;
    - Geração da Versão;
    - Criação do //Release 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 esclarecimentos do processo de negócio;
    - Parametrizações de Funções para a realidade do cliente;
    - Acessos virtuais assistidos, para apoiar o cliente no processo de treinamento e uso do produto, dentre muitas outras questões
\\

Convencionamos que esta fase corresponda a **5% da estimativa total do projeto**. Percebe-se que, ao somar a ponderação de cada fase do projeto, teremos o total de 100%.
</columns>

</WRAP>


\\ \\ \\ \\ 


\\ \\ \\ \\ 
\\ \\ \\ \\ 

\\ \\ \\ \\ 
\\ \\ \\ \\ 
\\ \\ \\ \\ 

\\ \\ \\ \\ 
\\ \\ \\ \\ 

\\ \\ \\ \\ 
\\ \\ \\ \\ 

\\ \\ \\ \\ 
\\ \\ \\ \\ 
\\ \\ \\ \\ 

\\ \\ \\ \\ 
\\ \\ \\ \\ 

\\ \\ \\ \\ 
\\ \\ \\ \\ 

\\ \\ \\ \\ 
\\ \\ \\ \\ 

\\ \\ \\ \\
\\
\\
\\
\\
\\

<html><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br></html>
**Referências**

//KARNER, Gustav. Resource estimation for objectory projects. Objective Systems SF AB, v. 17, 1993.// \\ \\
[[http://www.funpar.ufpr.br:8080/rup/process/activity/ac_ucana.htm#Find%20Classes%20from%20Use-Case%20Behavior|UFPR Material de Referência]]