CENTRO UNIVERSITÁRIO METODISTA IPA

CURSO ADMINISTRAÇÃO DE EMPRESAS

MAURO LUÍS CAMARGO FRAGA

MÉTRICAS DE DESENVOLVIMENTO DE SISTEMAS

PARA GOVERNANÇA DE TI

PORTO ALEGRE
 635

2008
CENTRO UNIVERSITÁRIO METODISTA IPA
CURSO ADMINISTRAÇÃO DE EMPRESAS

MAURO LUÍS CAMARGO FRAGA

MÉTRICAS DE DESENVOLVIMENTO DE SISTEMAS

PARA GOVERNANÇA DE TI

Trabalho de Conclusão do
Curso de Administração de Empresas
do Centro Universitário Metodista IPA
Orientador: Jaime Gross Garcia

PORTO ALEGRE
 635

2008
 RESUMO

Em um ambiente competitivo, onde a tecnologia é fator de extrema

importância para a atuação no mercado, a Tecnologia da Informação (TI) tem papel
primordial na manipulação e comunicação de dados e informações. A constante
necessidade de atualização nem sempre é entendida pela área administrativo-
financeira como um investimento estratégico.

A Governança em TI é formada pela liderança em sua capacidade para

controlar, formular e implementar estratégias que utilizem a TI para a melhoria das
estratégias e dos objetivos da organização. Porém, para garantir que esses
resultados sejam alcançados é necessário que o gestor tenha controle do uso e
aplicação dos ativos tecnológicos, sendo primordial obter medições eficientes que
permitam analisar os impactos na Implantação de novas tecnologias.
O objetivo deste trabalho é verificar se os processos de desenvolvimento de
sistemas da instituição estudada, em relação a controle e medições, estão de acordo
com as práticas de Governança de TI. Para isso se faz necessário verificar quais
processos poderão ser monitorados e avaliados por medições capazes de
evidenciar sua eficiência e ou eficácia em relação aos objetivos propostos pela
governança. Nesse contexto é necessário estudar algumas ferramentas de gestão
da governança de TI entre Cobit e ITIL, gerar métricas específicas para o
desenvolvimento de sistemas com a finalidade de evidenciar os pontos mais críticos
e suscetíveis a mudanças em relação à forma que é medido e controlado
atualmente, fazer uma comparação da técnica que esta sendo utilizada com outra
técnica de medição de desenvolvimento de sistemas sugerida nesse caso a Análise
de Pontos de Função, e por fim, verificar a viabilidade da nova técnica proposta à
instituição estudada.

Palavras Chave: métricas, maturidade, framework, estratégia, alinhamento,

compliance, governança em TI.
 53

ABSTRACT

In a competitive environment, where technology is extremely important for

market acting, Information Technology has a main role in data and information
manipulation and communication. The constant need for being updated is not always
understood as a strategic investment by the administrative-financial field.

IT Governance is formed by the leadership in its capacity of controlling,

formulating and implementing strategies that use the IT for improving s strategies
and objectives of the organization. However, to guarantee that these results are
reached it is necessary that the manager controls the use and application of the
technological assets, being very important to obtain efficient measures that allow
analyzing the impact of new technologies implantation.

The objective of this thesis is to verify if, in what it refers to control and
measures, the software development processes are aligned with the GOVERNANÇA
practices. To reach that objective, it is necessary to verify which processes can be
monitored and evaluated by measures that are capable of pointing out its efficiency
and or effectiveness in relation to the objectives proposed by the IT Governance. In
this context, it becomes necessary to study Governance managing tools among
Cobit and ITIL, generate metrics specifically for software development aiming to
evidence the most critical and susceptible to changes in relation to the way it is
currently measured and controlled, make a comparison between the technique that is
being use and the another software development measuring technique in this case
the Function Point Analysis, and last, verify the feasibility of the new technique
proposed to the studied institution.

Key Words: metrics, maturity, framework, strategy, alignment, compliance, IT

governance.
 53

LISTA DE FIGURAS

Figura 1- triangulo de ferro..........................................................................................11

Figura 2 – Modelo de Governança de TI....................................................................17
Figura 3: Relacionamento entre Governança Corporativa e Governança de TI........18
Figura 4 – Modelo de alinhamento..............................................................................20
Figura 5: Estrutura BSC .............................................................................................21
Figura 6 - Cobit Framework – Domínios e Processos................................................23
Figura 7 - estrutura do ITIL.........................................................................................25
Figura 8 – Áreas primordiais.......................................................................................27
Figura 9 – níveis decisórios x sistemas .....................................................................28
Figura 10 – fases do processo de desenvolvimento..................................................31
Figura 11 - contagem de Pontos de Função...............................................................37
 53

LISTA DE QUADROS

Quadro 1 – complexibilidade funcional e contribuição...............................................40

Quadro 2 - Características gerais do sistema.............................................................42
Quadro 3 – formulas para calculo dos pontos de função...........................................43
Quadro 4 – Resumo das etapas da pesquisa.............................................................46
Quadro 5 – procedimento atual da medição...............................................................54
Quadro 6 – Documentação.........................................................................................55
Quadro 7 - contagem de pontos de função do projeto Agendamento........................60
Quadro 8 – fator de ajuste do sistema de agendamento............................................62
Quadro 9 – PF ajustados do sistema de agendamento.............................................63
Quadro 10 – contagem de PF do projeto Pós-Graduação.........................................66
Quadro 11 – Fator de ajuste da Pós-Graduação........................................................69
Quadro 12 – PF do sistema da Pós-Graduação.........................................................71
 53

SUMÁRIO

1 INTRODUÇÃO..................................................................................................................................................7
1.1 Problema de pesquisa......................................................................................................................................8
1.2 Objetivo da pesquisa.......................................................................................................................................8
1.2.1 Objetivo geral...............................................................................................8
1.2.2 Objetivos Específicos..................................................................................8
1.3 justificativa......................................................................................................................................................9
2 REFERENCIAL TEÓRICO...........................................................................................................................10
2.1 A GOVERNANÇA CORPORATIVA...........................................................................................................11
2.1.1 Finalidades da Governança Corporativa.................................................12
2.2 Sarbanes-Oxley (SOX)..................................................................................................................................13
2.2.1 Impactos da SOX sobre a TI......................................................................14
2.3 governança em ti...........................................................................................................................................15
2.3.1 Modelo de governança em TI....................................................................16
2.3.2 O Alinhamento Estratégico e Compliance...............................................17
2.4 FRAMEWORKS...........................................................................................................................................18
2.4.1 BSC (Balanced Scorecard)........................................................................19
2.4.2 CobiT...........................................................................................................21
2.4.3 ITIL...............................................................................................................24
2.5 ISO17799, BS7799 e ISO27001...................................................................................................................26
2.6 processos.......................................................................................................................................................26
2.6.1 Processos gerenciais................................................................................27
2.6.2 Processo de desenvolvimento de Software............................................31
2.6.3 Etapas do Processo de Desenvolvimento de Software.........................31
2.7 Medições ou métricas....................................................................................................................................36
2.7.1 O que medir.................................................................................................36
2.7.2 Contagem de Linhas de Código Fonte (LOCs).......................................37
2.7.3 Análise por Casos de uso ........................................................................37
2.7.4 Análise de Pontos por Função..................................................................39
2.7.5 Determinação do tipo de contagem.........................................................40
2.7.6 Identificação do escopo da contagem e fronteira da aplicação...........41
2.7.7 As funções do tipo de dado......................................................................42
2.7.8 As funções do tipo transação...................................................................42
2.7.9 Determinar a contagem de pontos de função não ajustados...............43
2.7.10 Determinar o fator de ajuste...................................................................44
2.7.11 Calculo dos pontos de função ajustados..............................................46
 53

3 METODOLOGIA............................................................................................................................................47
3.1 Caracterização da Pesquisa...........................................................................................................................47
3.2 Limitação da pesquisa...................................................................................................................................48
3.3 descrição do desenvolvimento da pesquisa...................................................................................................49
4 ESTUDO DE CASO.........................................................................................................................................51
4.1 Histórico da instituição..................................................................................................................................51
4.1.1 O setor de desenvolvimento.....................................................................54
4.2 método de medição atual...............................................................................................................................55
DESCRIÇÃO......................................................................................................................................................58
4.2.1 Documentação............................................................................................58
4.3 método de medição proposto.........................................................................................................................60
4.3.1 Método pontos de função.........................................................................60
4.4 Aplicação do método.....................................................................................................................................61
4.5 descrição do projeto Sistema de agendamento..............................................................................................62
4.6 Tipo de contagem..........................................................................................................................................63
4.7 Escopo da contagem e fronteira da aplicação...............................................................................................63
4.8 contagem da função de dados e funções transacionais.................................................................................64
4.9 Cálculo do Fator de Ajuste............................................................................................................................65
4.9.1 Calcular Número de Pontos de Função Ajustados................................66
4.9.2 Resultados das medições do projeto de agendamento........................67
4.9.3 Descrição do projeto de Inscrição dos cursos de Pós-Graduação......68
4.9.4 Tipo de contagem.......................................................................................68
4.9.5 Escopo da contagem e fronteira da aplicação........................................69
4.9.6 IDENTIFICAÇÃO E CONTAGEM DA FUNÇÃO DE DADOS E FUNÇÕES
TRANSACIONAIS.................................................................................................69
4.10 Cálculo do Fator de Ajuste..........................................................................................................................71
4.10.1 Calcular Número de Pontos de Função Ajustados..............................71
4.10.2 Resultados das medições do projeto do formulário da Pós-
Graduação............................................................................................................73
4.10.3 Relatório comparativo entre os métodos..............................................73

5 CONCLUSÃO..................................................................................................................................................77

6 REFERÊNCIAS...............................................................................................................................................80

7 ANEXOS...........................................................................................................................................................82
 53

1 INTRODUÇÃO

Em um ambiente competitivo, onde a tecnologia é fator de extrema

importância para a atuação no mercado, a Tecnologia da Informação (TI) tem papel
primordial na manipulação e comunicação de dados e informações. Conforme
O’Brien (2004), existem formas diferentes para as organizações entenderem e
utilizarem a tecnologia da informação; uma maneira é optar pela utilização
estratégica dos sistemas de informação e outra é utilizarem os recursos de TI
apenas como uma ferramenta eficiente para as operações do seu dia-a-dia.
A TI tem necessidade de constantes atualizações e nem sempre isto é
entendido pela área administrativo-financeira, o que coloca o gerente de TI em uma
posição de constante impasse, mediante a necessidade da atualização e a
mensuração dos gastos, estabelecimento de metas eficientes, para o desempenho
da TI. Não adianta simplesmente buscar investimentos para a área, é necessário
justifica-los, e fazer com que os recursos estejam realmente servindo para os
propósitos estabelecidos no plano estratégico das empresas. Segundo Wood e
Picarelli (2004)

Os sistemas tradicionais de medição costumam focar exclusivamente

indicadores financeiros e de custos. Eles devem mudar para apoiar os
processos de melhoria e atender aos novos imperativos de competitividade
(WOOD e PICARELLI, 2004, p. 187).

Conforme WEILL E ROSS (2006), empresas de melhor desempenho têm

também melhores retornos sobre seus investimentos em TI, em até 40%. Extrair
maior valor da TI é uma competência organizacional e todos os líderes na empresa
precisam desenvolver essa importância.
 53

1.1 PROBLEMA DE PESQUISA

Os processos de desenvolvimento de sistemas de TI do Centro Universitário

Metodista IPA, em relação a controle e medições, estão de acordo com as práticas
de governança de TI?

1.2 OBJETIVO DA PESQUISA

O objetivo da pesquisa será brevemente explicado abaixo no objetivo geral e

detalhado nos objetivos específicos.

1.2.1 Objetivo geral

O objetivo geral deste trabalho é analisar o nível de maturidade dos

processos de desenvolvimento de sistemas da instituição citada, em relação as
práticas de controle e medições para a governança em TI, que capacitam o
alinhamento desses processos com os objetivos estratégicos da instituição.

1.2.2 Objetivos Específicos

Para alcançar o objetivo geral os objetivos específicos estão divididos em

três etapas:
 53

• Verificar quais processos poderão ser monitorados e

avaliados por medições capazes de evidenciar sua eficiência e ou
eficácia em relação aos objetivos esperados pela governança;
• Gerar novas métricas para o desenvolvimento, com a
finalidade de evidenciar os pontos mais críticos e suscetíveis a
mudanças, em relação à forma como é medido e controlado atualmente;
• Verificar a viabilidade da adoção das práticas
recomendadas à Instituição estudada.

1.3 JUSTIFICATIVA

O Centro Universitário Metodista IPA necessita de uma estrutura de TI capaz

de suprir as necessidades tecnológicas, de forma competitiva, e voltada aos
interesses previstos em seu planejamento estratégico.
WEILL E ROSS (2006) afirmam que para a obtenção desses resultados, é
necessário uma TI de governança acima da média.

Essas empresas de desempenho superior auferem proativamente o valor de

TI de diversas maneiras:

• Deixam claros as estratégias de negócios e o papel da TI em

concretizá-las.

• Mensuram e gerenciam o que se gasta e o que se ganha com a TI.

• Atribuem responsabilidades pelas mudanças organizacionais

necessárias para tirar proveito dos novos recursos de TI

• Aprendem com cada implementação tornando-se mais hábeis em

compartilhar e reutilizar sus ativos de TI (WEILL E ROSS, 2006, p. 2).

Sendo acadêmico do curso de Administração de Empresas, funcionário da

Gestão de Tecnologia da informação da instituição e ter conhecimento da
necessidade acima, sugiro o estudo das métricas de TI para que se possa suprir
essas necessidades em relação aos sistemas desenvolvidos na instituição
auxiliando assim a obtenção dos resultados esperados.
 53

2 REFERENCIAL TEÓRICO

Grande número de iniciativas de TI fracassam e não proporcionam os

resultados esperados pelas empresas. Segundo pesquisa publicada na revista Info
Corporate, de novembro de 2006, mais de 80% dos projetos de tecnologia saem
perigosamente dos trilhos, com estouro de orçamento e prazos, conforme Fé (2006).
Segundo Phillips e Luckey (2006), existem três vetores atuantes sobre um
projeto, esse tripé é conhecido como triângulo de ferro e está representado na
figura 1.

Figura 1- triangulo de ferro

Fonte: Phillips e Luckey (2006)

Para que um projeto seja bem sucedido, cada lado desse triângulo deve
permanecer em equilíbrio com os outros dois.
 53

Com base num estudo feito junto a 250 empresas de todo o mundo, WEILL
E ROSS (2006) afirmam que o valor de negócios de TI resulta diretamente de uma
governança de TI eficaz. Cientes das forças internas conflitantes, essas empresas
estruturam uma governança capaz de harmonizar os objetivos de negócio à
abordagem e os mecanismos de governança, às metas e os indicadores de
desempenho. O efeito disso traduz-se em uma boa concepção de governança,
permitindo que as empresas tenham resultados superiores em seus investimentos
de TI.

2.1 A GOVERNANÇA CORPORATIVA

Conforme Lamb (2005), o termo governança corporativa não é novo,

começou a ganhar força no mercado quando foi divulgado o documento Blue Ribbon
Report pela Wall Street, nos Estados Unidos, em 1999, alertando para o fato que
relatórios financeiros de empresas com ações cotadas na bolsa demonstravam mais
desejos do que realidades. Este documento recomendava uma série de práticas de
transparência que deveriam ser adotadas pelas empresas, de modo a permitir que
os acionistas tivessem mais controle sobre o dinheiro investido. Quando as fraudes
da Enron se tornaram públicas, em 2002, o documento virou a comentada e temida
lei Sarbanes-Oxley, conhecida também pelo apelido SOX, e a legislação, além de
impor uma série de regras para a prestação de contas corporativas, e assim a
adoção de métodos de governança corporativa, virou uma obrigação para empresas
americanas de capital aberto. Bocater et al. (2007) conceitua Governança
Corporativa como:

Governança Corporativa é o sistema pelo qual as sociedades são dirigidas

e monitoradas, envolvendo os relacionamentos entre Acionistas/Cotistas,
Conselho de Administração, Diretoria, Auditoria Independente e Conselho
Fiscal. As boas práticas de governança corporativa têm a finalidade de
aumentar o valor da sociedade, facilitar seu acesso ao capital e contribuir
para a sua perenidade (BOCATER. et al. 2007, p. 6).
 53

2.1.1 Finalidades da Governança Corporativa

A Governança Corporativa tem por finalidade aumentar o valor da sociedade

e facilitar o acesso do capital, contribuindo para obtenção de resultados positivos
para a empresa, através de um conjunto de práticas conhecidas como Princípios
Básicos de Governança ou Práticas de Boa Governança.
O Instituto Brasileiro de Governança Corporativa (IBGC) é responsável pela
publicação do Código das Melhores Práticas de Governança Corporativa e, segundo
Bocater et al. (2007), os princípios básicos que inspiram este Código são:

a) Transparência: é o princípio que norteia a confiança entre

os envolvidos com a empresa, deixando-os a par de todas as decisões
tomadas e sua fiscalização, através de regras e regulamentos
conhecidos. Assim, toda a informação governamental é livremente
disponível e livremente acessadas por aqueles que possam ser afetados
por tais decisões e pelos trabalhos de fiscalização. Para Bocater et al.
(2007) transparência é:

Mais do que ‘a obrigação de informar’, a Administração deve cultivar o

‘desejo de informar’, sabendo que da boa comunicação interna e externa,
particularmente quando espontânea, franca e rápida, resulta um clima de
confiança, tanto internamente, quanto nas relações da empresa com
terceiros. A comunicação não deve restringir-se ao desempenho
econômico-financeiro, mas deve contemplar também os demais fatores
(inclusive intangíveis) que norteiam a ação empresarial e que conduzem à
criação de valor (BOCATER, et al. 2007, p. 9).

b) Eqüidade é o direito assegurado à igualdade entre todos

os grupos nos objetivos da sociedade, ou seja, o desenvolvimento
econômico, financeiro, de reconhecimento e ou quaisquer resultados,
deverá ser compartilhado por todos os grupos sociais. Assim, as
decisões devem também assegurar a todos os membros da sociedade o
direito de participação. Para Bocater et al. (2007), a eqüidade
caracteriza-se como:
 53

Tratamento justo e igualitário de todos os grupos minoritários, sejam do

capital ou das demais ‘partes interessadas’ (stakeholders), como
colaboradores, clientes, fornecedores ou credores. Atitudes ou políticas
discriminatórias, sob qualquer pretexto, são totalmente inaceitáveis
(BOCATER, et al. 2007, p 10).

c) Prestação de Contas (accountability) está ligada

diretamente à transparência em uma gestão empresarial, pois não se
trata de apenas prestar contas das finanças e sim de deixar claro quais
são as ações em que a empresa está envolvida. Segundo Bocater et al.
(2007, p 10).

Os agentes da governança corporativa devem prestar contas de sua

atuação a quem os elegeu e respondem integralmente por todos os atos
que praticarem no exercício de seus mandatos (BOCATER, et al. 2007, p
10).

d) Responsabilidade Corporativa é um conceito que reúne a

responsabilidade societária, a fiscal, a trabalhista, a social, a ambiental e
a comunitária, podendo ser considerada como todo o processo de gestão
que leva em consideração os princípios de responsabilidade dos
stakeholders com a sociedade e/ou meio em que estão inseridos.
Bocater et al. (2007) afirmam que:

Conselheiros e executivos devem zelar pela perenidade das organizações

(visão de longo prazo, sustentabilidade) e, portanto, devem incorporar
considerações de ordem social e ambiental na definição dos negócios e
operações. Responsabilidade Corporativa é uma visão mais ampla da
estratégia empresarial, contemplando todos os relacionamentos com a
comunidade em que a sociedade atua. A "função social" da empresa deve
incluir a criação de riquezas e de oportunidades de emprego, qualificação e
diversidade da força de trabalho, estímulo ao desenvolvimento científico por
intermédio de tecnologia, e melhoria da qualidade de vida por meio de
ações educativas, culturais, assistenciais e de defesa do meio ambiente.
Inclui-se neste princípio a contratação preferencial de recursos (trabalho e
insumos) oferecidos pela própria comunidade (BOCATER, et al. 2007, p 10).

2.2 SARBANES-OXLEY (SOX)

 53

Conforme Tapajós (2007b), em 30 julho de 2002, o presidente George W.

Bush assinou o Ato Sarbanes-Oxley, que muda de forma radical as leis aplicadas a
empresas que têm ações negociadas na bolsa americana. Em 2001 e 2002,
empresas gigantes como Enron e o Worldcom foram forçadas a declarar a falência.
Fraudes contábeis e outras irregularidades foram reveladas em outras empresas,
tais como Adelphia e Global Crossing. Após esses escândalos, o governo americano
implementou uma legislação que ampliou os poderes da Securities and Exchange
Commission (SEC), órgão regulador do mercado financeiro americano, e aumentou
consideravelmente a responsabilidade da administração das empresas.
A SOX não é utilizada para regular atos da governança corporativa em
instituições financeiras; para essa função existe um código específico chamado
Basiléia.
Fernandes e Vladimir (2006) explicam que o acordo Basiléia II foi
estabelecido pelo Bank for international settlements (BIS), sediado na cidade suíça
de Basiléia. Esse acordo estipula requisitos de capital mínimo para as instituições
financeiras, em função dos seus riscos de crédito. Essa lei tem impactos similares à
SOX sobre a TI, mas não será abordada com profundidade, por regular apenas
instituições financeiras.

2.2.1 Impactos da SOX sobre a TI

Segundo Tapajós (2007a), em suas seções 404, 407, 408 e 409, a SOX
trata sobre os aspectos de controle interno, fiscalização da SEC sobre informação
pública, código de ética para diretores financeiros e publicação de alterações
operacionais e/ou financeiras. Determina a emissão de relatório especial, com
parecer, entregue à SEC, que ateste a realização anual de avaliação e de controles
e processos internos, que são a base de relatórios financeiros. Na seção 802, fala
sobre as penalidades criminais pela alteração de documentos e, na seção 90, sobre
a responsabilidade corporativa pelos relatórios financeiros.
Segundo Cavalcante et al. (2005), tecnicamente, a SOX é aplicável também
a empresas não americanas com ações no mercado acionário dos Estados Unidos
 53

(bolsa NYSE, AMEX e Nasdaq), e impõe regras de governança corporativa, entre as

quais a certificação das demonstrações financeiras pelos Chief Executive Officer
(CEOs) e pelos Chief Financial Officer (CFOs) das empresas.
De acordo com Fernandes e Vladimir (2006), a área de TI, ciente de que os
aplicativos transacionais da empresa, como os geradores de fatores contábeis e
financeiros, devem:

• Ter disponibilidade para acesso e emissão de relatórios de resultados

financeiros e contábeis;

• Armazenar os dados e informações de forma adequada e com

segurança;

• Ter a possibilidade de implementar trilhas de auditora e verificação de

processos (FERNANDES;VLADIMIR, 2006, p. 10).

2.3 GOVERNANÇA EM TI

A boa governança em TI é formada pela liderança, em sua capacidade para

controlar, formular e implementar estratégias que utilizem a TI para a melhoria das
estratégias e dos objetivos da organização. Essas estratégias de TI podem seguir
inúmeras práticas contidas em vários Frameworks existentes no mercado; cada um
desses pacotes traz um conjunto de práticas, ferramentas, processos e modelos,
para auxiliar o Gestor de Tecnologia da Informação, tratado por Chief Information
Oficer (CIO), para implementar e gerenciar os ativos, processos e necessidades da
TI de sua empresa. Os CIOs não realizam apenas atividades referentes aos serviços
de informação, mas, também se concentram no planejamento e estratégia de
negócios/TI, trabalhando em conjunto com os CEOs e outros altos executivos,
desenvolvendo usos estratégicos da tecnologia da informação para tornar a
empresa mais competitiva no mercado. Em muitas empresas, o cargo de CIO é
ocupado por executivos oriundos de funções ou unidades de negócios externas à
área de Sistemas de Informação. Esses CIOs enfatizam que o principal papel da
tecnologia da informação é ajudar a empresa alcançar seus objetivos estratégicos
de negócios, conforme O’Brien (2004). Definição de Governança em TI, segundo
Tapajós (2007a):
 53

É uma estrutura de relacionamentos e processos para dirigir e controlar a

organização a fim de atingir os objetivos desta organização, adicionando
valor, ao mesmo tempo que equilibra os riscos em relação ao retorno da TI
e seus processos (TAPAJÓS, 2007, p. 6).

Participação e envolvimento da alta direção na TI é fundamental, explica

O’Brien (2004).

O envolvimento dos diretores e gerentes de unidades na gestão da TI exige

o desenvolvimento de estruturas de governança corporativa, que incentivem
sua participação ativa no planejamento e controle dos usos da TI. Dessa
forma, muitas organizações tem desenvolvido decisões de TI que afetam
suas unidades. Isso ajuda os gerentes a evitarem os problemas de
desempenho dos Sistemas Informatizados[...] sem esse alto grau de
envolvimento, os gerentes não podem esperar melhorar o valor estratégico
da tecnologia da informação para os negócios (O’BRIEN, 2004, p. 404).

2.3.1 Modelo de governança em TI

Fernandes e Vladimir (2006) sugerem o modelo apresentado na figura 2,

pois esse pode ser adaptado a qualquer organização, sendo que seus componentes
devem ser encarados como peças a serem encaixadas, construídas e implantadas

Figura 2 – Modelo de Governança de TI

Fonte: Fernandes e Vladimir (2006, p. 33)
 53

de acordo com as prioridades, necessidades e disponibilidades da organização. Tem

como base um fluxo de mão dupla que segue o Ciclo da Governança de TI.
O ponto de partida para o modelo acima, proposto por Fernandes e Vladimir
(2006) é o alinhamento estratégico, pois nele são considerado a criação de valor
para o negócio e a aderência a requisitos de compliance.

2.3.2 O Alinhamento Estratégico e Compliance

Fernandes e Vladimir (2006) definem o alinhamento estratégico como o

processo de transformar a estratégia do negócio em estratégia e ações de TI,
garantindo que os objetivos de negócios sejam apoiados.
Segundo King (1978 apud BRODBACK, 2002), o alinhamento estratégico
em TI pode ser definido como a adequação estratégica entre as estratégias e
objetivos do negócio com as estratégias, objetivos e funções de TI.

O alinhamento ou coordenação entre Plano Estratégico do Negócio (PEN),

e o Plano Estratégico de Tecnologia de Informação (PETI), é alcançado
quando o conjunto de estratégias de sistema de informação (SI), composto
de sistemas, objetivos, obrigações e estratégias, é derivado do conjunto
estratégico organizacional, composto de missão, objetivos e estratégias
(KING, 1978 apud BRODBACK, 2002, p. 69) .

Do alinhamento entre o PETI e o PEN resultará um modelo de

relacionamento similar ao proposto por WEILL E ROSS (2006), que está demostrado
na figura 3; este modelo associa as governanças corporativas e de TI.

Figura 3: Relacionamento entre Governança Corporativa e Governança de TI

Fonte: Weill e Ross (2006, p. 6)
 53

Segundo WEILL E ROSS (2006) existem cinco decisões-chave para o

alinhamento estratégico e ações de TI; essas decisões estão ligadas entre si. São
elas:

• princípios de TI – esclarecem o papel de negócio da TI;

• arquitetura de TI – define os requisitos de integração e
padronização;
• infra-estrutura de TI – determina os serviços
compartilhados e de suporte;
• necessidade de aplicações de negócio - especifica a
necessidade comercial de aplicações de TI, compradas ou desenvolvidas
internamente;
• investimentos e priorização de TI – escolha de quais
iniciativas devem ser financiadas e quando se deve gastar.

Estas decisões devem manter um inter-relacionamento para que haja uma

governança eficaz; desta forma, os princípios de TI motivam a arquitetura, que por

sua vez leva à infra-estrutura. A infra-estrutura habilita o desenvolvimento com base

nas necessidades do negócio, especificadas freqüentemente pelos processo

comerciais, e, finalmente, os investimentos em TI (contratação de processos de

investimento e priorização de TI), devem ser motivados pelos princípios, pela

arquitetura, pela infra-estrutura e pelas necessidades de aplicações.

2.4 FRAMEWORKS

Entre as principais soluções que surgiram para melhor atender o CIO, em

sua incessante busca pelas melhores prática de TI, tem-se: o BSC, Cobit, ITIL,
ISO17799, BS7799 e ISO270001. Segundo Fernandes e Vladimir (2006), a
 53

utilização parcial ou integral de cada um dos frameworks existentes dependerá

exclusivamente da estratégia de cada empresa. Abaixo, na figura 4, temos a
composição de alguns dos frameworks citados, compondo um caminho para TI fazer
o alinhamento com a estratégia da empresa, conforme Tapajós (2007a).

Figura 4 – Modelo de alinhamento

Fonte: Tapajos (2007a, p. 6)

2.4.1 BSC (Balanced Scorecard)

Conforme descrito por Prado (2002), o Balanced Scorecard (BSC) é um dos

melhores métodos de gestão que apareceu nos últimos anos, foi apresentado ao
mundo em fevereiro de 1992, por Robert Kaplan e David Norton, através da
publicação do artigo “The Balanced Scorecard – Measeures that drive performance”
(Balanced Scorecard – medidas que impulsionam o desempenho), na revista
Harvard Bussiness.
Foi criada para resolver problemas de avaliação de desempenho, porém a
ferramenta se mostrou capaz na ajuda para implementação de novas estratégias
 53

nas empresas e na criação de valor para o cliente, transformando-se numa

ferramenta gerencial e estratégica de sucesso. O BSC visa atender uma das
grandes preocupações dos gerentes, de acompanhar e assegurar que os objetivos
da estratégia da empresa sejam executados e alcançados.
A utilização única de medições financeiras é inadequada para a avaliação da
trajetória das empresas da era da informação, para geração de valor futuro de
investimento em clientes, fornecedores, processos, tecnologia e inovação. Assim, o
Balanced Scorecard (BSC) faz a avaliação e gestão de uma organização, não
restringindo as medidas tradicionais de resultados e performance financeira, mas
sendo complementada com medidas de outras três dimensões, que focam a atenção
na satisfação dos clientes, processos internos e a capacidade de inovação, que
poderão influir positivamente nas atividades da empresa.
O BSC promove o alinhamento dos objetivos estratégicos com indicadores
de desempenho, metas e planos de ação, construindo um Mapa Estratégico. O
mapa estratégico é uma representação visual das relações de causa e efeito entre
os componentes da estratégia de uma organização.
Conforme Kaplan e Norton (1997), os objetivos e medidas do BSC são
derivados da visão e estratégia da empresa, focalizando o desempenho
organizacional sob quatro perspectivas: financeira, do cliente, dos processos
internos e de aprendizado e crescimento, como é mostrado na figura 5.

Figura 5: Estrutura BSC

Fonte: Kaplan e Norton, 1997, p. 10.
 53

2.4.2 CobiT

O Control Objectives for Information and related Technology (Cobit), é um

