Вы находитесь на странице: 1из 30

UNIP INTERATIVA PROJETO INTEGRADO MULTIDISCIPLINAR CURSOS SUPERIORES DE TECNOLOGIA

PROJETO INTEGRADO MULTIDISCIPLINAR VII ANÁLISE DE IMPACTO, PLANEJAMENTO, DESENVOLVIMENTO IMPLEMENTAÇÃO DE MELHORAS NOS PROCESSOS DE TI DA SOFTWARE DEVELOPER

Araraquara /SP 2012

UNIP INTERATIVA PROJETO INTEGRADO MULTIDISCIPLINAR CURSOS SUPERIORES DE TECNOLOGIA

PROJETO INTEGRADO MULTIDISCIPLINAR VII ANÁLISE DE IMPACTO, PLANEJAMENTO, DESENVOLVIMENTO IMPLEMENTAÇÃO DE MELHORAS NOS PROCESSOS DE TI DA SOFTWARE DEVELOPER

NOME: HIGOR VILLA GANDRA RA: 1127303

CURSO: CURSO SUPERIOR DE TECNOLOGIA EM GESTÃO DA TECNOLOGIA DA INFORMAÇÃO

3º SEMESTRE

Araraquara /SP 2012

RESUMO

A Software Developer é uma Empresa de Desenvolvimento de Sistemas, localizada na Cidade de Araraquara - SP. A Empresa vem apresentando alguns problemas em seus processos de Desenvolvimento, Documentação e serviços de Help Desk em seus processos. Em face destes problemas, a empresa contratou a Consulting, empresa especializada desenvolvimento de software para Bancos, tendo como principais produtos os Sistemas de Consórcio, Financiamentos e Empréstimos. A empresa Consulting elaborou um estudo contendo Análise de Impacto, Planejamento, Desenvolvimento e como implementar melhorias nos processos de TI da contratante Software Developer.

Serão usados modelos de Boas Práticas para a Melhoria do Processo de Desenvolvimento de Software, orientados pela Governança de TI e pelo CMMI, SOX, Cobit e ITIL.

PALAVRAS-CHAVE:

desenvolvimento,

planejamento, análise, processos.

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,

SUMÁRIO

1- Introdução

07

1.1- Documentação de Softwares

08

1.2- Uso da Documentação

08

1.3- Documentação do Processo

08

1.4- Documentação do Produto

09

1.4.1.- Documentação do Usuário

10

1.4.2- Documentação do Sistema

11

1.5- Documentação do Código

11

1.5.1- Escolha de Nomes

12

1.5.2- Organização Visual

12

1.6- Qualidade dos Documentos

12

2- Gerenciamento de Riscos

13

2.1- Gerência de Riscos no CMMI

14

2.2- PMBOK

16

2.3- Gerência de Risco com PMBOK

17

2.4- Processo de Gerenciamento de Risco

18

2.5- Plano de Gerenciamento de Risco

19

3-

Lei SOX

19

3.1- Aspectos do Desenvolvimento da Lei SOX

19

3.2- Cobit e Itil

20

3.3- Cobit

21

3.4- Itil

21

3.4.1- Service Desk e Itil

22

3.5- Governança de TI e Governança Corporativa

26

4- Software Livre

28

4.1- GPLI

29

5-

Conclusão

29

6- Bibliografias / Referências

29

Introdução

Realizado a análise dos problemas encontrados na empresa Software Developer, notou-se que alguns processos necessitam de melhorias para que haja um funcionamento dentro dos requisitos de qualidade e legalidade. As melhorias citadas abrangem as áreas de Governança de TI, Gestão de Qualidade e Sistemas para Internet e Softwares Livres. Cada melhoria citada tem papel fundamental nas melhorias dos processos da empresa Software Developer. Serão usados como base os modelos de boas práticas para a Melhoria dos Processos de Desenvolvimento de Softwares, objetivando processos que permitam desenvolver softwares com qualidade dentro de prazos, custos e requisitos definidos.

1.1- Documentação de Softwares

Qualquer software deve ter uma quantidade razoável de documentação. - Documentos de trabalho. - Manuais de usuário produzidos profissionalmente.

Em geral, a maioria destes documentos é produzida por engenheiros de software. Uma parte considerável dos custos de um projeto pode ser gasta com documentação.

1.2- Uso da Documentação

