115437403 PIM VII

Prévia do material em texto

1 
 
UNIP INTERATIVA 
PROJETO INTEGRADO MULTIDISCIPLINAR 
CURSOS SUPERIORES DE TECNOLOGIA 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
PROJETO INTEGRADO MULTIDISCIPLINAR VII 
ANÁLISE DE IMPACTO, PLANEJAMENTO, DESENVOLVIMENTO 
IMPLEMENTAÇÃO DE MELHORAS NOS PROCESSOS DE TI DA SOFTWARE 
DEVELOPER 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Araraquara /SP 2012 
 
 
 
2 
 
 
 
UNIP INTERATIVA 
PROJETO INTEGRADO MULTIDISCIPLINAR 
CURSOS SUPERIORES DE TECNOLOGIA 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
PROJETO INTEGRADO MULTIDISCIPLINAR VII 
ANÁLISE DE IMPACTO, PLANEJAMENTO, DESENVOLVIMENTO 
IMPLEMENTAÇÃO DE MELHORAS NOS PROCESSOS DE TI DA SOFTWARE 
DEVELOPER 
 
 
 
 
 
 
 
 
 
 NOME: HIGOR VILLA GANDRA 
 RA: 1127303 
 CURSO: CURSO SUPERIOR DE TECNOLOGIA 
 EM GESTÃO DA TECNOLOGIA 
 DA INFORMAÇÃO 
 3º SEMESTRE 
 
 
Araraquara /SP 2012 
3 
 
RESUMO 
A Software Developer é uma Empresa de Desenvolvimento de Sistemas, 
localizada na Cidade de Araraquara - SP. A Empresa vem apresentando alguns 
problemas em seus processos de Desenvolvimento, Documentação e serviços de 
Help Desk em seus processos. Em face destes problemas, a empresa contratou a 
Consulting, empresa especializada desenvolvimento de software para Bancos, tendo 
como principais produtos os Sistemas de Consórcio, Financiamentos e 
Empréstimos. A empresa Consulting elaborou um estudo contendo Análise de 
Impacto, Planejamento, Desenvolvimento e como implementar melhorias nos 
processos de TI da contratante Software Developer. 
Serão usados modelos de Boas Práticas para a Melhoria do Processo de 
Desenvolvimento de Software, orientados pela Governança de TI e pelo CMMI, 
SOX, Cobit e ITIL. 
 
 
 PALAVRAS-CHAVE: desenvolvimento, melhorias, 
planejamento, análise, processos. 
 
 
 
 
 
 
 
 
 
 
 
4 
 
Abstract 
The Software Developer is an Enterprise Systems Development, located in the city of 
Araraquara - SP. The Company has presented some problems in their processes 
Development, Documentation and Help Desk services in their processes. In the face 
of these problems, the company hired Consulting, a company specializing in software 
development banks, the main products Systems Consortium, loans and financing. 
The company produced a study containing Consulting Impact Analysis, Planning, 
Development and how to implement process improvements to IT Contractor Software 
Developer. 
Models will be used Good Practices for Improving the Software Development 
Process, driven by the IT Governance and CMMI, SOX, COBIT and ITIL. 
 
 
 KEYWORDS: development, improvement, planning, analysis, 
processes. 
 
 
 
 
 
 
 
 
 
 
 
 
 
5 
 
SUMÁRIO 
 
 1- Introdução.................................................................................................07 
1.1- Documentação de Softwares....................................................................08 
1.2- Uso da Documentação..............................................................................08 
1.3- Documentação do Processo......................................................................08 
1.4- Documentação do Produto........................................................................09 
 1.4.1.- Documentação do Usuário..................................................................10 
 1.4.2- Documentação do Sistema..................................................................11 
1.5- Documentação do Código..........................................................................11 
 1.5.1- Escolha de Nomes...............................................................................12 
 1.5.2- Organização Visual..............................................................................12 
1.6- Qualidade dos Documentos.......................................................................12 
 
2- Gerenciamento de Riscos..........................................................................13 
 2.1- Gerência de Riscos no CMMI ....................................................................14 
 
 2.2- PMBOK.......................................................................................................16 
 
2.3- Gerência de Risco com PMBOK...............................................................17 
2.4- Processo de Gerenciamento de Risco.......................................................18 
2.5- Plano de Gerenciamento de Risco.............................................................19 
 3- Lei SOX.........................................................................................................19 
 
 
 
6 
 
3.1- Aspectos do Desenvolvimento da Lei SOX...............................................19 
3.2- Cobit e Itil...................................................................................................20 
3.3- Cobit...........................................................................................................21 
3.4- Itil...............................................................................................................21 
 3.4.1- Service Desk e Itil................................................................................22 
3.5- Governança de TI e Governança Corporativa...........................................26 
 
 4- Software Livre..............................................................................................28 
4.1- GPLI...........................................................................................................29 
 
 5- Conclusão......................................................................................................29 
 6- Bibliografias / Referências...........................................................................29
7 
 
Introdução 
 
Realizado a análise dos problemas encontrados na empresa Software 
Developer, notou-se que alguns processos necessitam de melhorias para que haja 
um funcionamento dentro dos requisitos de qualidade e legalidade. 
 As melhorias citadas abrangem as áreas de Governança de TI, Gestão de 
