UNIP INTERATIVA PROJETO INTEGRADO MULTIDISCIPLINAR CURSOS SUPERIORES DE TECNOLOG IA PROJETO INTEGRADO MULTIDISCIPLINAR VII ANLISE DE IMPACTO, PLANEJAMENTO,

DESENVOLV IMENTO IMPLEMENTAO DE MELHORAS NOS PROCESSOS DE TI DA SOFTWARE DEVELOPER Araraquara /SP 2012 1

UNIP INTERATIVA PROJETO INTEGRADO MULTIDISCIPLINAR CURSOS SUPERIORES DE TECNOLOG IA PROJETO INTEGRADO MULTIDISCIPLINAR VII ANLISE DE IMPACTO, PLANEJAMENTO, DESENVOLV IMENTO IMPLEMENTAO DE MELHORAS NOS PROCESSOS DE TI DA SOFTWARE DEVELOPER NOME: HIGOR VILLA GANDRA RA: 1127303 CURSO: CURSO SUPERIOR DE TECNOLOGIA EM GESTO DA TECNOLOGIA DA INFORMAO 3 SEMESTRE Araraquara /SP 2012 2

RESUMO A Software Developer uma Empresa de Desenvolvimento de Sistemas, localiza da na Cidade de Araraquara - SP. A Empresa vem apresentando alguns problemas em seus processos de Desenvolvimento, Documentao e servios de Help Desk em seus proces sos. Em face destes problemas, a empresa contratou a Consulting, empresa especia lizada desenvolvimento de software para Bancos, tendo como principais produtos o s Sistemas de Consrcio, Financiamentos e Emprstimos. A empresa Consulting elaborou um estudo contendo Anlise de Impacto, Pl anejamento, Desenvolvimento e como implementar melhorias nos processos de TI da contratante Software Developer. Sero usados modelos de Boas Prticas para a Melhori a do Processo de Desenvolvimento de Software, orientados pela Governana de TI e p elo CMMI, SOX, Cobit e ITIL. PALAVRAS-CHAVE: planejamento, anlise, processos. desenvolvimento, melhorias, 3

Abstract The Software Developer is an Enterprise Systems Development, located in the city of Araraquara - SP. The Company has presented some problems in their p rocesses Development, Documentation and Help Desk services in their processes. I n the face of these problems, the company hired Consulting, a company specializi ng in software development banks, the main products Systems Consortium, loans an d financing. The company produced a study containing Consulting Impact Analysis, Planning, Development and how to implement process improvements to IT Contracto r Software Developer. Models will be used Good Practices for Improving the Softw are Development Process, driven by the IT Governance and CMMI, SOX, COBIT and IT IL. KEYWORDS: processes. development, improvement, planning, analysis, 4

SUMRIO 1- Introduo....................................................................... ..........................07 1.1- Documentao de Softwares......................... ...........................................08 1.2- Uso da Documentao.............. ................................................................08 1.3- Document ao do Processo.................................................................... ..08 1.4- Documentao do Produto................................................... .....................09 1.4.1.- Documentao do Usurio............................... ...................................10 1.4.2- Documentao do Sistema................ ..................................................11 1.5- Documentao do Cdigo...... ....................................................................11 1.5.1- Es colha de Nomes.................................................................. .............12 1.5.2- Organizao Visual........................................... ...................................12 1.6- Qualidade dos Documentos............. ..........................................................12 2- Gerenciamento de Riscos...................................................... ....................13 2.1- Gerncia de Riscos no CMMI ........................... .........................................14 2.2- PMBOK.......................... .............................................................................16 2.3- Gerncia 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 5

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 Iti l............................................................................... .22 3.5- Governana de TI e Governana Corporativa.................................. .........26 4- Software Livre............................................................... ...............................28 4.1- GPLI..................................... ......................................................................29 5- Concluso...................................................................... ................................29 6- Bibliografias / Referncias................. ..........................................................29 6

Introduo Realizado a anlise 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 Governana de TI, Gesto de Qualidade e Sist emas para Internet e Softwares Livres. Cada melhoria citada tem papel fundamenta l nas melhorias dos processos da empresa Software Developer. Sero usados como bas e os modelos de boas prticas para a Melhoria dos Processos de Desenvolvimento de Softwares, objetivando processos que permitam desenvolver softwares com qualidad e dentro de prazos, custos e requisitos definidos. 7

