Embed Size (px)
Citation preview
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
2008
635
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
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.........................................................................................................6
1.1 Problema de pesquisa...........................................................................................7
1.2 Objetivo da pesquisa.............................................................................................7
1.2.1 Objetivo geral ...................................................................................................7
1.2.2 Objetivos Específicos.......................................................................................7
1.3 justificativa.............................................................................................................8
2 REFERENCIAL TEÓRICO....................................................................................9
2.1 A GOVERNANÇA CORPORATIVA.....................................................................10
2.1.1 Finalidades da Governança Corporativa......................................................11
2.2 Sarbanes-Oxley (SOX)........................................................................................12
2.2.1 Impactos da SOX sobre a TI..........................................................................13
2.3 governança em ti.................................................................................................14
2.3.1 Modelo de governança em TI.........................................................................15
2.3.2 O Alinhamento Estratégico e Compliance....................................................16
2.4 FRAMEWORKS...................................................................................................17
2.4.1 BSC (Balanced Scorecard)............................................................................18
2.4.2 CobiT................................................................................................................20
2.4.3 ITIL .................................................................................................................22
2.5 ISO17799, BS7799 e ISO27001..........................................................................24
2.6 processos............................................................................................................24
2.6.1 Processos gerenciais.....................................................................................25
2.6.2 Processo de desenvolvimento de Software.................................................28
2.6.3 Etapas do Processo de Desenvolvimento de Software..............................28
2.7 Medições ou métricas..........................................................................................31
2.7.1 O que medir.....................................................................................................31
2.7.2 Contagem de Linhas de Código Fonte (LOCs)............................................32
2.7.3 Análise por Casos de uso..............................................................................32
2.7.4 Análise de Pontos por Função......................................................................34
2.7.5 Determinação do tipo de contagem..............................................................35
53
2.7.6 Identificação do escopo da contagem e fronteira da aplicação.................36
2.7.7 As funções do tipo de dado...........................................................................37
2.7.8 As funções do tipo transação........................................................................37
2.7.9 Determinar a contagem de pontos de função não ajustados.....................38
2.7.10 Determinar o fator de ajuste........................................................................38
2.7.11 Calculo dos pontos de função ajustados...................................................41
3 METODOLOGIA..................................................................................................42
3.1 Caracterização da Pesquisa................................................................................42
3.2 Limitação da pesquisa.........................................................................................43
3.3 descrição do desenvolvimento da pesquisa........................................................44
4 ESTUDO DE CASO.............................................................................................45
4.1 Histórico da instituição.........................................................................................45
4.1.1 O setor de desenvolvimento..........................................................................48
4.2 método de medição atual.....................................................................................50
DESCRIÇÃO.............................................................................................................53
4.2.1 Documentação................................................................................................53
4.3 método de medição proposto..............................................................................54
4.3.1 Método pontos de função..............................................................................55
4.4 Aplicação do método...........................................................................................56
4.5 descrição do projeto Sistema de agendamento...................................................57
4.6 Tipo de contagem................................................................................................58
4.7 Escopo da contagem e fronteira da aplicação.....................................................58
4.8 contagem da função de dados e funções transacionais......................................59
4.9 Cálculo do Fator de Ajuste...................................................................................60
4.9.1 Calcular Número de Pontos de Função Ajustados......................................61
4.9.2 Resultados das medições do projeto de agendamento..............................62
4.9.3 Descrição do projeto de Inscrição dos cursos de Pós-Graduação............63
4.9.4 Tipo de contagem...........................................................................................63
4.9.5 Escopo da contagem e fronteira da aplicação.............................................64
4.9.6 IDENTIFICAÇÃO E CONTAGEM DA FUNÇÃO DE DADOS E FUNÇÕES
TRANSACIONAIS.....................................................................................................64
4.10 Cálculo do Fator de Ajuste.................................................................................66
53
4.10.1 Calcular Número de Pontos de Função Ajustados....................................67
4.10.2 Resultados das medições do projeto do formulário da Pós-Graduação.68
4.10.3 Relatório comparativo entre os métodos...................................................68
5 CONCLUSÃO......................................................................................................71
6 REFERÊNCIAS...................................................................................................74
7 ANEXOS..............................................................................................................76
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.
Para que um projeto seja bem sucedido, cada lado desse triângulo deve
permanecer em equilíbrio com os outros dois.
Figura 1- triangulo de ferroFonte: Phillips e Luckey (2006)
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)
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
53
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
(bolsa NYSE, AMEX e Nasdaq), e impõe regras de governança corporativa, entre as
53
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
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.
Figura 2 – Modelo de Governança de TIFonte: Fernandes e Vladimir (2006, p. 33)
53
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
utilização parcial ou integral de cada um dos frameworks existentes dependerá
53
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).
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
nas empresas e na criação de valor para o cliente, transformando-se numa
Figura 4 – Modelo de alinhamentoFonte: Tapajos (2007a, p. 6)
53
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
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.
Figura 6 - Cobit Framework – Domínios e ProcessosFonte: Adaptado de ITGI (2004, p. 15
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.
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.
Figura 7 - estrutura do ITILFonte: Tapajós (2007b)
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.
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
Figura 8 – Áreas primordiaisFonte: Batista (2006, p. 38)
53
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.
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
Figura 9 – níveis decisórios x sistemas Fonte: adaptado de Rezende e Abreu (2001)
53
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
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
53
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
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.
Para Tapajós (2007b), o processo de desenvolvimento de software deve
possuir as fases mostradas na figura 10.
Figura 10 – fases do processo de desenvolvimentoFonte: Tapajós (2007b)
53
a) Avaliar: na fase de avaliação devem ser coletadas as 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.
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
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.
Figura 11 - contagem de Pontos de FunçãoFonte: adaptado de IFPUG (2004)
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.
(TD) – Quantidade de Tipos de Dados
(AR) – Quantidade de Arquivos Referenciados
(TR) – Quantidade de Tipos de Registro
Legenda
Contribuiçãocomplexibilidade
funcional
Quadro 1 – complexibilidade funcional e contribuiçãoFonte: 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 descrição1
1Comunicação de dados Descreve o nível em que a aplicação comunica-
se diretamente com o processador.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.
2
2
Processamento distribuído Descreve em que nível a aplicação transfere dados entre seus componentes.
53
n CGS descrição3
3
Performance Descreve em que nível os requisitos estabelecidos pelo usuário, sobre tempo de resposta, influenciam o projeto, desenvolvimento, instalação e suporte da aplicação.
4
4
Configuração altamente utilizada Descreve em que nível restrições computacionais influenciam no desenvolvimento 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.
5
5
Volume de transações Descreve em que nível o alto volume de transações influencia o projeto, desenvolvimento, instalação e suporte da aplicação.
6
6
Entrada de dados on-line Descreve em que nível são efetuadas entradas de dados na aplicação por, meio de transações interativas.
7
7
Eficiência do usuário final As funções on-line fornecidas pela aplicação enfatizam um projeto para o aumento da eficiência do usuário final
8
8
Atualização on-line Descreve em que nível os arquivos lógicos internos são atualizados de forma on-line. Acessibilidade, atalhos, ajudas e outros.
9
9
Complexibilidade de processamento Descreve em que nível o processamento lógico ou matemático influencia o desenvolvimento da aplicação.
1
10
Reutilização Descreve em que nível a aplicação e seu código foram especificamente projetadas, desenvolvidas, e suportadas para serem utilizadas em outras aplicações.
1
11
Facilidade de instalação Descreve um plano e/ou ferramentas de conversão e instalação foram fornecidos e testados durante a fase de teste do sistema.
1
12
Facilidade de operação Descreve em que nível a aplicação atende a alguns aspectos operacionais como: 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.
1
12
Múltiplos locais Descreve em que nível a aplicação foi especificamente projetada, desenvolvida e suportada para diferentes ambientes de hardware e software.
1
14
Facilidade de mudanças Descreve em que nível a aplicação foi especificamente desenvolvida, para facilitar a mudança de sua lógica de processamento ou estrutura de dados.
Quadro 2 - Características gerais do sistemaFonte: 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 VAFDFP 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 MelhoriaAFP = [(UFPB+ADD+CHGA)-(CHGB + DEL)] x VAFAUFPB UFP da aplicação antes da melhoria.CHGB UFP das funcionalidades alteradas, antes da melhoria.
Quadro 3 – formulas para calculo dos pontos de funçãoFonte: 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 etapasEtapas Descrição
Levantamento da documentação existente.
definição dos projetos a serem estudados; devantamento da documentação dos projetos
escolhidos.Estudo da documentação acima reunida.
confirmação dos dados necessários para o novo método na documentação já existente.
Comparação das métricas obtidas.
comparação do modelo atual de medição, com as métricas recomendadas para alcançar os objetivos da Governança de TI.
Aplicação do novo métodos
aplicação da APF nos projetos selecionados; 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:
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;
53
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 esforço
Os Cálculos tem base nos pontos de caso de uso. 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;
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.
53
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 existentes1proposta de projeto. documento de escopo do projeto.2especificação de necessidades de negócio.
também é vista no documento de escopo.
3documento de visão. existente, porém não aplicado nesse caso.
4modelo de entidades e relacionamentos.
modelo ER.
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çãoFonte: 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 agendamentoDescrição Tipo Td AR/TR Complexibilidade contribuição
Listar turmas AIE 4 1 Baixa 5Listar espaços físicos AIE 4 2 Baixa 5Listar reservas ALI 6 2 Baixa 7Solicitação de reserva EE 10 1 Baixa 3Aprovar/reprovar reserva EE 1 1 Baixa 3Comunicar usuário ALI 6 1 Baixa 7Verificar sobreposição SE 4 1 Baixa 4Cancelar reserva EE 5 1 Baixa 3
53
Editar reserva EE 10 2 Média 4Carregar reserva CE 6 2 Baixa 4
Quadro 7 - contagem de pontos de funçãoFonte: 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
Ajuste [VAF] = [TDI] x 0,01 + 0,65, Onde: Nível de Influência [DI] = 0.5 e Nível de
53
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 3Funções Distribuídas 5Performance 0Equipamento 0Volume de Transações 0Entrada de Dados On-line 5Interface com o Usuário 2Atualizações On-line 3Processamento Complexo 0Reusabilidade do Código 3Facilidade de Implantação 0Facilidade Operacional 0Múltiplos Locais 0Facilidade de Mudanças 5
TOTAL 26Fator de Ajuste 0,91
Quadro 8 – fator de ajuste do sistema de agendamentoFonte: 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 AgendamentoFunções Contribuição
Arquivos Lógicos InternosListar turmas 5Listar espaços físicos 5
Total 10Arquivos de Interface InternaListar reservas 7Comunicar usuário 7
Total 14Entradas ExternasSolicitação de reserva 3Aprovar/reprovar reserva 3Cancelar reserva 3Editar reserva 4
Total 13Saídas ExternasVerificar sobreposição 4
Total 4Consultas ExternasCarregar reserva 4
Total 4Conversão
Total 0
TOTAL NÃO AJUSTADOS 45FATOR DE AJUSTE 0,91
Número de Pontos de Função Ajustados 40,95Quadro 9 – PF ajustados do sistema de agendamentoFonte: 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;
Estimativa de esforço na execução do projeto é de 14 horas por PF;
53
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
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
53
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çãoInscrição Pós-Graduação EE 23 7 alta 6Gerar Boleto SE 7 2 Média 5E-mail de Confirmação de Inscrição
SE 8 1 Baixa 4
Consulta candidatos interessados nos cursos
CE 2 1 Baixa 3
Quadro 10 – contagem de PF do projeto Pós-GraduaçãoFonte: 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
Características gerais do sistema (CGS)Peso atribuído
Desenv. MelhoriaComunicação de Dados 3 2Funções Distribuídas 2 2Performance 0 0Equipamento 0 0Volume de Transações 0 1Entrada de Dados On-line 4 5Interface com o Usuário 2 2Atualizações On-line 0 0Processamento Complexo 0 0Reusabilidade do Código 0 0Facilidade de Implantação 0 0Facilidade Operacional 0 0Múltiplos Locais 0 0Facilidade de Mudanças 1 1
TOTAL 12 13Fator de Ajuste 0,77 0,78
Quadro 11 – Fator de ajuste da Pós-GraduaçãoFonte: 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çãoEntradas Externas
Inscrição Pós-Graduação 6Total 6
Saídas ExternasGerar Boleto 3E-mail de Confirmação de Inscrição 3
Total 6Consultas ExternasConsulta candidatos interessados nos cursos 4
Total 4Conversão
Total 0
TOTAL NÃO AJUSTADOS 18FATOR DE AJUSTE 0,78
Número de Pontos de Função Ajustados 7,02Quadro 12 – PF do sistema da Pós-GraduaçãoFonte: 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
desenvolvimento e por fim este relatório não tem objetivo de apontar erros ou falhas
53
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;
Estimativa de custo do projeto.
53
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
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ópolisCAVALCANTE, 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. Cronograma4.
Sistema CompletoEstimativa em horasTamanho 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
