pim 7

Prévia do material em texto

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 DO SOFTWARE
DEVELOPER
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
ASA NORTE /BRASILIA 2017
 
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
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
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.
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 
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
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.
 
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ários como 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 
 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 
1.4- Documentação do Produto
 Descreve o software que está sendo desenvolvido; 
 É muito utilizada depois que o sistema é implementado, mas é 
-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 linga e deve estar sempre atualizada em relação ao código.
Divide-se em :
-Documento do usuário 
-Documento 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 
-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ção uma introdução informal do sistema e descreve seu uso normal.
- 
-Deve explicado 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
-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 utiliza-las 
-mensagens de erros mais comuns 
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ção mais detalhadas e formais de cada aspecto do sistema.
-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
-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.
ndentação. 
-Devem ser usados para explicar o que o software faz, ao invés de como ele faz
1.6- Qualidades dos Documentos
A qualidade da documentação é tão importante quanto a qualidade do código. 
Aspecto importante 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.
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 paraos 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
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”, queconsiste na identificação e na análise dos riscos para se determinar o impacto, a probabilidade de ocorrência e o período em 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 finalidadeidentificar 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)
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 
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 Recursos Humanos, Gerenciamento da Comunicação, Gerência de Aquisições e Gerência de Riscos
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 de redução de risco e avalia sua eficácia durante todo o ciclo dos projetos.
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.
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 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 igualpara 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.
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. 
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.
3.4- Itil
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
3.4.1- Service Desk e Itil
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: 
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. 
HELPDESK: modelo de atendimento que gerencia , coordena e resolve incidentes o mais rápido possível. Garantindo que requisições não sejam perdidas.
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.
Service desk:
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 de atendimento; 
 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
 Tempo de atendimento; 
 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
Abertura de incidentes 
Acompanhamento de incidentes
Controle de solicitações 
Tempo de espera
Tempo de atendimento 
Conhecimento técnico do assunto 
Controle das solicitações atendidas dentro e fora do prazo (SLA).
 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 treina-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®®, resumindo qual o verdadeiro papel e responsabilidade da central de serviços para organizações.
-Seleção correta de ferramentas para suportar o servisse desk:
Uma boa ferramenta de incidentes, uma 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: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 conscientação para os usuários da central dos 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.
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
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”. 
Fonte: IGBE
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 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.
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 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 um discurso 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:
-Gestão e controle de computador
-Relatórios com gráficos
-Gestão de pedidos de assistência via web ou email;
-Vários idiomas
-Multi Usuários
-Níveis de usuário
-Gestão e monitoramento de licenças
-Gestão e atendimento de Helpdesk (ticketagem)
- Inventário
-Licença GPL;
-Plugins e etc…
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. 
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