1.1- Documentao de Softwares Qualquer software deve ter uma quantidade razovel de documentao. - Documentos de tr abalho. - Manuais de usurio produzidos profissionalmente. Em geral, a maioria destes documentos produzida por engenheiros de software. Uma parte considervel dos custos de um projeto pode ser gasta com documentao. 1.2- Uso da Documentao Meio de comunicao entre os membros de um grupo de desenvolvimento; Informaes para as pessoas que venham a fazer manuteno no sistema; Informaes gerncia de modo a ajudar a planejar, fazer o oramento e o cronograma; Informaes para ensinar aos usurios como utilizar e administrar o sistema. 1.3- Documentao do Processo produzida para que o processo de desenvolvimento do software seja administrvel Re gistram os processos de desenvolvimento e manuteno do software. Documentao do Proces so - Categorias -Planos estimativos e cronogramas. Produzidos por gerentes 8

Usados para prever e controlar o processo. -Relatrios Descrevem como os recursos foram do utilizados durante o

desenvolvimento software

-Padres -Memorandos, comunicaes, mensagens eletrnicas Registram as comunicaes e rentes e engenheiros de software Estabelecem como o processo deve ser implementa do; Podem ser organizacionais, nacionais, ou Internacionais. -Documentos tcnicos de trabalho Registram as ideias e pensamentos dos engenheiros de software. Descrevem estratgias de implementao. Registram problemas j identificad os. Especificam as razes para as decises de projeto. 1.4- Documentao do Produto Descreve o software que est sendo desenvolvido; muito utilizada depois que o sist ema implementado, mas essencial tambm para a administrao do processo de desenvolvimento Descreve o software produzido.

Tem vida longa e deve estar sempre atualizada em relao ao cdigo. Divide-se em: 9

Documentao do usurio. Documentao do sistema 1.4.1.- Documentao do Usurio

Deve levar em conta os diversos tipos de usurios. importante distinguir entre os vrios usurios. Exemplo: Usurios finais Usam o software para auxili-los em algum efa No esto interessados em detalhes tcnicos ou administrativos. Administradores do sistema Responsveis pela administrao do software Ex: operadores, gerentes de rede, etc Descrio funcional do sistema is do sistema Servios fornecidos por ele . Manual de introduo Apresenta uma introduo informal do sistema e descreve seu uso nor mal Deve explicar como comear a usar o sistema e como os usurios podem utilizar as facilidades oferecidas pelo sistema Manual de referncia Descreve as facilidades do sistema e seu uso Fornece uma list a das mensagens de erro e descreve como agir quando os erros ocorrerem Deve ser completo e tcnicas de descrio formal podem ser utilizadas Documento de instalao 10 Requisitos gera

Descreve como instalar o sistema Especifica a plataforma mnima necessria sua insta lao Manual do administrador do sistema. sistema Informaes relevantes para uma boa administrao do

Manual de referncia rpida do sistema. Informaes concisas das principais funes do si ma e como utiliz-las Mensagens de erros mais comuns. Ajuda on-line 1.4.2- Documentao do Sistema Descreve a implementao do sistema, desde a especificao dos requisitos at o plano de t estes. importante que seja estruturada com overviews levando a especificaes mais d etalhadas e formais de cada aspecto do sistema. Documento de requisitos

Descrio da arquitetura do sistema Descrio da arquitetura de cada um dos programas Li stagens do cdigo fonte dos programas 1.5- Documentao do Cdigo Pode ser extremamente til para melhorar (facilitar) o entendimento dos programas: Escolha de nomes; 11

Organizao visual; Comentrios. 1.5.1- Escolha de Nomes Os nomes devem ser significativos em relao ao que eles rep resentam. Identificadores maiores melhoram a compreenso dos programas, mesmo em p rogramas pequenos. Identificadores grandes demais dificultam sua digitao e podem s e tornar uma fonte de erros.

1.5.2- Organizao Visual Maneira como o cdigo aparece na tela do computador ou em um a listagem. Os padres de boa codificao mais aceitos incluem: comandos; Indentao. U co comando por linha; Espaamento entre os componentes dos Devem ser usados para explicar o que o software faz, ao invs de como ele faz. 1.6- Qualidade dos Documentos A qualidade da documentao to importante quanto a qualidade do cdigo. Aspectos import antes para se conseguir produzir bons documentos incluem: Planejamento (ou proje to) dos documentos; A existncia de padres a serem seguidos; Procedimentos de garan tia de qualidade. Padro do Processo de Documentao 12

