7/29/2019 115437403-PIM-VII

1/31

UNIP INTERATIVA PROJETO INTEGRADO MULTIDISCIPLINAR CURSOS SUPERIORES DE TECNOLOGIA

PROJETO INTEGRADO MULTIDISCIPLINAR VII ANLISE DE IMPACTO, PLANEJAMENTO, DESENVOLVIMENTO IMPLEMENTAO DE MELHORAS NOS PROCESSOS DE TI DA SOFTWARE DEVELOPER

Araraquara /SP 2012

1

7/29/2019 115437403-PIM-VII

2/31

UNIP INTERATIVA PROJETO INTEGRADO MULTIDISCIPLINAR CURSOS SUPERIORES DE TECNOLOGIA

PROJETO INTEGRADO MULTIDISCIPLINAR VII ANLISE DE IMPACTO, PLANEJAMENTO, DESENVOLVIMENTO IMPLEMENTAO DE MELHORAS NOS PROCESSOS DE TI DA SOFTWARE DEVELOPER

NOME: HIGOR VILLA GANDRA RA: 1127303 CURSO: CURSO SUPERIOR DE TECNOLOGIA EM GESTODA TECNOLOGIA DA INFORMAO 3 SEMESTRE

Araraquara /SP 2012

2

7/29/2019 115437403-PIM-VII

3/31

RESUMO A Software Developer uma Empresa de Desenvolvimento de Sistemas, localizada na Cidade de Araraquara - SP. A Empresa vem apresentando alguns problemas emseus processos de Desenvolvimento, Documentao e servios 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 Consrcio, Financiamentos e

Emprstimos. A empresa Consulting elaborou um estudo contendo Anlise de Impacto, Planejamento, Desenvolvimento e como implementar melhorias nos processos de TI dacontratante Software Developer. Sero usados modelos de Boas Prticas para a Melhoria do Processo de Desenvolvimento de Software, orientados pela Governana de TI e pelo CMMI, SOX, Cobit e ITIL.

PALAVRAS-CHAVE: planejamento, anlise, processos.

desenvolvimento,

melhorias,

3

7/29/2019 115437403-PIM-VII

4/31

Abstract The Software Developer is an Enterprise Systems Development, located inthe 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: processes.

development,

improvement,

planning,

analysis,

4

7/29/2019 115437403-PIM-VII

5/31

SUMRIO

1- Introduo.................................................................................................07 1.1- Documentao de Softwares....................................................................08 1.2- Uso da Documentao..............................................................................08 1.3- Documentao 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- Escolha 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.......................................................................................................162.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

7/29/2019 115437403-PIM-VII

6/31

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- Governana de TI e Governana Corporativa...........................................26

4- Software Livre..............................................................................................28 4.1- GPLI...........................................................................................................29

5- Concluso......................................................................................................29 6- Bibliografias / Referncias...........................................................................29

6

7/29/2019 115437403-PIM-VII

7/31

Introduo

Realizado a anlise dos problemas encontrados na empresa Software Developer, notou-se que alguns processos necessitam de melhorias para que haja um funcionamentodentro dos requisitos de qualidade e legalidade.

As melhorias citadas abrangem as reas de Governana de TI, Gesto de Qualidade e Sistemas para Internet e Softwares Livres. Cada melhoria citada tem papel fundamental nas melhorias dos processos da empresa Software Developer. Sero usados como base os modelos de boas prticas para a Melhoria dos Processos de Desenvolvimento deSoftwares, objetivando processos que permitam desenvolver softwares com qualidade dentro de prazos, custos e requisitos definidos.

7

7/29/2019 115437403-PIM-VII

8/31

1.1- Documentao de Softwares

Qualquer software deve ter uma quantidade razovel de documentao. - Documentos de trabalho. - Manuais de usurio produzidos profissionalmente.

Em geral, a maioria destes documentos produzida por engenheiros de software. Umaparte 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 apessoas que venham a fazer manuteno no sistema; Informaes gerncia de modo a ajuplanejar, fazer o oramento e o cronograma; Informaes para ensinar aos usurios comoutilizar e administrar o sistema.

1.3- Documentao do Processo

produzida para que o processo de desenvolvimento do software seja administrvel Registram os processos de desenvolvimento e manuteno do software. Documentao do Proceso - Categorias -Planos estimativos e cronogramas. Produzidos por gerentes