guia das melhores práticas de/para auditoria e governança de TI, desenvolvido pela
Information Systems Audit and Control Association (ISACA); não se trata de uma
metodologia, mas sim de um modelo onde o CIO pode fortalecer a sua capacidade
de observação e controle do ambiente, com informações sofisticadas sobre o nível
de maturidade de cada um dos processos da TI. A partir de sua versão 3, elaborada
em 2000, o Information Tecnologic Governance Institute (ITGI) começou a incluir
normas e guias, associadas à gestão no Cobit. Então, passa a ser o principal editor
desse framework.
Um modelo de maturidade é um método de avaliação, que permite a uma
organização graduar a sua maturidade, para um determinado processo, de não
existente (0) até otimizado (5), comparando assim seus processos com as melhores
práticas e padrões do mercado. Dessa forma, as deficiências podem ser
identificadas e ações específicas podem ser definidas, para se atingir as posições
desejadas.
O Cobit não diz o que fazer, mas aponta o que deve ser melhorado. Isto é,
deve ser encarado como positivo, pois deixa a empresa livre para usar a solução
que melhor resolverá seu problema, deixando o Gerente escolher quais outros
frameworks poderão ser utilizados junto ao Cobit, para potencializar seu poder. É
bastante comum nas empresas a utilização do Cobit, para o mapeamento e controle
da maturidade dos processos, o ITIL, para o gerenciamento da infra-estrutura, Six
Sigma, na qualidade, e BS7799 e/ou ISO27001 e ISO17799 para controle de
segurança.
Com a finalidade de prover as informações que a organização necessita
para atingir seus objetivos, o Cobit traz, em sua quarta versão, 34 processos,
conforme monstrado na figura 6.
53
 53

Figura 6 - Cobit Framework – Domínios e Processos

Fonte: Adaptado de ITGI (2004, p. 15

Conforme pode ser observado na figura, o Cobit está dividido em quatro

grupos distintos, denominados de Domínios. A função de cada um desses domínios
é explicada a seguir, conforme ITGI (2004):

a) Planejamento e Organização: neste domínio são

abordadas as estratégias e táticas de TI, identificando como melhor
poderá contribuir para alcançar os objetivos do negócio; essa visão
estratégica deverá ser planejada e comunicada ao CEO, de diferentes
perspectivas. Após as adequações, a infra-estrutura tecnológica deve
ser definida e implementada.
 53

b) Aquisição e Implementação: neste domínio deverá ser

formulada a estratégia de TI, através da identificação de soluções
necessárias que deverão ser desenvolvidas ou adquiridas, sendo que
essas deverão ser implementadas e integradas aos processos de
negócio. Nesse mesmo domínio são tratadas as mudanças e
manutenções nos sistemas existentes.
c) Entrega e Suporte: domínio em que ocorre o
processamento real de dados pelos sistemas de aplicação, ou seja, os
produtos reais dos serviços requeridos. Para que estes serviços possam
ser produzidos, é preciso que os processos de suporte necessários
existam, desde operações tradicionais de segurança a aspectos de
continuidade.
d) Monitoração: este domínio está focado nos processos de
TI a serem avaliados, regularmente, nos aspectos de sua qualidade e
em conformidade com os requerimentos de controle. Este domínio, além
disto, direciona a vigilância da gerência nos processos de controles da
organização e fornece garantia independente pela auditoria interna ou
externa, conforme.

2.4.3 ITIL

ITIL (Information Technology Infrastructure Library) significa Biblioteca de

Infra-estrutura de Tecnologia da Informação, criada pela Secretaria de Comércio -
CCTA (Central Computer and Telecommunications Agency) do governo inglês, junto
a consultores, especialistas e doutores da área de TI, um centro governamental para
sistemas de informações. Esta biblioteca é formada por módulos que trazem um
conjunto de melhores práticas, retiradas de empresas públicas e privadas, fazendo
dela o mais completo e acessível guia para gerentes de serviços de TI (ITSMF,
2006). O ITIL é um conjunto de livros que busca promover a gestão, com foco no
cliente a na qualidade dos serviços de tecnologia da informação (TI); tornou-se a
base padrão para a norma BS 15000, que se tornou um anexo da norma ISO 20000.
 53

O ITIL endereça estruturas de processos para a gestão de uma organização

de TI, apresentando um conjunto compreensivo de processos e procedimentos
gerenciais, organizados em disciplinas, com os quais uma organização pode fazer
sua gestão tática e operacional para alcançar o alinhamento estratégico com os
negócios.
Atualmente, o ITIL é o modelo mais utilizado em atendimentos de serviços
de TI, considerando todos os hardwares, softwares e telecomunicações, garantindo
os níveis de serviços acordados por clientes internos e externos.
O ITIL traz algumas mudanças de paradigma, tais como: fazer o negócio
focar no valor e não no custo, repensando toda a cadeia que envolve a prestação de
serviços, e não de forma fragmentada. A figura 7 mostra a estrutura do ITIL.

Figura 7 - estrutura do ITIL

Fonte: Tapajós (2007b)

A figura 7 mostra o inter-relacionamento dos diversos módulos do ITIL.

Esses módulos, segundo ITSMF (2005), foram criados considerando que o ITIL é
um conjunto de melhores práticas, que buscam organizar tópicos relevantes ao
gerenciamento da infra-estrutura, para que a área de TI seja vista como uma área
que presta serviço ao negócio.
 53

2.5 ISO17799, BS7799 E ISO27001

Segundo Dromos (2006), ISO17799 e BS7799 são políticas da segurança e

procedimentos dos padrões. O padrão foi sabido inicialmente como um British
Standard (BS), chamado padrão britânico 7799, desenvolvido pela instituição
britânica dos padrões. Mais tarde, se transformou no padrão do International
Electrotechnical Commission IEC 17799, da International Organization for
Standardization (ISO), quando foi adotado pelo comitê técnico do IEC do ISO para o
uso internacional. Elas cuidam de temas que vão desde a segurança física do
ambiente, passando pelas pessoas, e detalhando cuidados essenciais em temas
como rede, aplicativos e acessos remotos.
Tal comitê é chamado ISO IEC Joint Technical Committee JTC 1 e é
atualmente responsável por toda informação a respeito dos padrões da tecnologia, e
o BS7799 consulta especificamente o padrão da gerência da segurança da
informação, aprovado formalmente durante o ano 2000. Esse padrão define um jogo
de práticas de gerência recomendadas pela segurança da informação
A norma ISO 27001:2005 é a evolução natural da norma BS7799-2:2002,
um padrão britânico, que trata da definição de requisitos para um Sistema de Gestão
de Segurança da Informação. O padrão foi incorporado pela ISO, Instituição
internacional com sede na Suíça, que cuida do estabelecimento de padrões
internacionais de certificação em diversas áreas.

2.6 PROCESSOS

Processo, no latim procedere, é termo que indica a ação de avançar, ir para

frente (pro+cedere). É conjunto seqüencial e peculiar de ações que objetivam atingir
uma meta. É usado para criar, inventar, projetar, transformar, produzir, controlar,
manter e usar produtos ou sistemas. Segundo Galante e Pow (1999), “processo é a
seqüência sistemática de operações para produzir um resultado específico”.
 53

2.6.1 Processos gerenciais

Os processos gerenciais consistem, basicamente, em gerenciar recursos

materiais e humanos.
Qualquer empresa independente de seu tamanho, é composta pelas
seguintes áreas: produção, vendas e marketing, recursos humanos e uma área
financeira e contábil, conforme é mostrado na figura 8. Estas áreas têm funções
primordiais para que a empresa possa realizar a produção de bens ou serviços,
conforme o objetivo de seu negócio.
 53

Figura 8 – Áreas primordiais

Fonte: Batista (2006, p. 38)

Segundo Batista (2006), é difícil que apenas um sistema satisfaça todas as

necessidades de cada atividade, de cada uma das áreas citadas acima, pois essas
áreas possuem diferentes funções com diferentes níveis de responsabilidade, mas
que precisam estar inteiradas sobre as informações geradas por cada uma delas.
Sendo assim, dentro do sistema de informações da organização, existe a
necessidade da composição de subsistemas especialistas.
Para Batista (2006), os processos gerenciais são traduzidos para os
sistemas de informação, para melhorar o controle interno da empresa em seu tempo
e de acordo com a resposta do mercado, permitindo assim uma maior eficácia.
Dentro do contexto dos processos gerenciais, os sistemas são classificados de
acordo com os problemas que resolvem, sendo eles divididos em três níveis,
conforme Rezende e Abreu (2008) demostram na figura 9.
 53

Figura 9 – níveis decisórios x sistemas

Fonte: adaptado de Rezende e Abreu (2001)

A figura 9 mostra a relação dos sistemas e os níveis decisórios dentro de

uma organização. Esta relação é explicada logo abaixo:

a) Sistemas de níveis estratégicos:

Para Laudon e Laudon (2006), os sistemas que atuam em nível estratégico

têm como sua principal preocupação compatibilizar as mudanças no ambiente
externo com a capacidade da organização, ajudando assim aos diretores a atacar e
enfrentar as questões estratégicas e tendências de longo prazo, tanto na empresa
ou no ambiente externo.
Para Rezende e Abreu (2001), são responsáveis pelo processamento de
dados em um nível macro, filtrando-os das operações das funções empresariais da
organização, considerando o meio ambiente interno e/ou externo, visando auxiliar no
processo de tomada de decisão da alta administração, transformando assim os
dados e transações gerenciais em informações estratégicas. Os Sistemas de
Informação Estratégicos (SIE), também são conhecidos como Sistemas de
 53

Informação Executiva ou Sistemas de Suporte à decisão, ou ainda, pela sigla em

inglês EIS ou Executive Information Systems.

b) Sistemas táticos ou gerenciais:

Laudon e Laudon (2006) afirmam que os sistemas táticos tem a

característica de produzirem relatórios de forma instantânea^, atendendo assim às
atividades de monitoração, controle, tomada de decisões e procedimentos
gerenciais.
Segundo Rezende e Abreu (2001), os Sistemas de Informação Gerenciais
(SIG), também chamados de Sistemas de Apoio à Gestão Empresarial, ou Sistemas
Gerenciais, contemplam o processamento de grupos de dados operacionais e
transações operacionais, transformando-os em informações agrupadas para gestão.
Esses sistemas trabalham de forma sistemática com os dados agrupados das
funções empresarias da empresa, auxiliando a tomada de decisão do corpo gestor
ou gerencial das unidades departamentais em sinergia com as demais.

c) Sistemas de conhecimento:

Seu propósito é auxiliar a empresa a integrar tecnologia ao negócio e

controlar o fluxo de documentos. Esses sistemas estão sob forma de estações de
trabalho e automação de escritório, Laudon e Laudon (2006).

d) Sistemas operacionais

Conforme Laudon e Laudon (2006), o principal propósito de um sistema de

nível operacional é responder às perguntas de rotina e acompanhar o fluxo de
transações pela organização. Exemplo: transações bancárias efetuadas em um
terminal de um banco ou o número de horas que um trabalhador fez dentro de um.
Para Rezende e Abreu (2001), os Sistemas de Informações Operacionais
(SIO) controlam dados detalhados da funções empresariais básicas ao
funcionamento da empresa, auxiliando o corpo técnico nas unidades
departamentais; esses sistemas contemplam o processamento de operações e
transações rotineiras do quotidiano, de forma detalhada em cada um dos seus
 53

procedimentos. Os SIOs também são chamados de Sistemas de Apoio as

Operações Empresariais, Sistemas de Controle ou Sistemas de Processamento de
Transações (SPT).

2.6.2 Processo de desenvolvimento de Software

Um processo de desenvolvimento de software é um conjunto de atividades,

parcialmente ordenadas, com a finalidade de obter um produto e/ou serviço capaz
de satisfazer as necessidades, para o qual está sendo desenvolvido. Para que esse
desenvolvimento também esteja em conformidade com as diretrizes da Governança
de TI de uma empresa, é necessário que esse produto final, além de satisfazer as
necessidades, consiga também suprir as informações necessárias para alimentar os
frameworks de TI. Para Tapajós (2007), o mapeamento dos controles da SOX e o
seu relacionamento com o Cobit devem estar atrelados aos processos de TI.

2.6.3 Etapas do Processo de Desenvolvimento de Software

Conforme Fernandes e Vladimir (2006), o relacionamento entre o ciclo de

vida de desenvolvimento e manutenção de produtos, assim como a garantia de seu
funcionamento e da sua aderência às especificações devem ser agrupadas nas
seguintes áreas:
a) desenvolvimento de requisitos: esta área deverá gerar,
analisar, definir e validar requisitos do cliente, assim como seus
desdobramentos, para os requisitos do produto e dos seus
componentes, em conformidade com as necessidades dos grupos
interessados;
 53

b) Gestão de Requisitos: esta área deve gerenciar os

requisitos técnicos, e não técnicos, absorvidos ou gerados por um
projeto, identificando as inconsistências em relação aos planos e
produtos do projeto, e tratando de forma adequada as mudanças
necessárias e seus impactos.
c) Solução Técnica: área definida para projetar, desenvolver
e implementar alternativas de soluções para o atendimento de requisitos
preestabelecidos, podendo envolver a criação e/ou aquisição de
produtos, componentes de produtos ou serviços relacionados.
d) Solução Técnica: área definida para projetar, desenvolver
e implementar alternativas de soluções para o atendimento de requisitos
preestabelecidos, podendo envolver a criação e/ou aquisição de
produtos, componentes de produtos ou serviços relacionados.
e) Integração do Produto: área da montagem do produto a
partir dos seus componentes é responsável por entregá-lo ao cliente,
garantindo o seu funcionamento de forma integrada em relação a todas
as interfaces internas e externas.
f) Verificação: esta área deve garantir que um determinado
produto satisfaça os respectivos requisitos para os quais foi
desenvolvido.
g) Validação: esta área deve demonstrar que um
determinado produto ou componente de produto, atinge os resultados
esperados depois, de colocado em operação no ambiente final.
53
 53

Para Tapajós (2007b), o processo de desenvolvimento de software deve

possuir as fases mostradas na figura 10.
a) Avaliar: na fase de avaliação devem ser coletadas as

Figura 10 – fases do processo de desenvolvimento

Fonte: Tapajós (2007b)
informações, através de documentos e políticas existentes, e também
deverão ser feitas pesquisas e/ou workshops com os stackholders;
devem ser Identificados os processos, procedimentos e políticas para a
elaboração de um Plano de Ação (Roadmap).
b) Planejar: tendo em mãos o relatórios de recomendações e
o Plano de Ação, deverão ser elaborados nessa fase um Plano de
Implantação e o Cronograma desta implantação.
c) Implementar: nesta fase deverá se desenvolver ou
elaborar a metodologia de teste e homologação de sistema, após isso,
fazer uma revisão e testes, para alcançar finalmente a aprovação da
metodologia desenvolvida.
d) Auditar: nesta esta fase a metodologia de teste e
homologação de sistemas são aprovados pela auditoria interna,
conforme as diretrizes do COBIT e SOX.
e) Entregar: nesta fase são feitos testes, após isso um
relatório de conformidade com o framework de governança, o
treinamento com os usuários e é por fim publicada a metodologia.
 53

Segundo Vazquez et al. (2007), o processo de estimativa de um projeto de

software, basicamente, envolve as quatro atividades abaixo:

• Estimar o tamanho do produto a ser gerado;

• Estimar o esforço empregado na execução do projeto;
• Estimar a duração do projeto;
• Estimar o custo do projeto.
 53

2.7 MEDIÇÕES OU MÉTRICAS

As medições ou métricas são necessárias para a manutenção e

continuidade de qualquer processo, como por exemplo em cada um dos
Frameworks anteriormente citados, ou seja, no BSC, no COBIT e ITIL. Esta etapa é
fundamental, pois o que não é medido não é gerenciado, segundo Kaplan e Norton
(1997). Para esses autores, se as empresas quiserem sobreviver e prosperar na era
da informação, devem utilizar sistemas de gestão e medição de desempenho,
derivados de estratégias e capacidades.
Segundo um estudo realizado nos Estados Unidos, denominado “The Report
CHAOS”, em 1994 eram gastos mais de 250 bilhões de dólares por ano com
projetos de desenvolvimento de TI, sendo o custo médio dos projetos U$ 2.322.000
em companhias de grande porte, U$ 1.331.000 nas de médio porte e U$ 434.000
nas de pequeno porte. Desses projetos em software, 16,2% eram completados
dentro do prazo e do custo estimados, 31,1% eram cancelados antes de seu término
e 52,7% dos projetos eram realizados com custo de 189% além da estimativa inicial.
Segundo Wesley (2000 apud Drumont, 2004), hoje, o cenário é de demanda
crescente de softwares cada vez maiores, mais complexos, robustos e confiáveis,
devem respeitar os prazos e custos razoáveis e previsíveis. Para tanto é necessário
que o gerenciamento de projetos faça utilização de métricas que permitam a
mensuração do projeto, sendo capazes de gerar estimativas de prazo, custo e
recursos.