-Procedimentos de desenvolvimento: Ferramentas; Procedimentos de qualidade. Flexv eis para lidar com todos os tipos de documentos; Aplicam-se a todos os documentos (de um projeto) Fonte: <http://cps.erp5.org/workspaces/project/erp5_brasil/documentacao_dos_pro/ transpar Identificao; Estrutura; Apresentao; Indicao de mudanas. 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 identific ao de problemas potenciais e de oportunidades antes que eles ocorram, com o objeti vo de eliminar ou reduzir a probabilidade de ocorrncia e o impacto de eventos neg ativos para os objetivos do projeto, alm de potencializar os efeitos da ocorrncia de eventos positivos. O gerenciamento de riscos abordado por vrios modelos que co ntrolam 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 implantao e melhoria do processo de software da s organizaes. O RUP (Rational Unified Process) um processo baseado em melhores prti cas de Engenharia de Software. O MSF (Microsoft Solutions Framework) tem sido us ado pela Microsoft como o seu mtodo para desenvolvimento de solues de software dentro da Microsoft e tambm para 13

os milhares de clientes e parceiros da Microsoft em todo o mundo. O PMBOK (Proje ct Management Body of Knowledgement) trata do gerenciamento de projetos de uma f orma ampla, no sendo especfico para software. 2.1- Gerncia de Riscos no CMMI O CMMI (Capability Maturity Model Integration) considerado um modelo de gesto de processos que tem como objetivo prover s empresas, um conjunto de melhores prticas que possa suportar a melhoria contnua de seu desempenho, bem como ser referncia p ara eventuais comparaes por meio de seus nveis de maturidade e capacidade. O CMMI c ontm prticas (Genricas e Especficas) necessrias maturidade em disciplinas especficas Systems Engineering (SE), Software Engineering (SE), Integrated Product and Proc ess Development (IPPD), Supplier Sourcing (SS)). Desenvolvido pelo SEI (Software Engineering Institute) da University Carnegie Mellon, o CMMI uma evoluo do CMM 2 e procura estabelecer um modelo nico para o processo de melhoria corporativo, int egrando diferentes modelos e disciplinas. O CMMI-SW contm duas representaes: por es tgios, e contnua. A representao por estgios trata do nvel de maturidade da organizao o um todo, contendo cinco nveis de maturidade: inicial, gerenciado, definido, ger enciado quantitativamente e em otimizao. 1- A Representao Contnua: Possibilita organi zao utilizar a ordem de melhoria que melhor atender os objetivos de negcio da empre sa. caracterizado por Nveis de Capacidade (Capability Levels): Nvel 0: Incompleto (Adhoc) Nvel 1: Executado (Definido) Nvel 2: Gerenciado / Gerido Nvel 3: Definido 14

Nvel 4: Quantitativamente gerenciado / Gerido quantitativamente Nvel 5: Em otimizao (ou Optimizado) 2-Representao Por Estgios: Disponibiliza uma seqncia prdeterminada para melhoria baseada em estgios que no deve ser desconsiderada, pois cada estgio serve de base para o prximo. caracterizado por Nveis de Maturidade (Maturity Levels): Nvel 1: Inicial (Ad-hoc) Nvel 2: Gerenciado / Gerido Nvel 3: Definido Nvel 4: Quantitativamente gerenciado / Gerido quantitativamente Nvel 5: Em otimizao Cada nvel constitudo por um conjunto de reas de processos, compostas por objetivos especficos e objetivos genricos. Cada objetivo especfico pode ser composto por um c onjunto de prticas especficas. Um objetivo especfico (SG, Specific Practices by Goa l) descreve as caractersticas que devem estar presentes para satisfazer uma rea de processo. Uma prtica especfica (SP, Specific Practices) a descrio de uma atividade que considerada importante para se alcanar o objetivo especfico a ela associado. A problemtica do risco abordada nas reas de processo Planejamento do Projeto, Moni torao e Controle do Projeto, e Gerncia de Risco. As duas primeiras reas de processo esto no nvel 2 e a ltima est no nvel 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 identificao e na anlise dos riscos para se determinar o impacto, a probabilidade de ocorrncia e o perodo em 15