8

7/29/2019 115437403-PIM-VII

9/31

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 comunicarentes 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 engenheide software. Descrevem estratgias de implementao. Registram problemas j identificaos. 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 sistema 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

7/29/2019 115437403-PIM-VII

10/31

Documentao do usurio. Documentao do sistema

1.4.1.- Documentao do Usurio

Deve levar em conta os diversos tipos de usurios. importante distinguir entre osvrios usurios. Exemplo: Usurios finais Usam o software para auxili-los emefa No esto interessados em detalhes tcnicos ou administrativos. Administradores dosistema Responsveis pela administrao do software

Ex: operadores, gerentes de rede, etc Descrio funcional do sistema Requisitosis do sistema Servios fornecidos por ele

.

Manual de introduo Apresenta uma introduo informal do sistema e descreve seu uso nomal Deve explicar como comear a usar o sistema e como os usurios podem utilizar asfacilidades oferecidas pelo sistema

Manual de referncia Descreve as facilidades do sistema e seu uso Fornece uma lisa das mensagens de erro e descreve como agir quando os erros ocorrerem Deve sercompleto e tcnicas de descrio formal podem ser utilizadas

Documento de instalao10

7/29/2019 115437403-PIM-VII

11/31

Descreve como instalar o sistema Especifica a plataforma mnima necessria sua instalao

Manual do administrador do sistema. Informaes relevantes para uma boa administraosistema

Manual de referncia rpida do sistema. Informaes concisas das principais funesma 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 destes. importante que seja estruturada com overviews levando a especificaes mais detalhadas e formais de cada aspecto do sistema. Documento de requisitos

Descrio da arquitetura do sistema Descrio da arquitetura de cada um dos programas Lstagens do cdigo fonte dos programas

1.5- Documentao do CdigoPode ser extremamente til para melhorar (facilitar) o entendimento dos programas: Escolha de nomes;

11

7/29/2019 115437403-PIM-VII

12/31

Organizao visual; Comentrios.

1.5.1- Escolha de Nomes Os nomes devem ser significativos em relao ao que eles representam. Identificadores maiores melhoram a compreenso dos programas, mesmo em programas pequenos. Identificadores grandes demais dificultam sua digitao e podem se tornar uma fonte de erros.

1.5.2- Organizao Visual Maneira como o cdigo aparece na tela do computador ou em uma listagem. Os padres de boa codificao mais aceitos incluem: comandos; Indentaco 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 impantes para se conseguir produzir bons documentos incluem: Planejamento (ou projeto) dos documentos; A existncia de padres a serem seguidos; Procedimentos de garantia de qualidade.

Padro do Processo de Documentao

12

7/29/2019 115437403-PIM-VII

13/31

-Procedimentos de desenvolvimento: Ferramentas; Procedimentos de qualidade. Flexeis para lidar com todos os tipos de documentos;

Aplicam-se a todos os documentos (de um projeto) Fonte: Acesso em: 10 out 2012

2- Gerenciamento de Riscos

O gerenciamento de riscos trabalha justamente com a incerteza, visando identificao de problemas potenciais e de oportunidades antes que eles ocorram, com o objetivo de eliminar ou reduzir a probabilidade de ocorrncia e o impacto de eventos negativos para os objetivos do projeto, alm de potencializar os efeitos da ocorrnciade eventos positivos. O gerenciamento de riscos abordado por vrios modelos que controlam a qualidade do processo de desenvolvimento de software dentre os quais oPMBOK, o CMMI, o RUP e o MSF. O CMMI (Capability Maturity Model Integration forSoftware) prov um framework para a implantao e melhoria do processo de software das organizaes. O RUP (Rational Unified Process) um processo baseado em melhores prtcas 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 denda Microsoft e tambm para

13

7/29/2019 115437403-PIM-VII

14/31

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, no sendo especfico para software.

2.1- Gerncia de Riscos no CMMI

