Base de Conhecimento de Gestão Comercial de Saneamento

A maior base de documentação de GSAN do mercado mantida pela Consenso Tecnologia

Ferramentas do usuário

Ferramentas do site

Visitou: • web-services-consultar-doacao-faturada
casos_de_uso:regraapuc

Diferenças

Aqui você vê as diferenças entre duas revisões dessa página.

Link para esta página de comparações

Ambos lados da revisão anteriorRevisão anterior
Próxima revisão		Revisão anterior
casos_de_uso:regraapuc [21/03/2016 12:53] – moises.simoescasos_de_uso:regraapuc [06/08/2020 20:05] (atual) – [Regras de Classificação de Complexidade] bruno.barros
Linha 2: Linha 2:
  
 <WRAP left round info 80%> <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 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 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.+**CASO DE USO COMPLEXO (peso 15):** a partir de 8 transações ou mais de 10 classes  de análise.
  
 </WRAP> </WRAP>
Linha 14: Linha 14:
 <WRAP left round info 80%> <WRAP left round info 80%>
 **Como identificar os Atores?** **Como identificar os Atores?**
-  * [[:casos_de_uso:atores|ATORES]]+  * **[[:casos_de_uso:atores|ATORES]]**.
  
 **O que é Transação?** **O que é Transação?**
  
-   * “É um conjunto de atividades atômicas, as quais são executadas completamente ou nã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”; +   * //É 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”;+   * //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>
  
Linha 26: Linha 26:
 <WRAP left round info 80%> <WRAP left round info 80%>
 **O que contar?** **O que contar?**
-  * passos que contenham campos de entrada possuindo valores passíveis de escolha originados de leitura de dados (listas de opções, combos e grids); +  - Passos que contenham campos de entrada possuindo valores passíveis de escolha originados de leitura de dados (listas de opções, combos e grids); 
-  * passos que apresentem retorno de consultas com filtros preenchidos por buscas em bancos de dados +  - Passos que apresentem retorno de consultas com filtros preenchidos por buscas em bancos de dados; 
-  * passos que proporcionem validações complexas de negócio; +  - Passos que proporcionem validações complexas de negócio; 
-  * passos que contenham uma geração de relatório são considerados como uma transação, e cada filtro originado da leitura de dados das consultas será considerado uma outra transação; +  - Passos que contenham uma geração de relatório são considerados como uma transação, e cada filtro originado da leitura de dados das consultas é́ considerado uma outra transação; 
-  * passos que apresentem funcionalidades de consultas auxiliares como casos de uso a parte (pop-up); +  - Passos que apresentem funcionalidades de consultas auxiliares como casos de uso à parte (pop-up); 
-  * passos onde existirem validações simples de campo de entrada de dados são considerados como uma única transação se a quantidade de validações for menor ou igual a 10. Se a quantidade de validações for maior que 10, conta-se uma transação a cada grupo de 5 validações;+  - Passos nos quais existirem validações simples de campo de entrada de dados são considerados como uma única transação se a quantidade de validações for //menor// ou //igual// a 10. Se a quantidade de validações for //maior// que 10, conta-se uma transação a cada grupo de 5 validações;
  
 </WRAP> </WRAP>
Linha 38: Linha 38:
 <WRAP left round important 80%> <WRAP left round important 80%>
 **O que NÃO contar?** **O que NÃO contar?**
-  * passos que descrevam o iní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 descrevam o iní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 interação entre o sistema e o ator, por exemplo, “O usuário pressiona confirmar” ou “o sistema solicita ao usuário informar a operação (incluir, alterar, excluir)”; +  - Passos que detalhem a interação entre o sistema e o ator, por exemplo, //O usuário pressiona confirmar// ou //O sistema solicita ao usuário informar a operação (incluir, alterar, excluir)//; 
-  * passos que solicitem escolhas com valores fixos (sem leitura de dados); +  - Passos que solicitem escolhas com valores fixos (sem leitura de dados); 
-  * passos que façam leituras auxiliares de dados que já tenham sido realizadas em outros fluxos do mesmo caso de uso; +  - Passos que façam leituras auxiliares de dados que já tenham sido realizadas em outros fluxos do mesmo caso de uso; 
-  * fluxos alternativos que contenham mensagens de erro.+  - Fluxos alternativos que contenham mensagens de erro.
  
 </WRAP> </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>
 +
 +
 \\ \\ \\ \\  \\ \\ \\ \\ 
 +
  
 \\ \\ \\ \\  \\ \\ \\ \\ 
 \\ \\ \\ \\  \\ \\ \\ \\ 
  
 +\\ \\ \\ \\ 
 \\ \\ \\ \\  \\ \\ \\ \\ 
 \\ \\ \\ \\  \\ \\ \\ \\ 
Linha 55: Linha 89:
 \\ \\ \\ \\  \\ \\ \\ \\ 
 \\ \\ \\ \\  \\ \\ \\ \\ 
-<html><br><br><br><br><br><br><br><br><br><br><br><br><br></html>+ 
 +\\ \\ \\ \\  
 +\\ \\ \\ \\  
 + 
 +\\ \\ \\ \\  
 +\\ \\ \\ \\  
 +\\ \\ \\ \\  
 + 
 +\\ \\ \\ \\  
 +\\ \\ \\ \\  
 + 
 +\\ \\ \\ \\  
 +\\ \\ \\ \\  
 + 
 +\\ \\ \\ \\  
 +\\ \\ \\ \\  
 + 
 +\\ \\ \\ \\ 
 +\\ 
 +\\ 
 +\\ 
 +\\ 
 +\\ 
 + 
 +<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** **Referências**
  
-  KARNER, Gustav. Resource estimation for objectory projects. Objective Systems SF AB, v. 17, 1993.+//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]]
casos_de_uso/regraapuc.1458564835.txt.gz · Última modificação: 31/08/2017 01:11 (edição externa)