que podem ocorrer, para que os riscos possam ser priorizados. Na Monitorao e Contr ole do Projeto, tem-se o SG Monitorar o Projeto de Acordo com o Plano, onde est i nserido a SP Monitorar os Riscos do Projeto. A Gerncia de Risco no CMMI tem por f inalidade identificar potenciais problemas antes que ocorram, de forma que as at ividades de administrao desses riscos possam ser planejadas e realizadas, de acord o com suas necessidades, ao longo do ciclo de vida do produto ou projeto, para m itigar possveis impactos adversos. (ROCHA e BELCHIOR, 2004) Fonte: <http://www.flf.edu.br/revista-flf/monografiascomputacao/monografia_thiago_coelho.pdf> Acesso em: 10 out 2012. 2.2- PMBOK O PMI (Project Management Institute) uma organizao internacional sem fi ns lucrativos, fundada em 1969 por um grupo de cinco voluntrios, na Filadlfia Pens ilvnia - EUA. O principal objetivo do PMI tem sido a definio e divulgao das melhores prticas em gesto de projetos. Alm de desenvolver normas, seminrios, programas educac ionais e certificao profissional. Possui mais de 100.000 (cem mil) membros em todo o mundo e j certificou mais de 50.000 (cinqenta mil) PMP (Project Management Prof essional). O PMI estima que 10 trilhes de dlares sejam gastos anualmente no mundo em projetos, o que equivale a aproximadamente 25% do PIB mundial, e que cerca de 16,5 milhes de profissionais esto envolvidos diretamente com a Gerncia de Projetos no mundo. Este volume de projetos e mudanas constantes no cenrio competitivo mund ial gera a crescente necessidade de resultados mais rpidos, com qualidade e a um custo competitivo. Fatores como a globalizao do mercado e aquisies de novas tecnolog ias emergentes, tornam cada vez maior a Gerncia de Projetos um assunto da mais al ta importncia para as organizaes e para sua capacidade de sobrevivncia. Pesquisas re alizadas pelo PMI mostram que 75% dos seus membros indicaram que, nos prximos ano s, suas empresas estaro dando maior importncia para a gerncia de projetos. Fonte: <http://www.flf.edu.br/revista-flf/monografiascomputacao/monografia_thiago_coelho.pdf> Acesso em: 10 out 2012 16

2.3- Gerncia de Risco com PMBOK

O desenvolvimento de software tem avanado tecnologicamente em rpidas propores, mas e xistem fatores que ocorrem desde o comeo desse avano, so eles: os erros de gesto e a falta de sucesso do software desenvolvido, muitas vezes no atendendo o que clien te desejava. Para o sucesso ser completo, o produto final deve ser entregue dent ro do prazo, com o custo especificado, e ser realmente aquilo que o cliente nece ssitava. A Gerncia de Projetos uma soluo para os problemas que as equipes de desenv olvimento de Software vm enfrentando, porque distribuda em reas de conhecimento, on de cada uma delas descreve seus respectivos processos a fim de garantir que os o bjetivos planejados sejam atingidos. As tcnicas de gerenciamento de 32 projetos e sto sendo aprimoradas constantemente, buscando sempre garantir o sucesso dos proc essos. O Project Management Body of Knowledge, tambm conhecido como PMBOK um conj unto de prticas em gerncia de projetos levantado pelo Project Management Institute (PMI) e constituem a base da metodologia de gerncia de projetos do PMI. Estas prt icas so compiladas na forma de um guia, chamado de Guia do Conjunto de Conhecimen tos em Gerenciamento de Projetos, ou Guia PMBOK. (ALENCAR, 2006) O Gerente de pr ojetos a pessoa responsvel pela realizao dos objetivos do projeto, identificando s n ecessidades, estabelecendo objetivos claros e possveis de ser alcanados e tentar e quilibrar qualidade, escopo, tempo e custo, a ainda atender s expectativas das pa rtes interessadas no projeto. Ele e sua equipe devero seguir um cdigo de tica e con duta profissional para aqueles que possuem a certificao PMP. No gerenciamento de p rojetos so aplicados os conhecimentos, habilidades, ferramentas e tcnicas s ativida des do projeto e realizado atravs da aplicao e da integrao das seguintes reas de comp tncias gerncias, so elas: Gerenciamento de Integrao, Gerenciamento de Escopo, Gerenci amento de Tempo, Gerenciamento do Custo, Gerenciamento da Qualidade, Gerenciamen to dos 17

Recursos Humanos, Gerenciamento da Comunicao, Gerncia de Aquisies e Gerncia de Riscos Fonte: <http://www.flf.edu.br/revista-flf/monografiascomputacao/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 esforo. No planejamento do projeto, so realizadas reunies tendo como foco os objetivos do projeto: Escopo, Qualidade, Prazo e Custo. Neste momento j importante pensar nos riscos pois medida que os ob jetivos vo se consolidando, os possveis riscos vo se tornando mais provveis, podendo comprometer o andamento do projeto. Os processos do gerenciamento de riscos do projeto esto dispostos da seguinte forma: a. Plano de Gerenciamento do Risco: dec ide como abordar, planejar e executar as atividades de gerncia de risco para um p rojeto; b. Identificao dos Fatores de Risco: determina quais riscos podem afetar o projeto e documenta suas caractersticas; c. Anlise Qualitativa de Risco: realiza uma anlise qualitativa dos riscos e as condies para priorizar seus efeitos nos obje tivos do projeto. d. Anlise Quantitativa de Risco: mede a probabilidade atravs de uma anlise numrica e as conseqncias dos riscos e estima suas implicaes para os objetiv os do projeto. e. Planejamento de resposta ao Risco: desenvolve procedimentos e tcnicas para melhorar as oportunidades e reduzir as ameaas para os objetivos do pr ojeto. f. Monitoramento e Controle do Risco: monitora riscos residuais identific a novos riscos, executa planos de reduo de risco e avalia sua eficcia durante todo o ciclo do projeto. 18