O CMMI (Capability Maturity Model Integration) considerado um modelo de gesto deprocessos que tem como objetivo prover s empresas, um conjunto de melhores prticasque possa suportar a melhoria contnua de seu desempenho, bem como ser referncia para eventuais comparaes por meio de seus nveis de maturidade e capacidade. O CMMI contm prticas (Genricas e Especficas) necessrias maturidade em disciplinas especSystems Engineering (SE), Software Engineering (SE), Integrated Product and Process Development (IPPD), Supplier Sourcing (SS)). Desenvolvido pelo SEI (SoftwareEngineering Institute) da University Carnegie Mellon, o CMMI uma evoluo do CMM 2e procura estabelecer um modelo nico para o processo de melhoria corporativo, integrando diferentes modelos e disciplinas. O CMMI-SW contm duas representaes: por estgios, e contnua. A representao por estgios trata do nvel de maturidade da organio um todo, contendo cinco nveis de maturidade: inicial, gerenciado, definido, gerenciado quantitativamente e em otimizao. 1- A Representao Contnua: Possibilita ozao utilizar a ordem de melhoria que melhor atender os objetivos de negcio da empresa.

caracterizado por Nveis de Capacidade (Capability Levels): Nvel 0: Incompleto (Ad-hoc) Nvel 1: Executado (Definido) Nvel 2: Gerenciado / Gerido Nvel 3: Definido

14

7/29/2019 115437403-PIM-VII

15/31

Nvel 4: Quantitativamente gerenciado / Gerido quantitativamente Nvel 5: Em otimizao(ou Optimizado)

2-Representao

Por

Estgios:

Disponibiliza

uma

seqncia

pr-

determinada para melhoria baseada em estgios que no deve ser desconsiderada, poiscada 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 objetivosespecficos e objetivos genricos. Cada objetivo especfico pode ser composto por um conjunto de prticas especficas. Um objetivo especfico (SG, Specific Practices by Goal) descreve as caractersticas que devem estar presentes para satisfazer uma rea deprocesso. Uma prtica especfica (SP, Specific Practices) a descrio de uma atividaque considerada importante para se alcanar o objetivo especfico a ela associado.

A problemtica do risco abordada nas reas de processo Planejamento do Projeto, Monitorao e Controle do Projeto, e Gerncia de Risco. As duas primeiras reas de processoesto no nvel 2 e a ltima est no nvel 3 do CMMI-SW. No Planejamento do Projeto, temo SG Desenvolvimento do Plano do Projeto com a SP Identificar os Riscos do Projetoque consiste na identificao e na anlise dos riscos para se determinar o impacto, aprobabilidade de ocorrncia e o perodo em

15

7/29/2019 115437403-PIM-VII

16/31

que podem ocorrer, para que os riscos possam ser priorizados. Na Monitorao 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 Gerncia de Risco no CMMI tem por finalidade identificar potenciais problemas antes que ocorram, de forma que as atividades de administrao desses riscos possam ser planejadas e realizadas, de acordo com suas necessidades, ao longo do ciclo de vida do produto ou projeto, para mitigar possveis impactos adversos. (ROCHA e BELCHIOR, 2004)Fonte: Acesso em: 10 out 2012.

2.2- PMBOK O PMI (Project Management Institute) uma organizao internacional sem fins lucrativos, fundada em 1969 por um grupo de cinco voluntrios, na Filadlfia Pensilvnia - EUA. O principal objetivo do PMI tem sido a definio e divulgao das melhorprticas em gesto de projetos. Alm de desenvolver normas, seminrios, programas educaionais e certificao profissional. Possui mais de 100.000 (cem mil) membros em todoo mundo e j certificou mais de 50.000 (cinqenta mil) PMP (Project Management Professional). O PMI estima que 10 trilhes de dlares sejam gastos anualmente no mundoem projetos, o que equivale a aproximadamente 25% do PIB mundial, e que cerca de16,5 milhes de profissionais esto envolvidos diretamente com a Gerncia de Projetosno mundo. Este volume de projetos e mudanas constantes no cenrio competitivo mundial gera a crescente necessidade de resultados mais rpidos, com qualidade e a umcusto competitivo. Fatores como a globalizao do mercado e aquisies de novas tecnoloias 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 ralizadas pelo PMI mostram que 75% dos seus membros indicaram que, nos prximos anos, suas empresas estaro dando maior importncia para a gerncia de projetos.Fonte: Acesso em: 10 out 2012

16

7/29/2019 115437403-PIM-VII

17/31

2.3- Gerncia de Risco com PMBOK

