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

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 GESTO DA TECNOLOGIA DA INFORMAO 3 SEMESTRE

Araraquara /SP 2012

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, 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 da contratante 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,

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: processes.

development,

improvement,

planning,

analysis,

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.......................................................................................................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

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

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 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 de Softwares, objetivando processos que permitam desenvolver softwares com qualidade dentro de prazos, custos e requisitos definidos.

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. 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 Registram os processos de desenvolvimento e manuteno do software. Documentao do Processo - Categorias -Planos estimativos e cronogramas. Produzidos por gerentes

Usados

para

prever

controlar

processo.

-Relatrios Descrevem como os recursos foram do utilizados durante o

desenvolvimento

software

-Padres -Memorandos, comunicaes, mensagens eletrnicas Registram as comunicaes entre gerentes e engenheiros de software Estabelecem como o processo deve ser implementado; 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 identificados. 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:

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 alguma tarefa 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 Requisitos gerais do sistema Servios fornecidos por ele

Manual de introduo Apresenta uma introduo informal do sistema e descreve seu uso normal 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 lista 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

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

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

Manual de referncia rpida do sistema. Informaes concisas das principais funes do sistema 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 testes. 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 Listagens 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 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; Indentao. Um nico 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 importantes 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

-Procedimentos de desenvolvimento: Ferramentas; Procedimentos de qualidade. Flexveis 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 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 ocorrncia de eventos positivos. O gerenciamento de riscos abordado por vrios 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 implantao e melhoria do processo de software das organizaes. O RUP (Rational Unified Process) um processo baseado em melhores prticas de Engenharia de Software. O MSF (Microsoft Solutions Framework) tem sido usado 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 (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 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 para eventuais comparaes por meio de seus nveis de maturidade e capacidade. O CMMI contm prticas (Genricas e Especficas) necessrias maturidade em disciplinas especficas (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 evoluo do CMM 2 e 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 organizao como um todo, contendo cinco nveis de maturidade: inicial, gerenciado, definido, gerenciado quantitativamente e em otimizao. 1- A Representao Contnua: Possibilita organizao 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

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, 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 conjunto de prticas especficas. Um objetivo especfico (SG, Specific Practices by Goal) 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, Monitorao 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 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: <http://www.flf.edu.br/revista-flf/monografias-

computacao/monografia_thiago_coelho.pdf> Acesso em: 10 out 2012.

2.2- PMBOK O PMI (Project Management Institute) uma 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 melhores prticas em gesto de projetos. Alm de desenvolver normas, seminrios, programas educacionais 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 Professional). 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 mundial 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 tecnologias emergentes, tornam cada vez maior a Gerncia de Projetos um assunto da mais alta importncia para as organizaes e para sua capacidade de sobrevivncia. Pesquisas realizadas 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: <http://www.flf.edu.br/revista-flf/monografias-

computacao/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 existem 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 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 desenvolvimento de Software vm enfrentando, porque distribuda em reas de conhecimento, onde 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 s necessidades, 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 de competncias gerncias, so elas: Gerenciamento de Integrao, Gerenciamento de Escopo, Gerenciamento de Tempo, Gerenciamento do Custo, Gerenciamento da Qualidade, Gerenciamento dos

17

Recursos Humanos, Gerenciamento da Comunicao, Gerncia de Aquisies e Gerncia de Riscos

Fonte: <http://www.flf.edu.br/revista-flf/monografias-

computacao/monografia_thiago_coelho.pdf> Acesso em: 10 out 2012

2.4- Processo de Gerenciamento de Risco

O inicio de um projeto marcado por um grande 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, 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: 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 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 objetivos 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 objetivos do projeto. e. Planejamento de resposta ao Risco: desenvolve procedimentos e tcnicas 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 todo o ciclo do projeto.

18

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 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 isoladamente, interagem entre si e com os processos de outras reas, ocorrendo pelo menos uma vez em cada projeto.
Fonte: <http://www.flf.edu.br/revista-flf/monografias-

computacao/monografia_thiago_coelho.pdf> Acesso em: 15 out 2012

3.1- Aspectos do Desenvolvimento da Lei SOX Ao implantar a Lei SOX necessrio, que sejam adotadas boas prticas de governana corporativa, pois alm da empresa conquistar espao ela tambm obtm confiana por parte de todos os envolvidos na corporao, principalmente 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 CVM (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 corporativa aplicada

19

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 relacionamentos entre 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 boas 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 prestao 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:

<

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 organizao. 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 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 ajudam 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

O ITIL (Information Technology Infrastructure Library) o modelo de referncia para gerenciamento 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 de servio acordados com os clientes internos e externos As normas ITIL esto documentadas 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 importantes so o IT Service Support" e o IT Service Delivery". Caractersticas do ITIL Modelo de referncia para processos de TI no proprietrio; Adequado para todas as reas de atividade; Independente de tecnologia e fornecedor; Baseado nas melhores prticas; Um modelo 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 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 um papel secundrio. Com a implementao das melhores prticas em gerenciamento de servios de 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. uma funo, um departamento, uma organizao com importncia estratgica para a prestao de servios de TI. Por ser o ponto nico de contato entre TI e usurios , ele diretamente responsvel pela percepo e satisfao dos mesmos. Antes de tudo, preciso entender as diferenas 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 suporte especfico. 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 DESK: Alm 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 disponibilidade, 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

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 incidente); Classificao da solicitao, etc. Implantar um service desk, na maioria das vezes, 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 realizar o registro de forma independente. Durante a implantao preciso atentar-se os trs pilares importantssimos do ITIL pessoas, processos, ferramentas. So pontos de ateno:

selecionar

corretamente

pessoal

para

atendimento

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 um bom atendimento seja realizado. Alm disso, as equipes precisam ser treinadas quando a 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 central 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 incidentes, 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 excees no ponto nico de contato e auxiliando na conscientizao de suas equipes da importncia e do valor agregado da central de servios para uma organizao.

Campanhas de conscientizao para os usurios da Central de servios: devem ser feitas apresentaes, eventos, workshops e reunies para que os usurios passem a enxergar o valor 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 Servios). 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 (curva 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 clientes 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 servios 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, este 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 sejam 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 que forma 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 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 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 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 governana 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 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, 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 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 Fundao foram 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

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 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 muito 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 software e suporte ao usurio(helpdesk). Principais caractersticas do GLPI:

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

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 Inventory NG; Gesto e controle de computador;

28

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 uma ateno 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 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 Documentao 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/monografiascomputacao/monografia_thiago_coelho.pdf> Acesso em: 10 out 2012.

29

Gerncia de Riscos no CMMI: Fonte: <http://www.flf.edu.br/revista-flf/monografiascomputacao/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 Gerncia 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/revistaflf/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 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: <http://pt.wikipedia.org/wiki/Software_livre#GNU.2FLinux> acessado em 22 out 2012.

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

9df85a55-e61e-46d6-86ab-f10512a9bdfd

30