2.7.1 O que medir

O processo de medição deve definir, coletar, analisar e agir sobre medidas

que possam melhorar a qualidade dos produtos. É o próprio processo de
desenvolvimento e de obter dados quantitativos que darão apoio à tomada de
decisões.
 53

Entre os sistemas de medições de desenvolvimento de software podemos

citar: a Contagem de Linhas de Código Fonte (LOCs), o sistema Halstead
(operandos e operadores), a Análise por Casos de Uso (UC) e, entre outros, a
Análise de Pontos por Função. Todos esses métodos apresentam vantagem e
desvantagem, o que deve ser levado em conta na hora de escolher entre um e
outro, e a sua adequação com o desenvolvimento de software utilizado pela
empresa.
Wesley (2000 apud Drumont, 2004) explica que é necessário trabalhar com
medições capazes de oferecer, nos projetos de desenvolvimento, dados precisos
quanto às características do produto, o controle da evolução do projeto e a
identificação de divergências entre previsto e realizado. No caso de processos de
melhoria, é necessário que as métricas trabalhem o conhecimento quantitativo do
desempenho dos processos e o controle estatístico de aspectos críticos.

2.7.2 Contagem de Linhas de Código Fonte (LOCs)

A medição em linhas de código é a mais simples e barata, já que pode ser

contada de forma totalmente automática, porém tem pouco valor preditivo, tem a
necessidade de regras de padronização; as linhas de código reaproveitadas no
desenvolvimento devem, nesse caso, ser descartadas da contagem, assim como as
linhas geradas automaticamente pelas ferramentas de edição; além disso, existe a
dependência da linguagem utilizada no desenvolvimento.

2.7.3 Análise por Casos de uso

As medições levando-se em conta os Pontos de Caso de Uso, forem criadas

em 1993 por Gustav Karner, da Objectory, empresa hoje conhecida como Rational
Software. Essa técnica baseia-se em dois métodos: um deles é o de Análise dos
 53

Pontos de Função e outro conhecido como Mk II. O método consiste em estimar o

tamanho de um sistema, de acordo com o modo como os usuários o utilizarão,
vendo a complexidade de ações requerida por cada tipo de usuário; e a análise, em
alto nível, dos passos necessários para a realização de cada tarefa.
Esta técnica utiliza a documentação gerada nas fases de solicitação e
análise de dados, para fazer o cálculo da dimensão do sistema, sendo possível
assim estimar seu tamanho, gerando um gráfico conhecido como diagrama de
Casos de Uso (Use Case), que serve para descrever as funcionalidades do sistema,
de acordo com a utilização dos usuários.
É comum o uso dessa técnica com processos de engenharia de software
com enfoque disciplinado de atribuição de tarefas e responsabilidades, conhecido
como Rational Unified Process (RUP).
Segundo Hazan (2005), a métrica Pontos por Casos de Uso (PCU) foi
proposta por Gustav Karner; seu propósito é o de estimar recursos para projetos de
software OO (orientados a objetos).
Em linhas gerais, o método de contagem de Pontos por Caso de Uso
consiste nos seguintes passos:
• contar os atores e identificar sua complexidade;
• contar os casos de uso e identificar sua complexidade;
• calcular os PCUs não ajustados;
• determinar o fator de complexidade técnica;
• determinar o fator de complexidade ambiental;
• calcular os PCUs ajustados.

As técnicas orientadas a objeto (TOO) representam estratégias para

organizar sistemas, como coleções de objetos que interagem. Os objetos
correspondem aos conceitos do domínio do problema, que serão representados em
modelos e implementados em códigos de programa; cada objeto é identificado pelos
seus atributos, comportamento e relacionamentos com os outros objetos.
 53

2.7.4 Análise de Pontos por Função

A Análise de Pontos de Função (APF) foi proposto por Allan Albrecht, em

1979, e sua formalização de regras de contagem teve início em 1984, pela IBM. É
um método para a medição do desenvolvimento de software, que visa estabelecer
uma medida de tamanho do software em Pontos de Função (PFs), com base na
funcionalidade a ser implementada, sob o ponto de vista do usuário. Aguiar (2004)
define usuário para APF como:

Um usuário é qualquer pessoa que especifica requisitos funcionais para o

software, e/ou qualquer pessoa ou objeto que se comunica ou interage com
o software a qualquer tempo. Pode ser um ser humano, outro software, um
dispositivo de hardware, etc, desde que especificado nos requisitos
funcionais (AGUIAR, 2004, p.4).

Atualmente, a contagem dos pontos de função é homologada pela

International Function Point Users Group (IFPUG), uma organização localizada nos
Estados Unidos. O IFPUG publica o Manual de Práticas de Contagem (Counting
Practices Manual), que atualmente está na versão 4.2.1; no Brasil, o Brazilian
Function Point Users Group (BFPUG), representa o IFPUG. Estabelecer padrões
para o cálculo dos pontos de função e garantir uma padronização de procedimentos
é uma das atribuições do IFPUG, que oferece certificação na técnica e divulga os
profissionais já certificados através do site www.ifpug.org.
Segundo Hazan (2005), os objetivos da APF são:
• Medir as funcionalidades do sistema, requisitadas e recebidas pelo usuário;
• Medir projetos de desenvolvimento e manutenção de software, sem se
preocupar com a tecnologia que será utilizada na implementação;
O procedimento para contagem de Pontos de Função (PF) compreende sete
passos, mostrados na figura 11.
 53

Figura 11 - contagem de Pontos de Função

Fonte: adaptado de IFPUG (2004)

2.7.5 Determinação do tipo de contagem

Conforme Vazquez et al. (2007), a contagem de pontos de função pode

estar associada tanto a projetos quanto a aplicações e pode ser de três tipos:
a) Contagem de um projeto de desenvolvimento: este tipo de
contagem mede a funcionalidade fornecida aos usuários finais do
software quando da sua primeira instalação; essa contagem, na
realidade, é uma estimativa da funcionalidade que será entregue, uma
vez que é realizada, antes do término do projeto;
b) Contagem de um projeto de melhoria: o número de pontos
de função de um projeto de melhoria mede funções adiconadas,
modificadas ou excluídas do sistema, pelo projeto;
c) Contagem de uma aplicação: também é chamada de
número de pontos de função instalados, ou baseline; essa contagem
fornece a medida da atual funcionalidade obtida pelo usuário da
aplicação, e é inicializada ao final da contagem do número de pontos do
projeto de desenvolvimento, sendo atualizada no término de todo o
projeto de melhoria.
 53

2.7.6 Identificação do escopo da contagem e fronteira da aplicação.

Segundo Vazquez et al. (2007), o escopo da contagem define quais funções

serão contadas, ou seja, se a contagem abrangerá mais sistemas, apenas um
sistema ou partes de um sistema. Dessa forma, a contagem de uma aplicação, por
exemplo, poderá abranger todas as suas funcionalidades disponíveis, apenas as
efetivamente utilizadas pelo usuário, ou algumas funcionalidades específicas
(relatórios, transações cadastrais, etc.).
Conforme Vazquez et al. (2007), “a fronteira da aplicação é a interface
conceitual que delimita o software que será medido e o mundo exterior (seus
usuários)”. Se a definição da fronteira não estiver clara, corre-se o risco de se
trabalhar com uma contagem que posteriormente será invalidada.
A fronteira da aplicação delimita o software medido e o usuário. Segundo
FATTO (2008), a fronteira:

a) Define o que é externo à aplicação;

b) É a interface conceitual entre o ‘interno’ ao sistema e o
‘externo’ do mundo do usuário;
c) ‘Membrana’ pela qual dados processados pelas
transações (EE,SE,CE) passam, entrando e saindo;
d) Compreende dados mantidos pela aplicação (ALI);
e) Apóia na identificação de dados referenciados , mas não
mantidos dentro da fronteira da aplicação (AIE);
f) Deve ser determinada com base na visão do usuário,
focada no que ele pode entender e descrever;
g) A fronteira entre aplicações deve ser baseada na
separação de funções, como estabelecido pelos processos de negócio,
não em considerações técnicas;
h) Em projetos de melhoria, a fronteira estabelecida no início
do projeto deve estar de acordo com aquela já estabelecida para a
aplicação sendo modificada.
 53

2.7.7 As funções do tipo de dado

Segundo Vazquez et al. (2007), as funções do tipo de dado representam as

funcionalidades fornecidas pelo sistema, ao usuário, para atender a suas
necessidades de dados, e são classificadas em:

a) Arquivo Lógico Interno (ALI) : é o nome dado ao grupo de

dados ou informações de controle, logicamente relacionados,
reconhecido pelo usuário, mantido dentro da fronteira da aplicação. Sua
principal intenção é armazenar dados mantidos por um ou mais
processos elementares, da aplicação que esta sendo medida.
b) Arquivo de Interface Externa (AIE): é o nome dado ao
grupo de dados ou informações de controle, logicamente relacionados
reconhecido pelo usuário, referenciado pela aplicação, mas mantido
dentro da fronteira de outra aplicação. Sua principal intenção é
armazenar dados referenciados por um ou mais processos elementares
da aplicação que esta sendo contada. Um AIE contado para uma
aplicação, deve ser um ALI em outra.

2.7.8 As funções do tipo transação

Segundo Vazquez et al. (2007), as funções do tipo transação representam a

funcionalidade fornecida ao usuário, para atender as suas necessidades de
processamento de dados pela aplicação, e são classificadas em Entradas externas,
Saídas Externas ou Consultas Externas.

Segundo Drumond (2004), entradas externas (EE), são processos nos quais
os dados cruzam a fronteira da aplicação de fora para dentro, com o objetivo de
alterar o comportamento da aplicação ou dados; consultas externas (CE), são
processos nos quais os dados cruzam a fronteira da aplicação de fora para dentro,
 53

sem envolver cálculos ou alteração de dados e saídas externas; (SE) são processos
em que os dados cruzam a fronteira da aplicação de dentro para fora.

2.7.9 Determinar a contagem de pontos de função não ajustados

A contagem de pontos de função não ajustado é conseguida através da

soma dos pontos obtidos no levantamento dos dados contidos na documentação e
aos quais é atribuído um peso, denominado contribuição. O valor de contribuição é
conseguido de acordo com o grau de complexibilidade do ponto de função (PF) que
lhe é atribuído, conforme o quadro 1.

complexibilidade
Contribuição
funcional

Legenda

(TD) – Quantidade de Tipos de Dados

(AR) – Quantidade de Arquivos

Referenciados

(TR) – Quantidade de Tipos de

Registro

Quadro 1 – complexibilidade funcional e contribuição

Fonte: Adaptado de FATTO(2008)
 53

2.7.10 Determinar o fator de ajuste

Segundo Hazan (2005), o fator de ajuste é o cálculo baseado na ponderação

do Nível de Influência (NI), das 14 Características Gerais do Sistema (CGS)
definidas.
Segundo Vazquez et al. (2007), as funções de tipo de dado se referem ao
armazenamento de dados; as funções do tipo transação, se referem
especificamente ao processamento desses dados; e as CGSs refletem funções que
afetam a aplicação de maneira geral.
Para determinar o fator de ajuste de função (VAF), deve-se basear nas
características gerais de sistema (CGS).
Conforme explica Vazquez et al. (2007), para conhecer as características
(CGS), devemos perguntar ao sistema qual o nível de influência que tem cada uma
das quatorze características listadas no quadro 2; este valor pode variar de um
intervalo discreto de zero a cinco e indicam a funcionalidade geral fornecida pela
aplicação ao usuário. Calculado com base nas 14 CGSs, produzem uma variação de
+/- 35% no tamanho, variando entre 0,65 e 1,35.
Conforme FATTO (2008, p. 2) , o cálculo para obtenção do fator de ajuste se
dá pela fórmula:
Fator de Ajuste [VAF] = [TDI] x 0,01 + 0,65
Onde:
Nível de Influência [DI] = 0..5 e Nível de Influência Total [TDI] = Σ DI

Características Gerais do Sistema (CGS)

n CGS
1Comunicação de dados
1 se diretamente com o processador.
2Processamento distribuído
2
descrição
Descreve o nível em que a aplicação comunica-
Os dados ou informações de controle utilizados
pela aplicação, são enviados ou recebidos
através de recursos de comunicação.
Protocolo é um conjunto de convenções que
permitem a transferência ou intercâmbio de
informações entre dois sistemas ou dispositivos.
Descreve em que nível a aplicação transfere
dados entre seus componentes.
 53

n CGS descrição
3Performance Descreve em que nível os requisitos
estabelecidos pelo usuário, sobre tempo de
3
resposta, influenciam o projeto,
desenvolvimento, instalação e suporte da
aplicação.
4Configuração altamente utilizada Descreve em que nível restrições
computacionais influenciam no desenvolvimento
4
da aplicação. Por exemplo, o usuário deseja
executar a aplicação em um equipamento já
existente ou comprado e que será altamente
utilizado.
5Volume de transações Descreve em que nível o alto volume de
transações influencia o projeto,
5
desenvolvimento, instalação e suporte da
aplicação.
6Entrada de dados on-line Descreve em que nível são efetuadas entradas
de dados na aplicação por, meio de transações
6
interativas.
7Eficiência do usuário final As funções on-line fornecidas pela aplicação
enfatizam um projeto para o aumento da
7
eficiência do usuário final
8Atualização on-line Descreve em que nível os arquivos lógicos
internos são atualizados de forma on-line.
8
Acessibilidade, atalhos, ajudas e outros.
9Complexibilidade de processamento Descreve em que nível o processamento lógico
ou matemático influencia o desenvolvimento da
9
aplicação.
1Reutilização Descreve em que nível a aplicação e seu código
foram especificamente projetadas,
10
desenvolvidas, e suportadas para serem
utilizadas em outras aplicações.
1Facilidade de instalação Descreve um plano e/ou ferramentas de
conversão e instalação foram fornecidos e
11
testados durante a fase de teste do sistema.
1Facilidade de operação Descreve em que nível a aplicação atende a
alguns aspectos operacionais como:
12
inicialização, segurança e recuperação.
A aplicação minimiza a necessidade de
atividades manuais, como contagem de fitas,
manipulação de papel, entre outros processos
manuais.
1Múltiplos locais Descreve em que nível a aplicação foi
especificamente projetada, desenvolvida e
12
suportada para diferentes ambientes de
hardware e software.
1Facilidade de mudanças Descreve em que nível a aplicação foi
especificamente desenvolvida, para facilitar a
14
mudança de sua lógica de processamento ou
estrutura de dados.

Quadro 2 - Características gerais do sistema

Fonte: Adaptado de FATTO (2008, p. 2).
 53

2.7.11 Calculo dos pontos de função ajustados

O ultimo passo para a contagem de pontos de função envolve o cálculo final

para os três tipos de contagem, ou seja, contagem de projeto de desenvolvimento,
projeto de melhoria e aplicação. Segundo Vazquez et al. (2007), as fórmulas
apresentadas no quadro 3, são para cada tipo de contagem e estão exatamente
como descritas no manual do IFPUG, contendo os mesmos nomes de variáveis
inclusive.

Projeto de Desenvolvimento (DFP)

