Tecnologia do Blogger.

Localizar

segunda-feira, 14 de junho de 2010

Ponto de Função (Conceitual)


WILLIMAR AUGUSTO ROCHA



DEFINIÇÃO DE PRAZOS EM EMPRESAS DE TECNOLOGIA DA INFORMAÇÃO


Artigo sobre criação de uma métrica para formação de prazos para projetos de empresa de TI utilizando a metodologia de analise de pontos de função, Requisito de estudo para aplicação em Gerência de Projetos.




Juiz de Fora
2010



1. INTRODUÇÃO

          Flexibilidade e Eficiência no fechamento de prazos são requisitos primordiais para o sucesso de uma empresas prestadoras de serviço num mundo globalizado e cada vez mais concorrido. Hoje existem varias empresas, marcas e preços e o que faz o cliente comprar de uma empresa em específico?
          Segundo Philip Kotler a premissa é de que os clientes comprarão da empresa, que segundo a percepção dele oferecer maior valor. Para empresas de softwares as Software Houses um dos itens que agregam valor, mas não único é o prazo.
          Sistemas que atrasam na entrega geram insatisfação e reavaliação de valor do serviço por parte do cliente. Kotler conceituando sobre satisfação afirma que satisfação consiste na sensação de prazer ou desapontamento resultante da comparação de desempenho (ou resultado) percebido de um produto em relação a expectativa do comprador.



1.1. Considerações iniciais

          Já trabalhei em três diferentes software houses e uma fábrica de software e em cada uma destas empresas em que passei o maior problema sempre foi definir um prazo e conseguir cumprir sem ter de fazer hora extra. A coisa se agravou ainda mais na fábrica de software onde a customização de produtos elevava e muito a quantidade de horas extras, o que acarretava em perda de qualidade do software devido a insatisfação da equipe de programadores. Sem falar no feedback obtido pela empresa junto ao cliente por causa do atraso.
          O que cada uma destas empresas tinham em comum que fazia com que falhassem na definição de prazos?
          Todas elas não tinham nenhuma metodologia cientifica para definição dos prazos ignorando ou desconhecendo a existência de métodos para auxilio de cálculo para definição de prazos em empresas de TI (Tecnologia da Informação).
          Segundo o Professor Carlos Alberto Ribeiro muitos projetos de TI não obtém sucesso devido a problemas na projeção de tempo.
          Os problemas de definição de prazos podem ocorrer devido a vários fatores, mas o principal nestas empresas é a metodologia de definição de prazos. Nestas empresas nenhum dos projetos deixaram de ser concluídos, mas freqüentemente sofriam modificações na data de conclusão o que gerava frustração do cliente e de todos os outros stakeholders.

1.2. Questões norteadoras

          A definição de prazos constantemente é o maior desafio para empresas de TI que normalmente fazem isso num processo de “achismo” ou baseado no histórico de tarefas e projetos já executados.
          Qual outra maneira para definição de prazos pode ser usada em empresas de TI?

2. OBJETIVOS

2.1. Objetivos Gerais

          Demonstrar através de analise de ponto de função a possibilidade de se criar uma métrica para projetos de softwares e definição de tarefas, com escopo e prazos que possam ser consumados.

2.2. Objetivos Específicos

          Elucidar as reais vantagens de utilização de método cientifico para formulação de prazos.
          Elucidar como analise de ponto de função pode auxiliar na formação de prazos.

3. JUSTIFICATIVA

          Software housers, necessita cada vez mais de agilidade e velocidade no cumprimento de tarefas e para tal é necessário se criar prazos que não desmotivem os desenvolvedores criando sobrecargas no seu trabalho mantendo o nível de rotatividade de funcionários da empresa baixo.
          Segundo o Professor Gretz velocidade é a rapidez de movimentos, providencias, atitudes e decisões e agilidade é a leveza, desembaraço, vivacidade. Ágil é quem se move com facilidade despacha os assuntos com presteza e realiza as tarefas com eficiência sem enrolar e sem deixar as pendências se acumularem sobre a mesa.
          Logo o que se faz necessário é criar uma ferramenta que faça que o programador se torne ágil e a empresa por conseqüência disso seja mais veloz, e para isso é preciso criar formas de medição, pois “especificamente o processo de produção precisa de controles internos” (Druker, Peter F.). Apesar da possibilidade de que se seja criada resistência pelos programadores ou mesmo temores devido a existência de criação de métricas de avaliação de desempenho segundo Peter Druker o primeiro passo para tornar o trabalhador realizado é tornar o seu trabalho produtivo.
          Tornar o trabalho de um programador produtivo não é simples e não vai se limitar em estabelecer prazos e metas para execução de seu trabalho, pois ainda citando Druker que diz que são necessários quatro atividades separadas para tornar o trabalho produtivo: primeiro analise operações especificas necessárias ao trabalho, segundo síntese operações individuais precisam ser agrupadas num processo de produção, terceiro controle de direção de quantidade e qualidade de padrões e exceções e quarto providenciar instrumentos adequados.
          Como pode se observar, a definição de prazos reais não é um requisito único para o sucesso da empresa, mas por momento será o tema abordado neste projeto, já que ele se faz tão importante quanto qualquer outro.