Esses processos no ocorrem isoladamente, eles interagem entre si e tambm com proce ssos de outras reas. 2.5- Plano de Gerenciamento de Risco Dentro de um processo de administrao de risco, o seu plano de gerenciamento visa g arantir que o tipo, o nvel e a visibilidade da Gerncia de Risco sejam compatveis co m o risco e com a importncia do projeto. O Plano gerencial de riscos deve ser ter minado j no incio 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 nomeao de responsabilidades aos gestores e envolvidos. Os processos do Plano de Gerenciamento de Riscos no atuam isoladame nte, interagem entre si e com os processos de outras reas, ocorrendo pelo menos u ma vez em cada projeto. Fonte: <http://www.flf.edu.br/revista-flf/monografiascomputacao/monografia_thiago_coelho.pdf> Acesso em: 15 out 2012 3.1- Aspectos do Desenvolvimento da Lei SOX Ao implantar a Lei SOX necessrio, que sejam adotadas boas prticas de governana corporativa, pois alm da empresa conquist ar espao ela tambm obtm confiana por parte de todos os envolvidos na corporao, princip almente para os investidores, que vem nessas boas prticas um diferencial para toma r decises de investimento e da sua participao na mesma. De acordo com a Cartilha CV M (2002, p.1) define-se governana corporativa como segue: Governana corporativa o conjunto de prticas 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 anlise das prticas de governana corpor ativa aplicada 19

ao mercado de capitais envolve, principalmente: transparncia, eqidade de tratament o dos acionistas e prestao de contas. Complementa Steinberg (2003, p.18), como def inio usual em sua publicao: ... constitui o conjunto de prticas de relacionamentos en tre acionistas/cotistas, conselho de administrao, diretoria executiva, auditoria i ndependente e conselho fiscal com a finalidade de aprimorar o desempenho da empr esa e facilitar o acesso ao capital. Nas definies acima, possvel considerar que boa s prticas de governana corporativa juntamente com o mercado de capitais buscam env olvimento dos stakeholders (pblicos de interesse), acionistas e controladores atr avs da transparncia das informaes, tratamento igual para todos os acionistas e prest ao de contas. Segundo Andrade e Rossetti, citado por (2004 Gallon e Beuren 2006, p .4), resumem os diversos conceitos de governana corporativa a partir de expressesc have que procuram definir sua diversidade e abrangncia. 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 domnios: 1. Planejamento e orga nizao. 2. Aquisio e implementao. 3. Entrega e suporte. 4. Monitorao. 20

Fonte: < http://efagundes.com/artigos/COBIT.htm> Acesso em: 15 out 2012 3.3- Cobit O CobiT um guia para a gesto de TI recomendado pelo ISACF (Information Systems Audit and Control Foundation, www.isaca.org). O CobiT inclui recursos t ais como um sumrio executivo, um framework, controle de objetivos, mapas de audit oria, um conjunto de ferramentas de implementao e um guia com tcnicas de gerenciame nto. As prticas de gesto do CobiT so recomendadas pelos peritos em gesto de TI que a judam a otimizar os investimentos de TI e fornecem mtricas para avaliao dos resulta dos. 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 21