DFP = (UFP + CFP) x VAF
DFP PF de projeto de desenvolvimento.
UFP PF não ajustados da aplicação a ser instalada.
CFP PF incluídos de conversão de dados.
VAF Valor do fator de ajuste.

Projeto de Melhoria (EFP)

EFP = [(ADD + CHGA + CFP) x VAFA] + (DEL x VAFB)
EFP PF de projeto de melhoria.
ADD UFP das novas funcionalidades.
CHGA UFP das funcionalidades alteradas, depois da melhoria.
VAFA VAF depois da melhoria.
DEL UFP das funcionalidades excluídas.
VAFB VAF antes da melhoria.

Aplicação - Após Melhoria

AFP = [(UFPB+ADD+CHGA)-(CHGB + DEL)] x VAFA
UFPB UFP da aplicação antes da melhoria.
CHGB UFP das funcionalidades alteradas, antes da melhoria.

Quadro 3 – formulas para calculo dos pontos de função

Fonte: Adaptado de Vazquez et al. (2007, p. 132-138).
 53

3 METODOLOGIA

3.1 CARACTERIZAÇÃO DA PESQUISA

A modalidade de pesquisa utilizada para o desenvolvimento deste trabalho

será o estudo de caso único, de observação participante. Segundo Yin (2005), este
tipo de pesquisa tem grande expressão quando o pesquisador tem pouco controle
sobre os eventos comportamentais e quando o foco se encontra em eventos
contemporâneos com a necessidade de pesquisa que em sua forma estejam
questões do tipo, “como“ e “por que”, o estudo de caso apresenta vantagens sobre
outras maneiras de pesquisa.
No caso específico da pesquisa proposta, as questões acima mencionadas,
são bastante claras, pois segundo os objetivos já citados é necessário saber “como”
o processo de medição do desenvolvimento e manutenção de sistemas de TI se
encontra hoje e também é de fundamental importância saber “por que” deverá ou
não ser alterado para o novo sistema de medição proposta.
O estudo de caso para Gil (2006, p.41). “consiste no estudo profundo e
exaustivo de um objeto ou poucos, de maneira que permita seu detalhado
conhecimento”. Segundo Schramm (1971 apud YIN, 2005).

Essência de um estudo de caso, a principal tendência de todos os tipos de

estudo de caso, é que ela tenta esclarecer uma decisão ou um conjunto de
decisões: o motivo pelo qual foram tomadas, como foram implementadas e
com quais resultados, (SCHRAMM 1971, apud YIN, 2005, p. 31).

A pesquisa também pode ser caracterizada como observação participante

devida a presença do observador não ser passiva, podendo assumir uma variedade
de funções dentro de um estudo de caso, participando dos eventos que estão sendo
estudados na forma de membro de equipe ou pessoa que toma decisões chave em
uma organização, conforme explica Yin (2005).
 53

Segundo Yin (2005), o observador pode dispensar muito ou pouco tempo na

situação de pesquisa; o papel do observador pode ser uma parte integrante da
estrutura social ou ser simplesmente periférica com relação a ela.

3.2 LIMITAÇÃO DA PESQUISA

Este trabalho apresenta algumas limitações, entre as quais podem-se

destacar:

• Esta pesquisa não tem como objetivo medir o nível de

maturidade da área de TI da instituição estudada;
• Esta pesquisa não tem o objetivo de comparar o grau de
precisão de cada um e/ou entre cada um dos métodos de medição
citados;
• Apesar da utilização do PCU pelo setor de
desenvolvimento a comparação feita não será em relação PCU e APF,
mas sim da utilização da APF para conseguir métricas necessárias para
alcançar os objetivos propostos;
• Os projetos foram escolhidos pelo critério de abranger
tipos diferentes de medição de acordo com o que o novo método oferece,
outro fator na escolha desses projetos especificamente é a possibilidade
de medição durante o tempo de pesquisa deste trabalho, porém devo
lembrar que o método não limita sua aplicação ao tempo, uma vez que
age sobre a documentação a condição de tempo é uma conveniência
para efetivação do estudo.
• A pouca literatura encontrada para desenvolver a
metodologia no que se refere a métricas de desenvolvimento de
sistemas.
 53

3.3 DESCRIÇÃO DO DESENVOLVIMENTO DA PESQUISA

Primeiramente foi feito um levantamento da documentação utilizada para o

controle e medição de 2 projetos de desenvolvimento, sendo esses respectivamente
um projeto de criação de uma nova aplicação e alteração de uma aplicação
desenvolvida pelo setor de desenvolvimento de sistema da instituição.
Em seguida foi verificado a documentação já utilizada, com o objetivo de
confirmar seus dados com os necessário para aplicação novo método proposto.
Assim, se a documentação encontrada não fosse suficiente para o novo método
proposto, seria necessário a criação de uma nova para suprir a necessidade de
obtenção dos dados.
Em uma terceira foi feita a comparação entre os tipos de métricas
levantadas pelo método atual, com os tipos de métricas que podem ser conseguidas
com o novo método proposto e as métricas recomendadas para alcançar os
objetivos previstos no estudo.
Na quarta etapa foi aplicado o novo métodos proposto nos projetos
selecionados, com a finalidade de gerar as medições desse método e compara-las
com as medições do método já utilizado, levando em consideração apenas os tipos
de métrica que cada método pode apresentar em seu resultado.
Por fim na fase de conclusão será feita a comparação da medição resultante
de ambos os métodos e também uma avaliação de qual método poderá ser mais
produtivo e eficiente para alcançar os resultados esperados pela instituição em
relação aos frameworks que poderão ser utilizados pelo processo de Governança de
TI. O quadro 4 representa um resumo de cada etapa do estudo feito.
 53

Resumo da etapas
Etapas Descrição
Levantamento da • definição dos projetos a serem estudados;
documentação • devantamento da documentação dos projetos
existente. escolhidos.
Estudo da • confirmação dos dados necessários para o novo
documentação acima método na documentação já existente.
reunida.
Comparação das • comparação do modelo atual de medição, com as
métricas obtidas. métricas recomendadas para alcançar os objetivos
da Governança de TI.
Aplicação do novo • aplicação da APF nos projetos selecionados;
métodos • comparação do novo método com as métricas
recomendadas para alcançar os objetivos previstos
no estudo.
Conclusão • comparação entre os dois métodos;
• qual dos dois será melhor para a atingir os objetivos
propostos no estudo.
• Considerações finais
Quadro 4 – Resumo das etapas da pesquisa
 53

4 ESTUDO DE CASO

A pesquisa foi realizada no setor de desenvolvimento de sistemas da Gestão

de Tecnologia de Informação (GTI) do Centro Universitário Metodista, Instituição de
Ensino Superior (IES) sediada na rua Dr. Lauro de Oliveira, 71 em Porto Alegre no
Estado do Rio Grande do Sul.

4.1 HISTÓRICO DA INSTITUIÇÃO

O Centro Universitário Metodista IPA pertence a uma rede de instituições de

ensino da Igreja Metodista. A história da Igreja Metodista nasce no século XVIII na
Universidade de Oxford, expande-se como missão evangélica na província norte-
americana da Geórgia no período da América colonial e consolida-se na obra
educacional, cuja primeira experiência desenvolveu-se em Bristol, na Inglaterra.
O Centro Universitário Metodista, mantido pelo IPA- Instituto Porto Alegre da
Igreja Metodista, tem sua origem no Colégio Americano, criado em Porto Alegre
em 1885.
No IPA, foram criados, a partir de 1971, os curso de Educação Física,
Fisioterapia e Terapia Ocupacional. No Americano, por iniciativa da mantenedora
IMEC – Instituto Metodista de Educação e Cultura, desenvolveram-se, no mesmo
período, os cursos de Nutrição, Fonoaudiologia, Administração Hospitalar e Turismo
e em 2002, a educação básica das duas mantenedoras foi integrada em uma
apenas – o IMEC, no Colégio Metodista Americano. Os cursos superiores do IMEC
foram transferidos para o IPA, o que possibilitou a elaboração do projeto de
transformação em Centro Universitário. O credenciamento como Centro Universitário
Metodista ocorreu em 11 de outubro de 2004.
Antes do reconhecimento como Centro Universitário, a Instituição oferecia
sete cursos de graduação: Educação Física, Fisioterapia, Terapia Ocupacional,
Fonoaudiologia, Nutrição, Turismo com ênfase em Hotelaria e Administração
 53

Hospitalar. Naquele ano de 2004, antes mesmo do reconhecimento como Centro

Universitário, em decorrência de processo anterior em tramitação, foi oferecido o
curso de Administração.
Com a transformação em Centro Universitário, implementando o PDI
aprovado, somaram-se aos cursos existentes os novos cursos de Direito (em
transferência de mantença da Instituição Cesupa), Biomedicina, Enfermagem,
Ciências Contábeis, Comunicação Social – habilitação Publicidade e Propaganda,
Administração de Negócios Internacionais, Farmácia, Serviço Social, Ciências
Biológicas (Licenciatura), Pedagogia – Habilitação Séries Iniciais, Pedagogia –
Habilitação Educação Infantil, História, Letras – Habilitação Língua Inglesa, Letras –
Habilitação Língua Portuguesa, Música, Filosofia e Matemática, oferecidos nos
processos seletivos de 2004.
Em 2005, seguindo a orientação do PDI aprovado foi incorporada a
habilitação Jornalismo do curso de Comunicação Social (inicialmente prevista para
2009), tendo por justificativa a otimização da infra-estrutura já existente com o curso
de Comunicação Social – habilitação Publicidade e Propaganda.
Projetado inicialmente para 2005, o curso de Psicologia teve sua oferta
adiada em função da tramitação de processo para solicitação de autorização de
funcionamento. Também o curso de Engenharia de Produção, teve oferta adiada
para o ano de 2006, por decisão institucional de criação de um rol de cursos na área
tecnológica, com divulgação e esforços institucionais integrados.
Assim, no vestibular para 2006/1 foram oferecidos os seguintes cursos na
área tecnológica: Engenharia de Computação, Engenharia Civil, Engenharia de
Produção e Arquitetura (este último inicialmente previsto para 2007, também
adiantado). Inicialmente não prevista, a Engenharia Civil foi integrada em
substituição à Engenharia de Alimentos prevista para 2008, e a Engenharia de
Computação tomou lugar do curso de Ciências da Computação, projetado para
2010. O curso de Design Gráfico não foi aberto naquele ano, tendo seu projeto
alterado e nova proposta oferecida na seqüência.
Em 2006/2, o curso de Design de Moda, em substituição à proposta original
de Design Gráfico, também passou a ser oferecido, integrando o grupo de cursos da
área tecnológica. O Centro Universitário IPA assumiu vanguarda na oferta deste
curso na cidade de Porto Alegre, tendo em vista a grande demanda local e o fato do
mesmo ainda não ser oferecido por outras IES da capital gaúcha.
 53

A condição de Centro Universitário trouxe novo impulso ao crescimento e

desenvolvimento institucional, o que pode ser evidenciado por sua história recente.
A Instituição recebe, nos dias de hoje, aproximadamente nove mil estudantes de
graduação, distribuídos em 30 cursos
Atualmente, as atividades acadêmicas são realizadas no complexo que
reúne os campi IPA-Americano-Dona Leonor, no bairro Rio Branco, no campus
Cruzeiro do Sul, Hospital Parque Belém, Restinga e Penitenciária Madre Pelletier, na
zona sul de Porto Alegre, e no campus DC Shopping, localizado na zona norte da
capital gaúcha.
A parceria com o Hospital Parque Belém, iniciada em 1999, aprofundou-se e
potencializou-se no período 2004-2006, com a transformação do local em hospital-
escola. As Clínicas IPA, que já prestavam atendimento, foram integralmente
transferidas a partir de 2004 para o Hospital Parque Belém.
Em janeiro de 2005, foi firmado convênio com a Sociedade Caritativa e
Literária São Francisco de Assis Zona Central – SOCALIFRA para utilização do
espaço da antiga PIA Chaves Barcelos, localizada próxima aos campi Americano e
IPA, como novo campus no Rio Branco. Com a integração deste novo espaço,
histórico na cidade de Porto Alegre, sob o compromisso da manutenção predial e
preservação das fachadas (com possibilidade de tombamento), passou a ser
oferecido novo espaço para aulas teóricas e práticas de diferentes cursos.
Em março de 2005, convênio com a Igreja Episcopal Anglicana do Brasil
(IEAB), garantiu abertura de novo espaço no bairro Teresópolis, zona sul de Porto
Alegre, região até então também descoberta do ponto de vista do ensino superior. O
novo espaço, ocupando as instalações do extinto Colégio Cruzeiro do Sul, passa a
ser denominado Campus Cruzeiro, com a oferta dos cursos de Administração,
Ciências Contábeis, Direito, Pedagogia e Educação Física Licenciatura.
Em agosto de 2005, convênio com a AJ Renner S/A Indústria e
Participações, proprietária do Shopping DC, localizado no bairro Navegantes, zona
norte da capital gaúcha. No novo campus, foram oferecidos cursos na área
Tecnológica, Direito e Administração.
Em dezembro de 2005, o Centro Universitário Metodista IPA inova ao firmar
parceria com o Estado do Rio Grande do Sul – Secretaria da Justiça e da
Segurança, por meio da Superintendência dos Serviços Penitenciários (SUSEPE) -
para a abertura de um curso de Serviço Social para detentas, na Penitenciária
 53

Feminina Madre Pelletier. À margem das possibilidades de acesso formal à

educação superior, grande parte da população carcerária faz parte dos grupos
atingidos por processos sociais excludentes, tanto do ponto de vista das causas
quanto dos mecanismos operadores de exclusão que se dão durante e após o
cumprimento da pena restritiva de liberdade. O convênio firmado também foi
extensivo à oferta de educação básica para apenadas em condições de concluir o
ensino médio, de forma a viabilizar outras turmas de ensino superior.
Após o credenciamento como Centro Universitário, na perspectiva da
internacionalização institucional, o compromisso com a transformação social
estendeu-se, com a criação de um programa receptivo de estudantes estrangeiros
de países em processo de reconstrução após guerras, como Haiti, Timor Leste,
Angola e Moçambique.
A internacionalização almejada pelo Centro Universitário Metodista IPA não
cede ao modelo vigente de globalização segundo a lógica mercantil, mas busca
resgatar o papel da Instituição universitária como agente de “planetarização”, termo
etimologicamente advindo do grego plakso, que significa nivelamento ou
aplastamento de diferenças. Também não pode ser pensado como
homogeneização, mas como profunda mudança no sentido de diversidade,
reconfigurando o sentido de cidadania.

4.1.1 O setor de desenvolvimento

O setor de desenvolvimento do Centro Universitário Metodista, é

responsável pela criação, desenvolvimento e manutenção de aplicações utilizados
por diversas áreas da instituição. Essas aplicações têm a finalidade de interligar os
sistemas existentes e/ou oferecer funcionalidades que outros sistemas adquiridos
não comportam. Desta forma então o próprio setor desenvolve a grande maioria dos
sites e páginas do Portal Institucional da Rede Metodista de Educação , entidade em
que o Centro Universitário Metodista é integrante.
As ferramentas para de gestão para garantir a implantação da
governança são várias, e em sua busca para um melhor uso dessas ferramentas
 53

e técnicas a GTI aposta em estudos de desenvolvimento de TI, contratando