Meio de comunicação entre os membros de um grupo de desenvolvimento; Informações para as pessoas que venham a fazer manutenção no sistema; Informações à gerência de modo a ajudar a planejar, fazer o orçamento e o cronograma; Informações para ensinar aos usuários como utilizar e administrar o sistema.

1.3- Documentação do Processo

É produzida para que o processo de desenvolvimento do software seja administrável Registram os processos de desenvolvimento e manutenção do software. Documentação do Processo - Categorias -Planos estimativos e cronogramas.

Produzidos por gerentes

Usados

-Relatórios

para

prever

e

controlar

o

processo.

Descrevem

como

os

recursos

foram

utilizados

durante

o

desenvolvimento

 

do

software

-Padrões

Estabelecem como o processo deve ser implementado;

Podem ser organizacionais, nacionais, ou Internacionais.

-Memorandos, comunicações, mensagens eletrônicas

Registram

as

comunicações

entre

gerentes

e

engenheiros

de

software

-Documentos técnicos de trabalho

Registram as ideias e pensamentos dos engenheiros de software.

Descrevem estratégias de implementação.

Registram problemas já identificados.

Especificam as razões para as decisões de projeto.

1.4- Documentação do Produto

Descreve o software que está sendo desenvolvido;

É muito utilizada depois que o sistema é implementado, mas é essencial também para a administração do processo de desenvolvimento

Descreve o software produzido.

Tem vida longa e deve estar sempre atualizada em relação ao código. Divide-se em:

Documentação do usuário.

Documentação do sistema

1.4.1.- Documentação do Usuário

Deve levar em conta os diversos tipos de usuários. É importante distinguir entre os vários usuários. Exemplo:

Usuários finais

Usam o software para auxiliá-los em alguma tarefa

Não estão interessados em detalhes técnicos ou administrativos.

Administradores do sistema

Responsáveis pela administração do software

Ex: operadores, gerentes de rede, etc.

Descrição funcional do sistema

Requisitos gerais do sistema

Serviços fornecidos por ele

Manual de introdução

Apresenta uma introdução informal do sistema e descreve seu uso normal

Deve explicar como começar a usar o sistema e como os usuários podem utilizar as facilidades oferecidas pelo sistema

Manual de referência

Descreve as facilidades do sistema e seu uso

Fornece uma lista das mensagens de erro e descreve como agir quando os erros ocorrerem

Deve ser completo e técnicas de descrição formal podem ser utilizadas

Documento de instalação

Descreve como instalar o sistema

Especifica a plataforma mínima necessária à sua instalação

Manual do administrador do sistema.

Informações relevantes para uma boa administração do sistema

Manual de referência rápida do sistema.

Informações concisas das principais funções do sistema e como utilizá-las

Mensagens de erros mais comuns.

Ajuda on-line

1.4.2- Documentação do Sistema

Descreve a implementação do sistema, desde a especificação dos requisitos até o plano de testes.

É importante que seja estruturada com overviews levando a especificações mais detalhadas e formais de cada aspecto do sistema. Documento de requisitos

Descrição da arquitetura do sistema

Descrição da arquitetura de cada um dos programas

Listagens do código fonte dos programas

1.5- Documentação do Código

Pode ser extremamente útil para melhorar (facilitar) o entendimento dos programas:

Escolha de nomes;

Organização visual;

Comentários.

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

1.5.2- Organização Visual Maneira como o código aparece na tela do computador ou em uma listagem. Os padrões de boa codificação mais aceitos incluem:

Um único comando por linha;

Espaçamento entre os componentes dos

comandos;

Indentação.

Devem ser usados para explicar o que o software faz, ao invés de como ele faz.

1.6- Qualidade dos Documentos

A qualidade da documentação é tão importante quanto a qualidade do

código.

Aspectos importantes para se conseguir produzir bons documentos incluem:

Planejamento (ou projeto) dos documentos;

A existência de padrões a serem seguidos;

Procedimentos de garantia de qualidade.

Padrão do Processo de Documentação

-Procedimentos de desenvolvimento:

Ferramentas;

Procedimentos de qualidade.

Flexíveis para lidar com todos os tipos de documentos;

Aplicam-se a todos os documentos (de um projeto)

Identificação;

Estrutura;

Apresentação;

Indicação de mudanças.

Fonte:

9> Acesso em: 10 out 2012

2- Gerenciamento de Riscos