O ITIL (Information Technology Infrastructure Library) o modelo de referncia para gerenciamento de processos de TI mais aceito mundialmente. A metodologia foi cri ada pela secretaria de comrcio (Office of Government Commerce, OGC) do governo In gls, a partir de pesquisas realizadas por Consultores, Especialistas e Doutores, para desenvolver as melhores prticas para a gesto da rea de TI nas empresas privada s e pblicas. Atualmente se tornou a norma BS-15000, sendo esta um anexo da ISO 90 00/2000. O foco deste modelo descrever os processos necessrios para gerenciar a i nfra-estrutura de TI eficientemente e eficazmente de modo a garantir os nveis de servio acordados com os clientes internos e externos As normas ITIL esto documentada s em aproximadamente 40 livros, onde os principais processos e as recomendaes das melhores prticas de TI esto descritas. O ITIL composto por mdulos. Os mais important es so o IT Service Support" e o IT Service Delivery". Caractersticas do ITIL Model ferncia para processos de TI no proprietrio; Adequado para todas as reas de atividad e; Independente de tecnologia e fornecedor; Baseado nas melhores prticas; Um mode lo de referncia para a implementao de processos de TI; Checklist testado e aprovado ; O que fazer e o que no fazer. Fonte: < http://www.profissionaisdetecnologia.com .br/blog/?p=168 > Acesso em: 15 out 2012 3.4.1- Service Desk e Itil 22

H alguns anos, o Service Desk, infelizmente, era tratado apenas como uma rea secun dria dentro da empresa. TI costumava dar mais valor as equipes de suporte e outra s reas consideradas mais nobres para o negcio, deixando para a Central de Servios um papel secundrio. Com a implementao das melhores prticas em gerenciamento de servios d e TI (ITIL), essa viso finalmente e de maneira muito justa foi alterada. O Service Desk uma entidade independente, no apenas um processo dentro das melhores prticas. u ma funo, um departamento, uma organizao com importncia estratgica para a prestao de s ios de TI. Por ser o ponto nico de contato entre TI e usurios , ele diretamente res ponsvel pela percepo e satisfao dos mesmos. Antes de tudo, preciso entender as difere nas entre os modelos existentes de centrais de atendimento. So trs tipos: 1. CALL C ENTER: modelo de atendimento que registra as solicitaes e encaminha para o suporte especfico. Seu principal objetivo atender grande volume de chamadas e direcion-la s. 2. HELPDESK: modelo de atendimento que gerencia , coordena e resolve incident es o mais rpido possvel. Garantindo que requisies no sejam perdidas. 3. SERVICE DESK: Alm de apresentar as duas caractersticas anteriormente apresentadas, oferece serv ios com foco em TI e nos negcios, lidando com incidentes e provendo interfaces par a outros processos, como requisies de mudanas, nveis de servios, gerncia de disponibil idade, dentre outros. Resumindo, o Service Desk possui 3 caractersticas importants simas: Representam o provedor de servios. Defendem pessoas, processos e tecnologia ( o l ema do ITILl!!!) Operam no princpio da satisfao do usurio. 23

Ele responsvel por gestionar e acompanhar todas as solicitaes (incidentes, mudanas, requisies, consultas, reclamaes e etc). um departamento cobrado e medido por: Tempo de atendimento; Tempo de espera; Tempo de registro de um chamado; Taxa de abandono de ligaes; Conhecimento tcnico do assunto; Controle das solicitaes atendidas dentro e fora do prazo (SLA); Acompanhamento do incidente (ciclo de vida do inc idente); Classificao da solicitao, etc. Implantar um service desk, na maioria das ve zes, uma das primeiras misses que uma implantao ITIL recebe. No incio, significa concentrar todas as chamadas um nico atendimento, abrindo se possvel, outras formas de contato, como e-mail e tambm uma interface WEB do sistema de registro de chamados, permitindo ao usurio r ealizar o registro de forma independente. Durante a implantao preciso atentar-se o s trs pilares importantssimos do ITIL pessoas, processos, ferramentas. So pontos de a teno: selecionar corretamente o pessoal para atendimento e trein-los pontualmente e periodicamente: importante selecionar pessoas com conhecimento tcnico, mas somente isso no suficiente para garantir um bom atendimen to. preciso pessoas com os chamado soft skills : conhecimentos relacionados a capa cidade comunicao, raciocnio lgico e rpido, presteza e postura adequada para que um bo m atendimento seja realizado. Alm disso, as equipes precisam ser treinadas quando a central de servios for implementada e depois disso periodicamente para que o c onhecimento no seja dissipado. Definio correta de processos: preciso definir como o ser o atendimento, como a cent ral de servios se relacionar com os outros processos ITIL, 24

resumindo, qual o verdadeiro papel e responsabilidade da central de servios para a organizao. Seleo correta de ferramentas para suportar o service desk: uma boa ferramenta de i ncidentes, uma boa central de distribuio de ligaes so fatores chave para o sucesso de um service Desk.

Deve haver comprometimento gerencial, liderana pelo exemplo: os gerentes devem se comprometer inteiramente em tornar a central de servios um sucesso, no abrindo ex cees no ponto nico de contato e auxiliando na conscientizao de suas equipes da importn cia e do valor agregado da central de servios para uma organizao.