serviços de consultoria especializada em governança para auxilia-la em no
encontro do melhor pacote de ferramentas e serviços adequados para a
realidade institucional. Para a realização desse trabalho, a empresa de
consultoria juntamente com a GTI estabeleceu para a efetivação da governança
que entre outras divisões da área tecnológica, o setor de desenvolvimento de
sistemas deveria estudar uma forma de medir seus resultados e atividades
desenvolvida a fim de preencher as informações necessárias ao framework de
governança que está sendo desenvolvido.
A instituição esta implementando a de Governança de TI e apesar de não
definido todos os aspectos do Framework de Governança que será implantado, esta
claro em sua composição inicial o mapeamento de processos do Cobit, ITIL e
integração com BSC. Além disso, será obrigatório para seu sucesso a utilização de
normativas contidas nas ISO1779, ISO27001 e BS7799 em relação aos requisitos
de segurança da informação. Além disso será necessário verificar os procedimentos
contidos na SOX em suas seções 404, 407, 408 e 409, conforme expõe Tapajós
(2007a) e também é demonstrado pelo modelo proposto por Weill e Ross (2007),
conforme já mostrado na figura 1.
O fluxo do processo de desenvolvimento de aplicações do setor de
desenvolvimento é mostrado no Anexo A. Nesse diagrama podemos ver as
diferentes partes do desenvolvimento, essas etapas ocorrem após o projeto ter sido
estudado, analisado e aprovado por um comitê que define as prioridades para o
desenvolvimento de sistemas da instituição.

4.2 MÉTODO DE MEDIÇÃO ATUAL

Desde 2007 o setor de desenvolvimento de sistemas faz medições de

estimativa de esforço dos projetos através da técnica conhecida como Pontos de
Casos de Uso (PCU) e controla o andamento do projeto através dos gráficos
gerados pelo Dotproject (software para controle de projetos). Para utilizar este
método a equipe utiliza o seguinte procedimento:
 53

1. Registro da solicitação de forma detalhada em um documento definido como

Escopo Detalhado, conforme modelo contido no Anexo B. Nesse documento são
registradas as seguintes informações sobre o projeto:
a) nome do projeto: titulo dado a aplicação que irá ser
desenvolvida, alterada ou modificada;
b) declaração do escopo: detalhamento sobre a necessidade
do projeto e suas principais funções, restrições e procedimento para seu
uso, levando-se em consideração os envolvidos, fluxo de informações,
sistemas adjacentes;
c) parecer da divisão de infra-estrutura: este item descreve
quando necessário as condições técnicas de infra-estrutura necessárias
para que a aplicação possa ser implementada. Essa avaliação é feita
pela equipe de infra-estrutura verificando o impacto que tal aplicação
poderá causar na estrutura de servidores, pontos de rede, tráfego na
rede, segurança, máquinas e/ou outros equipamentos necessários para
que a sua performance possa ser a esperada.
d) cronograma: estimativa do tempo em que o projeto será
desenvolvido em sua totalidade e em suas etapas;
e) requerimentos de negócio (caso de uso): nesse item é
feito uma representação gráfica do projeto, mostrando seus atores,
rotinas e tarefas, fluxo de informação e inter-relacionamento entre esses
itens, além de uma breve descrição de cada um desses itens;
f) cancelamento: quando houver cancelamento a data e
motivo;
g) data de início do projeto: inicio do projeto;
h) nome dos envolvidos: nome dos participantes na
confecção do projeto.

2. calculo da estimativa do esforço para a execução do projeto, esse calculo é feito

através de uma planilha eletrônica que calcula o esforço baseado em pontos de
caso de uso conforme já levantados na documentação de escopo. Essa planilha
para poder estimar esse esforço, fará um calculo aproximado das seguintes
métricas:
 53

a) complexibilidade dos atores: define peso para cada ator

envolvido, de acordo com seu nível de envolvimento com o sistema,
sistemas adjacentes e/ou complexibilidade gráfica;
b) complexibilidade dos casos de uso: define peso para cada
caso de uso, de acordo com o número de transações desse caso;
c) listagem de fatores técnicos do projeto: atribui peso a
cada fator do projeto sendo eles: subsistemas, objetivos de performance,
eficiência online, complexibilidade de processamento, código reusável
em outras aplicações, facilidade de instalação, facilidade de uso,
portabilidade, facilidade/probabilidade de alterações em código, número
de usuários, segurança, acesso direto a terceiros e necessidade de
treinamento para usuários;
d) consideração de fatores ambientais: peso atribuído a cada
fator que poderá envolver o projeto em sua fase de execução. São eles:
familiaridade da equipe como RUP, experiência da equipe, experiência
em OO, capacidade dos analistas da equipe, motivação, estabilidade
dos requisitos, funcionários em tempo parcial e domínio da tecnologia.
e) pontos de caso de uso: nesse item são calculado os
PCUs, conseguindo os resultados: PCUs, pessoa-hora por unidade de
PCU, estimativa em pessoa-hora, tamanho da equipe, estimativa em
horas e estimativa em meses.

3. após a estimativa de esforço, os dados da planilha são verificados e passados ao

Dotproject para o acompanhamento e alocação da equipe de programadores ao
projeto. O anexo C, mostra a tela do software contendo um gráfico de gant de um
projeto.
Com a documentação acima descrita a área de desenvolvimento gera
métricas baseadas no método PCU, já explicado anteriormente, podendo assim ter
como resultado do método uma estimativa de esforço, equipe utilizada no projeto e
um acompanhamento cronológico do que já foi realizado no projeto, conforme o que
cada um dos envolvidos registrou no Dotproject.
O quadro 5 representa um resumo de cada etapa dos procedimentos do
métodos atualmente utilizado.
 53

Método atual
procedimento Descrição
Registro da solicitação Escopo Detalhado, conforme modelo contido no anexo B.
• nome do projeto;
• declaração do escopo;
• parecer da divisão de Infra-Estrutura;
• cronograma;
• requerimentos de negócio (caso de uso);
• quando houver cancelamento a data e motivo;
• data de início do projeto;
• nome dos envolvidos.
Calculo da estimativa do Os Cálculos tem base nos pontos de caso de uso.
esforço • complexibilidade dos atores;
• complexibilidade dos casos de uso;
• listagem de fatores técnicos do projeto;
• consideração de fatores ambientais;
• pontos de caso de uso.
Registro do projeto Uso do Dotproject para o acompanhamento e alocação da
equipe.
Quadro 5 – procedimento atual da medição

4.2.1 Documentação

Segundo Gil (2006), a pesquisa de estudo de casos, possibilita utilizar

diversos instrumentos de coleta de dados, bem como de gente e de papel.
Para atingir os requisitos previstos nestes frameworks, a empresa utiliza
uma documentação para registro e gerenciamento dos projetos, que é gerada
durante os processos de solicitação e análise de cada um dos projetos. Na
confecção de algumas dessas documentações são utilizados softwares específicos,
tais como:
a) JUDE para a confecção de gráficos em UML (Unified
Modeling Language), que demostram os casos de uso;
b) Designe For Data Base, para a confecção do desenho do
ER (Entidade de Relacionamento) das tabelas do banco de dados;
 53

c) Dotproject que é capaz de gerar documentação escrita e

gráficos para o acompanhamento do projeto, controle e distribuição dos
recursos, registro e distribuição das tarefas dos envolvidos no projeto.

Além desses softweres específicos também são criadas algumas planilhas,

documentos de escopo, de entrega do projetos e outros pertinentes e subjetivos a
cada projeto.
As alterações de sistemas com previsão de entrega menor que quatro horas
não irão gerar novo projeto, apenas serão registradas como tarefa de manutenção
no dotproject.
Conforme Vazquez at al. (2007), a captação dos requisitos necessários para
a contagem dos Pontos de Função podem ser extraídos da documentação já
existente. No quadro 6 é feito uma comparação da documentação sugerida e a
documentação já utilizada pelo setor de desenvolvimento de sistemas no método de
Pontos por Caso de USO.

Quadro 6 - Documentação
Vazquez (2007) Documentos existentes
1proposta de projeto. documento de escopo do projeto.
2especificação de necessidades de também é vista no documento de
negócio. escopo.
3documento de visão. existente, porém não aplicado nesse
caso.
4modelo de entidades e modelo ER.
relacionamentos.
5diagrama de fluxo de dados. não utilizado.
6diagrama de casos de uso. o diagrama é criado através do JUDE e
incorporado ao documento de escopo.
7especificação suplementar. algumas dessas especificações são
colocadas no documento de escopo.
8protótipo de interface. o protótipo é feito em tempo de
execução do projeto pelo próprio
programador, conforme necessidades
visualizadas por esse.
Quadro 6 – Documentação
Fonte: adaptado de Vazquez at al. (2007, p. 62).
 53

4.3 MÉTODO DE MEDIÇÃO PROPOSTO

O método de medição proposto APF, foi será aplicado em três projetos,

conforme anteriormente mencionado, no período da pesquisa, que se deu entre os
meses de março de 2008 à de abril de 2008, levando-se em conta a analise dos
pontos da função para a medição de cada um dos projetos, observando os requisitos
de cada sistema quanto à funcionalidade, usabilidade, confiabilidade, desempenho e
suporte. conforme menciona Vazquez et al. (2007).
Os dados aplicados ao método de medição, foram retirados em sua grande
maioria dos documentos já utilizados pela instituição para alimentar o método atual
de medição.

4.3.1 Método pontos de função

Para aplicar este novo método seguiremos os passos conforme o diagrama

em bloco mostrado por IFPUG (2004) na figura 10, que são: definição do tipo de
contagem, definição da fronteira da aplicação e escopo da contagem, funções tipo
dado, funções tipo transação, calcular contagem de pontos de função não ajustados,
calcular valor do fator de ajuste e calcular número de pontos de função ajustados.
O primeiro passo é determinar o tipo de contagem a ser realizada sobre o
projeto, isto dependerá especificamente do projeto, podendo ser aplicados um ou
mais dos três tipos de contagem, ou seja, poderá ser feita uma contagem de projeto
em desenvolvimento, de projeto de melhorias ou contagem de uma aplicação,
conforme já exposto no item tipos de contagem da APF.
O segundo passo foi determinar a fronteira da aplicação e escopo da
contagem, em nosso caso o escopo será a contagem apenas das funções que
tiverem referência especificamente com a tarefa ou tarefas que o projeto foi está
sendo desenvolvido, ou seja, não será avaliada nenhuma função que possa ser
também externa ao projeto, mesmo que estas estejam dentro das fronteiras desse,
 53

pois isso implicaria na análise de outros projetos que devido a recente condição de
medição no desenvolvimento de sistemas teríamos que criar a maioria da
documentação necessária. Isso não foi feito, pois estenderia significativamente a
pesquisa e não traria maior contribuição ao seu objetivo além de aumentar o tempo
de pesquisa.
Terceiro passo foi a contagem da função de dados e funções transacionais.
Neste passo a documentação verificada e identificado os tipos de funções, também
foi avaliado a interação entre o sistema medido e outros sistemas que esse se
relacionaria. Levou-se em conta o número de entradas e saídas de dados fornecidas
pelo sistema ou por usuários que o utilizarão. Nesse momento foi estudado as
necessidades e funcionalidades levantadas no escopo do projeto em relação ao
sistema, a sua interatividade com outros sistemas e com o usuário desde o
momento da solicitação de um campo no sistema para preenchimento de dados até
a saída dos dados, sob a forma de informações em relatórios, gráficos e ou
consultas na tela solicitadas.
No quarto passo após a contagem das funções de dados e das funções
transacionais, foram dados a essas pesos de acordo com seu grau de
complexibilidade e no quinto foi calculado o fator de ajuste levado em consideração
os valores conseguidos com as respostas dos desenvolvedores sobre cada projeto
às perguntas do quadro 2, e por fim foram calculados os pontos de função.

4.4 APLICAÇÃO DO MÉTODO

Nesse item será descrito a aplicação da APF em cada um dos projetos,

sendo o primeiro um projeto de desenvolvimento, que é o sistema de agendamento,
o segundo um projeto de alteração de aplicação que é o sistema de cadastro da
pós-lato e por fim o projeto de manutenção no formulário de inscrições online do
portal. Após uma breve descrição de cada projeto é conforme o relatado no
documento de escopo, será descrito a aplicação de cada uma das fases do método
proposto sobre cada projeto.
 53

O método foi aplicado seguindo os passos já descritos no item acima, porém

conforme sugestão encontrada no site BFPUG, que como já foi anteriormente
mencionado trata-se da representação do IFPUG no Brasil, foi utilizado para
cadastro dos dados levantados e calculo e resultado da PF, o Software APF Plus
disponível gratuitamente para download no site do BFPUG, que tem o seguinte
endereço <http://www.bfpug.com.br>. Esse software está na versão 1.3.0.0. ref.:4 de
10 de setembro de 2007 e tem direitos autorais creditados para Ivan Macenas,
Brasília, DF.

4.5 DESCRIÇÃO DO PROJETO SISTEMA DE AGENDAMENTO

O primeiro projeto a ser aplicado o novo método será o Sistema de

Agendamento, solicitado para solucionar necessidades da instituição em relação à
maneira que os laboratórios de informática e salas multimídia são reservados hoje.
Conforme descrito no documento de escopo é utilizado o sistema de mail
institucional via Web para realizar as reservas, que são feitas pelo escritório de
projetos via sistema de alocação de recursos conhecido como ADE, o qual gera um
arquivo PDF, que é utilizado pelo colaborador responsável pelos agendamentos dos
laboratórios de informática, e também pelo pelo colaborador responsável pelas salas
multimídia, para retirar as informações necessárias para a partir disso fazer o
agendamento propriamente dito utilizando o webmail.
O problema é a falta de informações, que gera um grande fluxo de e-mails e
também problemas na confirmação ao solicitante sobre sua reserva, gerando
transtornos ou conflitos de horários.
Esse sistema integrará todas as reservas em uma única aplicação na
Intranet, integrando-se com a agenda do Sistema acadêmico LOGOS e ADE, já
poderá ser visualizado todas as reservas de aula realizadas ainda no início do
semestre.
Os usuários poderão visualizar os horários disponíveis para as
salas/laboratórios desejadas(os), escolher os horários preenchendo o formulário de
solicitação, dessa forma o agendamento desse recurso ficará sinalizada para o
 53

escritório de projetos. O responsável pelas reservas fará a análise da solicitação e

confirmará ou não a reserva ao solicitante através de um e-mail gerado pelo
sistema.
O sistema permitira reservas com períodos diários, semanais e mensais,
devendo no caso de reservas para salas multimídia, respeitar um limite (duas por
mês, para a mesma disciplina), porém poderá haver exceções, sendo liberadas pelo
escritório de projetos. Para as reservas dos laboratório, a aplicação deverá ter um
formulário para a solicitação de instalação de software, também a possibilidade de
cancelamento de reservas, visualização das disponibilidades de capacidade da sala
e número de máquinas e opção para que usuários docentes possam indicar as
disciplinas que lecionam.

4.6 TIPO DE CONTAGEM

Nesse projeto foi utilizada a contagem do tipo projeto em desenvolvimento,

pois se trata de uma aplicação ainda não utilizada.
Este calculo teve como objetivo à quantificação das funções solicitadas e
entregues ao usuário pela nova aplicação, conforme é explicado Vazquez et al.
(2007), nesse tipo de calculo poderia também ser incluindo as funções referentes ao
processo de conversão de dados, mas devido as limitações colocadas no escopo da
contagem isso não foi efetuado. O valor conseguido nesse calculo menos os PF
associados às atividades de conversão torna-se o tamanho da aplicação, após sua
implantação, embora seja apenas uma estimativa da funcionalidade que será
entregue ao usuário.

4.7 ESCOPO DA CONTAGEM E FRONTEIRA DA APLICAÇÃO

 53

Conforme informações visualizadas no documento de escopo dessa

aplicação e demais informações coletadas junto ao setor de desenvolvimento
podemos definir a fronteira da aplicação de maneira bastante clara e assim limitar
também o escopo da contagem apenas ao que foi desenvolvido para o próprio
sistema de agendamento.
Essa limitação da fronteira acontece porque, apesar desse sistema
necessitar de dados vindos dos sistemas LOGOS/ADE e dos sistemas acadêmicos
utilizados, esses dados não necessitam de nenhum tipo de conversão e/ou
desenvolvimento de sistemas próprios para sua importação, pois essa etapa já é
realizada por outros sistemas na captação de dados e informações necessárias para
seu funcionamento. Os dados dessa aplicação são armazenados em um segundo
banco de dados e já convertidos para o padrão utilizado pelo setor de
desenvolvimento em sua aplicações.