O desenvolvimento de software tem avanado tecnologicamente em rpidas propores, mas xistem fatores que ocorrem desde o comeo desse avano, so eles: os erros de gesto e falta de sucesso do software desenvolvido, muitas vezes no 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 Gerncia de Projetos uma soluo para os problemas que as equipes de desenolvimento de Software vm enfrentando, porque distribuda em reas de conhecimento, ode cada uma delas descreve seus respectivos processos a fim de garantir que os objetivos planejados sejam atingidos. As tcnicas de gerenciamento de 32 projetos esto sendo aprimoradas constantemente, buscando sempre garantir o sucesso dos processos. O Project Management Body of Knowledge, tambm conhecido como PMBOK um conjunto 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 prticas so 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 responsvel pela realizao dos objetivos do projeto, identificando ecessidades, estabelecendo objetivos claros e possveis de ser alcanados e tentar equilibrar qualidade, escopo, tempo e custo, a ainda atender s expectativas das partes interessadas no projeto. Ele e sua equipe devero seguir um cdigo de tica e conduta profissional para aqueles que possuem a certificao PMP. No gerenciamento de projetos so aplicados os conhecimentos, habilidades, ferramentas e tcnicas s atividades do projeto e realizado atravs da aplicao e da integrao das seguintes reas d

tncias gerncias, so elas: Gerenciamento de Integrao, Gerenciamento de Escopo, Gereamento de Tempo, Gerenciamento do Custo, Gerenciamento da Qualidade, Gerenciamento dos

17

7/29/2019 115437403-PIM-VII

18/31

Recursos Humanos, Gerenciamento da Comunicao, Gerncia de Aquisies e Gerncia de RiFonte: 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 objetivos vo se consolidando, os possveis riscos vo se tornando mais provveis, podendcomprometer o andamento do projeto. Os processos do gerenciamento de riscos doprojeto esto dispostos da seguinte forma: a. Plano de Gerenciamento do Risco: decide como abordar, planejar e executar as atividades de gerncia de risco para um projeto; b. Identificao dos Fatores de Risco: determina quais riscos podem afetar oprojeto e documenta suas caractersticas; c. Anlise Qualitativa de Risco: realizauma anlise qualitativa dos riscos e as condies para priorizar seus efeitos nos objetivos do projeto. d. Anlise Quantitativa de Risco: mede a probabilidade atravs deuma anlise numrica e as conseqncias dos riscos e estima suas implicaes para os obos do projeto. e. Planejamento de resposta ao Risco: desenvolve procedimentos etcnicas para melhorar as oportunidades e reduzir as ameaas para os objetivos do projeto. f. Monitoramento e Controle do Risco: monitora riscos residuais identifica novos riscos, executa planos de reduo de risco e avalia sua eficcia durante todoo ciclo do projeto.

18

7/29/2019 115437403-PIM-VII

19/31

Esses processos no ocorrem isoladamente, eles interagem entre si e tambm com processos de outras reas.

2.5- Plano de Gerenciamento de Risco

Dentro de um processo de administrao de risco, o seu plano de gerenciamento visa garantir que o tipo, o nvel e a visibilidade da Gerncia de Risco sejam compatveis com o risco e com a importncia do projeto. O Plano gerencial de riscos deve ser terminado j no incio do planejamento do projeto, por ser essencial para executar comsucesso as outras atividades de planejamento. O Plano do Gerenciamento do Risco ,portanto, um documento que explica como ser desenvolvido o processo gerencial dorisco, o custo estimado e investido e a nomeao de responsabilidades aos gestorese envolvidos. Os processos do Plano de Gerenciamento de Riscos no atuam isoladamente, interagem entre si e com os processos de outras reas, ocorrendo pelo menos uma vez em cada projeto.Fonte: Acesso em: 15 out 2012

3.1- Aspectos do Desenvolvimento da Lei SOX Ao implantar a Lei SOX necessrio, quesejam adotadas boas prticas de governana corporativa, pois alm da empresa conquistar espao ela tambm obtm confiana por parte de todos os envolvidos na corporao, pralmente para os investidores, que vem nessas boas prticas um diferencial para tomar 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 oconjunto de prticas que tem por finalidade otimizar o desempenho de uma companhiaao proteger todas as partes interessadas, tais como investidores, empregados ecredores, facilitando o acesso ao capital. A anlise das prticas de governana corporativa aplicada

