Pim Vii e Viii 2 Marcos Oliveira

Download Pim Vii e Viii 2 Marcos Oliveira

Post on 25-Nov-2015

135 views

Category:

Documents

13 download

TRANSCRIPT

24 UNIVERSIDADE PAULISTA CURSO SUPERIOR DE TECNOLOGIA GESTÃO EM TECNOLOGIA DA INFORMAÇÃO MARCOS OLIVEIRA MARTINS PIM VII PROJETO INTEGRADO MULTIDISCIPLINAR ESTUDO DA EMPRESA SOFTWARE DEVELOPER BELÉM – PARÁ 2014 MARCOS OLIVEIRA MARTINS PIM VII PROJETO INTEGRADO MULTIDISCIPLINAR ESTUDO DA EMPRESA SOFTWARE DEVELOPER Trabalho do Projeto Integrado Multidisciplinar – PIM VII e VIII, apresentado como exigência para conclusão do 4º Semestre do Curso Superior de Tecnologia Gestão em Tecnologia da Informação, da Universidade Paulista – UNIP, campus Entroncamento. Monitora: LUANE BARRAL BELÉM - PARÁ 2014 RESUMO  Este projeto foi elaborado com o intuito de demonstrar a possível aplicação prática dos estudos das disciplinas cursadas no bimestre. O escopo deste trabalho consiste em uma Consultoria de Análise dos Processos de TI de uma empresa fictícia de desenvolvimento de softwares para instituições financeiras – denominada aqui de Software Developer -, feita por uma empresa também fictícia - denominada aqui por Consulting (grupo PIM) -, com a finalidade de solucionar alguns problemas conhecidos pelos clientes da Software Developer, e outros a serem identificados. Na prática, o uso das técnicas de ferramentas de gestão de produtos de TI como ITIL, COBIT, eTOM, CMMI, e outras bibliotecas, são consolidadas no cenário mundial como paradigmas de metodologias de trabalho em praticamente todos tipo de atividade onde são utilizados equipamentos e sistemas computacionais. Em tese, este Projeto Multidisciplinar afirma que a adoção das mudanças propostas pela Consultoria, com base nas melhores práticas de gestão dos processos de TI, solucionaria grande parte dos problemas apresentados no case, que enfrenta a Desenvolvedora de Software, principalmente na manutenção e suporte aos sistemas implantados em seus clientes. Também são consideradas aqui questões de segurança e confiabilidade de dados e transações de negócios, em caráter extremo, principalmente pelo fato de o objeto das atividades desses usuários ser de natureza monetária, e englobar padrões de formatações internacionais como a SOX, e operações WEB com a expansão das políticas de Software Livre. De acordo com o case apresentado, a proposta da Consultoria classifica os principais problemas enfrentados pela Software Developer como de natureza estrutural identificada principalmente no que se refere ao Suporte aos Serviços de TI, indicando como medida de mitigação essencialmente a utilização das bibliotecas de Suporte a Serviços ITIL, e propõe também certificar alguns prestadores nesta ferramenta. Também foram propostas implantação e análises de Métricas de SLM para medir a qualidade das novas dinâmicas de trabalho adotadas. Palavras-chave: Processos de TI. Boas práticas. ITIL. COBIT. Qualidade. Suporte. Confiabilidade. Segurança. SLM.  ABSTRACT  This project was designed in order to demonstrate the possible practical application of studies of subjects taken in two months. The scope of this work is a Consulting IT Process Analysis of a fictitious company to develop software for financial institutions called here Software Developer - made by a fictitious company also - here named by Consulting (Group PIM) - in order to solve some problems known to the customers of Software Developer, and others to be identified. In practice, the use of techniques of management tools for IT products such as ITIL, COBIT, eTOM, CMMI and other libraries already established itself worldwide as paradigms of working methodologies in virtually every type of activity where they are used equipments and systems computing. In theory, this multidisciplinary project states that the adoption of the changes proposed by the Consultancy, based on best practices in managing IT processes. Solve most problems facing software developers, especially in the maintenance and support systems in place on their customers. Also considered here are issues of security and reliability of data and business transactions, in extreme character, mainly because the object of the activities of these users be monetary, and international formats include standards such as SOX, and operations with the WEB expansion of the policies of Free Software. According to the case presented, the proposal of Consulting ranks the major problems faced by Software Developer identified as mainly structural in nature with regard to IT Service Support, stating as a mitigation measure primarily the use of libraries of Support Services ITIL, and proposes some providers also make sure this tool. It was also proposed deployment and analysis of SLM metrics to measure the quality of the new dynamics of work adopted. Keywords: IT Processes. Best practices. ITIL. COBIT. Quality. Support. Reliability. Security. SLM.  Sumário 1- Introdução  6 2-Objetivos. 7 3- Referencial Teórico 7 4- Conceitos de ITIL 7 4.1- Estudo de casos de sucesso de aplicações ITIL 9 4.2- Bibliotecas ITIL de suporte a serviços  10 4.3- SLA e SLM 11 4.4- Conceitos SOX 11 4.5- Análises, ações de mitigação e qualidade 12 4.6- Treinamento e certificação ITIL 12 4.7- Implementação do projeto de suporte a serviços 13 5- Análise de infraestrutura e software livre 14 6- Análise de impactos e gestão de qualidade 14 7- Conclusão 15 8- Referências bibliográficas 16 9- Glossário  17 1- INTRODUÇÃO  Segundo o Web Site TI Exames, a aplicação da ITIL não é só um modismo cultural, pois em uma pesquisa realizada no Brasil pela IDG em 2005 foi constatado que 37% das empresas entrevistadas já utilizam em seus processos as boas práticas das disciplinas das bibliotecas ITIL na redução de custos, aproveitamento de recursos e melhora dos índices de satisfação de seus clientes. Portanto pode-se entender que, tendo como base o uso das ferramentas da Biblioteca ITIL de Suporte a Serviços, combinadas com o uso das melhores práticas de Desenvolvimento de Software do CMMI, e de gestão da qualidade, é possível não só conter problemas endêmicos no modelo atual, mas como também prever novas ocorrências de incidentes criando um ciclo de instruções de processos e desenvolvimentos de TI apoiados nessas eficazes práticas de gestão. 2-OBJETIVOS  Os principais objetivos da aplicação das medidas propostas por essa consultoria são a capacitação e excelência do módulo de Suporte a Serviços de TI da provedora de sistemas para instituições financeiras, a adequação da infraestrutura de TI, a segurabilidade dos serviços, a confiabilidade de uma empresa terceirizada e certificada em ITIL. Além disso, indicar no plano da qualidade que efeitos que uma estrutura embasada nestes modelos está essencialmente interelacionados com os problemas identificados na prática pelos usuários dos sistemas por ela desenvolvidos.  3- REFERENCIAL TEÓRICO  A base utilizada nesse projeto foi a metodologia ITIL, mais especificamente no módulo de Suporte a Serviços. Também foram considerados conceitos de estrutura de sistema baseados na lei Sarbanes- Oxley, pela razão de que a reformulação acontece em uma prestadora de serviços a instituições financeiras multinacionais. Além de estudos de casos de sucessos no mercado corporativo e em artigos publicados aqui citados em Referências.  4- CONCEITOS DE ITIL  ITIL é definida como sendo uma biblioteca personalizada de melhores práticas para a implementação de processos de gestão de TI. Trata-se de um conjunto de documentos que definem os processos a serem implementados para os serviços de suporte e de disponibilidade de forma a atingir uma gestão eficaz de serviço de TI de acordo com o negócio a que se destina. Cada módulo da biblioteca fornece um código de prática para melhorar a eficácia das TI, reduzindo custos e aumentando a eficácia e a qualidade de gestão e de infraestrutura dos serviços de TI. Esta gestão de serviços de TI é uma abordagem orientada ao negócio para a gestão das TI que considera o valor estratégico do negócio pela organização TI e a necessidade de disponibilizar uma elevada qualidade de serviço TI. A adoção de ITIL fornece, hoje em dia, documentação consistente e compreensiva de melhores práticas na gestão de serviços de TI. ITIL consiste num conjunto de livros que fornecem conselhos e orientação para obter qualidade dos serviços de TI e para acomodação e ambientação de necessidades para suportar as TI. Não só apresenta um modelo de como as atividades de gestão de serviços interagem umas com as outras, como também apresenta uma forma flexível de integrar e estruturar processos existentes.  Quando o projeto de ITIL foi criado pela CCTA, os seus objetivos iniciais na gestão de serviços de TI eram: a. Eficiência para reduzir os custos dos serviços de TI b. Eficácia para alinhar os serviços de TI com os objetivos do negócio c. Qualidade de serviço  A figura seguinte (retirada de “ITIL Best Practices: Maximizing the Business Value of it – Part II”, da Mercury) ilustra estes objetivos principais e mostra as soluções de tecnologia que estes objetivos exigem. Por sua vez, as soluções de tecnologia, ajudam a construir valor de negócio.  Figura 1 – Objetivos ITIL exigem requerimentos de negócio e de tecnologia  Na figura pode-se observar que, para obter eficiência das TI e reduzir os custos em longo prazo dos serviços de TI, é necessário melhorar o processo de execução. A automatização dos serviços de TI é necessária para este efeito pois a ocorrência de erros diminui e a eficiência das operações de TI aumenta. Para obter esta automatização é necessário efetuar a digitalização dos processos chave de TI.  A eficácia para alinhar os serviços de TI com os objetivos do negócio pode ser alcançada estreitando as relações entre a tecnologia e o negócio propriamente dito. Para este efeito, são necessárias ferramentas que relacionem as prioridades do negócio com os serviços de TI, ferramentas que conduzem os serviços de TI de acordo com o negócio. O último objetivo diz respeito à qualidade dos serviços de TI. Para que esta qualidade tome lugar, é necessário haver qualidade da aplicação, de desempenho e de disponibilidade. Neste sentido, é essencial adquirir uma abordagem contínua de gestão, desde o desenvolvimento da aplicação ao seu lançamento, passando pela gestão de mudança. Com estes objetivos pretendia-se desfrutar de todos os benefícios associados às práticas de ITIL que, segundo autores como Malcolm Fry, é a redução de custos, o aperfeiçoamento de serviços de TI através do uso de processos de melhores práticas, a melhoria da satisfação do cliente através de uma abordagem mais profissional ao serviço de disponibilidade, o acesso a guias e padrões, a melhoria da produtividade, a melhoria da utilização de capacidades e experiência, etc. Segundo a TechRepublic (site de redes CNET que fornece novidades e informação a profissionais de tecnologia), a estrutura ITIL é composta por três segmentos principais, embora o terceiro não esteja ligado à gestão de serviços de TI: segmento táctico, segmento operacional e outros. Os segmentos principais na gestão de serviços de TI abordam o conceito das melhores práticas na gestão de serviços. Estes segmentos estão divididos em dois conjuntos intitulados de Serviço de Suporte (operações do dia-a-dia e suporte de serviços de TI) e Serviço de Disponibilidade (planejamento em longo prazo e aperfeiçoamento de serviços de TI) e cada um engloba um conjunto de processos.  A figura seguinte (retirada de “The Adoption of ITIL in Large Enterprises”, da Tech Republic) ilustra a estrutura do processo ITIL:  Figura 2 – Estrutura do Processo ITIL  Existem muitos autores que consideram que cada um destes serviços tem apenas cinco processos: o serviço de suporte engloba a gestão de incidentes, a gestão de problemas, a gestão de configuração, a gestão de alteração e a gestão de lançamento; e o serviço de disponibilidade inclui processos como a gestão de capacidade, a gestão financeira, a gestão de disponibilidade, a gestão a nível de serviço e a gestão de continuidade. Contudo, neste artigo será considerada a figura apresentada acima que, segundo a Mercury (uma das maiores empresas de software no mundo, líder global em otimização de tecnologia de negócio), apresenta cada um destes serviços com mais um processo para além dos referidos: o serviço de suporte com o processo “service desk” e, o serviço de disponibilidade com o processo de gestão de relacionamento com o cliente.  4.1- ESTUDO DE CASOS DE SUCESSO DE APLICAÇÕES ITIL  a. Eaton - Atuando mundialmente e com 50 mil usuários de TI, Eaton investiu em ferramentas de comunicação IP e colaboração, além de criar uma área para estudar tecnologias descontinuadas. Para driblar a dispersão da companhia nos diversos países, o projeto de service desk batizado de “Follow the Sun” e regido sob os princípios de ITIL organizou o atendimento dos chamados por fuso horário. Assim, a solução de problemas ou dúvidas pode ocorrer desde qualquer parte do mundo: resolve aquele especialista que pegar o ticket primeiro. “Isto acelera muito o processo. A Eaton é global, então, temos de pensar em soluções que se enquadrem ao mundo todo”, justifica Miranda. São cerca de 50 mil usuários de TI. Sem adotar os preceitos da biblioteca (em especial os da disciplina de Gerenciamento de Incidentes) será que em algum momento seria possível criar e manter um serviço de suporte que ’seguisse o sol’? b. Fundação Bradesco - Outro ponto trabalhado entre 2007 e 2008 foi a implantação de escritórios de projetos, de processos e de estratégia, este último dividido em gestão do conhecimento e inteligência competitiva. Para este processo, está sendo buscada no mercado uma ferramenta de BPM e ainda a certificação de profissionais em ITIL 3.0. Pelo menos em tese o Banco se beneficia do conhecimento de processos dos profissionais em ITIL para suportar sua estratégia de inovação. Num mercado competitivo como o financeiro, inovação e processos alinhados são premissas básicas.  c. Tecban – Entidade Processa 30 milhões de transações por mês; inclusão de BI no sistema de faturamento ajuda os executivos a corrigir rotas diariamente. Mais maduro: é assim que o CIO da Tecban, Lisias Lauretti, define o atual estágio do departamento que comanda. Depois de adotar a arquitetura orientada a serviços, práticas como ITIL, conexões WiMAX e GPRS para caixas eletrônicos e SMS como ferramenta de campo para técnicos, neste ano, além de contabilizar os resultados do que implementou em 2007, a TI partiu para o amadurecimento das práticas de colaboração, o acompanhamento do faturamento em tempo real, entre outros. De fato, 30 milhões de transações por mês é um número bastante imponente, um SLA bem estruturado deve auxiliar a manutenção deste índice – fora isto não há como esperar algo diferente de uma instituição que precisa de processos maduros para a sustentação de seu negócio.  d. Makro - A rede de supermercados de atacado Makro implantou o ITIL para gerenciar seus processos de TI e resolveu de vez a questão de prioridade de atendimento aos seus usuários. “Às vezes demorava até dez horas para resolvermos um problema crítico, por exemplo, um PDV (caixa de ponto de venda) que deixava de funcionar e gerar receita, enquanto uma questão simples tinha prioridade simplesmente porque havia sido levada à TI por um vizinho de sala”, diz Marco Antonio Ferreira de Souza, diretor de TI do Makro no Brasil. “Hoje demoramos 30 minutos.” O Makro criou um quadro de regras de priorização de incidentes de TI e uma base de conhecimento documentada desses problemas, para que todo e qualquer um dos 35 funcionários da área de tecnologia possa agir e tomar a ação necessária. “Agora ninguém mais usa o ‘eu acho’. Há regras de prioridade, caracterização e grau do problema, quem deve ser chamado e o que deve ser feito”, diz Souza. A base de conhecimento construída pela área de TI do Makro possui cerca de 150 scripts, ou roteiros de procedimentos para resolução de incidentes e demandas – desde um usuário que esqueceu a senha cadastrada, até a queda de um link de dados que tira uma loja inteira do ar. Sem esse roteiro, se uma chamada para a TI entrar pelo caminho errado, a pessoa que a receber pode não perceber que é um problema crítico. E atrasos podem fazer a loja perder vendas ou irritar os clientes com grandes filas nos caixas que ainda funcionam.  4.2- BIBLIOTECAS ITIL DE SUPORTE A SERVIÇOS  Figura 3 – Service Desk.  A disciplina ITIL denominada Service Desk ou Service suporte é composta por 5 bibliotecas, são elas:  a. Incident Management (Gerenciamento de incidentes) – reduzir o tempo de indisponibilidade (downtime) dos serviços;  b. Problem Management (Gerenciamento de problemas) – minimizar o impacto no negócio dos incidentes e problemas causados pelos erros na infraestrutura de TI e prevenir incidentes recorrentes desses mesmos erros;  c. Configuration Management (Gerenciamento de configuração) – identificar e controlar os ativos de TI e itens de configuração (CIs) existentes na organização, estabelecendo o relacionamento dos mesmos aos serviços prestados;  d. Change Management (Gerenciamento de mudanças) – minimizar o impacto da mudança requerida para resolução do incidente ou problema, mantendo a qualidade dos serviços, bem como melhorar a operacionalização da infraestrutura;  e. Release Management (Gerenciamento de liberações) – prevenir a indisponibilidade do serviço, garantindo que as instalações de versões de hardware e software estejam seguras, autorizadas e devidamente testadas.  4.3- SLA e SLM  SLA - Um Acordo de Nível de Serviço (ANS ou SLA, do inglês Service Level Agreement) é a parte de contrato de serviços entre duas ou mais entidades no qual o nível da prestação de serviço é definido formalmente. Na prática, o termo é usado no contexto de tempo de entregas de um serviço ou de um desempenho específico. Um contrato do tipo SLA inclui informações sobre: a definição dos serviços, performance, gerenciamento de problemas, responsabilidade de ambas as partes, garantias, medidas emergenciais, planos alternativos, planos para soluções temporárias, relatórios de monitoramento, segurança, confidenciabilidade e cancelamento do contrato. Um acordo de nível de serviço pode incluir, entre outros termos, especificações para: a. Disponibilidade. Ex.: durante um ano, o sistema poderá ficar indisponível no máximo 8,7 horas (99,9% de disponibilidade). Este item poderá ser dividido entre paradas planejadas (para manutenções periódicas) e paradas não planejadas (erros, problemas, etc.). b. Incidência de erros. Ex.: durante um ano, o sistema não deverá registrar mais de 1 erro a cada 1.000.000 de operações processadas. c. Performance. Ex.: o sistema deverá processar a folha de pagamento em no máximo 2 segundos a cada 10 servidores processados. d. Prioridades. Ex.: solicitações classificadas como "urgentes" deverão ser resolvidas em até 8 horas, solicitações "importantes" serão resolvidas em até 24 horas, solicitações "rotineiras" serão resolvidas em até 72 horas. SLM - é o conjunto de processos associados ao estabelecimento, monitoramento e revisão dos Acordos de Nível de Serviços (Service Level Agreements - SLAs). 4.4- CONCEITOS SOX  A Lei Sarbanes-Oxley (em inglês, Sarbanes-Oxley Act) é uma lei estadunidense, assinada em 30 de julho de 2002 pelo senador Paul Sarbanes (Democrata de Maryland) e pelo deputado Michael Oxley (Republicano de Ohio). Motivada por escândalos financeiros coorporativos (dentre eles o da Enron, que acabou por afetar drasticamente a empresa de auditoria Arthur Andersen), essa lei foi redigida com o objetivo de evitar o esvaziamento dos investimentos financeiros e a fuga dos investidores causada pela aparente insegurança a respeito da governança adequada das empresas. A lei Sarbanes-Oxley, apelidada de Sarbox ou ainda de SOX, visa garantir a criação de mecanismos de auditoria e segurança confiáveis nas empresas, incluindo ainda regras para a criação de comitês encarregados de supervisionar suas atividades e operações, de modo a mitigar riscos aos negócios, evitar a ocorrência de fraudes ou assegurar que haja meios de identificá-las quando ocorrem, garantindo a transparência na gestão das empresas. Atualmente grandes empresas com operações financeiras no exterior seguem a lei Sarbanes-Oxley. A lei também afeta dezenas de empresas brasileiras que mantém ADRs (American Depositary Receipts) negociadas na NYSE, como a Petrobras, a GOL Linhas Aéreas, a Sabesp,a TAM Linhas Aéreas, a Brasil Telecom, Ultrapar (Ultragaz), a Companhia Brasileira de Distribuição (Grupo Pão de Açúcar), Banco Itaú e a Telemig Celular. Os Requisitos da lei são: a. Controlar a criação, edição e versionamento dos documentos em um ambiente de acordo com os padrões ISO, para controle de todos os documentos relativos à seção 404; b. Cadastrar os riscos associados aos processos de negócios e armazenar os desenhos de processo;  c. Utilizar ferramentas como editor de texto e planilha eletrônica para m criação e alteração dos documentos da seção 404; d. Publicar em múltiplos websites os conteúdos da seção 404; e.Gerenciar todos os documentos controlando seus períodos de retenção e distribuição; f. Digitalizar e armazenar todos os documentos que estejam em papel, ligados à seção 404. Seção 404 - Determina uma avaliação anual dos controles e procedimentos internos para emissão de relatórios financeiros. Além disso, o auditor independente da companhia deve emitir um relatório distinto, que ateste a asserção da administração sobre a eficácia dos controles internos e dos procedimentos executados para a emissão dos relatórios financeiros;  4.5- ANÁLISES, AÇÕES DE MITIGAÇÃO E QUALIDADE  De acordo com o case apresentado, as áreas da Software Developer que mais necessitam de reestruturação no modelo de trabalho são as de Suporte a Serviços de TI, Desenvolvimento e Segurabilidade de dados e documentos. Utilizando as bibliotecas de Suporte a Serviços da metodologia ITIL, a consultoria propõe certificar esses prestadores nas melhores práticas de gestão, operação e manutenção dos processos de TI. Resultado este que será estendido a todo o conjunto de módulos da Software Developer, como por exemplo à área de Desenvolvimento e Gestão da Qualidade.  4.6- TREINAMENTO E CERTIFICAÇÃO ITIL  Uma grande base de funcionários da área de atendimento do módulo de Suporte da Software Developer passará por treinamento específico em ITIL no 1º nível de estudo da metodologia, que possui três níveis: Figura 4 - Níveis de certificação na V2 (retirada do site Ti exames.com.br)  Eles serão encaminhados para treinamento e farão exames para a certificação ITIL V2 Foundation, que provê uma avaliação dos fundamentos no Gerenciamento de Serviços em TI. Ela ajudará a ter uma familiaridade com as melhores práticas para Gerenciamento de Serviços em TI da terminologia da ITIL. Outro grupo menor de funcionários também será encaminhado para treinamento de nível Foundation, porém após isso serão respectivamente encaminhados para treinamento em ITIL V2 Practitioner e ITIL Manager – que exigem certificação Foundation anterior. Nestes níveis de certificação eles deverão fazer um curso em instituições credenciadas pelo EXIN ou ISEB, e os testes serão aplicados pela mesma instituição. Os profissionais que compõem este grupo menor de funcionários, já mais experientes no negócio das empresas usuárias dos sistemas, serão promovidos a Supervisores de Suporte, e se ocuparão da manutenção do sistema de Suporte a Serviços reportando os resultados às esferas gerenciais da Software Developer.  4.7- MPLEMENTAÇÃO DO PROJETO DE SUPORTE A SERVIÇOS  A adoção de utilização de recursos tecnológicos como SmartPhones e suporte VoIP, facilita a identificação dos chamados em campo e homogeneíza o processo de identificação de incidentes, criando um catálogo único de índices de problemas para que estes possam ser resolvidos de maneira mais automatizada. Este cronograma de implementação será definido em 4 etapas:  a. Treinamento ITIL b. Migração dos serviços e bancos de dados, e de parametrização. c. Aquisição, Distribuição e Instrução dos SmartPhones. d. Homologação do novo sistema.  5- ANÁLISE DE INFRAESTRUTURA E SOFTWARE LIVRE  Atualmente a base de testes está hospedada em máquinas IBM AIX 5.2. Equipamento que deverá ser substituída por um de versão mais nova em agosto de 2011. As estações de trabalho dos desenvolvedores hoje são a SUN e estão operando em Solaris 10 atendendo perfeitamente à demanda da nova versão da plataforma de testes que deverá ser o AIX 7. Outra questão que está sendo demandada é a de formatação dos sistemas para versões que rodem em plataformas de software livre. E este tipo de função ainda não poderá ser disponibilizada devido ao sistema de patentes que foram adotados no desenvolvimento dos produtos pela Software Developer não permitirem Copyleft para garantir a integridade do tipo de negócio em que se aplicam.  6- ANÁLISE DE IMPACTOS E GESTÃO DE QUALIDADE  Os impactos da aplicação desses modelos podem ser sentidos em todas as esferas de uma organização estruturada neles. E atingem não somente os níveis de gestão operacional, mas também é sentido de forma bastante considerável na gestão financeira, pela economia de esforços com a minimização de duplicidades de trabalhos e processos automatizados. As ferramentas de SLM quando monitoradas garantem a gestão da qualidade por meio de ações pontuais que evitam a extensão dos incidentes aos níveis de sensibilidade do usuário. Também há impacto na política dos parceiros envolvidos que passam a enxergar a empresa como aliada na concepção de projetos e de atitudes profissionais.  7- CONCLUSÃO  Desta forma podemos concluir que o processo de reestruturação proposto pela empresa Consulting, que se baseia nas demandas dos clientes da Software Developer, passa por uma profissionalização dos mecanismos e formatos de trabalho por esta desenvolvidos. E que tem como pilar as melhores práticas da biblioteca ITIL, e outras ferramentas de gestão da tecnologia de informação como o Cobit e CMMI. Ainda pode-se observar que de acordo com o tipo de negócio que é resultado do trabalho da empresa Software Developer, a atenção e ocupação de supervisão constante e importantes ferramentas de medição dos serviços e da integridade dos documentos e operações realizadas por elas, por meio do SLM. Adotando modelos de trabalho que atendam as necessidades para certificações como o 5s e ISO, é possível à Software Developer garantir a manutenção e eficiência dos produtos e dos serviços prestados aos clientes.  8- REFERÊNCIAS BIBLIOGRÁFICAS WIKI {1}. Information Tecnology Infrastructure Libery . Disponível em http://pt.wikipedia.org/wiki/Information_Technology_Infrastructure_Library]. WIKI {2}. Lei Sarbanes-Oxley. Disponível em [http://pt.wikipedia.org/wiki/Sox].. WIKI {3}. CMMI. Disponível em [http://pt.wikipedia.org/wiki/Cmmi]. ITIL NA PRÁTICA {1}. Glossário de Termos, Definições e Acrônimos. Disponível em [http://www.itilnapratica.com.br/arquivos/ITILV3_Glossary_Brazilian_Portuguese_v3. 1.24.pdf]. OLIVEIRA, Alexander. Gerenciamento de Eventos e Monitoramento - Pró-Atividade gerando valor à equipe de Suporte a Serviços. Disponível em [http://www.mundoitil.com.br/2009/06/02/gerenciamento-de-eventos-emonitoramento-%e2%80%93-pro-atividade-gerando-valor-uma-equipe-de-suportea-servicos/]. PEREIRA, Leandro C. Makro acaba com o ‘Achismo’ em TI. Disponível em [http://www.mundoitil.com.br/2010/01/14/gracas-ao-itil-makro-acaba-com-oachismo/]. AURÉLIO, Marco. As 100+ inovadoras parcerias de sucessos em ITIL. Disponível em [http://www.mundoitil.com.br/2008/11/07/100-inovadoras-mais-itil-parceria-desucesso/]. TI EXAMES. ITIL V3. Disponível em [http://www.tiexames.com.br/ITIL_Certificacao.php#ITIL]. WEILL, Peter; ROSS, Jeanne W. Governança de Tecnologia da Informação. São Paulo: Makron, 2006.  CIO – UOL. Disponível em [http://cio.uol.com.br/]. IBM AIX. Disponível em [http://www.ibm.com/br/systems/power/software/aix/]..  http://www.tiexames.com.br/ITIL3_esquema_certificacao.php http://sistemas-humano-computacionais.wikidot.com/capitulo:sistemas-de-icthttp://www.thegoatblog.com.br/archives/cat_tecnologiainformao.html http://www.silviosouza.com/o-que-e-itil/ 9- GLOSSÁRIO  Figura 1 – Objetivos ITIL exigem requerimentos de negócio e de tecnologia..............................................................................................8 Figura 2 – Estrutura do Processo ITIL........................................................................................................9  Figura 3 – Service Desk.....................................................................................................10  Figura 4 - Níveis de certificação na V2..................................................13 UNIVERSIDADE PAULISTA CURSO SUPERIOR DE TECNOLOGIA GESTÃO EM TECNOLOGIA DA INFORMAÇÃO MARCOS OLIVEIRA MARTINS PIM VII PROJETO INTEGRADO MULTIDISCIPLINAR ESTUDO DA EMPRESA SOFTWARE DEVELOPER BELÉM – PARÁ 2014 MARCOS OLIVEIRA MARTINS PIM VII PROJETO INTEGRADO MULTIDISCIPLINAR ESTUDO DA EMPRESA SOFTWARE DEVELOPER Trabalho do Projeto Integrado Multidisciplinar – PIM VII e VIII, apresentado como exigência para conclusão do 4º Semestre do Curso Superior de Tecnologia Gestão em Tecnologia da Informação, da Universidade Paulista – UNIP, campus Entroncamento. Monitora: LUANE BARRAL BELÉM - PARÁ 2014 RESUMO  Este trabalho discorre sobre o planejamento para a implantação da melhoria de processos aplicada em empresas de desenvolvimento de software sem um processo organizacional definido. O ponto central da pesquisa está inserido no contexto da gerência de projetos, especificamente no planejamento, e é alicerçada nos princípios do Guia de Conhecimentos em Gerenciamento de Projetos (PMBOK) do Instituto de Gerenciamento de Projetos (PMI) dos Estados Unidos. Um esforço maior se concentrará na investigação e no planejamento para aplicação da melhoria de processos de software baseada nas melhores práticas sugeridas pelo Capability Maturity Model Integration for Development, nível 2 de maturidade (CMMI-DEV L2) criado sob encomenda pelo Instituto de Engenharia de Software (SEI), da Universidade Carnegie Mellon, dos EUA. O processo para a implantação do CMMI-DEV é baseado no trabalho de Kulpa e Johnson (2008) em um cenário fictício que reflete a realidade de muitas empresas brasileiras. É enfatizada a atenção aos problemas decorrentes do impacto da mudança de cultura organizacional, da falta de visibilidade ou da má expectativa dos envolvidos, da má gestão técnica em gerenciamento de projetos de software, da inexistência da garantia da qualidade, dentre outros problemas.  Palavras-chave: planejamento, projeto, processo, CMMI-DEV, PMBOK ABSTRACT  This work discusses the planning for the deployment of process improvement applied in software development companies without a defined organizational process. The central point of research is inserted in the context of project management, specifically in planning, and based on the principles Guide of the Project Management Body of Knowledge (PMBOK) of Project Management Institute (PMI) of USA. A greater effort will focus on research and planning for implementation of software process improvement based on best practices suggested by the Capability Maturity Model Integration for Development, level 2 of maturity (CMMI-DEV L2) custom created by the Software Engineering Institute (SEI) of Carnegie Mellon University, U.S. The process to implement the CMMI-DEV based on work by Kulpa and Johnson (2008) in a fictional scenario reflects the reality of many Brazilian companies. Is emphasized attention to problems arising from the impact in changing organizational culture, lack of visibility or poor expectation of those stakeholders, mismanagement technical project management software, the lack of quality assurance, among other problems.   Keywords: planning, design, process, CMMI-DEV, PMBOK.  Sumário 1-Introdução 23 2- CMMI 24 3- Plano de Gerenciamento do Projeto 25 4- Requisitos do Projeto 25 5- Plano de gerenciamento dos requisitos 25 6-Aceitação dos Requisitos do Projeto 25 7- Matrizes de Rastreabilidade 26 8-Plano de Qualidade e Métricas de Qualidade 26 9- Plano de gerenciamento dos riscos 27 10- Planilha de riscos 27 11-Organograma do Projeto 27 12-Funções e Responsabilidades 27 13- Consultoria 28 Definições de Probabilidade e Impacto dos Riscos 28 14- Matriz de probabilidade e impacto 28 15- Controle de versão de software com o CVS 28 16- A qualidade de software e o mercado 28 17- PDCA 29 18-Conceito do portifolio de TI 29 19-Proposta de melhoria da Consulting para a Software Developer 30 20-Help Desk 30 21- Plano de negócio 31 22-A evolução do empreendedorismo 31 23- As quatro ondas da tecnologia. 32 24- Inovação e criatividade 32 25- Conclusão 33 26-Referências Bibliográficas 34 1-Introdução  Esta pesquisa pretende mostrar que um projeto para a implantação da melhoria de processos de desenvolvimento de software, através de um planejamento realizado de acordo com o Guia de Conhecimentos para Gerenciamento de Projetos (PMBOK) e concepções apresentadas para o processo de implantação do CMMI-DEV, conforme a metodologia apresentada por Kulpa e Johnson (2008), é uma tarefa que exige conhecimento sobre a abordagem adotada, comprometimento, envolvimento e disponibilidade das pessoas envolvidas no projeto, principalmente daqueles que o coordenam. São exigidas destas pessoas, habilidades para motivar, treinar, orientar, sugerir técnicas e procedimentos etc., bem como analisar os desvios que implicam na não aderência de um processo às metas e práticas impostas pelo CMMI-DEV. O CMMI-DEV é um modelo de referência que fornece direcionamento para as práticas a serem seguidas em um processo de desenvolvimento de software.  O principal objetivo foi realizar um planejamento para a construção de um processo consistente e maduro baseado nas metas e práticas do CMMIDEV nível 2, utilizando as recomendações do PMBOK, focando-se na mitigação dos riscos do projeto, no cumprimento dos prazos e no alcance da qualidade dos serviços a serem executados. Com isto, foi realizada a criação de um estudo de caso baseado em um cenário típico de processo ad hoc de trabalho e nos problemas inerentes de uma empresa fictícia que se encontra no nível caótico de maturidade em processo de desenvolvimento de software e que pretende obter a certificação CMMI-DEV nível 2. Este trabalho objetivou também realizar a identificação de riscos do projeto e um planejamento para sua mitigação ou contingenciamento; a realização de estimativas de custos e de esforço para execução do projeto; a determinação de critérios para o sucesso do projeto; a especificação de recursos necessários para as atividades do projeto; a criação e definição de demais produtos de trabalho que possam facilitar o planejamento e o controle do projeto etc.  2- CMMI O projeto de implantação do CMMI-DEV é realizado com base na representação estagiada, no nível 2 de maturidade, e visa estabelecer a execução de práticas inerentes às áreas de processos abaixo:  Gestão de Requisitos (REQM), aonde estabelece práticas para gerenciamento das mudanças nos requisitos que poderão ocorrer em qualquer ponto de execução em um processo de desenvolvimento de software;   Planejamento de Projeto (PP), que objetiva orientar os gerentes de projeto, ou papéis equivalentes, no planejamento para o esforço, custo, orçamento, recursos, riscos, qualidade etc., para um projeto de desenvolvimento de software;   Monitoramento e Controle de Projeto (PMC), que proporciona “um entendimento do progresso do projeto, de forma que ações corretivas apropriadas possam ser tomadas quando o desempenho do projeto desviar significativamente do plano” (SOFTWARE ENGINEERING INSTITUTE, 2006);   Gestão de Acordo com os Fornecedores (SAM), tem o propósito de gerenciar as aquisições realizadas para o projeto;   Medição e Análise (MA), que provê técnicas e ferramentas necessárias para obtenção de informações relevantes para o projeto, baseando-se em medições;   Garantia da Qualidade de Processo e de Produto (PPQA), que estabelece práticas necessárias de forma a garantir que os procedimentos estabelecidos para o processo estão sendo executados e que o produto é aderente aos padrões institucionalizados de qualidade;   Gestão de Configuração (CM), que estabelece e mantém “a integridade dos produtos de trabalho, utilizando identificação, controle, balanço e auditorias de configuração” (SOFTWARE ENGINEERING INSTITUTE, 2006).  Processo de Implantação de Kulpa e Johnson Uma implantação de sucesso deve ser realizado sob um bom planejamento utilizando um processo aplicável e provado. Kulpa e Johnson, em Interpreting the CMMI, a Process Improvement Approach, sugerem um ótimo processo para implantação do CMMI dividido em quatro fases básicas:  1. Set Up – que estabelece o grupo para melhoria de processos e uma infraestrutura organizacional, incluindo o estabelecimento da linha de base do processo, um planejamento inicial e o estabelecimento do envolvimento e do comprometimento da organização; 2. Design – que define as políticas e os procedimentos, a identificação e a definição dos padrões e dos processos; 3. Pilot – que realiza o treinamento dos participantes e o teste dos procedimentos em poucas áreas. Os procedimentos são atualizados, quando necessário, baseado nos resultados dos pilotos; 4. Implement – são executados os procedimentos em todos os projetos e a sua efetividade é medida.  3- Plano de Gerenciamento do Projeto O plano de gerenciamento do projeto detém informações sobre a definição, coordenação e integração de todos os outros planos auxiliares. Resumidamente reúne informações sobre a visão geral, finalidade, objetivo e escopo do projeto, bem como é realizado o planejamento para gerenciamento dos requisitos, do cronograma, dos riscos, dos recursos, da qualidade etc. Para este projeto, algumas informações relevantes sobre gerenciamento foram dispostas em artefatos separados. São eles: Plano de gerenciamento de requisitos; Plano de qualidade; Plano de recursos humanos; Plano de gerenciamento dos riscos.  Outras informações relevantes estão no próprio plano de gerenciamento do projeto. Observações relevantes adicionais sobre os produtos de trabalho gerados para o planejamento deste projeto serão descritos nas próximas seções.  4- Requisitos do Projeto De acordo com Kim Heldman, os requisitos funcionais de projetos que não estão relacionados com a execução do desenvolvimento de software em si, poderiam descrever especificações (HELDMAN, 2009, p. 106). Desta forma, os requisitos funcionais para o projeto especificam os objetivos a serem alcançados por cada entregável, metas e práticas específicas definidas em cada área de processo do CMMI-DEV nível 2. Estes requisitos não definem como as ações deverão ser realizadas, mas quais os objetivos deverão ser atingidos.  5- Plano de gerenciamento dos requisitos A finalidade do plano de gerenciamento de requisitos é documentar como os requisitos serão analisados, documentados e gerenciados do início ao fim do projeto. É descrito no documento que o levantamento dos requisitos baseia-se na análise das metas e práticas sugeridas pelo CMMI-DEV nível 2 de maturidade e que todas as mudanças no projeto serão aceitas levando-se em consideração os resultados das avaliações de riscos, impacto e viabilidade técnica, orçamentária, de esforço e de atendimento aos prazos. Será confirmada após a aceitação formal no documento de aceitação de requisitos. Foi definida também um prazo para resposta a aceitação dos requisitos e de suas mudanças, visando contingenciar riscos inerentes a baixa velocidade de resposta das partes interessadas e estabelecer a agilidade do andamento do projeto.  6-Aceitação dos Requisitos do Projeto A aceitação dos requisitos iniciais do projeto será evidenciada em uma planilha simples, aonde as partes interessadas poderão validar a completude, a clareza e o entendimento de suas necessidades. Para o gerenciamento das mudanças, este mesmo documento poderá ser utilizado, bastando evidenciar no campo referente às observações que o requisito é de mudança de escopo. As aceitações só poderão ser firmadas pelas partes interessadas constantes na planilha que descreve as partes interessadas do projeto.  7- Matrizes de Rastreabilidade A abordagem adotada para a rastreabilidade neste é definida como um mecanismo que facilite identificar quais são os itens que possuem vinculo com outros itens cujas mudanças poderão influenciar um no outro. Inicialmente, a rastreabilidade será mantida entre os requisitos funcionais e não funcionais.  Linha de base de desempenho dos custos A linha de base de desempenho dos custos é “o custo total esperado para o projeto ao utilizar um orçamento no cálculo no término” (HELDMAN, 2009, p. 206). Possui informações referente a linha de base de desempenho dos custos e os requisitos de financiamento. Este descreve a necessidade do financiamento ao longo do projeto. Aquele descreve a acumulação dos custos ao longo do tempo do projeto. 8-Plano de Qualidade e Métricas de Qualidade Este documento especifica como serão realizadas as atividades de gestão da qualidade e sugere, inicialmente, necessidades de informação para as medições a serem realizadas.  A garantia da qualidade do processo envolve a responsabilização da coordenação e do campeão do projeto na supervisão e na auditoria dos procedimentos, bem como em assegurar que o andamento do projeto é aderente aos padrões de qualidade impostos para o projeto.   As métricas do projeto são inicialmente sugeridas no documento, necessitando determinar quais são as informações que deverão ser analisadas e medidas durante a execução do projeto.  Modelo de Informação para Medição. Uma ótima abordagem para medição da melhoria de processos foi definido por Statz (2005) e define quatro dimensões:  Custo de Desempenho: custo para desenvolver e providenciar um produto ou serviço, baseado nas atividades que são executadas de acordo com o plano.   Custo de Prevenção: custo para estabelecer e manter processos e treinamentos para execução do trabalho.   Custo de Avaliação: custo para revisão dos produtos e serviços sob desenvolvimento, estar certo de que os requisitos serão aceitos e que haja conformidade com o processo.   Custo de Não Conformidade (Retrabalho): custo incorrido para lidar com defeitos no produto ou serviço, incluindo retrabalho no desenvolvimento do produto, reteste, revisões etc, bem como o custo de suporte ao cliente, pagamento de penalidades ou multas e outros custos associados aos efeitos dos defeitos.  Plano de recursos humanos: O plano de recursos humanos documenta as funções e  responsabilidades dos indivíduos e grupos envolvidos nos diversos elementos do projeto, em nível de papéis, autoridade e competência. Também define o organograma de acordo com os papéis e responsabilidades definidos para o projeto.  9- Plano de gerenciamento dos riscos O plano de gerenciamento dos riscos do projeto especifica como os riscos foram definidos, como serão monitorados e controlados ao longo do projeto. Define também a estrutura analítica dos riscos (EAR) e as definições adotadas de probabilidade e impacto dos riscos, bem como a matriz de probabilidade e impacto dos riscos.  10- Planilha de riscos A planilha de riscos para este projeto constitui-se um dos artefatos mais importantes, pois ele documenta a identificação dos riscos que influenciarão positiva e negativamente o projeto. Cada risco identificado é categorizado de acordo com o que foi definido no EAR do projeto, bem como são descritos informações sobre as possíveis causas, probabilidade de ocorrência numa escala de 0,05 a 0,8 (0,5% a 80%), impacto, grau de risco, conforme definido na matriz de probabilidade e impacto, proprietário do risco e o plano de resposta aos riscos.  Os riscos identificados para o projeto que possuem maior grau são a indisponibilidade de pessoal por causa de suas alocações a outros projetos ou mesmo o baixo interesse ou descomprometimento dos gerentes das unidades para a realização das atividades do projeto de melhoria. As ações sugeridas incorrem na realização de reuniões de conscientização que a melhoria trará para as atividades laborais dos recursos técnicos e gerenciais, bem como na melhoria do produto. 11-Organograma do Projeto Esta seção faz referência ao organograma do projeto, de acordo com os papéis e responsabilidades definidos neste plano.  12-Funções e Responsabilidades A equipe responsável pela administração dos riscos identificados e respectivas respostas são definidos abaixo:  Coordenador do projeto Realizar o levantamento e o acompanhamento dos riscos do projeto; Executar as estratégias definidas na planilha de riscos; Fornecer feedback para a alta gerência. Campeão   Apoiar a coordenação do projeto na execução das suas tarefas;  Resolver conflitos; Gerenciar expectativas da presidência e demais diretorias;   Avaliar desempenho das atividades.  13- Consultoria   Direcionar, avaliar e acompanhar atividades da coordenação do projeto e demais membros do worktime;  Categoria de Riscos Esta seção documenta as categorias de riscos que agregarão os riscos identificados de maneira sistemática.  Definições de Probabilidade e Impacto dos Risco A probabilidade define a chance de um evento ocorrer. Para este projeto definem-se quatro níveis de probabilidade: 0,8 – 80% de probabilidade que o evento ocorra; 0,6 – 60% de probabilidade que o evento ocorra; 0,4 – 40% de probabilidade que o evento ocorra; 0,2 – 20% de probabilidade que o evento ocorra;  O impacto é a quantidade de ganhos ou danos que um evento de risco representa para o projeto. Desta forma, a escala de impacto de riscos é determinada abaixo com base nos objetivos custos, tempo e qualidade:  14- Matriz de probabilidade e impacto A matriz de probabilidade e impacto define uma pontuação total dos riscos para o projeto. Os riscos que foram identificados e que possuem um alto valor de impacto merecem maior atenção para execução do plano de resposta. Os valores de impacto definidos na tabela abaixo serão utilizadas durante a análise dos riscos.  15- Controle de versão de software com o CVS A qualidade de software é um dos assuntos mais atuais em discussão na comunidade de Engenharia de Software. Embora os primeiros esforços mais amplos no sentido de se produzir software com maior qualidade e produtividade datem da década de 70, foi na segunda metade da década de 90 que uma série de novos conceitos e suas abordagens alcançaram maturidade e visibilidade. Neste contexto, destacam-se os modelos de qualidade de processo de software, entre os quais o SEI-CMM é o mais conhecido e utilizado, e as novas técnicas de desenvolvimento de software, tais como RAD (Rapid Application Development) e as orientadas a objetos. Assim sendo, um dos maiores desafios das organizações de software hoje é justamente aplicar em seus processos de desenvolvimento tanto os novos conceitos de engenharia de software quanto às práticas de qualidade preconizadas pelo CMM e outros modelos.  16- A qualidade de software e o mercado Desenvolver software de qualidade não é mais um requinte para poucos: transformou-se num fator de competitividade num mercado cada vez mais exigente. O filósofo Nietzsche, no século passado, alertava: "Com o aumento da competição, a qualidade se torna mera propaganda. Vence aquele que melhor engana". Essa receita é muito simples e fácil de seguir, todavia, quem tomar esse tipo de postura estará fadado ao fracasso. Nos dias de hoje, a qualidade tornou-se requisito imprescindível para garantir a sobrevida de um software no mercado. Portanto, neste contexto, podemos concluir que as empresas mais competitivas são as empresas que trabalham sob a ótica da melhoria contínua dos processos para aumentar a qualidade do processo de desenvolvimento e, conseqüentemente, aumentar a qualidade do produto final. Estima-se que o custo decorrente da correção de um bug cresce dramaticamente na medida em que ele é descoberto em fases mais adiantadas no processo de desenvolvimento de software. No entanto, ainda existe uma forte tendência nas empresas em negligenciar essa realidade e não dedicar o tempo mínimo necessário para a realização das atividades de qualidade e testes de software. Em contrapartida a esse cenário pouco promissor, o novo mantra da indústria é "Faça a coisa certa na primeira tentativa". Gigantes como a Microsoft, por exemplo, já se deram conta de que os consumidores já não confiam tanto nos seus produtos. O grande desafio dessas empresas é criar produtos tão confiáveis quanto os sistemas de distribuição de eletricidade, gás e telefone. Segundo artigos em sites especializados, a tônica dessa estratégia da Microsoft será a consolidação dos componentes fundamentais dos seus aplicativos. Apesar do ceticismo dos especialistas em TI, a Microsoft, em janeiro de 2006, admitira um possível atraso no lançamento do seu sistema operacional chamado Windows Vista. Conforme a declaração da empresa, o sistema operacional só seria lançado se atingisse as expectativas de qualidade. Discussões à parte, devemos admitir que essa é uma atitude madura de uma empresa que quer se manter no mercado.  17- PDCA O PDCA é aplicado para se atingir resultados dentro de um sistema de gestão e pode ser utilizado em qualquer empresa de forma a garantir o sucesso nos negócios, independentemente da área de atuação da empresa. O ciclo começa pelo planejamento, em seguida a ação ou conjunto de ações planejadas são executadas, checa-se se o que foi feito estava de acordo com o planejado, constantemente e repetidamente (ciclicamente), e toma-se uma ação para eliminar ou ao menos mitigar defeitos no produto ou na execução.  Os passos são os seguintes: Plan (planejamento): estabelecer uma meta ou identificar o problema (um problema tem o sentido daquilo que impede o alcance dos resultados esperados, ou seja, o alcance da meta); analisar o fenômeno (analisar os dados relacionados ao problema); analisar o processo (descobrir as causas fundamentais dos problemas) e elaborar um plano de ação. Do (execução): realizar, executar as atividades conforme o plano de ação. Check (verificação): monitorar e avaliar periodicamente os resultados, avaliar processos e resultados, confrontando-os com o planejado, objetivos, especificações vista. Act (ação): Agir de acordo com o avaliado e de acordo com os relatórios, eventualmente determinar e confeccionar novos planos de ação, de forma a melhorar a qualidade, eficiência e eficácia, aprimorando a execução e corrigindo eventuais falhas. e estado desejado, consolidando as informações, eventualmente confeccionando relatórios. Atualizar ou implantar a gestão à Ciclo PDCA e as metas Há dois tipos de metas:  · Metas para manter; · Metas para melhorar;  Metas para manter Exemplos de metas para manter: Atender ao telefone sempre antes do terceiro sinal. Estas metas podem também ser chamadas de "metas padrão". Teríamos, então, qualidade padrão, custo padrão, prazo padrão, etc.  O plano para se atingir a meta padrão é o Procedimento operacional Padrão (POP). O conjunto de procedimentos operacionais padrão é o próprio planejamento operacional da empresa.  18-Conceito do portifolio de TI A Sarbanes-Oxley é uma lei que visa proteger investidores do mercado de fraudes contábeis e financeiras de companhias de capital aberto, assim como instituir uma série de penalidades contra crimes relacionados. Já o Acordo Basiléia II atinge instituições financeiras em geral, estabelecida pelo BIS (Bank for International Settlements) que estipula requisitos de capital mínimos, em função dos seus riscos de crédito e operacionais.  Ambas regulamentações têm forte impacto na área de TI e fazem parte do modelo de Governança de TI. Seu atendimento está nos requisitos de diversos projetos que fazem parte do portfolio de TI e que vão criar restrições às operações de serviços de TI.  Fazem parte do portfolio de TI, soluções estratégicas, projetos de aplicativos ou soluções, projetos de manutenção de ativos ou projetos de processos, organização e serviços. A definição sobre o que manter e sobre em que investir vai depender dos mecanismos de decisão corporativos, como por exemplo, um Comitê de Projetos com a participação de usuários e executivos das demais áreas da empresa.  O portfolio de TI deve direcionar o relacionamento com os clientes (internos e externos), assim como com os fornecedores e parceiros de TI. Demandas que não estiverem enquadradas no portfolio não devem ser atendidas, pois o mesmo está constantemente alinhado com os objetivos e estratégias do negócio  19-Proposta de melhoria da Consulting para a Software Developer O objetivo do desenvolvimento desta ferramenta é garantir que para um determinado risco existente os critérios dos processos de negócio sejam examinados, mesmo que para esse risco estejam envolvidos fatores de tecnologia, processos ou pessoas.  Através dos dados informados ao sistema, o mesmo retorna todo um conhecimento corporativo de excelente qualidade, de modo a minimizar imprevistos custosos, oferecendo desta forma uma visão privilegiada da estrutura organizacional como um todo, ou seja, gerenciamento de risco (preocupação gerencial) x controles (capacidade gerencial). Entretanto os dados informados ao sistema devem ser de caráter confiável para a sua perfeita utilização, pois todo o processamento, ou seja, todas as funcionalidades serão executadas a partir desses dados. Através do sistema, também será possível analisar á área operacional da empresa mitigando assim possíveis riscos operacionais funcionais.  20-Help Desk Para resolver o problema de ticket a Consulting sugere a implantação de um Helpdesk “GLPI”.  GLPI (parc informatique gestionnaire livre) é uma ferramenta web de software livre (licença GPL) que oferece gerenciamento completo do inventário do computador da empresa, bem como, incluindo um sistema de gerenciamento de incidentes (ticketing / helpdesk). A ferramenta foi desenvolvida para ambientes de Apache, PHP, MySQL , então ele pode ser instalado em ambos os servidores windows e linux e de fácil instalação e de gestão para gerir todo o suporte e manutenção de uma empresa de forma rápida e simples, assim implantação e execução são relativamente pequenas.  Esta dupla função de gestão de inventário (computadores, servidores, periféricos, licenciamento de software da topologia da rede, etc) e helpdesk para monitorar as intervenções, permite que os administradores e pessoal de apoio, a ligação intervenções para usuários e computadores, criando assim um histórico completo de manutenção realizadas. Abrindo um Ticket: Através de uma URL o usuário irá logar no Helpdesk e ira preencher os campos: Título: Descreva o problema ou incidentes: Clicar em no botão “Enviar  Gerenciamento de Documentos A possibilidade de controlar e gerenciar documentos torna-se hoje uma necessidade estratégica para a competitividade. Capturar, gerenciar, processar, armazenar, e distribuir documentos eficientemente possibilita às empresas tornarem os seus negócios aptos às rápidas mudanças de mercado, aos mesmo tempo que aumenta a produtividade e reduz custos. Sistemas ECM (Enterprise Content Management) oferecem os recursos necessários ao gerenciamento do ciclo de vida de um documento num ambiente colaborativo, em que profissionais distribuídos por espaços físicos distintos participam do processo de criação de forma organizada. A duração do ciclo de vida de um documento, bem como cada estágio, depende muito do tipo de documento, dos processos de negócios, dos padrões da indústria, e até mesmo do caráter legal. Portanto, o correto entendimento do ciclo de vida e dos padrões de documentação em uma empresa são fatores críticos para se determinar os requisitos de um sistema de ECM.  Quando se analisa sistemas ECM, alguns aspectos técnicos importantes devem ser cuidadosamente avaliados: Gerenciamento: O sistema ECM deve ser capaz de gerenciar qualquer formato eletrônico, incluindo diferentes formatos de imagens, textos, documentos compostos, arquivos eletrônicos, áudio digital, vídeos etc. Armazenamento: Um sistema ECM deve suportar, idealmente, tanto o arquivamento off-line, quanto o on-line, em diferentes mídias de armazenamento, desde mídias digitais como discos ópticos, CD-ROM, discos magnéticos, fitas, até mídias tradicionais como microfilme e papel. O sistema deve gerenciar de forma segura o uso da mídia para o armazenamento do documento, migrar documentos entre mídias quando definido pelo ciclo de vida, e fazer uso de cache para acelerar a recuperação dos documentos mais utilizados; Recuperação: O sistema deve permitir que os documentos armazenados sejam recuperados a partir de um conjunto de atributos previamente definidos (metadados), mas também deve suportar a recuperação através de palavras e frases contidos nos documentos. A pesquisa deve ser realizada de forma unificada, de modo que os documentos sejam acessados, recuperados, e visualizados independente do local de armazenamento; Intercâmbio: Visando o intercâmbio de documentos entre a empresa e entidades sem acesso ao sistema ECM, o mesmo deve permitir o acesso a aplicações de terceiros, permitindo que os documentos sejam extraídos em seu formato nativo, e transportados como desejado; Internet: Todas as funcionalidades de um sistema ECM, devem estar disponíveis via Web.  21- Plano de negócio  O índice de mortalidade no primeiro ano de vida de micro e pequenas empresas brasileiras é ao redor de 70%, as causas das mortalidades precoces ocorrem por falta de planejamento, em primeiro lugar, Denotando falta de habilidade na gestão, além disso, outros fatores também são relevantes, como insuficiência de políticas de apoio, conjunturas econômicas e problemas pessoais.  Para possibilitar uma análise mais detalhada dos Produtos e Serviços da empresa, utilizamos a análise SWOT (strength, weaknesses, oportunities and trends), que verifica as forças e fraquezas no ambiente interno e oportunidades e riscos no ambiente externo da empresa.  22-A evolução do empreendedorismo A evolução do empreendedorismo consistente passou a ser mais que um dom pessoal, para ser uma atividade com recursos acadêmicos, com estudo de casos de referência e extremo profissionalismo. Também se faz necessário manter a indispensável pessoalidade para o sucesso de qualquer negócio, entretanto, aumentou a obrigatoriedade da observação de etapas e processos. A cada instante o mercado exige muito mais dos empreendedores. O conceito de „estar empreendedor‟ dá lugar ao „ser empreendedor‟ fazendo alusão de que não se pode parar de empreender, convertendo-se numa atitude essencial. Baseado nesse conceito, o empreendedor atual deve ampliar a competitividade em contraponto à velocidade da comunicação, recursos padronizados e insumos com forte pressão para redução de recurso. 23- As quatro ondas da tecnologia  1ª onda: tecnologia prometida – estimular o consumo.  2ª onda: tecnologia necessária – transformar o conhecimento em capital intelectual, motivando a competitividade e o futuro. 3ª onda: tecnologia de resultados – tratamento dos dados, transformando a informação em conhecimento, evoluindo de inteligência em estratégia. 4ª onda: tecnologia responsável – Preservação da vida, da paz e do meio ambiente através do conhecimento e do uso da inteligência para o entendimento do relacionamento humano e usar o estreitamento de relacionamento humano como estratégia de atuação. A tecnologia disponibiliza mecanismos que possibilitam a operação e a análise crítica em qualquer momento e lugar 24- Inovação e criatividade  As empresas precisam apresentar um diferencial, precisam diariamente responder à pergunta crucial: por que você compra meu produto ou serviço e não o do meu concorrente? Qualquer empresa que deseje o sucesso precisa de um processo produtivo inovador.  Por meio de uma análise da evolução histórica das organizações, percebe-se que uma das primeiras medidas para melhoria de competitividade dos processos produtivos foi a redução de custos para a otimização do preço final. Essa prática trouxe perda de qualidade e à diversidade de oferta do mercado uma nova reflexão: a saída seria a redução de custos e investimentos em qualidade. Nessa instância, os gurus da qualidade implantaram a ISO 9000 e outras normas similares para melhorar a eficácia e eficiência dos processos, resultando em confiabilidade para o consumidor final. Para que haja a possibilidade de um clima organizacional voltado para a inovação, será fundamental que a organização desenvolva uma cultura voltada para o desenvolvimento de lideranças, competências e relacionamento interpessoal. São valores básicos para a inovação o respeito, a confiança, a inclusão, a sinergia e o comprometimento.  25- Conclusão  De acordo com o planejamento realizado, verificou-se que um planejamento de um projeto de melhoria de processos de desenvolvimento de software baseado nas práticas do CMMI-DEV utilizando as recomendações do Guia PMBOK é interessante sob o aspecto orientado ao controle efetivo dos requisitos e sobre o que deverá ser realizado. As técnicas e ferramentas sugeridas facilitam o planejamento assertivo e conclusivo, apesar de demandar um esforço considerável. Um Sistema de Gerenciamento de Riscos Corporativos vem só a somar às estratégias da empresa, gerando assim uma visão bem mais aguçada da própria estrutura organizacional em si, possibilitando um maior domínio de todas as atividades e incertezas pertencentes aos processos de negócios da organização. A complexidade do mercado aumenta dia a dia e os negócios dependem cada vez mais desses sistemas. Daí a necessidade de melhores práticas e processos para eliminar lacunas e reduzir o risco operacional.  Através dos estudos e pesquisas elaborados neste projeto, podemos concluir que a aplicação de um sistema de gerenciamento de riscos corporativos gera diversos pontos positivos, o serviço de helpdesk melhora o atendimento nos chamados, o Gerenciamento de Documentos resolve os problemas de criação, alteração e controle de versões dos documentos, o PDCA tornar mais claros e ágeis os processos envolvidos na execução da gestão.  26-Referências Bibliográficas ALMEIDA, J. A., et al. Visão geral do método de avaliação padrão CMMI para melhoria de processos, SCAMPI, v. 1.1.  HELDMAN, K. Gerência de Projetos: guia para o exame oficial PMI  KULPA, M. K.; JOHNSON, H. A. Interpreting the CMMI: a process improvement approach. 2nd ed. Flórida, EUA:  PESSOA, M. S. P. Introdução ao CMMI, Modelo Integrado de Maturidade e Capacidade de Processos: o novo modelo que substitui o SW-CMM CAETANO, Cristiano. Processos e qualidade de software  WIKIPEDIA. Qualidade de Software. Apostila 4º Semestre TI - UNIP