UNIVERSIDADE FEDERAL DE ITAJUBÁ UNIFEI

UNIVERSIDADE FEDERAL DE ITAJUBÁ – UNIFEI

DESENVOLVIMENTO DE UM MÓDULO PARA AUTOMAÇÃO DO

PROCESSO DE ESTIMATIVAS DE TAMANHO E ESFORÇO

UTILIZANDO A TÉCNICA DE PONTO DE CASO DE USO NA

FERRAMENTA REDMINE.

Mikaele Pereira Caetano

UNIFEI Itajubá

DESENVOLVIMENTO DE UM MÓDULO PARA AUTOMAÇÃO DO

PROCESSO DE ESTIMATIVAS DE TAMANHO E ESFORÇO

UTILIZANDO A TÉCNICA DE PONTO DE CASO DE USO NA

FERRAMENTA REDMINE.

Mikaele Pereira Caetano

Monografia apresentada como trabalho final de graduação, requisito parcial para obtenção do título de Bacharel em Sistemas de Informação, sob orientação do Prof. Adler Diniz de Souza.

UNIFEI Itajubá

DESENVOLVIMENTO DE UM MÓDULO PARA AUTOMAÇÃO DO

PROCESSO DE ESTIMATIVAS DE TAMANHO E ESFORÇO

UTILIZANDO A TÉCNICA DE PONTO DE CASO DE USO NA

FERRAMENTA REDMINE.

Mikaele Pereira Caetano

Esta monografia foi julgada e aprovada como requisito parcial para obtenção do título de Bacharel em Sistemas de Informação, sob orientação do Prof. Adler Diniz de Souza.

Itajubá, 09 de junho de 2015.

_________________________________________________ Prof. Adler Diniz de Souza

Orientador

________________________________________________ Prof. Rodrigo Duarte Seabra

Membro da Banca Examinadora

________________________________________________ Profª. Drª. Elizabete Ribeiro Sanches da Silva

Coordenadora do TFG

UNIFEI Itajubá

RESUMO

Estimativa de software é uma tarefa essencial para estimar o tempo e o custo do desenvolvimento de software, deve ser usado pelas empresas antes do início de um projeto de software. Algumas empresas fazem uso da ferramenta Redmine para gerenciar seus projetos de software, outras fazem apenas uso de técnicas de estimativa com auxílio de planilhas eletrônicas, como, por exemplo, a técnica de Pontos de Caso de Uso. O principal problema do uso de planilhas é a perda de informações importantes do projeto. Este trabalho propõe o desenvolvimento de um módulo para a ferramenta Redmine, a fim de automatizar o processo de estimativa de tamanho e esforço de software aplicando a técnica de estimativa de software por Pontos de Caso de Uso.

ABSTRACT

Software estimation is an essential task to estimate the time and cost of software development must be used by companies before the beginning of a software project. Some companies make use of Redmine tool for managing your software projects others do only use estimation techniques with the aid of spreadsheets, for example, points of technique Use Case. The main problem is the use of spreadsheets the loss of important project information. This work proposes the development of a module for Redmine tool in order to automate the process of estimating size and software effort applying the software estimation technique Use Case points.

LISTA DE FIGURAS

Figura 1 – Representação das funções e a fronteira da aplicação ... 3

Figura 2 – Diagrama de caso de uso do funcionamento da aplicação ... 8

Figura 3 – Interface de cadastro de projeto ... 16

Figura 4 – Interface de CRUD de atores ... 17

Figura 5 – Interface CRUD de casos de uso ... 17

Figura 6 – Interface para pontuação dos fatores técnicos ... 18

Figura 7 – Interface de resultado da estimativa ... 19

Gráfico 1 – Resposta dos alunos em relação à métrica funcionalidade ... 21

Gráfico 2 – Resposta dos alunos em relação à métrica confiabilidade ... 21

LISTA DE TABELAS

Tabela 1 – Classificação dos atores ... 4

Tabela 2 – Classificação dos casos de uso ... 4

Tabela 3 – Classificação dos atores do sistema ... 12

Tabela 4 – Classificação dos casos de uso do sistema ... 13

Tabela 5 – Cálculo dos fatores de complexidade técnica ... 14

LISTA DE QUADROS

Quadro 1 – Casos de uso utilizados no Estudo de Caso 1 ... 20

Quadro 2 – Resposta das empresas em relação à métrica funcionalidade ... 23

Quadro 3 – Respostas das empresas em relação à métrica confiabilidade ... 23

SUMÁRIO

1. Introdução ... 1

1.1 Organização da monografia ... 1

2. Revisão da Literatura ... 2

2.1. Pontos por Função ... 2

2.2. Pontos de Caso de Uso – PCU ... 3

2.3. Trabalhos Correlatos ... 6

3. Desenvolvimento da aplicação ... 8

3.1. Ferramentas e técnolgias ... 9

3.1.1. Redmine ... 9

3.1.2. Ruby ... 9

3.1.3. HTML - Linguagem de Marcação de Hipertexto ... 9