Qualidade e Sistemas para Internet e Softwares Livres. Cada melhoria citada tem 
papel fundamental nas melhorias dos processos da empresa Software Developer. 
 Serão usados como base os modelos de boas práticas para a Melhoria dos 
Processos de Desenvolvimento de Softwares, objetivando processos que permitam 
desenvolver softwares com qualidade dentro de prazos, custos e requisitos 
definidos. 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
8 
 
 
1.1- Documentação de Softwares 
 
Qualquer software deve ter uma quantidade razoável de documentação. 
- Documentos de trabalho. 
- Manuais de usuário produzidos profissionalmente. 
 
Em geral, a maioria destes documentos é produzida por engenheiros de 
software. 
Uma parte considerável dos custos de um projeto pode ser gasta com 
documentação. 
 
1.2- Uso da Documentação 
 
Meio de comunicação entre os membros de um grupo de desenvolvimento; 
Informações para as pessoas que venham a fazer manutenção no sistema; 
Informações à gerência de modo a ajudar a planejar, fazer o orçamento e o 
cronograma; 
Informações para ensinar aos usuárioscomo utilizar e administrar o sistema. 
 
 
1.3- Documentação do Processo 
 
É produzida para que o processo de desenvolvimento do software seja 
administrável 
Registram os processos de desenvolvimento e manutenção do software. 
Documentação do Processo - Categorias 
-Planos estimativos e cronogramas. 
 Produzidos por gerentes 
 
 
 
9 
 
 Usados para prever e controlar o processo. 
 
-Relatórios 
 Descrevem como os recursos foram utilizados durante o 
desenvolvimento do software 
 
-Padrões 
 Estabelecem como o processo deve ser implementado; 
 Podem ser organizacionais, nacionais, ou Internacionais. 
 
-Memorandos, comunicações, mensagens eletrônicas 
 Registram as comunicações entre gerentes e engenheiros de 
software 
 
-Documentos técnicos de trabalho 
 Registram as ideias e pensamentos dos engenheiros de software. 
 Descrevem estratégias de implementação. 
 Registram problemas já identificados. 
 Especificam as razões para as decisões de projeto. 
 
 
1.4- Documentação do Produto 
 
 Descreve o software que está sendo desenvolvido; 
 É muito utilizada depois que o sistema é implementado, mas é 
essencial também para a administração do processo de 
desenvolvimento 
 Descreve o software produzido. 
 
Tem vida longa e deve estar sempre atualizada em relação ao código. 
Divide-se em: 
 
 
 
10 
 
 Documentação do usuário. 
 Documentação do sistema 
 
1.4.1.- Documentação do Usuário 
 
Deve levar em conta os diversos tipos de usuários. É importante distinguir 
entre os vários usuários. Exemplo: 
 Usuários finais 
 Usam o software para auxiliá-los em alguma tarefa 
 Não estão interessados em detalhes técnicos ou administrativos. 
 Administradores do sistema 
 Responsáveis pela administração do software 
Ex: operadores, gerentes de rede, etc. 
Descrição funcional do sistema 
 Requisitos gerais do sistema 
 Serviços fornecidos por ele 
Manual de introdução 
 Apresenta uma introdução informal do sistema e descreve seu uso 
normal 
 Deve explicar como começar a usar o sistema e como os usuários 
podem utilizar as facilidades oferecidas pelo sistema 
 
Manual de referência 
 Descreve as facilidades do sistema e seu uso 
 Fornece uma lista das mensagens de erro e descreve como agir 
quando os erros ocorrerem 
 Deve ser completo e técnicas de descrição formal podem ser 
utilizadas 
 
Documento de instalação 
 
 
 
11 
 
 Descreve como instalar o sistema 
 Especifica a plataforma mínima necessária à sua instalação 
 
Manual do administrador do sistema. 
 Informações relevantes para uma boa administração do sistema 
 
Manual de referência rápida do sistema. 
 Informações concisas das principais funções do sistema e como 
utilizá-las 
 Mensagens de erros mais comuns. 
 
Ajuda on-line 
 
1.4.2- Documentação do Sistema 
 
 Descreve a implementação do sistema, desde a especificação dos 
requisitos até o plano de testes. 
 É importante que seja estruturada com overviews levando a 
especificações mais detalhadas e formais de cada aspecto do 
sistema. 
Documento de requisitos 
 Descrição da arquitetura do sistema 
 Descrição da arquitetura de cada um dos programas 
 Listagens do código fonte dos programas 
 
 
1.5- Documentação do Código 
 
Pode ser extremamente útil para melhorar (facilitar) o entendimento dos 
programas: 
 Escolha de nomes; 
 
 
 
12 
 
 Organização visual; 
 Comentários. 
 
1.5.1- Escolha de Nomes 
Os nomes devem ser significativos em relação ao que eles representam. 
Identificadores maiores melhoram a compreensão dos programas, mesmo 
em programas pequenos. 
Identificadores grandes demais dificultam sua digitação e podem se tornar 
uma fonte de erros. 
 
1.5.2- Organização Visual 
Maneira como o código aparece na tela do computador ou em uma listagem. 
Os padrões de boa codificação mais aceitos incluem: 
 Um único comando por linha; 
 Espaçamento entre os componentes dos 
comandos; 
 Indentação. 
Devem ser usados para explicar o que o software faz, ao invés de como ele faz. 
 
 
1.6- Qualidade dos Documentos 
 