O gerenciamento de riscos trabalha justamente com a incerteza, visando à identificação de problemas potenciais e de oportunidades antes que eles ocorram, com o objetivo de eliminar ou reduzir a probabilidade de ocorrência e o impacto de eventos negativos para os objetivos do projeto, além de potencializar os efeitos da ocorrência de eventos positivos. O gerenciamento de riscos é abordado por vários modelos que controlam a qualidade do processo de desenvolvimento de software dentre os quais o PMBOK, o CMMI, o RUP e o MSF. O CMMI (Capability Maturity Model Integration for Software) provê um framework para a implantação e melhoria do processo de software das organizações. O RUP (Rational Unified Process) é um processo baseado em melhores práticas de Engenharia de Software. O MSF (Microsoft Solutions Framework) tem sido usado pela Microsoft como o seu “método” para desenvolvimento de soluções de software dentro da Microsoft e também para

os milhares de clientes e parceiros da Microsoft em todo o mundo. O PMBOK (Project Management Body of Knowledgement) trata do gerenciamento de projetos de uma forma ampla, não sendo específico para software.

2.1- Gerência de Riscos no CMMI

O CMMI (Capability Maturity Model Integration) é considerado um modelo de

gestão de processos que tem como objetivo prover às empresas, um conjunto de melhores práticas que possa suportar a melhoria contínua de seu desempenho, bem como ser referência para eventuais comparações por meio de seus níveis de maturidade e capacidade. O CMMI contém práticas (Genéricas e Específicas) necessárias à maturidade em disciplinas específicas (Systems Engineering (SE), Software Engineering (SE), Integrated Product and Process Development (IPPD), Supplier Sourcing (SS)).

Desenvolvido

pelo

SEI

(Software

Engineering

Institute)

da

University

Carnegie Mellon, o CMMI é uma evolução do CMM 2 e procura estabelecer um modelo único para o processo de melhoria corporativo, integrando diferentes modelos e disciplinas. O CMMI-SW contém duas representações: por estágios, e

contínua. A representação por estágios trata do nível de maturidade da organização como um todo, contendo cinco níveis de maturidade: inicial, gerenciado, definido, gerenciado quantitativamente e em otimização.

1- A Representação Contínua: Possibilita à organização utilizar a ordem de

melhoria que melhor atender os objetivos de negócio da empresa.

É caracterizado por Níveis de Capacidade (Capability Levels):

Nível 0: Incompleto (Ad-hoc)

Nível 1: Executado (Definido)

Nível 2: Gerenciado / Gerido

Nível 3: Definido

Nível 4: Quantitativamente gerenciado / Gerido quantitativamente

Nível 5: Em otimização (ou Optimizado)

2-Representação Por Estágios: Disponibiliza uma seqüência pré- determinada para melhoria baseada em estágios que não deve ser desconsiderada, pois cada estágio serve de base para o próximo.

É caracterizado por Níveis de Maturidade (Maturity Levels):

Nível 1: Inicial (Ad-hoc)

Nível 2: Gerenciado / Gerido

Nível 3: Definido

Nível 4: Quantitativamente gerenciado / Gerido quantitativamente

Nível 5: Em otimização

Cada nível é constituído por um conjunto de áreas de processos, compostas por objetivos específicos e objetivos genéricos. Cada objetivo específico pode ser composto por um conjunto de práticas específicas. Um objetivo específico (SG, Specific Practices by Goal) descreve as características que devem estar presentes para satisfazer uma área de processo.

Uma prática específica (SP, Specific Practices) é a descrição de uma atividade que é considerada importante para se alcançar o objetivo específico a ela associado.

A problemática do risco é abordada nas áreas de processo Planejamento do Projeto, Monitoração e Controle do Projeto, e Gerência de Risco. As duas primeiras áreas de processo estão no nível 2 e a última está no nível 3 do CMMI-SW. No Planejamento do Projeto, tem-se o SG “Desenvolvimento do Plano do Projeto” com a SP “Identificar os Riscos do Projeto”, que consiste na identificação e na análise dos riscos para se determinar o impacto, a probabilidade de ocorrência e o período em

que podem ocorrer, para que os riscos possam ser priorizados. Na Monitoração e Controle do Projeto, tem-se o SG Monitorar o Projeto de Acordo com o Plano, onde está inserido a SP Monitorar os Riscos do Projeto. A Gerência de Risco no CMMI tem por finalidade identificar potenciais problemas antes que ocorram, de forma que as atividades de administração desses riscos possam ser planejadas e realizadas, de acordo com suas necessidades, ao longo do ciclo de vida do produto ou projeto, para mitigar possíveis impactos adversos. (ROCHA e BELCHIOR, 2004) Fonte: <http://www.flf.edu.br/revista-flf/monografias- computacao/monografia_thiago_coelho.pdf> Acesso em: 10 out 2012.