3.1.4. Jquery ... 10

3.2. Casos de uso do sistema ... 10

3.3. Estimativa do esforço da aplicação ... 11

3.4. O módulo de estimativa de esforço ... 15

3.4.1. Manutenção dos projetos ... 16

3.4.2. Manutenção dos atores do projeto ... 16

3.4.3. Manutenção dos casos de uso do projeto... 17

3.4.4. Pontuar os fatores de complexidade técnica e ambiental ... 18

1. INTRODUÇÃO

Segundo Pressman (2006), estimar o esforço de um projeto de forma precisa é difícil, pois os requisitos podem ser de alto nível, imprecisos ou incompletos. Essa dificuldade aumenta muito mais quando ainda não se desenvolveu nenhum projeto semelhante ou quando a linguagem de programação nunca foi usada anteriormente pela equipe de projeto.

Tendo em vista as dificuldades de se estimar o esforço requerido para desenvolver uma ou mais funcionalidades de um software — por exemplo, quanto tempo um programador leva para desenvolver uma funcionalidade X e a dificuldade em se atualizar os fatores de produtividade —, observou-se a possibilidade de automatizar o processo de estimativas que, muitas vezes, é feito em planilhas que acabam sendo esquecidas ou arquivadas.

Geralmente as empresas que utilizam a técnica de estimativa de projetos por Pontos de Caso de Uso fazem uso de ferramentas para desenhar o diagrama de casos de uso e/ou planilhas eletrônicas, os arquivos gerados precisam ser compartilhados entre os desenvolvedores e armazenados para consultas futuras, em alguns casos são perdidos com o tempo.

O objetivo deste trabalho é automatizar a estimativa do tamanho dos projetos de software, utilizando a técnica de Ponto de Caso de Uso, por meio do desenvolvimento de um módulo na ferramenta Redmine. Como resultado, espera-se a diminuição da margem de erro entre tempo estimado e o tempo real gastos no desenvolvimento dos projetos de desenvolvimento de software, além de eliminar o uso das planilhas eletrônicas utilizadas para realizar a estimativa; evitando assim a perda de informações de estimativas e bases históricas.

1.1 Organização da monografia

Esta monografia está organizada da seguinte maneira:

 No Capítulo 2 são apresentadas as técnicas de estimativa de projeto para análise de Pontos de Caso de Uso, análise de Pontos por Função e alguns trabalhos correlatos.

 No Capítulo 3 são apresentadas algumas das linguagens e tecnologias utilizadas, casos de uso essenciais para o desenvolvimento da aplicação, a fim de exemplificar a utilização da técnica de estimativa de Pontos de Caso de Uso, além do módulo desenvolvido e sua forma de utilização.

2. REVISÃO DA LITERATURA

O objetivo da estimativa de software é calcular o esforço e o prazo para desenvolver um sistema. É essencial descobrir-se o custo de um projeto de software antes de iniciar o seu desenvolvimento, principalmente para as empresas; foi, a partir dessa necessidade, que surgiram as técnicas de estimativa de software.

Por muito tempo, a estimativa de tamanho de software era feita por meio da contagem de linhas de código-fonte, utilizando-se a técnica de mensuração por linhas de código (Lines of Code - LOC). Entretanto, Pressman (2006) e Gollapudi (2004) apresentam para essa técnica algumas desvantagens como: (i) a dependência da linguagem de software e do desenvolvedor; (ii) a ausência de um padrão de contagem.

A partir dessas deficiências foram desenvolvidas novas técnicas como a Estimativa por Pontos de Caso de Uso e Estimativas de Pontos de Função, a serem detalhadas nas próximas seções.

Segundo Pressman (2006), as estimativas podem ser classificadas em:

 Estimativa de Tamanho: é medida a partir dos requisitos, análise do projeto ou código do software e com base nas suas funções e na complexidade do problema.

 Estimativa de Esforço: quantidade de trabalho necessário para desenvolvimento do projeto obtido a partir da estimativa de tamanho.

Com base nessas estimativas, é possível obter a Estimativa de Prazo que prevê o tempo necessário para o desenvolvimento do projeto. Na seção 2.2, são apresentadas duas técnicas para a estimativa de tamanho.

2.1. Pontos por Função

A Análise por Pontos por Função (APF) surgiu em 1979 e foi desenvolvida por Alan Albrecht. Essa técnica obteve grande aceitação e uma quantidade cada vez maior de pessoas começou a utilizá-la. Hoje o método é mantido e aprimorado pelo International Function Point Users Group – IFPUG.

Ela permite estipular um fator de normalização e comparação de softwares, realizar estimativa de custos e recursos, além de estabelecer uma linguagem comum entre usuário e desenvolvedor, o que reduz conflitos de negociação.

do software que se pretende construir, ou seja, o grau de complexidade de desenvolvimento do software.

Segundo o IPFUG, a contagem de Pontos por Função pode ser representada conforme mostra a Figura 1.

Figura 1 – Representação das funções e a fronteira da aplicação Fonte: adaptado de Willimar, 2010.