A qualidade da documentação é tão importante quanto a qualidade do 
código. 
Aspectos importantes para se conseguir produzir bons documentos incluem: 
 Planejamento (ou projeto) dos documentos; 
 A existência de padrões a serem seguidos; 
 Procedimentos de garantia de qualidade. 
 
Padrão do Processo de Documentação 
 
 
 
 
13 
 
-Procedimentos de desenvolvimento: 
 Ferramentas; 
 Procedimentos de qualidade. 
 Flexíveis para lidar com todos os tipos de documentos; 
 
Aplicam-se a todos os documentos (de um projeto) 
 Identificação; 
 Estrutura; 
 Apresentação; 
 Indicação de mudanças. 
 
Fonte: 
<http://cps.erp5.org/workspaces/project/erp5_brasil/documentacao_dos_pro/transpar
encias_sobre/downloadFile/file/ProjetoDocumentacao1.pdf?nocache=1090370633.4
9> Acesso em: 10 out 2012 
 
 
2- Gerenciamento de Riscos 
 
O gerenciamento de riscos trabalha justamente com a incerteza, visando à 
identificação de problemas potenciais e de oportunidades antes que eles ocorram, 
com o objetivo de eliminar ou reduzir a probabilidade de ocorrência e o impacto de 
eventos negativos para os objetivos do projeto, além de potencializar os efeitos da 
ocorrência de eventos positivos. O gerenciamento de riscos é abordado por vários 
modelos que controlam a qualidade do processo de desenvolvimento de software 
dentre os quais o PMBOK, o CMMI, o RUP e o MSF. O CMMI (Capability Maturity 
Model Integration for Software) provê um framework para a implantação e melhoria 
do processo de software das organizações. O RUP (Rational Unified Process) é um 
processo baseado em melhores práticas de Engenharia de Software. O MSF 
(Microsoft Solutions Framework) tem sido usado pela Microsoft como o seu “método” 
para desenvolvimento de soluções de software dentro da Microsoft e também para 
 
 
 
14 
 
os milhares de clientes e parceiros da Microsoft em todo o mundo. O PMBOK 
(Project Management Body of Knowledgement) trata do gerenciamento de projetos 
de uma forma ampla, não sendo específico para software. 
 
 
2.1- Gerência de Riscos no CMMI 
 
O CMMI (Capability Maturity Model Integration) é considerado um modelo de 
gestão de processos que tem como objetivo prover às empresas, um conjunto de 
melhores práticas que possa suportar a melhoria contínua de seu desempenho, bem 
como ser referência para eventuais comparações por meio de seus níveis de 
maturidade e capacidade. O CMMI contém práticas (Genéricas e Específicas) 
necessárias à maturidade em disciplinas específicas (Systems Engineering (SE), 
Software Engineering (SE), Integrated Product and Process Development (IPPD), 
Supplier Sourcing (SS)). 
Desenvolvido pelo SEI (Software Engineering Institute) da University 
Carnegie Mellon, o CMMI é uma evolução do CMM 2 e procura estabelecer um 
modelo único para o processo de melhoria corporativo, integrando diferentes 
modelos e disciplinas. O CMMI-SW contém duas representações: por estágios, e 
contínua. A representação por estágios trata do nível de maturidade da organização 
como um todo, contendo cinco níveis de maturidade: inicial, gerenciado, definido, 
gerenciado quantitativamente e em otimização. 
1- A Representação Contínua: Possibilita à organização utilizar a ordem de 
melhoria que melhor atender os objetivos de negócio da empresa. 
 
É caracterizado por Níveis de Capacidade(Capability Levels): 
Nível 0: Incompleto (Ad-hoc) 
Nível 1: Executado (Definido) 
Nível 2: Gerenciado / Gerido 
Nível 3: Definido 
 
 
 
15 
 
Nível 4: Quantitativamente gerenciado / Gerido quantitativamente 
Nível 5: Em otimização (ou Optimizado) 
 
2-Representação Por Estágios: Disponibiliza uma seqüência pré-
determinada para melhoria baseada em estágios que não deve ser desconsiderada, 
pois cada estágio serve de base para o próximo. 
 
É caracterizado por Níveis de Maturidade (Maturity Levels): 
Nível 1: Inicial (Ad-hoc) 
Nível 2: Gerenciado / Gerido 
Nível 3: Definido 
Nível 4: Quantitativamente gerenciado / Gerido quantitativamente 
Nível 5: Em otimização 
 
Cada nível é constituído por um conjunto de áreas de processos, compostas 
por objetivos específicos e objetivos genéricos. Cada objetivo específico pode ser 
composto por um conjunto de práticas específicas. 
Um objetivo específico (SG, Specific Practices by Goal) descreve as 
características que devem estar presentes para satisfazer uma área de processo. 
Uma prática específica (SP, Specific Practices) é a descrição de uma 
atividade que é considerada importante para se alcançar o objetivo específico a ela 
associado. 
 
A problemática do risco é abordada nas áreas de processo Planejamento do 
Projeto, Monitoração e Controle do Projeto, e Gerência de Risco. As duas primeiras 
áreas de processo estão no nível 2 e a última está no nível 3 do CMMI-SW. No 
Planejamento do Projeto, tem-se o SG “Desenvolvimento do Plano do Projeto” com a 
SP “Identificar os Riscos do Projeto”, que consiste na identificação e na análise dos 
riscos para se determinar o impacto, a probabilidade de ocorrência e o período em 
 
 
 