2.2- PMBOK O PMI (Project Management Institute) é uma organização internacional sem fins lucrativos, fundada em 1969 por um grupo de cinco voluntários, na Filadélfia - Pensilvânia - EUA. O principal objetivo do PMI tem sido a definição e divulgação das melhores práticas em gestão de projetos. Além de desenvolver normas, seminários, programas educacionais e certificação profissional. Possui mais de 100.000 (cem mil) membros em todo o mundo e já certificou mais de 50.000 (cinqüenta mil) PMP (Project Management Professional). O PMI estima que 10 trilhões de dólares sejam gastos anualmente no mundo em projetos, o que equivale a aproximadamente 25% do PIB mundial, e que cerca de 16,5 milhões de profissionais estão envolvidos diretamente com a Gerência de Projetos no mundo. Este volume de projetos e mudanças constantes no cenário competitivo mundial gera a crescente necessidade de resultados mais rápidos, com qualidade e a um custo competitivo. Fatores como a globalização do mercado e aquisições de novas tecnologias emergentes, tornam cada vez maior a Gerência de Projetos um assunto da mais alta importância para as organizações e para sua capacidade de sobrevivência. Pesquisas realizadas pelo PMI mostram que 75% dos seus membros indicaram que, nos próximos anos, suas empresas estarão dando maior importância para a gerência de projetos. Fonte: <http://www.flf.edu.br/revista-flf/monografias- computacao/monografia_thiago_coelho.pdf> Acesso em: 10 out 2012

2.3- Gerência de Risco com PMBOK

O desenvolvimento de software tem avançado tecnologicamente em rápidas proporções, mas existem fatores que ocorrem desde o começo desse avanço, são eles: os erros de gestão e a falta de sucesso do software desenvolvido, muitas vezes não atendendo o que cliente desejava. Para o sucesso ser completo, o produto final deve ser entregue dentro do prazo, com o custo especificado, e ser realmente aquilo que o cliente necessitava. A Gerência de Projetos é uma solução para os problemas que as equipes de desenvolvimento de Software vêm enfrentando, porque é distribuída em áreas de conhecimento, onde cada uma delas descreve seus respectivos processos a fim de garantir que os objetivos planejados sejam atingidos. As técnicas de gerenciamento de 32 projetos estão sendo aprimoradas constantemente, buscando sempre garantir o sucesso dos processos. O Project Management Body of Knowledge, também conhecido como PMBOK é um conjunto de práticas em gerência de projetos levantado pelo Project Management Institute (PMI) e constituem a base da metodologia de gerência de projetos do PMI. Estas práticas são compiladas na forma de um guia, chamado de Guia do Conjunto de Conhecimentos em Gerenciamento de Projetos, ou Guia PMBOK. (ALENCAR, 2006) O Gerente de projetos é a pessoa responsável pela realização dos objetivos do projeto, identificando às necessidades, estabelecendo objetivos claros e possíveis de ser alcançados e tentar equilibrar qualidade, escopo, tempo e custo, a ainda atender às expectativas das partes interessadas no projeto. Ele e sua equipe deverão seguir um código de ética e conduta profissional para aqueles que possuem a certificação PMP. No gerenciamento de projetos são aplicados os conhecimentos, habilidades, ferramentas e técnicas às atividades do projeto e é realizado através da aplicação e da integração das seguintes áreas de competências gerências, são elas:

Gerenciamento de Integração, Gerenciamento de Escopo, Gerenciamento de Tempo, Gerenciamento do Custo, Gerenciamento da Qualidade, Gerenciamento dos

Recursos Humanos, Gerenciamento da Comunicação, Gerência de Aquisições e Gerência de Riscos Fonte: <http://www.flf.edu.br/revista-flf/monografias- computacao/monografia_thiago_coelho.pdf> Acesso em: 10 out 2012

2.4- Processo de Gerenciamento de Risco

O inicio de um projeto é marcado por um grande esforço. No planejamento do projeto, são realizadas reuniões tendo como foco os objetivos do projeto: Escopo, Qualidade, Prazo e Custo. Neste momento já é importante pensar nos riscos pois à medida que os objetivos vão se consolidando, os possíveis riscos vão se tornando mais prováveis, podendo comprometer o andamento do projeto. Os processos do gerenciamento de riscos do projeto estão dispostos da seguinte forma:

a. Plano de Gerenciamento do Risco: decide como abordar, planejar e executar as

atividades de gerência de risco para um projeto;

b. Identificação dos Fatores de Risco: determina quais riscos podem afetar o projeto e documenta suas características;

c. Análise Qualitativa de Risco: realiza uma análise qualitativa dos riscos e as

condições para priorizar seus efeitos nos objetivos do projeto.

d. Análise Quantitativa de Risco: mede a probabilidade através de uma análise

numérica e as conseqüências dos riscos e estima suas implicações para os objetivos

do projeto.

e. Planejamento de resposta ao Risco: desenvolve procedimentos e técnicas para

melhorar as oportunidades e reduzir as ameaças para os objetivos do projeto. f. Monitoramento e Controle do Risco: monitora riscos residuais identifica novos riscos, executa planos de redução de risco e avalia sua eficácia durante todo o ciclo do projeto.

Esses processos não ocorrem isoladamente, eles interagem entre si e também com processos de outras áreas.

2.5- Plano de Gerenciamento de Risco

Dentro de um processo de administração de risco, o seu plano de gerenciamento visa garantir que o tipo, o nível e a visibilidade da Gerência de Risco sejam compatíveis com o risco e com a importância do projeto. O Plano gerencial de riscos deve ser terminado já no início do planejamento do projeto, por ser essencial para executar com sucesso as outras atividades de planejamento. O Plano do Gerenciamento do Risco é, portanto, um documento que explica como será desenvolvido o processo gerencial do risco, o custo estimado e investido e a nomeação de responsabilidades aos gestores e envolvidos. Os processos do Plano de Gerenciamento de Riscos não atuam isoladamente, interagem entre si e com os processos de outras áreas, ocorrendo pelo menos uma vez em cada projeto. Fonte: <http://www.flf.edu.br/revista-flf/monografias- computacao/monografia_thiago_coelho.pdf> Acesso em: 15 out 2012

3.1- Aspectos do Desenvolvimento da Lei SOX Ao implantar a Lei SOX é necessário, que sejam adotadas boas práticas de governança corporativa, pois além da empresa conquistar espaço ela também obtém confiança por parte de todos os envolvidos na corporação, principalmente para os investidores, que vêem nessas boas práticas um diferencial para tomar decisões de investimento e da sua participação na mesma. De acordo com a Cartilha CVM (2002, p.1) define-se governança corporativa como segue:

Governança corporativa é o conjunto de práticas que tem por finalidade otimizar o desempenho de uma companhia ao proteger todas as partes interessadas, tais como investidores, empregados e credores, facilitando o acesso ao capital. A análise das práticas de governança corporativa aplicada

ao mercado de capitais envolve, principalmente: transparência, eqüidade de tratamento dos acionistas e prestação de contas. Complementa Steinberg (2003, p.18), como definição usual em sua publicação:

constitui o conjunto de práticas de relacionamentos entre acionistas/cotistas, conselho de administração, diretoria executiva, auditoria independente e conselho fiscal com a finalidade de aprimorar o desempenho da empresa e facilitar o acesso ao capital. Nas definições acima, é possível considerar que boas práticas de governança corporativa juntamente com o mercado de capitais buscam envolvimento dos stakeholders (públicos de interesse), acionistas e controladores através da transparência das informações, tratamento igual para todos os acionistas e prestação de contas. Segundo Andrade e Rossetti, citado por (2004 Gallon e Beuren 2006, p.4), resumem os diversos conceitos de governança corporativa a partir de expressões- chave que procuram definir sua diversidade e abrangência.

Fonte:

http://www.praticacontabil.com/contadorperito/Lei_Sarbanes_Oxley_e_seus_efeitos.

pdf > Acesso em: 15 out 2012

<

3.2- Cobit e Itil Todo Projeto estará alinhado com as melhores praticas orientadas pelo Cobit e ITIL.

O CobiT está dividido em quatro domínios:

1. Planejamento e organização.

2. Aquisição e implementação.

3. Entrega e suporte.

4. Monitoração.

Fonte: < http://efagundes.com/artigos/COBIT.htm > Acesso em: 15 out 2012 3.3- Cobit O CobiT é um

Fonte: < http://efagundes.com/artigos/COBIT.htm> Acesso em: 15 out 2012