Campanhas de conscientizao para os usurios da Central de servios: devem ser feitas a presentaes, eventos, workshops e reunies para que os usurios passem a enxergar o val or agregado de uma central de servios para a organizao e aceitem utilizar os servios da central (aceitao que promover a mudana cultural para a implementao da Central de S ervios). No deve-se esperar um Service Desk 100% eficaz e eficiente j no primeiro dia da implementao. natural que o Service Desk com o tempo v ganhando experincia (cu rva de aprendizado e maturidade), suportado pelos outros processos de suporte e entrega de servios. Mais do que nunca, o modelo de melhoria contnua tambm deve ser aplicado. FONTE: <http://www.itsmnapratica.com.br/service-desk-e-itil/> acessado em 21 nov 2012. A primeira soluo a ser feita montar um Service DESK o objetivo prover aos c lientes da Software Developer um ponto nico de contato (PUC) ou single point of c ontact (SPOC), vital para uma comunicao efetiva entre os usurios e as equipes da em presa. A misso principal do service desk o restabelecimento da operao normal dos se rvios dos Clientes o mais rpido possvel, minimizando o impacto nos negcios causados por falhas de TI. Para um provimento de servios de service desk com qualidade, es te service desk poder utilizar as melhores prticas ITIL ou outras metodologias de mercado. Ferramentas de Gesto de Servios de TI 25

bem estruturadas, tambm so vitalcias para o provimento de um bom servio. Para que se jam alcanadas todas as expectativas do cliente, interno ou externo, deve-se estab elecer Acordos de Nvel de Servio (SLA). O SLA que definir em quanto tempo e de que forma o servio ser prestado. Podemos utilizar dois tipos de atendimento por telefo nes ou por um sistema web, onde o cliente abre um chamado ou ticket para ser sol ucionado, neste caso optamos pelo Software GLPI. 3.5- Governana de TI e Governana Corporativa Governana Corporativa o sistema pelo qual as sociedades so dirigidas e monitoradas, envolvendo os relacionamentos entre Acionistas/Cotistas, Conselho de Administrao, Diretoria, Auditoria Independente e Conselho Fiscal. As boas prticas de governana corporativa tm a finalidade de aumentar o valor da sociedade, capital e facilita r contribuir para seu a acesso sua ao perenidade. IBGC Instituto Brasileiro de Governana Corporativa. A Governana permite uma maior agilidade operacional e uma resposta rpida e eficien te s demandas. Os controles propiciam um modelo para as reas das empresas e, em es pecial TI, aprimorarem os quesitos de eficincia, segurana, produtividade, acuracid ade e disponibilidade dos processos. Governana de TI est intimamente ligada responsabilidade dos executivos no que cons iste liderana, estrutura e processos organizacionais que asseguram a sustentao das estratgias da organizao e seus objetivos pela TI. A governana de TI est fundamentada bsicamente em PESSOAS, PROCESSOS e TECNOLOGIA. muito importante saber que a gover nana deve estar em completa 26

conformidade com Lei Sarbanes-Oxley que visa confiana dos investidores, exigindo que as organizaes selecionem e implementem um framework de controle interno adequa do. Fonte: http://www.devmedia.com.br/governanca-de-ti/8636 acessado em 22 out 2 012. 4- Software Livre A Free Software Foundation considera um software como livre quando atende aos qu atro tipos de liberdade para os usurios: Liberdade 0: A liberdade para executar o programa, para qualquer propsito; Liberd ade 1: A liberdade de estudar como o programa funciona, e adapt-lo para as suas n ecessidades;

Liberdade 2: A liberdade de redistribuir cpias do programa de modo que voc possa a judar ao seu prximo;

Liberdade 3: A liberdade de modificar o programa e distribuir estas modificaes, 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, tambm precisa estar registrado sob uma licena. O ideal izador do projeto GNU, sistema operacional criado em 1984 baseado em software li vre, Richard Stallman, criou a Free Software Foundation ou Fundao do Software Livr e, para tratar dos aspectos jurdicos e organizacionais do projeto. Atravs da Fundao foram criadas as duas licenas fundadoras do software livre, a GNU GPL, sigla em i ngls para o termo Licena Pblica Geral e a GNU LGPL, Licena Pblica Menos Geral. Criadas em 1989, nos Estados Unidos, e revisadas em 1991, com objetivo 27