16 
 
que podem ocorrer, para que os riscos possam ser priorizados. Na Monitoração e 
Controle do Projeto, tem-se o SG Monitorar o Projeto de Acordo com o Plano, onde 
está inserido a SP Monitorar os Riscos do Projeto. A Gerência de Risco no CMMI 
tem por finalidade identificar potenciais problemas antes que ocorram, de forma que 
as atividades de administração desses riscos possam ser planejadas e realizadas, 
de acordo com suas necessidades, ao longo do ciclo de vida do produto ou projeto, 
para mitigar possíveis impactos adversos. (ROCHA e BELCHIOR, 2004) 
Fonte: <http://www.flf.edu.br/revista-flf/monografias-
computacao/monografia_thiago_coelho.pdf> Acesso em: 10 out 2012. 
 
 
2.2- PMBOK 
O PMI (Project Management Institute) é uma organização internacional sem 
fins lucrativos, fundada em 1969 por um grupo de cinco voluntários, na Filadélfia - 
Pensilvânia - EUA. O principal objetivo do PMI tem sido a definição e divulgação das 
melhores práticas em gestão de projetos. Além de desenvolver normas, seminários, 
programas educacionais e certificação profissional. Possui mais de 100.000 (cem 
mil) membros em todo o mundo e já certificou mais de 50.000 (cinqüenta mil) PMP 
(Project Management Professional). O PMI estima que 10 trilhões de dólares sejam 
gastos anualmente no mundo em projetos, o que equivale a aproximadamente 25% 
do PIB mundial, e que cerca de 16,5 milhões de profissionais estão envolvidos 
diretamente com a Gerência de Projetos no mundo. Este volume de projetos e 
mudanças constantes no cenário competitivo mundial gera a crescente necessidade 
de resultados mais rápidos, com qualidade e a um custo competitivo. Fatores como 
a globalização do mercado e aquisições de novas tecnologias emergentes, tornam 
cada vez maior a Gerência de Projetos um assunto da mais alta importância para as 
organizações e para sua capacidade de sobrevivência. Pesquisas realizadas pelo 
PMI mostram que 75% dos seus membros indicaram que, nos próximos anos, suas 
empresas estarão dando maior importância para a gerência de projetos. 
Fonte: <http://www.flf.edu.br/revista-flf/monografias-
computacao/monografia_thiago_coelho.pdf> Acesso em: 10 out 2012 
 
 
 
17 
 
 
2.3- Gerência de Risco com PMBOK 
 
O desenvolvimento de software tem avançado tecnologicamente em rápidas 
proporções, mas existem fatores que ocorrem desde o começo desse avanço, são 
eles: os erros de gestão e a falta de sucesso do software desenvolvido, muitas vezes 
não atendendo o que cliente desejava. Para o sucesso ser completo, o produto final 
deve ser entregue dentro do prazo, com o custo especificado, e ser realmente aquilo 
que o cliente necessitava. 
A Gerência de Projetos é uma solução para os problemas que as equipes de 
desenvolvimento de Software vêm enfrentando, porque é distribuída em áreas de 
conhecimento, onde cada uma delas descreve seus respectivos processos a fim de 
garantir que os objetivos planejados sejam atingidos. As técnicas de gerenciamento 
de 32 projetos estão sendo aprimoradas constantemente, buscando sempre garantir 
o sucesso dos processos. O Project Management Body of Knowledge, também 
conhecido como PMBOK é um conjunto de práticas em gerência de projetos 
levantado pelo Project Management Institute (PMI) e constituem a base da 
metodologia de gerência de projetos do PMI. Estas práticas são compiladas na 
forma de um guia, chamado de Guia do Conjunto de Conhecimentos em 
Gerenciamento de Projetos, ou Guia PMBOK. (ALENCAR, 2006) O Gerente de 
projetos é a pessoa responsável pela realização dos objetivos do projeto, 
identificando às necessidades, estabelecendo objetivos claros e possíveis de ser 
alcançados e tentar equilibrar qualidade, escopo, tempo e custo, a ainda atender às 
expectativas das partes interessadas no projeto. Ele e sua equipe deverão seguir um 
código de ética e conduta profissional para aqueles que possuem a certificação 
PMP. No gerenciamento de projetos são aplicados os conhecimentos, habilidades, 
ferramentas e técnicas às atividades do projeto e é realizado através da aplicação e 
da integração das seguintes áreas de competências gerências, são elas: 
Gerenciamento de Integração, Gerenciamento de Escopo, Gerenciamento de 
Tempo, Gerenciamento do Custo, Gerenciamento da Qualidade, Gerenciamento dos 
 
 
 
18 
 
Recursos Humanos, Gerenciamento da Comunicação, Gerência de Aquisições e 
Gerência de Riscos 
Fonte: <http://www.flf.edu.br/revista-flf/monografias-
computacao/monografia_thiago_coelho.pdf> Acesso em: 10 out 2012 
 
 
2.4- Processo de Gerenciamento de Risco 
 