4. EMBASAMENTO TEORICO

          Este estudo será fundamentado por estudos apresentados pelo Professor Carlos Alberto.
          Antes de iniciar o estudo especifico sobre analise de ponto de função é interessante salientar que existem outros métodos para formação de prazo para projetos de softwares.

4.1. Metodo COCOMO (Construtive Cost Model)

          COCOMO (Construtive Cost Model): Modelo Algorítmico, composto, proposto por BARRY BOHEM da TRW em 1981 para estimar esforço de desenvolvimento, prazo e tamanho de equipe para um Projeto. Estimativa baseada em profissionais/mês.
          Subdivisão do COCOMO é feita em Básico (estimativas fornecidas são limitadas. Desconsideram limitações de hadware, qualificações e experiência do pessoal e uso de modernas técnicas e ferramentas), Intermediário (Adiciona os fatores suprimidos aumentando a acurácia) e Detalhado (Técnicas para se estimar tanto em nível de módulo, subsistema, e sistema, individualizando em todas as fazes do projeto os atributos de custo).

          BÁSICO

ESTIMATIVA DE ESFORÇO
MODO DE DESENVOLVIMENTO
EQUAÇÕES
ORGANICO
ESFORÇO (H/M) = 2,4(KDSI)1,05
DIFUSO
ESFORÇO (H/M) = 3,0(KDSI)1,12
RESTRITO
ESFORÇO (H/M) = 3,6(KDSI)1,20
ESTIMATIVA DE PRAZO
MODO DE DESENVOLVIMENTO
EQUAÇÕES
ORGANICO
PRAZO = 2,5(H/M)0,38
DIFUSO
PRAZO = 2,5(H/M)0,35
RESTRITO
PRAZO = 2,5(H/M)0,32
TAMANHO DA EQUIPE = (H/M)/PRAZO

          INTERMEDIÁRIO

ESTIMATIVA DE ESFORÇO
MODO DE DESENVOLVIMENTO
EQUAÇÕES
ORGANICO
ESFORÇO (H/M) = 3,2(KDSI)1,05
DIFUSO
ESFORÇO (H/M) = 3,0(KDSI)1,12
RESTRITO
ESFORÇO (H/M) = 2,8(KDSI)1,20
ESTIMATIVA DE PRAZO
MODO DE DESENVOLVIMENTO
EQUAÇÕES
ORGANICO
PRAZO = 2,5(H/M)0,38
DIFUSO
PRAZO = 2,5(H/M)0,35
RESTRITO
PRAZO = 2,5(H/M)0,32
TAMANHO DA EQUIPE = (H/M)/PRAZO

          Os quinze fatores de estimativa nominal para ajuste dos multiplicadores de esforços:
          • Atributos do Produto
                    o RELY: Confiabilidade requerida pelo Software
                    o DATA: Tamanho da Base de Dados
                    o CPLX: Complexidade do Produto
          • Atributos Computacionais
                    o TIME: Restrições de Execução (Tempo Máquina)
                    o STOR: Restrições de tamanho de uso da memória principal
                    o VIRT: Volatibilidade do ambiente virtual
                    o TURN: Tempo de resposta
          • Atributos da equipe
                    o ACAP: Capacidade dos analistas
                    o AEXP: Experiência na aplicação
                    o PCAP: Capacidade dos programadores
                    o VEXP: Experiência em máquina virtual
                    o LEXP: Experiência na linguagem de programação
          • Atributos do Projeto
                    o MODP: Técnicas modernas de programação
                    o TOOL: Uso de ferramentas
                    o SCED: Prazo requerido para o desenvolvimento
          Como pode ser percebido o uso do COCOMO exige que todas as etapas do projeto tenham sido concluídas com maior precisão possível, pois cada um dos fatores indicados tem um peso individual e são os multiplicadores para ajustarem as estimativas.

          Homem/Mês x RELLY x DATA x CPLX x TIME x STOR x VIRT x TURN x ACAP x AEXP x PCAP x VEXP x LEXP x MODP x TOLL x SCED

          Outro comentário pertinente é que os multiplicadores tratam equipes de forma homogenia não considerando que na equipe possam conter membros mais experientes e outros menos por exemplo.