3.3- Cobit O CobiT é um guia para a gestão de TI recomendado pelo ISACF (Information Systems Audit and Control Foundation, www.isaca.org). O CobiT inclui recursos tais como um sumário executivo, um framework, controle de objetivos, mapas de auditoria, um conjunto de ferramentas de implementação e um guia com técnicas de gerenciamento. As práticas de gestão do CobiT são recomendadas pelos peritos em gestão de TI que ajudam a otimizar os investimentos de TI e fornecem métricas para avaliação dos resultados. O CobiT independe das plataformas de TI adotadas nas empresas. Fonte: < http://efagundes.com/artigos/COBIT.htm> Acesso em: 15 out 2012

3.4- Itil

O ITIL™ (Information Technology Infrastructure Library) é o modelo de referência para gerenciamento de processos de TI mais aceito mundialmente. A metodologia foi criada pela secretaria de comércio (Office of Government Commerce, OGC) do governo Inglês, a partir de pesquisas realizadas por Consultores, Especialistas e Doutores, para desenvolver as melhores práticas para a gestão da área de TI nas empresas privadas e públicas. Atualmente se tornou a norma BS-15000, sendo esta um anexo da ISO 9000/2000. O foco deste modelo é descrever os processos necessários para gerenciar a infra-estrutura de TI eficientemente e eficazmente de modo a garantir os níveis de serviço acordados com os clientes internos e externos “As normas ITIL™ estão documentadas em aproximadamente 40 livros, onde os principais processos e as recomendações das melhores práticas de TI estão descritas. O ITIL™ é composto por módulos. Os mais importantes são o “”IT Service Support”" e o “”IT Service Delivery”".

Características do ITIL™

• Modelo de referência para processos de TI não proprietário;

• Adequado para todas as áreas de atividade;

• Independente de tecnologia e fornecedor;

• Baseado nas melhores práticas;

• Um modelo de referência para a implementação de processos de TI;

• Checklist testado e aprovado;

• O que fazer e o que não fazer.

> Acesso em: 15 out 2012

3.4.1- Service Desk e Itil

Há alguns anos, o Service Desk, infelizmente, era tratado apenas como uma área secundária dentro da empresa. TI costumava dar mais valor as equipes de suporte e outras áreas consideradas “mais nobres para o negócio”, deixando para a Central de Serviços um papel secundário. Com a implementação das melhores práticas em gerenciamento de serviços de TI (ITIL®®), essa visão finalmente e de maneira muito justa foi alterada.

O Service Desk é uma “entidade independente”, não apenas um processo dentro das melhores práticas. É uma função, um departamento, uma organização

com importância estratégica para a prestação de serviços de TI. Por ser o ponto único de contato entre TI e usuários , ele é diretamente responsável pela percepção

e satisfação dos mesmos.

Antes de tudo, é preciso entender as diferenças entre os modelos existentes de centrais de atendimento. São três tipos:

1. CALL CENTER: modelo de atendimento que registra as solicitações e encaminha para o suporte específico. Seu principal objetivo é atender grande volume de chamadas e direcioná-las.

2. HELPDESK: modelo de atendimento que gerencia , coordena e resolve incidentes

o mais rápido possível. Garantindo que requisições não sejam perdidas.

3. SERVICE DESK: Além de apresentar as duas características anteriormente apresentadas, oferece serviços com foco em TI e nos negócios, lidando com incidentes e provendo interfaces para outros processos, como requisições de mudanças, níveis de serviços, gerência de disponibilidade, dentre outros.

Resumindo, o Service Desk possui 3 características importantíssimas:

Representam o provedor de serviços.

Defendem pessoas, processos e tecnologia ( o lema do ITIL®®l!!!)

Operam no princípio da satisfação do usuário.

Ele

é

responsável

por

gestionar

e

acompanhar

todas

as

solicitações

(incidentes, mudanças, requisições, consultas, reclamações e etc).

É um departamento cobrado e medido por:

Tempo de atendimento;

Tempo de espera;

Tempo de registro de um chamado;

Taxa de abandono de ligações;

Conhecimento técnico do assunto;

Controle das solicitações atendidas dentro e fora do prazo (SLA);

Acompanhamento do incidente (ciclo de vida do incidente);

Classificação da solicitação, etc.

Implantar um service desk, na maioria das vezes, é uma das primeiras missões que uma implantação ITIL®® recebe. No início, significa concentrar todas as chamadas um único atendimento, abrindo se possível, outras formas de contato, como e-mail e também uma interface WEB do sistema de registro de chamados, permitindo ao usuário realizar o registro de forma independente.