O inicio de um projeto é marcado por um grande esforço. No planejamento 
do projeto, são realizadas reuniões tendo como foco os objetivos do projeto: Escopo, 
Qualidade, Prazo e Custo. Neste momento já é importante pensar nos riscos pois à 
medida que os objetivos vão se consolidando, os possíveis riscos vão se tornando 
mais prováveis, podendo comprometer o andamento do projeto. 
Os processos do gerenciamento de riscos do projeto estão dispostos da 
seguinte forma: 
a. Plano de Gerenciamento do Risco: decide como abordar, planejar e executar as 
atividades de gerência de risco para um projeto; 
b. Identificação dos Fatores de Risco: determina quais riscos podem afetar o 
projeto e documenta suas características; 
c. Análise Qualitativa de Risco: realiza uma análise qualitativa dos riscos e as 
condições para priorizar seus efeitos nos objetivos do projeto. 
d. Análise Quantitativa de Risco: mede a probabilidade através de uma análise 
numérica e as conseqüências dos riscos e estima suas implicações para os objetivos 
do projeto. 
e. Planejamento de resposta ao Risco: desenvolve procedimentos e técnicas para 
melhorar as oportunidades e reduzir as ameaças para os objetivos do projeto. 
f. Monitoramento e Controle do Risco: monitora riscos residuais identifica novos 
riscos, executa planos deredução de risco e avalia sua eficácia durante todo o ciclo 
do projeto. 
 
 
 
19 
 
Esses processos não ocorrem isoladamente, eles interagem entre si e 
também com processos de outras áreas. 
 
2.5- Plano de Gerenciamento de Risco 
 
Dentro de um processo de administração de risco, o seu plano de 
gerenciamento visa garantir que o tipo, o nível e a visibilidade da Gerência de Risco 
sejam compatíveis com o risco e com a importância do projeto. O Plano gerencial de 
riscos deve ser terminado já no início do planejamento do projeto, por ser essencial 
para executar com sucesso as outras atividades de planejamento. O Plano do 
Gerenciamento do Risco é, portanto, um documento que explica como será 
desenvolvido o processo gerencial do risco, o custo estimado e investido e a 
nomeação de responsabilidades aos gestores e envolvidos. Os processos do Plano 
de Gerenciamento de Riscos não atuam isoladamente, interagem entre si e com os 
processos de outras áreas, ocorrendo pelo menos uma vez em cada projeto. 
Fonte: <http://www.flf.edu.br/revista-flf/monografias-
computacao/monografia_thiago_coelho.pdf> Acesso em: 15 out 2012 
 
 
3.1- Aspectos do Desenvolvimento da Lei SOX 
Ao implantar a Lei SOX é necessário, que sejam adotadas boas práticas de 
governança corporativa, pois além da empresa conquistar espaço ela também obtém 
confiança por parte de todos os envolvidos na corporação, principalmente para os 
investidores, que vêem nessas boas práticas um diferencial para tomar decisões de 
investimento e da sua participação na mesma. 
De acordo com a Cartilha CVM (2002, p.1) define-se governança 
corporativa como segue: 
Governança corporativa é o conjunto de práticas que tem por finalidade 
otimizar o desempenho de uma companhia ao proteger todas as partes 
interessadas, tais como investidores, empregados e credores, facilitando o 
acesso ao capital. A análise das práticas de governança corporativa aplicada 
 
 
 
20 
 
ao mercado de capitais envolve, principalmente: transparência, eqüidade de 
tratamento dos acionistas e prestação de contas. 
Complementa Steinberg (2003, p.18), como definição usual em sua 
publicação: 
... constitui o conjunto de práticas de relacionamentos entre 
acionistas/cotistas, conselho de administração, diretoria executiva, auditoria 
independente e conselho fiscal com a finalidade de aprimorar o desempenho 
da empresa e facilitar o acesso ao capital. 
Nas definições acima, é possível considerar que boas práticas de governança 
corporativa juntamente com o mercado de capitais buscam envolvimento dos 
stakeholders (públicos de interesse), acionistas e controladores através da 
transparência das informações, tratamento igual para todos os acionistas e 
prestação de contas. 
Segundo Andrade e Rossetti, citado por (2004 Gallon e Beuren 2006, p.4), 
resumem os diversos conceitos de governança corporativa a partir de expressões-
chave que procuram definir sua diversidade e abrangência. 
 
 
Fonte: < 
http://www.praticacontabil.com/contadorperito/Lei_Sarbanes_Oxley_e_seus_efeitos.
pdf > Acesso em: 15 out 2012 
 
3.2- Cobit e Itil 
Todo Projeto estará alinhado com as melhores praticas orientadas pelo Cobit e ITIL. 
O CobiT está dividido em quatro domínios: 
1. Planejamento e organização. 
2. Aquisição e implementação. 
3. Entrega e suporte. 
4. Monitoração. 
 
 
 
21 
 
 
Fonte: < http://efagundes.com/artigos/COBIT.htm> Acesso em: 15 out 2012 
 
3.3- Cobit 
O CobiT é um guia para a gestão de TI recomendado pelo ISACF 
(Information Systems Audit and Control Foundation, www.isaca.org). O CobiT inclui 
recursos tais como um sumário executivo, um framework, controle de objetivos, 
mapas de auditoria, um conjunto de ferramentas de implementação e um guia com 
técnicas de gerenciamento. As práticas de gestão do CobiT são recomendadas 
pelos peritos em gestão de TI que ajudam a otimizar os investimentos de TI e 
fornecem métricas para avaliação dos resultados. O CobiT independe das 
plataformas de TI adotadas nas empresas. 
Fonte: < http://efagundes.com/artigos/COBIT.htm> Acesso em: 15 out 2012 
 