4.2. Function Poit Analysis (FPA – Analise de Ponto de Função)

          Baseando-se no ponto de vista do usuário FPA passa a ser uma medida para determinar o tamanho de uma aplicação.
          Desenvolvida na IBM em 1979, por autoria de Allan Albrecht. O procedimento é ajustado pelo nível de complexidade, determinado por características da aplicação (comunicação, performance, volume das transações, facilidade de instalação).

4.2.1. Conceitos preliminares

          Entrada Externa (EE): Dados gerados a partir de origem externa a aplicação.
Ex.:
          Importação de arquivos gerados por outro aplicativo.
          Informação fornecida por usuário a ser gravada e Arquivo Lógico Interno.

          Saída Externa (SE): Geração de informações a partir de dados armazenados. Estes dados durante o processo de apresentação sofrem transformações. As transformações podem ser embasadas em formulas matemáticas, cálculos de totais, dados derivados. Podem também alterar o comportamento do sistema.
Ex.:
          Relatórios (Desde que totalizem valores, ou possuam cálculos)
          Relatórios que atualizem arquivos.
          Exportação de arquivos de dados.
          Gráficos.

          Arquivo Lógico Interno (ALI): Arquivos lógicos que contém dados gerados pela aplicação.
Ex.:
          Tabela de Dados.
          Arquivo de Configuração da Aplicação.
          Arquivos de Log.
          Arquivos de exportação de dados, arquivo temporários, arquivos de índice não se enquadram como ALI, pois seu perfil de utilização são enquadrados como SE.

          Arquivos de Interface Externa (AIE): Arquivos de dados gerados externamente ao aplicativo que servem para somente leitura. Estes arquivos não devem gerar dados para ALI, pois este perfil se enquadraria em EE.
Ex.:
          Arquivos de Log (Desde que o arquivo seja gerado por outro aplicativo)

          Consulta Externa (CE): Apresentação de informações pela aplicação por meio de simples recuperação de dados. Não deve conter formulas matemáticas, cálculos de totais, não deve gerar dados derivados, não deve alimentar ALI e não altera o comportamento do sistema.
Ex.:
          Telas de Help.
          Telas de Login.
          Drop Down (Somente quando recolhe dados de ALI)

4.2.2. Calculo dos Pontos de Função

          Uma analise de requisitos mais detalhada para a uma formação de escopo mais especifica por tarefa vai ser fazer necessária para que seja possível aumentar a precisão da definição do tamanho do sistema por ponto de função.
          Uma boa analise de requisitos vai facilitar a identificação dos pontos de entrada e saída de acordo com os conceitos abordados. Erros na analise de requisitos vão fazer com que escopos sejam mau definidos e o tamanho do software seja definido de forma errada gerando erros na definição do prazo.


          Algumas considerações a serem feias na formação do escopo para se definir o tamanho do sistema.
          1. Determinar o tipo de contagem que será feita:
                    • Desenvolvimento
                    • Manutenção
                    • Aplicação
          2. Identifique todas as Entradas Externas
          3. Identifique todas as Saídas Externas
          4. Identifique todos os Arquivos Lógicos Internos que serão usados no projeto
          5. Identifique todos os Arquivos de Interface Externas que serão usados no sistema
          6. Identifique todas as Consultas Externas a serem utilizadas
          Cada item deve ser definido levando-se em consideração o nível de complexidade (SIMPLES, MÉDIO e COMPLEXO).

          Tabelas para definição do nível de complexidade das funções.

COMPLEXIDADE ENTRADA

