ESTIMANDO PROJETOS DE SOFTWARE …siaibib01.univali.br/pdf/Richard Souza.pdfTabela 19 Comparação do modelo original com o novo modelo COCOMO..... 50 Tabela 20 Fatores do expoente

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



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


9


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


Membro

Prof. Dr. Adhemar Maria do Valle Filho


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;


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;


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



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


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


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


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"> 

<beans>  <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"/>  <bean id="urlMapping" class="org.springframework.web.servlet.handler.SimpleUrlHandlerMapping"> <property name="mappings"> <props>  <prop key="/addArtefato.exec">controladorDecasodeuso</prop> <prop key="/salvaartefato.exec">controladoraddDecasodeuso</prop> <prop key="/editaartefato.exec">controladoreditaartefatp</prop> <prop key="/salvaedicao.exec">controladorsalvaedicaoartefato</prop>  <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>  <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>  <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>  <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).


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.


Pós-Condição: Nenhuma alteração.

Caso de Uso 002 - Nome: Cadastra Caso de Uso



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


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.


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).


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).


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).


FE-2 Erro ao excluir

No passo 5 do fluxo alternativo 3, o sistema não consegue excluir o caso de uso.



Caso de Uso 003 - Nome: Calcula Pontos de Caso de Uso



Meta: Calcular o esforço a partir dos casos de uso, atores e fatores de ajuste cadastrados no sistema.


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 .



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



Meta: Cadastrar (Incluir, editar e excluir) Fatores de Ajuste conforme a necessidade do projeto.


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)


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.


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.



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



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.


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."


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.


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)


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.


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)


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)


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.


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.


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.


129

Teste ID: 03



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.





130

Teste ID: 04



Procedimentos: Inicializar o browser. Digitar o endereço o qual se encontra a aplicação PLACES. + “\addCasoDeUso.jsp”





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.


Os dados no campo senha devem estar criptografados.

Resultados Reais: As senhas estão criptografadas.


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.


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.


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.


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.


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)


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.


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


As alterações foram gravadas pelo sistema.

Resultados Reais: Todas as alterações foram realizadas 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.


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


As alterações foram gravadas pelo sistema.

Resultados Reais: Todas as alterações foram realizadas com sucesso.


134

Teste ID: 10

Requisito do Projeto: REF. 06 O sistema deve calcular os fatores ponderados.


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.


Cálculo feito corretamente (RNE.09, RNE.10).

Resultados Reais: O cálculo foi feito corretamente.


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.


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.


Alteração gradavada corretamente.

Resultados Reais: A alteração foi gravada corretamente.


135

Teste ID: 12

Requisito do Projeto: REF. 08 O sistema deve calcular o número de pontos de caso de uso.


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.


Cálculo feito corretamente (ver RNE.011, anexo 5).



Teste ID: 13

Requisito do Projeto: REF. 09 O sistema deve calcular o esforço.


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.


Cálculo feito corretamente (ver RNE.012 anexo 5).



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).


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


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.


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


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.

http://java.sun.com/

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


Figura 39 Tela de configuração do browser.


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.


Clique no botão Variáveis de Ambiente, e aparecerá uma tela conforme figura 43.


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.


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.

http://127.0.0.1:8080/

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.


Selecione a opção I Agree e clique no botão Next, conforme figura 64.


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.


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.


Figura 75 Configuração do JAVA.


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.

http://www.eclipse.org/downloads/

163




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


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.


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".


*************************************************************************************************************

169

Caso de Uso 002 - Nome: Cadastra Plano de ensino

Ator ativo: Professor


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.


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.


170


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.




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."


*************************************************************************************************************

Caso de Uso 003 - Nome: Copia Emenda



Meta:copiar uma emenda.

Pré-condição: Ter uma disciplina cadastrada, estar logado como Coordenador de curso.


171

FLUXO BASE

1. O sistema exibe a tela de principal do sistema.

2. O coordenador de curso opta pela busca por turmas.



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.


*************************************************************************************************************

Caso de Uso 004 - Nome: Copia Plano de ensino





172


FLUXO BASE






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.




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".


173

*************************************************************************************************************

Caso de Uso 005 - Nome: Valida Plano de ensino



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.


FLUXO BASE


2. O coordenador de curso seleciona a opção “somente planos não validados ” e opta pela busca por

turmas.




6. O coordenador de curso seleciona o 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.


FA-02 Cancela

Se, no passo 2..8 do fluxo base, o coordenador de curso a opção cancelar.



*************************************************************************************************************

Caso de Uso 006 - Nome: Revisa Plano de ensino

Ator ativo: Coordenador acadêmico


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.


FLUXO BASE


2. O coordenador acadêmico seleciona a opção “somente planos não validados ” e opta pela busca

por turmas.

175


4. O coordenador acadêmico seleciona uma disciplina.


6. O coordenador acadêmico seleciona o 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.


FA-02 Cancela

Se, no passo 2..8 do fluxo base, o coordenador de curso a opção cancelar.



176

*************************************************************************************************************

Caso de Uso 007 - Nome: Visualização do plano de ensino

Ator ativo: Aluno


Meta:visualizar plano de ensino.

Pré-condição: O aluno de sistema deve estar logado no sistema.


FLUXO BASE


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.



177

*************************************************************************************************************

Caso de Uso 008 - Nome: Validar/Conf. Conversão






FLUXO BASE






6. O professor seleciona a opção “Validar Plano”.


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.



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.

http://www.developershed.com/

Documents

ESTIMANDO PROJETOS DE SOFTWARE …siaibib01.univali.br/pdf/Richard Souza.pdfTabela 19 Comparação do modelo original com o novo modelo COCOMO..... 50 Tabela 20 Fatores do expoente