Dekkers (1998) descreve a terminologia da Figura 1:

Arquivo Lógico Interno (ALI): grupo lógico de dados mantido pelo aplicativo. Seu objetivo é armazenar dados mantidos por meio de uma ou mais transações da aplicação.

Arquivo Interface Externa (AIE): grupo lógico de dados referenciado, mas não mantido. Seu objetivo é armazenar dados referenciados por meio de uma ou mais transações da aplicação.

Entrada Externa (EE): mantém ALI ou passa dados de controle para a aplicação. Seu objetivo é manter um ou mais arquivos lógicos internos e/ou alterar o comportamento do sistema. Exemplo: incluir cliente, alterar cliente, excluir cliente.

Saída Externa (SE): dados formatados enviados para fora do aplicativo, com valor adicionado. Seu objetivo é apresentar a informação ao usuário para realizar algum cálculo.

Consulta Externa (CE): ao contrário da Saída Externa (SE), seu objetivo é apresentar informação ao usuário pela simples recuperação de dados ou informações de controle de arquivos lógicos internos (ALI) ou arquivos de interface externa (AIE). Não é necessário adicionar nenhum valor à saída.

2.2. Pontos de Caso de Uso – PCU

do projeto, já que depende apenas da descrição dos requisitos de sistema (Medeiros, 2004). O módulo desenvolvido neste trabalho faz uso da técnica de estimativa por Ponto de Caso de Uso.

A técnica de Pontos de Caso de Uso foi proposta por Gustav Karner em 1993, e baseou-se na técnica de Pontos de Função, que foi apresentada na Seção 2.1. Segundo Medeiros (2004), a técnica de PCU pode ser dividida em três passos:

Passo 1: cálculo do peso dos atores do sistema, que consiste em classificar o ator do sistema em um dos três tipos de atores: simples, médio ou complexo, conforme a Tabela 1 – Classificação dos atores. O peso total dos atores (TPNAA) é calculado somando-se os produtos das quantidades de atores de cada complexidade por seu respectivo peso

Tabela 1 – Classificação dos atores Complexidade

do Ator Descrição Peso

Simples Sistema acessado através de API de

programação 1

Médio Sistema interagindo através de protocolo de

comunicação 3

Complexo Usuário interagindo por interface gráfica ou

página web 5

Passo 2: cálculo do peso dos Casos de Uso, que consiste no cálculo do peso bruto dos casos de uso que são classificados em três níveis de complexidade, de acordo com o número de transações envolvidas em seu processamento, segue o padrão de classificação da Tabela 2 – Classificação dos casos de uso.

Tabela 2 – Classificação dos casos de uso Complexidade

do Ator Descrição Peso

Simples

Contém uma interface com o usuário

simplificada e utiliza apenas uma entidade no banco de dados.

5

Médio Contém uma interface com o usuário trabalhada

e utiliza 2 ou mais entidades no banco de dados. 10 Complexo Contém uma interface com o usuário complexa

e utiliza 3 ou mais entidades no banco de dados. 15

Para calcular os Pontos de Caso de Uso Não Ajustados, basta somar o peso total dos atores (TPNAA) e o peso total dos casos de uso (TPNAUC), conforme a Equação 1. É chamado de Pontos de Caso de Uso Não Ajustado por ainda não serem considerados os fatores de complexidade.

PCUNA= TPNAA+TPNAUC (1)

Passo 3: cálculo dos Fatores de Ajuste, que consiste em um cálculo de fatores técnicos (analisando uma série de requisitos funcionais do sistema) dado pela Equação 2 e um cálculo de fatores ambientais (requisitos não funcionais associados ao processo de desenvolvimento) dado pela Equação 3.

Os fatores de ajuste técnico, assim como os fatores de ajuste ambiental, devem ser pontuados com valores de 0 a 5 em determinadas características que podem trazer dificuldade para o desenvolvimento do projeto; a Tabela 5 – Cálculo dos fatores de complexidade técnica e a Tabela 6 – Cálculo do fator de complexidade ambiental e técnica que ilustra esse passo podem ser vistas no Capítulo 3, Seção 3.5.

Por fim, os fatores de complexidade técnica (FCT) e de complexidade ambiental (FCA) podem ser calculados com as Equações 2 e 3, respectivamente.

FCT = 0,6 + (0,01* somatório fator técnico) (2)

FCA = 1,4 + (-0,03 * somatório do fator ambiental) (3)

Exemplos de fatores de complexidade técnica: utilização em sistemas distribuídos, relevância do desempenho da aplicação, complexidade de processamento interno, reusabilidade do código, facilidade de instalação, entre outros descritos na Tabela 5 – Cálculo dos fatores de complexidade, apresentada adiante, no Capítulo 3, Seção 3.5.

Exemplos de fatores de complexidade ambiental: familiaridade com o processo de desenvolvimento de software, experiências anteriores, capacidade de análise do líder, motivação da equipe, entre outros descritos na Tabela 6 – Cálculo do fator de complexidade ambiental, apresentada adiante, no Capítulo 3, Seção 3.5.