(AR) Arquivos
Campos (TD)
1 a 4 Campos
5 a 15 Campos
16 ou mais Campos
0 ou 1 Arquivo
Simples
Simples
Médio
2 Arquivos
Simples
Médio
Complexo
3 ou mais Arquivos
Médio
Complexo
Complexo


COMPLEXIDADE SAÍDA

(AR) Arquivos
Campos (TD)
1 a 5 Campos
6 a 19 Campos
20 ou mais Campos
0 ou 1 Arquivo
Simples
Simples
Médio
2 ou 3 Arquivos
Simples
Médio
Complexo
4 ou mais Arquivos
Médio
Complexo
Complexo


COMPLEXIDADE ALI

(TR) Registros
Campos (TD)
1 a 19 Campos
20 a 50 Campos
51 ou mais Campos
1 Tipo de Registro
Simples
Simples
Médio
2 a 5 Tipo de Registros
Simples
Médio
Complexo
6 ou Mais Tipo de Registros
Médio
Complexo
Complexo


COMPLEXIDADE AIE

(TR) Registros
Campos (TD)
1 a 19 Campos
20 a 50 Campos
51 ou mais Campos
1 Tipo de Registro
Simples
Simples
Médio
2 a 5 Tipo de Registros
Simples
Médio
Complexo
6 ou Mais Tipo de Registros
Médio
Complexo
Complexo

COMPLEXIDADE CONSULTA

(AR) Arquivos
Campos (TD)
1 a 5 Campos
6 a 19 Campos
20 ou mais Campos
0 ou 1 Arquivo
Simples
Simples
Médio
2 ou 3 Arquivos
Simples
Médio
Complexo
4 ou mais Arquivos
Médio
Complexo
Complexo


TABELA PESOS FPA
Função
N° de Ocorrências
Complexidade
Peso
Total
Entrada Externa (EE)

Simples
x 3
=

Médio
x 4
=

Complexo
x 6
=

Total 1

=
Saída Externa (SE)

Simples
x 4
=

Médio
x 5
=

Complexo
x 7
=

Total 2

=
Arquivo Lógico Interno (ALI)

Simples
x 7
=

Médio
x 10
=

Complexo
x 15
=

Total 3

=
Arquivo Interface Externa (AIE)

Simples
x 5
=

Médio
x 7
=

Complexo
x 10
=

Total 4

=
Consultas Externas (CE)

Simples
x 3
=

Médio
x 4
=

Complexo
x 6
=

Total 5

=

          Obs.: Uma CE deve referenciar ao menos 1 ALI ou AIE para justificar o origem da informação.
          Siglas usadas nas tabelas: Arquivo Referenciado (AR), Tipo de Dados (TD) e Tipo de Registro (TR).

Exemplo de uso para calculo de ponto de função bruto (Extraindo do material do Professor Carlos Alberto).

          Suponha uma aplicação o qual foram identificados os itens:
                    - 3 EE – Entradas Externas (3 Simples)
                    - 2 SE – Saídas Externas (1 Simples, 1 Média)
                    - 4 ALI – Arquivos Lógicos (3 Simples, 1 Médio)
                    - 3 AIE – Arquivos Interface (2 Simples, 1 Médio)
                    - 5 CE – Consultas Externas (1 Simples, 3 Médias, 1 Complexo)

VERIFICANDO O PESO PARA CADA ITEM DO PROJETO
Função
N° de Ocorrências
Complexidade
Peso
Total
Entrada Externa (EE)
3
Simples
x 3
= 9
0
Médio
x 4
= 0
0
Complexo
x 6
= 0

Total 1

= 9
Saída Externa (SE)
1
Simples
x 4
= 4
1
Médio
x 5
= 5
0
Complexo
x 7
= 0

Total 2

= 9
Arquivo Lógico Interno (ALI)
3
Simples
x 7
= 21
1
Médio
x 10
= 10
0
Complexo
x 15
= 0

Total 3

= 31
Arquivo Interface Externa (AIE)
2
Simples
x 5
= 10
1
Médio
x 7
= 7
0
Complexo
x 10
= 0

Total 4

= 17
Consultas Externas (CE)
1
Simples
x 3
= 3
3
Médio
x 4
= 12
1
Complexo
x 6
= 6

Total 5

= 21
TOTAL DE PONTOS DE FUNÇÃO BRUTO
= 87