de proteger a integridade do sistema de livre distribuio dos softwares, elas se es tabeleceram como as licenas mais amplamente usadas pela comunidade que adota soft ware livre. "O que se deve indagar se os termos destas licenas afrontam a lei bra sileira", uma vez que tanto a Lei de Software quanto a Lei sobre Direitos Autora is so altamente protecionistas no Brasil, o que oposto ao que prega a filosofia d o software livre. Infelizmente no existe leis no Brasil que cubra todos os direitos dos autores de software livres, o software livre no software gratuito. Este um erro muito comum, mas que pode ter graves consequncias. O Google, por exemplo, tem um discurso mui to bonito de uso de software livre. Mas a maioria de seus principais produtos e servios no so livres, so gratuitos. O conceito de livre uma questo de liberdade. Deve ser pensado como em liberdade de expresso, no em "cerveja grtis. 4.1- GPLI GLPI uma soluo web Open-source completa para gesto de ativos e helpdesk. O mesmo gerncia todos os seus problemas de inventrio de ativos/hardwares e softwar e e suporte ao usurio(helpdesk). Principais caractersticas do GLPI: Multi Usurios Sistema de autenticao (local, LDAP, AD, POP/IMAP, CAS, X509) e multise rvidor;

Vrios idiomas; Niveis de usurio; Sistema de notificaes sobre eventos via email; Gesto de pedidos de assistncia via web ou email; Relatrios com grficos; Integrao com OCS I nventory NG; Gesto e controle de computador; 28

Gesto e monitoramento de licenas; Gesto e atendimento de Helpdesk (ticketagem); Inv entrio; Licena GPL; Plugins e etc Fonte: http://www.thiagopassamani.com.br/glpi/o-que-e-glpi.html acessado em 22 o ut 2012. 5- Concluso Os procedimentos aqui citados visam melhoria nos processos de TI da e mpresa Software Developer. Pesquisas realizadas mostram que existem vrias pendncia s a serem sanadas na rea de Gerenciamento de Projetos. Alguns pontos merecem uma ateno em especial, visando seguir a lei Sarbanes-Oxley. Devero ser usados Modelos d e Boas Prticas de Gesto de Softwares e Processos como o CMMI, Cobit e Itil, objeti vando uma administrao estruturada e com qualidade. Investindo recursos de maneira correta, com base em Modelos de Boas Prtica e respeitando normas legais garantir a empresa um desenvolvimento eficaz com melhoria contnua do desempenho, oferecendo servios de qualidade, dentro do oramento de prazo. 6- Bibliografias / Referncias D ocumentao de Software Fonte: <http://cps.erp5.org/workspaces/project/erp5_brasil/documentacao_dos_pro/transpa r encias_sobre/downloadFile/file/ProjetoDocumentacao1.pdf?nocache=1090370633.4 9> Acesso em: 10 out 2012 Gerenciamento de Riscos: Fonte: <http://www.flf.edu.br/re vista-flf/monografiascomputacao/monografia_thiago_coelho.pdf> Acesso em: 10 out 2012. 29

Gerncia de Riscos no CMMI: Fonte: <http://www.flf.edu.br/revista-flf/monografiasc omputacao/monografia_thiago_coelho.pdf> Acesso em: 10 out 2012. PMBOK: Fonte: <http://www.flf.edu.br/revista-flf/monografiascomputacao/monografia_thiago_coelho.pdf> Acesso em: 10 out 2012 Gerncia de Risco com o PMBOK: Fonte: <http://www.flf.edu.br/revistaflf/monografias-computacao/monografia_thiago_coelho.pdf> Acesso em: 10 out 2012 Processo de Gerenciamento de Risco: Fonte: <http://www.flf.edu.br/revistaflf/mon ografias-computacao/monografia_thiago_coelho.pdf> Acesso em: 15 out 2012 Plano d o Gerenciamento de Risco: Fonte: <http://www.flf.edu.br/revistaflf/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/artigo s/COBIT.htm> Acesso em: 15 out 2012 Cobit: Fonte: < http://efagundes.com/artigos /COBIT.htm> Acesso em: 15 out 2012 Itil: Fonte: < http://www.profissionaisdetecn ologia.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 Governana de em TI e a 21 Governana nov Corporativa: 2012. Fonte: http://www.devmedia.com.br/governanca-de-ti/8636 acessado em 22 out 2012. Softwa re Livre: fonte: <http://pt.wikipedia.org/wiki/Software_livre#GNU.2FLinux> acess ado em 22 out 2012. GPLI: Fonte: http://www.thiagopassamani.com.br/glpi/o-que-e-glpi.html acessado e m 22 out 2012. 9df85a55-e61e-46d6-86ab-f10512a9bdfd 30