19

7/29/2019 115437403-PIM-VII

20/31

ao mercado de capitais envolve, principalmente: transparncia, eqidade de tratamento dos acionistas e prestao de contas. Complementa Steinberg (2003, p.18), como definio usual em sua publicao: ... constitui o conjunto de prticas de relacionamentostre acionistas/cotistas, conselho de administrao, diretoria executiva, auditoria independente e conselho fiscal com a finalidade de aprimorar o desempenho da empresa e facilitar o acesso ao capital. Nas definies acima, possvel considerar que bos prticas de governana corporativa juntamente com o mercado de capitais buscam envolvimento dos stakeholders (pblicos de interesse), acionistas e controladores atravs da transparncia das informaes, tratamento igual para todos os acionistas e presao 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 expresseschave que procuram definir sua diversidade e abrangncia.

Fonte:

Acesso em: 15 out 2012

3.2- Cobit e Itil Todo Projeto estar alinhado com as melhores praticas orientadaspelo Cobit e ITIL. O CobiT est dividido em quatro domnios: 1. Planejamento e organizao. 2. Aquisio e implementao. 3. Entrega e suporte. 4. Monitorao.

20

7/29/2019 115437403-PIM-VII

21/31

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 (InformationSystems Audit and Control Foundation, www.isaca.org). O CobiT inclui recursos tais como um sumrio executivo, um framework, controle de objetivos, mapas de auditoria, um conjunto de ferramentas de implementao e um guia com tcnicas de gerenciamento. As prticas de gesto do CobiT so recomendadas pelos peritos em gesto de TI que judam a otimizar os investimentos de TI e fornecem mtricas para avaliao 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

21

7/29/2019 115437403-PIM-VII

22/31

O ITIL (Information Technology Infrastructure Library) o modelo de referncia paragerenciamento de processos de TI mais aceito mundialmente. A metodologia foi criada pela secretaria de comrcio (Office of Government Commerce, OGC) do governo Ingls, a partir de pesquisas realizadas por Consultores, Especialistas e Doutores,para desenvolver as melhores prticas para a gesto da rea de TI nas empresas privadas e pblicas. Atualmente se tornou a norma BS-15000, sendo esta um anexo da ISO 9000/2000. O foco deste modelo descrever os processos necessrios para gerenciar a infra-estrutura de TI eficientemente e eficazmente de modo a garantir os nveis deservio acordados com os clientes internos e externos As normas ITIL esto documentads em aproximadamente 40 livros, onde os principais processos e as recomendaes dasmelhores prticas de TI esto descritas. O ITIL composto por mdulos. Os mais importes so o IT Service Support" e o IT Service Delivery". Caractersticas do ITIL ferncia para processos de TI no proprietrio; Adequado para todas as reas de ativie; Independente de tecnologia e fornecedor; Baseado nas melhores prticas; Um modlo de referncia para a implementao de processos de TI; Checklist testado e aprovad; 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

7/29/2019 115437403-PIM-VII

23/31

H alguns anos, o Service Desk, infelizmente, era tratado apenas como uma rea secundria dentro da empresa. TI costumava dar mais valor as equipes de suporte e outras reas consideradas mais nobres para o negcio, deixando para a Central de Servios papel secundrio. Com a implementao das melhores prticas em gerenciamento de servioe TI (ITIL), essa viso finalmente e de maneira muito justa foi alterada. O ServiceDesk uma entidade independente, no apenas um processo dentro das melhores prticasma funo, um departamento, uma organizao com importncia estratgica para a prestaios de TI. Por ser o ponto nico de contato entre TI e usurios , ele diretamente reponsvel pela percepo e satisfao dos mesmos. Antes de tudo, preciso entender as dnas entre os modelos existentes de centrais de atendimento. So trs tipos: 1. CALL CENTER: modelo de atendimento que registra as solicitaes e encaminha para o suporteespecfico. Seu principal objetivo atender grande volume de chamadas e direcion-las. 2. HELPDESK: modelo de atendimento que gerencia , coordena e resolve incidentes o mais rpido possvel. Garantindo que requisies no sejam perdidas. 3. SERVICE DEAlm de apresentar as duas caractersticas anteriormente apresentadas, oferece servios com foco em TI e nos negcios, lidando com incidentes e provendo interfaces para outros processos, como requisies de mudanas, nveis de servios, gerncia de dispoidade, dentre outros. Resumindo, o Service Desk possui 3 caractersticas importantssimas:

Representam o provedor de servios. Defendem pessoas, processos e tecnologia ( o lema do ITILl!!!) Operam no princpio da satisfao do usurio.

23

7/29/2019 115437403-PIM-VII

24/31

Ele responsvel por gestionar e acompanhar todas as solicitaes (incidentes, mudanarequisies, consultas, reclamaes e etc). um departamento cobrado e medido por:

Tempo de atendimento; Tempo de espera; Tempo de registro de um chamado; Taxa deabandono de ligaes; Conhecimento tcnico do assunto; Controle das solicitaes atendidentro e fora do prazo (SLA); Acompanhamento do incidente (ciclo de vida do incidente); Classificao da solicitao, etc. Implantar um service desk, na maioria das vzes, uma das primeiras

misses que uma implantao ITIL recebe. No incio, significa concentrar todas as chaum nico atendimento, abrindo se possvel, outras formas de contato, como e-mail etambm uma interface WEB do sistema de registro de chamados, permitindo ao usurio realizar o registro de forma independente. Durante a implantao preciso atentar-se os trs pilares importantssimos do ITIL pessoas, processos, ferramentas. So pontosteno:

selecionar

corretamente

o

pessoalpara

atendimento

e

trein-los

pontualmente e periodicamente: importante

selecionar pessoas com

conhecimento tcnico, mas somente isso no suficiente para garantir um bom atendimento. preciso pessoas com os chamado soft skills : conhecimentos relacionados a capacidade comunicao, raciocnio lgico e rpido, presteza e postura adequada para que umm atendimento seja realizado. Alm disso, as equipes precisam ser treinadas quandoa central de servios for implementada e depois disso periodicamente para que o conhecimento no seja dissipado.

Definio correta de processos: preciso definir como o ser o atendimento, como a cenral de servios se relacionar com os outros processos ITIL,

24

7/29/2019 115437403-PIM-VII

25/31

resumindo, qual o verdadeiro papel e responsabilidade da central de servios paraa organizao.

Seleo correta de ferramentas para suportar o service desk: uma boa ferramenta de incidentes, uma boa central de distribuio de ligaes so fatores chave para o sucessoum service Desk.

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

Campanhas de conscientizao para os usurios da Central de servios: devem ser feitas presentaes, eventos, workshops e reunies para que os usurios passem a enxergar o vaor agregado de uma central de servios para a organizao e aceitem utilizar os servioda central (aceitao que promover a mudana cultural para a implementao da Centralervios). 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

rva de aprendizado e maturidade), suportado pelos outros processos de suporte eentrega de servios. Mais do que nunca, o modelo de melhoria contnua tambm deve seraplicado.

FONTE: acessado em 21 nov2012. A primeira soluo a ser feita montar um Service DESK o objetivo prover aos lientes da Software Developer um ponto nico de contato (PUC) ou single point of contact (SPOC), vital para uma comunicao efetiva entre os usurios e as equipes da empresa. A misso principal do service desk o restabelecimento da operao normal dos srvios dos Clientes o mais rpido possvel, minimizando o impacto nos negcios causadospor falhas de TI. Para um provimento de servios de service desk com qualidade, este service desk poder utilizar as melhores prticas ITIL ou outras metodologias demercado. Ferramentas de Gesto de Servios de TI

25

7/29/2019 115437403-PIM-VII

26/31

bem estruturadas, tambm so vitalcias para o provimento de um bom servio. Para que sjam alcanadas todas as expectativas do cliente, interno ou externo, deve-se estabelecer Acordos de Nvel de Servio (SLA). O SLA que definir em quanto tempo e de queforma o servio 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- Governana de TI e Governana Corporativa

Governana Corporativa o sistema pelo qual as sociedades so dirigidas e monitoradasenvolvendo os relacionamentos entre Acionistas/Cotistas, Conselho de Administrao,Diretoria, Auditoria Independente e Conselho Fiscal. As boas prticas de governanacorporativa tm a finalidade de aumentar o valor da sociedade, capital e facilitar 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 eficiente s demandas. Os controles propiciam um modelo para as reas das empresas e, em especial TI, aprimorarem os quesitos de eficincia, segurana, produtividade, acuracidade e disponibilidade dos processos.