PCUA = PCUNA * FCT * FCA (4)

O fator de produtividade pode ser obtido com base no tamanho estimado do projeto e no esforço real do projeto, conforme a Equação 5. Para obter o esforço global deve-se multiplicar o peso de caso de uso ajustado (PCUA) pelo fator de produtividade, como apresentado na Equação 6.

Produtividade = Tamanho estimado / Esforço real (5)

Tamanho estimado= PCUA * Produtividade (6)

Quanto mais preciso o valor atribuído ao fator de produtividade, mais próximo da realidade será o tamanho estimado do projeto. Para aumentar essa precisão utiliza-se a média entre os fatores de produtividade de projetos anteriores.

2.3. Trabalhos Correlatos

Existem diversos trabalhos na linha de estimativa de projetos de software. Segundo Andrade e Oliveira (2004), os procedimentos de estimativa por APF e PCU para projetos orientados a objetos devem ser utilizados em diversos projetos de software de uma empresa para que se crie uma base histórica. Andrade e Oliveira (2004) também analisou dezenove projetos de software para montar uma base histórica de dados referente aos valores das estimativas APF e PCU, o que permitiu investigar a existência de uma relação entre as duas estimativas. Chegou-se à conclusão de que para os projetos analisados existia uma equação de relação, o que pode permitir a combinação das duas técnicas de estimativas de software, além de uma lista de ações gerenciais recomendadas para controlar o cronograma do projeto.

quando a empresa faz uso de alguma ferramenta, como o Redmine, para gerência de projetos, essa base histórica pode ser facilmente acessada.

A ferramenta Spider-PE (PORTELA et al., 2012), desenvolvida na Universidade Federal de Pernambuco, tem por objetivo auxiliar a execução de projetos de software com foco na implementação do programa de melhoria da qualidade do processo organizacional. Tem como parte integrante, entre outras ferramentas, o Redmine, que lhe fornece o registro, monitoramento e acompanhamento da resolução de problemas e não conformidades. O Redmine também foi utilizado no desenvolvimento da aplicação apresentada nesta monografia.

3. DESENVOLVIMENTO DA APLICAÇÃO

A ferramenta Redmine é open source e foi escrita com o framework Ruby on Rails, que é um framework com curva de aprendizagem muito baixa e utiliza o padrão Model-view-controller, tornando o código limpo, organizado e de fácil entendimento.

Na Figura 2 é apresentado um diagrama para exemplificar o procedimento e a estrutura da aplicação proposta por essa monografia. Os casos de uso em verde representam o módulo proposto, e os casos de uso em azul são os casos de uso que o Redmine possui implementados.

3.1. Ferramentas e técnolgias

Nesta Seção são apresentadas algumas das técnologias envolvidas no desenvolvimento do módulo proposto.

3.1.1. Redmine

Redmine é uma aplicação web de gerenciamento de projetos. Escrita usando o framework Ruby on Rails e na linguagem Ruby é multiplataforma e multibanco de dados. Entre as características do Redmine pode-se citar:

 Possui um sistema de rastreamento de tarefas/atividades flexível;  Gera o Gráfico de Gantt e calendário;

 Permite o controle de tempo;

 Possui campos personalizados para o cadastro de projetos, tarefas e usuários (permitindo designar tarefas para usuários específicos);

 Permite a atualização das tarefas e dos tempos das tarefas por parte do usuário designado para a tarefa;

 Armazena as informações em banco de dados.

As mais importantes para este trabalho são as relacionadas ao armazenamento (em banco de dados) das tarefas e controle do tempo gasto e estimado para a sua execução, o que permite manter um histórico dos desenvolvedores (usuários do sistema).

3.1.2. Ruby

Segundo Ruby-Lang, em 1993, Yukihiro Matsumoto, inspirado principalmente pelas linguagensPython, Perl, Smalltalk, Eiffel, Ada e Lisp, criou a linguagem Ruby, que é muito similar à linguagem Python em vários aspectos. Ruby é uma linguagem dinâmica, open source, com foco na simplicidade e na produtividade. É orientada a objeto e sua tipagem é dinâmica, ou seja, não é necessário declarar o tipo das variáveis.

3.1.3. HTML - Linguagem de Marcação de Hipertexto

HTML (HyperText Markup Language) é a linguagem utilizada pelas páginas web e interpretada pelo navegador (browser). Segundo a W3C, a sintaxe HTML é baseada em uma lista de tags que descrevem o formato da página. Essas tags formatam os textos que são exibidos.

para apresentação do conteúdo na internet, e propõem melhorias. Ela é a principal responsável pela padronização da internet.

3.1.4. Jquery

É uma biblioteca Javascript de código aberto, construída para facilitar a utilização do próprio Javascript, que, segundo Balduino (2012), permite manipular documentos HTML e eventos do lado do cliente, ou seja, no browser, também chamado de navegador. Esses eventos são executados no cliente, podendo ser iniciados ou interrompidos com base na ação do usuário.