3.4- Itil 
 
 
 
22 
 
O ITIL™ (Information Technology Infrastructure Library) é o modelo de 
referência para gerenciamento de processos de TI mais aceito mundialmente. A 
metodologia foi criada pela secretaria de comércio (Office of Government 
Commerce, OGC) do governo Inglês, a partir de pesquisas realizadas por 
Consultores, Especialistas e Doutores, para desenvolver as melhores práticas para a 
gestão da área de TI nas empresas privadas e públicas. Atualmente se tornou a 
norma BS-15000, sendo esta um anexo da ISO 9000/2000. O foco deste modelo é 
descrever os processos necessários para gerenciar a infra-estrutura de TI 
eficientemente e eficazmente de modo a garantir os níveis de serviço acordados 
com os clientes internos e externos “As normas ITIL™ estão documentadas em 
aproximadamente 40 livros, onde os principais processos e as recomendações das 
melhores práticas de TI estão descritas. O ITIL™ é composto por módulos. Os mais 
importantes são o “”IT Service Support”" e o “”IT Service Delivery”". 
Características do ITIL™ 
• Modelo de referência para processos de TI não proprietário; 
• Adequado para todas as áreas de atividade; 
• Independente de tecnologia e fornecedor; 
• Baseado nas melhores práticas; 
• Um modelo de referência para a implementação de processos de TI; 
• Checklist testado e aprovado; 
• O que fazer e o que não fazer. 
Fonte: < http://www.profissionaisdetecnologia.com.br/blog/?p=168 
> Acesso em: 15 out 2012 
3.4.1- Service Desk e Itil 
 
 
 
23 
 
Há alguns anos, o Service Desk, infelizmente, era tratado apenas como uma 
área secundária dentro da empresa. TI costumava dar mais valor as equipes de 
suporte e outras áreas consideradas “mais nobres para o negócio”, deixando para a 
Central de Serviços um papel secundário. Com a implementação das melhores 
práticas em gerenciamento de serviços de TI (ITIL®®), essa visão finalmente e de 
maneira muito justa foi alterada. 
O Service Desk é uma “entidade independente”, não apenas um processo 
dentro das melhores práticas. É uma função, um departamento, uma organização 
com importância estratégica para a prestação de serviços de TI. Por ser o ponto 
único de contato entre TI e usuários , ele é diretamente responsável pela percepção 
e satisfação dos mesmos. 
Antes de tudo, é preciso entender as diferenças entre os modelos existentes 
de centrais de atendimento. São três tipos: 
1. CALL CENTER: modelo de atendimento que registra as solicitações e encaminha 
para o suporte específico. Seu principal objetivo é atender grande volume de 
chamadas e direcioná-las. 
2. HELPDESK: modelo de atendimento que gerencia , coordena e resolve incidentes 
o mais rápido possível. Garantindo que requisições não sejam perdidas. 
3. SERVICE DESK: Além de apresentar as duas características anteriormente 
apresentadas, oferece serviços com foco em TI e nos negócios, lidando com 
incidentes e provendo interfaces para outros processos, como requisições de 
mudanças, níveis de serviços, gerência de disponibilidade, dentre outros. 
Resumindo, o Service Desk possui 3 características importantíssimas: 
 Representam o provedor de serviços. 
 Defendem pessoas, processos e tecnologia ( o lema do ITIL®®l!!!) 
 Operam no princípio da satisfação do usuário. 
 
 
 
24 
 
Ele é responsável por gestionar e acompanhar todas as solicitações 
(incidentes, mudanças, requisições, consultas, reclamações e etc). 
É um departamento cobrado e medido por: 
 Tempo deatendimento; 
 Tempo de espera; 
 Tempo de registro de um chamado; 
 Taxa de abandono de ligações; 
 Conhecimento técnico do assunto; 
 Controle das solicitações atendidas dentro e fora do prazo (SLA); 
 Acompanhamento do incidente (ciclo de vida do incidente); 
 Classificação da solicitação, etc. 
Implantar um service desk, na maioria das vezes, é uma das primeiras 
missões que uma implantação ITIL®® recebe. No início, significa concentrar todas 
as chamadas um único atendimento, abrindo se possível, outras formas de contato, 
como e-mail e também uma interface WEB do sistema de registro de chamados, 
permitindo ao usuário realizar o registro de forma independente. 
Durante a implantação é preciso atentar-se os três pilares importantíssimos 
do ITIL®® – pessoas, processos, ferramentas. São pontos de atenção: 
 selecionar corretamente o pessoal para atendimento e treiná-los 
pontualmente e periodicamente: é importante selecionar pessoas com 
conhecimento técnico, mas somente isso não é suficiente para garantir um bom 
atendimento. É preciso pessoas com os chamado “soft skills” : conhecimentos 
relacionados a capacidade comunicação, raciocínio lógico e rápido, presteza e 
postura adequada para que um bom atendimento seja realizado. Além disso, as 
equipes precisam ser treinadas quando a central de serviços for implementada e 
depois disso periodicamente para que o conhecimento não seja dissipado. 
 Definição correta de processos: é preciso definir como o será o atendimento, 
como a central de serviços se relacionará com os outros processos ITIL®®, 
 
 
 
25 
 