Governana de TI est intimamente ligada responsabilidade dos executivos no que consiste liderana, estrutura e processos organizacionais que asseguram a sustentao d

estratgias da organizao e seus objetivos pela TI. A governana de TI est fundamentabsicamente em PESSOAS, PROCESSOS e TECNOLOGIA. muito importante saber que a governana deve estar em completa

26

7/29/2019 115437403-PIM-VII

27/31

conformidade com Lei Sarbanes-Oxley que visa confiana dos investidores, exigindoque as organizaes 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 usurios:

Liberdade 0: A liberdade para executar o programa, para qualquer propsito; Liberdade 1: A liberdade de estudar como o programa funciona, e adapt-lo para as suas necessidades;

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

Liberdade 3: A liberdade de modificar o programa e distribuir estas modificaes, demodo que toda a comunidade se beneficie.

fonte: acessado em 22out 2012.

O software, para ser livre, tambm precisa estar registrado sob uma licena. O idealizador do projeto GNU, sistema operacional criado em 1984 baseado em software livre, Richard Stallman, criou a Free Software Foundation ou Fundao do Software Livre, para tratar dos aspectos jurdicos e organizacionais do projeto. Atravs da Fundaoforam criadas as duas licenas fundadoras do software livre, a GNU GPL, sigla em ingls 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

7/29/2019 115437403-PIM-VII

28/31

de proteger a integridade do sistema de livre distribuio dos softwares, elas se estabeleceram como as licenas mais amplamente usadas pela comunidade que adota software livre. "O que se deve indagar se os termos destas licenas afrontam a lei brasileira", uma vez que tanto a Lei de Software quanto a Lei sobre Direitos Autorais so altamente protecionistas no Brasil, o que oposto ao que prega a filosofia do software livre.

Infelizmente no existe leis no Brasil que cubra todos os direitos dos autores desoftware 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 muito bonito de uso de software livre. Mas a maioria de seus principais produtos eservios no so livres, so gratuitos. O conceito de livre uma questo de liberdade.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 software e suporte ao usurio(helpdesk). Principais caractersticas do GLPI:

Multi Usurios Sistema de autenticao (local, LDAP, AD, POP/IMAP, CAS, X509) e multisrvidor;

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

28

7/29/2019 115437403-PIM-VII

29/31

Gesto e monitoramento de licenas; Gesto e atendimento de Helpdesk (ticketagem); Inventrio; Licena GPL; Plugins e etc

Fonte: http://www.thiagopassamani.com.br/glpi/o-que-e-glpi.html acessado em 22 out 2012.

5- Concluso Os procedimentos aqui citados visam melhoria nos processos de TI da empresa Software Developer. Pesquisas realizadas mostram que existem vrias pendncias a serem sanadas na rea de Gerenciamento de Projetos. Alguns pontos merecem umaateno em especial, visando seguir a lei Sarbanes-Oxley. Devero ser usados Modelos de Boas Prticas de Gesto de Softwares e Processos como o CMMI, Cobit e Itil, objetivando uma administrao estruturada e com qualidade. Investindo recursos de maneiracorreta, com base em Modelos de Boas Prtica e respeitando normas legais garantir aempresa um desenvolvimento eficaz com melhoria contnua do desempenho, oferecendoservios de qualidade, dentro do oramento de prazo. 6- Bibliografias / Referncias Documentao de SoftwareFonte:

Acesso em: 10 out 2012 Gerenciamento de Riscos: Fonte: Acesso em: 10 out2012.

29

7/29/2019 115437403-PIM-VII

30/31

Gerncia de Riscos no CMMI: Fonte: Acesso em: 10 out 2012. PMBOK:Fonte: Acesso em: 10 out 2012 Gerncia de Riscocom o PMBOK:Fonte: Acesso em: 10 out 2012Processo de Gerenciamento de Risco: Fonte: Acesso em: 15 out 2012 Plano do Gerenciamento de Risco:Fonte: Acesso em: 15 out 2012Aspectos do Desenvolvimento da lei SOX:Fonte: 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: 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. Software Livre: fonte: 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

30

7/29/2019 115437403-PIM-VII

31/31