Nesse trabalho, o Jquery será utilizado para capturar a informação que o usuário digitar, por exemplo, quando uma tarefa é cadastrada o usuário seleciona os fatores de complexidade da tarefa. Com base nessa seleção, é possível calcular o tempo estimado para a realização da tarefa antes mesmo que ela seja cadastrada, para que o gerente de projetos não tenha que adivinhar o tempo ou fazer o cálculo à parte.

3.2. Casos de uso do sistema

A seguir são descritos alguns requisitos que devem existir na aplicação proposta nessa monografia, para exemplificar o funcionamento da técnica de estimativa de projetos por Pontos de Casos de Uso:

UC01 – Manter projetos: esse caso de uso permite que o gerente de projetos mantenha (cadastre, altere, consulte e remova) os projetos que serão desenvolvidos. A complexidade desse caso de uso é simples, pois o Redmine já possui esse cadastro e a única alteração é o redirecionamento para o módulo de estimativa de projetos.

UC02 – Manter atores do projeto: esse caso de uso permite que o gerente mantenha (cadastre, altere, consulte e remova) os atores e suas respectivas complexidades (simples, médio e complexo), conforme apresentados na Tabela 2. A complexidade desse caso de uso é média, pois utiliza duas tabelas no banco de dados: projetos e atores.

UC03 – Manter casos de uso do projeto: esse caso de uso permite que o gerente mantenha (cadastre, altere, consulte e remova) os casos de uso do projeto atribuindo-lhes suas complexidades (simples, médio e complexo). A complexidade desse caso de uso é média, pois utiliza duas tabelas no banco de dados: projetos e casos de uso.

Tabela 5 apresentada na próxima seção. A complexidade desse caso de uso é complexa, pois utiliza uma interface mais trabalhada e três tabelas no banco de dados: projetos, complexidades e complexidade do projeto.

UC05 – Pontuar fatores de complexidade ambiental: esse caso de uso permite que o gerente atribua valores entre 0 e 5 para os fatores de complexidade ambiental apresentados na Tabela 6 apresentada na próxima seção. A complexidade desse caso de uso é complexa, pois utiliza uma interface mais trabalhada e três tabelas no banco de dados: projetos, complexidades e complexidade do projeto.

UC06 – Manter a base histórica do projeto: esse caso de uso permite que o gerente de projetos atualize o fator de produtividade quando necessário, deve também sugerir o fator de produtividade média com base na produtividade real de projetos anteriores. A complexidade desse caso de uso é complexa, pois utiliza uma interface mais trabalhada e três tabelas no banco de dados: projetos, complexidade do projeto e base histórica.

UC07 – Calcular o tamanho do projeto: após o cadastro dos atores, casos de uso e pontuação dos fatores de complexidade técnica e ambiental, o módulo deve calcular o tamanho do projeto, com base na produtividade obtida, dos dados históricos ou no valor de produtividade atribuído pelo gerente. A complexidade desse caso de uso é complexa, pois utiliza uma interface mais trabalhada, com uso de Javascript e quatro tabelas no banco de dados: projetos, complexidade do projeto, atores, casos de uso.

3.3. Estimativa do esforço da aplicação

A seguir será apresentada a estimativa de esforço baseada em caso de uso da aplicação proposta neste trabalho, tendo como base os casos de uso mencionados na Seção 3.2. As Tabelas 3 e 4 apresentam, respectivamente, os pesos atribuídos aos atores e aos casos de uso conforme a classificação de complexidade já descrita na Seção 2.2.

Segundo a metodologia Use Case Point os atores são considerados complexos quando interagem com o sistema através de interface gráfica ou páginas web. Como a aplicação possui dois atores e esses interagem por meio de páginas web, eles são classificados como complexos.

Tabela 3 – Classificação dos atores do sistema

Atores

Complexidade

S M C

Gerente de alocações 0 0 1

Usuário comum/ desenvolvedor 0 0 1

Total de Atores 0 0 2

Peso Total 10

Segundo a metodologia Use Case Point os casos de uso são classificados como: (i) simples, se contém uma interface com o usuário simplificada e utiliza apenas uma entidade no banco de dados; (ii) médio, se contém uma com o usuário interface mais trabalhada e utiliza duas ou mais entidades no banco de dados; (iii) complexo se contém uma interface com o usuário complexa e utiliza apenas três ou mais entidades no banco de dados.

Tabela 4 – Classificação dos casos de uso do sistema Casos de Uso Complexidade S M C UC01 Manter projetos 1 0 0 UC02 Manter atores 0 1 0 UC03

Manter casos de uso 0 1 0

UC04

Pontuar fatores de complexidade técnica 0 0 1

UC05

Pontuar fatores de complexidade ambiental 0 0 1

UC06

Manter a base histórica do projeto 0 0 1

UC07

Calcular o tamanho do projeto 0 0 1

Total Casos de Uso

1 2 4

Peso Total

85