4.8 CONTAGEM DA FUNÇÃO DE DADOS E FUNÇÕES TRANSACIONAIS

As funções específicas da aplicação foram identificadas e agrupadas por

tipo de função, considerando a fronteira definida e apenas os componentes
solicitados pelo usuário e visíveis foram contados, isso se deu através do documento
de escopo nos itens declaração de escopo e requerimentos de negócio, também
pela demonstração gráfica do diagrama UML, diagrama ER do sistema, diagrama de
classes e finalmente pela descrição de cada um dos casos de uso, podemos calcular
os pontos de contagem de função de tipo de dados e funções transacionais, assim
verificando o grau de complexibilidade e contribuição de cada funcionalidade
conforme é mostrado no quadro 7.
Contagem dos pontos de função do projeto de desenvolvimento do agendamento
Descrição Tipo Td AR/TR Complexibilidade contribuição
Listar turmas AIE 4 1 Baixa 5
Listar espaços físicos AIE 4 2 Baixa 5
Listar reservas ALI 6 2 Baixa 7
Solicitação de reserva EE 10 1 Baixa 3
Aprovar/reprovar reserva EE 1 1 Baixa 3
Comunicar usuário ALI 6 1 Baixa 7
Verificar sobreposição SE 4 1 Baixa 4
Cancelar reserva EE 5 1 Baixa 3
 53

Editar reserva EE 10 2 Média 4

Carregar reserva CE 6 2 Baixa 4
Quadro 7 - contagem de pontos de função
Fonte: adaptado de Vazquez at al. (2007, p. 70).

Pode ser observado que a integração das reservas proposta na declaração

de escopo é demostrada no diagrama através da ligação da classe agendamento,
criada apenas para essa aplicação, e as classes espaço físico e usuário, que são
classes criadas para serem utilizadas em qualquer aplicação que necessite das
informações sobre o espaço físico ou sobre o usuário.
Conforme os dados já levantados o quadro 7, mostra que a função listar
turmas e listar espaços físicos são do tipo AIE, por terem seus dados relacionados
com entradas vindas de outros sistemas, de mesma forma as funções de listar
reserva e comunicar usuário são do tipo ALI, pois apenas registram e trabalham com
dados subjetivos a aplicação.
As funções Solicitação de reserva, Aprovação/reprovação de reserva,
Cancelamento de reservas e Editar reservas são do tipo Entradas Externas, pois
exigem a alimentação de dados e/ou confirmação desses dados por parte do usuário
e essas ações modificaram as informações registradas no sistema.
A função Verificar sobreposição é do tipo Saída Externa, pois gera uma nova
informação que é apresentada ao usuário através do cruzamento dos dados por ele
fornecido e os dados retirados do sistema.
A função Carregar reserva é considerada do tipo consulta externa, porque
apenas lista os dados já contidos no sistema não gerando novas informações
através de cruzamento de dados e/ou qualquer tipo de calculo. O quadro 7,
apresenta na coluna contribuição o cálculo dos pontos de função não ajustados.

4.9 CÁLCULO DO FATOR DE AJUSTE

Para o calculo do fator de ajuste foi feito através do software APF Plus,
conforme anteriormente mencionado, para isso o software utiliza o calculo: Fator de
 53

Ajuste [VAF] = [TDI] x 0,01 + 0,65, Onde: Nível de Influência [DI] = 0.5 e Nível de
Influência Total [TDI] = Σ DI e fazendo uma avaliação geral da funcionalidade da
aplicação levando em consideração as 14 características gerais do sistema. Foi
encontrado o fator conforme mostrado no quadro 8:

CÁLCULO DO FATOR DE AJUSTE DO SISTEMA DE AGENDAMENTO.

Características gerais do sistema (CGS) Peso atribuído
Comunicação de Dados 3
Funções Distribuídas 5
Performance 0
Equipamento 0
Volume de Transações 0
Entrada de Dados On-line 5
Interface com o Usuário 2
Atualizações On-line 3
Processamento Complexo 0
Reusabilidade do Código 3
Facilidade de Implantação 0
Facilidade Operacional 0
Múltiplos Locais 0
Facilidade de Mudanças 5
TOTAL 26
Fator de Ajuste 0,91
Quadro 8 – fator de ajuste do sistema de agendamento
Fonte: adaptado de Vazquez at al. (2007, p. 70).

4.9.1 Calcular Número de Pontos de Função Ajustados

Para calcular os pontos de função ajustados desse projeto foi realizado o

calculo de projeto de desenvolvimento através do APF Plus, conforme anteriormente
mencionado o software utiliza o seguinte calculo: DFP = (UFP + CFP) x VAF, onde:
DFP PF de projeto de desenvolvimento, UFP = PF não ajustados da aplicação a ser
instalada, CFP PF incluídos de conversão de dados e VAF Valor do fator de
ajuste. . Foi encontrado os resultado mostrado no quadro 9:
 53

Número de Pontos de Função Ajustados do sistema de Agendamento

Funções Contribuição
Arquivos Lógicos Internos
Listar turmas 5
Listar espaços físicos 5
Total 10
Arquivos de Interface Interna
Listar reservas 7
Comunicar usuário 7
Total 14
Entradas Externas
Solicitação de reserva 3
Aprovar/reprovar reserva 3
Cancelar reserva 3
Editar reserva 4
Total 13
Saídas Externas
Verificar sobreposição 4
Total 4
Consultas Externas
Carregar reserva 4
Total 4
Conversão
Total 0

TOTAL NÃO AJUSTADOS 45

FATOR DE AJUSTE 0,91
Número de Pontos de Função Ajustados 40,95
Quadro 9 – PF ajustados do sistema de agendamento
Fonte: adaptado de Vazquez at al. (2007, p. 70).

4.9.2 Resultados das medições do projeto de agendamento.

Segundo os dados fornecidos pelo software APF Plus podemos chegar aos
seguintes resultados, para atender as necessidades básicas de estimativas de um
projeto de software, conforme citado por Vazquez et al. (2007), ou seja para o
projeto temos:
• Estimativa de tamanho do produto a ser gerado é de 44,6
PF trabalhando-se com a contagem tipo estimativa;
 53

• Estimativa de esforço na execução do projeto é de 14

horas por PF;
• Estimativa de duração do projeto é 3,55 meses;
• Estimativa de custo do projeto é de r$ 6.473,12.

Os dados mencionados acima encontram-se no relatório de custo por prazo

do sistema de agendamento, este relatório foi emitido pelo software APF Plus –
Anexo D.

4.9.3 Descrição do projeto de Inscrição dos cursos de Pós-Graduação

O formulário de inscrição dos cursos de Pós-Graduação está no site da Pós-

Graduação, não era um formulário de interesse dos candidatos nos cursos
oferecidos pela instituição, mas sim um formulário para a inscrição de cursos que
estão sendo oferecidos, não possibilitando o registro de interesse do internauta
visitante em outros cursos não abertos no momento ou a sua indicação de interesse
em outros cursos que a instituição ainda não fornece. A procura dos interessados
em outros cursos é feita somente via e-mail ou contato telefônico, o que fez com que
o setor de Pós-Graduação Identificasse a necessidade de criar um formulário
eletrônico para agilizar o processo de abertura dos cursos oferecidos.
O sistema necessitou da possibilidade de emissão e visualização de
relatórios pela intranet, que servirão de apoio à decisão da abertura ou não de cada
curso e também poderão agilizar as matrículas em caso positivo da abertura do
curso procurado.

4.9.4 Tipo de contagem

 53

Nesse projeto foi utilizada a contagem do tipo projeto de atualização, uma

vez que a aplicação será iniciada com base no formulário já existente e apenas será
alterado para que a aplicação possa atender as funcionalidade necessárias para o
desenvolvimento da atividade específica, conforme o citado no documento de
escopo.

4.9.5 Escopo da contagem e fronteira da aplicação

Conforme informações visualizadas no documento de escopo dessa

aplicação e demais coletadas junto ao setor de desenvolvimento podemos concluir
que a fronteira desta aplicação será apenas sobre os arquivos desenvolvidos para a
mesma uma vez que não faz integração com nenhum outro sistema não
requisitando assim a necessidade de dados de arquivos externos.

4.9.6 IDENTIFICAÇÃO E CONTAGEM DA FUNÇÃO DE DADOS E FUNÇÕES

TRANSACIONAIS

As funções específicas da aplicação foram identificadas e agrupadas por

tipo de função, considerando a fronteira definida observada através do documento
de escopo nos itens declaração de escopo e requerimentos de negócio, também
pela demonstração gráfica do diagrama UML, diagrama ER do sistema e na
descrição de cada um dos casos de uso, podemos calcular os pontos de contagem
de função de tipo de dados e funções transacionais, assim verificando o grau de
complexibilidade e contribuição de cada funcionalidade conforme é mostrado no
quadro 10.
 53

Contagem dos pontos de função do projeto de alteração do formulário de inscrição

da Pós-Graduaçao
Descrição Tipo Td AR/TR Complexibilidade contribuição
Inscrição Pós-Graduação EE 23 7 alta 6
Gerar Boleto SE 7 2 Média 5
E-mail de Confirmação de SE 8 1 Baixa 4
Inscrição
Consulta candidatos CE 2 1 Baixa 3
interessados nos cursos
Quadro 10 – contagem de PF do projeto Pós-Graduação
Fonte: adaptado de Vazquez at al. (2007, p. 70).

A inscrição é uma função do tipo Entrada Externa, pois basicamente faz o

recebimento dos dados informados e vindo de fora da fronteira da aplicação,
através do próprio formulário digitado pelo usuário.
A função Gerar boleto é uma função do tipo Saída Externa, porque os dados
contidos na aplicação servirão de base para alimentar informações necessárias para
que o sistema que cria os boletos bancários. Sendo assim existe envio de dados ou
informações para fora da fronteira da aplicação, ou seja, quando o sistema de
boletos recupera informações. Algumas vezes poderá o sistema ter de calcular
informações sobre datas de vencimento referente a dias úteis e/ou último dia de
pagamento, isso é a principal característica de uma Saída Externa.
O envio de confirmação de inscrição também é considerada uma função do
tipo SE porque envia dados ao sistema de envio de email alterando o
comportamento e servindo como AIE desse outro sistema.
No quadro 10, temos a função consulta candidatos, essa é uma função do
tipo Consulta Externa pois apenas se encarrega de carregar os dados dos
candidatos sendo que para essa tarefa o sistema não modifica e/ou cruza dados,
apenas faz sua localização, dispensando o uso de fórmulas matemáticas ou cálculo,
também não cria dados derivados, não alterar o comportamento do sistema para
traze-los e essa consulta não alimenta dos de nenhum ALI.
 53

4.10 CÁLCULO DO FATOR DE AJUSTE

Para o calculo do fator de ajuste foi feito através do software APF Plus,
conforme anteriormente mencionado, para isso o software utiliza o calculo: Fator de
Ajuste [VAF] = [TDI] x 0,01 + 0,65, Onde: Nível de Influência [DI] = 0.5 e Nível de
Influência Total [TDI] = Σ DI e fazendo uma avaliação geral da funcionalidade da
aplicação levando em consideração as 14 características gerais do sistema. Foram
encontrados os fatores conforme mostrado no quadro 11, sendo que a segunda
coluna trata-se dos dados do projeto de desenvolvimento do formulário da Pós-
Graduação e a terceira os valores do projeto de melhoria.

Cálculo do Fator de Ajuste do formulário da Pós-Graduação

Peso atribuído
Características gerais do sistema (CGS)
Desenv. Melhoria
Comunicação de Dados 3 2
Funções Distribuídas 2 2
Performance 0 0
Equipamento 0 0
Volume de Transações 0 1
Entrada de Dados On-line 4 5
Interface com o Usuário 2 2
Atualizações On-line 0 0
Processamento Complexo 0 0
Reusabilidade do Código 0 0
Facilidade de Implantação 0 0
Facilidade Operacional 0 0
Múltiplos Locais 0 0
Facilidade de Mudanças 1 1
TOTAL 12 13
Fator de Ajuste 0,77 0,78
Quadro 11 – Fator de ajuste da Pós-Graduação
Fonte: adaptado de FATTO (2008, p. 2).

4.10.1 Calcular Número de Pontos de Função Ajustados

 53

Também foi feito utilizado o APF Plus para o calculo dos pontos de função
ajustados deste projeto, sendo utilizado o calculo de projeto de melhoria, uma vez
que a aplicação já existia, porém não tinha todas as funcionalidades então
solicitadas. O calculo para esse tipo de projeto é: EFP = [(ADD + CHGA + CFP) x
VAFA] + (DEL x VAFB), onde : EFP = PF de projeto de melhoria, ADD = UFP das
novas funcionalidades, CHGA = UFP das funcionalidades alteradas, depois da
melhoria, CFP = PF incluídos de conversão de dados, VAFA = VAF depois da
melhoria, DEL UFP das funcionalidades excluídas , VAFB = VAF antes da melhoria,
VAF=Valor do fator de ajuste, UFP=PF não ajustados da aplicação a ser instalada.
O fator de ajuste encontrado foi o mostrado no Quadro 12:

Número de Pontos de Função Ajustados do sistema do formulário da

Pós-graduação
Funções Contribuição
Entradas Externas
Inscrição Pós-Graduação 6
Total 6
Saídas Externas
Gerar Boleto 3
E-mail de Confirmação de Inscrição 3
Total 6
Consultas Externas
Consulta candidatos interessados nos cursos 4
Total 4
Conversão
Total 0

TOTAL NÃO AJUSTADOS 18

FATOR DE AJUSTE 0,78
Número de Pontos de Função Ajustados 7,02
Quadro 12 – PF do sistema da Pós-Graduação
Fonte: adaptado de Vazquez at al. (2007, p. 70).
 53

4.10.2 Resultados das medições do projeto do formulário da Pós-Graduação.

Segundo os dados fornecidos pelo software APF Plus podemos chegar aos
seguintes resultados, no projeto de melhoria do formulário da Pós-Graduação. Para
atender as necessidades básicas de estimativas de um projeto de software,
conforme citado por Vazquez et al. (2007), para o projeto de melhoria dessa
aplicação temos:

• Estimativa de tamanho do produto a ser gerado é de 7,02

PF trabalhando-se com a contagem tipo estimativa;
• Estimativa de esforço na execução do projeto é de 14
horas por PF;
• Estimativa de duração do projeto é 18 dias;
• Estimativa de custo do projeto é de r$ 1.019,09.

Os dados mencionados acima encontram-se no relatório de custo por prazo

do projeto de melhoria do formulário da Pós-Graduação, este relatório foi emitido
pelo software APF Plus – Anexo E.

4.10.3 Relatório comparativo entre os métodos

Primeiramente devemos deixar claro que a comparação entre os métodos

não tem como objetivo qualificar qual o melhor método quanto ao grau de precisão
em medidas, mas sim fazer uma comparação entre os métodos para tentar chegar a
conclusão de qual dos métodos poderá trazer um melhor retorno quanto a métricas
para um desenvolvimento de software alinhados a Governança de TI. Outro ponto
que deve ser entendido é que o método atualmente utilizado, não é exatamente o
método de Pontos de Caso de Uso, mas sim uma adaptação de suas
funcionalidades a fim de iniciar uma estimativa sobre a utilização das métricas de
 53

desenvolvimento e por fim este relatório não tem objetivo de apontar erros ou falhas
no atual trabalho que está sendo desenvolvido em relação as métricas de sistema
na instituição estudada, mas sim, verificar uma possível melhoria através da
apresentação de um novo métodos que poderá ser capaz de medir o
desenvolvimento das aplicações com métricas que poderão ser utilizadas para
auxiliar nas etapas de controle do framework de governança institucional e/ou em
um dos frameworks específicos já apresentados.
O método até em tão utilizado pelo setor é capaz em sua atual forma de
utilização demonstrar as seguintes medidas:

• Tamanho do projeto estimado pelo número de Pontos de

Caso de USO (PCU);
• Estimativa de pessoal para desenvolvimento de aplicação
baseados na Unidade PCUs por pessoa em um período de horas;
• Estimativa de produção de pessoa/hora para cada PCU;

• Estimativa do tamanho da equipe para cada projeto;

• Estimativa em horas para conclusão de projetos;
• Estimativa em meses para a conclusão de projetos.

Na documentação utilizada pelo setor não foi possível visualizar a utilização

de estimativas de custo e estimativas de esforço.
Ao se identificar a necessidade de desenvolvimento, manutenção ou
mesmo aquisição e/ou customização de um software para atender a novas
demandas de uma organização, sempre se questiona o tempo que será necessário
para a conclusão do projeto e quando esse projeto custará. Para poder responder
essas questões primárias é necessário que o sistema de medições utilizadas seja
capaz de medir os quatro processos básicos de estimativa de desenvolvimento de
software, ou seja:

• Estimativa de tamanho do produto a ser gerado;

• Estimativa de esforço empregado na execução do projeto;
• Estimativa de duração do projeto;
 53

• Estimativa de custo do projeto.

Conforme pode ser visto nos projetos de desenvolvimento do Sistema de

Agendamento e no projeto de modificação do formulário da Pós-Graduação, a
Análise de Pontos de Função (APF), pode gerar essas estimativas básicas. Além
disso a APF é capaz de também de gerar métricas para projetos que já tenham sido
desenvolvidos, mesmo que não exista documentação para esses projetos e ao
contrário da PCU a APF pode fazer essas estimativas independentes da criação dos
casos de uso.
A principal vantagem desse sistema de medidas é que os softwares podem
ser medidos mesmo que tenham sido desenvolvidos por terceiros, ou seja, por não
fazer uso obrigatório de documentação prévia para mensurar uma aplicação e/ou
sistema, a APF também pode ser utilizada para estimar projetos de aquisição e
produção de software por empresas contratadas.
Partindo das quatro estimativas básicas de desenvolvimento podemos
levantar com os resultados de uma APF inúmeros indicadores que
consequentemente poderão alimentar o framework de governança em TI.
Após algum tempo de utilização do método através de registros feitos ou
através de pesquisas feitas em projetos anteriores, mesmo que no tempo de sua
concepção a empresa utilizasse qualquer tipo de registro para as medições desses
projetos, segundo Vasques at. al. (2007), a Análise de Pontos de Função de um
conjunto de sistema e/ou aplicações desenvolvidas poderá ser utilizada para estimar
o dimensionamento de projetos em suas várias fases no seu ciclo de vida de
desenvolvimento e manutenção. Com esses dados a empresa poderá se beneficiar
de outro indicador muito importante no processo de estimativas que é a variação do
tamanho do projeto, assim além de contribuir para a melhoria contínua do processo
de desenvolvimento utilizado, isso fará com que a instituição possa ter conhecimento
dos fatores que contribuem para o aumento de tamanho do projeto, conhecido como
fator de crescimento(FC) dos projetos, indicador que poderá ser utilizado na
antecipação do crescimento do orçamento inicial do projeto.
Ao utilizar a APF poderemos verificar a relação entre a falta de definição de
cada etapa de seu ciclo de vida de desenvolvimento e o conhecimento de todos os
subprodutos gerados em cada uma dessas fases, ou seja, a definição do esforço
 53

para cada funcionalidade dentro de um projeto, fator será necessário para a

definição de estimativa de produtividade e prazo de entrega.
 53

5 CONCLUSÃO

Atualmente a Instituição busca um melhor posicionamento de mercado,

investindo no crescimento e acreditando que o investimento em tecnologia é um
fator importante para que isso ocorra. Baseando-se nisso a gerência de
tecnologia de informação (GTI) em suas últimas gestões busca a implantação da
governança de TI afim de satisfazer as necessidades da instituição para o
cumprimento das metas instituídas em seu Plano de desenvolvimento
institucional
A primeiro maneira utilizada para tentar medir o desenvolvimento dos
sistemas, foi a utilização da técnica de Pontos de Casos de Uso, que é uma
técnica voltada para medições de desenvolvimento de aplicações Orientadas a
Objetos, o que restringe parte das medições, uma fez que o setor de
desenvolvimento de sistemas na instituição existe há aproximadamente cinco
anos e as técnicas de orientação a objetos só iniciaram efetivamente a pouco
mais de dois anos. Sendo assim através da PCU não poderá ser medido os
projetos desenvolvidos antes do inicio da utilização da programação orientada a
objetos, o que restringe as medições apenas aos projetos desenvolvidos
atualmente, isto é, não contempla a medição de projetos de melhoria de
software, somente projetos de desenvolvimento. Essa impossibilidade de
medição em projetos de alteração, manutenção e/ou projetos já desenvolvidos
oferecem dificuldades a questões de auditorias que possam ser necessárias
nesses projetos, com isso coloca-se desfavorável a um dos princípios de
governança conforme prevê a SOX quanto a segurança e armazenamento de
informações. Isso é reforçado por Fernandes e Vladimir (2006), quando
enfatizam que a área de TI deve estar ciente de que os aplicativos transacionais
da empresa como os geradores de fatores contábeis e financeiros, devem ter a
possibilidade de implementar trilhas de auditora e verificação de processos.
Outro inconveniente é a obrigatoriedade de somente pode ser aplicada
em projetos de software cuja especificação tenha sido expressa por casos de
uso, ou seja, é necessário começar a desenvolver o sistema para começar a
 53

medi-lo, não possibilitando dessa forma a estimativas a partir das solicitações

dos usuários, mas somente após a análise do desenvolvimento. Isso ocasiona
inconvenientes de dependência do trabalho do analista para determinar prazos ,
tamanho da equipe para trabalhar no projeto e estimativas de custo. Isso
impossibilita duas das cinco decisões-chave para o alinhamento estratégico e
ações de TI, segundo Weill e Ross (2006), que são a visualização da
necessidade de aplicações de negócio que especifica a necessidade comercial
de aplicações de TI compradas ou desenvolvidas internamente, também não
possibilita a determinação prévia de investimentos e priorização de TI, definições
que acarretam na escolha de quais iniciativas devem ser financiadas e quanto se
deve gastar.
Além disso a PCU da forma como está sendo aplicada não possibilita as
estimativas de esforço e custo, duas das quatro estimativas básicas para
desenvolvimento de sistemas. Isso ocorre devido as desvantagens da falta de
uma organização responsável pela padronização ou evolução do método PCU.
O método de medições proposto nesse trabalho através da técnica de
Análise de Pontos de Função APF, possibilita algumas vantagens em relação ao
método atualmente utilizado, ou seja, ao PCU, em primeiro lugar a APF pode ser
utilizada para medir sistemas cujos requisitos foram expressos através de casos
de usos como também para medir sistemas cujos requisitos foram documentados
utilizando outras metodologias, assim podendo ser utilizada independente do
inicio do projeto e descrição do caso de uso pelo analista, agilizando as
possibilidade de orçamento do projeto apenas com as primeiras informações de
escopo informadas pelo usuários durante a solicitação do mesmo.
A APF é eficiente em fornecer as estimativas básicas que são de
fundamental importância para responder os dois principais questionamentos
sobre o desenvolvimento ou aquisição de softwares, ou seja, qual o tempo será
necessário para concluir o projeto e qual o custo deste projeto para a
organização. Isso é possível porque como podemos mostrar através da pesquisa
no resultado da aplicação do método nas aplicações de amostra, esse é capaz
de satisfazer o processo de estimativas de um projeto de software em suas
quatro atividades básicas, ou seja, estimar o tamanho do produto gerado, estimar
 53

o esforço empregado na execução do projeto, estimar a duração do projeto e o

custo do projeto, conforme exposto por Vazquez et al. (2007).
Alem disso, embora a APF não seja uma técnica perfeita, seu grau de
maturidade é grande e com relação ao seu uso no mercado, o IFPUG trabalha
continuamente para sua evolução, padronização e certificação dos profissionais,
além de manter uma base de dados de aplicações e sistemas dos mais variados
portes, devidamente catalogados e a disposição par benchmarket para
associados.
Devido as vantagens citadas acima da APF em relação a PCU,
recomendamos a utilização da APF, esperando que essa sua utilização seja
responsável por agregar valor às decisões tomadas pela GTI, pautando-se nos
princípios de Governança em TI que agregaram valor aos serviços prestados
pelo setor de desenvolvimento de sistemas através de ações ágeis que
permitiram responder aos seus clientes sobre prazos, custos e ou qualquer outra
estimativa necessárias e esperadas para o desenvolvimento de projetos na
instituição.
 53

6 REFERÊNCIAS

AGUIAR, Mauricio. PFI Pontos de Função de Implementação. Disponível em:

<http://www.bfpug.com.br/pfi>. acessado em: dez, 2007.
BATISTA, Emerson de Oliveira. Sistemas de Informação: uso consciente da
tecnologia para gerenciar. São Paulo, SP: Editora Saraiva, 2006. p. 38, 39.
BOCATER, Maria Isabel; CAMARGO; COSTA e SILVA. Código das Melhores
Práticas de Governança Corporativa. São Paulo: IBGC, 2007. p. 9,10.Disponível
em: <http://www.ibgc.org.br/imagens/StConteudoArquivos>. acessado em mai. 2007.
BRODBECK, A. & HOPPEN, N. Modelo de alinhamento estratégico para
implementação dos planos de negócio e de tecnologia de informação. Anais do
XXIV Encontro Nacional da ANPAD, Florianópolis
CAVALCANTE, Francisco; MISUMI, Jorge Yoshio; RUDGE, Luiz Fernando. Mercado
de Capitais, o que é, como funciona. Rio de Janeiro, RJ: Editora Campus, 2005, p.
109.
DROMOS, Tecnologia e Gestão: processos em sistemas e tecnologia de
informação. Disponível em: <http://www.dromostg.com.br/psti/pstigeral.htm>.
acessado em: abr, 2007.
DRUMOND, Fernanda P. . Introdução à Análise de Pontos de Função, 2004.
Disponível em:<http://www.ibpug.com.br>. acessado em abr, 2007.
FATTO, Cartão de Referência sobre Análise de Pontos de Função da FATTO.
FATTO Consultoria e Sistemas Ltda. 2008. Disponível em:<
www.fattoCS.com.br/cartao.asp>. acessado em mar. 2008.
FÉ, Ana Lúcia. TI Eficiente e Sem Atrasos. Revista Info Corporate, n 38. São Paulo,
SP: Editora Abril, 2006, p. 30.
FERNANDES, Aguinaldo Aragon; VLADIMIR, Ferraz de Abreu, Implantando a
Governança de TI, da Estratégia à Gestão dos Processos e Serviços. São
Paulo, SP: BRASPORT Livros e Multimídia Ltda, 2006. p. 10.
PHILLIPS, Joseph; LUCKEY, Teresa, Software Project Management For
Dummies. Indianapolis, Indiana, USA: Wiley Publishing, Inc. 2006. P. 14.
GALANTE, Terezinha Prado; POW, Elizabeth, Inglês Para Processamento de
dados. São Paulo, SP: Editora Atlas, 1999. p. 143.
GIL, Antônio Carlos. Como Elaborar Projeto de Pesquisa. 4.ed. São Paulo: Atlas,
2006. p. 41, 175.
HAZAN, Claudia; STAA, Arndt von. Análise e Melhoria de um Processo de
Estimativas de Tamanho de Projetos de Software. Monografias em Ciência da
Computação. PUCRJ, 2005.
IFPUG. Counting Practices Manual. Version 4.2, 2004. Disponivel em:
<http://www.ifpug.org>. acessado em: jan, 2007.
ITGI, IT Governance Institute. Student Book. ISACF, Information Systems Audit and
Control Foundation. CobiT 3rd Edition. CobiT in Academia, 2004, p. 15,16, 21.
Disponível em:<http://www.isaca.org>. acessado em: abr, 2007.
ITSMF - IT Service Management Forum Brasil. Melhores Práticas ITIL. Disponível
em:<http://www.itsmf.com.br/melhorespraticas.php >. acessado em: Mar, 2006.
KAPLAN, R. S.; NORTON, D. P. A estratégia em Ação: balanced scorecard. 21 ed.
São Paulo: Editora Campus,1997. p. 10,21.
 53

LAMB, Roberto. Empresas brasileiras descobrem na Governança Corporativa

as virtudes da transparência e da ética. Revista Administração no Milênio, ano 4,
n 12. Porto Alegre,RS: Escola de Administração da UFRGS, 2005. p. 12. Disponível
em <http://www.ea.ufrgs.br/publicacoes/Milenio/inverno%202005.pdf>. acessado
em : jun, 2007.
LAUDON, Laudon e Laudon C.; LAUDON, Jane P. . Sistemas de Informação
Gerencias: administrando a empresa digital, 5 ed. São Paulo: Pearson Education do
Brasil, 2006. P. 40.
O’BRIAN, James A. Sistema de Informação e as Decisões Gerenciais na Era da
Internet. 2 ed. São Paulo, SP: Editora Saraiva, 2004. p. 49,404,413.
PRADO, Lauro Jorge; Guia do Balanced Scorecard: série empresarial – balanced
scorecard, e-book 1. Ed. Jaguariaíva, PR: n LJP e-ZINE – A Revista Eletrônica da
Gestão, 2002. Disponível em:<http:/lauroprado.tripod.com/ezine>. acessado em nov.
2007.
ROSS, Jeanne W., PETER, Weill; Governança em TI: tecnologia da informação.
São Paulo, SP: M. Bookes, 2006. p. 22.
REZENDE, Denis Aleides; ABREU, Aline França de. Tecnologia da Informação,
Aplicada a sistemas de Informação Empresariais, 2 ed.: São Paulo, SP: Editora
Atlas, 2001. p. 133,134,135.
TAPAJÓS, Uires. Palestra de Governança de TI, SOX e COBIT, 2007.
CompanyWeb – TI & Negócios. p. 9, 11. Disponível em:
<http://www.companyweb.com.br/downloads/formulario.cfm>. acessado em jun,
2007.
TAPAJÓS, Uires. Palestra BSC e COBIT, 2007. CompanyWeb – TI & Negócios.
p. 9, 11. Disponível em:<http://www.companyweb.com.br/downloads/formulario.cfm>.
acessado em jun, 2007.
WOOD JR, Thomas; PICARELLI, filho: Remuneração Estratégica: a nova
vantagem competitiva. São Paulo: Atlas, 2004.
VAZQUEZ, Carlos Eduardo; SIMOES, Guilherme Siqueira; ALBERT, Renato
Machado. Analise de Pontos de Função: medições, estimativas e gerenciamento
de projetos de software. SP: Editora Érica, 2007.
YIN, Robert K. Estudo de Casos: planejamento e métodos. 3 ed. São Paulo:
Artimed Editora, 2005.
 53

7 ANEXOS

ANEXO A - O fluxo do processo de desenvolvimento de aplicações.

 53

ANEXO B – Escopo do projeto

Escopo Detalhado
1. Nome do Projeto

2. Parecer da Divisão de Infra-Estrutura

3. Cronograma
4.
Sistema Completo
Estimativa em horas
Tamanho da equipe
(pessoas)
Estimativa em meses

5. Requerimentos de Negócio (Casos de Uso)

Caso de Uso:
MONO MONNO
Atores:

Descrição:

6. Cancelamento

6.1. Data

6.2. Motivo

7. Data Início

8. Envolvidos

Nome Setor Observação

 53

ANEXO C – Gráfico do sistema Dotproject

 53

ANEXO D – Relatório do custo previsto para o projeto da Pós-Graduação

 53

ANEXO E - Relatório do custo previsto para o projeto da Pós-Graduação