estimando projetos de software …siaibib01.univali.br/pdf/richard souza.pdftabela 19 comparação...
TRANSCRIPT
UNIVERSIDADE DO VALE DO ITAJAÍ
RICHARD HENRIQUE DE SOUZA
ESTIMANDO PROJETOS DE SOFTWARE ORIENTADOS A OBJETO
COM CASOS DE USO
São José
2005
8
RICHARD HENRIQUE DE SOUZA
ESTIMANDO PROJETOS DE SOFTWARE ORIENTADOS A OBJETO
COM CASOS DE USO
Trabalho de Conclusão de Curso apresentado como requisito parcial para obtenção do título de Bacharel em Ciência da Computação na Universidade do Vale do Itajaí, Centro de Educação São José.
Orientador: Marcello Thiry C. da Costa.
São José
2005
RICHARD HENRIQUE DE SOUZA
9
ESTIMANDO PROJETOS DE SOFTWARE ORIENTADOS A OBJETO
COM CASOS DE USO
Este Trabalho de Conclusão de Curso foi julgado adequado para obtenção do título de
Bacharel em Ciência da Computação e aprovado pelo Curso de Ciência da Computação, da
Universidade do Vale do Itajaí (SC), Centro de Educação São José.
Área de Concentração: Engenharia de Software
São José, 19 de dezembro de 2005
Prof. Dr. Marcello Thiry C. da Costa
UNIVALI-CE de São José
Orientador
Prof. Dr. Christiane Gresse von Wangenhein
UNIVALI-CE de São José
Membro
Prof. Dr. Adhemar Maria do Valle Filho
UNIVALI-CE de São José
Membro
10
DEDICATÓRIA
A minha mãe que me apoiou do inicio ao fim do curso de Ciência da
Computação e que vem me ensinando desde quando eu era uma criança...
11
AGRADECIMENTOS
À minha mãe, pelas noites de sono perdidas por minha causa. À minha tia Zelir, pelo apoio e incentivo. Ao professor Marcello Thiry pela orientação, confiança, apoio e incentivo. Aos professores e colegas do Curso, pela troca de experiências; Em especial aos professores Paulo Roberto Valim, Alessandro Mueller, Fernanda Cunha e Kelen Regina Salles Silva pelo apoio e incentivo.
12
Se você não conseguir admirar alguém que faz algo bem só por competir com você, estará jogando fora uma possibilidade de melhorar a si mesmo.
Ayrton Senna da Silva.
13
RESUMO
Usualmente, os desenvolvedores de software não dedicam tempo para coletar dados sobre o
processo de desenvolvimento de software. Com poucos dados históricos como guia, as
estimativas de tamanho têm sido realizadas com base na experiência dos gerentes, gerando
resultados aleatórios e não positivos. Sem nenhuma indicação sólida de produtividade, não é
possível avaliar com precisão a eficácia de novas ferramentas, métodos ou padrões. Sendo
assim, o contexto deste trabalho é a estimativa de software orientado a objeto utilizando o
método de análise por pontos de caso de uso (UCP – use case points). Os casos de uso vem
sendo cada vez mais utilizados pelas empresas de software para o levantamento de requisitos,
permitindo que o uso do método UCP seja viabilizado. Este trabalho apresenta uma
ferramenta para o cálculo de UCP que está sendo desenvolvida como um módulo da
plataforma PLACES. Para tal, foi também desenvolvida uma ferramenta web cadastrar casos
de uso e artefatos relacionados, permitindo a integração do levantamento de casos de uso com
o levantamento de dados para o cálculo dos pontos de caso de uso. Além do desenvolvimento
e da apresentação da arquitetura computacional utilizada, o módulo desenvolvido foi testado
com um estudo de caso real, permitindo algumas comparações. O foco deste trabalho é a
estimativa de tamanho, oferecendo possibilidades de continuação a partir desta medida.
Palavras Chaves: Pontos de caso de uso, Estimativa de tamanho, Software orientado a
objeto.
14
LISTA DE FIGURAS
Figura 1 Implantação de programas da qualidade e sistemas da qualidade ou similares....................................... 23 Figura 2 Distribuição da comercialização brutal anual proveniente de software (2000)....................................... 24 Figura 3 Empresas que fazem algum tipo de estimativa. ...................................................................................... 29 Fonte: MCT, 2001. ................................................................................................................................................ 29 Figura 4 Tela de projetos do PLACES. ................................................................................................................. 65 Figura 5 Divisão MVC no PLACES. .................................................................................................................... 66 Figura 6 Lista de atores. ........................................................................................................................................ 79 Figura 7 Cadastro de ator. ..................................................................................................................................... 79 Figura 8 Excluir Ator. ........................................................................................................................................... 80 Figura 9 lista de Caso de uso................................................................................................................................. 80 Figura 10 Cadastro de caso de uso. ....................................................................................................................... 81 Figura 11 Excluir Caso de Uso.............................................................................................................................. 82 Figura 12 Lista de Fatores de Ajuste ..................................................................................................................... 83 Figura 13 Cadastro de Fator de Ajuste .................................................................................................................. 84 Figura 14 Edição dos fatores de ajuste .................................................................................................................. 84 Figura 15 Excluir um fator de ajuste ..................................................................................................................... 85 Figura 16 Edita Esforço......................................................................................................................................... 85 Figura 17 Calculo dos Pontos de Caso de Uso ...................................................................................................... 86 Figura 18 Configurar esforço e fatores de Ajuste.................................................................................................. 87 Figura 19 Fatores de complexidade técnica no EA. .............................................................................................. 87 Figura 20 Fatores de complexidade ambiente no EA. ........................................................................................... 88 Figura 21 Calcular pontos de caso de uso no EA .................................................................................................. 89 Figura 22 Tela de pontos de caso de uso no EA.................................................................................................... 89 Figura 23 diagrama de casos de uso. ..................................................................................................................... 90 Figura 24 Opção Other do menu new. ................................................................................................................... 95 Figura 25 Criar um middlegen Build File.............................................................................................................. 96 Figura 26 Seleção do arquivo Build. ..................................................................................................................... 96 Figura 27 Conectando com o banco. ..................................................................................................................... 97 Figura 28 Arquivo .JAR de conexão com o banco de dados. ................................................................................ 97 Figura 29 Carregando as tabelas do banco de dados. ............................................................................................ 98 Figura 30 Atores do Sistema ............................................................................................................................... 112 Figura 31 Caso de Uso do Sistema...................................................................................................................... 112 Figura 32 SEQ-01 Cadastro de Atores ................................................................................................................ 143 Figura 33 SEQ-02 Cadastro de caso de uso......................................................................................................... 144 Figura 34 SEQ-03 Cálculo de Pontos de caso de uso.......................................................................................... 145 Figura 35 SEQ-04 Cadastro de Fatores de Ajuste ............................................................................................... 146
15
Figura 36 Tela de instalação do JAVA................................................................................................................ 148 Figura 37 Tela de personalização da instalação do JAVA. ................................................................................. 148 Figura 38 Tela de configuração das ferramentas do JAVA................................................................................. 148 Figura 39 Tela de configuração do browser. ....................................................................................................... 149 Figura 40 Tela de finalização da instalação......................................................................................................... 149 Figura 41 Configuração das variáveis de Ambiente............................................................................................ 150 Figura 42 Configuração das variáveis de Ambiente............................................................................................ 150 Figura 43 Configuração das variáveis de Ambiente............................................................................................ 150 Figura 44 Configuração das variáveis de Ambiente............................................................................................ 151 Figura 45 Configuração das variável PATH. ...................................................................................................... 151 Figura 46 Configuração das variável PATH ....................................................................................................... 151 Figura 47 Criar a variável JAVA_HOME........................................................................................................... 152 Figura 48 Criar a variável JAVA_HOME........................................................................................................... 152 Figura 49 Tela de inicio da instalação do Tomcat ............................................................................................... 152 Figura 50 Termo de licença do Tomcat............................................................................................................... 153 Figura 51 Configuração do Tomcat..................................................................................................................... 153 Figura 52 Configuração do local de instalação do Tomcat.................................................................................. 153 Figura 53 Tela de configuração do Tomcat......................................................................................................... 154 Figura 54 Tela de configuração do Java no Tomcat. ........................................................................................... 154 Figura 55 Tela de termino da instalação do Tomcat............................................................................................ 154 Figura 56 Pagina principal do Tomcat. ............................................................................................................... 155 Figura 57 Inicio da instalação do MySQL........................................................................................................... 155 Figura 58 Tela de informação do MySQL........................................................................................................... 156 Figura 59 Escolha do diretória do MySQL.......................................................................................................... 156 Figura 60 Configuração do MySQL.................................................................................................................... 156 Figura 61 Termino da instalação do MySQL. ..................................................................................................... 156 Figura 62 Executar o MySQL. ............................................................................................................................ 157 Figura 63 Executar o MySQL. ............................................................................................................................ 157 Figura 64 Executar o MySQL. ............................................................................................................................ 157 Figura 65 Tela de boas vindas do ODBC MySQL. ............................................................................................. 158 Figura 66 Tela de confirmação............................................................................................................................ 158 Figura 67 Tela de confirmação............................................................................................................................ 158 Figura 68 Tela de confirmação do ODBC........................................................................................................... 159 Figura 69 Adicionando a fonte de dados MySQL. .............................................................................................. 159 Figura 70 Adicionando a fonte de dados MySQL ............................................................................................... 159 Figura 71 Tela inicial do Netbeans...................................................................................................................... 160 Figura 72 Tela de lincença do Netbeans.............................................................................................................. 160 Figura 73 Local de instalação do Netbeans. ........................................................................................................ 160 Figura 74 Configuração do JAVA....................................................................................................................... 161 Figura 75 Configuração do JAVA....................................................................................................................... 161
16
Figura 76 Tela de finalização da instalação do NetBeans. .................................................................................. 161 Figura 77 Criando mapeamento Hipernate.......................................................................................................... 162 Figura 78 Criando mapeamento Hipernate.......................................................................................................... 163 Figura 79 Criando mapeamento Hipernate.......................................................................................................... 163 Figura 80 Conectando com o banco. ................................................................................................................... 164 Figura 81 Arquivo JAR de conexão com o banco. .............................................................................................. 164 Figura 82 Carregando as tabelas do banco de dados. .......................................................................................... 165 Figura 83 Modelagem do Banco de dados .......................................................................................................... 166
17
Lista de tabelas
Tabela 1 Definição dos pesos dos componentes de acordo com a sua complexidade. ............................ 37 Tabela 2 Cálculo do número não ajustado pontos de função. ................................................................. 38 Tabela 3 Definição da complexidade para arquivos internos usada pelo IFPUG.................................... 38 Tabela 4 Definição da complexidade para entradas externas usadas pelo IFPUG. ................................. 38 Tabela 5 Definição da complexidade para saídas externas usadas pelo IFPUG...................................... 39 Tabela 6 Definição da complexidade para consultas externas usadas pelo IFPUG................................. 39 Tabela 7 Características gerais do sistema. ............................................................................................. 39 Tabela 8 Contabilização de fatores.......................................................................................................... 41 Tabela 9 Soma dos fatores individuais. ................................................................................................... 41 Tabela 10 Número bruto de pontos de função. ..................................................................................... 42 Tabela 11 Respostas aos níveis de influência. ...................................................................................... 42 Tabela 12 Cálculo do fator de ajuste. ................................................................................................... 42 Tabela 13 Número ajustado de pontos de função ................................................................................. 42 Tabela 14 Valores das variáveis a e b baseado no tipo de projeto........................................................ 44 Tabela 15 Valores das variáveis c e d baseado no tipo de projeto........................................................ 45 Tabela 16 Produtividade por pontos de objetos.................................................................................... 46 Tabela 17 Direcionadores de cálculo.................................................................................................... 47 Tabela 18 Atributos de esforço............................................................................................................. 48 Tabela 19 Comparação do modelo original com o novo modelo COCOMO....................................... 50 Tabela 20 Fatores do expoente ............................................................................................................. 49 Tabela 21 Conversão de KLOC para APF............................................................................................ 51 Tabela 22 Contabilização dos direcionadores de cálculo. .................................................................... 51 Tabela 23 Cálculo de M........................................................................................................................ 52 Tabela 24 Cálculo de esforço. .............................................................................................................. 52 Tabela 25 Cálculo de custo................................................................................................................... 52 Tabela 26 Classificação dos atores ....................................................................................................... 55 Tabela 27 Complexidade do caso de uso.............................................................................................. 55 Tabela 28 Complexidade do caso de uso por meio de classes.............................................................. 56 Tabela 29 Grau de influência................................................................................................................ 56 Tabela 30 Fatores de complexidade técnica ......................................................................................... 57 Tabela 31 Fatores de ambiente e seus respectivos pesos ...................................................................... 58 Tabela 32 Definição da complexidade técnica ..................................................................................... 59 Tabela 33 Cálculo do TFactor .............................................................................................................. 60 Tabela 34 Cálculo do TFactor .............................................................................................................. 61 Tabela 35 Fatores de ambiente e seus respectivos pesos ...................................................................... 61 Tabela 36 Cálculo do EFactor .............................................................................................................. 61 Tabela 37 Cálculo do TFactor .............................................................................................................. 61 Tabela 38 Cálculo do número ajustado de pontos de casos.................................................................. 61
18
LISTA DE ANEXOS
ANEXO 1 Middlegenide.................................................................................................................................. 95 ANEXO 2 Casos de uso do módulo de estimativa ........................................................................................... 99 ANEXO 3 Casos de uso para o teste do Módulo de Estimativa..................................................................... 112 ANEXO 4 Testes do Módulo de estimativa ................................................................................................... 127 ANEXO 5 Regras de negócio......................................................................................................................... 138 ANEXO 6 Requisitos do sistema de estimativa ............................................................................................. 141 ANEXO 7 Diagramas de sequência do módulo de estimativa ....................................................................... 143 ANEXO 8 Instalação das ferramentas para o desenvolvimento e manutenção do PLACES ......................... 147 ANEXO 9 Modelo do banco de dados do módulo de estimativa do PLACES .............................................. 166
ANEXO 10 Casos de uso para validação do módulo de estimativa ................................................................171
19
SUMÁRIO
Lista de Anexos .................................................................................................................... 18 Lista de Anexos .................................................................................................................... 18 1 Introdução......................................................................................................... 21 1.1 Apresentação ............................................................................................................................ 21 1.2 Justificativa............................................................................................................................... 23 1.3 Objetivos................................................................................................................................... 25 1.3.1 Objetivo geral ........................................................................................................................... 25 1.3.2 Objetivos específicos................................................................................................................ 25 1.4 Delimitação do trabalho............................................................................................................ 25 1.5 Metodologia.............................................................................................................................. 26 1.5.1 Aspectos Metodológicos........................................................................................................... 26 1.5.2 Plano de Trabalho..................................................................................................................... 27 1.6 Organização do trabalho........................................................................................................... 28 2 Estimativa de software...................................................................................... 29 2.1 Apresentação ............................................................................................................................ 29 2.2 Tipos de estimativa................................................................................................................... 30 2.2.1 Estimativa bottom-up................................................................................................................ 31 2.2.2 Estimativa Top-down ............................................................................................................... 32 2.2.3 Experiência de um especialista ................................................................................................. 33 2.2.4 Estimativa por analogia ............................................................................................................ 34 2.3 Conclusão do capítulo .............................................................................................................. 35 3 Métodos de Estimativa ..................................................................................... 36 3.1 Análise por ponto de função ..................................................................................................... 36 3.1.1 Exemplo de aplicação de APF.................................................................................................. 41 3.2 COCOMO................................................................................................................................. 43 3.2.1 COCOMO 81............................................................................................................................ 43 3.2.2 COCOMO II............................................................................................................................. 45 3.2.2.1 Nível inicial de prototipação..................................................................................................... 46 3.2.2.2 Nível inicial de projeto ............................................................................................................. 46 3.2.2.3 Nível pós-arquitetura ................................................................................................................ 48 3.2.3 Exemplo de utilização do COCOMO ....................................................................................... 51 3.3 Análise por pontos de caso de uso............................................................................................ 53 3.3.1 Classificando os atores e casos de uso...................................................................................... 54 3.3.2 Número ajustado de pontos de casos de uso............................................................................. 56 3.3.2.1 Fatores técnicos ........................................................................................................................ 57 3.3.2.2 Fatores de ambiente .................................................................................................................. 57 3.3.3 Cálculo de esforço .................................................................................................................... 59 3.4 Exemplo de aplicação de UCP ................................................................................................ 59 3.5 Conclusão ................................................................................................................................. 62 4 Ferramenta de estimativa de software .............................................................. 64 4.1 Tecnologia Utilizada................................................................................................................. 65 4.1.1 O Framework SPRING ............................................................................................................. 66 4.1.2 Oframework Hibernate............................................................................................................. 68 4.2 Padrões de Projeto .................................................................................................................... 72 4.2.1 Front Controller ........................................................................................................................ 72
20
4.2.2 View Helper.............................................................................................................................. 73 4.2.3 Composite View ....................................................................................................................... 74 4.2.4 Business Delegate..................................................................................................................... 75 4.2.5 Data Access Object................................................................................................................... 76 4.2.6 Business Object ........................................................................................................................ 76 4.2.7 Transfer object.......................................................................................................................... 77 4.2.8 Dispatcher................................................................................................................................. 77 4.3 O Módulo de Estimativa........................................................................................................... 78 4.3.1 Cadastro de atores..................................................................................................................... 78 4.3.2 Cadastro de casos de uso .......................................................................................................... 80 4.3.3 Cadastro de fator de Ajuste....................................................................................................... 82 4.3.4 Editar o esforço......................................................................................................................... 85 4.3.5 Cálculo de Pontos de Caso de Uso ........................................................................................... 86 4.4 Enterprise architect ................................................................................................................... 87 4.5 Comparação entre as ferramentas ............................................................................................. 90 4.6 Estudo de caso .......................................................................................................................... 90 5 Conclusão ......................................................................................................... 92 5.1 TRABALHO FUTURO ........................................................................................................... 94 6 REFERÊNCIAS ................................................ Erro! Indicador não definido.
21
1 INTRODUÇÃO
1.1 APRESENTAÇÃO
PLACES é uma plataforma colaborativa desenvolvida para apoiar a gerência de projetos de
software, flexibilizando a construção de ferramentas que venham oferecer suportar diferentes
processos da Engenharia de Software (MORETTO, 2005). Esta plataforma é uma evolução da
ferramenta colaborativa ARCase, desenvolvida inicialmente para suportar apenas a fase de
concepção de software (KONOWALOW, 2003; DOMINGOS, 2004). A plataforma PLACES
é um ambiente comum para a construção incremental de diferentes ferramentas onde os
recursos colaborativos já estão disponíveis. Desta forma, a construção das ferramentas é
facilitada e focada nas boas práticas associadas com os processos que elas pretendem
trabalhar. No trabalho de Moretto (2005), foi desenvolvida uma ferramenta para gerência de
projetos, incluindo as áreas de planejamento e monitoração de projetos. Além disso, foi
também desenvolvida toda uma infra-estrutura de segurança e de colaboração (ferramentas
para reuniões virtuais, fóruns de discussão e outros recursos).
Este trabalho integra um módulo para estimar tamanho de software na plataforma PLACES.
O método de estimativa utilizado foi um baseado em pontos de casos de uso (UCP – Use Case
Points) (KARNER, 1993). Este método propõe uma estimativa de tamanho para o projeto de
desenvolvimento de software. Segundo o estudo de Damodaran (2003, p.2), o método UCP
pode ser utilizado para estimar o tamanho do desenvolvimento de software com um baixo
nível de erros na estimativa. Para calcular os pontos de casos de uso, é necessário classificar a
complexidade de atores e casos de uso, além de estabelecer fatores de ajuste relacionados à
equipe de desenvolvimento e ao projeto (KARNER, 1993). A partir destas informações, é
possível calcular o total de pontos de caso de uso.
A motivação deste trabalho é que estimativas de software são freqüentemente imprecisas.
Essa mesma conclusão também é indicada por Sommerville (1996, p. 590) e Mayhauser
(1990, p.684). A produtividade dos desenvolvedores de software não tem acompanhado a
22
demanda dos seus serviços, a qualidade de software é usualmente abaixo da esperada e custos
excessivos têm sido experimentados (MCT, 2001).
Ainda de acordo com Pressman (1995, p.90), os desenvolvedores não dedicam tempo para
coletar dados sobre o processo de desenvolvimento de software. Com poucos dados históricos
como guia, as estimativas têm sido realizadas com base na experiência dos analistas, gerando
resultado aleatórios e, quase sempre, não positivos. Sem nenhuma indicação sólida de
produtividade, não é possível avaliar com precisão a eficácia de novas ferramentas, métodos
ou padrões.
A função de estimar o tamanho das tarefas a serem executadas é uma das práticas associadas
com a gerência de projetos, a qual “é a aplicação de conhecimentos, habilidades, e técnicas
para projetar atividades que visem atingir os requerimentos do projeto” (PMBOK, 2000, p. 6).
A gerência de projetos de software é, por sua vez, uma tarefa complexa, pois envolve
diferentes pessoas que utilizam conhecimentos tácitos1 a para realização de suas tarefas. Isso
dificulta a transcrição destas tarefas e rotinas, executadas no dia-a-dia, para uma forma
explícita. Além disso, o próprio software é um produto complexo (MARTIN; ODELL, 1995,
p.4). Essa complexidade, inerente ao software, deve-se à sua natureza abstrata e a alguns
fatores com o qual o hardware irá suportar o software, em que plataforma ele será executado,
qual o tipo de usuário que irá operá-lo entre outros (MARTIN; ODELL, 1995, p.36). Um fator
dessa complexidade é uma função do número de possíveis caminhos de execução no
programa e da dificuldade de rastrear os caminhos antes de sua implementação (MARTIN e
ODELL, 1995, p.44). Neste sentido, torna-se necessário adotar uma sistemática que permita
um maior monitoramento e controle do processo de desenvolvimento de software.
Entretanto, para que seja possível estimar as tarefas dentro da gerência de projetos de
software, é necessário identificar as reais necessidades dos usuários e documentá-las de forma
que seja viável aplicar alguma das técnicas citadas anteriormente. Neste sentido, é necessário
documentar os requisitos do sistema e do software.
A engenharia de requisitos é a utilização sistemática de métodos, linguagens, ferramentas e
princípios verificáveis para a análise e descrição das necessidades do usuário e a descrição
dos recursos comportamentais e não-comportamentais de um sistema de software que
satisfaça às necessidades do usuário (PETTERS; PEDRYCZ, 2001, p. 9). A engenharia de
1 Conhecimento implícito, que não se exprime por palavras (AURÉLIO, 1999, p. 1915).
23
requisitos é a base para a estimativa de tamanho. Caso a análise de requisitos não seja bem
feita, estimativas apuradas serão mais difíceis de serem obtidas.
Neste contexto, o foco deste trabalho é a estimativa de tamanho de software orientado a
objeto utilizando o método de análise por pontos de caso de uso (UCP). O modelo de caso de
uso vem sendo cada vez mais utilizado pelas empresas para o levantamento de requisitos
(DAMODARAM, 2003, p.1), permitindo que o uso do método UCP seja aplicável.
Dessa forma, este trabalho procura contribuir com a implementação de uma ferramenta para
estimar software usando o método de análise por pontos de caso de uso. Esta ferramenta é um
novo módulo da plataforma PLACES2 (MORETTO, 2005).
1.2 JUSTIFICATIVA
Em 2001, existia cerca de 10.713 empresas e prestadores de serviço no setor de software
(MCT, 2001). Ainda de acordo com o MCT (2001), até 2001, a região sul contava com 34283
empresas até 2001. Com a necessidade de manter seu nível de competitividade, as empresas
de software estão buscando melhorar a qualidade de seus processos (MCT, 2001). A figura 1
mostra o percentual das empresas que tem programas de qualidade, as que estão implantando
e as que não tem programas de qualidades ou similares.
Implantação de programas da qualidade total sistemas da qualidade ou similares
25,10% 26,20%
48,70%
0,00%
10,00%
20,00%
30,00%
40,00%
50,00%
60,00%
Sim Em estudo ouimplantação
Não
SimEm estudo ou implantaçãoNão
Figura 1 Implantação de programas da qualidade e sistemas da qualidade ou similares.
Fonte: MCT, 2001
2 PLACES plataforma colaborativa de engenharia de software para a fase de análise de requisitos de software e gerência de projetos de software, a qual implementa o cadastro e edição de casos de uso. 3 Este número tende a ser maior hoje, devido ao crescimento do número de empresas demonstrado na própria pesquisa do MCT.
24
Como a figura 2 demonstra, a maioria das empresas de software trabalha com o
desenvolvimento de software por encomenda. Sendo assim, um aspecto importante que deve
ser considerado é a estimativa do tamanho. A estimativa de tamanho tem impacto direto no
custo do projeto, na alocação de recursos (humanos e não humanos), além de servir como
base para a definição do cronograma de entrega de artefatos. Entretanto, grande parte das
empresas não adota nenhuma técnica ou ferramenta formal para esta tarefa (MCT, 2001).
Distribuição da comercialização bruta anual proveniente de software - 2000
7%2%
21%
70%
0%
10%
20%
30%
40%
50%
60%
70%
80%
Embarcado Internet Pacote Encomenda
EmbarcadoInternetPacoteEncomenda
Figura 2 Distribuição da comercialização brutal anual proveniente de software (2000).
Fonte: MCT, 2001
Geralmente, as estimativas são feitas exclusivamente com base na experiência dos gerentes e
analistas. Esta situação pode levar a inconsistências, principalmente em domínios diferentes.
As micro e pequenas empresas têm uma dificuldade ainda maior, pela sua usual
informalidade. Vale ressaltar, porém, que o fato de uma empresa ser pequena não garante que
os softwares desenvolvidos por ela também sejam de pequeno porte e com poucos riscos
envolvidos. Neste sentido, este trabalho procura contribuir com um módulo que implementa a
técnica de análise por pontos de caso de uso para a estimativa de tamanho em projetos de
software orientado a objeto. Cabe ressaltar que este módulo é parte integrante de uma
ferramenta web integrada à plataforma PLACES, que permite a documentação de casos de
uso. Esta ferramenta é também um dos resultados deste trabalho.
25
Embora a técnica de estimativa baseada em pontos de função possa ser adotada em
abordagens orientadas a objeto, seu principal problema está no grau de detalhe necessário na
documentação dos requisitos funcionais do sistema (DAMODARAM, 2003, p.1).
Usualmente, o tamanho do sistema é estimado após todo o levantamento de requisitos e com a
construção dos primeiros protótipos, ou mediante uma análise detalhada junto a um cliente
que consiga entender o sistema em um nível funcional bem detalhado. Na maioria dos casos,
esta não é a situação real. Além disso, o crescimento da utilização de casos de usos para
capturar a funcionalidade do sistema pelas empresas faz com que esse trabalho esteja em
sintonia com as necessidades dos desenvolvedores de software.
1.3 OBJETIVOS
1.3.1 OBJETIVO GERAL
Este trabalho apresenta o desenvolvimento de um protótipo de ferramenta para documentação
de casos de uso com um módulo de estimativa de tamanho baseado em pontos de caso de uso
1.3.2 OBJETIVOS ESPECÍFICOS
1. Identificar as principais medidas utilizadas para as estimativas de tamanho em projetos
de software, focando naquelas voltadas a projetos orientados a objeto.
2. Modelar e implementar um protótipo web de uma ferramenta para o auxílio na
estimativa de projetos de desenvolvimento de software orientados a objetos, utilizando
o método de análise por pontos de caso de uso.
3. Adaptar o ambiente ARCASE (KONOWALOW, 2003; DOMINGOS, 2004), na
plataforma PLACES.
4. Desenvolver um módulo de estimativa de tamanho na plataforma PLACES.
5. Comparar os resultados obtidos do protótipo construído a partir de um estudo de caso
simulado com os resultados obtidos a partir de uma ferramenta que suporte o método
por pontos de caso de uso.
1.4 DELIMITAÇÃO DO TRABALHO
Este trabalho apresenta uma visão geral de estimativas de software, com foco na estimativa de
tamanho em projetos de softwares orientados a objetos, onde o método a ser analisado é o de
26
análise por pontos de casos de uso (UCP). Embora comentados, não faz parte do escopo do
trabalho, as estimativas de esforço, prazos (tempo) e custos, uma vez o cálculo destas
informações necessitariam de dados adicionais, incluindo características específicas da
empresa de software.
Outro resultado tangível deste trabalho é a implementação de uma ferramenta web para o
auxílio de estimativa utilizando o método UCP. Para que seja possível estimar utilizando
pontos de caso de uso, é necessário já possuir as informações sobre os atores e casos de uso
do sistema. Embora não seja necessária uma ferramenta para documentar o modelo de caso de
uso, este trabalho prevê a atualização da ferramenta ARCASE (KONOWALOW, 2003;
DOMINGOS, 2004) para que ela suporte o módulo de estimativa e também para que ela faça
parte da plataforma PLACES (MORETTO, 2005).
Este trabalho não pretende avaliar, testar ou implementar uma ferramenta para outros métodos
de estimativa como, por exemplo, pontos de função e COCOMO.
1.5 METODOLOGIA
1.5.1 ASPECTOS METODOLÓGICOS
Considerando a forma de abordar o problema, é adotada uma pesquisa qualitativa. A pesquisa
qualitativa “trabalha com o universo de significados, motivos, aspirações, crenças, valores e
atitudes, o que corresponde a um espaço mais profundo das relações, dos processos e dos
fenômenos que não podem ser reduzidos à operacionalização de variáveis” (MINAYO et al,
2000, p.22). Este trabalho não utiliza técnicas de levantamento e análise estatística, uma vez
que o objeto é a construção de um protótipo baseado em um método específico (pontos de
casos de uso). Desta forma, não é possível generalizar os resultados. Entretanto, foram feitas
simulações que permitiram identificar a tendência ou não de sucesso da aplicação. Vale
ressaltar que o próprio método selecionado ainda não está totalmente disseminado na
comunidade de desenvolvimento, permitindo que o trabalho ofereça uma contribuição neste
sentido.
Do ponto de vista de seus objetivos, será adotada uma pesquisa exploratória. Ela visa
proporcionar maiores informações sobre um determinado assunto para torná-lo explícito ou
para permitir a construção de hipóteses (RICHARDSON et al, 1999, p.45). A pesquisa
exploratória compreende levantamento bibliográfico e análise de exemplos que estimulem a
27
compreensão. Ela assume, em geral, as formas de pesquisas bibliográficas e estudos de caso
(ANDRADE, 1999, p.106).
Para a execução do trabalho, serão adotados os procedimentos técnicos de pesquisa
bibliográfica e pesquisa-ação. A pesquisa bibliográfica procura explicar um problema a partir
de referências teóricas publicadas em documentos (CERVO; BERVIAN, 1996, p.48),
constituído principalmente de livros, artigos de periódicos e atualmente com material
disponibilizado na Internet. Neste sentido, este trabalho apresentará um estudo aprofundado
sobre estimativa em projetos de software orientado a objeto. Serão estudados os tipos de
estimativa existentes, bem como um conjunto de métodos de estimativas que poderiam ser
utilizados no contexto do trabalho. A ênfase será nos pontos de caso de uso e na sua utilização
em um projeto orientado a objeto.
A pesquisa-ação é caracterizada quando o trabalho é concebido e realizado em estreita
associação com uma reação ou com a resolução de um problema coletivo. Os pesquisadores e
participantes representativos da situação ou do problema estão envolvidos de modo
cooperativo ou participativo (GIL, 1999, p.46). É dentro deste contexto que este trabalho com
a construção prototipada de um módulo para a estimativa baseada em pontos de casos de uso
que será integrado à plataforma PLACES. A construção do software seguirá um ciclo de vida
evolucionário, com versões funcionais incrementais. Para cada versão, serão feitos testes
específicos que permitirão a verificação parcial dos resultados obtidos. Com estes resultados,
serão tomadas as ações necessárias para a continuação e posterior conclusão do trabalho.
1.5.2 PLANO DE TRABALHO
As ações que devem ser executadas para alcançar os objetivos deste trabalho estão listadas
abaixo:
1. Estruturar a teoria sobre estimativas em projetos de software, aprofundando-se em
projeto de software orientado a objetos. Para obter o embasamento necessário para a
justificativa deste trabalho (objetivos específicos 1)
2. Aprofundar os conhecimentos em análise por pontos de caso de uso, por meio de uma
revisão bibliográfica (objetivo específico 1).
3. Definir os requisitos para a ferramenta de estimativa que foi desenvolvida, com base
nas informações levantadas durante a revisão bibliográfica (objetivo específico 2).
28
4. Revisar o trabalho (TCC1) de acordo com as recomendações da banca de avaliadores
(objetivo específico 3).
5. Revisar a implementação do ARCASE, fazendo os ajustes necessários para que a
ferramenta a ser construída possa ser devidamente encaixada no ambiente (objetivo
específico 3).
6. Modelar e implementar o protótipo (objetivos específicos 2, 3 e 4).
7. Testar o ambiente em um estudo de caso simulado, comparando com outra ferramenta
que adote o método UCP (objetivos específicos 4 e 5).
8. Discutir os resultados (objetivo específico 5).
1.6 ORGANIZAÇÃO DO TRABALHO
O trabalho está organizado em 4 capítulos correlacionados, iniciando com esta introdução
sobre o tema proposto.
O segundo capítulo aborda os principais tipos de estimativa encontrados na literatura. São
apresentados tipos de estimativa baseados na forma em que as informações para a estimativa
são obtidas (bottom-up e top-down), assim como a estimativa definida com base na
experiência dos especialistas envolvidos. Ainda é discutido o tipo de estimativa baseado em
analogia.
O terceiro capítulo apresenta os métodos mais conhecidos para estimar projetos de software.
Além do próprio método que será utilizado (pontos de casos de uso) para o desenvolvimento
da ferramenta, serão ainda apresentados os métodos por ponto de função e COCOMO.
O quarto capítulo descreve a ferramenta desenvolvida para estimar projetos de software
orientado a objeto com a utilização de pontos de caso de uso.
29
2 ESTIMATIVA DE SOFTWARE
2.1 APRESENTAÇÃO
A estimativa de tamanho é muito importante para a atividade de planejamento
(MAYHAUSER, 1990, p.684). Segundo Sommerville (1996, p.595), não há um caminho
simples para estimar com exatidão o tamanho do futuro sistema de software. As abordagens
disponíveis exigem uma disciplina rígida para a obtenção dos dados para o cálculo da
estimativa. Mesmo assim, as estimativas de tamanho diferem do tamanho real dos sistemas de
software (MAYHAUSER, 1990, p.695). Esta dificuldade está associada com aquilo que
diferencia um projeto de software de outros tipos de projeto, onde o custo primário está
associado com recursos humanos.
Empresas que fazem estimativa
55,00%45% 45,70%
54,30%
29,00%
71%
0,00%10,00%20,00%30,00%40,00%50,00%60,00%70,00%80,00%
Est
imat
iva
de c
usto
s
Não
usa
est
imat
iva
decu
sto
Est
imat
iva
de e
sfor
ço
Não
usa
usa
est
imat
iva
dees
forç
o
Est
imat
iva
de ta
man
ho
Não
usa
est
imat
iva
deta
man
ho
Estimativa de custos
Não usa estimativa decustoEstimativa de esforço
Não usa usa estimativade esforçoEstimativa de tamanho
Não usa estimativa detamanho
Figura 3 Empresas que fazem algum tipo de estimativa.
Fonte: MCT, 2001.
30
Apesar dos vários4 tipos de estimativas existentes, apenas pouco mais da metade das
empresas brasileiras as utilizam (MCT, 2001), conforme pode ser observado na figura 3.
Mesmo assim, há um crescimento no número de empresas que utilizam a estimativa de
tamanho (MCT, 2001).
A estimativa de tamanho é utilizada para saber o tamanho do projeto podendo ser medido em
KLOC (milhares de linhas de código), PF (pontos de função) ou PO (pontos por objetos),
dependendo da metodologia de métrica utilizada. A estimativa de tamanho é encontrada com
base em informações obtidas a partir, principalmente, dos requisitos do projeto.
A estimativa de esforço é representada pelos recursos humanos necessários para a execusão
de um projeto de software, que pode ser medido em pessoa/ano, pessoa/mês, pessoa/semana
ou pessoa/hora. Para estabelecer o esforço, é necessário ter a estimativa do tamanho ou
complexidade do software.
A estimativa de custo depende das estimativas anteriores: tamanho e esforço. Além destas
entradas, a estimativa de custo ainda necessita de outras informações como recursos de infra-
estrutura, as quais não fazem parte do escopo deste trabalho. A partir da manipulação de todas
estas informações é que seria possível estimar quanto seria o custo de um projeto de software.
Cabe ressaltar que esta estimativa de custo não deve ser utilizada, necessariamente, para
calcular o preço final do produto de software. O objetivo é encontrar o valor total do custo
utilizado para o desenvolvimento do produto. Como não serão discutidas todas as informações
indicadas para o levantamento do custo, esta estimativa não fará parte do escopo deste
trabalho.
2.2 TIPOS DE ESTIMATIVA
Os tipos de estimativas são técnicas que descrevem o que deve ser feito para estimar o
tamanho de um projeto de software. Entretanto, os tipos não descrevem como isso deve ser
feito. Este capítulo aborda os tipos de estimativa.
4 Há, pelo menos 5 estimativas diferentes descritas nas referências deste Trabalho de Conclusão de Curso (HUGHES; COTTERELL, 1999, p. 85; SOMMERVILLE, 1996, p. 596; FENTON; PFLEEGER, 1997, p. 432-458).
31
2.2.1 ESTIMATIVA BOTTOM-UP
Na estimativa bottom-up, o projeto é dividido em partes menores, resultando em subprodutos,
componentes ou tarefas. Após a divisão do projeto, é calculado o tamanho requerido para
desenvolver cada um desses elementos. A totalização destes “tamanhos” define o tamanho de
todo o sistema (SOMMERVILLE, 2004, p. 443; FENTON; PFLEEGER, 1997, p. 434).
A estimativa bottom-up considera cada um dos componentes do produto, inclusive os
problemas técnicos difíceis associados com componentes específicos5. Contudo, essa
abordagem, provavelmente, poderá subestimar o tamanho das atividades do sistema, como o
tamanho do software para a integração dos componentes. Outro problema é a demora em
estimar todos os componentes, pois há necessidade de uma análise de requisitos mais
detalhada e um planejamento detalhado das tarefas do projeto de sistema. Assim, a estimativa
bottom-up é também mais dispendiosa comparada aos demais tipos de estimativa. Contudo, a
análise mais detalhada permite que a estimativa seja mais precisa (SOMMERVILLE, 2004, p.
443).
A estimativa bottom-up pode ser combinada com outros tipos de estimativas como a analogia
com outros projetos e a experiência do especialista para aumentar sua precisão. Modelos
podem ser construídos combinando pequenos pedaços do projeto, e a analogia pode ser
aplicada para reunir estimativas semelhantes para cada parte de um produto ou processo maior
(FENTON; PFLEEGER, 1997, p. 434).
Com um projeto maior, o processo de dividir em tarefas costuma tornar-se repetitivo: cada
tarefa será analisada em subtarefas que ainda poderão ser divididas em outras subtarefas e
assim por diante. Isto é repetido até se encontrar os componentes que podem ser executados
por indivíduos distintos em, aproximadamente, uma semana ou duas. O WBS6 (Work
breakdown structure) é utilizado pela estimativa bottom-up como uma maneira de detalhar o
projeto de software (HUGHES; COTTERELL, 1999, p. 86).
Como a estimativa bottom-up detalha o projeto de software, ela se torna apropriada para ser
utilizada pela gerência do projeto. Assim, a gerência então pode atuar sobre o projeto para
5 Componentes específicos é referente a implementação de interfaces com um novo tipo de hardware, ou com outro software. 6 Em gerenciamento de projetos, uma WBS é método de decomposição do trabalho do projeto em partes manejáveis. Em português, às vezes é traduzida como Estrutura Analítica do Projeto, embora o termo WBS seja mais amplamente utilizado. Por esse motivo, o termo WBS será adotado no contexto deste trabalho.
32
evitar atrasos baseados nos pontos críticos do projeto. Os pontos críticos podem ser derivados
das tarefas detalhadas pela estimativa bottom-up7. Se este método é usado antecipadamente no
ciclo de projeto então o gerente poderá fazer algumas suposições aproximadas das
características do sistema final, como por exemplo tamanho dos módulos do software.
(HUGHES; COTTERELL, 1999, p. 86).
Quando não há projetos concluídos ou não há dados históricos utilizáveis, pode-se usar a
estimativa bottom-up como um caminho mais seguro para estimar um projeto de software.
(HUGHES; COTTERELL, 1999, p. 86).
2.2.2 ESTIMATIVA TOP-DOWN
A estimativa top-down inicia com uma visão geral do produto para, depois, estimar as partes
(componentes, tarefas, atividades) do projeto. Estimativas para os componentes são calculadas
como partes relacionadas com a estimativa total. O gerente inicia examinando a
funcionalidade geral do produto e como essa funcionalidade pode ser decomposta em
subfunções que interagem entre si. O tamanho de atividades globais, como integração,
gerenciamento de configuração e documentação são levados em conta (SOMMERVILLE,
2004, p. 443; FENTON; PFLEEGER, 1997, p. 434).
A estimativa top-down pode subestimar o tamanho para a resolução de problemas técnicos
difíceis, associados com componentes específicos. Um programador pode demorar mais em
desenvolver um algoritmo de um módulo, pois não compreende uma regra de negócio
(SOMMERVILLE, 2004, p. 443). Desta forma, existe o problema de designar proporções
para os esforços de cada tarefa dentro do projeto (HUGHES; COTTERELL, 1999, p. 86).
Para calcular o esforço, a estimativa top-down pode utilizar fórmulas, como a definida abaixo
(1):
Esforço = (tamanho do sistema) * (valor da produtividade) (1)
Tamanho do sistema: Tamanho em linhas de código, pontos de função ou pontos de caso de
uso.
Valor da produtividade: Quantidade de horas, semanas, meses, anos para cada unidade de
tamanho.
7 Pode ser utilizado método como o PERT para determinar o caminho crítico, permitindo um maior controle sobre possíveis atrasos no projeto.
33
Por exemplo, o tamanho do sistema pode ser em forma de “milhares de linhas de código”
(KLOC) e o valor de produtividade de dias por KLOC (HUGHES; COTTERELL, 1999, p.
86).
As estimativas top-down e bottom-up não são mutuamente exclusivas. Gerentes de projetos,
provavelmente, irão utilizar um número diferente de estimativas, pessoas e métodos, podendo
ainda, fazer uma inter-relação entre elas. A gerência pode dividir o projeto em duas ou mais
partes onde em uma parte seria adotada a estimativa top-down e em outra a estimativa bottom-
up (HUGHES; COTTERELL, 1999, p. 86).
2.2.3 EXPERIÊNCIA DE UM ESPECIALISTA
A opinião de um especialista refere-se às previsões feitas com base em experiências passadas.
Usualmente, esta abordagem pode resultar em uma estimativa precisa. Somente quando os
projetos são parecidos com os quais o especialista já tenha participado (SOMMERVILLE
1996, p. 596).
Um problema com esse tipo de estimativa é que ela é totalmente dependente da experiência
do especialista. Se o especialista sair da empresa ou desenvolver um software em uma área
diferente do que costuma desenvolver, ou trocar a tecnologia utilizada para o seu
desenvolvimento, à empresa não terá mais a mesma precisão para estimar projetos até que
outro especialista compreenda o processo da empresa. Entretanto, o problema pode ser
minimizado com uma gestão de conhecimento adequada, permitindo a recuperação destas
experiências.
A opinião de um especialista tem como vantagem, a maturidade de sua experiência pessoal.
Ao usar esta técnica, um desenvolvedor ou gerente descreve os parâmetros do projeto a ser
empreendido, e o especialista faz a predição baseada em experiências passadas. O especialista
pode ainda usar ferramentas, modelos ou outros métodos para estimativas genéricas
(FENTON; PFLEEGER, 1997, 434).
Ao mudar um software já existente a tendência é usar a experiência de um especialista para
fazer a estimativa de tamanho. O especialista, provavelmente, já participou do projeto original
e, por isso, pode estimar com mais precisão o tamanho da mudança no software (HUGHES;
COTTERELL, 1999, p. 86).
34
A experiência de um especialista aparenta ser simplesmente um meio de adivinhação do
tamanho do projeto de software, mas na verdade, a sua experiência pode ser utilizada em
conjunto com a estimativa por analogia (descrita na seção 2.2.4), onde a informação é obtida a
partir de projetos concluídos e que sejam parecidos. As estimativas bottom-up e top-down
(descritas respectivamente nas seções 2.2.1 e 2.2.2) também podem ser utilizadas pelo
especialista (HUGHES; COTTERELL, 1999, p. 86).
2.2.4 ESTIMATIVA POR ANALOGIA
Analogia é uma abordagem mais formal do que a opinião de um especialista. O gerente
compara o projeto proposto com um ou mais projetos anteriores. Diferenças e similaridades
são identificadas e usadas para ajustar a estimativa. O gerente, usualmente, identificará o tipo
de aplicação, estabelecerá uma previsão inicial e então refinará a previsão dentro de uma faixa
original (SOMMERVILLE 2004, p. 596).
Então, as diferenças são usadas para ajustar o valor do tamanho atual comparado a um projeto
passado. Esta técnica força os avaliadores descreverem um projeto em termos de
características chaves. Além disso, esta análise é usualmente documentada. Desse modo, é
possível ser comparado com outros tipos de estimativas. A documentação permite a revisão
para achar razões porque a estimativa pode não ter sido tão exata quanto era esperado.
“O uso de analogia é também chamado de raciocínio baseado em casos8” (HUGHES;
COTTERELL, 1999, p. 88). O gerente busca outros projetos que são os casos passados e que
tem características parecidas com o novo projeto. O tamanho registrado no projeto passado
pode então ser usado como uma base para a estimativa do projeto atual. O gerente poderá
então identificar qualquer diferença entre o novo projeto e o caso passado e fazer os ajustes
para a estimativa do novo projeto (HUGHES; COTTERELL, 1999, p. 88).
Um dos problemas deste tipo de estimativa está em como identificar as similaridades e as
diferenças entre os vários sistemas. Tentativas têm sido feitas para automatizar o processo.
Um meio de identificar as diferenças é utilizar a seguinte fórmula abaixo (2):
8 Por não ser tratar do foco deste trabalho, este assunto não será explorado neste trabalho, porém uma ampla discussão sobre o mesmo pode ser encontrada em GRESSE VON WANGENHEIM, Christiane; VON WANGENHEIM, Aldo. Raciocínio Baseado em Casos. Editora Manole, 2003, 300p.
35
( )∑=
−=n
iii origemparâmetroatualparâmetroDistância
1
2__ (2)
Onde o “parâmetro_atual” é um vetor com as entradas do sistema e as saídas do sistema a ser
implementado e o “parâmetro_origem” é um vetor com as entradas e as saídas do sistema de
um projeto concluído.
2.3 CONCLUSÃO DO CAPÍTULO
Este capítulo apresentou inicialmente a motivação para estimar projetos de software,
considerando o tamanho. Foram discutidos quatro tipos de estimativa utilizados em projetos
de software, cada um com suas características específicas. Porém, torna-se relevante ressaltar
que o foco deste capítulo foi na definição de estimativas e nos tipos que podem ser utilizados.
Entretanto, não foi abordado como as estimativas podem ser feitas. Este será o objetivo do
capítulo seguinte.
O próximo capítulo apresenta três métodos de estimativa utilizados em projetos de software.
Todos os três poderiam ser aplicados em projetos orientado a objeto, mas apresenta-se,
durante o capítulo, a motivação para a adoção do método de estimativa por pontos de casos de
uso.
36
3 MÉTODOS DE ESTIMATIVA
Como comentado anteriormente, o capítulo 2 apresentou quatro tipos de estimativa, mas não
indicou como as estimativas devem ser feitas. Neste sentido, este capítulo discute três
métodos de estimativa: APF (análise por pontos de função), COCOMO (Constructive Cost
Model) e UCP (pontos por casos de uso). Cada um destes modelos está focado em
determinados aspectos da estimativa: requisitos e funcionalidades, esforço, tamanho do
sistema respectivamente.
O APF e UCP são baseadas no tipo de estimativa top-down, o COCOMO é um modelo
matemático baseado em estudos de caso de projetos passados. Contudo, mesmo sendo
baseado em um tipo de estimativa os métodos podem ser utilizados em conjunto com outros
tipos de estimativa. Os métodos não são apenas exemplos da aplicação de um determinado
tipo de estimativa.Os métodos utilizam, usualmente, combinações dos tipos mostrados no
capítulo 2. As próximas seções apresentam estes métodos.
3.1 ANÁLISE POR PONTO DE FUNÇÃO
Análise por pontos de função (APF) é uma estimativa do tipo top-dowm que foi desenvolvido
por Allan Albrecht quando ele trabalhava na IBM (HUGHES; COTTERELL, 1999, p. 89). É
um método para estimar o tamanho do software em pontos de função. O método APF é uma
forma estruturada de classificar os componentes de um sistema, dividindo o sistema em
componentes menores para que eles possam ser mais bem entendidos e analisados. O método
APF utiliza, basicamente, os requisitos funcionais para estimar o projeto de software,
oferecendo somente a estimativa do tamanho funcional. O objetivo é identificar as
funcionalidades requeridas para um projeto e contar as funcionalidades do comportamento
externo que irão requerer processamento (SCHAUM, 2003, p.61). É importante ressaltar que
o método APF é independente de tecnologia que será utilizada para o desenvolvimento
selecionado, o número de pontos de função será o mesmo (VENUGOPALAN, 2004).
37
O método APF considera cinco componentes de um projeto: entrada externas, saídas externas,
consultas externas, arquivos lógicos internos (ou entidades9) e interfaces externas. Para cada
protótipo de tela é possível estimar um número de pontos de função realizando um cálculo
sobre a quantidade de arquivos lógicos (internos e externos) acessados, o número de entradas
e as saídas externas, além do número de consultas (FREIRE, 2003, p.1; HUGHES;
COTTERELL, 1999, p. 89).
As entradas externas são transações de entrada da aplicação de dados suprida pelo programa,
e que atualiza os arquivos internos do computador. A entrada externa é considerada um item e
os campos individuais não são contados separadamente. Por exemplo, a entrada de dados
pessoais (nome, data de nascimento...) para o cadastro de um novo funcionário pode ser
considerada uma entrada (HUGHES; COTTERELL, 1999, p. 89; SCHAUM, 2003, p. 61).
As saídas externas são transações onde dados de saída da aplicação são exibidos. Pode ser um
relatório, uma tela ou uma mensagem de erro. Os campos individuais não são considerados
saídas separadas (SCHAUM, 2003, p. 61; HUGHES; COTTERELL, 1999, p. 89).
As consultas externas são transações iniciadas por um usuário, sendo composta por pares de
solicitação-resposta que não alteram os dados internos. Por exemplo, a solicitação pelo
endereço de um funcionário específico é considerada uma consulta (SCHAUM, 2003, p. 61;
HUGHES; COTTERELL, 1999, p. 89).
Os arquivos lógicos internos são os arquivos usados pelo sistema. Para contagem de pontos de
função o arquivo refere-se à um grupo de dados que é acessado de forma agrupada, como os
dados pessoais de um funcionário (SCHAUM, 2003, p. 62; HUGHES; COTTERELL, 1999,
p. 89).
Tabela 1 Definição dos pesos dos componentes de acordo com a sua complexidade. Componente Pesos
Baixa Médio Alta Entrada externa 3 4 6 Saídas externas 4 5 7 Arquivo lógico interno 7 10 15 Interface externa 5 7 10 Consulta externa 3 4 6
Fonte: HUGHES; COTTERELL (1999, p. 90) e SCHAUM (2003, p. 62).
As interfaces externas são dados que são compartilhados com outros programas. Por exemplo,
um arquivo pessoal pode ser usado pelo sistema de recursos humanos e para o sistema de
9 Pode ser considerado como entidade quando o projeto utiliza a abordagem orientada a objeto.
38
contabilidade. Então, ele pode ser considerado uma interface com ambos os sistemas.
(SCHAUM, 2003, p. 62; HUGHES; COTTERELL, 1999, p. 89).
Para cada um dos cinco componentes, é atribuído um determinado peso que varia de acordo
com uma classificação de complexidade. Os graus utilizados para definir a complexidade são:
alta, média e baixa a tabela 1 apresenta os pesos que devem ser considerados para cada um
dos componentes de acordo com a complexidade.
Tabela 2 Cálculo do número não ajustado pontos de função. PFB = EE + SE + CE + ALI + AIE
Variáveis Significado PFB Número não ajustado de pontos de função EE Somatória do fator de multiplicador de entrada externa SE Somatória do fator de multiplicador de saída externa CE Somatória do fator de multiplicador de consulta externa ALI Somatória do fator de multiplicador arquivo lógico interno AIE Somatória do fator de multiplicador interface externa
Fonte: HUGHES; COTTERELL (1999, p. 90); SCHAUM (2003, p. 62).
Dessa forma, para se obter o valor total em pontos de função, deve-se encontrar a quantidade
de elementos no projeto que podem ser agrupados em um dos cinco componentes e classificá-
los de acordo com sua complexidade. Depois, basta multiplicar a quantidade encontrada pelo
respectivo peso. O valor total em pontos de função indicará o tamanho do processo da
informação. A fórmula é descrita na tabela 2.
Tabela 3 Definição da complexidade para arquivos internos usada pelo IFPUG. Número de Nº de dados referenciados registros lógicos <20 20 até 50 >50
1 Baixo Baixo Médio 2 até 5 Baixo Médio Alta
>5 Médio Alta Alta Fonte: HUGHES; COTTERELL (1999, p. 90); IFPUG (1999, p. 7-06).
Tabela 4 Definição da complexidade para entradas externas usadas pelo IFPUG. Nº de arquivos Nº de dados referenciados Referenciados <5 5 até 15 >15
0 ou 1 Baixo Baixo Médio 2 Baixo Médio Alta
>2 Médio Alta Alta Fonte: HUGHES; COTTERELL, (1999, p. 91); IFPUG (1999, p. 7-06).
“Não há padrão para contar pontos de função e livros têm sido escritos com diferentes regras
de contagem” (SCHAUM, 2003, p. 62). A APF tenta medir o tamanho do novo projeto de
software. Entretanto, o Grupo Internacional de Usuários de Pontos de Função (IFPUG –
International Function Points Users Group) tem uma regra para definir se a complexidade do
componente “arquivo lógico interno” ou “interface externa” é baixa, média ou alta. A regra
39
utiliza a relação entre os tipos de registro e os tipos de dados conforme a tabela 03 (HUGHES;
COTTERELL, 1999, p. 90).
Tabela 5 Definição da complexidade para saídas externas usadas pelo IFPUG. Nº de arquivos Nº de dados referenciados Referenciados <6 6 até 19 >19
0 ou 1 Baixo Baixo Médio 2 ou 3 Baixo Médio Alta
>3 Médio Alta Alta Fonte: HUGHES; COTTERELL, (1999, p. 91); IFPUG (1999, p. 7-06).
Tabela 6 Definição da complexidade para consultas externas usadas pelo IFPUG. Nº de arquivos Nº de dados referenciados Referenciados <5 6 até 19 >19
0 ou 1 Baixo Baixo Médio 2 ou 3 Baixo Médio Alta
>3 Médio Alta Alta Fonte: IFPUG , (1999, p. 7-22); IFPUG (1999, p. 7-06).
Tabela 7 Características gerais do sistema. Descrição da característica Peso Insuficiente Mínima Moderada Média Alta Essencial Requer cópias de segurança confiáveis? 0 1 2 3 4 5 O sistema requer comunicação de dados? 0 1 2 3 4 5 Existe processamento distribuído de funções?
0 1 2 3 4 5
O desempenho é um aspecto crítico? 0 1 2 3 4 5 Ambiente de execução tem grande carga de processamento?
0 1 2 3 4 5
O sistema requer entrada on-line? 0 1 2 3 4 5 As transações on-line são eficientes para o usuário?
0 1 2 3 4 5
Os arquivos são utilizados on-line? 0 1 2 3 4 5 Configuração e utilização de equipamento? 0 1 2 3 4 5 O processamento é complexo? 0 1 2 3 4 5 O código é projetado/construído para ser reutilizado?
0 1 2 3 4 5
O projeto inclui conversões ou instalações? 0 1 2 3 4 5 O sistema é projetado para o uso em múltiplas instalações em diferentes organizações?
0 1 2 3 4 5
O sistema é projetado para ser de fácil utilização e para facilitar mudanças?
0 1 2 3 4 5
Fonte: IFPUG , 1999, p. 8-4
Para a definição da complexidade dos componentes “entradas externas”, “saídas externas” e
“consultas externas”, utiliza-se a relação entre o número de arquivos referenciados10 e o
número de dados referenciados11 conforme, respectivamente, as tabelas 4, 5 e 6.
10 O número de arquivos referenciados podem ser arquivos em disco ou tabelas de um banco de dados.
40
Após ter calculado o número não ajustado de pontos de função (tabela 2), pode-se calcular o
número ajustado de pontos de função. Para ajustar o resultado obtido é usado o NI (nível de
influência), o qual é obtido a partir de 14 características gerais do sistema (tabela 7). Para
cada característica, é atribuído um peso que varia entre 0 e 5, onde: 0 = insuficiente, 1 =
mínima, 2 = moderada, 3 = média, 4 = alta e 5 = essencial. A somatória dos pesos é o valor de
NI.
Depois de somados todos os pesos das características do sistema para o NI, então é possível
calcular o FA (fator de ajuste), seguindo a fórmula abaixo (3):
FA = NI/100 + 0,64 (3)
onde:
FA = fator de ajuste
NI = nível de influência
Por fim, o número ajustado de pontos de função é calculado multiplicando o FA (fator de
ajuste) pelos PFB (número não ajustado de pontos de função). Conforme a fórmula abaixo
(4).
PF = PFB x FA (4)
onde:
PF = número ajustado de pontos de função.
PFB = número não ajustado de pontos de função.
FA = fator de ajuste.
O método APF estima o tamanho em pontos de função. Neste sentido é necessário um
levantamento histórico na empresa para ajustar o esforço em relação a pontos de função.
Sugere-se usar 15 homens/mês por ponto de função como medida de esforço. O custo irá
depender de quanto é pago para o profissional que irá desenvolver o software. Além de outros
fatores não discutidos neste trabalho12. Para melhor compreensão do cálculo usado no método
APF, a próxima seção apresenta um exemplo.
11 Os dados referenciados são, por exemplo, os campos de uma tabela de um banco de dados, em uma tabela pessoa, os dados seriam o nome da pessoa, a idade e o sexo. 12 Fatores do tipo: recursos de materiais necessários, análise de risco entre outros.
41
3.1.1 EXEMPLO DE APLICAÇÃO DE APF
Considere o cadastro de um funcionário, o qual deve conter o nome do funcionário, endereço
(rua, número, bairro, cidade, estado, pais), telefone residencial, setor, ramal principal e o
número do funcionário. Considerando também que os setores já estão cadastrados, o cadastro
de funcionário deve permitir que um setor seja selecionado. A partir do setor que foi
selecionado, será apresentada uma lista com seus respectivos ramais, permitindo que o
operador do sistema possa selecionar o ramal que será utilizado durante a jornada de trabalho
do funcionário. O número do funcionário deve ser gerado pelo sistema para evitar que dois
funcionários tenham o mesmo número.
Tabela 8 Contabilização de fatores. Comp. Qtde. Descrição EE 1 O cadastro dos dados do funcionário. SE 1 Os setores exibidos para ser selecionado com seu respectivo ramal. CE 2 Os setores a serem exibidos.
Os ramais conforme o setor selecionado. ALI 1 Arquivo (ou tabela de banco de dados) onde serão gravados os dados do funcionário. AIE 0 Não acessa sistema externo.
Com posse desses dados, o primeiro passo para calcular APF é contabilizar as EE (entradas
externas), SE (saída externas), CE (consultas externas), ALI (arquivo lógico interno) e AIE
(interface externa). Conforme a descrito na tabela 8.
Com base nas tabelas 3, 4, 5 e 6 temos o fator multiplicador de cada componente conforme a
classificação dos componentes. A tabela 9 mostra o cálculo de cada fator. A obtenção dos
pontos de função brutos é advinda da soma dos fatores conforme mostra a tabela 10.
Tabela 9 Soma dos fatores individuais. Comp. Classificação Multiplicador Cálculo Total
EE Simples 3 1 x 3 3 SE Simples 4 1 x 4 4 CE Simples 7 2 x 7 14 ALI Simples 3 1 x 3 3 AIE Simples 5 0 x 5 0
Conforme a tabela 10, o número não ajustado de pontos de função ou número bruto de pontos
de função é igual a 34. Para calcular o número ajustado de pontos de função, é preciso
calcular antes, o nível de influência. Este nível é calculado pela somatória dos pesos dados às
características do sistema, utilizando-se uma faixa de 0 à 5 como demonstrado na tabela 11.
42
Tabela 10 Número bruto de pontos de função. Soma dos fatores PFB 3+ 4+ 14+ 3+0 24
Tabela 11 Respostas aos níveis de influência. Perguntas Peso
Requer cópias segurança confiáveis? 5 O sistema requer comunicação de dados? 1 Existe processamento distribuído de função? 0 O desempenho é um aspecto crítico? 2 Ambiente de execução tem grande carga de processamento? 1 O sistema requer entrada on-line? 5 As transações on-line são eficientes para o usuário? 4 Os arquivos são utilizados on-line? 5 Configuração e utilização de equipamento? 5 O processamento é complexo? 1 O código é projetado/construído para ser reutilizado? 2 O projeto inclui conversão ou instalações? 4 O sistema é projetado para o uso em múltiplas instalações em diferentes organizações? 1 O sistema é projetado para ser de fácil utilização e para facilitar mudanças? 4
Após o somatório dos pesos descritos na tabela 11, o valor de NI é igual a 40. Com isso,
podemos calcular o fator de ajuste demonstrado na tabela 12.
Tabela 12 Cálculo do fator de ajuste. Cálculo Fator de Ajuste
(40 / 100) + 0,64 1,04
Com FA (fator de ajuste) e FPB (número bruto de pontos de função), pode-se calcular o
número ajustado de pontos de função como demonstrado na tabela 13.
Tabela 13 Número ajustado de pontos de função Cálculo PFA-Número ajustado de pontos
de função 24 x 1,04 24,96
Para calcular o esforço, é preciso saber o quanto de esforço é necessário para cada ponto de
função. Isso varia de empresa para empresa e de acordo com a experiência da equipe de
desenvolvimento. Considerando que são gastas 4 pessoas/hora por ponto de função então
chega-se a (4 x 24,96) 99,84 pessoas/horas de esforço. Isto resultaria em quase um mês de
trabalho para uma pessoa (considerando que o mês tenha 176 horas).
O custo vai depender de quanto é pago para o profissional. Por exemplo, se o programador
ganha R$ 5,00 (cinco reais) por hora, o custo de programação seria de (99,84 x 5) R$ 499,20
43
reais (quatrocentos e noventa e nove reais e vinte centavos). Obviamente, existem outros
custos envolvidos: encargos, manutenção de equipamento, testes, modelagem, gerência e
outros custos. Entretanto, a partir da experiência de estimativa, estes outros custos podem ser
gradativamente embutidos no valor de uma pessoa/hora.
3.2 COCOMO
O COCOMO (COnstructive COst MOdel13) é um modelo de predição de esforço para o
cronograma do projeto de software usando uma fórmula básica onde os parâmetros são
determinados por um banco de dados contendo o histórico de projetos e as características do
atual projeto. Para fazer a estimativa são comparados as características do atual projeto e com
as características dos projetos passados (MAYHAUSER, 1990, p.707). Este modelo não
estima o tamanho do software a ser desenvolvido. Neste sentido se faz necessário utizar outra
técnica para a estimativa de tamanho.
Existe uma série de modelos algoritmos que foram propostos como base para estimar o esforço, os prazos e os custos de um projeto de software. Eles são conceitualmente semelhantes, mas utilizam diferentes valores de parâmetros. O modelo específico discutido aqui é denominado COCOMO (COnstructive COst MOdel), que é um modelo empírico. Ele foi derivado pela coleta de dados a partir de um grande número de projetos de software e, em seguida, pela análise desses dados para descobrir fórmulas que fossem mais adequadas às observações (SOMMERVILLE, 2004, p. 443).
Segundo Sommerville (2004, p. 443) as vantagens de utilizar o método COCOMO são:
• Ele é bem documentado, de domínio público, e é compatível com ferramentas
comerciais e de domínio público.
• Ele tem sido amplamente utilizado e avaliado.
• Tem uma longa linhagem, desde sua primeira verão, lançada 1981, seguindo um
aperfeiçoamento ajustado ao desenvolvimento de software em Ada, até sua mais
recente versão, publicada em 1995.
3.2.1 COCOMO 81
A primeira versão do modelo COCOMO (conhecido como COCOMO 81) possui três níveis.
O nível básico fornecia uma estimativa preliminar. O nível intermediário modificava essa
13 Modelo de custo construtivo.
44
condição, utilizando uma série de multiplicadores de projeto e processo. O nível avançado
produzia estimativas para diferentes fases do projeto. (FENTON; PFLEEGER, 1997, p. 434).
O COCOMO usa a seguinte fórmula básica (5):
E = a Sb F (5)
Onde:
E = esforço em mês.
S = Tamanho medido em milhares de instruções de código previsto em KLOC.
F = Fator de ajuste.
a14 = Valor empirico com base na pesquisa de Boehm. Valores descritos na tabela 14.
b = Valor empirico com base na pesquisa de Boehm. Valores descritos na tabela 14.
Tabela 14 Valores das variáveis a e b baseado no tipo de projeto Tipo de projeto a b Orgânico 2,4 1,05 Semi-vinculado 3,0 1,12 Embarcado 3,6 1,20
Fonte: FENTON; PFLEEGER (1997).
Perto da escolha do modo de desenvolvimento e aplicada a equação apropriada de esforço,
COCOMO produz uma estimativa preliminar de esforço. O modelo básico do COCOMO é
usado ao inicio do desenvolvimento.
Para a estimativa de esforço no modelo básico do COCOMO é necessário estimar o tamanho
do projeto em milhares de linhas de código (KLOC), determinar o tipo do projeto: orgânico,
semi-vinculado ou embarcado, determinar as variáveis a e b (ver tabela 14), calcular o esforço
E (em pessoa/mês) de acordo com a fórmula (6):
E= a(KLOC)b (6)
14 As variáveis ‘a’, ‘b’, ‘c’ e ‘d’ foram obtidas através de pesquisa de projetos de software feita por Boehm.
45
Para a estimativa de tempo de desenvolvimento é necessário calcular o esforço E de acordo
com o que foi descrito acima. Determinar as variáveis c e d de acordo com a tabela 15.
Calcular o tempo T (em meses) de acordo com a fórmula (7):
T = c(KLOC)d. (7)
Tabela 15 Valores das variáveis c e d baseado no tipo de projeto
Tipo de projeto c d Orgânico 2,5 0,8 Semi-vinculado 2,5 0,35 Embarcado 2,5 0,32
Fonte: FENTON; PFLEEGER (1997).
3.2.2 COCOMO II
A partir da década de 90, o modelo COCOMO ficou defasado e precisou ser remodelado. Por
isso, foi desenvolvido o modelo COCOMO 2 que reconhece diferentes abordagens de
desenvolvimento de software, como prototipação e o desenvolvimento pela composição de
componentes. Os níveis de modelo não refletem simplesmente estimativas cada vez mais
complexas e detalhadas. Os níveis estão associados com atividades no processo de software,
de modo que as estimativas iniciais podem ser feitas previamente no processo, com as
estimativas mais detalhadas sendo realizadas depois que a arquitetura do sistema foi definida.
Os níveis identificados no COCOMO 2 são:
• Nível inicial de prototipação. As estimativas de tamanho são feitas com base em
pontos de objetos, e uma fórmula simples de tamanho/produtividade é utilizada para
estimar o esforço requerido. Esta técnica captura o tamanho e o esforço generalizado,
como o número de serviços de tabelas do banco de dados (FENTON; PFLEEGER,
1997, p. 434; HUGHES; COTTERELL, 1999, p. 97; SOMMERVILLE, 2004, p. 443).
• Nível inicial de projeto. Esse nível corresponde à conclusão dos requisitos do sistema
com algum projeto inicial. Utiliza pontos de função como medida, que são, então,
convertidos para o número de linhas de código-fonte. (FENTON; PFLEEGER, 1997,
p. 434; HUGHES; COTTERELL, 1999, p. 97; SOMMERVILLE, 2004, p. 443).
Nível pós-arquitetura. Uma vez projetada a arquitetura do sistema, uma estimativa mais
precisa do tamanho do software pode ser feita. A estimativa desse nível utiliza um conjunto
mais amplo de multiplicadores, refletindo a capacidade pessoal, as características de produto e
46
de projeto (FENTON; PFLEEGER, 1997, p. 434; HUGHES; COTTERELL, 1999, p. 97;
SOMMERVILLE, 2004, p. 443).
3.2.2.1 Nível inicial de prototipação
O nível inicial de prototipação foi introduzido no COCOMO para apoiar a realização de
estimativas de esforço necessário para projetos de prototipação e para projetos em que o
software é desenvolvido pela composição dos componentes existentes. A produtividade do
programador depende de sua experiência e capacidade de usar as ferramentas CASE para
apoiar o desenvolvimento. A tabela 16 mostra a produtividade sugerida pelo modelo
COCOMO (SOMMERVILLE, 2004, p. 443).
Este modelo considera o número de pontos de objeto utilizado na estimativa de prazos que é
ajustado para levar em conta a percentagem de reuso (% de reuso) esperada. Portanto, a
fórmula (8) final para o cálculo do prazo é:
PM = (NPO X (1- % reuso/100))/ PROD (8)
Onde:
PM = Esforço medido em pessoa-mês.
NPO = número de pontos por objeto.
PROD = produtividade.
O PROD é calculado a partir da tabela 16:
Tabela 16 Produtividade por pontos de objetos Experiência e capacitação do desenvolvedor
Muito baixa Baixa Nominal Alta Muito Alta
Maturidade e capacitação de CASE
Muito baixa Baixa Nominal Alta Muito Alta
PROD (NPO/mês) 4 7 13 25 50 Fonte: SOMMERVILLE (2004).
3.2.2.2 Nível inicial de projeto
No nível inicial do projeto as estimativas produzidas se baseiam na seguinte fórmula-padrão
(9) para os modelos algorítmicos:
47
Esforço = A x TamanhoB x M (9)
Boehm propôs que o coeficiente A deve ser 2,5 para as estimativas feitas nesse nível. O
tamanho do sistema é expresso em KSLOC, ou seja, o número de milhares de linhas de
código-fonte. Esse número é calculado estimando-se o número de pontos de função no
software e convertendo-o para KSLOC, com a utilização de tabelas15, que relacionam o
tamanho do software a pontos de função, para diferentes linguagens de programação. Essa
estimativa de tamanho se refere ao código que é implementado manualmente, em vez de ser
gerado ou reutilizado (SOMMERVILLE, 2004, p. 443).
O expoente B reflete o esforço aumentado, requerido à medida que o tamanho do projeto
aumenta. Esse expoente não é fixo, como na primeira versão do COCOMO, mas pode variar
de 1,1 a 1,24, dependendo da novidade do projeto, da flexibilidade de desenvolvimento, dos
processos de resolução de riscos utilizados, da coesão da equipe de desenvolvimento e do
nível de maturidade de processo da organização (SOMMERVILLE, 2004, p. 443) .
Tabela 17 Direcionadores de cálculo Sigla Descrição Muito
Baixo Baixo Normal Alto Muito
Alto Extra Alto
RCPX confiabilidade e complexidade do produto
0,75 0,88 1 1,09 1,13 1,66
RUSE reuso requerido - 0,91 1 1,14 1,29 1,49 PDIF dificuldade de plataforma - 0,87 1 1,06 1,21 1,57 PERS capacitação pessoal 1,24 1,1 1 0,83 0,67 - PREX experiência pessoal 1,22 1,10 1 0,88 0,81 - SCED Prazo 1,29 1,1 1 1 1 1 FCIL recursos de suporte 1,24 1,10 1 0,86 0,72 0,78
Fonte: HUGHES; COTTERELL (1999, p. 103).
O multiplicador M baseia-se em um conjunto simplificado de sete direcionadores de
processos derivados descritos na tabela 17 (SOMMERVILLE, 2004, p. 443).
Utiliza-se as seguintes fórmulas (10 e 11):
PM = A x TamanhoB x M + PMm, (10)
M = RCPX x RUSE x PDIF x PERS x PREX x SCED x FCIL (11)
15 Estas tabelas são oriundas de bases históricas das empresas, sendo assim o valor da conversão muda de empresa para empresa.
48
O último termo na fórmula (PMm) é um fator utilizado quando uma percentagem significativa
do código é gerada automaticamente. Geralmente os código são gerados por ferramentas que
transcrevem uma modelagem do sistema para código.
Utilizando-se a seguinte fórmula para calcular o PMm(12):
PMm = (ASLOC x (AT/100))/ATPROD (12)
Onde,
ASLOC = número de linhas de código-fonte geradas automatizadas.
ATPROD = nível de produtividade para esse tipo de produção de código.
AT = o esforço exigido para modificar o código gerado automaticamente.
3.2.2.3 Nível pós-arquitetura
Tabela 18 Atributos de esforço Tipo modificado código Esforço modificado Atributos de RELY Confiança nos requisitos de software. produto DATA Tamanho no banco de dados DOCU Documentação igual ao ciclo de vida necessário CPLX Complexidade do produto REUSE Reusabilidade dos requisitos Atributos de TIME Restrição do tempo de execução Plataforma STOR Restrição de memória PVOL Volatibilidade de plataforma Atributos de ACAP Capacidade de analise Pessoal AEXP Experiência no aplicativo PCAP Capacidade do programador PEXP Experiência na plataforma LEXP Experiência na linguagem de programação PCON Continuidade do pessoal Atributo de TOOL Usa ferramentas de software projeto SITE Desenvolvimentos em vários lugares SCED Redução do cronograma de desenvolvimento
Fonte: HUGHES; COTTERELL (1999, p. 103).
As estimativas produzidas no nível pós-arquitetura têm como base a mesma fórmula básica
utilizada nas primeiras estimativas de projeto. Contudo, são utilizados 17 atributos (ver tabela
18), em vez de 7, para aperfeiçoar o cálculo do esforço inicial (SOMMERVILLE, 2004, p.
443).
A estimativa do número total de linhas de código-fonte é ajustada para levar em conta dois
importantes fatores de projeto:
49
• A volatilidade dos requisitos. Para fazer uma estimativa do re-trabalho que pode ser
necessário para adequar as mudanças nos requisitos do sistema. Essa estimativa é
expressa como o número de linhas de código-fonte que possivelmente será
modificado.
• A possível extensão do reuso. Usado para estimar a quantidade de número de linhas
de código-fonte que serão reutilizadas no sistema e que precisam ser corrigidas.
Utiliza-se a seguinte fórmula (13):
ESLOC = ASLOC x ( AA + SU + 0,4DM + 0,3CM + 0,3 IM)/100 (13)
Onde,
ESLOC = número equivalente de linhas resultantes da modificação do código.
ASLOC = número de linhas de código reutilizável à ser modificado.
DM = percentagem do projeto modificado.
CM = percentagem do código que foi modificado.
IM = percentagem do esforço original de integração requerido para integrar o software reutilizado.
SU = fator que tem como base o custo de entendimento do software, que varia de 50, para os códigos não estruturados complexos, até 10, para os códigos orientados a objetos, escritos adequadamente.
AA =fator que reflete os custos da avaliação inicial para decidir se o software pode ser utilizado. Ele depende da quantidade de teste e da avaliação requerida. Seu valor varia de 0 a 8.
Tabela 19 Fatores do expoente Fator de escala Descrição Precedência Reflete a experiência prévia da organização com o tipo de projeto. Muito baixo
significa nenhuma experiência prévia; Extra alto significa que a organização está inteiramente familiarizada com esse domínio da aplicação.
Flexibilidade de desenvolvimento
Reflete o grau de flexibilidade no processo de desenvolvimento. Muito baixo significa que um processo prescrito é utilizado; extra alto significa que o cliente apenas estabelece objetivos gerais.
Resolução de arquitetura/risco
Reflete a extensão da análise de risco realizada. Muito baixo significa pouca análise; extra alto significa uma análise de risco completa e abrangente.
Coesão da equipe Reflete o quanto os membros da equipe de desenvolvimento se conhecem bem e trabalham juntos. Muito baixo significa interações muito difíceis; extra alto significa uma equipe integrada, e eficaz, sem problemas de comunicação.
Maturidade do processo
Reflete o processo de maturidade da organização. O cálculo desse valor depende do questionário de maturidade de CMM, mas uma estimativa pode ser feita subtraindo-se de 5 o nível de maturidade de processo de CMM.
Fonte: (SOMMERVILLE, 2004, p. 443).
O expoente é estimado considerando cinco fatores em escala, como mostra a tabela 19 acima.
Esses fatores são classificados em uma escala de 6 pontos, desde muito baixo até extra alto (0
a 5). As classificações resultantes são acrescentadas, divididas por 100, e o resultado é
somado a 1,01 para fornecer o valor do expoente (SOMMERVILLE, 2004, p. 443).
50
Tabela 20 Comparação do modelo original com o novo modelo COCOMO Aspecto do modelo
COCOMO original
COCOMO 2.0 Estágio 1
COCOMO 2.0 Estágio 2
COCOMO 2.0 Estágio 3
Tamanho Quantidade de intruções de máquina (DSI) ou Linhas de código (SLOC ou equivalente)
Pontos de objeto Pontos de função (FP) e linguagem.
FP e linguagem ou SLOC
Uso Equivalente a SLOC Implícito no modelo
% de uso não modificado, % de uso modificado (determinado por funções)
Equilalente a SLOC como funções de outras variáveis
Quebra Requisitos voláteis Modelo implícito
% de quebra % de quebra (atraso)
Manutenção Tráfico de mudança anual (ACT) = % de adição + % modificado
Pontos de objeto ACT
Modelo de uso Modelo de uso
Escala (b) em normal equação de uso
Organização: 1.05 meio separado 1.12, embarcado 1.20
1.0 1.02 para 1.26 depende da precedência, conformidade, arquitetura precoce, resolução de riscos, coesão da equipe, processo de maturidade da SEI
1.02 para 1.26 depende da precedência, conformidade, arquitetura precoce, resolução de riscos, coesão da equipe, maturidade do processo SEI
Produtos de tipos de custo
Confiança, tamanho do banco de dados, complexidade do produto
Não tem Complexidade, habilidade requerida
Confiabilidade, tamanho do banco de dados, documentação necessária, complexidade do produto.
Base para tipos de custo
Limite do tempo de execução, restrição do armazenamento principal, valatibilidade da maquina virtual, tempo de turnaround do computador
Não há Dificuldade de plataforma
Restrição do tempo de execução, restrição do armazenamento principal, volatibilidade da maquina virtual
Tipos de custo pessoal
Capacidade do analista, experiência de aplicativos, capacidade do programador, experiência na maquina virtual, experiência na linguagem de programação,
Não há Capacidade pessoal e experiência
Capacidade do analista, experiência de aplicativos, capacidade do programador, experiência do programador, experiência na ferramenta e na linguagem de programação, continuidade do pessoal
Tipos de custo de projeto
Usa modernas praticas de programação, usa ferramentas de software, lista de requisitos de desenvolvimento
Não há Lista de requisitos de desenvolvimento, desenvolvimento de ambiente.
Uso de ferramentas de software, lista de requisitos de desenvolvimento, desenvolvimento local
Fonte: (FENTON; PFLEEGER, 1997, p. 442).
51
Na tabela 20 é mostrado um comparativo entre o modelo original do COCOMO com os cada
um dos três níveis do COCOMO II. O modelo COCOMO é utilizado para se obter o esforço
necessário no desenvolvimento do software, este modelo não estima tamanho. Neste sentido é
necessário uma estimativa prévia do tamanho. Para melhor compreensão do cálculo usado no
método COCOMO, a próxima seção apresenta um exemplo no estágio 2 do COCOMO II.
3.2.3 EXEMPLO DE UTILIZAÇÃO DO COCOMO
Será utilizado o mesmo exemplo de cadastro de funcionário descrito na seção 3.1.1 (exemplo
de APF).
Para esse exemplo, é considerado a estimativa COCOMO para projeto em seu nível inicial
(ver seção 3.2.2.2). Então o primeiro passo é obter o tamanho do software a ser
implementado. Neste sentido será aproveitado o cálculo de APF descrito na seção 3.1.1 no
qual o número de pontos de função é igual a 35,36. Para conversão de pontos de função para
SLOC (linhas de código) utiliza-se uma tabela com a média de SLOC por ponto de função.
Neste caso é preciso saber a linguagem de programação utilizada, para esse exemplo iremos
considerar a ferramenta de programação Delphi, cuja a linguagem é o Object Pascal. Então
segundo Boehm (1997, p.26) para a linguagem Pascal é utilizado a conversão de 91 SLOC
por pontos de função. Por utilizar a ferramenta Delphi neste exemplo arredondamos para 80
SLOC por pontos de função.
Tabela 21 Conversão de KLOC para APF. Cálculo KLOC
24,96 x (90/1000) 2,24
O cálculo para a conversão de pontos de função para KLOC (milhares de linhas de código) é
descrito na tabela 21.
Tabela 22 Contabilização dos direcionadores de cálculo. Sigla Classificação Fator de
multiplicador RCPX Baixo 0,88 RUSE Baixo 0,91 PDIF Baixo 0,87 PERS Muito alta 0,67 PREX Muito alta 0,81 SCED Normal 1 FCIL Muito alto 0,72
52
O segundo passo é calcular o valor da variável M da fórmula 11 (ver seção 2.2.2). Sendo
assim, deve-se multiplicar os direcionadores de cálculo para obter o valor de M.
Na tabela 17 é atribuído uma classificação entre muito baixa e extra alta para cada
direcionador de cálculo. Conforme a classificação é definido um fator multiplicador conforme
mostra a tabela 22. Com os pesos definidos, multiplicam-se seus valores para obter o valor de
M conforme mostrado na tabela 23.
Tabela 23 Cálculo de M. Multiplicação dos pesos Valor de M
M = 0,88 x 0,91 x 0,87 x 0,67 x 0,81 x 1 x 0,72 0,27
Com posse dos valores do tamanho e da variável M, utiliza-se à fórmula 9 para calcular o
esforço em pessoa/mês conforme a tabela 24. Lembrando que o valor de A para este caso
(nível inicial de projeto) é fixo em 2,5. E a variável B tem valor 1,1 considerando que um
cadastro não representa novidade para equipe de desenvolvimento.
Tabela 24 Cálculo de esforço. Cálculo Valor em pessoas/mês
2,5 x (2,24)1,1 x 0.27 1,63
O esforço para esse exemplo é de 1,63 pessoa/mês (tabela 24). Considerando o mesmo custo
do exemplo descrito na seção 3.1.1 que é R$ 5,00 (cinco reais) por hora. Considerando que o
mês seja de 176 horas. O valor por pessoa é de 176 horas multiplicado por 5 reais que é igual
a R$ 880 reais por mês (176 x 5 = 880). Sendo assim, para esse exemplo, o custo da
implementação é calculado conforme mostrado na tabela 25.
Tabela 25 Cálculo de custo Cálculo Custo em R$
880 (reais) x 1,63 (p/m16) 1434,40
O custo deste software é de 1434,40 (mil quatrocentos e trinta e quatro reais e quarenta
centavos). Vale ressaltar que a diferença no custo calculado neste exemplo, em relação ao
anterior, (descrito na seção 3.1.1) deve-se ao fato do modelo COCOMO considerar também
outros custos como equipamentos usados, gerência entre outros. Entretanto, o modelo
16 p/m é igual a pessoa/mês.
53
COCOMO necessita de um histórico para que seja possível fazer os ajustes e tornar a
estimativa mais precisa.
3.3 ANÁLISE POR PONTOS DE CASO DE USO
A análise e projetos orientados a objetos (APOO) usualmente utilizam a UML (Unified
Modeling Language) para modelar um sistema futuro e os casos de uso servem como uma
forma de capturar as funcionalidades do sistema de software. Oferecendo um modo de
identificar o tamanho do futuro sistema. Os casos de uso estão cada vez mais sendo utilizados
na descrição de sistemas de software orientados a objetos, o que possibilita o uso dos casos de
uso para a estimativa (DAMODARAM, 2003, p.1; RIBU, 2001, p.1).
A análise por pontos de caso de uso utiliza os modelos de caso uso como entrada além da
complexidade dos casos de uso e nível de experiência da equipe de desenvolvimento. Sendo
assim, o modelo de análise por pontos de caso de uso é utilizado para estimar projetos de
software orientados a objetos.
Em 1993, o método de análise por pontos de caso de uso (UCP) para dimensionar e estimar
projetos orientados a objetos foi desenvolvido por Gustav Karner (RIBU, 2001, p.2),
(DAMODARAN, 2003, p.2). Este método é uma extensão do método de análise por pontos
de função e do método do método de análise por pontos de função Mk II (uma adaptação
bastante utilizada no Reino Unido) (RIBU, 2001, p.2) e é baseado na mesma filosofia destes
métodos. Ou seja, é que a funcionalidade vista pelo usuário é a base para a estimativa do
tamanho do software (RIBU, 2001, p.2).
Estimar tamanho num projeto é importante na conquista de mercados e clientes. A estimativa
de tamanho de um projeto de software ajuda na definição do cronograma do projeto de
software. Controlar o desenvolvimento do software e avaliar o desempenho dos
desenvolvedores e do avaliador.
Casos de usos é a descrição do “que” fazer no sistema antes de “como” o sistema faz,
conseqüentemente eles são mais robustos e menos mutáveis do que pontos de função ou
linhas de código. Casos de uso são artefatos, que os futuros usuários do sistema podem
utilizar para entender as funcionalidades do sistema sem que o sistema esteja pronto
(DAMODARAN, 2003, p.2).
O método pontos de casos de uso propõe uma estimativa de tamanho para o projeto de
desenvolvimento de software. Segundo o estudo de Damodaran (2003, p.2), o método de
54
estimação pontos de casos de uso pode ser utilizada para estimar o tamanho do software com
um nível baixo de erros na estimativas. Para calcular pontos de casos de uso é necessário
classificar os atores e os casos de uso, além de cálculo dos fatores de ajuste. E por fim o
cálculo de esforço17.
3.3.1 CLASSIFICANDO OS ATORES E CASOS DE USO
O primeiro passo para calcular os pontos de caso de uso é classificar os atores como simples,
médio ou complexo.
Um ator simples representa um sistema externo com uma API definida. Considerando um
projeto para o desenvolvido de um sistema de compras on-line, um bom exemplo de ator
simples seria a interface com o sistema financeiro, que seria responsável pela verificação do
crédito do cliente. Esse tipo de ator tem uma interface bem definida e é bastante previsível
quanto às suas reações, à saída proporcionada pelo sistema em questão ou à entrada que ele
recebe da interface (KARNER, 1993; RIBU, 2001, p. 20; DAMODARAN, 2003, p.3).
Um ator médio representa um sistema externo onde a comunicação é feita por meio de um
protocolo de comunicação como TCP/IP ou representa um sistema de hardware, onde a
interface de comunicação é também de alguma forma padronizada. Embora esses atores sejam
previsíveis, eles requerem mais esforço para controlá-los e usualmente são mais propensos a
erros (KARNER, 1993; RIBU, 2001, p. 20; DAMODARAN, 2003, p.3).
Atores complexos são aqueles atores que se enquadram na categoria “humano”. Este tipo de
ator é representando por uma pessoa interagindo através de uma tela (GUI – Graphic User
Interface) ou uma página web (KARNER, 1993; RIBU, 2001, p. 20; DAMODARAN, 2003,
p.3). Um bom exemplo seria um cliente (no caso de uma compra online) ou um funcionário
do financeiro. Esses atores são os mais difíceis de controlar e são totalmente imprevisíveis.
Embora uma GUI ou mesmo uma interface baseada em texto possa impor edições e controles,
há mais complexidade envolvida ao trabalhar com um ator desconhecido que mantém sua
própria vontade livre para fazer o que quiser.
Depois de classificar qual o tipo de ator o caso de uso terá, utiliza-se o fator ponderado para
cada tipo de ator conforme a tabela 26.
17 O cálculo de esforço irá de acordo com histórico de cada empresa.
55
Tabela 26 Classificação dos atores Complexidade do ator Fator ponderado (peso) Simples 1 Médio 2 Complexo 3
Fonte: RIBU, 2001, p.20.
O total ponderado não ajustados dos atores (UAW – unadjusted actor weights) é calculado
com a contagem de quantos atores existem em cada tipo (por grau de complexidade),
multiplicando cada total pelo seu fator ponderado, e adicionando todos os produtos (RIBU,
2001, p. 20; DAMODARAN, 2003, p.3).
O segundo passo para calcular os pontos de caso de uso é classificar os casos de uso como
simples, médio ou complexo.
Cada caso de uso é então definido como simples, médio ou complexo, dependendo do número
de transações descritas no do caso de uso, incluindo fluxos alternativos. Uma transação é um
conjunto de atividades que o sistema deve executar. Contar o número de transações pode ser
feito pela contagem dos passos de caso de uso.
Se houver alguma dúvida durante a definição da complexidade de um caso de uso, deve-se
adotar, na faixa de complexidade considerada, aquela de maior valor.
O aspecto primário dos casos de uso que deve ser julgado é referente a seus caminhos. O
número de caminhos determina o fator de peso. Os caminhos consistem do caminho normal
bem como dos caminhos alternativos ao longo dos casos de uso. Se houver um grande número
de caminhos de exceção primários, estes deverão também ser incluídos. Se as exceções forem
ocasionais ou simples situações de erro, não devem ser consideradas.
As extensões: inclui (includes), estende (extends), e generaliza (generalize) devem ser
incluídas no diagrama de caso de uso.
A complexidade do caso de uso é então definida e ponderada de acordo com a tabela 27.
Tabela 27 Complexidade do caso de uso Complexidade do caso de uso Transações Fator ponderado (peso)
Simples 1..3 5 Médio 4..7 10
Complexo 8..* 15 Fonte: RIBU, 2001, p. 20.
56
Outro mecanismo para medir a complexidade de um caso de uso é por meio da contagem das
classes de análise, as quais podem ser utilizadas no lugar de transações, uma vez que elas
determinam quais classes (ver tabela 28) implementam um caso de uso específico
(DAMODARAN, 2003, p.2).
Tabela 28 Complexidade do caso de uso por meio de classes Complexidade do caso de uso Nº de classes Fator ponderado (peso) Simples 1..5 5 Médio 6..10 10 Complexo 11..* 15
Fonte: RIBU, 2001, p. 20.
Cada tipo de caso de uso é então multiplicado pelo fator ponderado e os produtos são
adicionados para obter o total ponderado não ajustado dos casos de uso (UUCW – unadjusted
use case weight). O UAW é adicionado ao UUCW para obter o UUCP (unadjusted use case
points):
UAW+UUCW=UUCP (14)
Para obter um valor mais consistente pode calcular os fatores de ajuste conforme descrito na
próxima seção.
3.3.2 NÚMERO AJUSTADO DE PONTOS DE CASOS DE USO
O método também emprega um multiplicador para fatores técnicos correspondendo ao fator
de ajuste de complexidade técnica do método APF e um multiplicador para fatores ambientais
de modo a quantificar os requisitos não funcionais tais como facilidade de uso e motivação da
equipe. Vários fatores que influenciam a produtividade são associados com pesos e cada fator
é associado com um valor, dependendo do grau de influência daquele fator. A tabela 29
mostra o relacionamento entre os graus de influência e o valor associado a cada um
(KARNER, 1993; RIBU, 2001, p. 21; DAMODARAN, 2003, p.3).
Tabela 29 Grau de influência Grau de influência Avaliação Nenhuma 0 Média 3 Forte 5
Fonte: RIBU, 2001, p. 21.
Os fatores de ajuste são multiplicados pelo número não ajustado de pontos de caso de uso
para produzir o número ajustado de pontos, oferecendo uma estimativa de tamanho do
software.
57
3.3.2.1 Fatores técnicos
Tabela 30 Fatores de complexidade técnica Fator Descrição Peso T1 Sistema distribuído 2 T2 Tempo de resposta (desempenho) 2 T3 Eficiência do usuário final 1 T4 Complexidade do processamento interno 1 T5 Código reutilizável 1 T6 Facilidade de instalação 0.5 T7 Facilidade de uso 0.5 T8 Portabilidade 2 T9 Facilidade de alteração 1 T10 Necessidade de concorrência 1 T11 Aspectos especiais de segurança 1 T12 Conexão com outros sistemas 1 T13 Necessidade de treinamento especial para o usuário 1
Fonte: RIBU, 2001, p. 22.
O fator de complexidade técnica TCF (Technical Complexity factor) está relacionado com as
características técnicas do projeto, envolvendo basicamente os requisitos não funcionais. O
TCF é calculado pela multiplicação do valor de cada fator pelo seu peso e então todos estes
números são somados, criando o TFactor. A tabela 30 apresenta os fatores considerados e o
peso associado cam cada um (RIBU, 2001, p. 21; DAMODARAN, 2003, p.3).
Como visto na tabela de grau de influência (tabela 28), os valores associados com cada fator
podem assumir 0, 3 ou 5 e devem ser definidos com a seguinte orientação:
• O valor 0 significa que o fator é irrelevante no contexto do projeto.
• O valor 3 significa que o fator é relevante com um grau de influência média.
• O valor 5 significa que o fator é essencial para o sucesso do projeto.
A seguinte fórmula é aplicada (15):
TCF =0.6+(0.01*TFactor) (15)
Com o TCF calculado falta calcular o fator de ambiente.
3.3.2.2 Fatores de ambiente
O fator de ambiente (EF – Environmental Factor) está relacionamento com a experiência dos
membros da equipe do projeto. O EF é calculado pela multiplicação do valor de cada fator
pelo seu peso e então todos os produtos são somados, criando o EFactor. A tabela 31
apresenta os fatores considerados e o peso associado com cada um.
58
Tabela 31 Fatores de ambiente e seus respectivos pesos Fator
Descrição Peso
F1 A equipe é familiar com o processo formal de desenvolvimento que será utilizado 1.5 F2 Experiência da equipe com o tipo de aplicação 0.5 F3 Experiência da equipe com orientação a objetos 1 F4 Capacidade de analise chefe 0.5 F5 Motivação da equipe 1 F6 Estabilidade dos requisitos 2 F7 Trabalhadores em tempo parcial -1 F8 Dificuldade com a linguagem de programação escolhida 2
Fonte: RIBU, 2001, p. 22.
Como visto na tabela de grau de influência (tabela 29), os valores associados com cada fator
podem assumir 0, 3 ou 5 e devem ser definidos com a seguinte orientação:
• Para os quatro primeiros fatores, 0 significa nenhuma experiência no assunto, 3
significa experiência média ou normal e 5 significa alta experiência (especialista).
• Para o quinto fator, 0 significa nenhuma motivação para o projeto, 3 significa
motivação média ou normal e 5 significa alta motivação.
• Para o sexto fator, 0 significa que os requisitos estão mudando constantemente no
prijeto, 3 significa mudança nos requisitos é média ou normal e 5 significa que os
requisitos praticamente não mudam durante o projeto.
• Para o sétimo fator, 0 significa que não haverá pessoal técnico trabalhando em tempo
parcial, 3 significa que poucos estarão trabalhando em tempo parcial (na média) e 5
significa que todo pessoal técnico estará trabalhando em tempo parcial.
• Para o oitavo fator, 0 significa que a linguagem de programação adotada é fácil de
usar, 3 significa que a complexidade da linguagem é média e 5 significa que a
linguagem de programação é muito difícil de usar.
A seguinte fórmula é então aplicada (16):
EF= 1.4+(-0.03*EFactor) (16)
O total ajustado de pontos de casos de uso (UCP) é calculado com a seguinte fórmula (17):
UCP = UUCP*TCP*EF (17)
Com o número ajustado de pontos de caso de uso pode-se calcular o esforço necessário para o
projeto de software.
59
3.3.3 CÁLCULO DE ESFORÇO
Karner (1993) propôs um fator de esforço de 20 pessoas/horas de equipe por ponto de caso de
uso para estimar um projeto. Porém se o número de fatores ambientais entre F1 e F6 (tabela
31) for entre 3 e 4 o esforço é de 28 pessoas/horas e se passar de 4 o esforço é de 36
pessoas/horas (RIBU, 2001, p.114).
É recomendado que na primeira estimativa utilize-se 36 pessoas/horas por UCP. A razão para
esta abordagem é que os fatores ambientais medem o nível de experiência da equipe e a
estabilidade do projeto. Números negativos significam um esforço extra gasto em treinamento
ou problemas com instabilidade. Entretanto, utilizando este método de cálculo significa que
mesmo pequenos ajustes em um fator ambiental, por um exemplo, em meio ponto, pode
causar uma grande diferença na estimativa.
3.4 EXEMPLO DE APLICAÇÃO DE UCP
Será utilizado o mesmo exemplo de cadastro de funcionário descrito na seção 3.1.1 (exemplo
de APF). Neste sentido o caso de uso abaixo no quadro 1, descreve o cadastro de funcionário.
O primeiro passo é definir o tipo de ator do sistema, neste caso o ator é um usuário humano,
ou seja, o ator é do tipo complexo. Fator ponderado para o ator é 3.
O segundo passo é preciso classificar o caso de uso. Neste caso, o caso de uso é considerado
de complexidade média, pois contém 6 transações diferentes descritas nos passos 2, 5, 8, 9, 10
e 11 do fluxo base. Os fluxos alternativos não foram contados pois podem ser representados
como apenas uma transação parecida com a descrita no passo 10, podendo então ser
reutilizada nos demais passos. Então temos que o fator ponderado do caso de uso é igual a 10.
Tabela 32 Definição da complexidade técnica Fator Peso Grau de influência Total por fator T1 2 0 0 T2 2 3 6 T3 1 3 3 T4 1 0 0 T5 1 0 0 T6 0.5 0 0 T7 0.5 3 1,5 T8 2 0 0 T9 1 0 0 T10 1 0 0 T11 1 3 3
60
Quadro 1 Caso de uso do cadastro de funcionário.
Nome: Cadastro de funcionário. Ator ativo : Usuário. Pré-Condições: Sistema deve estar inicializado. Pós-Condições: O cadastro de um funcionário efetuado no sistema. FLUXO BASE
1. O usuário seleciona a opção de cadastro de funcionário. 2. O sistema exibe a tela de cadastro de funcionário. 3. O usuário preenche os dados do funcionário.. 4. O usuário seleciona um setor. 5. O sistema exibe a lista de ramais relacionada ao setor selecionado. 6. O usuário seleciona um ramal. 7. O usuário opta por cadastrar o funcionário. 8. O sistema gera o número para o funcionário. 9. O sistema grava os dados do novo funcionário. 10. O sistema exibe uma mensagem de confirmação juntamente com o número e nome do funcionário recem
cadastrado. 11. O usuário confirma e saiu do cadastro. 12. O sistema exibe a tela padrão do sistema.
FLUXO ALTERNATIVO: Cancelar cadastro Condição: Nos passos 1 ao 7 do fluxo base.
1. O usuário pode optar por cancelar a operação. 2. O sistema exibe a tela padrão do sistema.
FLUXO ALTERNATIVO: Funcionário já existente. Condição: No passo 9 do fluxo base, se o usuário tentar cadastrar um funcionário já existente, ou seja, nomes iguais.
1. O sistema exibe uma mensagem de alerta. 2. O usuário confirma a leitura da mensagem. 3. O sistema retorna para o passo 2 do fluxo base. .
FLUXO DE EXCEÇÃO: Não tem setor cadastrado. Condição: No passo 4 do fluxo base, não exite setor para selecionar.
1. O sistema exibe uma mensagem: Não existe setor cadastrado. 2. O usuário confirma. 3. Retorna ao passo 1 do fluxo base.
FLUXO DE EXCEÇÃO: Não tem ramal cadastrado. Condição: No passo 5 do fluxo base, não exite ramal cadastrado para o setor.
1. O sistema exibe uma mensagem: Não existe ramal cadastrado. 2. O usuário confirma. 3. Passa para o passo 7 do fluxo base.
FLUXO DE EXCEÇÃO: Dados em branco ou caracteres invalidos Condição: No passo 7do fluxo base, O usuário não preenche os dados do cadastro.
1. O sistema exibe uma mensagem para avisar que faltam dados ou os dados estão preenchidos errados. 2. O usuário confirma. 3. Valta para o passo 2.
O terceiro passo é calcular o número não ajustado de pontos de casos de uso. Para isso usa-se
a fórmula 14, que é a soma do fator ponderado para o ator com o fator ponderado do caso de
uso, cujo resultado neste exemplo é 13 (3+10) o número não ajustado de pontos de casos de
uso.
O quarto passo é calcular o fator de complexidade técnica (TCF). Sendo assim é preciso
definir o grau de influência (ver tabela 29) para os 11 (onze) fatores de complexidade técnica
para que seja multiplicado pelos seus respectivos pesos conforme a tabela 32.
Tabela 33 Cálculo do TFactor Cálculo TFactor
0 + 6 + 3 + 0 + 0 + 0 + 1.5 + 0 + 0 + 0 + 3 13,5
61
Tabela 34 Cálculo do TFactor Cálculo TCF
0,6 + (0,01 * 13,5) 0,73
O TFactor é calculado por meio da soma dos 11 fatores de complexidade técnica como
mostrado na tabela 33. Calculado o TFactor usa-se a fórmula 15 para calcular o TCF. Neste
exemplo o TCF é igual a 0,73 como demonstrado na tabela 34.
O quinto passo é calcular o fator de ambiente (EF). Sendo assim é preciso definir o grau de
influência (ver tabela 28) para os 8 (oito) fatores de complexidade de ambiente para que seja
multiplicado pelos seus respectivos pesos conforme a tabela 35.
Tabela 35 Fatores de ambiente e seus respectivos pesos Fator Peso Grau de influência Total por fator F1 1.5 3 4,5 F2 0.5 5 2,5 F3 1 5 5 F4 0.5 5 2,5 F5 1 3 3 F6 2 5 10 F7 -1 0 0 F8 2 3 6
Tabela 36 Cálculo do EFactor Cálculo EFactor
4,5 + 2,5 + 5 + 2,5 + 3 + 10 + 0 + 6 33,5
Tabela 37 Cálculo do TFactor Cálculo EF
1,4 + (-0,03 * 33,5) 0,39
O EFactor é calculado por meio da soma dos 8 fatores de complexidade técnica como
mostrado na tabela 36. Calculado o EFactor usa-se a fórmula 16 para calcular o EF. Neste
exemplo o EF é igual a 0,39 como demonstrado na tabela 37.
Tabela 38 Cálculo do número ajustado de pontos de casos Cálculo UCP
13* 0,73 * 0,39 3,70
Por fim utiliza-se a fórmula 17 para calcular o número ajustado de pontos de caso de uso
como demonstrado na tabela 38. Neste exemplo o número de pontos de caso de uso é igual a
3,70.
62
Considerando que o esforço seja 20 pessoas/hora por pontos de casos de uso, o esforço deste
exemplo é 20 pessoas/hora multiplicado por 3,70 pontos de caso de uso, que é igual a 74
pessoas/horas. Considerando o mesmo custo de R$ 5 (cinco reais) descrito no exemplo da
seção 3.1, o custo desta implementação é de R$ 370,00 (trezentos e setenta reais). Vale
ressaltar que a estimativa de custo descrita acima foi baseado no salário de um programador,
não levando em conta os diferentes salários que podem vir a ter numa empresa e outros papeís
como o de gerente.
3.5 CONCLUSÃO
Modelos de custo como o COCOMO e métodos baseados no tamanho como análise por
pontos de função (APF) são bem conhecidos e têm seu uso difundido na engenharia de
software como pode ser observado nos livros de engenharia de software do Sommerville
(1996, p.599), Mayhauser (1990, p.707). Entretanto, estas abordagens têm algumas limitações
relevantes. Pontos de função foi desenvolvida para projetos de software que utilizem
programação estruturada. O modelo COCOMO utiliza linhas de código como entrada
(MAYHAUSER, 1990, p.707), as quais formam uma medida ambígua, uma vez que o
número de linhas de código não necessariamente corresponde ao esforço aplicado para
escrevê-las por que um algoritmo recursivo exige um maior esforço em menos linhas de
código do que um algoritmo que não use recursividade. “Nenhuma destas abordagens é bem
adaptada para definir o tamanho de projetos de software orientados a objetos” (RIBU, 2001,
p.2).
No método UCP, há muitas variações de estilos de especificação de casos de uso e formatos.
Isto faz com que haja dificuldades em desenvolver uma ferramenta de software para utilizar
os casos de uso para estimar o tamanho do software (DAMODARAN, 2003, p.2). Um caso de
uso descreve comportamento a partir da visão do ator, o que pode esconder a complexidade
inerente do desenvolvimento do sistema.
Porém, “o método de pontos de caso de uso de estimação de tamanho é muito valioso se
adicionado com ferramentas utilizadas pelo gerente de projeto” (DAMODARAN, 2003, p.2).
Mesmo assim, é importante lembrar que todos os métodos de estimativa são suscetíveis a
erro, mesmo por que, as estimativas tratam o que é previsto pelo avaliador. O que é
esquecido, ou seja, que não é previsto antecipadamente como riscos, pode aumentar o
tamanho necessário para o projeto (DAMODARAN, 2003, p.2).
63
“Poucas pesquisas tem testado o método de pontos de caso de uso e analisado suas
descobertas. Os resultados ainda que não conclusivos, indica que o método pontos de caso de
uso tem potencial para ser uma fonte segura de estimação” (DAMODARAN, 2003, p.2).
Neste sentido, este trabalho pretende contribuir com uma ferramenta de estimativa de
tamanho, a qual utiliza como base o método por pontos de casos de uso. A qual poderá ser
utilizada para pesquisas posteriores, agilizando tempo necessário para se estimar um projeto
de software. Vale ressaltar ainda que este trabalho é integrado a uma ferramenta já existente
para a construção de modelo de caso de uso e gerência de projetos.
64
4 FERRAMENTA DE ESTIMATIVA DE SOFTWARE
PLACES é uma plataforma colaborativa desenvolvida para apoiar a gerência de projetos de
software, flexibilizando a construção de ferramentas que venham oferecer suportar diferentes
processos da Engenharia de Software Moretto (2005). Esta plataforma é uma evolução da
ferramenta colaborativa ARCase, desenvolvida inicialmente para suportar apenas a fase de
concepção de software (KONOWALOW, 2003; DOMINGOS, 2004). A proposta é
desenvolver um ambiente comum para a construção incremental de diferentes ferramentas
onde os recursos colaborativos já estão disponíveis para esta plataforma. Desta forma, a
construção das ferramentas é facilitada e focada nas boas práticas associadas com os
processos que elas pretendem trabalhar. No trabalho de Moretto (2005), foi desenvolvido uma
ferramenta para gerência de projetos, incluindo as áreas de planejamento e monitoração de
projetos. Entretanto, foi desenvolvida toda uma infra-estrutura de segurança e de colaboração
(ferramentas para reuniões virtuais, fóruns de discussão e outros recursos). A figura 4
apresenta uma tela da plataforma PLACES, onde é possível selecionar um dos projetos em
andamento.
Neste sentido, o ambiente ARCase passou a ser uma das ferramentas da plataforma PLACES,
dando ênfase à área de desenvolvimento de requisitos. Um dos objetivos deste trabalho é a
migração de parte (aquela associada ao desenvolvimento de requisitos) da ferramenta ARCase
para a plataforma PLACES. A filosofia inicial do ambiente ARCase foi preservada nesta nova
versão, onde a ênfase não está no desenvolvimento de diagramas, uma vez que ela não possui
recursos para a construção de diagramas. O foco continua sendo a manipulação eficiente de
documentos, usualmente deixada em segundo plano por ferramentas gráficas. Utilizando os
recursos disponibilizados pela plataforma PLACES, a ferramenta atua como um banco de
informações compartilhadas entre os participantes do projeto, por meio de um ambiente
colaborativo. Através desta colaboração, são gerados diversos tipos de artefatos como regras
de negócio, requisitos funcionais, requisitos não funcionais, telas do sistema e outros ainda
65
customizáveis. O caso de uso é o artefato central da ferramenta que permite a integração da
concepção. É possível associar quaisquer artefato construído entre si e com os casos de uso,
oferecendo rastreabilidade.
Figura 4 Tela de projetos do PLACES.
Entretanto, a versão anterior da ferramenta não possuía nenhum recurso para auxiliar os
gerentes na estimativa de tamanho. Sendo assim, este trabalho buscou um segundo objetivo
(motivação principal para este TCC) que foi o desenvolvimento de um módulo de estimativa
de software com base nos artefatos disponibilizados pela ferramenta de desenvolvimento de
requisitos da plataforma PLACES. A partir deste módulo, é possível estimar o tamanho.
4.1 TECNOLOGIA UTILIZADA
Para o desenvolvimento da ferramenta web é utilizada a linguagem de programação JAVA,
sendo que as páginas web foram escritas em JSP (Java Server Pages)18. O desenvolvimento
seguiu o padrão MVC (Model-View-Controller) (SUN, 2005). Este padrão separa o código
em apresentação, controle e modelo de dados (ALUR, 2002, p.7). No PLACES esta divisão
foi feita principalmente em três pacotes, Web Pages (view), com.business.delegate
(controller), com.transfer.object (model) (ver figura 5).
Foram utilizados os frameworks ( “framework é uma estrutura de suporte definida em que um
outro projeto do software pode ser organizado e desenvolvido. Pode incluir programas de
18 IDE utilzada é o netbeans 4.1. O banco de dados utilizado é o MySQL 4.1. O servidor web utilizado é o Tomcat 5.5.
66
VIEW
CONTROLLER
MODEL
apoio, bibliotecas de código, scripts e outros softwares” (WIKIPEDIA, 2005)) Spring
(RAIBLE, 2005) e o Hibernate (BAUER; KING, 2005). O Spring é utilizado para controlar a
comunicação entre a camada de apresentação (view) e a camada de controle (controller),
permitindo a passagem de objetos (instâncias de classes) de uma pagina para outra. O
Hibernate é um framework para a camada de persistência, de acesso ao banco de dados,
fazendo o mapeamento objeto-relacional. Nas próximas seções serão explicados o
funcionamentos desses frameworks.
Figura 5 Divisão MVC no PLACES.
4.1.1 O FRAMEWORK SPRING
O Spring é um framework de código aberto (WALLS; BREIDENBACH, 2005) que
possibilita o uso de JavaBeans para executar objetos parecido com a tecnologia EJB
(Enterprise JavaBeans)(SUN, 2005). O Spring permite a simplicidade, testabilidade e baixo
acoplamento do código (WALLS; BREIDENBACH, 2005, p.7). O Spring fica localizado na
camada de negócios no modelo MVC, gerenciando os objetos de negócio, transações, sessões
do Hibernate entre outras funções.
Este framework reduz o acoplamento, porque o Spring utiliza um arquivo de configuração
para mapear as dependências entre os objetos. Desse modo, cada objeto pode ser escrito
independente de outro, utilizando uma técnica conhecida como inversion of control (IoC)
(WALLS; BREIDENBACH, 2005, p.8). Este arquivo de configuração é o placesapp-
servlet.xml (ver quadro 2).
O arquivo de configuração do Spring é divido em duas partes (quadro 2), a primeria parte do
arquivo é composto dos mapeamentos da localização das classes controladoras (controller) do
PLACES para um identificador, a segunda parte relaciona esse identificador com uma chave
(key). Essa chave é usado pelo PLACES como uma chave de localização dos controladores.
67
Testabilidade é uma vantagem na utilização do Spring, isso ocorre pois o Spring reduz o
acoplamento do código. Sendo assim não é preciso ter o programa todo pronto para testar uma
classe, as classes podem ser testadas conforme são desenvolvidas.
Quadro 2 Arquivo de configuração placesapp-servlet.xml
Este framework permite o desenvolvimento de aplicações complexas a partir de componentes
simples. No Spring, as classes utilizadas na aplicação são declaradas em um arquivo XML
(placesapp-servlet.xml, ver quadro 2). O Spring também contém uma infraestrutura de
<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE beans PUBLIC "-//SPRING//DTD BEAN//EN""http://www.springframework.org/dtd/spring-beans.dtd"> <!-- Mapeamentos do Framework SPRING -->
<beans> <!-- Beans Controladores do PLACES--> <bean id="controladorDecasodeuso" class="com.business.delegate.ControladorCasoDeUso"/> <bean id="controladoraddDecasodeuso" class="com.business.delegate.ControladorAddArtefato"/> <bean id="controladorlistaartefato" class="com.business.delegate.ControladorListaArtefatos"/> <bean id="controladorsalvaedicaoartefato" <bean id="controladorconfigurarfatorajuste" class="com.business.delegate.pcu.ControladorConfigurarFatorAjuste"/> <bean id="controladorsalvaedicaofatorajuste" class="com.business.delegate.pcu.ControladorSalvaEdicaoFatorAjuste"/> <bean id="controladoraddfatorajuste" class="com.business.delegate.pcu.ControladorAddFatorAjuste"/> <bean id="controladorsalvafatorajuste" class="com.business.delegate.pcu.ControladorSalvaFatorAjuste"/> <bean id="controladordeletefatorajuste" class="com.business.delegate.pcu.ControladorDeleteFatorAjuste"/> <bean id="controladorEditProjeto" class="com.business.delegate.ControladorEditProjeto"/> <bean id="controladorvisualizapontoscasodeuso" class="com.business.delegate.pcu.ControladorVisualizaPontosCasoDeUso"/> <bean id="controladorsalvaedicaopontoscasodeuso" class="com.business.delegate.pcu.ControladorSalvaEdicaoPontosCasoDeUso"/> <bean id="controladorcalculapontoscasodeuso" class="com.business.delegate.pcu.ControladorCalcularPontosCasoDeUso"/> <bean id="controladorlistaatores" class="com.business.delegate.ator.ControladorListaAtores"/> <bean id="controladorviewator" class="com.business.delegate.ator.ControladorViewAtor"/> <bean id="controladorsalvaedicaoator" class="com.business.delegate.ator.ControladorSalvaEdicaoAtor"/> <bean id="controladorcadastraator" class="com.business.delegate.ator.ControladorCadastraAtor"/> <bean id="controladorsalvaator" class="com.business.delegate.ator.ControladorSalvaAtor"/> <bean id="controladorapagaator" class="com.business.delegate.ator.ControladorApagaAtor"/> <!-- Mapeamento dos controladores --> <bean id="urlMapping" class="org.springframework.web.servlet.handler.SimpleUrlHandlerMapping"> <property name="mappings"> <props> <!-- Controlador de Casos de Uso --> <prop key="/addArtefato.exec">controladorDecasodeuso</prop> <prop key="/salvaartefato.exec">controladoraddDecasodeuso</prop> <prop key="/editaartefato.exec">controladoreditaartefatp</prop> <prop key="/salvaedicao.exec">controladorsalvaedicaoartefato</prop> <!-- Controlador de Pontos de Casos de Uso --> <prop key="/configurarfatordeajuste.exec">controladorconfigurarfatorajuste</prop> <prop key="/editaFA.exec">controladorsalvaedicaofatorajuste</prop> <prop key="/addFA.exec">controladoraddfatorajuste </prop> <prop key="/salvaFA.exec">controladorsalvafatorajuste </prop> <prop key="/removeFA.exec">controladordeletefatorajuste </prop> <prop key="/visualizaPCU.exec">controladorvisualizapontoscasodeuso </prop> <prop key="/salvaedicaoPCU.exec">controladorsalvaedicaopontoscasodeuso</prop> <prop key="/calculaPCU.exec">controladorcalculapontoscasodeuso</prop> <!-- Cadastro Atores do Sistema --> <prop key="/listaAtores.exec">controladorlistaatores</prop> <prop key="/editaator.exec">controladorviewator</prop> <prop key="/salvaedicaoator.exec">controladorsalvaedicaoator</prop> <prop key="/addAtor.exec">controladorcadastraator</prop> <prop key="/salvaator.exec">controladorsalvaator</prop> <prop key="/removeAtor.exec">controladorapagaator</prop> </props> </property> </bean> <bean id="messageSource" class="org.springframework.context.support.ResourceBundleMessageSource"> <property name="basename"><value>messages</value></property></bean>
68
funcionalidades (gerenciamento de transação, persistência por meio de framework integração,
entre outros) deixando a lógica do aplicativo para o desenvolvedor (WALLS;
BREIDENBACH, 2005, p.7). Assim resta ao desenvolvedor escrever o código especifico para
cada classe. Além do Spring controlar as transações e interligação entre as camadas do
modelo MVC. Para isso o Spring utiliza os pacotes Controller e ModelAndView (ver quadro
3). Neste trabalho esses pacotes são importados pela classe ControladorAction.
Quadro 3 Classe ControladorAction
4.1.2 O FRAMEWORK HIBERNATE
O Hibernate (BAUER; KING, 2005) possibilita o desacoplamento entre a camada de negócio
e a camada de persistência ao mesmo tempo em que faz o mapeamento objeto-relacional. Ele
permite que os dados persistidos passem para a camada de negócio como objetos, seguindo a
estilo de programação orientado a objetos (BAUER; KING, 2005, p.2).
O Hibernate possibilita que o DBA (administrador de banco de dados) e programador possam
trabalhar de forma independente. O programador não precisa saber exatamente a estrutura das
tabelas no banco de dados, mas apenas saber qual objeto representa os dados de que ele
precisa. O programador também não precisa conhecer a linguagem SQL (Structured Query
Language) e suas variações de acordo com o banco de dados. O DBA, por outro lado, é quem
vai escrever o código das consultas, inserções, alterações e de exclusões no banco de dados de
acordo com a linguagem HQL (Hibernate Query Language) (BAUER; KING, 2005, p.23).
No arquivo Hibernate.properties é o arquivo de configuração que será utilizado pelo
Hibernate para poder acessar o banco de dados. Neste arquivo está contido caminho do driver
(conjunto de arquivos necessários para se conectar com o banco de dados) de conexão com o
banco de dados, o local onde se encontra instalado o banco de dados (se o servidor da
aplicação e o servidor de banco de dados forem o mesmo ponto na rede, o local pode ser
package com.business.delegate; import javax.servlet.*; import javax.servlet.http.*; … import org.springframework.web.servlet.mvc.Controller; import org.springframework.web.servlet.ModelAndView; public class ControladorAction implements Controller{ … }
69
descrito mo localhost ), o nome do banco de dados o qual se quer conectar, o username e a
senha (ver quadro 4). No caso do PLACES o banco de dados utilizados é o MySQL, o nome
do banco é places, conforme pode ser observado no quadro 4.
Quadro 4 Hibernate.properties
O HQL é uma linguagem similar ao SQL, porém muito mais simples. Ou seja, quem conhece
a linguagem SQL não terá problemas com a HQL, pois ela é uma linguagem SQL voltada
para a orientação objeto (BAUER; KING, 2005, p.33). No quadro 5 há um exemplo da
linguagem HQL, note que na lingugem SQL seria necessário o comando select para fazer uma
consulta no banco, na HQL, este comando é omitido, além disso ao invés de colocar o nome
da tabela a qual se deseja fazer a consulta, é colocado o nome da classe que representa um
objeto (o qual pode representar uma ou mais tabelas no banco de dados). O Hibernate já
monta o objeto na consulta, não sendo necessário montá-lo.
Assim como o comando select, os comandos insert, update e delete do SQL são omitidos pelo
Hibernate. Note que com isso o programador não precisa saber dos relacionamentos das
tabelas do banco de dados, apenas saber quais objetos ele precisa para desenvolver o
programa.
Quadro 5 Exemplo de HQL
Neste trabalho, a maior dificuldade com o Hibernate foi sua configuração inicial, pois ela
exige o conhecimento das tags XML (extensible markup language) específicas ao Hibernate.
hibernate.query.imports net.sf.hibernate.test, net.sf.hibernate.eg
#################
### Platforms ###
#################
## MySQL hibernate.dialect net.sf.hibernate.dialect.MySQLDialect
hibernate.connection.driver_class com.mysql.jdbc.Driver
hibernate.connection.driver_class org.gjt.mm.mysql.Driver
hibernate.connection.url jdbc:mysql://127.0.0.1:3306/places?autoReconnect=true
hibernate.connection.username root
hibernate.connection.password *****
public FatorAjusteTO findByKey(int key) throws Exception { Session session = HibernateUtil.currentSession(); List fatores = session.find("from FatorAjusteTO as f where f.idFatorAjuste= "+key); FatorAjusteTO fto = (FatorAjusteTO)fatores.get(0); return fto; }
70
Além de aprender a utilizar e configurar o Hibernate, foi também necessário conhecer a
linguagem XML (BAUER; KING, 2005, p.34).
O mapeamento objeto-relacional é feito por meio do arquivo XML. O arquivo
hibernate.cfg.xml é o arquivo de configuração do Hibernate, por meio desse arquivo o
Hibernate mapea quais arquivos representam os mapeamentos objeto-relacional (ver quadro
6).
Quadro 6 Arquivo hibernate.cfg.xml.
Os arquivos mapeados no arquivo hibernate.cfg.xml são os arquivos que representam a
relação entre uma tabela e um objeto, os campos das tabelas são mapeados para os atributos
do objeto conforme quadro 7. Neste caso o objeto ArtefatoTO esta relacionado com a tabela
Artefato (esta tabela pode representar um arquivo tipo documento do projeto, um caso de uso,
um requisto funcional, uma regra de negócio entre outros) no banco de dados.
Note que nesse arquivo é colocado qual a tabela do banco de dados será mapeada, no caso a
tabela Artefato, e o objeto o qual representará essa tabela, neste caso ArtefatoTO que está
localizado no pacote com.transfer.object.
Há um campo identificador na tabela Artefato, neste caso ID_ARTEFATO, o qual é do tipo
auto_increment, ou seja, a cada nova inserção no banco o valor dessa coluna é incrementado.
Isso é necessário para que o Hibernate possa inserir novos dados na tabela do banco de dados.
Para mapear um atributo com a coluna da tabela utiliza-se a tag property. Nesta tag o campo
name representa o atributo da classe, o campo type representa o tipo do atributo da classe, o
campo column representa o nome da coluna da tabela do banco de dados, e por fim o campo
length representa o tamanho de cada dado da coluna da tabela.
<?xml version='1.0' encoding='utf-8'?> <!DOCTYPE hibernate-configuration PUBLIC "-//Hibernate/Hibernate Configuration DTD//EN" "http://hibernate.sourceforge.net/hibernate-configuration-2.0.dtd"> <hibernate-configuration> <session-factory> <!-- Arquivos de mapeamento --> <mapping resource="ArtefatoGrupoTO.hbm.xml"/> <mapping resource="ArtefatoTO.hbm.xml"/> <mapping resource="ParticipanteTO.hbm.xml"/> <mapping resource="TipoArtefatoTO.hbm.xml"/> <mapping resource="FatorDeAjusteTO.hbm.xml"/> <mapping resource="AtorTO.hbm.xml"/> <mapping resource="PCUTO.hbm.xml"/> </session-factory> </hibernate-configuration>
71
Quadro 7 Arquivo ArtefatoTO.hbm.xml de mapeamento objeto-relacional.
Para configurar os mapeamentos do Hibernate com as tabelas do banco de dados foi utilizado
o plugin do eclipse chamado Medlegim (ver anexo 1).
<<?xml version="1.0"?> <!DOCTYPE hibernate-mapping PUBLIC "-//Hibernate/Hibernate Mapping DTD 3.0//EN" "http://hibernate.sourceforge.net/hibernate-mapping-3.0.dtd" > <hibernate-mapping> <!-- Created by the Middlegen Hibernate plugin 2.2 http://boss.bekk.no/boss/middlegen/ http://www.hibernate.org/ --> <class name="com.transfer.object.ArtefatoTO"
table="ARTEFATO" > <id name="idArtefato" type="java.lang.Integer"
column="ID_ARTEFATO" > <meta attribute="field-description" inherit="false"> auto_increment </meta> <generator class="native" /> </id> <property name="idParticipanteCriou" type="int" column="ID_PARTICIPANTE_CRIOU" length="11" /> <property name="idTipoArtefato" type="int" column="ID_TIPO_ARTEFATO" length="11" /> <property name="versao" type="java.lang.String" column="VERSAO" length="15" /> <property name="palavraChave" type="java.lang.String" column="PALAVRA_CHAVE" length="255" /> <property name="codigoArtefato" type="java.lang.String" column="CODIGO_ARTEFATO" length="20" /> <property name="nomeArtefato" type="java.lang.String" column="NOME_ARTEFATO" length="255" /> <property name="descricaoArtefato" type="java.lang.String" column="DESCRICAO_ARTEFATO" length="65535" /> <property name="grauComplexidade" type="java.lang.String" column="GRAU_COMPLEXIDADE" length="65535" /></class> </hibernate-mapping>
72
4.2 PADRÕES DE PROJETO
O desenvolvimento do módulo de estimativa de software seguiu a arquitetura MVC (Model-
view-Controller) (SUN, 2005), onde o código é divido em três camadas. A camada model que
representa o modelo dos dados na aplicação. A camada view que representa a parte da
interação do sistema com o usuário e a camada controller que representa a parte da lógica da
aplicação, fornecendo serviços comuns como autorização e gerenciamento de erros (HUSTED
at al, 2004, p.580). Neste trabalho, a parte view é parte do pacote web pages, a parte model é
implementada no pacote transfer.object e a parte do controller é implementada no pacote
business.object (ver figura 5).
Para implementar o módulo de estimativa com base na arquitetura MVC, foram utilizados
alguns padrões de projeto conhecidos, tais como Front Controller, View Helper, Composite
View, Data Access Model, Business Delegate, Business Object e Transfer Object (ou Value
Object). Nas próximas seções, estes padrões são brevemente apresentados e seu uso no
desenvolvimento é comentado.
4.2.1 FRONT CONTROLLER
O Front Controller “fornece um controlador centralizado para gerenciar o tratamento de uma
solicitação” (ALUR, Deepak et al, 2002, p.116). É um container para manter a lógica de
processamento comum que ocorre na camada de apresentação e que, por outro lado, é
colocado de forma errônea em uma visualização. Um controlador trata as solicitações e
gerencia a recuperação de conteúdo, segurança, gerenciamento e navegação da visualização,
delegando ao componente Dispatcher (ver seção 4.2.8) a função de distribuir para uma
visualização (ALUR et al, 2002, p.125). Esse padrão permite a centralização do código
relacionado com os serviços do sistema, serviços de segurança, recuperação do conteúdo,
gerenciamento da exibição e navegação, portanto esse código da aplicação não é duplicado
infinitamente ou misturado com o conteúdo da exibição (HUSTED at al, 2004, p.553).
No PLACES o Front Controller é implementado na classe “ControladorAction” (ver quadro
3). O Dispatcher (ver seção 4.2.8) é configurado no arquivo placesapp-servlet.xml,( ver
quadro 2) o qual é utilizado pelo framework Spring.
73
4.2.2 VIEW HELPER
O View Helper encapsula a lógica que não esteja relacionada à formatação da apresentação
em componentes auxiliares (Helper) (ALUR et al, 2002, p.116). O View Helper encoraja a
separação do código relacionado à formatação de outra lógica de negócios. Sugere utilizar os
componentes helper para encapsular a lógica relacionada ao início da recuperação do
conteúdo, validação e adaptação e formatação do modelo. O componente view é, depois,
deixado para encapsular a formatação da apresentação. Os componentes helper normalmente
delegam funções ao Busisness Services através de um Business Delegate, embora uma
visualização possa ser composta de diversos componentes secundários para criar template
(ALUR et al, 2002, p.125).
Quadro 8 Classe View Helper.
/* getXMLValue.java * Created on 25 de Abril de 2005, 18:48 */ package com.business.helper; import javax.naming.*; public class GetXMLValueUtil { private Context env; private String XMLValue; /** Creates a new instance of getXMLValue */ public GetXMLValueUtil() { try{ env = (Context) new InitialContext().lookup("java:comp/env"); } catch(javax.naming.NamingException e){ System.out.println("Erro ao ler do arquivo web.xml..."); } } /** Retorna o valor da tag xml com nome appName * @return */ public String getXMLErroLogin(){ try{ //Pega o conte�do de uma tag XML para a mem�ria prim�ria. XMLValue = (String) env.lookup("erroLogin"); } catch(javax.naming.NamingException erro){ System.out.println("Erro ao ler o web.xml...\n:<br>"+erro); XMLValue = ""; } return XMLValue; } /** * Retorna o valor da tag xml com nome appName * @return */ public String getXMLAppName(){ try{ //Pega o conte�do de uma tag XML para a mem�ria prim�ria. XMLValue = (String) env.lookup("appName"); } catch(javax.naming.NamingException erro){ System.out.println("Erro ao ler o web.xml...\n:<br>"+erro); XMLValue = ""; } return XMLValue; } /** * * @return */ public String getXMLAppPath(){ try{ //Pega o conte�do de uma tag XML para a mem�ria prim�ria. XMLValue = (String) env.lookup("path"); } catch(javax.naming.NamingException erro){ System.out.println("Erro ao ler o web.xml...\n:<br>"+erro); XMLValue = ""; } return XMLValue; } }
74
O View Helper é implementado no pacote “com.business.helper” no PLACES (ver quadro 8).
No quadro 8 mostra a classe “GetXMLValueUtil.java” que é utilizado entre outras funções
para retornar uma mensagem de erro no caso de uma tentativa de autenticação com o login do
usuário ou a senha esteja errados.
4.2.3 COMPOSITE VIEW
O Composite View cria uma visualização (view) agregada a partir de subcomponentes muitos
pequenos (ALUR, Deepak et al, 2002, p.116). O Composite View sugere compor uma
visualização de inúmeras parcelas pequenas. Diversas visualizações menores, tantos estáticas
quanto dinâmicas, são reunidas para criar um único template (ALUR et al, 2002, p.125). Este
padrão é implementando por meio das taglibs (quadro 9) que compõe a tela principal. No
PLACES para compor a visualização da página web addCasoDeUso.jsp (quadro 10), foi
utilizado a tag exibeComplexidadeArtefato.tag (quadro 9).
Quadro 9 Arquivo exibeComplexidadeArtefato.tag
Quadro 10 Página addCasoDeUso.jsp
Neste caso foram omitidos 5 linhas de código html na página addCasoDeUso.jsp por meio da
tag exibeComplexidadeArtefato.tag possibiliatando um cógido html limpo em outras páginas
<%@tag description="Exibe a complexidade do projeto" pageEncoding="UTF-8"%> <select name="complexidade"> <option value="1" selected>baixa</option> <option value="2">média</option> <option value="3">alta</option> </select>
<%@page pageEncoding="UTF-8"%> <%@taglib prefix="tag" tagdir="/WEB-INF/tags"%> <%-- The taglib directive below imports the JSTL library. If you uncomment it, you must also add the JSTL library to the project. The Add Library... action on Libraries node in Projects view can be used to add the JSTL 1.1 library. --%> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <form name="form1" method="post" action="ControladorCasoDeUso.action"> <table border="0" cellpadding="4" cellspacing="4" width="100%"> <tbody> <tr> <td colspan="6"> <table border="0" cellpadding="2" cellspacing="2" width="100%"> <tbody> <tr> <td class="titulo1" width="99%">Cadastro de Caso de Uso</td> </tr> </tbody> </table> </td> </tr> <tr> <td width="21%" align="right" bgcolor='#eeeefc'> <b>Caso de Uso <b> <input name="nome" id="nome" type="text" width="79%" bgcolor='#eeeefc'> </td> <td width="21%" align="right" bgcolor='#eeeefc'> <b>Complexidade:<b> <tag:exibeComplexidadeArtefato/> </td> <td></td> </tr> </table>
75
web foi retirado os códigos java das paginas JSP, separando o código dinâmico do estático.
Esta técnica foi utilizada em todo código em especial nas telas ListaAtores.jsp (figura 6),
ListaFatoresDeAjuste.jsp (figura 9) entre outras.
4.2.4 BUSINESS DELEGATE
O Business Delegate decompõe as camadas de apresentação e serviço e fornece uma interface
de facade (fachada de acesso) e de proxy aos serviços (ALUR et al, 2002, p.116). O Business
Delegate reduz o acoplamento entre as camadas e fornece um ponto de entrada para acessar
os serviços que são fornecidos por outra camada. O delegate pode também fornece
armazenamento em cache de resultados para as solicitações comuns para melhorar o
desempenho. Um Business Delegate normalmente utiliza um service locator para localizar
objetos de serviço, como um objeto EJB Home e uma Factory JMS Connection. (ALUR et al,
2002, p.125). O padrão Business Delegate é implementado no pacote “com.business.delegate”
e seus subpacotes (ver quadro 11).
No quadro 11, um exemplo de classe utilizando o padrão Business Delegate, a qual recebe
uma requisição e redireciona para a página correspondente no caso a página
addCadoDeUso.jsp (quadro 10).
Quadro 11 Arquivo ControladorMontaCasoDeUso.java
<%@page pageEncoding="UTF-8"%> * * ControladorMontaCasoDeUso.java * * Created on 30 de Agosto de 2005, 09:33 */ package com.business.delegate; import java.io.*; import java.net.*; import javax.servlet.*; import javax.servlet.http.*; import com.transfer.object.*; import com.business.object.*; import java.util.ArrayList; import org.springframework.web.servlet.ModelAndView; /** * @author Richard Henrique de Souza * @version */ public class ControladorMontaCasoDeUso extends ControladorAction { public ModelAndView handleRequest(HttpServletRequest request, HttpServletResponse response) throws Exception { super.processRequest(request, response); super.setView("main.jsp?link=casodeuso/addCasoDeUso&autor="+super.pto.getNome()); try{ return super.handleRequest(request, response); } catch (java.lang.Exception e){ super.logger.error(e); return new ModelAndView(super.getView()); } } }
76
4.2.5 DATA ACCESS OBJECT
O Data Access Object (DAO) é padrão utilizado para a persistência dos dados. Fornece acesso
transparente aos dados (ALUR et al, 2002, p.116). O Data Access Object fornece baixo
acoplamento entre as camadas de negócio e de persistência. O Data Access Object intercepta
e presta serviços a todos os acessos à camada de persistência, tornando os detalhes da
implementação das camadas de persistência transparentes para os clientes. Os dados na
camada de persistência podem persistir em sistemas de bancos de dados, sistemas
proprietários, outros sistemas e serviços externos. Utilizando esse padrão, pode-se criar
aplicações que sejam mais flexíveis e portáveis (ALUR, et al, 2002, p.126).
No PLACES utiliza esse padrão por meio do Hibernate (ver seção 4.1.2). Neste caso
utilizando as classes do tipo Transfer Object (ver seção 4.2.7). Estas classes representam uma
ou mais tabelas no banco de dados. Essas classes são mapeadas pelo Hibernate. Utilizam-se
as classes do tipo Business Object para ter acesso as classes do tipo Transfer Object.
Resumindo é utilizado o padrão DAO por meio da configuração dos arquivos utilizados pelo
Hibernate (ver quadros 4, 6 e 7), a criação das classes dos tipos Transfer Object e Business
Object (ver seção 4.2.6 e quadro 5).
4.2.6 BUSINESS OBJECT
O Business Object (SUN, 2005) um objeto que implementa a lógica de negócios e/ou os
dados de negócios. Os dados de negócio e a lógica de negócios são implementados em objetos
de granulação grossa denominados objetos de negócios (business object). No J2EE, os objetos
de negócio são implementados como beans de sessão (session beans) ou de entidade (SUN,
2005). Em alguns casos, um objeto de negócios poderia ser um objeto Java arbitrário que
fornecesse algum serviço (padrões da camada de negócio) (ALUR et al, 2002, p.118). Este
padrão foi implementando por meio do framework Hibernate.
No PLACES as classes Business Object estão no pacote com.business.delegate (ver figura 5).
Essas classes são utilizadas no PLACES para fazer a inserção, a consulta, a atualização e
apagar os dados do banco de dados. Cada classe do tipo Business Object (ver quadro 5) tem
uma classe do tipo Transfer Object (ver seção 4.2.7) correspondente.
77
4.2.7 TRANSFER OBJECT
O Transfer Object (objeto de dados) um objeto Java arbitrário que é utilizado para transportar
dados de um objeto/camada para outro. Normalmente não contém nenhum método de
negócios. Pode ser projetado com atributos públicos ou fornecido com métodos get’s e set’s
para obter e atribuir valores dos atributos. (ALUR et al, 2002, p.125). O Transfer Object
fornece as melhores técnicas e estratégias para trocar dados através de camadas (isto é, através
de limites de sistemas). Esse padrão tenta reduzir a sobrecarga de rede minimizando diversas
camadas de rede para receber dados da camada de negócios. Também é conhecido como
Value Object.
Este padrão foi implementado no pacote “com.transfer.object” no PLACES, contendo neste
pacote todas as classes de dados do PLACES (ver quadro 12). Todas as classes Transfer
Object são utilizadas para enviar os dados de um página para um controlador ou de un
controlador para uma página web. As classes Business Object (ver seção 4.2.6) são
responsáveis recuperar as classes Transfer Object do banco de dados. Neste caso utilizando o
Hibernate (ver seção 4.1.2). Por exemplo a classe ArtefatoTO.java (ver quadro 12) é mapeado
em um arquivo XML (ver quadro 7).
Quadro 12 Classe ArtefatoTO.java
4.2.8 DISPATCHER
O Dispatcher é um controlador que gerencia a seleção de uma visualização apropriada.
Separando esse comportamento do controlador principal (ALUR et al, 2002, p.119). Este
package com.transfer.object; import java.io.Serializable; import java.util.Date; /** @author Hibernate CodeGenerator */ public class ArtefatoTO implements Serializable { /** identifier field */ private Integer idArtefato; /** nullable persistent field */ private Integer idParticipanteCriou; /** nullable persistent field */ private Integer idTipoArtefato; /** nullable persistent field */ private String palavraChave; /** nullable persistent field */ private String codigoArtefato; /** nullable persistent field */ private String nomeArtefato; /** nullable persistent field */ private String descricaoArtefato; /** nullable persistent field */ private String grauComplexidade;
78
padrão é implementado por meio do framework Spring (ver seção 4.1.1 e o quadro 2). O qual
utiliza um arquivo XML (ver quadro 2) para configurar esse mecanismo.
4.3 O MÓDULO DE ESTIMATIVA
Antes de calcular a estimativa do tamanho pelo método de pontos de caso de uso, os casos de
uso devem estar cadastrados no sistema assim como os atores do sistema. É recomendado que
os valores e pesos dos fatores de ajuste sejam modificados de acordo com o projeto. Se
necessário, é possível adicionar um fator de ajuste, seja este fator de complexidade técnica ou
de ambiente. Para calcular o esforço e o custo a ferramenta tem uma tela (figura 16) que
possibilita o gerente entrar com os dados relativos a quanto seria o esforço por ponto de caso
de uso e valor da hora trabalhada. As próximas seções descrevem como as tarefas
mencionadas anteriormente podem ser executadas no sistema.
4.3.1 CADASTRO DE ATORES
Conforme o método pontos de caso de uso visto na seção 3.3, para calcular os pontos de caso
é preciso definir o grau de complexidade de cada ator. Para isso, o sistema tem o cadastro de
ator que possibilita o cadastro da complexidade.
Na página que lista os atores do sistema (figura 6) é possíver visualizar todos os atores de um
projeto de software. Desta página é possivel acessar as páginas de inclusão e edição, além de
poder excluir um ator.
Na página que lista os atores do sistema, ao optar pela opção “Incluir” o sistema exibirá a
página de cadastro de ator (figura 7).
Na página de cadastro de ator, no campo “código” o usuário pode escrever um código para o
ator. No campo “nome” o usuário pode escrever o nome do ator a ser cadastrado. No campo
“versão” o usuário pode escrever a versão do ator a ser cadastrado (o valor padrão é 1.0). No
campo “complexidade” o usuário pode selecionar a complexidade do ator a ser cadastrado
(que será usado para o cálculo do médoto pontos de caso de uso e pode variar entre baixo,
médio e alto). No campo “tipo artefato” o usuário pode selecionar outro tipo de artefato para
ser cadastrado (o valor padrão é ator, mas o usuário pode optar por cadastrar outro artefato
como caso de uso, requisitos funcionais, entre outros). No campo “palavras-chave”, o usuário
pode escrever as palavras-chave que representam o ator a ser cadastrado. No campo “autor”,
o usuário pode ver o nome do usuário logado no sistema. No campo “descrição geral” o
79
usuário pode escrever uma descrição do que o ator a ser cadastrado no sistema realiza no novo
sistema. O botão “Salvar” serve para inserir o novo ator no sistema.
Figura 6 Lista de atores.
Ao selecionar um ator na página que lista os atores e logo após o usuário optar pela opção
“Editar”, o sistema exibe a página de cadastro de ator, com os campos preenchidos de acordo
com o que esta cadastrado no banco de dados. Se o usuário alterar qualquer um dos campos e
selecionar a opção “Salvar”. Os dados serão atualizados no banco de dados.
Figura 7 Cadastro de ator.
Ao selecionar um ator na página que lista os atores e logo após o usuário optar pela opção
“Excluir”, (figura 8) o sistema exibe uma tela com a pergunta “Você deseja excluir o ator
80
nome do atorXX ?”. Se você selecionar o botão “OK” o sistema irá apagar o ator da base de
dados e voltar para a página que lista os atores (figura 6). Se você selecionar o botão
“Cancelar” o sistema irá retornar a página que lista os atores sem alterar a base de dados.
Figura 8 Excluir Ator.
4.3.2 CADASTRO DE CASOS DE USO
Conforme o método pontos de caso de uso visto na seção 3.3, para calcular é preciso definir o
grau de complexidade de cada caso de uso. Para isso, o sistema tem um campo do tipo seleção
(combobox) para definir o grau de complexidade de um caso de uso, conforme pode ser
observado na figura 10. Sendo assim, no cadastro do caso de uso já é possível definir o seu
grau de complexidade, que pode ser baixa, média ou alta. Isto pode também ser editado mais
tarde. Detalhes de como pode ser classificado um caso de uso está descrito na seção 3.3 deste
trabalho. Uma discusão mais ampla pode ser encontrada em Karner (1993) e Ribu (2001).
Figura 9 lista de Caso de uso
81
Na página que lista os casos de uso do sistema (figura 9) é possíver visualizar todos os casos
de uso de um projeto de software. Desta página é possível ir para a página de inclusão e
edição, além de poder excluir um caso de uso. Na página que lista os casos de uso do sistema,
ao optar pela opção “Incluir” o sistema exibirá a página de cadastro de casos de uso (figura
10).
Figura 10 Cadastro de caso de uso.
Na página de cadastro de casos de uso, no campo “código” o usuário pode escrever um código
para o caso de uso. No campo “nome” o usuário pode escrever o nome do caso de uso a ser
cadastrado. No campo “versão” o usuário pode escrever a versão do caso de uso a ser
cadastrado (o valor padrão é 1.0). No campo “complexidade” o usuário pode selecionar a
complexidade do caso de uso a ser cadastrado (que será usado para o cálculo do método
pontos de caso de uso e pode variar entre baixo, médio e alto. Ver seção 3.3). No campo “tipo
artefato” o usuário pode selecionar outro tipo de artefato para ser cadastrado (o valor padrão é
caso de uso, mas o usuário pode optar por cadastrar outro artefato como ator, requisitos
funcionais, entre outros). No campo “palavras-chave” o usuário pode escrever as palavras-
chave que representam o caso de uso a ser cadastrado. No campo “autor” o usuário pode ver o
nome do usuário logado no sistema. No campo “descrição geral” o usuário pode escrever
82
uma breve descrição do caso de uso. No campo “detalhamento” o usuário pode escrever o
fluxo base do caso de uso, os fluxos alternativos e os fluxos de exceção. O botão “Salvar”
serve para gravar o novo caso de uso no sistema.
Ao selecionar um caso de uso na página que lista os casos de uso e logo após o usuário optar
pela opção “Editar”, o sistema exibe a página de cadastro de casos de uso, com os campos
preenchidos de acordo com os dados do caso de uso selecionado. Se o usuário alterar qualquer
um dos campos e selecionar a opção “Salvar”. Os dados serão atualizados no banco de dados
Ao selecionar um caso de uso na página que lista os casos de uso e logo após o usuário optar
pela opção “Excluir”, (figura 11) o sistema exibe uma tela com a pergunta “Você deseja
excluir o caso de uso nome do caso de uso XX ?”. Se você selecionar o botão “OK” o sistema
irá apagar o caso de uso da base de dados e voltar para a página que lista os casos de uso
(figura 9). Se você selecionar o botão “Cancelar” o sistema irá retornar a página que lista os
casos de uso sem alterar a base de dados.
Figura 11 Excluir Caso de Uso
4.3.3 CADASTRO DE FATOR DE AJUSTE
Na tela de configuração dos fatores de ajuste (figura 12), são listados todos os fatores de
ajuste. A partir desta tela é possível editar, incluir ou apagar cada fator de ajuste. Inicialmente,
estão cadastrados no sistema 13 fatores de complexidade técnica e 8 fatores de ambiente com
os respectivos pesos conforme descrito na seção 3.3 tabelas 30 e 31 respectivamente. Os
valores iniciais para todos os fatores é 3.
83
Figura 12 Lista de Fatores de Ajuste
Para incluir um fator de ajuste, selecionar a opção “Incluir” para acessar a página de cadastro
de fator de ajuste (figura 13). No campo “descrição” o usuário pode escrever uma descrição
do fator de ajuste. No campo “peso” o usuário pode escrever um número conforme o peso
deste fator no desenvolvimento de um sistema de software. No campo “valor” o usuário pode
escrever o valor deste fator, este valor será o valor padrão para os futuros projetos. No campo
“tipo” o usuário pode selecionar o tipo de fator de ajuste (Fator de complexidade de ambiente
ou complexidade técnica). O botão “Salvar” serve para gravar o novo fator de ajuste no
sistema.
Ao selecionar um fator de ajuste na página que lista os fatores de ajuste (figura 12) e logo
após o usuário optar pela opção “Editar”, o sistema exibe a página de cadastro de fatores de
ajuste, porém com os campos preenchidos de acordo com o fator selecionado (figura 14). Se o
usuário alterar qualquer um dos campos e selecionar a opção “Salvar”. Os dados serão
atualizados no banco de dados.
84
Figura 13 Cadastro de Fator de Ajuste
Ao selecionar um dos fatores de ajuste na página que lista os casos de uso e logo após o
usuário optar pela opção “Excluir”, (figura 15) o sistema exibe uma tela com a pergunta
“Você deseja excluir fatores de ajuste nome fatores de ajuste XX ?”. Se você selecionar o
botão “OK” o sistema irá apagar o fatores de ajuste da base de dados e voltar para a página
que lista os casos de uso (figura 12). Se você selecionar o botão “Cancelar” o sistema irá
retornar a página que lista os fatores de ajuste sem alterar a base de dados.
Figura 14 Edição dos fatores de ajuste
85
Figura 15 Excluir um fator de ajuste
4.3.4 EDITAR O ESFORÇO
Na página que lista os casos de uso, o usuário pode optar pela opção “Pontos de Caso de
Uso”. O sistema então exibe a página de edição do esforço (figura 16).
Figura 16 Edita Esforço
No campo “esforço” o usuário pode escrever um número que corresponde o esforço por
pontos de caso de uso. No campo “tipo” o usuário seleciona o tipo de esforço (pode ser
86
homem/hora, homem/mês ou homem/ano, o padrão do sistema é homem/hora). No campo
“valor” o usuário pode escrever o valor de cada hora (pode ser de um mês ou de um ano, vai
depender do tipo selecionado no campo “tipo”) de trabalho de um participante do projeto. O
botão “Salvar” para gravar as alterações no sistema.
4.3.5 CÁLCULO DE PONTOS DE CASO DE USO
Para o cálculo de pontos de caso de uso são utilizadas as fórmulas descritas na seção 3.3. Na
página de edição de esforço (figura 16), o usuário pode optar pela opção “Calcular”. O
sistema exibe a página de pontos de caso de uso (figura 17) com resultado do cálculo do
método pontos de caso de uso. Onde é exibido a soma dos fatores ponderados dos casos de
uso, a soma dos fatores ponderados dos atores, o número não ajustado de pontos de caso de
uso, o número de fatores de complexidade técnica (TCF), o número de fatores de ambiente
(EF), o número de pontos de caso de uso, o esforço e o custo.
Figura 17 Calculo dos Pontos de Caso de Uso
87
4.4 ENTERPRISE ARCHITECT
A ferramenta Enterprise Architect também implementa o método pontos de caso de uso.
Nesta ferramenta, para cálcular o número de pontos de caso de uso pode-se fazer algumas
alterações nas configurações no esforço, e fatores de ajuste (figura 18). Diferente do módulo
implementado neste trabalho o Enterprise Architect apresenta uma tela diferente para inserir,
alterar ou excluir um fator de complexidade técnica (figura 19) do fator de complexidade do
ambiente (figura 20).
Figura 18 Configurar esforço e fatores de Ajuste
No campo “description” (figura 19) o usuário do Enterprise Architect pode escrever uma
descrição do fator de ajuste. No campo “assigned value” o usuário pode escrever um número
conforme o peso deste fator no desenvolvimento de um sistema de software. No campo
“weight” o usuário pode escrever o valor deste fator.
Figura 19 Fatores de complexidade técnica no EA.
88
A tela de fatores de complexidade de ambiente (figura 20) tem as mesmas funcionalidades da
tela de fatores de complexidade técnica (figura 19), a diferença que uma tela cadastra fatores
de complexidade técnica e a outra cadastra os fatores de complexidade de ambiente.
Figura 20 Fatores de complexidade ambiente no EA.
Para cálcular o número de pontos de caso de uso no Enterprise Architect, após ter cadastrado
os casos de uso e os atores do sistema, tem a opção Use Case Metrics no menu project
(figura 21). O Enterprise Architect exibirá a tela de pontos de caso de uso (figura 22).
Na tela de pontos de caso de uso é possível ver os casos de uso e os atores do sistema
modelado no Enterprise Architect (figura 22) com seus respectivos valores de complexidade
(ver seção 3.3.1 e as tabelas 26, 27 e 28). A tela mostra o número de pontos de caso de uso
não ajustado (UUCP).
É apresentado também o número de fator de complexidade técnica e de ambiente com as
fórmulas do método pontos de caso de uso, com a possibilidade de alterar os valores da
fórmula. A tela apresenta também o número de pontos de caso de uso ajustado (UCP) e o
número de horas estimadas para a execução do projeto.
89
Figura 21 Calcular pontos de caso de uso no EA
Figura 22 Tela de pontos de caso de uso no EA
A principal vantagem do Enterprise Architect é o ambiente gráfico para o cadastro de casos
de uso e de atores do sistema (figura 23).
90
Figura 23 diagrama de casos de uso.
4.5 COMPARAÇÃO ENTRE AS FERRAMENTAS
As vantagens da estimativa de tamanho no Enterprise Architect são:
• O ambiente gráfico para o cadastro de casos de uso e de atores do sistema.
• Possibilita o cálculo do tamanho por meio de pontos de caso de uso.
As vantagens do módulo de estimativa de tamanho do PLACES são:
• Ambiente integrado de gerencia de projetos.
• Acesso via internet.
• Suporte ao idioma português.
Apesar do Enterprise Architect ter um surporte gráfico bom, o PLACES se destaca pelo fato
de ser um ambiente de estimativa de tamanho integrado com as funcionalidades de gerência,
possibilitando um auxilio na elaboração de cronogramas e análise de custo.
4.6 ESTUDO DE CASO
Para validar o sistema, foi utilizado um estudo de caso real. O projeto de software escolhido
foi sistema de plano de ensino online, desenvolvido no NCOMP em 2003. Este sistema tinha
como características:
91
• Abordagem orientada a objetos.
• Software desenvolvido em camadas para a web.
• Linguagem utilizada PHP.
• Banco de dados ORACLE.
Os casos de uso deste sistema estão detalhados no anexo 10 deste trabalho. O sistema de
plano de ensino é composto por 8 casos de uso, sendo 2 de complexidade alta, 2 de
complexidade média e 4 de complexidade baixa. O sistema possui ainda 3 atores de
complexidade alta e 1 de complexidade média.
Ao utilizar o módulo desenvolvido, é possível estimar um tamanho de 36,08 pontos por caso
de uso. O cálculo do esforço irá depender da empresa e dos dados históricos da empresa.
Supondo que o esforço seja 15 horas por ponto de caso de uso, chegou-se a um esforço
estimado de 541,20 homens/hora. Para 20 horas por ponto de caso de uso, o esforço seria de
721,67 homens/hora. Já, utilizando um total de 30 horas para cada ponto de caso de uso, o
esforço seria de 1.082,5 homens/hora. Para estimar prazo e custo, seria necessário obter outras
informações além do esforço. Sendo assim, estas estimativas não serão tratadas neste estudo
de caso.
Considerando que, na situação real de desenvolvimento do sistema de plano de ensino o
esforço foi de 500 homens/hora, é possível verificar que o tamanho estimado a partir de 15
horas por ponto de caso de uso ficou bastante próximo. Entretanto, esta informação não é
suficiente para concluir a precisão do método. Para uma validação real, seria necessário a
aplicação em vários estudos de caso da organização, com um levantamento histórico para
identificar o valor médio de horas por ponto de caso de uso que deveria ser utilizado para cada
tipo de projeto.
92
5 CONCLUSÃO
Este trabalho apresenta uma revisão dos métodos análise por pontos de função, COCOMO e
pontos de caso de uso. Sendo que foi desenvolvido um protótipo de software a partir do
método pontos de caso de uso. Esta escolha se deve ao fato dos pontos de caso de uso ser uma
estimativa para projetos de software orientados a objetos.
Estimativa adequada para projetos orientados a objetos que utilizam casos de uso para
descrever a funcionalidade do sistema. Segundo Damodaran (2003, p.2), uma possível razão
para as empresas de desenvolvimento de software não utilizarem o método UCP na estimativa
de esforço é porque não há ferramentas populares de estimação de projetos utilizando o
método pontos de casos de uso. Neste sentido, este trabalho contribuí com um módulo de
estimativa de tamanho na plataforma PLACES. Tendo como principal vantagem a integração
com um ambiente de gerência de projetos.
A técnica é simples, mas exige cuidados para sua aplicação efetiva. São necessários dados
históricos para apurar o cálculo de esforço. Está técnica pode ser usada para auxiliar na
elaboração de cronograma e na análise de custo, porém deve-se observar que o esforço é
apenas uma das entradas necessárias para o cálculo da estimativa de tempo e custo. Por esse
motivo à ênfase deste trabalho é a estimativa de tamanho.
A estimativa pode ser calculada apenas com o levantamento dos casos de uso, dificultando
seu uso para auxiliar na preparação de um contrato. Porém, é possível utilizar uma abordagem
simplificada, sem envolver o detalhamento dos casos de uso. Desta forma, esta adaptação
poderia ser utilizada no início (pré-estimativas).
O módulo de estimativa permite o cadastro dos atores e de casos de uso com a possibilidade
de classificá-los em simples, médio e complexo. Permite também o cadastro dos fatores de
complexidade técnica e de complexidade de ambiente. Este módulo calcula os fatores
93
ponderados, e permite a edição do valor esforço em pessoa/hora. E com base nos casos de uso
já cadastrados e nos fatores ponderados, o módulo calcula o esforço total do projeto.
Este trabalho agrega novas funcionalidas ao ambiente PLACES, tornando-o mais atrativo para
a gerência de projetos de software. Os quatro objetos específicos deste trabalho foram
alcançados, tais objetivos são descritos a seguir:
• O objetivo de identificar as principais medidas utilizadas para as estimativas de
tamanho em projetos de software, focando naquelas voltadas a projetos orientados a
objeto foi alcançado (seção 3). Este trabalho estruturou a teoria sobre estimativas em
projetos de software, aprofundando-se em projeto orientados a objetos. Neste sentido,
este trabalho consiste na implementação do método por pontos de caso de uso.
• O objetivo de modelar o sistema foi feito (anexo 2, 5, 6, 7 e 9), o qual ajudou no
entendimento do método pontos de caso de uso.
• O objetivo de adptação do ambiente ARCase para integrar a plataforma PLACES foi a
parte mais trabalhosa deste trabalho. Porque além de estudar a nova técnologia usada
no PLACES (Spring, Hibernate e os padrões de projeto), foi também necessário
estudar o código e as funcionalidades do ARCase.
• O objetivo de comparar os resultados obtidos foi realizado. Utilizou-se 10 casos de
uso (anexo 3) como entrada de dados para testar do módulo de estimativa, os mesmos
teste foi realizado no Enterprise Architect. Obtendo o mesmo resultado nas duas
ferramentas. Utilizou-se 15 casos de teste (anexo 4) de acordo com os requisitos
funcionais, não funcionais (anexo 6) e regras de negócio (anexo 5), A grande
vantagem do módulo desenvolvido neste trabalho é que uma ferramenta web. A
ferramenta também está no idioma português.
Neste sentido, os objetivos geral e específicos deste trabalho foram alcançados. As principais
dificuldades foram o aprendizado da linguagem de programação (no caso Java), pouco
conhecimento para programação voltada para internet (configuração do servidor), e pouco
conhecimento de utilização de frameworks (Spring e Hibernate) e padrões de projeto.
A vantagem do módulo de estimativa no PLACES é que esta ferramenta está agregada a
software de gerência de projetos. Outra vantagem é o fato de a ferramenta ser acessada via
internet.
94
5.1 TRABALHO FUTURO
Este trabalho pode ser continuado, segue algumas sugestões dos trabalhos futuros:
• Implementar um mecanismo automático para informar a complexidade dos atores e
casos de uso, possibilitando uma estimativa mais apurada.
• Permitir a extração de informações históricas da plataforma PLACES, permitindo o
refinamento do cálculo de esforço.
• Desenvolver um mecanismo de importação XMI, para importar os diagramas do
Enterprise Architect, ou outra ferramenta CASE.
• Desenvolver um ambiente gráfico para o cadastro de artefatos no PLACES.
• Implementar o método COCOMO em conjunto com pontos de caso de uso,
possibilitando uma estimativa de outros recursos além do recurso humano para o
desenvolvimento de software.
95
ANEXO 1
MIDDLEGENIDE
O plugin middlegenide (middlegenide_1.3.2.zip) para o eclipse19 é usado para fazer o
mapeamento do banco de dados para o Hibernate. Para a instalação desse plugin é necessário
os arquivo middlegenide_1.3.2.zip, GEF-SDK-3.1.zip, emf-sdo-xsd-SDK-2.1.0.zip e mysql-
connector-java-3.0.16-ga-bin.jar (este arquivo é usado para a conecção com o banco de
dados, neste trabalho foi usado o banco de dados MySQL, para outros bancos de dados é
necessário outro arquivo de conexão).
Para instalar middlegenide descompacte os 3 arquivos zip para dentro do diretório do eclipse
sobrescrevendo os arquivos. Esta pronta a instalação do middlegenide, agora inicialize o
eclipse, crie um novo projeto e no projeto criado crie um novo Source Folder. Dentro da
Source Folder criado clique com o botão direito e selecione new->other, conforme figura 24.
Figura 24 Opção Other do menu new.
Selecione middlegen Build File e clique em Next>, conforme figura 19.
19 Ferramenta de desenvolvimento Java.
96
Figura 25 Criar um middlegen Build File.
Clique no botão Next>, conforme figura 25.
Figura 26 Seleção do arquivo Build.
Clique no botão Browser conforme figura 26.
97
Figura 27 Conectando com o banco.
Selecione o arquivo “mysql-connector-java-3.0.16-ga-bin.jar”(é esse o arquivo para banco de
dados MySQL) e clique no botão Abrir, conforme figura 27.
Figura 28 Arquivo .JAR de conexão com o banco de dados.
Preencher as informações necessárias para conexão com o banco de dados, como os campos:
Database URI, User, e Password e clique em load conforme figura 28.
Selecione as tabelas que serão mapeadas para o Hibernate e clique no botão Finish.
98
Figura 29 Carregando as tabelas do banco de dados.
Verifique os relacionamentos e tipos de dados das tabelas e clique no menu Generate e feche
a janela. O eclipse irá criar as classes TO (Transfer Object) e os mapeamentos XML
correspondentes entre as classes TO e as tabelas do banco.
99
ANEXO 2
CASOS DE USO
Caso de Uso 001 - Nome: Cadastro de Atores
Ator ativo: Analista de Sistema
Atores passivos: N\A.
Meta: Calcular o esforço a partir dos casos de uso, atores e fatores de ajuste cadastrados no sistema.
Pré-condição: O analista de sistema deve estar logado no sistema.
Requisitos Funcionais: REF.02.
FLUXO BASE
1. O sistema exibe a lista de atores. (TEL-011).
2. O analista seleciona a opção incluir.
3. O sistema apresenta a tela de cadastro de ator.(TEL-012).
4. O analista digita os dados do ator, e opta por gravá-los.
5. O sistema grava e mostra a mensagem: ator gravado com sucesso.
(TEL-002).
Pós-condição: O ator está cadastrado no sistema.
FLUXO ALTERNATIVO – FA-01 Cancelamento
Nos passos 1, 2 ou 3 do fluxo base, o analista pode cancelar.
1. O sistema sai da tela de cadastro de ator
Pós-condição: Nenhuma alteração no sistema
FA-2 Edita Ator
100
No passo 2 do fluxo base, o analista seleciona um ator.
1. O analista seleciona a opção Editar.
2. O sistema exibe uma tela de edição de ator.(TEL-012).
3. O analista edita o caso de uso e opta por gravá-los.
4. O sistema grava a alteração no ator.
5. O sistema exibe uma mensagem de alterção feita com sucesso. (TEL-002).
Pós-Condição: O ator foi alterado.
FA-3 Exclui Ator
No passo 2 do fluxo base, o analista seleciona um ator.
1. O analista seleciona a opção Excluir.
2. O sistema exibe uma tela de confirmação.(TEL-002).
3. O analista confirma.
4. O sistema exclui o ator.
5. O sistema exibe uma mensagem de exclusão feita com sucesso. (TEL-002).
Pós-Condição: O ator foi excluído.
FLUXO DE EXCEÇÃO – FE-1 Erro ao salvar ator
No passo 4 do fluxo base, o sistema não consegue salvar o ator.
1. O sistema sai da tela de cadastro de ator e apresenta uma tela de erro (TEL-002).
Pós-condição: Nenhuma alteração no sistema
FE-2 Erro ao editar
101
No passo 3 do fluxo alternativo 2, o sistema não consegue salvar as alterações .
1. O sistema exibe uma tela de erro.(TEL-002).
FE-3 Erro ao excluir
No passo 5 do fluxo alternativo 3, o sistema não consegue excluir o ator.
1. O sistema exibe uma tela de erro.(TEL-002).
Pós-Condição: Nenhuma alteração.
Caso de Uso 002 - Nome: Cadastra Caso de Uso
Ator ativo: Analista de Sistema
Atores passivos: N\A.
Meta: Cadastrar (Incluir, editar e excluir) um caso de uso.
Pré-condição: N/A.
Requisitos Funcionais: REF.03.
FLUXO BASE
1. O sistema exibe a lista de caso de uso. (TEL-006).
2. O Analista seleciona o incluir.
3. O sistema apresenta a tela de cadastro de caso de uso.(TEL-004).
4. O analista digita os dados do caso de uso, e opta por gravar os dados.(RNE.006)
5. O sistema grava dados e mostra a mensagem: caso de uso gravado com sucesso.
(TEL-002).
Pós-condição: O caso de uso esta cadastrado no sistema.
FLUXO ALTERNATIVO – FA-1 Cancela Cadastro
No passo 1, 2, 3 do fluxo base o Analista pode cancelar.
1. retorna ao passo 1 do caso de uso.
102
Pós-condição: Nenhuma alteração no sistema
FA–2 Edita Caso de uso
No passo 2 do fluxo base, o analista seleciona um caso de uso.
1. O analista seleciona a opção Editar.
2. O sistema exibe uma tela de edição de caso de uso.(TEL-004).
3. O analista edita o caso de uso e seleciona gravar. (RNE.006)
4. O sistema grava a alteração no caso de uso.
5. O sistema exibe uma mensagem de alteração feita com sucesso. (TEL-002).
Pós-Condição: O caso de uso foi alterado.
FA-2.1 Cancela Edição
Nos passos 1, 2 ou 3, do fluxo alternativo FA-2 o analista cancela a edição.
1. Retorna ao passo 1 do fluxo base.
Pós-Condição: Nenhuma alteração.
FA-3 Excluir Caso de Uso
No passo 2 do fluxo base, o analista seleciona um caso de uso.
1. O analista seleciona a opção Excluir.
2. O sistema exibe uma tela de confirmação.(TEL-002).
3. O analista confirma.
4. O sistema exclui o caso de uso.
5. O sistema exibe uma mensagem de exclusão feita com sucesso. (TEL-002).
Pós-Condição: O caso de uso foi excluído.
103
FA-3.1 Cancela Exclusão
Nos passos 1,2 ou 3 do fluxo alternativo FA-3, o analista cancela.
1. Retorna ao passo 1 do fluxo base.(TEL-006).
Pós-Condição: Nenhuma alteração.
FLUXO DE EXCEÇÃO – FE-1 Erro ao gravar
No passo 4 do fluxo base o sistema não consegue gravar o caso de uso.
1. O sistema sai da tela de cadastro de caso de uso e apresenta uma tela de erro (TEL-002).
Pós-condição: Nenhuma alteração no sistema
FE-2 Erro ao excluir
No passo 5 do fluxo alternativo 3, o sistema não consegue excluir o caso de uso.
1. O sistema exibe uma tela de erro.(TEL-002).
Pós-Condição: Nenhuma alteração.
Caso de Uso 003 - Nome: Calcula Pontos de Caso de Uso
Ator ativo: Analista de Sistema
Atores passivos: N\A.
Meta: Calcular o esforço a partir dos casos de uso, atores e fatores de ajuste cadastrados no sistema.
Pré-condição: N/A.
Requisitos Funcionais: REF.06, REF.07, REF.08, REF.09.
FLUXO BASE
104
1. O sistema exibe a lista de caso de uso (TEL-006).
2. O analista seleciona a opção Pontos de caso de Uso.
3. O sistema exibe a tela de edição de esforço. (TEL-008).
4. O analista seleciona Calcular.(RNE. 003, RNE. 004, RNE. 005, RNE. 006, RNE. 007, RNE. 008,
RNE. 009, RNE. 010, RNE. 011)
5. O sistema calcula o número de pontos de caso de uso, o esforço e o custo.
6. O sistema exibe a tela de Pontos de caso de Uso. (TEL-009).
Pós-Condição: O sistema calculou o número de Pontos de caso de uso.
FLUXO ALTERNATIVO – FA-01 Edita Esforço
No passo 4 do fluxo base, o analista edita os campos esforço, custo e tipo.
1. O analista seleciona a opção Salvar.
2. O sistema salva as alterações.
Pós-Condição: O dados de esforço são alterados.
FA-02 Cancela Edição
No passo 1, 2 ou 3, do fluxo alternativo FA-01 o analista cancela a edição .
1. Retorna ao passo 1 do fluxo base.
Pós-Condição: Nenhuma alteração.
FLUXO DE EXCEÇÃO – FE-01 Erro ao Calcular
No passo 5 do fluxo base, o sistema não consegue fazer o calculo.
1. O sistema mostra uma tela de erro (TEL-002).
Pós-Condição: Nenhuma modificação do sistema
105
FE-02 Erro ao editar
No passo 2 do fluxo Alternativo FA-01, o sistema não consegue salvar as alterações.
1. O sistema mostra uma tela de erro. (TEL-002)
Pós-Condição: O dados de esforço não são alterados.
Caso de Uso 004 - Nome: Cadastra Fatores de Ajuste
Ator ativo: Analista de Sistema
Atores passivos: N\A.
Meta: Cadastrar (Incluir, editar e excluir) Fatores de Ajuste conforme a necessidade do projeto.
Pré-condição: N/A.
Requisitos Funcionais: REF.04, REF.05
FLUXO BASE
1. O sistema exibe a lista de caso de uso (TEL-006).
2. O analista seleciona a opção Fator de ajuste.
3. O sistema exibe a lista de fatores de ajuste. (TEL-007).
4. O analista seleciona a opção incluir.
5. O sistema exibe a tela de cadastro de Fator de Ajuste (TEL-010)
6. O analista digita os dados e seleciona a opta por gravar os dados.
7. O sistema grava os dados do novo Fator de Ajuste.
Pós-Condição: Novo Fator de Ajuste é gravado no sistema.
FLUXO ALTERNATIVO – FA-1 Edita Fator de Ajuste
No passo 4 do fluxo base, o analista seleciona um fator de Ajuste.
106
1. O analista seleciona a opção excluir fator de ajuste.
2. O sistema exibe a tela de edição de fator de Ajuste (TEL-010)
3. O analista digita os dados e seleciona a opta por gravá-los.
4. O sistema grava os dados do fator de Ajuste
Pós-Condição: o Fator de Ajuste é gravado no sistema com as novas alterações.
FLUXO ALTERNATIVO – FA-2 Exclui Fator de Ajuste
No passo 4 do fluxo base, o Analista seleciona um fator de ajuste
1. O analista seleciona a opção excluir fator de ajuste.
2. O sistema exibe a mensagem "Você deseja Excluir o Fator de Ajuste XX" (TEL-002)
3. O analista confirma.
4. O sistema exclui o fator de ajuste.
Pós-Condição: o Fator de Ajuste é excluído do sistema.
FLUXO DE EXCEÇÃO – FE-1 Erro ao salvar
No passo 6 do fluxo base, o sistema não consegue gravar o fator de ajuste.
1. O sistema exibe uma tela de erro (TEL-002).
Pós-Condição: Nenhuma alteração no sistema.
FE-2 Erro ao excluir Fator de Ajuste
No passo 4 do fluxo alternativo FA-2, o sistema não consegue excluir o fator de Ajuste.
1. O sistema exibe a mensagem de erro. (TEL-002)
107
Pós-Condição: Nenhuma alteração no sistema.
TELA 002 – Mensagem Padrão
cd Interface
«web page»TEL-002 Mensagem padrão
Texto qualquer...
Ok
TELA 003 – Mensagem Padrão
cd Interface
«web page»TE-003 Pergunta padrão
Pergunta a ser feita?
Sim Não
108
TELA 004 – Cadastro de Casos de Uso
cd TEL-004 Cadastro Artefato
TEL-004- Cadastro de Artfato
Nome do Artefato
Tipo do Artefato
Código do Artefato
Versao
Descricao
detalhes
Salvar
Grau de Complexidade
Palavras Chaves
Cancela
TELA 006 – Lista Casos de Uso
cd TEL-006- Lista de Artefatos
TEL-006 Lista de Artefatos
Artefato XX
Incluir Editar Excluir Voltar
109
TELA 007 – Lista Fatores de Ajuste
cd TEL-007 Lista Fatores de Ajuste
TEL-007 Lista Fatores de Ajuste
T1 - Fator de Ajuste XXX
Incluir Editar Excluir Voltar
E1- Fator de Ajuste XY
TELA 008 – Edição de esforço
cd TEL-008 Tela de edição de Eforço
TEL-008 Edição de Esforço
esforço
Tipo do esforço
Custo de 1 hora trabalhada
Salvar Cancelar Calcular
110
TELA 009 – Pontos de caso de uso
cd TEL-009 Pontos de Caso de Uso
TEL-009 Pontos de Caso de Uso
Pontos de caso de uso
Esforço
Custo
Valor TCF
Valor Ef
TELA 010 – Cadastro de Fator de Ajuste
cd TEL-010 Cadastro/Edicao Fator de Ajuste
TEL-010 Fator de Ajuste
Descricao
Eh_TCF
Peso
Valor
111
TELA 011 – Lista Atores
TELA 012 – Cadastro de Ator
112
ANEXO 3 CASOS DE USO PARA O TESTE DO MÓDULO DE ESTIMATIVA
ud Atores do Sistema
Participante
Administrador
Gerente
Cliente
Figura 30 Atores do Sistema
Caso de Uso do Sistema
Figura 31 Caso de Uso do Sistema
113
USC-001 Cadastra Projeto
Restrições
Approved Pré-condição . O administrador deve estar logado no sistema. O administrador
deve estar cadastrado . Um participante com responsabilidade de gerente deve estar
cadastrado.
Fluxo base
1. O sistema exibe a tela de cadastro de projeto. TEL-004.
2. O Administrador preenche o nome do projeto, e seleciona um gerente.
3. O administrador clica em Salvar .
4 O sistema exibe uma mensagem que o projeto foi cadastro com sucesso. (TEL-002).
Pós-condição: o projeto foi cadastrado.
FA-01 - Editar {Alternativo}.
Se, no passo 2 do fluxo base, o administrador digita o nome do projeto e clica em pesquisar.
1. O sistema exibe o projeto pesquisado.
2. O administrador altera os dados e clica em Salvar.
3. O sistema salva as alterações.
Pós-condições: Alterações salvas.
FA-02.01 Não Exclui projeto {Alternativo}.
Se, no passo 4 do fluxo alternativo 02 (FA-02), o administrador seleciona NÃO.
1. O sistema volta ao passo 1 do fluxo base..
Pós-Condição: O projeto não é excluído.
FA-02 - Excluir {Alternativo}.
114
Se, no passo 2 do fluxo base, o administrador digita o nome do projeto e clica em pesquisar.
1. O sistema exibe o projeto pesquisado.
2. O administrador seleciona a opção excluir.
3. O sistema exibe a pergunta: "Tem certeza que deseja excluir este projeto ?"(TEL-003).
4. O administrado seleciona SIM.
5. O sistema exclui o projeto do sistema.
Pós-condições: o projeto excluído.
FA-03 - Cancela {Alternativo}.
Se, no passo 2 do fluxo base, o administrador seleciona a opção cancelar.
1. termina o caso de uso.
Pós-Condição: o caso de uso é terminado sem nenhuma alteração.
FE - 01 Dados em Barnco {Exceção}.
Se, no passo 3, o administrador deixar os campos em branco.
1. O sistema apresenta a mensagem: "Os dados do projeto devem ser preenchidos."
2. Retorna ao passo 1 do Fluxo Base.
USC-002 Cadastra Participante
Restrições
Approved Pré-condição . O administrador deve estar logado no sistema. O administrador deve
estar cadastrado.
Fluxo Base.
1. O sistema exibe a tela de cadastro de Participante. TEL-025.
2. O Administrador preenche o login, cargo e senha do participante.
3. O administrador clica em Salvar .
115
4. O sistema exibe uma mensagem que o participante foi cadastrado com sucesso. (TEL-002).
Pós-condição: o participante foi cadastrado .
FA01 - Editar {Alternativo}.
1. No passo 2 o administrador digita o login do participante e clica em pesquisar.
2. O sistema exibe o participante pesquisado.
3. O administrador altera os dados e clica em Salvar.
4. O sistema salva as alterações.
Pós-condições: Alterações salvas.
FA02 - Excluir {Alternativo}.
1. No passo 2 o administrador digita o login do participante e clica em pesquisar.
2. O sistema exibe o participante pesquisado.
3. O administrador confere os dados e clica em Excluir.
4. O sistema pede confirmação do administrador (TEL-003)
5. Caso o administrador confirme o sistema exclui o participante.
Pós-condições: Participante excluído
FA03 - Login não encontrado {Alternativo}.
1. No passo 1 do FA01 ou FA02, o administrador digita o login de participante que não esteja
cadastrado no sistema e clica em pesquisar;
2. O sistema exibe mensagem que o participante não foi encontrado no cadastro (TEL-002).
Pós-condições: Volta para passo 1 do FA02 ou FA01
116
FA04 - Desistir de Exclusão {Alternativo}.
1. No passo 4 do FA02, o administrador não confirma a exclusão.
Pós-condições: Volta para passo 1 do FA02.
USC-003 Cadastra Responsabilidades
Restrições
Mandatory Pré-condição . O administrador precisa estar logado no sistema.
Fluxo base: Inclusão de uma responsabilidade
1. O sistema apresenta a lista de responsabilidades. (TEL-014)
2. O administrador opta por criar uma nova responsabilidade.
3. O sistema apresenta uma tela para a edição de uma responsablidade (TEL-015)
4. O administrador preenche as informações e confirma.
5. O sistema valida os dados e efetua a gravação da responsabilidade. (RNE-020)
6. O sistema registra a ocorrência no histórico de uso (log). (RNE-012)
7. O sistema volta ao passo 1 deste fluxo.
Fluxo alternativo 1: Edição de responsabilidade {Alternativo}.
Condição: no passo 2 do fluxo base, se o administrador optar por editar uma responsabilidade
existente.
1. O sistema apresenta uma tela com as informações preenchidas da responsablidade (TEL-
015)
Fluxo alternativo 2: Alteração de responsabilidade {Alternativo}.
Condição: no passo 2 do fluxo base, se o administrador optar por editar uma responsabilidade
existente.
1. O sistema vai para o passo 3 do fluxo base e segue o fluxo base a partir dali.
117
Fluxo alternativo 3: Exclusão de responsabilidade {Alternativo}.
Condição: após fazer o passo 1 do fluxo alternativo 1, se o administrador optar por apagar
uma responsabilidade existente.
1. O sistema apresenta uma tela para confirmar a exclusão. (TEL-003)
2. Se a resposta for SIM, o sistema exclui a responsabilidade e registra a ocorrência no
histórico de uso (log). (RNE-012)
3. O sistema volta ao passo 1 do fluxo base.
Fluxo de exceção 1: Dados inválidos {Exceção}.
Condição: no passo 5 do fluxo base, se o sistema identificar problemas nos dados da
responsabilidade.
1. O sistema apresenta uma mensagem de erro para cada problema encontrado, informando
qual foi o problema.
2. O sistema vai para o passo 4 do fluxo base.
USC-004 Cadastra tarefa
Restrições
Proposed Pré-condição . O gerente precisa estar logado no sistema. As pós-condições estão
cadastradas com os fluxos (ver aba Scenario). Os projetos devem estar cadastrados no
sistema.
Fluxo base: Incluir tarefa
1. O sistema apresenta a lista de tarefas. (TEL-009)
2. O gerente opta por criar uma nova tarefa.
3. O sistema apresenta uma tela para a edição de uma tarefa (TEL-008) (RNE-002)
118
4. O gerente preenche as informações dos campos desprotegidos e confirma.
5. O sistema valida os dados e efetua a gravação da tarefa. (RNE-003)
6. O sistema registra a ocorrência no histórico de uso (log). (RNE-012)
7. O sistema volta ao passo 1 deste fluxo.
Pós-condição do fluxo base: Uma tarefa foi criada no sistema.
Fluxo alternativo 1: Consulta tarefa {Alternativo}.
Condição: no passo 2 do fluxo base, se o gerente optar por editar uma tarefa existente.
1. O sistema apresenta uma tela com as informações preenchidas da tarefa (TEL-008) (RNE-
004)
Pós-condição do fluxo alternativo 1: Uma tarefa foi editada no sistema.
Fluxo de exceção 1: Dados inválidos {Exceção}.
Condição: no passo 5 do fluxo base, se o sistema identificar problemas nos dados da tarefa
1. O sistema apresenta uma mensagem de erro para cada problema encontrado, informando
qual foi o problema. (TEL-002)
2. O sistema vai para o passo 4 do fluxo base.
Pós-condição do fluxo de exceção 1: a mesma do fluxo base.
Fluxo alternativo 2: Alteração de tarefa {Alternativo}.
Condição: no passo 2 do fluxo base, se o gerente optar por editar uma tarefa existente.
1. O sistema vai para o passo 3 do fluxo base e segue o fluxo base a partir dali. (no passo 3, o
sistema apresenta a tela através da regra de negócios RNE-004 e não a RNE-002 e no passo 5.
o sistema valida os dados através da regra de negócios RNE-007 e não a RNE-003)
119
Pós-condição do fluxo alternativo 2: Uma tarefa foi atualizada no sistema.
Fluxo alternativo 3: Limpar tarefa {Alternativo}.
Condição: no passo 4 do fluxo base, se o gerente optar por selecionar o botão Limpa.
1. O sistema deve verificar se existe alguma alteração de atributos de tela não gravados no
cadastro de tarefa. (RNE-008)
2. O sistema devolve uma tela com todos os campos desprotegidos não preenchidos.
Pós-condição do fluxo alternativo 3: O sistema deverá apresentar uma tela vazia. (TEL-008).
Fluxo alternativo 4: Excluir tarefa {Alternativo}.
Condição: após fazer o passo 1 do fluxo alternativo 1, se o gerente optar por apagar uma
tarefa existente.
1. O sistema apresenta uma tela para confirmar a exclusão. (TEL-003)
2. Se a resposta for SIM, o sistema exclui a tarefa e todos os participantes associados a essa
tarefa (RNE-005), além de registrar a ocorrência no histórico de uso (log). (RNE-012)
3. O sistema volta ao passo 1 do fluxo base.
Pós-condição do fluxo alternativo 4: Uma tarefa foi excluída do sistema, assim como todos os
participantes associados a essa tarefa.
Fluxo alternativo 5: Cancelar cadastro de tarefa {Alternativo}.
Condição: no passo 4 do fluxo base, se o gerente optar por selecionar o botão Volta.
1. O sistema retorna a tela de seleção de tarefas, sem alterar o cadastro da tarefa. (TEL-009)
(RNE-009)
120
Pós-condição do fluxo alternativo: O sistema retorna a tela que originou a chamada da tela
cadastra tarefa.
Fluxo alternativo 6: Estimativa percentual conclusão {Alternativo}.
Condição: no passo 4 do fluxo base, se o gerente optar por selecionar o botão Estimativa.
1. O sistema segue o fluxo base dos Casos de Uso USC-004.1
Fluxo alternativo 7: Associar Participante {Alternativo}.
Condição: no passo 4 do fluxo base, se o gerente optar por selecionar o botão Participante.
1. O sistema verifica se houve alteração nos dados do cadastro de tarefa (RNE-010)
2. Caso não houve alteração, o sistema segue o fluxo base dos Casos de Uso USC-004.2
USC-005 Cadastra Atividade
Restrições
Approved Pré-condição . Ter um projeto cadastrado.
Fluxo Base
1. O sistema exibe a tela de cadastro de atividade. TEL-007.
2. O Participante preenche o nome da atividade, e seleciona uma tarefa ou se atividade avulsa.
3. O Participante clica em Salvar .
4 O sistema exibe uma mensagem que a atividade foi cadastrada com sucesso. (TEL-002).
Pós-condição: A atividade foi cadastrada.
FA-01 Edita {Alternativo}.
Se, no passo 2 do fluxo base, o Participante digita o nome da atividades e clica em pesquisar.
1. O sistema exibe a atividade pesquisada.
2. O Participante altera os dados e clica em Salvar.
121
3. O sistema salva as alterações.
Pós-condições: Alterações salvas.
FA-02 Excluir {Alternativo}.
Se, no passo 2 do fluxo base, o Participante digita o nome da atividade e clica em pesquisar.
1. O sistema exibe a atividade pesquisada.
2. O Participante seleciona a opção excluir.
3. O sistema exibe uma pergunta: "Deseja excluir esta tarefa?"
4. O Participante seleciona a opção SIM.
5. O sistema exclui a atividade do sistema.
Pós-condições: a atividade foi ecluída.
FA-02.01 Não exclui atividade {Alternativo}.
Se, no passo 4 do fluxo alternativo 02(FA-02), o Participante seleciona a opção NÃO.
1. retorna ao passo 1 do fluxo base.
Pós-condições: a atividade NÃO foi ecluída.
FA-03 Cancela {Alternativo}.
Se, no passo 2 do fluxo base, o Participante seleciona a opção cancelar.
1. termina o caso de uso.
Pós-Condição: o caso de uso é terminado sem nenhuma altera
FE-01 Dados em branco {Exceção}.
122
Se, no passo 3, o Participante deixar os campos em branco.
1. O sistema apresenta a mensagem: "Os dados do projeto devem ser preenchidos."
2. Retorna ao passo 1 do Fluxo Base.
USC-006 Configura Notificação
Restrições
Approved Pré-condição . Um participante com responsabilidade de gerente deve estar
cadastrado. O Gerente deve estar logado no sistema.
Fluxo Base
1. O participante com papel de Gerente entra na tela de configuração de Notificação (TEL-
024);
2. O Gerente configura o horário e o e-mail em que deseja receber a notificação diária;
3. O Gerente clica em Salvar
4. O sistema exibe uma mensagem que a configuração foi salva com sucesso. (TEL-002).
Pós-condição: Notificação configurada
FA01 - Horário Incorreto {Alternativo}.
1. No passo 2, o Gerente informa um horário inválido;
2. O sistema exibe mensagem de erro informando o Gerente que o horário está incorreto
(maior que 24:59 ou menor que 0) (TEL-002)
. USC-007 Seleciona relatórios / consultas
Restrições
Mandatory Pré-condição . O participante precisa estar logado no sistema.
Fluxo base: escolha de um relatório / consulta
123
1. O sistema apresenta uma tela para a seleção de relatórios / consultas. (TEL-016)
2. O participante seleciona o relatório / consulta.
3. Conforme relatório / consulta selecionada.
USC-008 Gera Grafico de GANTT
Restrições
Proposed Pré-condição . O gerente precisa estar logado no sistema. O sistema de gerência de
projetos precisa estar com projetos já cadastrados. As pós-condições estão cadastradas com
os fluxos (ver aba Scenario).
Fluxo base: Geração de um relatório / consulta na forma de um gráfico de Gantt {Base}.
1. O sistema apresenta uma tela para a seleção do projeto. (TEL-012)
2. O gerente seleciona o projeto e opta por Gráfico de Gantt.
3. O sistema apresenta a geração de um relatório/consulta na forma de um gráfico de Gantt
que permite visualizar todas as tarefas agendadas no escopo do projeto. (TEL-013)
Pós-condição: Um relatório / consulta na forma de um gráfico de Gantt foi criado no sistema.
Fluxo alternativo 1: Geração de um relatório apresentando a dependência entre as tarefas
{Alternativo}.
Condição: no passo 2 do fluxo base, se o gerente optar por consultar a Dependência entre
tarefas.
1. O sistema apresenta a geração de um relatório/consulta que permite visualizar a
dependência entre as tarefas no escopo do projeto. (TEL-011)
Pós-condição: Um relatório / consulta mostrando a dependência entre tarefas foi criado no
sistema.
USC-009 Exibe Situação Projeto
124
Restrições
Approved Pré-condição . Um projeto deve estar cadastrado. Uma tarefa deve estar cadastrada
para o projeto.
Fluxo Base
1. O siatema apresenta a tela de cadastro de Projeto(TEL-004).
2. O cliente seleciona um Projeto e clica na opção Visualizar .
3. O sistema exibe a tela visualiza Projeto. (TEL-005).
4. O cliente seleciona a opção "Situação do Projeto".
5. O sistema exibe um quadro resumido da situação do projeto.(TEL-006).
6. O cliente seleciona aopção Sair.
7. Termina o caso de uso.
Pós-Condição: O cliente visualizou a situação do projeto.
FA-01 Cancela {Alternativo}.
Se, nos passos 2,3.4.5 o cliente optar por cancelar a operação:
1. Termina o caso de uso.
Pós-Condição: O caso de uso foi encerrado sem que o cliente tenha visualizado a situação do
projeto.
FE-01 Projeto não cadastrado. {Exceção}.
Se, no passo 2 o cliente digitar um projeto inexistente:
1. O sistema apresenta a mensagem: "Projeto não cadastrado!".(TEL-002)
2. Retorna ao passo 1 do fluxo base.
USC-010 Loga no Sistema
Restrições
125
Approved Pré-condição . N/A.
Fluxo Base
1. O sistema apresenta uma página solicitando a conta e a senha do operador. (TEL-001)
2. O operador preenche os dados e confirma.
3. O sistema valida a conta e senha fornecidas .
4. O sistema busca as permissões do operador
5. O sistema gera um registro de log sobre a autenticação do operador.
Pós-Condição: operador autenticado no
sistema com suas permissões recuperadas.
FA-01 Cancela {Alternativo}.
Se, no passo 2 do fluxo base, o operador optar por cancelar a operação, então:
1. Termina caso de uso.
Pós-Condição: o caso de uso foi encerrado sem que o operador seja autenticado.
FE-01 Senha/Login em branco {Exceção}.
Se, no passo 2 do fluxo base, o operador deixar a conta e/ou o login em branco, então:
1. O sistema apresenta a mensagem "A conta e o login precisam ser preenchidos!". (TEL-002)
2. Retorna ao passo 1 do fluxo base.
FE-02 Senha/Login inválidos {Exceção}.
Se, no passo 3 do fluxo base, o sistema não validar a conta/senha fornecidas, então:
1. O sistema apresenta a mensagem "Conta ou login inválidos!". (TEL-002)
2. Retorna ao passo 1 do fluxo base.
126
USC-011 Consulta Historico
Restrições
Approved Pré-condição . Um participante com responsabilidade de gerente deve estar
cadastrado. O Gerente deve estar logado no sistema.
Fluxo Base 1. O participante com papel de Gerente entra na tela de Consulta Histórico (TEL-
023);
2. O Gerente informa intervalo de datas para a busca do histórico;
3. O Gerente clica em Consultar;
4. O sistema exibe as ações, datas e usuários que as realizaram no sistema, ordenadas pela
data.
Pós-condição: Consulta Exibida.
127
ANEXO 4
TESTES DO MÓDULO DE ESTIMATIVA
Nome do Projeto: TCC
Nome do Programa: PLACES – Módulo de Estimativa de software
Preparado Por: Richard Henrique de Souza Data: 10/09
Testado Por: Richard Henrique de Souza Data: 15/10
Retestado Por: Marcello Thiry Data: 01/11
Teste ID: 01
Requisito do Projeto: REF.01 O sistema deve permitir que um usuário possa efetuar o login no sistema.
Condição de Teste: O servidor de aplicação deve estar inicializado.
Procedimentos: Inicializar o browser. Digitar o endereço no qual se encontra a aplicação PLACES. Digitar um login e senha válidos. Selecionar a opção ok.
Resultados/Objetivo Esperados:
O sistema deve exibir a tela de projetos do PLACES com o usuário autenticado no sistema.
Resultados Reais: O usuário conseguiu autenticar no sistema.
Observações: Teste feito com sucesso.
128
Teste ID: 02
Requisito do Projeto: RNF. 01.01 O sistema deve possuir um mecanismo de controle de segurança para evitar que pessoas não autorizadas tenham acesso ao sistema.
Condição de Teste: O servidor de aplicação deve estar inicializado.
Procedimentos: Inicializar o browser. Digitar o endereço o qual se encontra a aplicação PLACES. Digitar um login inválido Digitar uma senha qualquer. Selecionar a opção ok.
Resultados/Objetivo Esperados:
O sistema não permite a entrada no sistema e exibe uma mensagem: Usuário não autorizado.
Resultados Reais: O sistema não deixou entrar no sistema.
Observações: Teste feito com sucesso.
129
Teste ID: 03
Requisito do Projeto: RNF. 01.01 O sistema deve possuir um mecanismo de controle de segurança para evitar que pessoas não autorizadas tenham acesso ao sistema.
Condição de Teste: O servidor de aplicação deve estar inicializado.
Procedimentos: Inicializar o browser. Digitar o endereço o qual se encontra a aplicação PLACES. Digitar um login válido. Digitar uma senha inválida. Selecionar a opção ok.
Resultados/Objetivo Esperados:
O sistema não permite a entrada no sistema e exibe uma mensagem: Usuário não autorizado.
Resultados Reais: O sistema não deixou entrar no sistema.
Observações: Teste feito com sucesso.
130
Teste ID: 04
Requisito do Projeto: RNF. 01.01 O sistema deve possuir um mecanismo de controle de segurança para evitar que pessoas não autorizadas tenham acesso ao sistema.
Condição de Teste: O servidor de aplicação deve estar inicializado.
Procedimentos: Inicializar o browser. Digitar o endereço o qual se encontra a aplicação PLACES. + “\addCasoDeUso.jsp”
Resultados/Objetivo Esperados:
O sistema não permite a entrada no sistema e exibe uma mensagem: Usuário não autorizado.
Resultados Reais: O sistema não deixou entrar no sistema.
Observações: Teste feito com sucesso.
Teste ID: 05
Requisito do Projeto: RNF. 01.02 As senhas cadastradas que estiverem no banco de dados não deverão ser visíveis diretamente, devendo estar em um modo criptografado.
Condição de Teste: O servidor de banco de dados deve estar inicializado.
Procedimentos: Inicializar o MySQL browser. Verificar os dados da tabela Participante. Verificar o campo senha.
Resultados/Objetivo Esperados:
Os dados no campo senha devem estar criptografados.
Resultados Reais: As senhas estão criptografadas.
Observações: Teste feito com sucesso.
131
Teste ID: 06
Requisito do Projeto: REF. 02 O sistema deverá permitir o cadastro dos atores com a possibilidade de classificá-los em simples, médio e complexo.
Condição de Teste: O usuário deve estar autenticado no sistema.
Procedimentos: Ir na página de cadastro de ator. Cadastrar um ator, e classificá-lo como sinmples. Cadastrar um ator, e classificá-lo como médio. Cadastrar um ator, e classificá-lo como complexo. Verificar se os atores foram cadastrados. Verificar se classificação cadastrada está correta.
Resultados/Objetivo Esperados:
Ter 3 atores cadastrados no sistema, com as classificações simples, médio e complexa cadastrada. (RNE. 03, ver anexo 5)
Resultados Reais: O sistema gravou os 3 atores com as classificações corretas.
Observações: Teste feito com sucesso.
132
Teste ID: 07
Requisito do Projeto: REF. 02 O sistema deverá permitir o cadastro de caso de uso com a possibilidade de classificá-los em simples, médio e complexo.
Condição de Teste: O usuário deve estar autenticado no sistema.
Procedimentos: Ir na página de cadastro de caso de uso. Cadastrar um caso de uso, e classificá-lo como sinmples. Cadastrar um caso de uso, e classificá-lo como médio. Cadastrar um caso de uso, e classificá-lo como complexo. Verificar se os casos de uso foram cadastrados. Verificar se classificação cadastrada está correta.
Resultados/Objetivo Esperados:
Ter 3 casos de uso cadastrados no sistema, com as classificações simples, médio e complexa cadastrada.
Resultados Reais: O sistema gravou os 3 casos de uso com as classificações corretas. (RNE. 06, ver anexo 5)
Observações: Teste feito com sucesso.
133
Teste ID: 08
Requisito do Projeto: REF. 04 O sistema deverá permitir o cadastro de grau de influência dos fatores de complexidade técnica.
Condição de Teste: O usuário deve estar autenticado no sistema.
Procedimentos: Ir na página de fatores de ajuste. Para cada fator de ajuste de complexidade técnica, entrar na página de edição. Alterar o número do campo “VALOR”. Salvar a alteração. Verificar se as alterações foram feitas
Resultados/Objetivo Esperados:
As alterações foram gravadas pelo sistema.
Resultados Reais: Todas as alterações foram realizadas com sucesso.
Observações: Teste feito com sucesso.
Teste ID: 09
Requisito do Projeto: REF. 05 O sistema deverá permitir o cadastro de grau de influência dos fatores de complexidade de ambiente.
Condição de Teste: O usuário deve estar autenticado no sistema.
Procedimentos: Ir na página de fatores de ajuste. Para cada fator de ajuste de complexidade de ambiente, entrar na página de edição. Alterar o número do campo “VALOR”. Salvar a alteração. Verificar se as alterações foram feitas
Resultados/Objetivo Esperados:
As alterações foram gravadas pelo sistema.
Resultados Reais: Todas as alterações foram realizadas com sucesso.
Observações: Teste feito com sucesso.
134
Teste ID: 10
Requisito do Projeto: REF. 06 O sistema deve calcular os fatores ponderados.
Condição de Teste: O usuário deve estar autenticado no sistema.
Procedimentos: Ir na página de caso de uso. Selecionar a opção calcular Pontos de caso de Uso Verificar se o cálculo dos fatores foi feito e se está correto.
Resultados/Objetivo Esperados:
Cálculo feito corretamente (RNE.09, RNE.10).
Resultados Reais: O cálculo foi feito corretamente.
Observações: Teste feito com sucesso.
Teste ID: 11
Requisito do Projeto: REF. 07 O sistema deve permitir o cadastro de esforço de pessoa/hora por ponto de caso de uso.
Condição de Teste: O usuário deve estar autenticado no sistema.
Procedimentos: Ir na página de caso de uso. Selecionar a opção pontos de caso de uso. Alterar o esforço por pessoa\hora Verificar se o esforço foi alterado.
Resultados/Objetivo Esperados:
Alteração gradavada corretamente.
Resultados Reais: A alteração foi gravada corretamente.
Observações: Teste feito com sucesso.
135
Teste ID: 12
Requisito do Projeto: REF. 08 O sistema deve calcular o número de pontos de caso de uso.
Condição de Teste: O usuário deve estar autenticado no sistema.
Procedimentos: Ir na página de caso de uso. Selecionar a opção calcular Pontos de caso de Uso Verificar se o cálculo do número de ponstos de casos de uso foi feito e se está correto.
Resultados/Objetivo Esperados:
Cálculo feito corretamente (ver RNE.011, anexo 5).
Resultados Reais: O cálculo foi feito corretamente.
Observações: Teste feito com sucesso.
Teste ID: 13
Requisito do Projeto: REF. 09 O sistema deve calcular o esforço.
Condição de Teste: O usuário deve estar autenticado no sistema.
Procedimentos: Ir na página de caso de uso. Selecionar a opção calcular Pontos de caso de Uso Verificar se o cálculo do esforço foi feito e se está correto.
Resultados/Objetivo Esperados:
Cálculo feito corretamente (ver RNE.012 anexo 5).
Resultados Reais: O cálculo foi feito corretamente.
Observações: Teste feito com sucesso.
136
Teste ID: 14
Requisito do Projeto: RNF. 02.01 O navegador deve ser compatível com o Internet Explore 6.0.
Condição de Teste: O Servidor deve estar inicializado.
Procedimentos: Inicializar o browser. Digitar o endereço o qual se encontra a aplicação PLACES. Digitar um login e senha do administrador do sistema. Selecionar a opção ok. Verificar todas as páginas do módulo de estimativa. (Lista de atores, cadastro de atores, lista de casos de uso, cadastro de caso de uso, lista de fatores, cadastro de fatores, edição de esforço e cálculo de pontos de caso de uso).
Resultados/Objetivo Esperados:
A visualização de todas páginas do módulo de estimativa
Resultados Reais: Todas as páginas do módulo de estimativa foram exibidas corretamente
Observações: Teste feito com sucesso.
137
Teste ID: 15
Requisito do Projeto: RNF. 03.01 O sistema deverá ser suficientemente robusto para permitir acessos 24h. Por dia, todos os dias da semana.
Condição de Teste: O Servidor deve estar inicializado.
Procedimentos: Inicializar o browser. Digitar o endereço o qual se encontra a aplicação PLACES. Digitar um login e senha do administrador do sistema. Selecionar a opção ok. Verificar todas as páginas do módulo de estimativa. (Lista de atores, cadastro de atores, lista de casos de uso, cadastro de caso de uso, lista de fatores, cadastro de fatores, edição de esforço e cálculo de pontos de caso de uso). Repetir o teste 6 vezes ao dia nos horários: 8:00, 10:00, 12:00, 14:00, 16:00 e 18:00. durante 1 mês.
Resultados/Objetivo Esperados:
A visualização de todas páginas do módulo de estimativa
Resultados Reais: Todas as páginas do módulo de estimativa foram exibidas corretamente
Observações: Teste feito com sucesso.
138
ANEXO 5
REGRAS DE NEGÓCIO
RNE.001 A senha deve ter tamanho mínimo de 6 caracteres e tamanho máximo de 14.
RNE.002 As senhas serão sempre convertidas para letras maiúsculas.
RNE. 003 Os atores são classificados como simples, médio ou complexo.
SIMPLES ==> Um ator é dito como simples quando representa um sistema externo com uma
API definida.
MÉDIO ==> Um ator é dito como médio quando representa um sistema externo onde a
comunicação é feita por meio de um protocolo de comunicação como TCP/IP ou representa
um sistema de hardware, onde a interface de comunicação é também de alguma forma
padronizada.
COMPLEXO ==> Atores complexos são aqueles atores que se enquadram na categoria
“humano”.
RNE. 004 O peso dos fatores ponderados dos atores são 1 para o simples, 2 para o médio e 3
para o complexo.
RNE.005 O total ponderado não ajustados dos atores é calculado com a contagem de quantos
atores existem em cada tipo (por grau de complexidade), multiplicando cada total pelo seu
fator ponderado, e adicionando todos os produtos.
UAW = ( número de atores simples * 1) + ( número de atores médios * 2) +
( número de atores complexo* 3).
RNE.006 Os casos de uso são classificados como simples, médio ou complexo.
Simples ==> É considerado simples um caso de uso de 1 a 3 transações ou que envolve de 1 a
5 classes.
Médio ==> É considerado médio um caso de uso de 4 a 7 transações ou que envolve de 6 a 10
classes.
139
Complexo ==> É considerado complexo um caso de uso de 8 a * transações ou que envolve
de 11 a * classes.
RNE.007 O total ponderado não ajustados dos casos de uso é calculado com a contagem de
quantos caso de uso existem em cada tipo (por grau de complexidade), multiplicando cada
total pelo seu fator ponderado, e adicionando todos os produtos.
UUCW = ( número de casos de uso simples * 1) + ( número de casos de uso médios * 2) +(
número de casos de uso complexo * 3).
RNE.008 O cálculo do número de pontos de caso de uso não ajustado é dado pela soma do
total ponderado não ajustado de atores pela soma do total ponderado não ajustado de casos de
ajuste.
UUCP = UAW + UUCW
UUCP => Número de pontos de caso de uso não ajustado.
UAW => Total ponderado não ajustado de atores
UUCW => Total ponderado não ajustado de casos de uso
RNE.009 O TCF é calculado pela multiplicação do valor de cada fator pelo seu peso e então
todos estes números são somados, criando o TFator. Então multiplica-se o TFator por 0.01 e
soma-se o resultado com 0.6.
TFator = (Fator 1 * peso do fator 1) + (Fator 2 * peso do fator 2) ... (Fator n * peso do fator n)
TCF = 0.6+(0.01 * TFator)
RNE.010 O EF é calculado pela multiplicação do valor de cada fator pelo seu peso e então
todos estes números são somados, criando um EFator, O Efator é multiplicado por -0.03 e
somado a 1.4.
EFator = (Fator 1 * peso do fator 1) + (Fator 2 * peso do fator 2) ... (Fator n * peso do fator n)
EF = 1.4+( -0.03 * EFator).
140
RNE.011 O número de pontos de caso de uso ajustado é dado pela multiplicação do número
de pontos de caso de uso não ajustado por Fatores de complexidade tecnica e por Fatores de
Ambiente.
UCP = UUCP * TCF * EF
UCP => Número ajustado de pontos de caso de uso.
UUCP => Número não ajustado de pontos de caso de uso (RNE-008).
TCF => Número de Fator de Complexidade Técnica (RNE-009)
EF => Número de Fator de Ambiente (RNE-010)
RNE.012 O esforço é calculado multiplicado os pontos de caso de uso por um dado esforço(
que pode variar entre 20 pessoa/horas ate 36 pessoa/hora) dependendo da empresa.
Exemplo:
Esforço = UCP * 20 (pessoa/hora).
141
ANEXO 6 REQUISITOS FUNCIONAIS
REF.01 O sistema deve permitir que um operador possa efetuar o login no sistema.
REF.02 O sistema deverá permitir o cadastro dos atores com a possibilidade de classificá-los
em simples, médio e complexo.
REF.03 O sistema deverá permitir o cadastro dos casos de uso com a possibilidade de
classificá-los em simples, médio e complexo.
REF.04 O sistema deverá permitir o cadastro de grau de influência dos fatores de técnico.
REF.05 O sistema deverá permitir o cadastro de grau de influência dos fatores de ambiente.
REF.06 O sistema deve calcular os fatores ponderados.
REF.07 O sistema deve permitir o cadastro de esforço de pessoa/hora por ponto de caso de
uso.
O valor default inicialmente adotado será 36 pessoas/hora. Entretanto, cada organização
poderá ajustar este valor de acordo com suas necessidades e de acordo com as características
do projeto a ser desenvolvido.
REF.08 O sistema deve calcular o número de pontos de caso de uso.
REF. 09 Com base nos casos de uso já cadastrados e nos fatores ponderados, o sistema
deverá ser capaz de calcular o esforço total do projeto.
142
REQUISITOS NÃO FUNCIONAIS
1.Segurança
RNF.01.01 O sistema deve possuir um mecanismo de controle de segurança para evitar que
pessoas não autorizadas tenham acesso ao sistema
RNF.01.02 As senhas cadastradas que estiverem no banco de dados não deverão ser visíveis
diretamente, devendo estar em um modo criptografado.
2. Usabilidade
RNF.02.01 Os navegadores deverão ser compatíveis com o Internet Explorer 6.0 ou versões
superiores.
3.Confiabilidade
RNF.03.01 O sistema deverá ser suficientemente robusto para permitir acessos 24h por dia,
todos os dias da semana.
4.Desempenho
RNF.04.01 O sistema deve estar preparado para atender até 5 usuários simultâneos.
5. Software e Hardware
RNF.05.01 O sistema deve estar preparado para trabalhar com o banco de dados MySQL 4.1.
RNF.05.02 O sistema será executado em rede de computadores com protocolo TCP/IP.
RNF.05.03 O sistema será executado em um computador que tenha acesso a Internet.
RNF.05.04 O sistema será executado em um computador que tenha no mínimo 512 MB de
memória RAM e 1GB de espaço em disco.
143
ANEXO 7 DIAGRAMAS DE SEQUÊNCIA
sd COL 01 Cadastra Ator
:Analista de Sistema :TelaListaAtores :ControladorAtor :TelaAddAtor :AtorBO :AtorTO
List:= FindByAll()
Show(lista_atores)
Incluir()
Incluir()
Show()
Salvar()
Salvar(Complexidade,Descricao,nome)
new
Save(ator)
Editar()
Editar(id)FindByKey(id)
Show(ator)
Salvar()
Salvar(Complexidade,Descricao,nome)
Update(ator)
Exclui()Excluir(id)
Delete(id)
Figura 32 SEQ-01 Cadastro de Atores
144
sd SEQ.01.00Seqüência
:Analista de Sistema :TelaListaCasosDeUso
:ControladorMontaCasoDeUso
:ArtefatoBO :TelaAddCasoDeUso
:TelaEditaCasoDeUso
Lista:= FindByProjetoAndTipo(id_tipo,id_projeto)
Show()
Incluir()Incluir()
Show()
Salvar()
Insere()
Save(caso_de_uso)
Show()
Editar(id)Editar()
ArtefatoTO:= FindByKey(id_artefato)
Show(casoDeUso)
Salvar()
Salvar()
Update(caso_de_uso)
Show()
Excluir(id)Excluir(id)
Delete(caso_de_uso)
Figura 33 SEQ-02 Cadastro de caso de uso
145
Figura 34 SEQ-03 Cálculo de Pontos de caso de uso
146
sd Sequencia
:Administrador :ControladorMontaFatoresDeAjuste
:TelaFatoresDeAjustes
:telaCadastroFatorAjuste
:FatorAjusteBO
lista:= FindByFatores(id_projeto)
Show()
Incluir()ExibeTelaCadastro()
Show()
Salvar()
IncluiFatorAjuste()
Salvar(fa)
Show()
Edita()Editar(id_fa)
FatorAjusteTO:= FindByFator(id)
Show()
Salvar()
SalvaEditacao(fator)
Update(Fa)
Show()
Excluir()Excluir(id_fa)
Delete(id_fa)
Figura 35 SEQ-04 Cadastro de Fatores de Ajuste
147
ANEXO 8 INSTALAÇÃO DAS FERRAMENTAS PARA O DESENVOLVIMENTO
E MANUTENÇÃO DO PLACES
1. Ferramentas Utilizadas.
• JDK 1.5.0 ou superior. Kit de desenvolvimento JAVA.
• TOMCAT 5.5 ou superior. Servidor de aplicação com suporte a JAVA e JSP.
• MySQL 4.0. Banco de dados a ser utilizado pelo PLACES.
• MyODBC-3.51.11-2-win. Driver de conexão do banco para o sistema operacional
Windows.
• NetBeans 4.0 ou superior. Ambiente de desenvolvimento JAVA.
• Eclipse 3.0 ou superior. Ambiente de desenvolvimento em JAVA. (Opcional).
No item 2 em diante segue dicas de instalação, e os links podem não estar mais ativos ou os
arquivos não estarem mais disponíveis.
2. Instalação do JDK 1.5.0.
O primeiro passo é baixar o pacote de instalação do JDK 5.0 na página da SUN.
http://java.sun.com
Procure pelo jdk 1.5 (arquivo “jdk-1_5_0_01-windows-i586-p”) para fazer o download.
Após ter baixado o arquivo de instalação do jdk, dê um duplo click no arquivo de
instalação (jdk-1_5_0_01-windows-i586-p). (Aqui poderá aparecer uma mensagem de
erro se você já tiver instalado o JDK, e a instalação será abortada.)
E uma tela de instalação irá aparecer.
148
Figura 36 Tela de instalação do JAVA
Selecione a opção “I accept ...” e logo em seguida clique no botão Next > conforme a
figura 36.
Figura 37 Tela de personalização da instalação do JAVA.
Clique no botão Next > , conforme a figura 37.
Figura 38 Tela de configuração das ferramentas do JAVA.
149
Clique no botão Next > , conforme a figura 38.
Figura 39 Tela de configuração do browser.
Clique no botão Next > , conforme a figura 39.
Figura 40 Tela de finalização da instalação.
Clique no botão Finish, conforme a figura 40.
Se você seguiu todas as instruções até aqui, o kit de desenvolvimento Java já está
instalado, faltando apenas configurar as variáveis de ambiente do Windows.
2.1 Variáveis de Ambiente
Ao concluir a instalação do JDK, já podemos criar a variável de ambiente JAVA_HOME,
necessária para instalação do netbeans e o eclipse. No Windows XP para criar e alterar as
variáveis de ambiente pode ir no ícone “Meu Computador” e com um clique do botão direito
do mouse, aparecerá um menu suspenso, clique em propriedades, conforme a figura 41.
150
Figura 41 Configuração das variáveis de Ambiente
Aparecerá uma tela, clique na aba Avançado, conforme figura 42.
Figura 42 Configuração das variáveis de Ambiente
Clique no botão Variáveis de Ambiente, e aparecerá uma tela conforme figura 43.
Figura 43 Configuração das variáveis de Ambiente
151
Abaixo de Variáveis do sistema tem os botões Nova, Editar e Excluir, conforme figura 44.
Será usado o botão Nova para criar a variável JAVA_HOME e Editar para as variáveis PATH
e PATHTEXT.
Figura 44 Configuração das variáveis de Ambiente
Vamos agora editar a variável PATH, adicionando o caminho do kit de desenvolvimento
JAVA, para isso localizar a pasta bin (é a que contém os aplicativos java, javac e etc) aonde
foi instalado o JDK. Por exemplo:
“C:\Arquivos de programas\Java\jdk1.5.0_01\bin”
Se você seguiu os passos descritos no primeiro parágrafo do item 2.1, agora selecione a
variável PATH e em seguida clique no botão Editar, conforme figura 45.
Figura 45 Configuração das variável PATH.
No campo valor da variável adicione ao final um ponto e vírgula “;” e copie o caminho
da pasta bin onde está instalado o jdk, conforme figura 46.
Figura 46 Configuração das variável PATH
Adicionar ao PATHTEXT o “.JAR”, para que o sistema possa reconhecer os arquivos.
Para isso selecione a variável PATHTEXT e clique no botão Editar e no campo valor da
variável adicione ao final um ponto e vírgula “;” e digite “JAR” sem as aspas.
Criar a variável de ambiente “JAVA_HOME” e adicionar o caminho onde está instalado o
JDK. Por exemplo:
“C:\Arquivos de programas\Java\jdk1.5.0_01”
152
Clique no botão Nova, conforme figura 47.
Figura 47 Criar a variável JAVA_HOME
No campo Nome da Variável coloque JAVA_HOME, e no campo valor da variável
coloque o caminho onde se encontra instalado o jdk, conforme figura 48.
Figura 48 Criar a variável JAVA_HOME
Com isso terminamos a instalação do JAVA.
3. Instalação TOMCAT
IMPORTANTE: Para a instalação do TOMCAT 5.5 é necessário que o JDK 1.5.0 ou
superior esteja instalado e que a variável JAVA_HOME esteja corretamente configurada.
O primeiro passo é baixar o arquivo de instalação do Tomcat. Disponível em:
http://jakarta.apache.org/
Dê um duplo click no arquivo de instalação do Tomcat. Clique no botão Next >, conforme
a figura 49.
Figura 49 Tela de inicio da instalação do Tomcat
153
Clique no botão “I Agree” para continuar a instalação, conforme figura 50.
Figura 50 Termo de licença do Tomcat
Escolha a opção full e clique em Next>, conforme figura 51.
Figura 51 Configuração do Tomcat.
Escolha o diretório a onde será instalado o Tomcat e clique no botão Next>, conforme
figura 52.
Figura 52 Configuração do local de instalação do Tomcat.
154
Configure a porta onde vai rodar o Tomcat, geralmente na porta 8080, defina o login e
senha, conforme a figura 53.
Figura 53 Tela de configuração do Tomcat
Verifique o diretório é o mesmo onde está instalado o JAVA e clique no botão Install,
conforme figura 54.
Figura 54 Tela de configuração do Java no Tomcat.
Clique no botão Finish para terminar a instalação, conforme figura 55.
Figura 55 Tela de termino da instalação do Tomcat.
Verifique se o Tomcat esta rodando, abrindo o browser digitando http://127.0.0.1:8080/,
irá aparecer uma tela conforme a figura 56.
155
Figura 56 Pagina principal do Tomcat.
Pronto, agora o Tomcat já esta pronto para uso.
4. Instalação do MySQL
O primeiro passo é baixar o arquivo de instalação do MySQL. Disponível em:
http://dev.mysql.com/downloads/
Dê um duplo click no arquivo de instalação do MySql (SETUP), clique no botão Next,
conforme figura 57.
Figura 57 Inicio da instalação do MySQL.
Clique em Next, conforme a figura 58.
156
Figura 58 Tela de informação do MySQL.
Para escolher o diretório de instalação clique no botão Browser, e depois clique em Next>,
conforme figura 59.
Figura 59 Escolha do diretória do MySQL.
Escolha a opção Typical e clique no botão Nest>, conforme figura 60.
Figura 60 Configuração do MySQL.
Clique no botão Finish, conforme figura 61.
Figura 61 Termino da instalação do MySQL.
157
Agora para iniciar o MySQL, deve-se ir na pasta BIN que se encontra no diretório onde foi
instalado o MySQL (C:\mysql\bin), dê um clique duplo no arquivo “winmysqladmin.exe”
para inicializar o MySQL, conforme figura 62.
Figura 62 Executar o MySQL.
Agora o MySQL está rodando.
5. Instalação do driver ODBC do MySql.
O primeiro passo é baixar o arquivo de instalação do driver ODBC do MySQL.
Disponível em:
http://dev.mysql.com/downloads/
Dê um duplo click no arquivo de instalação do MySql (MyODBC-3.51.11-2-win). Clique
no botão Next, conforme figura 63.
Figura 63 Executar o MySQL.
Selecione a opção I Agree e clique no botão Next, conforme figura 64.
Figura 64 Executar o MySQL.
Clique no botão Next>, conforme 65.
158
Figura 65 Tela de boas vindas do ODBC MySQL.
Clique no botão Next>, conforme 66.
Figura 66 Tela de confirmação.
Clique no botão Finish, conforme a figura 67.
Figura 67 Tela de confirmação.
Agora falta configurar o ODBC, ir no painel de controle, ir em ferramentas
administrativas,
Dê um clique duplo em Fonte de Dados (ODBC), conforme figura 68.
159
Figura 68 Tela de confirmação do ODBC.
Na aba Fonte de Dados clique no botão Adicionar. Selecione a Fonte de dado MySQL e
clique no botão concluir, conforme figura 69.
Figura 69 Adicionando a fonte de dados MySQL.
Preencha os dados conforme a figura 70 e clique em Ok, ou pode testar a configuração
clicando no botão Test.
Figura 70 Adicionando a fonte de dados MySQL
Na aba Fonte de Dados do sistema clique no botão Adicionar e siga os passos anteriores
descritos a partir da aba Fonte de Dados.
Feito isso o acesso ao MySQL pode ser feito via ODBC.
160
6. Instalação do NetBeans
O primeiro passo é baixar o arquivo de instalação do NetBeans. Disponível em:
http://www.netbeans.org
Dê um duplo click no arquivo de instalação do NetBeans.
Clique no botão Next, conforme figura 71.
Figura 71 Tela inicial do Netbeans.
Selecione a opção “I Accept ...”, e clique no botão Next>, conforme figura 35.
Figura 72 Tela de lincença do Netbeans.
Digite o caminho a onde será instalado o NetBeans e clique no botão Next>, conforme 36.
Figura 73 Local de instalação do Netbeans.
161
Se o diretório da instalação do JAVA estiver colocado errado coloque o caminho certo e
clique no botão Next>, conforme figura 74.
Figura 74 Configuração do JAVA.
Clique no botão Next>, conforme figura 75.
Figura 75 Configuração do JAVA.
Clique no botão Finish, conforme a figura 76.
Figura 76 Tela de finalização da instalação do NetBeans.
Agora você esta pronto para programar em JAVA.
7. Instalação do Eclipse
IMPORTANTE: Para a instalação do Eclipse é necessário que o JDK esteja instalado e
que a variável JAVA_HOME, PATH e PATHTEXT estejam corretamente configurados
conforme item 2 deste manual.
162
O primeiro passo é baixar o arquivo de instalação do Eclipse. Disponível em:
http://www.eclipse.org/downloads/
Descompacte o arquivo baixado em uma pasta. Exemplo:
C:\Arquivos de programas\
Na pasta Eclipse terá um arquivo eclipse. Dê um duplo click neste arquivo e o eclipse será
iniciado. Crie um atalho deste arquivo para inicializar o eclipse sem ter que navegar entre os
diretórios.
8. Instalação do middlegenid
O middlegenide (middlegenide_1.3.2.zip) é usado para fazer o mapeamento do banco de
dados para o Hibernate. Procure na internet os seguintes arquivos: middlegenide_1.3.2.zip,
GEF-SDK-3.1.zip, emf-sdo-xsd-SDK-2.1.0.zip e mysql-connector-java-3.0.16-ga-bin.jar.
Descompacte os 3 arquivos zip em alguma pasta, copie os arquivos descompactados para
dentro do diretório do eclipse sobrescrevendo os arquivos.
Agora inicialize o eclipse, crie um novo projeto e no projeto criado crie um novo Source
Folder. Dentro da Source Folder criado clique com o botão direito e selecione new->other,
conforme figura 77.
Figura 77 Criando mapeamento Hipernate.
Selecione middlegen Build File e clique em Next>, conforme figura 78.
163
Figura 78 Criando mapeamento Hipernate.
Clique no botão Next>, conforme figura 79.
Figura 79 Criando mapeamento Hipernate.
Clique no botão Browser conforme figura 80.
164
Figura 80 Conectando com o banco.
Selecione o arquivo “mysql-connector-java-3.0.16-ga-bin.jar” e Clique no botão Abrir,
conforme figura 81.
Figura 81 Arquivo JAR de conexão com o banco.
Preencher as informações necessárias para conexão com o banco de dados, como os
campos: Database URI, User, e Password e clique em “load table”. Conforme figura 82.
165
Figura 82 Carregando as tabelas do banco de dados.
Selecione as tabelas que serão mapeadas para o Hibernate e clique no botão Finish.
Verifique os relacionamentos e tipos de dados das tabelas e clique no menu Generate e feche
a janela.
166
ANEXO 9 MODELO DO BANCO DE DADOS DO MÓDULO DE ESTIMATIVA DO
PLACES
Figura 83 Modelagem do Banco de dados
167
ANEXO 10 CASOS DE USO PARA VALIDAÇÃO DO MÓDULO DE ESTIMATIVA
Caso de Uso 001 - Nome: Cadastro Emenda
Ator ativo: Coordenador de curso
Atores passivos: N\A.
Meta:Cadastrar (Incluir, editar e excluir ) uma emenda.
Pré-condição: Ter uma disciplina cadastrada, estar logado como Coordenador de curso.
Requisitos Funcionais:
FLUXO BASE
1. O sistema exibe a tela de principal do sistema.
2. O coordenador de curso opta pela busca por turmas.
3. O sistema exibe as disciplinas conforme o tipo de busca.
4. O coordenador de curso seleciona uma disciplina.
5. O sistema exibe a tela da disciplina com a lista de ementas da disciplina selecionada.
6. O coordenador de curso seleciona a opção “Incluir”.
7. O sistema exibe a tela de cadastro da ementa.
8. O coordenador de curso preenche os dados e opta por salvar.
9. O coordenador de curso seleciona a opção “termino de cadastro de ementa” e opta por salvar.
Pos-condição: A ementa foi cadastrada.
FLUXO ALTERNATIVO – FA-01 editar
Se, no passo 6 do fluxo base, o coordenador de curso seleciona uma ementa e opta por editar.
1. O sistema exibe a tela de alteração de ementa.
168
2. O coordenador de curso faz as alterações e opta por salvar.
Pos-condições: Alterações salvas.
FA-02 Excluir Ementa
Se, no passo 6 do fluxo base, o coordenador de curso seleciona uma ementa e opta por excluir.
1. O sistema exibe seguinte mensagem “Você deseja excluir esta ementa ?”.
2. O coordenador de curso opta por sim.
3. O sistema exclui a ementa do sistema.
Pós-condições: a ementa foi excluída.
FA-04 Cancela
Se, nos passos 2..7 do fluxo base, o coordenador de curso seleciona a opção cancelar.
1. termina o caso de uso.
Pós-Condição: o caso de uso é terminado sem nenhuma altera
FLUXO DE EXCEÇÃO – FE-01 Dados em branco
Se, no passo 8, o coordenador de curso deixar os campos em branco.
1. O sistema apresenta a mensagem: "Os dados do projeto devem ser preenchidos".
2. Retorna ao passo 7 do Fluxo Base.
*************************************************************************************************************
169
Caso de Uso 002 - Nome: Cadastra Plano de ensino
Ator ativo: Professor
Atores passivos: N\A.
Meta:Validar a conversão.
Pré-condição: O Professor de sistema deve estar logado no sistema.
Requisitos Funcionais: REF. 01, REF.06
FLUXO BASE
1. O sistema exibe a tela principal do sistema.
2. O professor opta pela busca por turmas.
3. O sistema exibe as disciplinas conforme o tipo de busca.
4. O professor seleciona uma disciplina.
5. O sistema exibe a tela da disciplina.
6. O professor seleciona a opção “Cadastrar Plano de Ensino”.
7. O sistema exibe a tela do plano de ensino.
8. O professor preenche os campos obrigatórios.
9. O professor seleciona a opção “Liberar plano de ensino” e opta por salvar.
10. O sistema salva a o plano e liberar para Validação.
Pós-condição: o plano de ensino foi cadastrado
FLUXO ALTERNATIVO – FA-01 editar
Se, no passo 6 do fluxo base, o professor opta por editar um plano de ensino.
1. O sistema exibe o plano de ensino.
2. O professor altera os dados e clica em Salvar.
3. O sistema salva as alterações.
170
Pós-condições: Alterações salvas.
FA-02 Excluir Plano de ensino
Se, no passo 6 do fluxo base, o professor opta por excluir plano de ensino.
1. O sistema excluí o plano de ensino.
Pós-condições: Plano de ensino excluído.
FA-03 Cancela
Se, no passo 2..8 do fluxo base, o professor a opção cancelar.
1. termina o caso de uso.
Pós-Condição: o caso de uso é terminado sem nenhuma alteração.
FLUXO DE EXCEÇÃO – FE-01 Dados em branco
Se, no passo 8, o professor deixar os campos obrigatórios em branco.
1. O sistema apresenta a mensagem: "Os dados do plano de ensino devem ser preenchidos."
2. Retorna ao passo 7 do Fluxo Base.
*************************************************************************************************************
Caso de Uso 003 - Nome: Copia Emenda
Ator ativo: Coordenador de curso
Atores passivos: N\A.
Meta:copiar uma emenda.
Pré-condição: Ter uma disciplina cadastrada, estar logado como Coordenador de curso.
Requisitos Funcionais:
171
FLUXO BASE
1. O sistema exibe a tela de principal do sistema.
2. O coordenador de curso opta pela busca por turmas.
3. O sistema exibe as disciplinas conforme o tipo de busca.
4. O coordenador de curso seleciona uma disciplina.
5. O sistema exibe a tela da disciplina com a lista de ementas da disciplina selecionada.
6. O coordenador de curso seleciona a opção “Incluir”.
7. O sistema exibe a tela de cadastro da ementa.
8. O coordenador de curso opta por copiar uma ementa.
9. O sistema exibe a ementas cadastradas.
10. O coordenador de curso seleciona uma ementa e opta por copiar.
11. O sistema copia a ementa.
Pós-condição: A ementa foi copiada.
FA-02 Cancela
Se, nos passos 2..7 do fluxo base, o coordenador de curso seleciona a opção cancelar.
1. termina o caso de uso.
*************************************************************************************************************
Caso de Uso 004 - Nome: Copia Plano de ensino
Ator ativo: Professor
Atores passivos: N\A.
Meta:Validar a conversão.
Pré-condição: O Professor de sistema deve estar logado no sistema.
172
Requisitos Funcionais: REF. 01, REF.06
FLUXO BASE
1. O sistema exibe a tela principal do sistema.
2. O professor opta pela busca por turmas.
3. O sistema exibe as disciplinas conforme o tipo de busca.
4. O professor seleciona uma disciplina.
5. O sistema exibe a tela da disciplina.
6. O professor seleciona a opção “Copiar plano de ensino”.
7. O sistema exibe a tela de copia plano de ensino.
8. O professor seleciona o ano e semestre do plano de ensino que deseja copiar.
9. O sistema exibe os planos de ensino do ano e semestre selecionado.
10. O professor seleciona o plano de ensino origem e o plano de ensino destino e opta por atualizar.
11. O sistema copia o plano de ensino.
Pós-condição: o plano de ensino foi copiado.
FA-02 Cancela
Se, no passo 2..8 do fluxo base, o professor a opção cancelar.
1. termina o caso de uso.
Pós-Condição: o caso de uso é terminado sem nenhuma alteração.
FLUXO DE EXCEÇÃO – FE-01 Dados em branco
Se, no passo 10, o professor não selecionar a origem e/ou o destino.
1. O sistema apresenta a mensagem: "É necessário selecionar a origem e o destino".
2. Retorna ao passo 10 do Fluxo Base.
173
*************************************************************************************************************
Caso de Uso 005 - Nome: Valida Plano de ensino
Ator ativo: Coordenador de curso
Atores passivos: N\A.
Meta:Validar o plano de ensino.
Pré-condição: O Coordenador de curso de sistema deve estar logado no sistema.
O plano de ensino deve estar liberado pelo professor.
Requisitos Funcionais:
FLUXO BASE
1. O sistema exibe a tela principal do sistema.
2. O coordenador de curso seleciona a opção “somente planos não validados ” e opta pela busca por
turmas.
3. O sistema exibe as disciplinas conforme o tipo de busca.
4. O coordenador de curso seleciona uma disciplina.
5. O sistema exibe a tela da disciplina.
6. O coordenador de curso seleciona o plano de ensino.
7. O sistema exibe a tela do plano de ensino.
8. O coordenador de curso seleciona a opção validar plano de ensino e opta por salvar.
9. O sistema salva a o plano.
Pós-condição: o plano de ensino foi validado
FLUXO ALTERNATIVO – FA-01 Não conformidades
174
Se, no passo 7 do fluxo base, o coordenador de curso opta por selecionar a opção “não
conformidades” no plano de ensino.
1. O sistema exibe a tela de não conformidades.
2. O coordenador de curso descreve as não conformidades e opta por Salvar.
3. O sistema salva.
Pós-condições: Alterações salvas.
FA-02 Cancela
Se, no passo 2..8 do fluxo base, o coordenador de curso a opção cancelar.
1. termina o caso de uso.
Pós-Condição: o caso de uso é terminado sem nenhuma alteração.
*************************************************************************************************************
Caso de Uso 006 - Nome: Revisa Plano de ensino
Ator ativo: Coordenador acadêmico
Atores passivos: N\A.
Meta:Validar o plano de ensino.
Pré-condição: O coordenador acadêmico de sistema deve estar logado no sistema.
O plano de ensino deve estar liberado pelo professor.
Requisitos Funcionais:
FLUXO BASE
1. O sistema exibe a tela principal do sistema.
2. O coordenador acadêmico seleciona a opção “somente planos não validados ” e opta pela busca
por turmas.
175
3. O sistema exibe as disciplinas conforme o tipo de busca.
4. O coordenador acadêmico seleciona uma disciplina.
5. O sistema exibe a tela da disciplina.
6. O coordenador acadêmico seleciona o plano de ensino.
7. O sistema exibe a tela do plano de ensino.
8. O coordenador acadêmico seleciona a opção verificar plano de ensino e opta por salvar.
9. O sistema exibe a tela de observações.
10. O coordenador acadêmico preenche os dados e seleciona a opção “Verificado”.
11. O coordenador acadêmico opta por salvar.
12. O sistema salva as observações.
Pós-condição: o plano de ensino foi validado
FLUXO ALTERNATIVO – FA-01 Não conformidades
Se, no passo 10 do fluxo base, o O coordenador acadêmico opta por selecionar a opção “não
conformidades” no plano de ensino.
1. O sistema exibe a tela de não conformidades.
2. O O coordenador acadêmico descreve as não conformidades e opta por Salvar.
3. O sistema salva.
Pós-condições: Alterações salvas.
FA-02 Cancela
Se, no passo 2..8 do fluxo base, o coordenador de curso a opção cancelar.
1. termina o caso de uso.
Pós-Condição: o caso de uso é terminado sem nenhuma alteração.
176
*************************************************************************************************************
Caso de Uso 007 - Nome: Visualização do plano de ensino
Ator ativo: Aluno
Atores passivos: N\A.
Meta:visualizar plano de ensino.
Pré-condição: O aluno de sistema deve estar logado no sistema.
Requisitos Funcionais: REF. 01, REF.06
FLUXO BASE
1. O sistema exibe a tela principal do sistema.
2. O aluno seleciona o campus.
3. O sistema exibe os cursos do campus.
4. O aluno seleciona um curso.
5. O sistema exibe os turnos .
6. O aluno seleciona um turno.
7. O sistema exibe a lista de planos de ensino.
8. O aluno seleciona um plano de ensino e opta por visualizar.
Pós-condição: o plano de ensino foi visualizado.
FA-01 Cancela
Se, no passo 2..7 do fluxo base, o aluno seleciona a opção cancelar.
1. termina o caso de uso.
Pós-Condição: o caso de uso é terminado sem nenhuma alteração.
177
*************************************************************************************************************
Caso de Uso 008 - Nome: Validar/Conf. Conversão
Ator ativo: Professor
Atores passivos: N\A.
Meta:Validar a conversão.
Pré-condição: O Professor de sistema deve estar logado no sistema.
Requisitos Funcionais: REF. 01, REF.06
FLUXO BASE
1. O sistema exibe a tela principal do sistema.
2. O professor opta pela busca por turmas.
3. O sistema exibe as disciplinas conforme o tipo de busca.
4. O professor seleciona uma disciplina.
5. O sistema exibe a tela da disciplina.
6. O professor seleciona a opção “Validar Plano”.
7. O sistema exibe a tela do plano de ensino.
8. O professor opta por uma das opções.
9. O professor opta por salvar.
10. O sistema salva a Validação.
Pos-condição: o plano de ensino foi cadastrado
FA-01 Cancela
Se, no passo 2..8 do fluxo base, o professor seleciona a opção cancelar.
1. termina o caso de uso.
Pós-Condição: o caso de uso é terminado sem nenhuma alteração.
178
6 REFERÊNCIAS
ANDRADE, Maria Margarida de. Introdução à metodologia do trabalho científico. 4. ed.
São Paulo: Atlas, 1999, 153 p. ISBN 85-224-2300-8.
AURÉLIO (Aurélio Buarque de Holanda Ferreira). Dicionário Aurélio da Língua
Portuguesa. 2. ed., Nova fronteira.,1999. 2128 p. ISBN 85-209-0411-4.
WALLS, Craig; BREIDENBACH, Ryan. Spring in action. Greenwich: MANNING. 2005.
472 p. ISBN 1-932394-35-4.
BAUER, Christian; KING, Gavin. Hibernate in action. Greenwich: MANNING. 2005. 432 p. ISBN 1932394-15-X. BOEHM, Barry et al. COCOMO II: model definition manual. Version 1.4. Los Angeles,
CA: University of Southern California, 1997. 72 p.
CERVO, A.L; BERVIA, P. A. Metodologia científica. 4. ed. São Paulo: Makron Books,
1996. 209 p. ISBN 85-346-0521-1.
SCHAUM, Coleção. GUSTAFSON, David A. Engenharia de software. Trad. Fernanda
Cláudia Alves Campos. São Paulo: Bookman, 2003. 207 p. ISNB 85–363-0185-6.
DAMODARAM, Mel. Estimation using use case points. Computer Science Program,
Universt of Houston-Victory. 2003.
DOMINGOS, Marlon. Um editor de casos de uso para suportar a rastreabilidade de
artefatos em um processo de software. 2004. Paginação irregular. Trabalho de conclusão de
curso (Bacharelado em Ciência da Computação) – Curso de Ciência da Computação,
Universidade do Vale do Itajaí- Univali, Centro de Educação São José, São José, 2004.
FENTON, Norman E. PFLEEGER, Shari Lawrence. Software metrics: A rigorous and
practical approach. 2. ed. Boston: PWS. 1997. 651 p. ISBN0-534-95425-1.
179
FREIRE, Herval. Calculando estimativas: o método de pontos de caso de uso. Developer´s
magazine, n. 78, fevereiro 2003.
GIL, Antônio Carlos. Métodos e técnicas de pesquisa social. 5.ed. São Paulo: Atlas, 1999.
206 p. ISBN 85-224-2270-2.
HUGHES, Bob; COTTERELL, Mike. Software project management. 2. ed. Washington
D.C.: the McGraw-Hill Companies, 1999. 384 p. ISBN 007-709505-7.
IFPUG - INTERNATIONAL FUNCTION POINT USER GROUP. Function point
counting practices manual. Release 4.1.1, 1999. 354 p.ISBN 0-963-1742-7-4.
JACOBSON, Ivar et al. Object-Oriented Software Engineering. Harlow: Addison-Wesley,
1998. 528 p. ISBN 0-201-54435-0.
JOHNSON Rod, Expert One-on-One J2EE Design and Development, Wrox, JOHNSON,
Rod. Expert One-on-One J2EE Design and Development. Hoboken, EUA: Wrox, 2002. 768p.
ISBN 0-7645-4385-7
KANER, Gustav. Resource estimation for objectory projects. Objective systems SF AB.
1993.
KONOWALOW, Alexsander Pereira. Um ambiente colaborativo de suporte à fase de
concepção. Bolsista PIBIC/CNPQ – 2002/2003. Disponível em:
<http://www.sj.univali.br/~apkalex/pibic>. Acesso em 21 de março de 2005.
MARTIN, James; ODEL, James J. Análise e projeto orientados a objetos. trad. José Carlos
Barbosa dos Santos. São Paulo: Makron Books, 1995. 639 p. ISBN 85-346-0426-6
MAYHAUSER, Annelise Von. Software engineering: Methods and Management..
Boston: Acadamic press. 1990. 864 p. ISBN 0-12-727320-4.
MCT. Catálogo de Qualidade e Produtividade no Setor de Software Brasileiro.
Ministério de Ciência e Tecnologia, 2003.
MINAYO, Maria Cecília de Souza et al. Pesquisa social: Teoria, método e criatividade.
16.ed. Petrópolis: Vozes, 2000. ISBN 85-326-1145-1.
MORETTO, Luís Augusto Machado. Places: uma plataforma colaborativa para
engenharia de software via web. 2005. Paginação irregular. Trabalho de conclusão de curso
180
(Bacharelado em Ciência da Computação) – Curso de Ciência da Computação, Universidade
do Vale do Itajaí- Univali, Centro de Educação São José, São José, 2005.
PETERS, James F; Pedrycz, Wiltold. Engenharia de Software- Teoria e Prática. trad. Ana
Patricia Garcia. Rio de Janeiro: Campus, 2001. 602 p. ISBN 85-352-0746-5.
PMBOK. Project management institute brazil minas gerais chapter. 2000.
PRESSMAN, Roger S. Engenharia de Software. 3 ed. trad. José Carlos Barbasa dos Santos;
revisão técnica José Carlos Maldonado, Paulo César Masiero, Rosely Sanches. São Paulo:
Makron Books, 1995. 1056 p. ISBN 85-346-0237-9.
RAIBLE,Matt. Spring Liveby. LLC.Cover: SourceBeat. 2004. 160 p. ISBN: 0974884340
RIBU, Kirsten. Estimating object-oriented software projects with use cases. 2001. p. 133.
Master of science thesis. Department of informatics. University of oslo, Oslo, 2001.
RICHARDSON, Roberto Jarry et al. Pesquisa Social: Métodos e Técnicas. 3 ed. São Paulo:
Atlas S.A., 1999. 334 p. ISBN 85-224-2111-0.
SOMMERVILLE, Ian. Engenharia de software. 6.ed. São Paulo: Addison-Wesley, 2004.
592 p. ISBN 85-886-3907-6.
SUN. Enterprise javabeans. Novembro, 2005. http://java.sun.com/products/ejb/docs.html.
VENUGOPALAN, Nandini. An Overview of Function Point Analysis. Developer Shed
Newsletter, June, 2004. (http://www.developershed.com).
WALLS, Craig; BREIDENBACH, Ryan. Spring in action. Greenwich: MANNING. 2005.
472 p. ISBN 1-932394-35-4.
WIKIPEDIA. A enciclopédia livre. Acesso em dezembro de 2005.
http://pt.wikipedia.org/wiki/Framework.