Durante a implantação é preciso atentar-se os três pilares importantíssimos do ITIL®® pessoas, processos, ferramentas. São pontos de atenção:

selecionar corretamente o pessoal para atendimento e treiná-los pontualmente e periodicamente: é importante selecionar pessoas com conhecimento técnico, mas somente isso não é suficiente para garantir um bom atendimento. É preciso pessoas com os chamado “soft skills” : conhecimentos relacionados a capacidade comunicação, raciocínio lógico e rápido, presteza e postura adequada para que um bom atendimento seja realizado. Além disso, as equipes precisam ser treinadas quando a central de serviços for implementada e depois disso periodicamente para que o conhecimento não seja dissipado.

Definição correta de processos: é preciso definir como o será o atendimento, como a central de serviços se relacionará com os outros processos ITIL®®,

resumindo, qual o verdadeiro papel e responsabilidade da central de serviços para a organização.

Seleção correta de ferramentas para suportar o service desk: uma boa ferramenta de incidentes, uma boa central de distribuição de ligações são fatores chave para o sucesso de um service Desk.

Deve haver comprometimento gerencial, liderança pelo exemplo: os gerentes devem se comprometer inteiramente em tornar a central de serviços um sucesso, não abrindo exceções no ponto único de contato e auxiliando na conscientização de suas equipes da importância e do valor agregado da central de serviços para uma organização.

Campanhas de conscientização para os usuários da Central de serviços:

devem ser feitas apresentações, eventos, workshops e reuniões para que os usuários passem a enxergar o valor agregado de uma central de serviços para a organização e aceitem utilizar os serviços da central (aceitação que promoverá a mudança cultural para a implementação da Central de Serviços).

Não deve-se esperar um Service Desk 100% eficaz e eficiente já no primeiro dia da implementação. É natural que o Service Desk com o tempo vá ganhando

experiência (curva de aprendizado e maturidade), suportado pelos outros processos de suporte e entrega de serviços. Mais do que nunca, o modelo de melhoria

contínua também

2012.

deve

ser

aplicado.

A primeira solução a ser feita é montar um Service DESK o objetivo é prover aos clientes da Software Developer um ponto único de contato (PUC) ou single point of contact (SPOC), vital para uma comunicação efetiva entre os usuários e as equipes da empresa. A missão principal do service desk é o restabelecimento da operação normal dos serviços dos Clientes o mais rápido possível, minimizando o impacto nos negócios causados por falhas de TI. Para um provimento de serviços de service desk com qualidade, este service desk poderá utilizar as melhores práticas ITIL ou outras metodologias de mercado. Ferramentas de Gestão de Serviços de TI

bem estruturadas, também são vitalícias para o provimento de um bom serviço. Para que sejam alcançadas todas as expectativas do cliente, interno ou externo, deve-se estabelecer Acordos de Nível de Serviço (SLA). O SLA é que definirá em quanto tempo e de que forma o serviço será prestado. Podemos utilizar dois tipos de atendimento por telefones ou por um sistema web, onde o cliente abre um chamado ou ticket para ser solucionado, neste caso optamos pelo Software GLPI.

3.5- Governança de TI e Governança Corporativa

são

dirigidas e monitoradas, envolvendo os relacionamentos entre Acionistas/Cotistas,

Conselho de Administração, Diretoria, Auditoria Independente e Conselho Fiscal. As boas práticas de governança corporativa têm a finalidade de aumentar o valor da

Governança

Corporativa

é

o

sistema

pelo

qual as

sociedades

sociedade,

facilitar

seu

acesso

ao

capital

e

contribuir

para

a

sua

perenidade.”

IBGC Instituto Brasileiro de Governança Corporativa.

A Governança permite uma maior agilidade operacional e uma resposta rápida e eficiente às demandas. Os controles propiciam um modelo para as áreas das empresas e, em especial TI, aprimorarem os quesitos de eficiência, segurança, produtividade, acuracidade e disponibilidade dos processos.

Governança de TI está intimamente ligada à responsabilidade dos executivos no que consiste à liderança, à estrutura e processos organizacionais que asseguram a sustentação das estratégias da organização e seus objetivos pela TI. A governança de TI está fundamentada básicamente em PESSOAS, PROCESSOS e TECNOLOGIA. É muito importante saber que a governança deve estar em completa

conformidade com Lei Sarbanes-Oxley que visa à confiança dos investidores, exigindo que as organizações selecionem e implementem um framework de controle interno adequado.