resumindo, qual o verdadeiro papel e responsabilidade da central de serviços 
para a organização. 
 Seleção correta de ferramentas para suportar o service desk: uma boa 
ferramenta de incidentes, uma boa central de distribuição de ligações são 
fatores chave para o sucesso de um service Desk. 
 Deve haver comprometimento gerencial, liderança pelo exemplo: os 
gerentes devem se comprometer inteiramente em tornar a central de serviços 
um sucesso, não abrindo exceções no ponto único de contato e auxiliando na 
conscientização de suas equipes da importância e do valor agregado da central 
de serviços para uma organização. 
 Campanhas de conscientização para os usuários da Central de serviços: 
devem ser feitas apresentações, eventos, workshops e reuniões para que os 
usuários passem a enxergar o valor agregado de uma central de serviços para a 
organização e aceitem utilizar os serviços da central (aceitação que promoverá a 
mudança cultural para a implementação da Central de Serviços). 
Não deve-se esperar um Service Desk 100% eficaz e eficiente já no primeiro 
dia da implementação. É natural que o Service Desk com o tempo vá ganhando 
experiência (curva de aprendizado e maturidade), suportado pelos outros processos 
de suporte e entrega de serviços. Mais do que nunca, o modelo de melhoria 
contínua também deve ser aplicado. 
FONTE: <http://www.itsmnapratica.com.br/service-desk-e-itil/> acessado em 21 nov 
2012. 
A primeira solução a ser feita é montar um Service DESK o objetivo é prover 
aos clientes da Software Developer um ponto único de contato (PUC) ou single point 
of contact (SPOC), vital para uma comunicação efetiva entre os usuários e as 
equipes da empresa. A missão principal do service desk é o restabelecimento da 
operação normal dos serviços dos Clientes o mais rápido possível, minimizando o 
impacto nos negócios causados por falhas de TI. Para um provimento de serviços de 
service desk com qualidade, este service desk poderá utilizar as melhores práticas 
ITIL ou outras metodologias de mercado. Ferramentas de Gestão de Serviços de TI 
 
 
 
26 
 
bem estruturadas, também são vitalícias para o provimento de um bom serviço. Para 
que sejam alcançadas todas as expectativas do cliente, interno ou externo, deve-se 
estabelecer Acordos de Nível de Serviço (SLA). O SLA é que definirá em quanto 
tempo e de que forma o serviço será prestado. 
 Podemos utilizar dois tipos de atendimento por telefones ou por um sistema 
web, onde o cliente abre um chamado ou ticket para ser solucionado, neste caso 
optamos pelo Software GLPI. 
 
3.5- Governança de TI e Governança Corporativa 
 
“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.” 
IBGC – Instituto Brasileiro de Governança Corporativa. 
 
 A Governança permite uma maior agilidade operacional e uma resposta 
rápida e eficiente às demandas. Os controles propiciam um modelo para as áreas 
das empresas e, em especial TI, aprimorarem os quesitos de eficiência, segurança, 
produtividade, acuracidade e disponibilidade dos processos. 
 
Governança de TI está intimamente ligada à responsabilidade dos 
executivos no que consiste à liderança, à estrutura e processos organizacionais que 
asseguram a sustentação das estratégias da organização e seus objetivos pela TI. A 
governança de TI está fundamentada básicamente em PESSOAS, PROCESSOS e 
TECNOLOGIA. 
 É muito importante saber que a governança deve estar em completa 
 
 
 
27 
 
conformidade com Lei Sarbanes-Oxley que visa à confiança dos investidores, 
exigindo que as organizações selecionem e implementem um framework de controle 
interno adequado. 
Fonte: http://www.devmedia.com.br/governanca-de-ti/8636 acessado em 22 
out 2012. 
 
4- Software Livre 
 
A Free Software Foundation considera um software como livre quando atende aos 
quatro tipos de liberdade para os usuários: 
 Liberdade 0: A liberdade para executar o programa, para qualquer propósito; 
 Liberdade 1: A liberdade de estudar como o programa funciona, e adaptá-lo 
para as suas necessidades; 
 Liberdade 2: A liberdade de redistribuir cópias do programa de modo que 
você possa ajudar ao seu próximo; 
 Liberdade 3: A liberdade de modificar o programa e distribuir estas 
modificações, de modo que toda a comunidade se beneficie. 
fonte: <http://pt.wikipedia.org/wiki/Software_livre#GNU.2FLinux> acessado em 22 
out 2012. 
 
O software, para ser livre, também precisa estar registrado sob uma licença. 
O idealizador do projeto GNU, sistema operacional criado em 1984 baseado em 
software livre, Richard Stallman, criou a Free Software Foundation ou Fundação do 
Software Livre, para tratar dos aspectos jurídicos e organizacionais do projeto. 
Através da Fundação foram criadas as duas licenças fundadoras do software livre, a 
GNU GPL, sigla em inglês para o termo Licença Pública Geral e a GNU LGPL, 
Licença Pública Menos Geral. 
 Criadas em 1989, nos Estados Unidos, e revisadas em 1991, com objetivo 
 
 
 
28 
 
