apoio automatizado ao cÁlculo de estimativa de projetos de software utilizando o mÉtodo de pontos...
TRANSCRIPT
FUNDAÇÃO DE ASSISTÊNCIA E EDUCAÇÃO - FAESA FACULDADES INTEGRADAS ESPÍRITO-SANTENSES
BACHARELADO EM CIÊNCIA DA COMPUTAÇÃO
GEORGE MAESTRI FURTADO DA ROSA JOSE CARLOS PIMENTEL
LUIZ FERNANDO ROSÁRIO
APOIO AUTOMATIZADO AO CÁLCULO DE ESTIMATIVA DE PROJETOS DE SOFTWARE UTILIZANDO O MÉTODO
DE PONTOS POR CASO DE USO
VITÓRIA
2008
GEORGE MAESTRI FURTADO DA ROSA JOSE CARLOS PIMENTEL
LUIZ FERNANDO ROSÁRIO
APOIO AUTOMATIZADO AO CÁLCULO DE ESTIMATIVA DE PROJETOS DE SOFTWARE UTILIZANDO O MÉTODO
DE PONTOS POR CASO DE USO
Trabalho de Conclusão de Curso de Graduação em Ciência da Computação apresentado às Faculdades Integradas Espírito-santenses, como requisito parcial para obtenção do título de Bacharel em Ciência da Computação, sob orientação da profa. Denise Franzotti Togneri.
VITÓRIA 2008
GEORGE MAESTRI FURTADO DA ROSA JOSE CARLOS PIMENTEL
LUIZ FERNANDO ROSÁRIO
APOIO AUTOMATIZADO AO CÁLCULO DE ESTIMATIVA DE PROJETOS DE SOFTWARE UTILIZANDO O MÉTODO
DE PONTOS POR CASO DE USO
BANCA EXAMINADORA
Profa Denise Franzotti Togneri Orientadora
Profº Eliana
Profº Andromeda Trabalho de Conclusão de Curso aprovado em ____ / ____/ ____.
AGRADECIMENTOS
À DEUS, por me dar força, saúde, sabedoria e paciência nos momentos em que
mais precisei, aos meus pais Luiz e Eliana, por terem me proporcionado os estudos,
me apoiando e incentivando para a concretização de mais um sonho a ser realizado,
à minha noiva Amanda pela compreensão, ajuda e companheirismo, à nossa
orientadora Denise Franzotti Togneri e professores pelos ensinamentos.
George Maestri Furtado da Rosa.
À minha mãe, por acreditar nesse momento, pela educação e por estar sempre
presente. Ao meu irmão, pelo apoio e confiança. Às minhas tias Josélia, Francisca e
Nazaret, pelos conselhos e ensinamentos. À minha namorada por ter estado ao meu
lado todo esse tempo. Aos meus familiares e amigos pelos momentos de
descontração. À professora Denise Franzotti Togneri, que nos orientou e tornou
possível a realização desse trabalho.
Jose Carlos Pimentel.
Agradeço, primeiramente, à DEUS, por me dar sabedoria e forças, por seu amor e
suas misericórdias a cada dia. Aos meus pais Luiz e Marta por acreditarem em mim
e investirem em meu futuro e por me mostrarem o caminho correto. À minha esposa
Suéllen por sua compreensão e paciência nos momentos difíceis. À nossa
orientadora Denise por sua orientação e ensinamento.
Luiz Fernando Rosário.
"Embora ninguém possa voltar atrás e fazer um novo começo, qualquer um pode começar agora e fazer um novo fim."
Chico Xavier
LISTA DE QUADROS QUADRO 1 – Modelo de descrição de caso de uso ................................................. 21
QUADRO 2 – Peso dos atores .................................................................................. 23
QUADRO 3 – Peso dos casos de uso ....................................................................... 24
QUADRO 4 – Peso dos fatores de complexidade técnica ........................................ 25
QUADRO 5 – Peso dos fatores ambientais .............................................................. 26
QUADRO 6 – Dicionário de Dados da ferramenta proposta ..................................... 43
LISTA DE FIGURAS
FIGURA 1 – Diagrama de Casos de Uso .................................................................. 17
FIGURA 2 – Ator do diagrama de Casos de Uso ...................................................... 17
FIGURA 3 – Caso do uso do diagrama de Casos de Uso ........................................ 18
FIGURA 4 – Relacionamento de generalização entre casos de uso ......................... 19
FIGURA 5 – Relacionamento de inclusão entre casos de uso .................................. 19
FIGURA 6 – Relacionamento de extensão entre casos de uso ................................ 19
FIGURA 7 – Diagrama de Caso de Uso Principal. .................................................... 31
FIGURA 8 – Diagrama de Caso de Uso GerenciarProjetos ...................................... 32
FIGURA 9 – Diagrama de Caso de Uso GerenciarDadosGerais .............................. 33
FIGURA 10 – Diagrama de Caso de Uso GerenciarDiagramaCasoUso ................... 34
FIGURA 11 – Diagrama de Caso de Uso ImportarCasoUso. .................................... 35
FIGURA 12 – Diagrama de Caso de Uso GerenciarEstimativaProjeto. .................... 36
FIGURA 13 – Diagrama de Classe da ferramenta proposta. .................................... 40
FIGURA 14 – Diagrama de Seqüência IncluirProjeto. ............................................... 44
FIGURA 15 – Diagrama de Seqüência IncluirCasoUso. ........................................... 45
FIGURA 16 – Diagrama de Seqüência IncluirAtor. ................................................... 46
FIGURA 17 – Diagrama de Seqüência IncluirPesoComplexAtor. ............................. 47
FIGURA 18 – Diagrama de Seqüência IncluirPesoComplexCasoUso. ..................... 48
FIGURA 19 – Diagrama de Seqüência CalcularEstimativa. ...................................... 49
FIGURA 20 – Arquitetura Cliente-Servidor. ............................................................... 51
FIGURA 21 – Diagrama Relacional do Banco de Dados. ......................................... 53
FIGURA 22 – Tela principal da ferramenta UCPCALC. ............................................ 56
FIGURA 23 – Tela de configuração do peso dos Atores. .......................................... 57
FIGURA 24 – Tela de configuração do peso dos Casos de Uso. .............................. 58
FIGURA 25 – Tela de configuração dos Fatores de Complexidade Técnica. ........... 59
FIGURA 26 – Tela de configuração dos Fatores Ambientais. ................................... 60
FIGURA 27 – Tela de cadastro de projetos ou importação de arquivo. .................... 61
FIGURA 28 – Tela de definir Fatores de complexidade Técnica do projeto. ............. 62
FIGURA 29 – Tela de definir Fatores Ambientais do projeto..................................... 63
FIGURA 30 – Tela de definir Atores do projeto. ........................................................ 64
FIGURA 31 – Tela de Inclusão de Ator. .................................................................... 65
FIGURA 32 – Tela de definir Casos de Uso do projeto. ............................................ 66
FIGURA 33 – Tela de Inclusão de Caso de Uso. ...................................................... 67
FIGURA 34 – Tela de Inclusão do Fluxo Normal. ..................................................... 68
FIGURA 35 – Tela de Inclusão do Fluxo Alternativo. ................................................ 69
FIGURA 36 – Tela de importação de projetos aba Atores. ....................................... 70
FIGURA 37 – Tela de importação de projetos aba Caso de Uso. ............................. 71
FIGURA 38 – Tela de Exibição da Estimativa do Projeto. ......................................... 72
RESUMO
Atualmente a tecnologia de orientação a objetos e os modelos Linguagem de
Modelagem Unificada (UML - Unified Modeling Language) encontram-se bastante
difundida e utilizada nas diversas organizações. Dentre esses modelos, destaca-se o
diagrama de casos de uso. Os casos de uso são, geralmente, criados nas fases
iniciais do projeto e isso tornou possível a proposição de algumas métricas baseadas
em casos de uso, conhecidas como Pontos por Caso de Uso (PCU) que possibilitam
estimar, na fase de planejamento, o tamanho de um software baseado no esforço
medido em pessoas-mês, tempo e esforço. O objetivo geral deste trabalho é o
desenvolvimento de uma ferramenta denominada UCPCalc que auxiliará o gerente
de projeto na estimativa de tempo e esforço de um determinado projeto de software,
utilizando o método de pontos por caso de uso. Para isso, foi adotada uma
metodologia composta de revisão bibliográfica, elicitação, modelagem e
documentação de requisitos a serem atendidos pela ferramenta, utilizando-se do
paradigma da orientação a objetos, para o projeto, o desenvolvimento e os testes do
sistema. UCPCalc foi desenvolvida adotando-se a arquitetura cliente/servidor em
duas camadas, com linguagem de programação Delphi 2007 for Win32 e sistema
gerenciador de banco de dados relacional MySQL 5.0. O desenvolvimento e
implementação de UCPCalc demonstrou a viabilidade de apoio automatizado ao
cálculo de estimativas de tempo e esforço, utilizando como base o método de pontos
por caso de uso.
Palavras-chave: pontos por caso de uso, diagrama de casos de uso, estimativas de
software. UCPCalc.
SUMÁRIO 1 INTRODUÇÃO ..................................................................................................... 11
2 ESTIMATIVA DE PROJETO DE SOFTWARE ORIENTADO A OBJETOS ........ 14
2.1 ANÁLISE ORIENTADA A OBJETOS ................................................................ 14
2.2 A LINGUAGEM DE MODELAGEM UNIFICADA ............................................... 15
2.3 DIAGRAMA DE CASOS DE USO ..................................................................... 16
2.3.1 Ator ................................................................................................................ 17
2.3.2 Caso de uso .................................................................................................. 18
2.3.3 Relacionamentos .......................................................................................... 18
2.3.4 Descrição de casos de uso .......................................................................... 20
2.4 O MÉTODO DE PONTOS POR CASO DE USO .............................................. 22
2.4.1 Classificação e contagem dos atores ......................................................... 22
2.4.2 Classificação e contagem dos casos de uso ............................................. 23
2.4.3 Cálculo dos pontos por caso de uso não ajustados – UUCP ................... 24
2.4.4 Determinação dos fatores de complexidade técnica – TCF ...................... 25
2.4.5 Determinação dos fatores ambientais – EF ................................................ 26
2.4.6 Cálculo dos pontos por caso de uso ajustados – UCP ............................. 27
2.5 VANTAGENS E DESVANTAGENS NA ESTIMATIVA DE PONTOS POR CASO
DE USO..................................................................................................................... 27
2.6 CONSIDERAÇÕES FINAIS .............................................................................. 28
3 UMA PROPOSTA PARA APOIO AUTOMATIZADO AO CÁLCULO DE
ESTIMATIVA DE PROJETOS DE SOFTWARE UTILIZANDO O MÉTODO DE
PONTOS POR CASO DE USO ................................................................................ 30
3.1 REQUISITOS FUNCIONAIS ............................................................................. 30
3.1.1 Caso de Uso GerenciarProjeto .................................................................... 32
3.1.2 Caso de Uso GerenciarDadosGerais .......................................................... 33
3.1.3 Caso de Uso GerenciarDiagramaCasoUso ................................................. 34
3.1.4 Caso de Uso GerenciarEstimativaProjeto .................................................. 35
3.2 TRABALHOS CORRELATOS ........................................................................... 36
3.3 CONSIDERAÇÕES FINAIS .............................................................................. 38
4 ANÁLISE ............................................................................................................. 39
4.1 MODELAGEM DE CLASSES............................................................................ 39
4.2 DIAGRAMAS DE SEQÜÊNCIA ......................................................................... 44
4.3 CONSIDERAÇÕES FINAIS .............................................................................. 50
5 PROJETO E IMPLEMENTAÇÃO ........................................................................ 51
5.1 PROJETO ......................................................................................................... 51
5.1.1 Projeto de Arquitetura do Sistema .............................................................. 51
5.1.2 Projeto de banco de dados .......................................................................... 52
5.2 IMPLEMENTAÇÃO ........................................................................................... 54
5.2.1 Tecnologia e linguagem utilizada ................................................................ 54
5.2.2 Restrições de implementação ..................................................................... 55
5.2.3 Protótipo da ferramenta ............................................................................... 55
5.2.4 Instalação e funcionamento do protótipo ................................................... 73
5.3 CONSIDERAÇÕES FINAIS .............................................................................. 73
6 CONCLUSÕES E PERSPECTIVAS FUTURAS .................................................. 74
REFERÊNCIAS ......................................................................................................... 75
ANEXOS ................................................................................................................... 77
11
1 INTRODUÇÃO Antes que o projeto de software, como um todo, comece, é necessário que a equipe
de projeto estime o trabalho, o tempo e os recursos necessários para implementá-lo.
É nessa fase que a atividade de planejamento de projeto se inicia. A fase de
planejamento tem como objetivo fornecer um conjunto de dados que permita ao
gerente do projeto fazer essas estimativas. O planejamento envolve atividades tais
como: definição do escopo, estudo de viabilidade, análise de risco, definição de
recursos, estimativas de custo e esforço e elaboração do cronograma do projeto.
Estimar tempo e esforço é fundamental para assegurar que o projeto de software
seja concluído dentro do orçamento previsto e aprovado. Para apoiar este processo,
diversos modelos de estimativa de esforço foram propostos e incluem o tamanho do
software como um parâmetro importante.
Atualmente, um dos métodos de cálculo de estimativas mais utilizados pelos
gerentes de projeto é a análise por pontos de função, que mede os requisitos
funcionais do projeto. No entanto, apresenta alguns problemas como: o método é
aplicado somente ao final da atividade de Engenharia de Requisitos de Software,
após ser feita a descrição funcional do sistema, impactando no estudo de viabilidade
do projeto em termos de custo e tempo e necessita do Diagrama de Fluxo de Dados
modelado, que é um diagrama pouco utilizado atualmente.
Temos como hipótese para este trabalho o apoio automatizado ao cálculo de
estimativa de custo e esforço de projetos de software, utilizando o método de Pontos
por Caso de Uso, pode contribuir para a solução dos problemas levantados.
O método de estimativa por pontos de caso de uso (UCP – Use Case Point) foi
proposto por Gustav Karner em 1993, com o objetivo de estimar o esforço numa fase
mais inicial do processo de software, durante o levantamento de requisitos. É
inspirado no modelo de estimativas de Pontos de Função proposto por Allan
Albrecht, em 1979, e utiliza o Diagrama de Casos de Uso, um dos modelos da
Linguagem de Modelagem Unificada (UML – Unified Modeling Language), como
base para medir a funcionalidade do sistema.
12
O objetivo geral deste trabalho é o desenvolvimento de uma ferramenta para apoiar
o gerente na atividade de estimativa de tempo e esforço de um projeto de software,
utilizando o método de estimativas por pontos de caso de uso. Os objetivos
específicos são:
Investigar o estado da arte sobre Diagramas de Caso de Uso e cálculos de
estimativas via Pontos por Caso de Uso;
Levantar os requisitos para uma ferramenta de apoio ao gerente de projeto na
atividade de estimativas de tempo e esforço utilizando pontos por caso de
uso;
Analisar, projetar, construir e testar a ferramenta.
Este trabalho se justifica, pois a automatização do cálculo de estimativa pode dar
mais agilidade e qualidade ao planejamento do projeto de software, uma vez que
será possível calcular a estimativa assim que o Diagrama de Casos de Uso estiver
aprovado pelos usuários. De posse de uma ferramenta de estimativas de projetos, o
gerente de projetos poderá analisar os pontos a serem aprimorados, ajustar o tempo
de desenvolvimento de cada tarefa em função da produtividade real da equipe,
melhorar o processo de desenvolvimento, avaliar os pontos fortes e fracos da equipe
e fornecer ao cliente um custo e tempo mais precisos possível.
Para uma melhor compreensão do sistema a ser desenvolvido e na busca da melhor
solução para o desenvolvimento de uma ferramenta para estimar tempo e esforços
de projetos de software, foi adotada uma metodologia composta das seguintes
fases:
revisão bibliográfica. Inicialmente foi feito um estudo sobre análise orientada a
objetos, Linguagem de Modelagem Unificada, Diagrama de Casos de Uso e
métodos para estimativas de software, para que se pudesse adquirir uma
base sobre esses assuntos;
engenharia de requisitos. Os requisitos foram levantados e documentados
para que pudesse ser dado início à implementação do sistema;
13
projeto do sistema. Nesta etapa, os recursos tecnológicos a serem utilizados
no desenvolvimento do sistema foram definidos, foi feita a especificação da
arquitetura de hardware e software, estrutura de dados e estruturas de
controles;
implementação: foi feita a codificação da ferramenta, utilizando a tecnologia
Borland Delphi e banco de dados MySQL;
testes: o teste do sistema foi planejado e executado.
Este trabalho contém, além desta introdução, mais cinco capítulos.
O Capítulo 2 – Estimativa de Projeto de Software Orientado a Objetos – apresenta
uma base teórica sobre o método de estimativas por pontos de caso de uso e
conceitos relacionados à estimativa de software, análise OO e UML.
O Capítulo 3 – Uma Proposta para Apoio Automatizado ao Cálculo de Estimativa de
Projetos de Software utilizando o Método de Pontos por Casos de Uso - propõe uma
ferramenta para a estimativa de projetos baseada na estimativa de projetos por
pontos de casos de uso. Descreve os requisitos funcionais da ferramenta,
apresentando os diagramas de casos de uso e suas descrições e a análise de
algumas ferramentas correlatas.
O Capítulo 4 – Análise Orientada a Objetos – apresenta a análise OO da ferramenta
proposta incluindo os diagramas de classes e de seqüência.
O Capítulo 5 – Projeto e Implementação – aborda as fases de projeto orientado a
objetos e implementação da ferramenta proposta.
O Capítulo 6 – Conclusões e Perspectivas Futuras – apresenta as conclusões e
perspectivas futuras deste trabalho.
14
2 ESTIMATIVA DE PROJETO DE SOFTWARE ORIENTADO A OBJETOS
Neste capítulo, serão abordados, de maneira geral, conceitos relacionados à Análise
Orientada a Objetos, Linguagem de Modelagem Unificada (UML - Unified Modeling
Language), Diagrama de Casos de Uso, Estimativas de Projeto de Software e o
método de Pontos por Caso de Uso proposto por Gustav Karner.
2.1 ANÁLISE ORIENTADA A OBJETOS A Análise Orientada a Objetos (AOO) é a primeira atividade técnica que é realizada
como parte da Engenharia de Software Orientada a Objetos. A AOO não se utiliza
do modelo de entrada-processamento-saída ou de estruturas hierárquicas; ela cria
um modelo orientado às classes baseado na Orientação a Objetos.
Para modelar sistemas orientados a objetos, Grady Booch, James Rumbaugh e Ivar
Jacobson combinaram as melhores características de seus métodos individuais e
propuseram uma linguagem de modelagem denominada Linguagem de Modelagem
Unificada (UML – Unified Modeling Language), que se tornou amplamente utilizada
na indústria.
Inicialmente, é feita uma descrição de casos de uso baseada em cenários de como
atores interagem com o produto a ser construído. A AOO examina um domínio do
problema definido como um conjunto de casos de uso em um esforço para extrair
classes que definam o problema. Cada classe tem um conjunto de atributos e
operações. Classes estão relacionadas entre si por uma variedade de modos e são
modeladas por meio de Diagramas de Classe (PRESSMAN, 2006, p. 181). Além
disso, a UML, abordada a seguir, também propõe que na AOO devem ser
modelados, dentre outros, os Diagramas de Seqüência e os Diagramas de Estado.
15
2.2 A LINGUAGEM DE MODELAGEM UNIFICADA A UML é uma linguagem-padrão para a elaboração da estrutura de projeto de
software, que poderá ser empregada para visualizar, especificar, construir e
documentar artefatos de um sistema ou projeto e pode ser utilizada com todos os
processos ao longo do ciclo de desenvolvimento. Ela é apenas uma notação e,
portanto, é somente uma parte de um método para desenvolvimento de software. É
um facilitador de comunicação para todas as pessoas envolvidas no
desenvolvimento de um projeto ou sistema, por ser uma linguagem de fácil
entendimento.
A UML possui dois tipos de diagramas que são os estruturais e os comportamentais.
Os diagramas estruturais são responsáveis por documentar os aspectos estáticos do
sistema, onde se enquadram (BOOCH, RUMBAUGH, JACOBSON, 2000, p. 13):
diagrama de classes: estrutura lógica estática em uma superfície de duas
dimensões mostrando uma coleção de elementos declarativos de modelo,
como classes, tipos e seus respectivos conteúdos e relações;
diagrama de objetos: faz a modelagem de instâncias de itens contidos em
diagramas de classes;
diagrama de componentes: representa, de forma estática, aspectos físicos do
sistema sendo modelado;
diagrama de implantação: mostra a configuração de nós de processamento
em tempo de execução e os componentes que neles existem.
Os diagramas comportamentais são responsáveis por documentar os aspectos
dinâmicos do sistema, onde se enquadram (BOOCH, RUMBAUGH, JACOBSON,
2000, p. 13):
diagrama de seqüência: é usado para modelar a interação entre objetos em
um sistema;
diagrama de colaboração: é uma outra alternativa para a modelagem de
interações entre objetos de um sistema;
16
diagrama de estados: é usado para modelar o comportamento dinâmico de
um sistema;
diagrama de atividades: é essencialmente um gráfico que mostra o fluxo de
controle de uma atividade para outra;
diagrama de casos de uso: ilustra um conjunto de casos de uso para um
sistema, os atores e a relação entre os atores e os casos de uso.
O Diagrama de Casos de Uso será abordado em detalhes na próxima seção.
2.3 DIAGRAMA DE CASOS DE USO Os diagramas de casos de uso são uma representação diagramática de um caso de
uso que é utilizado para modelar o sistema do ponto de vista do usuário. São
importantes principalmente para a organização e modelagem dos comportamentos
de um sistema, e, como são gerados na fase inicial do levantamento e
documentação de requisitos, facilitam o desenvolvimento de várias técnicas de
medição de tempo e esforço de um software.
O diagrama é necessário para a visualização, especificação e documentação dos
comportamentos de um elemento. Através do diagrama é mais fácil o entendimento
do sistema, subsistemas e classes, por ser um diagrama que apresenta uma visão
externa de como os elementos ali contidos podem ser utilizados.
Em um diagrama de caso de uso podem ser identificados três componentes
principais: atores, casos de uso e relacionamentos, descritos a seguir (BOOCH,
RUMBAUGH, JACOBSON, 2000, p. 231-233). A Figura 1 apresenta um exemplo de
um diagrama de casos de uso.
17
FIGURA 1 – Diagrama de Casos de Uso
2.3.1 Ator Um ator representa um conjunto coerente de papéis que os usuários de casos de
uso desempenham quando interagem com esses casos de uso. Tipicamente, um
ator representa um papel que um ser humano, um dispositivo de hardware ou até
outro sistema desempenha com o sistema. Um ator é representado no diagrama por
um stickman com seu nome abaixo do desenho, conforme a Figura 2.
FIGURA 2 – Ator do diagrama de Casos de Uso
Mesmo utilizando atores na modelagem do Caso de Uso, eles não são parte do
sistema; são apenas representação de uma entidade externa ao sistema (BOOCH,
RUMBAUGH, JACOBSON, 2000, p. 221).
18
2.3.2 Caso de uso Um caso de uso especifica o comportamento de um sistema ou de parte de um
sistema e é uma descrição de um conjunto de seqüências de ações, incluindo
variantes realizadas pelo sistema para produzir um resultado observável do valor de
um ator. Podem ser aplicados para captar o comportamento pretendido do sistema
que está sendo desenvolvido, sem ser necessário especificar como esse
comportamento é implementado.
Os casos de usos fornecem uma maneira para os desenvolvedores chegarem a uma
compreensão comum com os usuários finais do sistema e com os especialistas do
domínio. Além disso, servem para ajudar a validar a arquitetura e para verificar o
sistema à medida que ele evolui durante seu desenvolvimento. Os casos de uso são
representados por elipses que contêm o nome (título) do caso de uso; esse título
pode ser posicionado no interior ou, opcionalmente, abaixo de cada elipse, conforme
a Figura 3 (BOOCH, RUMBAUGH, JACOBSON, 2000, p. 217).
FIGURA 3 – Caso do uso do diagrama de Casos de Uso
2.3.3 Relacionamentos Além das ligações entre casos de uso com ator, existem também ligações entre caso
do uso com outro caso de uso, que podem ser de três tipos: inclusão, extensão e de
generalização.
A generalização entre casos de uso é semelhante à generalização entre as classes.
Aqui a generalização significa que o caso de uso filho herda o comportamento e o
significado do caso de uso pai; o filho deverá acrescentar ou sobrescrever o
comportamento de seu pai; e o filho poderá ser substituído em qualquer local no
qual o pai apareça (ambos, o pai e o filho poderão ter instâncias concretas). A
19
generalização entre casos de uso é representada como uma linha cheia direcionada
com uma seta aberta, exatamente como ocorre com a generalização entre classes.
FIGURA 4 – Relacionamento de generalização entre casos de uso
Um relacionamento de inclusão entre casos de uso significa que o caso de uso base
incorpora explicitamente o comportamento de outro caso de uso em uma localização
especificada na base. Este relacionamento e utilizado para evitar descrever o
mesmo fluxo de eventos várias vezes, incluindo o comportamento comum em um
caso de uso próprio (o caso de uso incluído em um caso de uso básico).
FIGURA 5 – Relacionamento de inclusão entre casos de uso
Um relacionamento de extensão entre casos de uso significa que o caso de uso
base incorpora implicitamente o comportamento de outro caso de uso em um local
especificado indiretamente pelo caso de uso estendido. Um relacionamento
estendido é utilizado para a modelagem da parte de um caso de uso que o usuário
poderá considerar como um comportamento opcional do sistema. Desse modo,
separa-se o comportamento opcional do comportamento obrigatório (BOOCH,
RUMBAUGH, JACOBSON, 2000, p. 224-226).
FIGURA 6 – Relacionamento de extensão entre casos de uso
20
2.3.4 Descrição de casos de uso Não existe um modelo específico de descrição de um caso de uso. Qualquer texto
descrevendo o que um sistema pode ser ou fazer pode ser considerado uma
descrição de um caso de uso (KOIRALA, 2007, p. 97).
Segundo Cockburn (2000, p. 94) existem alguns passos a serem seguidos para a
construção de casos de usos:
usar gramática simples: A sentença dever ser bastante simples, sujeito...
verbo...objeto direto...predicado. Isso é tudo que deve conter. Se a sentença
for mal formulada, o passo-a-passo será difícil de seguir;
ser claro: o ator que será o sujeito da sentença, o primeiro ator nomeado,
deve ser de preferência a primeira ou segunda palavra da frase;
deve ser escrito com “Visão de pássaro”: ou seja, o caso de uso deve ser
escrito dando uma visão geral, não se prendendo muito a detalhes. Por
exemplo, ao invés de “O usuário pega o cartão do bolso e insere na máquina”,
deve ser escrito como “O usuário insere o cartão”;
descrever a intenção do ator, não os movimentos: descrever os movimentos
do ator é um dos erros mais comuns. Por exemplo, ao invés de descrever “O
usuário move o mouse até a caixa de texto e escreve o nome”, deve ser
escrito como “O usuário preenche o nome”.
Vários modelos de descrição dos casos de uso foram propostos desde que
Jacobson criou o conceito de casos de uso. Alguns elementos são comuns a todos
os modelos, como é o caso da seção “fluxo normal” e da seção “fluxo alternativo”,
porém, alguns elementos aparecem de acordo com a necessidade do analista. A
descrição dos casos de uso pode conter as seguintes seções (WAZLAWICK, 2004,
p.84):
atores: listas as entidades do mundo real que interagem com o sistema por
meio dos casos de uso;
21
interessados: a parte que tem interesse nos resultados produzidos pelo caso
de uso. É útil listar os interessados porque o caso de uso deve satisfazer a
todos os interessados;
precondições: fatos considerados verdadeiros antes do início do caso de uso,
necessários para a sua execução;
pós-condições: descreve os resultados, o que será verdadeiro após a
execução do caso de uso;
requisitos correlacionados: correlação entre os requisitos e os casos de uso;
variações tecnológicas: registram as possíveis variações tecnológicas que
poderiam ser utilizadas para realizar o caso de uso;
questões em aberto: dúvidas que no momento o analista não pode sanar
talvez por estar trabalhando sem a presença do cliente.
Cockburn (2000, p.126) propõe o seguinte modelo para descrição dos Casos de
Uso, como mostra o quadro 1:
Caso de Uso: Nome do caso de uso
Breve descrição: Descrição sucinta do caso de uso.
Atores: Descrição dos atores do caso de uso.
Gatilho: Ação do ator que inicia o caso de uso.
Fluxo de Eventos
Fluxo Normal
Descrição do cenário principal de sucesso.
Fluxo Alternativo
Descrição dos cenários alternativos ou de exceção.
Requisitos especiais: Descrição das funcionalidades não descrita nos casos de uso, mas que devem ser levadas em conta no projeto ou implementação.
Pré-Condição: Descrição das condições que devem ser supridas para o início dos casos de uso.
Pós-condições: Descrição das condições que devem acontecer após o fim dos casos de uso.
Pontos de extensão: Descrição dos casos de uso de extensão do diagrama.
QUADRO 1 – Modelo de descrição de caso de uso Fonte: COCKBURN, 2000, p. 126
22
Os casos de uso e suas descrições podem ser usados como base para medir o
tamanho do esforço de desenvolvimento do software, como, por exemplo, o método
de pontos por caso de uso, descrito na próxima seção.
2.4 O MÉTODO DE PONTOS POR CASO DE USO O método de Pontos por Caso de Uso (UCP- Use Case Point) foi proposto por
Gustav Karner, em 1993, e é inspirado no modelo de estimativas de Pontos de
Função proposto por Allan Albrecht em 1979. O UCP tem como objetivo estimar o
tamanho do esforço (em pessoa-mês) para desenvolver projetos de software
orientado a objetos. O Diagrama de Casos de Uso é utilizado como base para medir
a funcionalidade do sistema através da contagem dos Pontos por Caso de Uso Não
Ajustados (UUCP). Os Fatores de Complexidade Técnica (TCF) e os Fatores
Ambientais (EF) envolvidos no projeto também são considerados pelo método. Os
Pontos por Caso de Uso são obtidos através do produto desses três fatores
(KARNER, 1993, p. 2).
Segundo ANDRADE (2004, p. 22), o processo de contagem dos Pontos por Caso de
Uso consiste nas seguintes etapas: classificar e contar os atores e os casos de uso,
calcular os pontos por caso de uso não ajustados, determinar os fatores de
complexidade técnica, determinar os fatores ambientais e calcular os pontos por
caso de uso ajustados, que são abordados a seguir.
2.4.1 Classificação e contagem dos atores Nesta etapa, os atores devem ser classificados de acordo com a sua complexidade
que pode ser definida como simples, média e complexa. Os atores com mesma
complexidade deverão ser somados. O total de atores de mesma complexidade
deverá ser multiplicado pelo seu respectivo peso de acordo com o Quadro 2
(ANDRADE, 2004, p. 22).
23
Complexidade (i) Definição Peso (Wi)
Simples Um ator é simples se representa um outro sistema com uma API definida.
1
Médio
Um ator é médio se ele é:
1. Uma interação com outro sistema através de um protocolo.
2. Uma interação humana com um terminal.
2
Complexo Um ator é complexo se ele interage através de uma interface gráfica com o usuário.
3
QUADRO 2 – Peso dos atores Fonte: KARNER, 1993, p. 2
O peso dos atores não ajustados (UAW) pode ser obtido utilizando a fórmula (RIBU,
2001, p. 20):
i
i
i WnUAW *3
1
(1)
onde:
UAW = peso dos atores não ajustado
i = complexidade
ni = quantidade de atores com a complexidade i
Wi = peso da complexidade i
2.4.2 Classificação e contagem dos casos de uso Nesta etapa os casos de uso devem ser classificados de acordo com a sua
complexidade definida como simples, média e complexa. A complexidade do caso
de uso é determinada pelo número de transações presentes no mesmo. Os casos de
uso com mesma complexidade deverão ser somados. O total de casos de uso de
mesma complexidade deverá ser multiplicado pelo seu respectivo peso de acordo
com o Quadro 3 (ANDRADE, 2004, p. 23).
24
Complexidade (i) Definição Peso (Wi)
Simples
Um caso de uso é simples se tem 3 ou menos transações incluindo cursos alternativos. Você deverá ser capaz de compreender o caso de uso com menos que 5 objetos de análise.
5
Médio
Um caso de uso é médio se tem de 3 a 7 transações incluindo cursos alternativos. Você deverá ser capaz de compreender o caso de uso com 5 a 10 objetos de análise.
10
Complexo
Um caso de uso é complexo se ele tem mais do que 7 transações incluindo cursos alternativos. O caso de uso deverá, pelo menos, necessitar de 10 objetos de análise.
15
QUADRO 3 – Peso dos casos de uso Fonte: KARNER, 1993, p. 2
O Peso dos Casos de Uso Não Ajustados (UUCW) pode ser obtido utilizando a
fórmula (RIBU, 2001, p. 20):
i
i
i WnUUCW *3
1
(2)
onde:
UUCW = peso dos casos de uso não ajustado
i = complexidade
ni = quantidade de casos de uso com a complexidade i
Wi = peso da complexidade i
2.4.3 Cálculo dos pontos por caso de uso não ajustados – UUCP Os Pontos por Caso de Uso Não Ajustados podem ser obtidos utilizando a fórmula
(RIBU, 2001, p. 21):
UUCWUAWUUCP (3)
onde:
UUCP = pontos por caso de uso não ajustados
UAW = peso dos atores não ajustado
UUCW = peso dos casos de uso não ajustado
25
2.4.4 Determinação dos fatores de complexidade técnica – TCF Para determinar os Fatores de Complexidade Técnica cada fator Fi deve ser
classificado numa escala de zero a cinco, onde zero indica que o fator é irrelevante e
cinco indica que o fator é essencial. Se o fator não é nem importante nem
irrelevante, ele terá o valor três. Caso todos os fatores tenham o valor três, o TCF ≈
1. Após classificar cada fator, o valor Fi deve ser multiplicado pelo seu respectivo
peso conforme o Quadro 4 (KARNER, 1993. p. 3).
Fi Fatores que Contribuem para Complexidade Wi
F1 Sistemas distribuídos. 2
F2 Objetivos de desempenho da aplicação, em qualquer resposta ou taxa
de transferência. 1
F3 Eficiência do usuário final (on-line). 1
F4 Processamento interno complexo. 1
F5 Reusabilidade, o código deve permitir reutilização em outras
aplicações. 1
F6 Fácil instalação. 0,5
F7 Fácil operação, usabilidade. 0,5
F8 Portabilidade. 2
F9 Fácil manutenção. 1
F10 Concorrência. 1
F11 Características especiais de segurança. 1
F12 Proporcionar acesso direto a terceiros. 1
F13 Facilidades de treinamento especiais. 1
QUADRO 4 – Peso dos fatores de complexidade técnica Fonte: KARNER, 1993, p. 3
O Fator de Complexidade Técnica pode ser obtido utilizando a fórmula (KARNER,
1993, p. 3):
i
i
i WFCCTCF **13
1
21 (4)
26
onde:
TCF = fator de complexidade técnica do projeto
C1 = 0,6
C2 = 0,01
Fi = fator de complexidade técnica
Wi = peso do fator de complexidade técnica (Fi)
2.4.5 Determinação dos fatores ambientais – EF Os Fatores Ambientais são obtidos da mesma maneira que os Fatores de
Complexidade Técnica. Cada fator Fi deve ser classificado numa escala de zero a
cinco, onde zero indica que o fator é irrelevante e cinco indica que o fator é
essencial. Se o fator não é nem importante nem irrelevante, ele terá o valor três.
Caso todos os fatores tenham o valor três, o EF ≈ 1. Após classificar cada fator, o
valor Fi deve ser multiplicado pelo seu respectivo peso conforme o Quadro 5
(KARNER, 1993, p. 3).
Fi Fatores que Contribuem para Eficiência Wi
F1 Familiaridade com o processo de desenvolvimento de software. 1,5
F2 Trabalhadores de tempo parcial. -1
F3 Capacidade do analista. 0,5
F4 Experiência com a aplicação. 0,5
F5 Experiência com a orientação a objetos. 1
F6 Motivação. 1
F7 Dificuldade com a linguagem de programação. -1
F8 Requisitos estáveis. 2
QUADRO 5 – Peso dos fatores ambientais Fonte: KARNER, 1993, p. 3
O Fator Ambiental pode ser obtido utilizando a fórmula (KARNER, 1993, p. 3):
i
i
i WFCCEF **8
1
21 (5)
27
onde:
EF = fator ambiental do projeto
C1 = 1,4
C2 = -0,03
Fi = fator ambiental Wi = peso do fator ambiental (Fi)
2.4.6 Cálculo dos pontos por caso de uso ajustados – UCP Finalmente, depois de ter obtido os Pontos por Caso de Uso Não Ajustados, os
Fatores de Complexidade Técnica e os Fatores Ambientais, os Pontos por Caso de
Uso Ajustados podem ser calculados utilizando fórmula (KARNER, 1993, p. 4):
EFTCFUUCPUCP ** (6)
Onde:
UCP = pontos por caso de uso ajustados
UUCP = pontos por caso de uso não ajustados
TCF = fator de complexidade técnica do projeto
EF = fator ambiental do projeto
Após a realização do cálculo dos Pontos por Caso de Uso Ajustados, é possível
obter o tamanho do esforço necessário para desenvolver o projeto, mapeando os
Pontos por Caso de Uso Ajustados em pessoa-hora. Karner sugere um total de 20
pessoas-horas por unidade de ponto de caso de uso, mas em média fica entre 15 e
30 pessoas-horas (KARNER, 1993, p. 5).
2.5 VANTAGENS E DESVANTAGENS NA ESTIMATIVA DE PONTOS POR CASO DE USO
A abordagem pelo método de Pontos por Caso de Uso possui algumas vantagens e
desvantagens. As vantagens são (COHN, 2005, p. 12):
o processo de estimativas por Pontos de Caso de Uso pode ser otimizado,
como, por exemplo, ajustando ferramentas que gerenciam casos de uso para
contar automaticamente o número de pontos por caso de uso no sistema. Isso
28
pode reduzir o tempo de realização da estimativa, porém, pessoas da área
argumentam que uma estimativa é tão boa quanto o esforço nela aplicado;
a organização poderá estabelecer um tempo médio de implementação de
pontos por caso de uso. Isso será útil para realizar futuras previsões. O nível
de detalhamento na escrita do caso de uso deverá ser o mesmo para todos
os autores de casos de uso;
os Pontos por Caso de Uso são uma medida de tamanho pura, já que o
tamanho da aplicação independe do tamanho, da tecnologia envolvida e da
experiência da equipe.
As desvantagens são (COHN, 2005, p. 12):
a estimativa de pontos por caso de uso não pode ser realizada até que todos
os casos de uso tenham sido escritos. Escrever casos de uso com os
objetivos do usuário representa um esforço de 10-20% do esforço total de um
projeto, isso poderá atrasar a criação do Plano de Projeto;
casos de uso demandam muito trabalho para serem realizados no
planejamento de um sistema. A melhor abordagem seria separar o caso de
uso em user stories e estimar user stories em story points ou ideal times;
as regras que determinam o que constitui uma transação são imprecisas. A
contagem do número de passos no user goal ou no user story é uma
aproximação, o que torna a técnica imprecisa, já que o detalhamento do caso
de uso varia muito de autor para autor;
alguns Fatores de Complexidade Técnica não impactam o projeto como um
todo. Porém, como são multiplicados pelo peso dos casos de uso e atores
esses fatores acabam impactando todo o projeto.
2.6 CONSIDERAÇÕES FINAIS Neste capítulo foram abordados os conceitos relacionados à Análise Orientada a
Objetos, à Linguagem de Modelagem Unificada, ao Diagrama de Casos de Uso, às
29
Estimativas de Projeto de Software e ao método de Pontos por Caso de Uso. No
próximo capítulo será apresentada uma proposta para apoio automatizado ao
cálculo de estimativa de projetos de software utilizando o método de pontos por caso
de uso.
30
3 UMA PROPOSTA PARA APOIO AUTOMATIZADO AO CÁLCULO DE ESTIMATIVA DE PROJETOS DE SOFTWARE UTILIZANDO O MÉTODO DE PONTOS POR CASO DE USO
Neste capítulo, são apresentados os requisitos funcionais do sistema, abordando os
casos de uso e uma breve descrição de cada um, bem como alguns softwares
correlatos desenvolvidos para o cálculo de estimativas de projetos.
O software proposto permitirá ao gerente fazer o registro de projetos, atores e casos
de uso, sendo que casos de uso e atores poderão ser importados para o sistema
através de um arquivo XMI (arquivo gerado por ferramentas de modelagem que dão
suporte a essa importação).
Após o cadastro ou importação dos casos de uso e atores de um projeto, o
engenheiro de software fará a descrição de cada caso de uso e o gerente informará
a complexidade de cada ator registrado no sistema. A inserção da descrição dos
casos de uso será feita de forma a otimizar a contagem de transações do caso de
uso. O gerente informará também os valores de complexidade técnica e fatores
ambientais do projeto (informações essas que variam de projeto para projeto).
Com base nessas informações o software efetuará o cálculo dos pontos por caso de
uso, utilizando o método proposto por Karner (1993), fornecendo ao final a
quantidade de tempo e o esforço do projeto.
No sistema ficarão armazenados os históricos de tempo/esforços anteriores para
que o gerente possa fazer uma comparação do projeto atual com os anteriores.
3.1 REQUISITOS FUNCIONAIS Os requisitos funcionais serão apresentados através dos Diagramas de Caso de Uso
e suas descrições. Eles foram elicitados através de revisão bibliográfica, entrevistas
com especialistas da área, tendo os seguintes atores que interagem com o sistema:
Gerente de Projeto: Responsável pelo projeto, possui acesso total e irrestrito
ao sistema;
31
Engenheiro de Software: Tem acesso somente às funções mais básicas,
como por exemplo, cadastrar atores e casos de uso e efetuar consultas.
Os diagramas de caso de uso e suas descrições são apresentados a seguir, de
forma sucinta. A sua descrição completa é apresentada no anexo A. O diagrama de
Caso de Uso principal é representado na Figura 7.
FIGURA 7 – Diagrama de Caso de Uso Principal.
Os casos de uso principais do sistema são: GerenciarProjeto,
GerenciarDadosGerais, GerenciarDiagramaCasoUso e GerenciarEstimativaProjeto e
serão descritos a seguir.
32
3.1.1 Caso de Uso GerenciarProjeto O caso de uso GerenciarProjeto é utilizado pelo ator Gerente de Projeto e pelo
Engenheiro de Software, sendo que este somente consulta os dados. É responsável
por gerenciar os dados relacionados ao projeto no sistema, como mostra a Figura 8,
e é decomposto nos seguintes casos de uso:
CadastrarProjetos. É responsável pelo gerenciamento das informações do
projeto;
CadastrarRelFatComplexTecProjeto. É responsável pelo gerenciamento da
relevância dos fatores relacionados à complexidade técnica do projeto;
CadastrarRelFatAmbientaisProjeto. É responsável pelo gerenciamento da
relevância dos fatores ambientais do projeto;
ConsultarDadosHistoricos. Mostra os dados referentes a projetos anteriores
cadastrados no sistema.
FIGURA 8 – Diagrama de Caso de Uso GerenciarProjetos
33
3.1.2 Caso de Uso GerenciarDadosGerais O caso de uso GerenciarDadosGerais é utilizado pelo ator Gerente de Projeto e pelo
Engenheiro de Software, sendo que este apenas consulta os dados. É responsável
por gerenciar os dados gerais do sistema, como mostra a Figura 9, e é decomposto
nos seguintes casos de uso:
CadastrarPesoComplexAtor. É responsável pelo cadastro dos pesos das
complexidades dos atores;
CadastrarPesoComplexCasoUso. É responsável pelo cadastro dos pesos das
complexidades dos casos de uso;
CadastrarPesoFatComplexTec. É responsável pelo cadastro dos pesos das
complexidades técnicas do sistema;
CadastrarPesoFatAmbientais. É responsável pelo cadastro dos pesos dos
fatores ambientais do sistema.
FIGURA 9 – Diagrama de Caso de Uso GerenciarDadosGerais
34
3.1.3 Caso de Uso GerenciarDiagramaCasoUso O caso de uso GerenciarDiagramaCasoUso, apresentado na Figura 10, é utilizado
pelo atores Gerente de Projeto e Engenheiro de Software, sendo que o Engenheiro
de Software só tem permissão para gerenciar os casos de uso e atores.
FIGURA 10 – Diagrama de Caso de Uso GerenciarDiagramaCasoUso
É responsável pelas funções de gerenciamento dos diagramas de casos de uso de
um projeto no sistema. É decomposto nos seguintes casos de uso:
GerenciarCasoUso. Responsável pelo cadastro de casos de uso de um
projeto no sistema;
GerenciarAtor. Responsável pelo cadastro de atores de um projeto no
sistema;
ImportarDCasoUso. Responsável pela importação do diagrama de casos de
uso e atores de um arquivo XMI. É subdividido em casos de uso menores
como importar diagrama de casos de uso e importar atores, conforme a
Figura 11. O gerente irá selecionar o arquivo XMI e o sistema irá analisar o
arquivo e fazer a importação desses dados para o sistema.
35
FIGURA 11 – Diagrama de Caso de Uso ImportarCasoUso.
3.1.4 Caso de Uso GerenciarEstimativaProjeto O caso de uso GerenciarEstimativaProjeto é executado pelo Gerente de Projeto e
Engenheiro de Software, sendo que esse apenas consulta a estimativa do projeto.
Tem como objetivo fazer o cálculo da estimativa de projeto. É apresentado na Figura
12 e é decomposto nos seguintes casos de uso:
EstimarProjeto. É responsável pelo cálculo dos valores da complexidade do
ator e casos de uso, PCU não ajustado e PCU ajustado, do esforço de
pessoas-hora por caso de uso e o prazo estimado para a conclusão do
desenvolvimento de cada caso de uso, onde cada um deles é executado por
um caso de uso específico;
ConsultarEstimativa. É responsável por gerar um relatório do cálculo da
estimativa do projeto informado;
36
FIGURA 12 – Diagrama de Caso de Uso GerenciarEstimativaProjeto.
3.2 TRABALHOS CORRELATOS O cálculo de estimativa de projetos de software através de pontos por casos de uso
pode ser desenvolvido de diversas formas. Muitas pesquisas já foram efetuadas
nessa área o que resultou na implementação de algumas ferramentas.
A Ferramenta de Cálculo de Pontos por Casos de Uso denominada SISPCU foi
desenvolvida por alunos de Ciência da Informação da Faculdade Vitoriana de
Tecnologia – FVT, Espírito Santo. A SISPCU é uma ferramenta para o cálculo da
estimativa de projeto de software. A ferramenta foi implementada em Delphi sendo
executada na plataforma Windows.
A SISPCU permite a estimativa de tempo e esforço de projetos de software
utilizando o método de Pontos por Caso de Uso. Também permite o cadastro de
cargos e salários (valor/hora), armazena também os funcionários que irão participar
do projeto para um maior controle dos recursos humanos. Permite a consulta de
margem de erro dos projetos desenvolvidos, ou seja, a diferença entre o estimado e
o realizado. Possui cadastro de módulos e funcionalidades, sendo que esses dados
37
ajudam na precisão do cálculo, diminuindo a margem de erros, melhorando assim, a
eficiência da ferramenta (CORTELETTI, SANTOS, 2005, p. 43).
Kusumoto et al. (2006) apresentaram a ferramenta U-EST - Use case based
Estimation Supporting Tool, que foi desenvolvida na Graduate School of Information
Science and Technology, na Osaka University, tendo como base a métrica baseada
por pontos de caso de uso. Ela foi desenvolvida em JAVA e Xerces2 Java Parser.
A U-EST foi proposta com o objetivo de se criar uma ferramenta para estimativas de
projetos o mais automática possível. Nela a entrada principal de dados é um arquivo
XMI contendo o diagrama de casos de uso. Esse arquivo passa por um analisador e
são extraídos os atores e casos de uso, que são analisados e é feita a atribuição da
complexidade para cada um deles. Caso haja necessidade de algum ajuste na
classificação, o sistema permite o ajuste antes de ser feito o cálculo. Depois de ser
feito o cálculo, os dados são armazenado em um banco de dados servindo como
base histórica para outros projetos.
O Controla é uma ferramenta desenvolvida por alunos da Faculdade de Viçosa –
FDV, Minas Gerais. Ela é uma ferramenta para apoio ao processo de
desenvolvimento de software, contendo várias funcionalidades:
Cadastro e manutenção de projetos de software;
Gerenciamento de Casos de Uso;
Gerenciamento de Casos de Teste;
Estimativa de tamanho de software por Pontos de Casos de Uso;
Gerenciamento de implementações.
A ferramenta apresenta um conjunto de indicadores que possibilita ao Gerente de
Projeto tomar decisões junto aos clientes para que o projeto seja conduzido com
maior controle, reduzindo os problemas inerentes ao desenvolvimento de um
software. O sistema ainda permite ao final do processo um relatório detalhado do
projeto.
38
O Controla possui usuários espalhados por todo o país, cerca de 3000 cópias foram
distribuídas. Uma versão multi-usuário para ambiente Web está sendo desenvolvida,
que possibilitará a colaboração on-line para equipes de desenvolvimento em
múltiplos projetos, incluindo recursos de fórum de discussão, workflow e
acompanhamento de métricas pré-estabelecidas (FILHO, REIS, 2007, p. 3).
A análise das ferramentas de apoio ao cálculo de estimativas de projetos de
software teve como objetivo o entendimento e a comparação das semelhanças e
diferenças entre as ferramentas.
Assim como o SISPCU, U-EST e o Controla, a ferramenta proposta também auxilia
ao gerente de projeto uma melhor estimativa do projeto de software, permitindo a ele
mensurar com maior segurança e com uma taxa menor de erros o tempo e esforço
de um determinado projeto. Ainda permite a melhoria do processo de
desenvolvimento de software e conseqüentemente do produto gerado.
Assim como a U-EST, a ferramenta proposta permite uma automatização do
processo de classificação dos atores e casos de uso quanto a sua complexidade.
Permite também ao final do processo do cálculo um relatório detalhado das
informações envolvidas no cálculo do esforço, permitindo um maior controle por
parte do gerente, assim como na ferramenta Controla.
A ferramenta proposta não permite a inserção de funcionários e cargos no sistema,
diferente da ferramenta SISPCU, porém permite a importação do diagrama de casos
de uso através de um arquivo XMI, para evitar o retrabalho do gerente do projeto.
3.3 CONSIDERAÇÕES FINAIS Este capítulo apresentou os requisitos funcionais do sistema dando uma breve
descrição dos casos de uso. Abordou também algumas ferramentas de estimativas
de projetos de software, suas vantagens e desvantagens, e uma comparação com a
ferramenta proposta. No próximo capítulo será abordada a análise orientada a
objetos do projeto.
39
4 ANÁLISE Este capítulo aborda a Análise Orientada a Objetos da ferramenta proposta. A
Análise Orientada a Objeto será feita utilizando a Linguagem de Modelagem
Unificada (UML – Unified Modeling Language), na qual serão apresentados os
produtos gerados durante o processo de Análise. A modelagem de classes é
discutida na seção 4.1. A seção 4.2 apresenta a modelagem do comportamento
através dos diagramas de seqüência.
4.1 MODELAGEM DE CLASSES A Figura 13 apresenta o diagrama de classes desenvolvido para a ferramenta
proposta.
40
FIGURA 13 – Diagrama de Classe da ferramenta proposta.
41
A classe Projeto permite ao gerente cadastrar um determinado projeto que se
relaciona com a classe Fator, que é responsável por armazenar os fatores de
complexidade técnica e ambiental do projeto. A classe Projeto também se relaciona
com a classe DiagramaCasoUso, que armazena os diagramas de caso de uso de
um projeto. A classe DiagramaCasoUso se relaciona com Ator para registrar os
atores dos casos de uso e também se relaciona com CasoUso para registrar as
descrições dos casos de uso. A classe Ator se relaciona com ComplexidadeAtor,
que é uma subclasse da superclasse Complexidade. A mesma situação acontece
com a classe CasoUso, que se relaciona com ComplexidadeCasoUso, que
também é uma subclasse da superclasse Complexidade. A classe CasoUso se
relaciona também com Curso, que é uma superclasse e possui duas subclasses
que são CursoNormal e CursoAlternativo relativos à descrição dos casos de uso.
A subclasse CursoNormal registra as descrições dos casos normais do caso de
uso. Já a subclasse CursoAlternativo registra as descrições dos casos alternativos
do caso de uso. A superclasse Curso é associada à classe Transação, que é
responsável por armazenar as transações do caso de uso. A classe Transação se
relaciona com CursoAlternativo para registrar as transações do CursoAlternativo.
O Quadro 6 apresenta o Dicionário de Dados referentes às classes do Diagrama de
classes do projeto, bem como a Lista de Restrições de Integridade.
42
DICIONÁRIO DE DADOS
Classe Atributo
Obrigato rieda
de (S/N)
Descrição Valores
Possíveis
Projeto
código S Código de identificação do Projeto
nome S Nome do Projeto
descrição S Descrição do Projeto
dataInicio S Data de Inicio do Projeto
dataFim S Data de Termino do Projeto
horasPCU S Horas de Trabalho por Pontos de Caso de Uso
Fator
descrição S Descrição do Fator de Ajuste
peso S Peso do Fator de Ajuste
tipo S Tipo do Fator de Ajuste Técnico, Ambiental
FatorProjeto relevância S Relevância do Fator de
Ajuste
DiagramaCasoU
so
nome S Nome do Diagrama
descrição S Descrição
CasoUso
nome S Nome do Caso de Uso
descrição S Descrição do Caso de Uso
gatilho S Dispara o Caso de Uso
requisitoEspecial N
Descrição das Funcionalidades não Descrita nos Casos de Uso
43
DICIONÁRIO DE DADOS
Classe Atributo
Obrigato rieda
de (S/N)
Descrição Valores
Possíveis
preCondicao N Precondições para Inicio do Caso de Uso
posCondicao N Poscondicoes ao Termino do Caso de Uso
pontosExtensao N Descrição dos Casos de Uso de Extensão do Diagrama
Ator nome S Nome do Ator
descricao S Descrição do Ator
Complexidade
descricao S Descrição da Complexidade
definicao S Definição da Complexidade
peso S Peso das Complexidades
RelacionamentoCasoUso
tipo S Tipo do Relacionamento do Caso de Uso
Extende, Include
Curso nome S Nome dos Fluxos
descricao S Descrição do Curso
Transação
descricao S Descrição da Transação
ordem S Ordem do Curso
tipo S Tipo da Transação
Evento, Resposta do Sistema, Passo Complemantar
LISTA DE RESTRIÇÃO DE INTEGRIDADE
R1 = Somente transações relacionadas ao curso normal podem ser associados a algum curso alternativo.
QUADRO 6 – Dicionário de Dados da ferramenta proposta
44
4.2 DIAGRAMAS DE SEQÜÊNCIA A seguir serão apresentados os diagramas de seqüência construídos para mostrar
como os objetos colaboram para a execução de alguns casos de uso descritos
anteriormente no capítulo 3.
As Figuras 14, 15, 16 apresentam respectivamente os diagramas de seqüência
IncluirProjeto, IncluirCasoUso e IncluirAtor. O diagrama de seqüência IncluirProjeto
tem como objetivo a inclusão de um projeto para ser estimado. O diagrama
incluirCasoUso é responsável pela inclusão dos casos de uso do projeto. Já o
diagrama incluirAtor é responsável pela inclusão dos atores envolvidos no projeto.
FIGURA 14 – Diagrama de Seqüência IncluirProjeto.
45
FIGURA 15 – Diagrama de Seqüência IncluirCasoUso.
46
FIGURA 16 – Diagrama de Seqüência IncluirAtor.
47
As Figuras 17, 18, 19 apresentam respectivamente os diagramas de seqüência
IncluirPesoComplexAtor, IncluirPesoComplexCasoUso e CalcularEstimativa. O
diagrama IncluirPesoComplexAtor tem como objetivo incluir o peso dos atores do
projeto. O diagrama IncluirPesoComplexCasoUso é responsável por incluir o peso
dos casos de uso do projeto. Já o diagrama de seqüência CalcularEstimativa, que
tem como objetivo efetuar o cálculo de estimativa do projeto selecionado.
FIGURA 17 – Diagrama de Seqüência IncluirPesoComplexAtor.
48
FIGURA 18 – Diagrama de Seqüência IncluirPesoComplexCasoUso.
49
FIGURA 19 – Diagrama de Seqüência CalcularEstimativa.
50
4.3 CONSIDERAÇÕES FINAIS Este capítulo apresentou a Análise Orientada a Objetos da ferramenta proposta. No
próximo capítulo serão apresentados o projeto e a implementação do sistema.
51
5 PROJETO E IMPLEMENTAÇÃO Este capítulo aborda o projeto orientado a objeto e a implementação da ferramenta
para estimativa de tempo/esforço utilizando o método de pontos por caso de uso.
5.1 PROJETO Nesta seção são descritos o projeto da ferramenta “UCPCalc”. Na seção 5.1.1
apresenta o projeto de interface da ferramenta. A seção 5.1.2 contém o projeto de
banco de dados.
5.1.1 Projeto de Arquitetura do Sistema O projeto de Arquitetura do Sistema é apresentado na Figura 20.
Estações de Trabalho
Servidor de Banco de Dados
Arquitetura Cliente/Servidor
FIGURA 20 – Arquitetura Cliente-Servidor.
A arquitetura utilizada pela ferramenta proposta será a arquitetura Cliente/Servidor.
Esta arquitetura se divide em duas partes claramente diferenciadas, a primeira é a
parte do servidor e a segunda a de um conjunto de clientes “estações de trabalho”.
52
Os servidores são entidades passivas, pois apenas respondem a requisições
enviadas pelos clientes, após seu processamento específico. Os clientes são
entidades ativas, que submetem suas requisições aos servidores e, geralmente,
implementam a interface com o usuário final do serviço.
Podemos dizer que esta arquitetura necessita de três tipos de software para seu
correto funcionamento:
Software de gerenciamento de dados: Este software se encarrega da
manipulação e gerenciamento de dados armazenados e requeridos pelas
diferentes aplicações. Normalmente este software se hospeda no servidor.
Software de desenvolvimento: este tipo de software se hospeda nos clientes e
só naqueles que se dediquem ao desenvolvimento de aplicações.
Software de interação com os usuários: Também reside nos clientes e é a
aplicação gráfica de usuário para a manipulação de dados, sempre é claro, a
nível de usuário (consultas principalmente).
5.1.2 Projeto de banco de dados O Projeto de Dados transforma o modelo do domínio do problema criado durante a
análise em estruturas de dados que serão requeridas para a implementação do
software. O modelo do Sistema Gerenciador do Banco de Dados usado no projeto
será o modelo relacional. A Figura 21 apresenta o projeto do Banco de Dados
Relacional para a ferramenta proposta. O Sistema Gerenciador do Banco de Dados
utilizado para armazenar os dados do sistema será o MySQL 5.0 desenvolvido pela
MySQL AB.
53
FIGURA 21 – Diagrama Relacional do Banco de Dados.
54
5.2 IMPLEMENTAÇÃO Esta seção apresenta as tecnologias utilizadas para a construção da ferramenta
proposta, as restrições de implementação e o protótipo da ferramenta.
5.2.1 Tecnologia e linguagem utilizada As tecnologias e linguagens utilizadas para a elaboração da ferramenta foram:
CodeGear RAD Studio 2007, Delphi 2007 for Win32 e o sistema gerenciador de
banco de dados MySQL 5.0.
O CodeGear RAD Studio é composto por Delphi para Win32, C + + Builder e o novo
Delphi for .NET, desenvolvido em um único ambiente integrado. Ele é um ambiente
de desenvolvimento que suporta tanto o desenvolvimento para aplicações nativas
MS-Windows (2000, XP e Vista) quanto .NET. Assim, os desenvolvedores podem
construir aplicações Windows, Web ou cliente / servidor para qualquer uma das três
plataformas. O CodeGear RAD Studio oferece ao desenvolvedor flexibilidade para
os sistemas operacionais que precisam das suas melhores suítes enquanto
desenvolvem para múltiplos sistemas operacionais em Windows, incluindo Windows
Vista e Web.
O Delphi for Win32 é o único IDE que suporta a criação de aplicações de código
nativo compatíveis com Windows 2000, XP e Vista. O Delphi for Win32 não apenas
permite que você desenvolva para as três plataformas, mas também que você
distribua para qualquer delas. Isso cria a flexibilidade de utilizar o sistema
operacional que melhor atenda às suas necessidades, mesmo quando
desenvolvendo para outras plataformas Windows mais populares. O Delphi for
Win32 capacita o desenvolvimento de aplicações suportadas pelo Vista a partir do
familiar ambiente Win32, a fácil criação de aplicações web que suportam AJAX, e
uma dinamizada conectividade a banco de dados corporativos (CODEGEAR, 2008).
O MySQL é um sistema de gerenciamento de banco de dados (SGBD), que utiliza a
linguagem SQL (Structured Query Language - Linguagem de Consulta Estruturada)
55
como interface. É atualmente um dos bancos de dados mais populares, com mais de
6 milhões de instalações pelo mundo (MYSQL BRASIL, 2008).
5.2.2 Restrições de implementação Não foram implementados os casos de uso CadastrarPesoComplexAtor,
CadastrarPesoComplexCasoUso, CadastrarPesoFatComplexTec,
CadastrarPesoFatAmbientais, pois esse trabalho foi desenvolvido como um
projeto de conclusão de curso, onde o tempo é um fato limitante.
5.2.3 Protótipo da ferramenta A seguir será apresentado o protótipo da ferramenta para estimativa de
tempo/esforço utilizando o método de pontos por caso de uso.
56
A Figura 22 apresenta a tela principal da ferramenta UCPCALC.
FIGURA 22 – Tela principal da ferramenta UCPCALC.
Na tela inicial do sistema existem duas abas principais: Projetos e Configurações.
Na aba Projetos é possível buscar um projeto cadastrado no sistema, preenchendo
as informações nos campos e clicando em Localizar, poderá incluir um novo projeto
através do botão Novo. Através dos botões Excluir e Estimar o usuário poderá
excluir um projeto ou consultar a estimativa, respectivamente.
57
A Figura 23 mostra a tela que é responsável pela configuração dos pesos dos
atores.
FIGURA 23 – Tela de configuração do peso dos Atores.
Na aba Configurações o usuário poderá configurar através de cada aba os seguintes
parâmetros: Peso de cada complexidade dos atores (Figura 23) e Casos de Uso
(Figura 24), o peso de cada Fator de Complexidade Técnica (Figura 25) e o peso de
cada Fator Ambiental (Figura 26). Na aba Peso dos Atores, os pesos para as
complexidades dos atores poderão ser ajustados pelo usuário.
58
A Figura 24 mostra a tela que é responsável pela configuração do peso dos Casos
de Uso.
FIGURA 24 – Tela de configuração do peso dos Casos de Uso.
Na aba Peso dos Casos de Uso, os pesos para as complexidades dos casos de uso
poderão ser ajustados pelo usuário.
59
A Figura 25 mostra a tela que é responsável pela configuração do peso dos Fatores
de Complexidade Técnica.
FIGURA 25 – Tela de configuração dos Fatores de Complexidade Técnica.
Na aba Fatores de Complexidade Técnica, o peso de cada fator de complexidade
técnica poderá ser ajustado pelo usuário.
60
A Figura 26 mostra a tela que é responsável pela configuração do peso dos Fatores
Ambientais.
FIGURA 26 – Tela de configuração dos Fatores Ambientais.
Na aba Fatores Ambientais, o peso de cada fator ambiental poderá ser ajustado pelo
usuário.
61
A Figura 27 mostra a tela que é responsável pelo cadastro de projetos ou pela
importação de arquivos criados em ferramentas de modelagem de dados com
suporte a XMI.
FIGURA 27 – Tela de cadastro de projetos ou importação de arquivo.
Ao clicar no botão Novo na tela inicial o usuário tem acesso a tela de Cadastros de
Projetos. Nessa tela o usuário poderá informar os dados do projeto e através das
abas informar a relevância de cada Fator de Complexidade Técnica (Figura 28), a
relevância de cada Fator Ambiental (Figura 29), cadastrar e classificar os atores
(Figura 30) e cadastrar e classificar os casos de uso (Figura 31).
62
A Figura 28 mostra a tela que é responsável pela definição das relevâncias dos
fatores de complexidade técnica de um projeto.
FIGURA 28 – Tela de definir Fatores de complexidade Técnica do projeto.
Na aba Fatores de Complexidade Técnica, o usuário deverá determinar a relevância
de cada fator de complexidade técnica do projeto selecionado.
63
A Figura 29 mostra a tela que é responsável pela definição das relevâncias dos
fatores ambientais de um projeto.
FIGURA 29 – Tela de definir Fatores Ambientais do projeto.
Na aba Fatores Ambientais, o usuário deverá determinar a relevância de cada fator
ambiental do projeto selecionado.
64
A Figura 30 mostra a tela que é responsável pela definição dos atores que irão
participar de um projeto.
FIGURA 30 – Tela de definir Atores do projeto.
Na aba Atores o usuário poderá buscar atores já cadastrados no sistema,
informando os parâmetros da busca e clicar no botão Localizar. Clicando no botão
Novo será aberta um nova janela para a inserção do ator (Figura 31) . O usuário
poderá excluir um ator cadastrado selecionado ele na lista e clicando no botão
Excluir.
65
A Figura 31 mostra a tela que é responsável pela inclusão do ator.
FIGURA 31 – Tela de Inclusão de Ator.
Nesta tela, o usuário preenche ou altera as informações referentes ao ator
selecionado.
66
A Figura 32 mostra a tela que é responsável pela definição dos Casos de Uso de um
projeto.
FIGURA 32 – Tela de definir Casos de Uso do projeto.
Na aba Casos de Uso, o usuário poderá buscar casos de uso já cadastrados no
sistema informando os parâmetros da busca e clicando no botão Localizar. Ao clicar
no botão Inserir uma nova janela será aberta para a inserção do caso de uso (Figura
33) . Ao selecionar um caso de uso na lista e clicar no botão Excluir o caso de uso
será apagado do sistema.
67
A Figura 33 mostra a tela que é responsável pela inclusão do Caso de Uso.
FIGURA 33 – Tela de Inclusão de Caso de Uso.
Nesta tela, o usuário preenche ou altera as informações referentes ao caso de uso
selecionado. Na aba Caso de Uso, o usuário informa nome, complexidade,
descrição, gatilho, requisitos especiais, pré-condição, pós-condição e pontos de
extensão.
68
A Figura 34 mostra a tela que é responsável inclusão e visualização dos fluxos
normais.
FIGURA 34 – Tela de Inclusão do Fluxo Normal.
Na aba Fluxo Normal, o usuário deverá descrever os passos do fluxo normal.
69
A Figura 35 mostra a tela que é responsável pela inclusão e visualização dos fluxos
Alternativos.
FIGURA 35 – Tela de Inclusão do Fluxo Alternativo.
Na aba Fluxo Alternativo o usuário poderá cadastrar os fluxo alternativos do caso de
uso selecionando o tipo do fluxo e a qual passo normal ele está associado. Será
possível a navegação em cada fluxo normal através dos botões na parte superior da
tela.
70
A Figura 36 mostra a tela que é responsável pela importação dos projetos com
extensão XMI. Visualizando a aba Atores.
FIGURA 36 – Tela de importação de projetos aba Atores.
Nessa tela, o usuário fará a importação do arquivo XMI e verificará através das abas
Atores e Casos de Uso (Figura 37) o que foi importado. Na aba Atores, os atores
encontrado no arquivos XMI serão exibidos.
71
A Figura 37 mostra a tela que é responsável pela importação dos projetos com
extensão XMI. Visualizando a aba Casos de Uso.
FIGURA 37 – Tela de importação de projetos aba Caso de Uso.
Na aba Casos de Uso, os casos de uso encontrados no arquivo XMI serão exibidos.
72
A Figura 38 mostra a tela que é responsável pela exibição da estimativa do projeto.
FIGURA 38 – Tela de Exibição da Estimativa do Projeto.
Ao clicar no botão Estimar na tela principal, o sistema exibe uma janela com as
informações da estimativa e as varíaveis utilizadas e geradas para o cálculo.
73
5.2.4 Instalação e funcionamento do protótipo Para executar o UCPCalc é necessário ter instalado no computador a última versão
do banco de dados MySQL. Após a instalação do banco é necessária a configuração
do banco. Primeiro é necessário a criação de um usuário no banco de dado com o
usuário “ucpcalc” e senha “mysql”, e é necessário dar todas as permissões ao
mesmo. Após a configuração é necessária a instalação do pacote msxml4.msi, pois
o mesmo permite a importação do arquivo com extensão XML para o sistema.
Depois de executar os passos acima será possível a execução do sistema UCPCalc.
5.3 CONSIDERAÇÕES FINAIS Este capítulo apresentou o Projeto e a Implementação da ferramenta UCPCalc
proposta. No próximo capítulo serão apresentadas as conclusões e perspectivas
futuras deste trabalho.
74
6 CONCLUSÕES E PERSPECTIVAS FUTURAS No mercado atual, uma das grandes preocupações das empresas é o cumprimento
de prazos e cronogramas de seus projetos de desenvolvimento de software. Tanto o
prazo quanto o custo dependem, dentre outros, de um planejamento efetivo do
projeto.
Com isso, em um mercado tão competitivo, é indispensável a existência de apoio
automatizado que auxilie no processo de planejamento de sistemas, para não
extrapolar custos e prazos.
Diante dessa necessidade, foi implementada UCPCalc - uma ferramenta para
estimativa de tempo e esforço de um projeto de software baseada em pontos por
caso de uso, estimativas essas que podem, então, ser geradas na fase de
levantamento de requisitos.
Essas estimativas podem ser cada vez mais apuradas e precisas, pois com
UCPCalc é possível manter um histórico de estimativas de projetos anteriores.
Este trabalho demonstrou a viabilidade de apoiar, de forma automatizada, o cálculo
de estimativa de tempo e esforço de projeto de software, durante a engenharia de
requisitos de software, utilizado pontos por caso de uso, de forma a antecipar o
início do estudo de viabilidade.
Algumas dificuldades em relação ao método foram levantadas. Uma das mais
agravantes é que não existe uma maneira padronizada de descrever os casos de
uso, o que torna o cálculo um pouco mais complicado. Por isso, foi adotada a forma
de descrição de casos de uso proposta por Cockburn (2000).
Tendo em vista que este trabalho foi desenvolvido como um projeto de conclusão de
curso, onde o tempo é um fato limitante, podem ser citadas como perspectivas
futuras da ferramenta dentre outras:
associar à ferramenta um analisador léxico e morfológico da língua portuguesa,
com o intuito de classificar os atores e casos de uso de um caso de uso.
implementar alguns relatórios que mostrem dados de projetos já analisados.
implementar uma comparação do projeto atual com projetos anteriores.
75
REFERÊNCIAS ANDRADE, E. L. P. Pontos de Caso de Uso e Pontos de Função na gestão de estimativa de tamanho de projetos de software orientados a objetos. 2004. 143f. Dissertação (Mestrado em Gestão do Conhecimento e Tecnologia da Informação) – Universidade Católica de Brasília, Brasília.
BOOCH, G.; RUMBAUGH, J.; JACOBSON, I. UML: guia do usuário. Tradução por Fábio Freitas da Silva. Rio de Janeiro: Ed. Campos, 2000. 482 p.
COCKBURN, A. Writing Effective Use Cases. New Jersey: Addison-Wesley Professional, 2000, 304 p.
CODEGEAR RAD Studio 2007. On-line. Disponível em: <http://www.codegear.com/br/products/radstudio>. Acesso em: 13 mai. 2008.
COHN, M. Estimating with use case points. Methods & Tools. Vevey, v. 13, n. 3, p. 3-13, set. - dez. 2005.
CORTELETTI, J.; SANTOS, M. Realização de Estimativas utilizando Pontos por Caso de Uso. 2005. 132 f. Trabalho de Conclusão de Curso (Graduação em Sistemas de Informação) – Faculdade Vitoriana de Tecnologia, Vitória, 2005.
FILHO, C. V. F.; REIS, J. M. dos. Controla: ferramenta de apoio ao processo de desenvolvimento de software em pequenas empresas. Faculdade de Viçosa, 07 f. 2006
KARNER, G. Resource Estimation for Objectory. 1993. On-line. Disponível em: <http://www.bfpug.com.br>. Acesso em: 22 fev. 2008.
KOIRALA, S. How to Prepare Software Quotation. 2004. On-line. Disponível em: <http://k.1asphost.com/UseCasePoints/UseCasePoints.pdf>. Acesso em: 22 fev. 2008.
KUSUMOTO, S. et al. Efort Estimation Tool Based on Use Case Points Method. 2005. 08 f. Graduate School of Information Science and Technology, Osaka University, Osaka, Japão, 2005.
MYSQL BRASIL. On-line. Disponível em: <http://www.mysqlbrasil.com.br>. Acesso em: 13 mai. 2008.
PRESSMAN, R. S. Engenharia de software. 6. ed. Tradução por José Carlos Barbosa dos Santos. São Paulo: Makron Books, 2006. 752 p.
RIBU, K. Estimating Object-Oriented Software Projects with Use Cases. 2001.147f. Dissertação (Master of Science Thesis) - University of Oslo, Oslo.
ROCHA, C. M. Explorando o relacionamento entre métricas baseadas em caso de uso e o número de casos de teste. 2005. 81f. Dissertação (Mestrado em Informática) – Setor de Ciências Exatas, Universidade Federal do Paraná, Curitiba.
76
WAZLAWICK, R. S. Análise e projeto de sistemas de informação orientados a objetos. Rio de Janeiro: Elsevier, 2004. 298 p.
77
ANEXOS
78
Principal
Projeto: Sistema de Cálculo de Pontos por Caso de Uso
Sub-Sistema:
Nome do Caso de Uso: Principal
Descrição: O caso de uso Principal tem como objetivo gerenciar os projetos que
serão estimados por pontos de caso de uso através dos atores e casos de uso dos
diagramas de caso de uso contidos no projeto.
O Sistema de Cálculo de Pontos por Caso de Uso possui os seguintes atores:
Gerente de Projeto: gerente do projeto responsável por realizar as
estimativas;
Engenheiro de Software: analista de sistema responsável pelo levantamento
de requisitos.
79
Gerenciar Projetos
Projeto: Sistema de Cálculo de Pontos por Caso de Uso
Sub-Sistema: Principal
Nome do Caso de Uso: Gerenciar Projetos
Descrição: O caso de uso Gerenciar Projetos tem como objetivo cadastrar os
projetos que serão estimados, os fatores de complexidade técnica e os fatores
ambientais relevantes para o projeto.
80
Cadastrar Projetos
Projeto: Sistema de Cálculo de Pontos por Caso de Uso
Sub-Sistema: Gerenciar Projetos
Nome do Caso de Uso: Cadastrar Projetos
1. Caso de Uso: ConsultarProjeto.
1.1. Breve Descrição
O caso de uso Consultar Projeto tem como objetivo visualizar os projetos já
cadastrados no sistema.
1.2. Atores
Gerente de Projeto e Engenheiro de Software
1.3. Gatilho
Gerente de Projeto seleciona a opção na interface do sistema.
2. Fluxo de Eventos
2.1. Fluxo Normal
1. O gerente de projeto seleciona o projetor a ser consultado.
2. O sistema exibe as informações referentes ao projeto consultado.
2.2. Fluxo Alternativo
Não possui.
3. Requisitos especiais
Não possui.
4. Pré-Condição
O projeto deve existir no banco de dados do sistema.
5. Pós-condições
Não possui.
6. Pontos de extensão
Não possui.
81
1. Caso de Uso: Incluir Projeto.
1.1. Breve Descrição
O caso de uso Incluir Projeto tem como objetivo registrar os projetos que
serão estimados pelo software.
1.2. Atores
Gerente de Projeto.
1.3. Gatilho
Gerente de Projeto seleciona a opção na interface do sistema.
2. Fluxo de Eventos
2.1. Fluxo Normal
1. O gerente de projeto entra com os dados do projeto.
2. O sistema valida os dados inseridos.
2.2. Fluxo Alternativo
2.a. Caso o gerente de projeto tenha deixado de preencher algum campo ou
tenha preenchido com algum dado invalido o sistema retornara uma
mensagem de erro.
3. Requisitos especiais
Não possui.
4. Pré-Condição
Não possui.
5. Pós-condições
Após a validação dos dados pelo sistema, o mesmo é inserido no banco de
dados do sistema.
6. Pontos de extensão
Não possui.
82
1. Caso de Uso: AlterarProjeto.
1.1. Breve Descrição
O caso de uso Alterar Projeto tem como objetivo alterar as informações
referentes a algum projeto já cadastrado anteriormente.
1.2. Atores
Gerente de Projeto.
1.3. Gatilho
Gerente de Projeto seleciona a opção na interface do sistema.
2. Fluxo de Eventos
2.1. Fluxo Normal
1. O Gerente de Projetos seleciona o projeto a ser alterado.
2. O Gerente de Projeto faz as alterações necessárias.
3. O sistema valida os dados alterados.
2.2. Fluxo Alternativo
3.a. Caso o gerente de projeto tenha alterado algum campo com dados
inválidos ou deixado de preencher o sistema retornara uma mensagem de
erro.
3. Requisitos especiais
Não possui.
4. Pré-Condição
O projeto deve existir no banco de dados do sistema.
5. Pós-condições
Após a validação dos dados pelo o sistema, os dados são alterados.
6. Pontos de extensão
Não possui.
83
1. Caso de Uso: ExcluirProjeto.
1.1. Breve Descrição
O caso de uso Excluir Projeto tem como objetivo excluir um projeto inserido
anteriormente.
1.2. Atores
Gerente de Projeto.
1.3. Gatilho
Gerente de Projeto seleciona a opção na interface do sistema.
2. Fluxo de Eventos
2.1. Fluxo Normal
1. O gerente de projeto seleciona o projeto a ser excluído.
2. O sistema pede a confirmação da exclusão.
2.2. Fluxo Alternativo
Não possui.
3. Requisitos especiais
Não possui.
4. Pré-Condição
O projeto deve existir no banco de dados do sistema.
5. Pós-condições
Após a confirmação da exclusão, o projeto é excluído do banco de dados do
sistema.
6. Pontos de extensão
Não possui.
84
CadastrarRelFatComplexTecProjeto
Projeto: Sistema de Cálculo de Pontos por Caso de Uso
Sub-Sistema: Gerenciar Projetos
Nome do Caso de Uso: CadastrarRelFatComplexTecProjeto
1. Caso de Uso: ConsultarRelevanciaFatoresComplexTecnica.
1.1. Breve Descrição
O caso de uso Consultar Relevância dos Fatores de Complexidade Técnica
tem como objetivo visualizar as informações das relevâncias dos fatores
técnicos do projeto.
1.2. Atores
Gerente de Projeto e Engenheiro de Software.
1.3. Gatilho
Gerente de Projeto seleciona a opção na interface do sistema.
2. Fluxo de Eventos
2.1. Fluxo Normal
1. O gerente de projeto seleciona a relevância a ser consultado.
2. O sistema exibe as informações da relevância dos fatores de
complexidade técnica.
2.2. Fluxo Alternativo
Não possui.
3. Requisitos especiais
Não possui.
4. Pré-Condição
As relevâncias devem estar cadastras no banco de dados do sistema.
5. Pós-condições
Não possui.
6. Pontos de extensão
Não possui.
85
1. Caso de Uso: IncluirRelevanciaFatoresComplexTecnica.
1.1. Breve Descrição
O caso de uso Incluir Relevância dos Fatores de Complexidade Técnica tem
como objetivo registrar o grau de relevância dos fatores de complexidade
técnica do projeto.
1.2. Atores
Gerente de Projeto.
1.3. Gatilho
Gerente de Projeto seleciona a opção na interface do sistema.
2. Fluxo de Eventos
2.1. Fluxo Normal
1. O gerente de projeto entra com os dados da relevância dos fatores de
complexidade técnica do projeto.
2. O sistema valida os dados inseridos.
2.2. Fluxo Alternativo
2.a. Caso o gerente de projeto tenha deixado de preencher algum campo ou
tenha preenchido com algum dado invalido o sistema retornara uma
mensagem de erro.
3. Requisitos especiais
Não possui.
4. Pré-Condição
Não possui.
5. Pós-condições
Após a validação dos dados pelo sistema, o mesmo é inserido no banco de
dados do sistema.
6. Pontos de extensão
Não possui.
86
1. Caso de Uso: AlterarRelevanciaFatoresComplexTecnica.
1.1. Breve Descrição
O caso de uso Alterar Relevância dos Fatores de Complexidade Técnica tem
como objetivo alterar as informações referente a relevância técnica já
cadastrado anteriormente.
1.2. Atores
Gerente de Projeto.
1.3. Gatilho
Gerente de Projeto seleciona a opção na interface do sistema.
2. Fluxo de Eventos
2.1. Fluxo Normal
1. O Gerente de Projetos seleciona a relevância a ser alterada.
2. O Gerente de Projeto faz as alterações necessárias.
3. O sistema valida os dados alterados.
2.2. Fluxo Alternativo
3.a. Caso o gerente de projeto tenha alterado algum campo com dados
inválidos ou deixado de preencher o sistema retornara uma mensagem de
erro.
3. Requisitos especiais
Não possui.
4. Pré-Condição
A relevância deve existir no banco de dados do sistema.
5. Pós-condições
Após a validação dos dados pelo o sistema, os dados são alterados.
6. Pontos de extensão
Não possui.
1. Caso de Uso: ExcluirRelevanciaFatoresComplexTecnica.
1.1. Breve Descrição
87
O caso de uso Excluir Relevância dos Fatores de Complexidade Técnica tem
como objetivo excluir o grau de relevância dos fatores de complexidade
técnica.
1.2. Atores
Gerente de Projeto.
1.3. Gatilho
Gerente de Projeto seleciona a opção na interface do sistema.
2. Fluxo de Eventos
2.1. Fluxo Normal
1. O gerente de projeto seleciona o grau da relevância a ser excluída.
2. O sistema pede a confirmação da exclusão.
2.2. Fluxo Alternativo
Não possui.
3. Requisitos especiais
Não possui.
4. Pré-Condição
A relevância deve existir no banco de dados do sistema.
5. Pós-condições
Após a confirmação da exclusão, o grau da relevância é excluído do banco de
dados do sistema.
6. Pontos de extensão
Não possui.
88
CadastrarRelFatAmbientaisProjeto
Projeto: Sistema de Cálculo de Pontos por Caso de Uso
Sub-Sistema: Gerenciar Projetos
Nome do Caso de Uso: CadastrarRelFatAmbientaisProjeto
1. Caso de Uso: ConsultarRelevanciaFatoresAmbientais.
1.1. Breve Descrição
O caso de uso Consultar Relevância dos Fatores Ambientais tem como
objetivo visualizar as informações das relevâncias dos fatores ambientais do
projeto.
1.2. Atores
Gerente de Projeto e Engenheiro de Software.
1.3. Gatilho
Gerente de Projeto seleciona a opção na interface do sistema.
2. Fluxo de Eventos
2.1. Fluxo Normal
1. O gerente de projeto seleciona a relevância a ser consultado.
2. O sistema exibe as informações da relevância ambiental.
2.2. Fluxo Alternativo
Não possui.
3. Requisitos especiais
Não possui.
4. Pré-Condição
As relevâncias devem estar cadastras no banco de dados do projeto.
5. Pós-condições
Não possui.
6. Pontos de extensão
Não possui.
89
1. Caso de Uso: IncluirRelevanciaFatoreAmbientais.
1.1. Breve Descrição
O caso de uso Incluir Relevância dos Fatores Ambientais tem como objetivo
registrar o grau de relevância dos fatores de complexidade técnica.
1.2. Atores
Gerente de Projeto.
1.3. Gatilho
Gerente de Projeto seleciona a opção na interface do sistema.
2. Fluxo de Eventos
2.1. Fluxo Normal
1. O gerente de projeto entra com os dados das relevâncias ambientais do
projeto.
2. O sistema valida os dados inseridos.
2.2. Fluxo Alternativo
2.a. Caso o gerente de projeto tenha deixado de preencher algum campo ou
tenha preenchido com algum dado invalido o sistema retornara uma
mensagem de erro.
3. Requisitos especiais
Não possui.
4. Pré-Condição
Não possui.
5. Pós-condições
Após a validação dos dados pelo sistema, o mesmo é inserido no banco de
dados do sistema.
6. Pontos de extensão
Não possui.
90
1. Caso de Uso: AlterarRelevanciaFatoresAmbientais.
1.1. Breve Descrição
O caso de uso Alterar Relevância dos Fatores Ambientais tem como objetivo
alterar as informações referente a relevância dos fatores ambientais já
cadastrado anteriormente.
1.2. Atores
Gerente de Projeto.
1.3. Gatilho
Gerente de Projeto seleciona a opção na interface do sistema.
2. Fluxo de Eventos
2.1. Fluxo Normal
1. O Gerente de Projetos seleciona a relevância a ser alterada.
2. O Gerente de Projeto faz as alterações necessárias.
3. O sistema valida os dados alterados.
2.2. Fluxo Alternativo
3.a. Caso o gerente de projeto tenha alterado algum campo com dados
inválidos ou deixado de preencher o sistema retornara uma mensagem de
erro.
3. Requisitos especiais
Não possui.
4. Pré-Condição
A relevância deve existir no banco de dados do sistema.
5. Pós-condições
Após a validação dos dados pelo o sistema, os dados são alterados.
6. Pontos de extensão
Não possui.
91
1. Caso de Uso: ExcluirRelevanciaFatoreAmbientais.
1.1. Breve Descrição
O caso de uso Excluir Relevância dos Fatores Ambientais tem como objetivo
excluir o grau de relevância dos fatores ambientais.
1.2. Atores
Gerente de Projeto.
1.3. Gatilho
Gerente de Projeto seleciona a opção na interface do sistema.
2. Fluxo de Eventos
2.1. Fluxo Normal
1. O gerente de projeto seleciona o grau da relevância a ser excluída.
2. O sistema pede a confirmação da exclusão.
2.2. Fluxo Alternativo
Não possui.
3. Requisitos especiais
Não possui.
4. Pré-Condição
A relevância deve existir no banco de dados do sistema.
5. Pós-condições
Após a confirmação da exclusão, o grau da relevância é excluído do banco de
dados do sistema.
6. Pontos de extensão
Não possui.
92
1. Caso de Uso: ConsultarDadosHistoricos.
1.1. Breve Descrição
O caso de uso Consultar Dados Históricos tem como objetivo consultar os
projetos estimados anteriormente para usá-los como referência para
estimativas futuras e na determinação do fator de produtividade.
1.2. Atores
Gerente de Projeto.
1.3. Gatilho
Gerente de Projeto seleciona a opção na interface do sistema.
2. Fluxo de Eventos
2.1. Fluxo Normal
1. O gerente de projeto seleciona os dados históricos de um projeto a ser
consultado.
2. O sistema exibe as informações dos dados históricos do projeto.
2.2. Fluxo Alternativo
Não possui.
3. Requisitos especiais
Não possui.
4. Pré-Condição
O projeto deve ter sua estimativa já concluída anteriormente.
5. Pós-condições
Não possui.
6. Pontos de extensão
Não possui.
93
Gerenciar Dados Gerais
Projeto: Sistema de Cálculo de Pontos por Caso de Uso
Sub-Sistema: Principal
Nome do Caso de Uso: Gerenciar Dados Gerais
Descrição: O caso de uso Gerenciar Dados Gerais tem como objetivo registrar as informações de apoio ao cálculo realizado pelo sistema.
94
Gerenciar Peso de Complexidade do Ator
Projeto: Sistema de Cálculo de Pontos por Caso de Uso
Sub-Sistema: Gerenciar Dados Gerais
Nome do Caso de Uso: Gerenciar Peso de Complexidade do Ator
1. Caso de Uso: ConsultarPesoComplexAtor
1.1. Breve descrição
O caso de uso Consultar Peso da Complexidade do Ator tem como objetivo
visualizar o peso de cada complexidade de ator cadastrado no sistema.
1.2. Atores
Gerente de Projeto e Engenheiro de Software.
1.3. Gatilho
Gerente de Projeto seleciona a opção na interface do sistema.
2. Fluxo de Eventos
2.1. Fluxo Normal
1. Gerente de Projeto seleciona a complexidade do ator desejado.
2. O sistema exibe o peso selecionado.
2.2. Fluxo Alternativo
Não possui.
3. Requisitos especiais
Não possui
4. Pré-Condição
Deverá existir alguma complexidade de ator cadastrada no sistema.
5. Pós-condições
Não possui.
6. Pontos de extensão
Não possui.
95
1. Caso de Uso: IncluirPesoComplexAtor
1.1. Breve descrição
O caso de uso Cadastrar Peso da Complexidade do Ator tem como objetivo
registrar o peso de cada complexidade de ator prevista pelo método de
Pontos por Caso de Uso.
1.2. Atores
Gerente de Projeto
1.3. Gatilho
Gerente de Projeto seleciona a opção na interface do sistema.
2. Fluxo de Eventos
2.1. Fluxo Normal
1. O Gerente de Projetos informa o peso da complexidade do ator.
2. O sistema valida os dados inseridos.
2.2. Fluxo Alternativo
1.a. Caso o peso informado seja inválido o sistema exibe um aviso
informando o erro.
3. Requisitos especiais
Não possui.
4. Pré-Condição
Não possui.
5. Pós-condições
Após a validação dos dados pelo o sistema, os dados são armazenados.
6. Pontos de extensão
Não possui.
1. Caso de Uso: AlterarPesoComplexAtor
1.1. Breve descrição
O caso de uso Alterar Peso de Complexidade do Ator tem como objetivo
alterar o peso de complexidade de um caso de uso inserido previamente.
1.2. Atores
Gerente de Projeto
1.3. Gatilho
Gerente de Projeto seleciona a opção na interface do sistema.
2. Fluxo de Eventos
96
2.1. Fluxo Normal
1. O Gerente de Projetos seleciona a complexidade do ator a ser alterado.
2. O Gerente informa o valor do novo peso.
3. O sistema valida os dados inseridos.
2.2. Fluxo Alternativo
1.a. Caso o peso informado seja inválido o sistema exibe um aviso
informando o erro.
3. Requisitos especiais
Não possui.
4. Pré-Condição
Existir uma complexidade de ator cadastrado previamente no sistema.
5. Pós-condições
Após a validação dos dados pelo o sistema, os dados são alterados.
6. Pontos de extensão
Não possui.
97
Gerenciar Peso de Complexidade do Caso de Uso
Projeto: Sistema de Cálculo de Pontos por Caso de Uso
Sub-Sistema: Gerenciar Dados Gerais
Nome do Caso de Uso: Gerenciar Peso de Complexidade do Caso de Uso
1. Caso de Uso: ConsultarPesoComplexCasoUso
1.1. Breve descrição
O caso de uso Consultar Peso da Complexidade do Caso de Uso tem como
objetivo visualizar o peso de cada complexidade de caso de uso cadastrado
no sistema.
1.2. Atores
Gerente de Projeto e Engenheiro de Software.
1.3. Gatilho
Gerente de Projeto seleciona a opção na interface do sistema.
2. Fluxo de Eventos
2.1. Fluxo Normal
1. Gerente de Projeto seleciona a complexidade do caso de uso desejado.
2. O sistema exibe o peso selecionado.
2.2. Fluxo Alternativo
Não possui.
3. Requisitos especiais
Não possui
4. Pré-Condição
Deverá existir alguma complexidade de caso de uso cadastrada no sistema.
5. Pós-condições
Não possui.
6. Pontos de extensão
Não possui.
98
1. Caso de Uso: IncluirPesoComplexCasoUso
1.1. Breve descrição
O caso de uso Cadastrar Peso da Complexidade do Caso de Uso tem como
objetivo registrar o peso de cada complexidade de caso de uso prevista pelo
método de Pontos de Caso de Uso.
1.2. Atores
Gerente de Projeto
1.3. Gatilho
Gerente de Projeto seleciona a opção na interface do sistema.
2. Fluxo de Eventos
2.1. Fluxo Normal
1. O Gerente de Projetos informa o peso da complexidade do caso de uso.
2. O sistema valida os dados inseridos.
2.2. Fluxo Alternativo
1.a. Caso o peso informado seja inválido o sistema exibe um aviso
informando o erro.
3. Requisitos especiais
Não possui.
4. Pré-Condição
Não possui.
5. Pós-condições
Após a validação dos dados pelo o sistema, os dados são armazenados.
6. Pontos de extensão
Não possui.
1. Caso de Uso: AlterarPesoComplexCasoUso
1.1. Breve descrição
O caso de uso Alterar Peso de Complexidade do Caso de Uso tem como
objetivo alterar o peso de complexidade de um caso de uso inserido
previamente.
1.2. Atores
Gerente de Projeto
1.3 Gatilho
Gerente de Projeto seleciona a opção na interface do sistema.
99
2. Fluxo de Eventos
2.1. Fluxo Normal
1. O Gerente de Projetos seleciona a complexidade de caso de uso a ser
alterado.
2. O Gerente informa o valor do novo peso.
3. O sistema valida os dados inseridos.
2.2. Fluxo Alternativo
1.a. Caso o peso informado seja inválido o sistema exibe um aviso
informando o erro.
3. Requisitos especiais
Não possui.
4. Pré-Condição
Existir uma complexidade de caso de uso cadastrado previamente no sistema.
5. Pós-condições
Após a validação dos dados pelo o sistema, os dados são alterados.
6. Pontos de extensão
Não possui.
100
Gerenciar Peso dos Fatores de Complexidades Técnica
Projeto: Sistema de Cálculo de Pontos por Caso de Uso
Sub-Sistema: Gerenciar Dados Gerais
Nome do Caso de Uso: Gerenciar Peso dos Fatores de Complexidade Técnica
1. Caso de Uso: ConsultarPesoFatComplexTecnica
1.1. Breve descrição
O caso de uso Consultar Peso dos Fatores de Complexidade Técnica tem
como objetivo visualizar o peso de cada fator complexidade técnica
cadastrado no sistema.
1.2. Atores
Gerente de Projeto e Engenheiro de Software.
1.3. Gatilho
Gerente de Projeto seleciona a opção na interface do sistema.
2. Fluxo de Eventos
2.1. Fluxo Normal
1. Gerente de Projeto seleciona o fator técnico desejado.
2. O sistema exibe o peso selecionado.
2.2. Fluxo Alternativo
Não possui.
3. Requisitos especiais
Não possui
4. Pré-Condição
Deverá existir um algum fator de complexidade técnica cadastrado no sistema.
5. Pós-condições
Não possui.
6. Pontos de extensão
Não possui.
101
1. Caso de Uso: IncluirPesoFatComplexTecnica
1.1. Breve descrição
O caso de uso Incluir Peso dos Fatores de Complexidade Técnica tem como
objetivo inserir o peso de cada fator complexidade técnica previsto pelo
método de Pontos por Caso de Uso.
1.2. Atores
Gerente de Projeto
1.3. Gatilho
Gerente de Projeto seleciona a opção na interface do sistema.
2. Fluxo de Eventos
2.1. Fluxo Normal
1. O Gerente de Projetos informa o peso do fator de complexidade técnica.
2. O sistema valida os dados inseridos.
2.2. Fluxo Alternativo
1.a. Caso o peso informado seja inválido o sistema exibe um aviso
informando o erro.
3. Requisitos especiais
Não possui.
4. Pré-Condição
Não possui.
5. Pós-condições
Após a validação dos dados pelo o sistema, os dados são armazenados.
6. Pontos de extensão
Não possui.
1. Caso de Uso: AlterarPesoFatComplexTecnica
1.1. Breve descrição
O caso de uso Alterar Peso dos Fatores de Complexidade Técnica tem como
objetivo alterar o peso de um fator complexidade técnica inserido
previamente.
1.2. Atores
Gerente de Projeto
1.3. Gatilho
102
Gerente de Projeto seleciona a opção na interface do sistema.
2. Fluxo de Eventos
2.1. Fluxo Normal
1. O Gerente de Projetos seleciona o fator a ser alterado.
2. O Gerente Informa o valor do novo peso.
3. O sistema valida os dados inseridos.
2.2 Fluxo Alternativo
1.a. Caso o peso informado seja inválido o sistema exibe um aviso
informando o erro.
3. Requisitos especiais
Não possui.
4. Pré-Condição
Existir o fator cadastrado previamente no sistema.
5. Pós-condições
Após a validação dos dados pelo o sistema, os dados são alterados.
6. Pontos de extensão
Não possui.
103
Gerenciar Peso dos Fatores Ambientais
Projeto: Sistema de Cálculo de Pontos por Caso de Uso
Sub-Sistema: Gerenciar Dados Gerais
Nome do Caso de Uso: Gerenciar Peso dos Fatores Ambientais
1. Caso de Uso: ConsultarPesoFatAmbientais
1.1. Breve descrição
O caso de uso Consultar Peso dos Fatores Ambientais tem como objetivo
visualizar o peso de cada fator ambiental cadastrado no sistema.
1.2. Atores
Gerente de Projeto e Engenheiro de Software.
1.3. Gatilho
Gerente de Projeto seleciona a opção na interface do sistema.
2. Fluxo de Eventos
2.1. Fluxo Normal
1. Gerente de Projeto seleciona o fator ambiental desejado.
2. O sistema exibe o peso selecionado.
2.2. Fluxo Alternativo
Não possui.
3. Requisitos especiais
Não possui
4. Pré-Condição
Deverá existir um algum fator ambiental cadastrado no sistema.
5. Pós-condições
Não possui.
6. Pontos de extensão
Não possui.
104
1. Caso de Uso: IncluirPesoFatAmbientais
1.1. Breve descrição
O caso de uso Incluir Peso dos Fatores Ambientais tem como objetivo inserir
o peso de cada fator complexidade técnica previsto pelo método de Pontos
por Caso de Uso.
1.2. Atores
Gerente de Projeto
1.3. Gatilho
Gerente de Projeto seleciona a opção na interface do sistema.
2. Fluxo de Eventos
2.1. Fluxo Normal
1. O Gerente de Projetos informa o peso do fator ambiental.
2. O sistema valida os dados inseridos.
2.2 Fluxo Alternativo
1.a. Caso o peso informado seja inválido o sistema exibe um aviso
informando o erro.
3. Requisitos especiais
Não possui.
4. Pré-Condição
Não possui.
5. Pós-condições
Após a validação dos dados pelo o sistema, os dados são armazenados.
6. Pontos de extensão
Não possui.
1. Caso de Uso: AlterarPesoFatAmbientais
1.1. Breve descrição
O caso de uso Alterar Peso dos Fatores Ambientais tem como objetivo alterar
o peso de um fator ambiental inserido previamente.
1.2. Atores
Gerente de Projeto
1.3. Gatilho
Gerente de Projeto seleciona a opção na interface do sistema.
105
2. Fluxo de Eventos
2.1. Fluxo Normal
1. O Gerente de Projetos seleciona o fator ambiental a ser alterado.
2. O Gerente informa o valor do novo peso.
3. O sistema valida os dados inseridos.
2.2. Fluxo Alternativo
1.a. Caso o peso informado seja inválido o sistema exibe um aviso
informando o erro.
3. Requisitos especiais
Não possui.
4. Pré-Condição
Existir o fator ambiental cadastrado previamente no sistema.
5. Pós-condições
Após a validação dos dados pelo o sistema, os dados são alterados.
6. Pontos de extensão
Não possui.
106
Gerenciar Diagrama de Caso de Uso
Projeto: Sistema de Cálculo de Pontos por Caso de Uso
Sub-Sistema: Principal
Nome do Caso de Uso: Gerenciar Diagrama de Caso de Uso
107
Gerenciar Ator
Projeto: Sistema de Cálculo de Pontos por Caso de Uso
Sub-Sistema: Gerenciar Diagrama de Caso de Uso
Nome do Caso de Uso: Gerenciar Ator
1. Caso de Uso: ConsultarAtor
1.1. Breve descrição
O caso de uso Consultar Ator tem como objetivo visualizar as informações
dos atores de casos de uso.
1.2. Atores
Gerente de Projeto e Engenheiro de Software
1.3. Gatilho
Gerente de Projeto/Engenheiro de Software seleciona a opção na interface do
sistema.
2. Fluxo de Eventos
2.1. Fluxo Normal
1. O Gerente de Projeto/Engenheiro de Software seleciona um ator a ser
visualizado.
2. O sistema exibe as informações do ator selecionado.
2.2. Fluxo Alternativo
Não possui.
3. Requisitos especiais
Não possui.
4. Pré-Condição
Existir um ator cadastrado previamente no sistema.
5. Pós-condições
Não possui.
6. Pontos de extensão
Não possui.
108
1. Caso de Uso: IncluirAtor
1.1. Breve descrição
O caso de uso Incluir Ator tem como objetivo registrar os atores dos casos de
uso.
1.2. Atores
Gerente de Projeto e Engenheiro de Software
1.3. Gatilho
Gerente de Projeto/Engenheiro de Software seleciona a opção na interface do
sistema.
2. Fluxo de Eventos
2.1. Fluxo Normal
1. O Gerente de Projeto/Engenheiro de Software informa os dados do ator.
2. O sistema valida os dados inseridos.
2.2. Fluxo Alternativo
Não possui.
3. Requisitos especiais
Não possui.
4. Pré-Condição
Não possui.
5. Pós-condições
Após a validação dos dados, o sistema armazena as informações.
6. Pontos de extensão
Não possui.
1. Caso de Uso: AlterarAtor
1.1. Breve descrição
O caso de uso Alterar Ator tem como objetivo alterar um ator inserido
previamente.
1.2. Atores
Gerente de Projeto e Engenheiro de Software
1.3. Gatilho
Gerente de Projeto/Engenheiro seleciona a opção na interface do sistema.
2. Fluxo de Eventos
2.1. Fluxo Normal
109
1. O Gerente de Projeto/Engenheiro seleciona o ator a ser alterado.
2. O Gerente de Projeto/Engenheiro informa os dados a serem alterados.
3. O sistema valida os dados inseridos.
2.2. Fluxo Alternativo
1.a. Caso os dados informados sejam inválidos o sistema exibe um aviso
informando o erro.
3. Requisitos especiais
Não possui.
4. Pré-Condição
Existir o ator cadastrado previamente no sistema.
5. Pós-condições
Após a validação dos dados pelo o sistema, os dados são alterados.
6. Pontos de extensão
Não possui.
1. Caso de Uso: ExcluirAtor
1.1. Breve descrição
O caso de uso Excluir Ator tem como objetivo excluir um ator inserido
previamente.
1.2. Atores
Gerente de Projeto e Engenheiro de Software
1.3. Gatilho
Gerente de Projeto/Engenheiro seleciona a opção na interface do sistema.
2. Fluxo de Eventos
2.1. Fluxo Normal
1. O Gerente de Projeto/Engenheiro excluir o ator desejado.
2. O sistema pede a confirmação da exclusão.
2.2. Fluxo Alternativo
1.a. Caso os o ator a ser excluído estiver vinculado a um caso de uso o
sistema exibe um aviso informando o erro.
3. Requisitos especiais
Não possui.
4. Pré-Condição
Existir o ator cadastrado previamente no sistema.
110
O ator não pode estar vinculado a um caso de uso.
5. Pós-condições
Após a confirmação da exclusão, os dados do ator são apagados do sistema.
6. Pontos de extensão
Não possui.
111
Gerenciar Casos de Uso
Projeto: Sistema de Cálculo de Pontos por Caso de Uso
Sub-Sistema: Gerenciar Diagrama de Caso de Uso
Nome do Caso de Uso: Gerenciar Casos de Uso
1. Caso de Uso: ConsultarCasoUso
1.1. Breve descrição
O caso de uso Consultar Caso de Uso tem como objetivo visualizar as
informações dos casos de uso do projeto.
1.2. Atores
Gerente de Projeto e Engenheiro de Software
1.3. Gatilho
Gerente de Projeto/Engenheiro de Software seleciona a opção na interface do
sistema.
2. Fluxo de Eventos
2.1. Fluxo Normal
1. O Gerente de Projeto/Engenheiro de Software seleciona um caso de uso a
ser visualizado.
2. O sistema exibe as informações do caso de uso selecionado.
2.2. Fluxo Alternativo
Não possui.
3. Requisitos especiais
Não possui.
4. Pré-Condição
Existir um caso de uso cadastrado previamente no sistema.
5. Pós-condições
Não possui.
6. Pontos de extensão
Não possui.
112
1. Caso de Uso: IncluirCasoUso
1.1. Breve descrição
O caso de uso Incluir Caso de Uso tem como objetivo registrar os casos de
uso do projeto.
1.2. Atores
Gerente de Projeto e Engenheiro de Software
1.3. Gatilho
Gerente de Projeto/Engenheiro de Software seleciona a opção na interface do
sistema.
2. Fluxo de Eventos
2.1. Fluxo Normal
1. O Gerente de Projeto/Engenheiro de Software informa os dados do caso de
uso.
2. O sistema valida os dados inseridos.
2.2. Fluxo Alternativo
Não possui.
3. Requisitos especiais
Não possui.
4. Pré-Condição
Não possui.
5. Pós-condições
Após a validação dos dados, o sistema armazena as informações.
6. Pontos de extensão
Não possui.
1. Caso de Uso: AlterarCasoUso
1.1. Breve descrição
O caso de uso Alterar Caso de Uso tem como objetivo alterar um caso de uso
inserido previamente.
1.2. Atores
Gerente de Projeto e Engenheiro de Software
1.3. Gatilho
Gerente de Projeto/Engenheiro seleciona a opção na interface do sistema.
2. Fluxo de Eventos
113
2.1. Fluxo Normal
1. O Gerente de Projeto/Engenheiro seleciona o caso de uso a ser alterado.
2. O Gerente de Projeto/Engenheiro informa os dados a serem alterados.
3. O sistema valida os dados inseridos.
2.2. Fluxo Alternativo
1.a. Caso os dados informados sejam inválidos o sistema exibe um aviso
informando o erro.
3. Requisitos especiais
Não possui.
4. Pré-Condição
Existir o caso de uso cadastrado previamente no sistema.
5. Pós-condições
Após a validação dos dados pelo o sistema, os dados são alterados.
6. Pontos de extensão
Não possui.
1. Caso de Uso: ExcluirCasoUso
1.1. Breve descrição
O caso de uso Excluir Caso de Uso tem como objetivo excluir um caso de uso
inserido previamente.
1.2. Atores
Gerente de Projeto e Engenheiro de Software
1.3. Gatilho
Gerente de Projeto/Engenheiro seleciona a opção na interface do sistema.
2. Fluxo de Eventos
2.1. Fluxo Normal
1. O Gerente de Projeto/Engenheiro excluir o caso de uso desejado.
2. O sistema pede a confirmação da exclusão.
2.2. Fluxo Alternativo
Não possui.
3. Requisitos especiais
Não possui.
4. Pré-Condição
Existir o caso de uso cadastrado previamente no sistema.
114
5. Pós-condições
Após a confirmação da exclusão, os dados do caso de uso são apagados do
sistema.
6. Pontos de extensão
Não possui.
115
Importar Diagrama de Caso de Uso
Projeto: Sistema de Cálculo de Pontos por Caso de Uso
Sub-Sistema: Gerenciar Diagrama de Caso de Uso
Nome do Caso de Uso: Importar Diagrama de Caso de Uso
116
1. Caso de Uso: ImportarAtor
1.1. Breve descrição
O caso de uso Importar Ator tem como objetivo importar os atores do projeto
modelados em uma ferramenta com suporte a XMI.
1.2. Atores
Gerente de Projeto e Engenheiro de Software
1.3. Gatilho
Gerente de Projeto/Engenheiro seleciona a opção na interface do sistema.
2. Fluxo de Eventos
2.1. Fluxo Normal
1. O Gerente de Projeto/Engenheiro seleciona o arquivo a ser carregado pelo
sistema.
2. O sistema verifica a extensão do arquivo e a integridade.
2.2. Fluxo Alternativo
1.a. Caso a extensão do arquivo não for compatível o sistema exibe um aviso
informando o erro.
2.a. Caso o arquivo esteja corrompido, o sistema exibe um aviso.
3. Requisitos especiais
Não possui.
4. Pré-Condição
Não possui.
5. Pós-condições
Após a validação do arquivo pelo sistema, os dados são armazenados.
6. Pontos de extensão
Não possui.
1. Caso de Uso: ImportarCasoUso
1.1. Breve descrição
O caso de uso Importar Caso de Uso tem como objetivo importar os caso de
uso do projeto modelados em uma ferramenta com suporte a XMI.
1.2. Atores
Gerente de Projeto e Engenheiro de Software
1.3. Gatilho
Gerente de Projeto/Engenheiro seleciona a opção na interface do sistema.
117
2. Fluxo de Eventos
2.1. Fluxo Normal
1. O Gerente de Projeto/Engenheiro seleciona o arquivo a ser carregado pelo
sistema.
2. O sistema verifica a extensão do arquivo e a integridade.
2.2. Fluxo Alternativo
1.a. Caso a extensão do arquivo não for compatível o sistema exibe um aviso
informando o erro.
2.a. Caso o arquivo esteja corrompido, o sistema exibe um aviso.
3. Requisitos especiais
Não possui.
4. Pré-Condição
Não possui.
5. Pós-condições
Após a validação do arquivo pelo sistema, os dados são armazenados.
6. Pontos de extensão
Não possui.
118
Gerenciar Estimativa Projetos
Projeto: Sistema de Cálculo de Pontos por Caso de Uso
Sub-Sistema: Principal
Nome do Caso de Uso: Gerenciar Estimativa Projetos
Descrição: O caso de uso Gerenciar Estimativa Projetos tem como objetivo aplicar o
método de Pontos por Caso de Uso em um determinado projeto.
119
Estimar Projeto
Projeto: Sistema de Cálculo de Pontos por Caso de Uso
Sub-Sistema: Gerenciar Estimativa Projetos
Nome do Caso de Uso: Estimar Projeto
1. Caso de Uso: CalcularComplexAtor.
1.1. Breve Descrição
O caso de uso Calcular Complexidade do Ator tem como objetivo calcular a
complexidade de cada ator envolvido no projeto.
1.2. Atores
Gerente de Projeto.
1.3. Gatilho
Gerente de Projeto seleciona a opção na interface do sistema.
2. Fluxo de Eventos
2.1. Fluxo Normal
1. O sistema efetua o calculo da complexidade dos atores.
2.2. Fluxo Alternativo
1.a. Caso os dados de cadastro do projeto não tenha sido anteriormente
inseridos no sistema o mesmo retornara uma mensagem de erro.
3. Requisitos especiais
Não possui.
4. Pré-Condição
Todos os dados necessários para o calculo devem já estar inseridos no
sistema.
5. Pós-condições
O sistema exibe o resultado do calculo.
6. Pontos de extensão
Não possui.
120
1. Caso de Uso: CalcularComplexCasoUso.
1.1. Breve Descrição
O caso de uso Calcular Complexidade do Caso de Uso tem como objetivo
calcular a complexidade de cada caso de uso do projeto.
1.2. Atores
Gerente de Projeto.
1.3. Gatilho
Gerente de Projeto seleciona a opção na interface do sistema.
2. Fluxo de Eventos
2.1. Fluxo Normal
1. O sistema efetua o calculo da complexidade dos casos de uso.
2.2. Fluxo Alternativo
1.a. Caso os dados de cadastro do projeto não tenha sido anteriormente
inseridos no sistema o mesmo retornara uma mensagem de erro.
3. Requisitos especiais
Não possui.
4. Pré-Condição
Todos os dados necessários para o calculo devem já estar inseridos no
sistema.
5. Pós-condições
O sistema exibe o resultado do calculo.
6. Pontos de extensão
Não possui.
121
1. Caso de Uso: CalcularPCUNaoAjustado.
1.1. Breve Descrição
O caso de uso Calcular Ponto de Caso de Uso Não Ajustado tem como
objetivo calcular os pontos por casos de uso ainda não ajustado do projeto.
1.2. Atores
Gerente de Projeto.
1.3. Gatilho
Gerente de Projeto seleciona a opção na interface do sistema.
2. Fluxo de Eventos
2.1. Fluxo Normal
1. O sistema efetua o calculo dos pontos por casos de uso ainda não
ajustado.
2.2. Fluxo Alternativo
1.a. Caso os dados de cadastro do projeto não tenha sido anteriormente
inseridos no sistema o mesmo retornara uma mensagem de erro.
3. Requisitos especiais
Não possui.
4. Pré-Condição
Antes que este caso de uso inicie e necessário que os casos de uso
CalcularComplexAtor e CalcularComplexCasoUso, já tenho sido anteriormente
executados.
5. Pós-condições
O sistema exibe o resultado do calculo.
6. Pontos de extensão
Não possui.
122
1. Caso de Uso: CalcularPCUAjustado.
1.1. Breve Descrição
O caso de uso Calcular Ponto de Caso de Uso Ajustado tem como objetivo
calcular os pontos por casos de uso após o calculo dos fatores de ajuste do
projeto.
1.2. Atores
Gerente de Projeto.
1.3. Gatilho
Gerente de Projeto seleciona a opção na interface do sistema.
2. Fluxo de Eventos
2.1. Fluxo Normal
1. O sistema efetua o calculo dos pontos por casos de uso ajustado.
2.2. Fluxo Alternativo
1.a. Caso os dados de cadastro do projeto não tenha sido anteriormente
inseridos no sistema o mesmo retornara uma mensagem de erro.
3. Requisitos especiais
Não possui.
4. Pré-Condição
Antes que este caso de uso inicie e necessário que o calculo dos fatores de
ajuste, já tenham sido feitos anteriormente.
5. Pós-condições
O sistema exibe o resultado do calculo.
6. Pontos de extensão
Não possui.
123
1. Caso de Uso: CalcularEsforcoHH.
1.1. Breve Descrição
O caso de uso Calcular Esforço Homem Horas tem como objetivo calcular o
esforço de horas de trabalho por caso de uso.
1.2. Atores
Gerente de Projeto.
1.3. Gatilho
Gerente de Projeto seleciona a opção na interface do sistema.
2. Fluxo de Eventos
2.1. Fluxo Normal
1. O sistema efetua o calculo do esforço de horas de trabalho.
2.2. Fluxo Alternativo
1.a. Caso os dados de cadastro do projeto não tenha sido anteriormente
inseridos no sistema o mesmo retornara uma mensagem de erro.
3. Requisitos especiais
Não possui.
4. Pré-Condição
Antes que este caso de uso inicie e necessário que o caso de uso
CalcularPCUAjustado, já tenham sido anteriormente executado.
5. Pós-condições
O sistema exibe o resultado do calculo.
6. Pontos de extensão
Não possui.
124
1. Caso de Uso: EstimarPrazoEquipe.
1.1. Breve Descrição
O caso de uso Estimar Prazo da Equipe tem como objetivo estimar prazos
para o desenvolvimento do projeto.
1.2. Atores
Gerente de Projeto.
1.3. Gatilho
Gerente de Projeto seleciona a opção na interface do sistema.
2. Fluxo de Eventos
2.1. Fluxo Normal
1. O sistema efetua a estimativa de prazos para o desenvolvimento do
projeto.
2.2. Fluxo Alternativo
1.a. Caso os dados de cadastro do projeto não tenha sido anteriormente
inseridos no sistema o mesmo retornara uma mensagem de erro.
3. Requisitos especiais
Não possui.
4. Pré-Condição
Antes que este caso de uso inicie e necessário que o caso de uso
CalcularEsforcoHH, já tenham sido anteriormente executado.
5. Pós-condições
O sistema exibe o resultado da estimativa.
6. Pontos de extensão
Não possui.
125
1. Caso de Uso: Consultar Estimativa.
1.1. Breve Descrição
O caso de uso Consultar Estimativas tem como objetivo consultar os projetos
já estimados.
1.2. Atores
Gerente de Projeto.
1.3. Gatilho
Gerente de Projeto seleciona a opção na interface do sistema.
2. Fluxo de Eventos
2.1. Fluxo Normal
1. O gerente de projeto seleciona um projetor já estimado para ser
consultado.
2. O sistema exibe as informações da estimativa do projeto.
2.2. Fluxo Alternativo
Não possui.
3. Requisitos especiais
Não possui.
4. Pré-Condição
O projeto já deve ter tido sua estimativa concluída.
5. Pós-condições
O sistema exibe o resultado completo da estimativa.
6. Pontos de extensão
Não possui.