Os pontos de casos de uso não ajustados (PCUNA) podem ser encontrados pela soma dos pesos dos atores e dos pesos dos casos de uso.

PCUNA = 85 + 10= 95

Tabela 5 – Cálculo dos fatores de complexidade técnica

# Fatores Técnicos Peso Valor Peso x

Valor

T1 Sistema distribuído 2 0 0

T2 Objetivos de performance relativos à

tempo de resposta e vazão 1 1 1

T3 Eficiência on-line 1 1 1

T4 Processamento interno complexo 1 3 3

T5 Reutilização de código 1 0 0 T6 Facilidade na instalação 0,5 0 0 T7 Facilidade na utilização 0,5 5 2,5 T8 Portabilidade 2 0 0 T9 Manutenabilidade 1 2 2 T10 Concorrência 1 1 1

T11 Inclui características especiais de

segurança 1 0 0

T12 Fornece acesso direto de/para terceiro 1 0 0

T13 Facilidades de treinamento especiais para

usuários 1 0 0

Total dos Fatores Técnicos 10,5

FCT= 0,6 + (0,01 x 10,5) = 0,705 0,705

Tabela 6 – Cálculo do fator de complexidade ambiental

# Fatores Ambientais Peso Valor

(0-5)

Peso x Valor FA1 Familiaridade com o RUP (ou o processo de

desenvolvimento utilizado) 1,5 3 4,5

FA2 Experiência na aplicação 0,5 2 1

FA3 Experiência em orientação a objetos 1 3 3

FA4 Capacidade de liderança do analista líder 0,5 5 2,5

FA5 Motivação 1 4 4

FA6 Requisitos estáveis 2 3 6

FA7 Trabalhadores part-time −1 5 −5

FA8 Dificuldade na linguagem de programação −1 0 0

Total dos Fatores Ambientais 16

FCA = 1,4 + (-0,03 x 16) = 0,92 0,92

Tanto na Tabela 3, quanto na Tabela 4, a coluna Valor deve receber notas de 0 a 5. Já a coluna Peso x Valor apresenta o produto das colunas Peso e Valor. As colunas Fatores Técnicos e Peso apresentam valores fixos.

O cálculo do peso de caso de uso ajustado é dado pelo produto do peso de casos de uso não ajustado e dos fatores de complexidade técnica e de complexidade ambiental.

PCUA = 95 x 0,705 x 0,92 = 61,62

Para o desenvolvimento deste trabalho foi utilizada a técnica de estimativa por Ponto de Caso de Uso descrita na Seção 2.2, a ferramenta para gerenciamento de projetos Redmine e as linguagens de programação.

3.4. O módulo de estimativa de esforço

3.4.1. Manutenção dos projetos

Essa etapa é a principal da ferramenta Redmine; nenhuma alteração foi feita na interface com o usuário, apenas foi acrescido o botão ―Criar e continuar‖ que cria o projeto e redireciona o usuário para o módulo de estimativa de projetos, conforme a Figura 3.

Figura 3 – Interface de cadastro de projeto

3.4.2. Manutenção dos atores do projeto

Figura 4 – Interface de CRUD de atores

3.4.3. Manutenção dos casos de uso do projeto

A Figura 5 representa a interface de manutenção dos casos de uso; devem ser cadastrados os casos de uso do projeto classificados em simples, médio ou complexo. O sistema não permite o cadastro de casos de uso com descrições iguais no mesmo projeto.

3.4.4. Pontuar os fatores de complexidade técnica e ambiental

A Figura 6 apresenta a interface para pontuação dos fatores de complexidade técnica. Como já descrito na Seção 2.2 deve-se atribuir valores de 0 a 5 aos fatores de complexidade técnica e ambiental.

Figura 6 – Interface para pontuação dos fatores técnicos

3.4.5. Resultado

Após o preenchimento de todas as informações solicitadas, o módulo realiza o cálculo da estimativa, utilizando a técnica de pontos de caso de uso.

4. AVALIAÇÃO DO MÓDULO

Foram realizados dois estudos de caso com duas amostras: (i) uma composta por alunos que cursaram a disciplina Engenharia de Software II da Universidade Federal de Itajubá; (ii) a outra, por profissionais formados que trabalham com desenvolvimento de projetos de software na Incubadora de Empresas de Base Tecnológica de Itajubá.

Para avaliação do módulo desenvolvido foi utilizada a norma ISO/IEC 25010, que propõe um modelo para avaliação de produtos de software.

4.1. Estudo de Caso 1: avaliação do módulo de estimativa de caso de uso realizada com alunos da disciplina de Engenharia de Software II

Os alunos utilizaram o módulo para realizar o teste estimando o esforço de dois casos de uso, apresentados no Quadro 1; após o teste, responderam o questionário de avaliação (Apêndice A).

Quadro 1 – Casos de uso utilizados no Estudo de Caso 1

ID Nome Descrição Atores

UC01 Manter Fornecedor

Caso de uso começa quando o Ator deseja adicionar um novo fornecedor ao sistema. Administrador, Digitador e Responsável pelo Almoxarifado. UC02 Informar a Entrada de Medicamentos no Almoxarifado