de proteger a integridade do sistema de livre distribuição dos softwares, elas se 
estabeleceram como as licenças mais amplamente usadas pela comunidade que 
adota software livre. "O que se deve indagar é se os termos destas licenças 
afrontam a lei brasileira", uma vez que tanto a Lei de Software quanto a Lei sobre 
Direitos Autorais são altamente protecionistas no Brasil, o que é oposto ao que 
prega a filosofia do software livre. 
 Infelizmente não existe leis no Brasil que cubra todos os direitos dos autores 
de software livres, o software livre não é software gratuito. Este é um erro muito 
comum, mas que pode ter graves consequências. O Google, por exemplo, tem umdiscurso muito bonito de uso de software livre. Mas a maioria de seus principais 
produtos e serviços não são livres, são gratuitos. O conceito de livre é uma questão 
de liberdade. Deve ser pensado como em “liberdade de expressão”, não em "cerveja 
grátis”. 
 
4.1- GPLI 
GLPI é uma solução web Open-source completa para gestão de ativos e helpdesk. 
O mesmo gerência todos os seus problemas de inventário de ativos/hardwares e 
software e suporte ao usuário(helpdesk). 
Principais características do GLPI: 
 Multi Usuários 
 Sistema de autenticação (local, LDAP, AD, POP/IMAP, CAS, X509…) e multi-
servidor; 
 Vários idiomas; 
 Niveis de usuário; 
 Sistema de notificações sobre eventos via email; 
 Gestão de pedidos de assistência via web ou email; 
 Relatórios com gráficos; 
 Integração com OCS Inventory NG; 
 Gestão e controle de computador; 
 
 
 
29 
 
 Gestão e monitoramento de licenças; 
 Gestão e atendimento de Helpdesk (ticketagem); 
 Inventário; 
 Licença GPL; 
 Plugins e etc… 
Fonte: http://www.thiagopassamani.com.br/glpi/o-que-e-glpi.html acessado em 22 
out 2012. 
 
 5- Conclusão 
Os procedimentos aqui citados visam à melhoria nos processos de TI da 
empresa Software Developer. Pesquisas realizadas mostram que existem várias 
pendências a serem sanadas na área de Gerenciamento de Projetos. 
Alguns pontos merecem uma atenção em especial, visando seguir a lei 
Sarbanes-Oxley. Deverão ser usados Modelos de Boas Práticas de Gestão de 
Softwares e Processos como o CMMI, Cobit e Itil, objetivando uma administração 
estruturada e com qualidade. 
Investindo recursos de maneira correta, com base em Modelos de Boas 
Prática e respeitando normas legais garantirá a empresa um desenvolvimento eficaz 
com melhoria contínua do desempenho, oferecendo serviços de qualidade, dentro 
do orçamento de prazo. 
 6- Bibliografias / Referências 
Documentação de Software Fonte: 
<http://cps.erp5.org/workspaces/project/erp5_brasil/documentacao_dos_pro/transpar
encias_sobre/downloadFile/file/ProjetoDocumentacao1.pdf?nocache=1090370633.4
9> Acesso em: 10 out 2012 
Gerenciamento de Riscos: Fonte: <http://www.flf.edu.br/revista-flf/monografias-
computacao/monografia_thiago_coelho.pdf> Acesso em: 10 out 2012. 
 
 
 
30 
 
Gerência de Riscos no CMMI: Fonte: <http://www.flf.edu.br/revista-flf/monografias-
computacao/monografia_thiago_coelho.pdf> Acesso em: 10 out 2012. 
PMBOK: Fonte: <http://www.flf.edu.br/revista-flf/monografias-
computacao/monografia_thiago_coelho.pdf> Acesso em: 10 out 2012 
Gerência de Risco com o PMBOK: Fonte: <http://www.flf.edu.br/revista-
flf/monografias-computacao/monografia_thiago_coelho.pdf> Acesso em: 10 out 2012 
Processo de Gerenciamento de Risco: Fonte: <http://www.flf.edu.br/revista-
flf/monografias-computacao/monografia_thiago_coelho.pdf> Acesso em: 15 out 2012 
Plano do Gerenciamento de Risco: Fonte: <http://www.flf.edu.br/revista-
flf/monografias-computacao/monografia_thiago_coelho.pdf> Acesso em: 15 out 2012 
Aspectos do Desenvolvimento da lei SOX: Fonte: < 
http://www.praticacontabil.com/contadorperito/Lei_Sarbanes_Oxley_e_seus_efeitos.
pdf > Acesso em: 15 out 2012 
Cobit e Itil: Fonte: < http://efagundes.com/artigos/COBIT.htm> Acesso em: 15 out 2012 
Cobit: Fonte: < http://efagundes.com/artigos/COBIT.htm> Acesso em: 15 out 2012 
Itil: Fonte: < http://www.profissionaisdetecnologia.com.br/blog/?p=168 
> Acesso em: 15 out 2012. 
Service Desk e a Itil: FONTE: <http://www.itsmnapratica.com.br/service-desk-e-itil/> 
acessado em 21 nov 2012. 
Governança de TI e a Governança Corporativa: Fonte: 
http://www.devmedia.com.br/governanca-de-ti/8636 acessado em 22 out 2012. 
Software Livre: fonte: <http://pt.wikipedia.org/wiki/Software_livre#GNU.2FLinux> 
acessado em 22 out 2012. 
GPLI: Fonte: http://www.thiagopassamani.com.br/glpi/o-que-e-glpi.html acessado em 
22 out 2012. 
9df85a55-e61e-46d6-86ab-f10512a9bdfd