Fonte: http://www.devmedia.com.br/governanca-de-ti/8636 acessado em 22 out 2012.

4- Software Livre

A Free Software Foundation considera um software como livre quando atende aos quatro tipos de liberdade para os usuários:

Liberdade 0: A liberdade para executar o programa, para qualquer propósito;

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

Liberdade 2: A liberdade de redistribuir cópias do programa de modo que você possa ajudar ao seu próximo;

Liberdade 3: A liberdade de modificar o programa e distribuir estas modificações, de modo que toda a comunidade se beneficie.

O software, para ser livre, também precisa estar registrado sob uma licença. O idealizador do projeto GNU, sistema operacional criado em 1984 baseado em software livre, Richard Stallman, criou a Free Software Foundation ou Fundação do

Software Livre, para tratar dos aspectos jurídicos e organizacionais do projeto. Através da Fundação foram criadas as duas licenças fundadoras do software livre, a GNU GPL, sigla em inglês para o termo Licença Pública Geral e a GNU LGPL,

Licença

Criadas em 1989, nos Estados Unidos, e revisadas em 1991, com objetivo

Geral.

Pública

Menos

de proteger a integridade do sistema de livre distribuição dos softwares, elas se estabeleceram como as licenças mais amplamente usadas pela comunidade que

adota software livre. "O que se deve indagar é se os termos destas licenças afrontam a lei brasileira", uma vez que tanto a Lei de Software quanto a Lei sobre Direitos Autorais são altamente protecionistas no Brasil, o que é oposto ao que

livre.

Infelizmente não existe leis no Brasil que cubra todos os direitos dos autores de software livres, o software livre não é software gratuito. Este é um erro muito comum, mas que pode ter graves consequências. O Google, por exemplo, tem um discurso muito bonito de uso de software livre. Mas a maioria de seus principais produtos e serviços não são livres, são gratuitos. O conceito de livre é uma questão de liberdade. Deve ser pensado como em “liberdade de expressão”, não em "cerveja grátis”.

prega

a

filosofia

do

software

4.1- GPLI

GLPI é uma solução web Open-source completa para gestão de ativos e helpdesk. O mesmo gerência todos os seus problemas de inventário de ativos/hardwares e software e suporte ao usuário(helpdesk).

Principais características do GLPI:

Multi Usuários

Sistema de autenticação (local, LDAP, AD, POP/IMAP, CAS, X509…) e multi- servidor;

Vários idiomas;

Niveis de usuário;

Sistema de notificações sobre eventos via email;

Gestão de pedidos de assistência via web ou email;

Relatórios com gráficos;

Integração com OCS Inventory NG;

Gestão e controle de computador;

Gestão e monitoramento de licenças;

Gestão e atendimento de Helpdesk (ticketagem);

Inventário;

Licença GPL;

Plugins e etc…

5- Conclusão

Os procedimentos aqui citados visam à melhoria nos processos de TI da empresa Software Developer. Pesquisas realizadas mostram que existem várias pendências a serem sanadas na área de Gerenciamento de Projetos.

Alguns pontos merecem uma atenção em especial, visando seguir a lei Sarbanes-Oxley. Deverão ser usados Modelos de Boas Práticas de Gestão de

Softwares e Processos como o CMMI, Cobit e Itil, objetivando uma administração estruturada e com qualidade.

Investindo recursos de maneira correta, com base em Modelos de Boas Prática e respeitando normas legais garantirá a empresa um desenvolvimento eficaz com melhoria contínua do desempenho, oferecendo serviços de qualidade, dentro do orçamento de prazo.

6- Bibliografias / Referências

Documentação

9> Acesso em: 10 out 2012

Gerenciamento

de

Software

Fonte:

de

Riscos:

Fonte:

Gerência de Riscos no CMMI: Fonte: <http://www.flf.edu.br/revista-flf/monografias- computacao/monografia_thiago_coelho.pdf> Acesso em: 10 out 2012.

PMBOK:

Plano

Aspectos

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

Fonte:

Gerência

Processo

do

de

de

Risco

com

o

PMBOK:

de

Risco:

Risco:

Fonte:

Fonte:

Fonte:

da

Gerenciamento

Gerenciamento

do

de

lei

SOX:

Fonte:

<

Desenvolvimento

acessado

em

21

nov

2012.

Governança

de

TI

e

a

Governança

Corporativa:

 

Fonte:

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