Caso de uso começa quando o Ator deseja informar as entradas dos medicamentos.

Administrador e Digitador

A classificação da complexidade dos atores e dos casos de uso ficou a critério da interpretação dos alunos. Dois valores de pontos de caso de uso não ajustados (PCUNA) foram obtidos ao final do estudo de caso: 8 alunos (57,1%) obtiveram PCUNA igual a 35; os outros 6 alunos (42,9%) encontraram PCUNA igual a 30.

Dos 14 alunos, 7 (50%) afirmaram conhecer e já ter feito uso da ferramenta Redmine e 11 alunos (73%) afirmaram ter utilizado a técnica de estimativa por pontos de caso de uso.

Gráfico 1 – Resposta dos alunos em relação à métrica funcionalidade

O tempo de resposta foi considerado aceitável por todos os alunos, assim como a facilidade de utilização do módulo. Dos alunos, 10 (71,4%) afirmaram não encontrar falhas no sistema, enquanto um (7,1%) aluno afirmou encontrar falha no sistema e 3 (21,4%) consideram que a pergunta não se aplica ao contexto; ver o Gráfico 2. A falha encontrada por um aluno ocorreu devido à ausência de validação para entrada de valores atribuidos aos fatores de complexidade técnica, Seção 3.4.4, o problema foi solucionado utilizando Jquery.

Gráfico 2 – Resposta dos alunos em relação à métrica confiabilidade

Gráfico 3 – Resposta dos alunos em relação à métrica usabilidade

4.2. Estudo de Caso 2: Avaliação do módulo de estimativa de caso de uso realizada com empresas de desenvolvimento de software.

Das três empresas entrevistadas, duas já possuem experiência com a estimativa de Pontos de Caso de Uso e uma não utiliza nenhuma técnica formal para estimar o tamanho dos projetos; essa última utiliza o conhecimento e experiências anteriores para realizar a estimativa.

A Mundo SEO, que não possui experiências anteriores, tem quatro funcionários e já faz uso da ferramenta Redmine para gerenciar seus projetos.

A Pandô Apps tem seis funcionários, não utiliza técnica de estimativa por pontos de caso de uso, mas utiliza o diagrama de casos de uso para conhecer o tamanho do projeto e realiza o cálculos em rascunhos, assim não armazena de forma efetiva a base de dados de projetos anteriores.

Já a Web nas Nuvens tem oito funcionários, utiliza planilhas eletrônicas para realizar a estimativa por Pontos de Caso de Uso e a ferramenta Redmine para gerenciar o desenvolvimento dos projetos.

Quadro 2 – Resposta das empresas em relação à métrica funcionalidade O cálculo das

horas é mais fácil usando a ferramenta? Permite gerenciar os atores envolvidos? Permite gerenciar os casos de uso do sistema? Permite a identificação dos atores envolvidos nos casos de uso? Mundo SEO Sim, parcialmente Sim, parcialmente Sim Sim

Pandô Apps Sim Sim Sim Sim

Web nas

Nuvens Sim Sim Sim Sim

Em relação à métrica confiabilidade as três empresas também afirmaram que o módulo é rápido e não apresenta falhas com frequência, conforme o Quadro 3.

Quadro 3 – Respostas das empresas em relação à métrica confiabilidade Apresenta falhas

com frequência?

É rápido ou tem uma velocidade de processamento aceitável?

Mundo SEO Não Sim

Pandô Apps Não Sim

Web nas

Nuvens Não Sim

Todas as empresas também concordaram quanto à facilidade de entendimento, aprendizado e operação do módulo, conforme o Quadro 4.

Quadro 4 – Respostas das empresas em relação à métrica usabilidade É fácil entender o conceito e a aplicação? É fácil aprender a usar? A ajuda contextual está disponível? É fácil de operar e controlar?

Mundo SEO Sim Sim Sim Sim

Pandô Apps Sim Sim Sim Sim

Web nas

5. CONSIDERAÇÕES FINAIS

O módulo desenvolvido agiliza o processo de estimativa de software, uma vez que substitui as planilhas e rascunhos utilizados para estimativa de casos de uso. A Web nas Nuvens é um exemplo de empresa que obteria ótimos resultados com a implantação do módulo, pois já utiliza o Redmine e a técnica de pontos por caso de uso.

Dentre as vantagens, além da redução de tempo e do retrabalho no processo de estimativa, a ferramenta armazena, de forma efetiva, a base histórica dos projetos, em um banco de dados, resultando em maior precisão da estimativa.

6. REFERÊNCIAS

ANDRADE, Edméia L. P.; OLIVEIRA, Káthia M.. Aplicação de Pontos de Função e Pontos de Casos de Uso de Forma Combinada no Processo de Gestão de Estimativa de Tamanho de Projetos de Software Orientado a Objetos. III SIMPÓSIO BRASILEIRO DE QUALIDADE

DE SOFTWARE. Anais... Brasília, 2004. Disponível em:

<http://www.ip.pbh.gov.br/ANO7_N1_ PDF/IP7N1_andrade.pdf>. Acesso em: 25 ago. 2014.

BALDUINO, Plínio. Dominando JavaScript com jQuery. São Paulo: Casa do Código, 2012.

DEKKERS, Carol A. Desmistificando Pontos de Função: Entendendo a Terminologia.

Out./1998. IT Metrics Strategies. Disponível em: <http://www.bfpug.com.br/

Artigos/Desmistificando%20Pontos %20de%20Fun % C3%A7%C3%A3o.pd>. Acesso em: 19 set. 2013.

GOLLAPUDI, Kurmanadham V.V.G.B. Function Points or Lines of Code? - An Insight.

Global Microsoft Business Unit, 2004. Disponível em:

<http://sst.umt.edu.pk/courses/cs590/functionpointsorlinesofcode.doc>. Acesso em: 21 de ago. 2013.

HEIMBERG, Viviane. Estudo de Caso de Aplicação da Métrica de Pontos de Casos de Uso

numa Empresa de Software. 2005. Disponível em: <http://www.inf.

furb.br/seminco/2005/artigos/130-vf.pdf> Acesso em: 21 de ago. 2013.

IFPUG. International Function Point Users Group. Disponível em:

<http://www.ifpug.org/about-ifpug/about-function-point-analysis/> Acesso em: 21 de ago. 2013.

MEDEIROS, Ernani. Desenvolvendo Software com UML 2.0. São Paulo: Makron Books, 2004.

PRESSMAN, Roger S. Engenharia de software. 6.ed. Porto Alegre: Bookman, 2006.

PORTELA, Carlos S.; SILVA, Antônio A. C.; SILVA, Elder J. F.; OLIVEIRA, Sandro R. B.; VASCONCELOS, Alexandre M. L. Spider-PE: Uma Ferramenta de Apoio à Execução de

Processos de Software aderente ao CMMI-DEV e MR-MP. 2012. Disponível em:

<http://wsl.softwarelivre.org/2012/0003/5.pdf> Acesso em: 3 set. 2014.

REDMINE. Comunidade Redmine. Disponível em: <www.redmine.org> Acesso em: 20 ago. 2013.

RIBEIRO, Altair L. Análise de Pontos por Função. p. 37 (adaptado). Disponível em: <www.bfpug com br rtigos adia ppt >. Acesso em 20 ago.2013.

SALEH, Diogo B; BRITZ; José C M. Gerência do Ciclo de Vida de Casos de Uso Baseada na

Ferramenta Redmine. 2013. Disponível em:

<http://bsi.uniriotec.br/tcc/201304SalehBritz.pdf>. Acesso em: 20 jan. 2013.

WAZLAWICK, Raul S. Análise e Design Orientados A Objetos Para Sistemas de Informação 3.ed. Elsevier. 2015.

GLOSSÁRIO – Fatores de Complexidade

C

Concorrência - necessidade da aplicação trabalhar com controle de acesos simultâneos, como, por exemplo, compartilhamento de dados ou recursos (Wazlawick, 2015).

E

Eficiência on-line - Necessidade da aplicação permanecer 24h online para acesso do usuário.

F

Facilidade de treinamento especiais para usuários - os usuários do sistema precisam de treinamento para utilizarem o sistema ou a aplicação deve ser de fácil entendimento (Wazlawick, 2015).

Facilidade na instalação - a aplicação precisa ser projetada de forma que a instalação seja automática, ou seja, usuário com pouca capacidade técnica encontra facilidade na instalação (Wazlawick, 2015).

Facilidade na utilização - a aplicação é projetada para realizar ações sem a necessidade de um operador, ações podem ser pré-programadas, necessidade de capacidade técnica para utilizar o sistema (Wazlawick, 2015).

Familiaridade com o RUP - Familiaridade com processo unificado, o RPU (Rational Unified Process) utiliza orientação a objetos e a documentação utiliza a notação UML (Unified Modeling Language) para ilustrar os processos, com o objetivo de aumentar a produtividade da equipe.

Fornece acesso direto de/para terceiro - O sistema utiliza frameworks ou não existe nenhum código pré existente ou código de qualidade questionável (Wazlawick, 2015).

M

Manutenabilidade - facilidade de manter e mudar a aplicação no futuro.

O

P

Portabilidade - necessidade da aplicação funcionar em diferentes plataformas.

Processamento interno complexo - necessidade de algorítimos complexos em funcionalidades da aplicação (Wazlawick, 2015).

R

Reutilização de código - a aplicação deve ser empacotada e/ou documentada para facilitar o reuso do código e ser personalizável (Wazlawick, 2015).

S

Segurança - necessidade de especificações adicionais de segurança, o plano de segurança é elaborado e testado para suportar auditoria (Wazlawick, 2015).

Sistema distribuído - a aplicação utiliza uma arquitetura distribuída, vários núcleos ou computadores para executar sus processos (Wazlawick, 2015).

T