PIMVII E VIII TI

UNIVERSIDADE PAULISTA

CURSO SUPERIOR DE TECNOLOGIA

GESTÃO EM TECNOLOGIA DA INFORMAÇÃO

LINDALVA DE SOUZA LIMA

PIM VII

PROJETO INTEGRADO MULTIDISCIPLINAR

GESTÃO DE TI DO SOFTWARE DEVELOPER

Belém – Pará

2014

LINDALVA DE SOUZA LIMA

PIM VII

PROJETO INTEGRADO MULTIDISCIPLINAR

GESTÃO DE TI DO 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: NATÁLIA MORAES

Belém - Pará

2014

Resumo

Muitos ainda rotulam a Governança como mais um dos jargões da TI, entretanto, alinhar e integrar com o negócio, junto com as melhores práticas e metodologias transformou a Governança de TI em uma das melhores ferramentas para mostrar o real valor da TI. Antes de qualquer coisa, mudar a cultura de uma empresa é um trabalho árduo, nada fácil, considerando-se que toda mudança há resistências e há de se lembrar de que muitas barreiras deverão ser quebradas. A mudança deve obrigatoriamente vir de cima para baixo para ter um impacto mais rápido, mas nada impede que o processo tenha início de baixo para cima com pequenas mudanças, assim como plantar algumas sementes de frutos em um milharal. No início talvez pelo fato do terreno não estar preparado para um determinado cultivo muitas sementes não terão o desenvolvimento adequado, mas se prepararmos o solo as mudanças virão com certeza mesmo que a médio/longo prazo. Preparar aqui é definir o que se quer mudar e qual objetivo. Celebrar objetivos alcançados, também está em conformidade com o COBIT, refletir sobre o quanto é importante esta celebração e o quanto, no mundo Corporativo, alguns gestores já colocaram seus colaboradores para correr uma corrida atrás da outra e lutar na sequência após um belo nocaute! Independente da complexidade ou não das atividades o importante é alcança-los, mas nunca devemos esquecer-nos das pessoas. E um ponto importante é que, com as celebrações o fato fica marcado e dá motivos para novas ações, já que as atividades, processos, ferramentas e projetos são movidos por pessoas. Ao celebrarmos as vitórias, já estamos caminhando para a conformidade com o Objetivo de Controle PO7 do COBIT, Governança de TI e pelo CMMI, SOX e ITL, gerenciar Recursos Humanos que tem em sua definição: “Adquirir, manter e motivar mão-de-obra competente para criação e entrega de serviços de TI para o negócio. Isto é alcançado seguindo práticas definidas e combinadas que suportam recrutar, treinar, avaliar desempenho, promover e terminar. Este processo é crítico, pois as pessoas são recursos importantes, e a governança e ambiente de controle interno são fortemente dependentes em motivação e competência do pessoal”. Ou seja, o simples fato de desenvolver um plano de ação para este objetivo de controle faz com que estejamos aumentando o índice de conformidade com os motivos que levam as organizações, parcial ou totalmente, suas diferentes atividades e serviços na área de Tecnologia da Informação, sendo muitos deles associados à redução de custos, melhoria de qualidade e foco nas atividades essenciais da organização. Algumas teorias econômicas embasam as decisões, particularmente a economia dos custos de transação, custos de produção e teoria de agência. Esta tese tem como objetivo realizar um estudo exploratório sobre as formas de desenvolvimento de softwares no gerenciamento da Governança de TI, Gestão de Qualidade e Sistemas para Internet e Software Livre da empresa Software Developer. Sobre os dados provenientes da amostra foram aplicadas várias técnicas estatísticas, como análise de correlação, análise de clusters e análise de variância, para validar as hipóteses do modelo. Os resultados obtidos confirmam o modelo de pesquisa parcialmente, comprovando os relacionamentos entre as formas de contratação e gerenciamento, porém, não permitindo conclusões definitivas sobre a influência de fatores econômicos e objetivos estratégicos na definição e escolha dos modelos de gestão.

Palavras-chave: Tecnologia da Informação, Governança de TI, Gestão de Qualidade. Sistemas para Internet e Software Livre, CMMI, SOX, COBIT e ITIL.

Abstract

Many still frictions the Governance as plus one of the jargon of you, however, to line up and to integrate with the business, together with the best practical and methodologies transformed the Governance of you into one of the best tools to show the real value of you. Before anything, changing the culture of a company it is an arduous, far from easy work, considering itself that all change has resistance and has of if remembering of that many barriers will have to be broken. The change must obligatorily come from top to bottom to have a faster impact, but nothing it hinders that the process has beginning of low for top with small changes, as well as planting some seeds of fruits in a maize field. At the beginning by the fact of the land it will perhaps not be prepared for one determined culture many seeds will not have the adjusted development, but if to prepare the ground the changes will come with same certainty that the medium/long stated period. To prepare here is to define what it is wanted to move and which objective. To celebrate reached objectives, also are in compliance with the COBIT, to reflect on how much this celebration is important and how much, in the Corporative world, some managers already had placed its collaborators to run a race behind the other and to after fight in the sequence of beautiful knock-out! Independent of the complexity or of the activities the important one is not reaches them, but never must we forget us them people. E an important point is that, with the celebrations the fact is marked and of the reasons for new actions, since the activities, processes, tools and projects are moved by people. When celebrating the victories, already we are walking for conformity with the Objective of Control PO7 of COBIT, Governance of you and for the CMMI, SOX and ITL, managing Human resources that have in its definition: “To acquire, to keep and to motivate competent man power for creation and delivery of services of you for the business. That is reached following practical definite and combined that they support to enlist, to train, to evaluate performance, to promote and to finish. This process is critical, therefore the people are important resources, and the governance and environment of internal control are strong dependents in motivation and ability of the staff”. That is, the simple fact to develop a plan of action for this objective of control makes with that let us increase the index of conformity with the reasons that take the organizations total, partial or, its different activities and services in the area of Technology of the Information, being many of them associates to the reduction of costs, improvement of quality and focus in the essential activities of the organization. Some economic theories base the decisions, particularly the economy of the transaction costs, costs of production and theory of agency. This thesis has as objective to carry through an exploratory study on the forms of development of software’s in the management of the Governance of you, Management of Quality and Systems for Internet and Free Software of the company Developer Software. On the data proceeding from the sample statistical techniques had been applied several, as analysis of correlation, analysis of clusters and analysis of variance, to validate the hypotheses of the model. The gotten results partially confirm the research model, proving the relationships between the act of contract forms and management; however, not allowing to definitive conclusions on the influence of strategical economic and objective factors in the definition and choice of the management models.

Key Words: Technology of the Information, IT Governance, Quality Management, Free Software, CMMI, SOX, COBIT and ITIL.

Sumário

1. Introdução 7

2. O COBIT auxilia na conformidade com a Sarbanes? 8

2.1 O COBIT e a Governança de TI 8

3. Governança de TI 8

3.1 Os Processos do ITIL 8

4. Estrutura do ITIL 9

4.1 Gerenciamento de Infraestrutura de TI 9

4.1.1 Projeto e Planejamento. 9

4.1.2 Implantação. 9

4.1.3 Operação. 9

4.1.4 Suporte Técnico 9

4.1.5 Gerenciamento de Serviços 9

5. BSC: BALANCED SCORECARD 9

6. SLA 10

6.1 Conteúdo do SLA e Objetivos Chave 10

6.2 O Gerenciamento do Ciclo de Vida de SLAs. 10

6.3 O novo foco: Negócios 10,10

7. Gestão da qualidade 11

8. Sistemas para Internet E Software Livre 12

8.1 Free/Libre Open Source Software (FLOSS) 12

9. Linux 12,13

10. Cliente/servidor 12

11. Apresentação do problema 14

12. Modelo cliente/servidor 16

12.1 Elementos do modelo Cliente/Servidor 16

12.1.2 Cliente 16,17

12.1.3 Servidor 17

13. Modelos de arquitetura cliente/servidor 17

14. Arquitetura c/s em dois níveis 18

15. Arquitetura c/s multinível 19

16. Desenvolvimento 19,20,21

16.1-Release Planning 21

16.2-Release Building …………………………………………………………………………… …..22

16.3-Acceptance Testing…………………………………………………………………………… ..22

16.4-Release Preparation…………………………………………………………………………… .22

16.5-Release Deployment ……………………………………………………………………… .22,23

16.6-Problem Recording and Classification 23,24

16.7-Problem Investigation and Diagnosis 24

16.8-Error Control 24

16.9- Problem Closure 24

17. Conclusão 24

18. Referências bibliográficas 26

19-Glossário 27

1. Introdução

É princípio básico de uma organização buscar a gerência dos seus processos internos e também a forma de comunicação destes processos com os seus fornecedores e parceiros de negócios, que podemos chamar de processos externos à organização. Isso visa identificar as interfaces entre esses processos, as responsabilidades das áreas da empresa, das pessoas e o desempenho esperado medido por indicadores e metas. Na maioria dos casos, tendo às interfaces definidas, as responsabilidades claras entre as áreas e a mensuração do desempenho, as empresas conseguem alcançar o objetivo final que é a melhoria dos serviços devido aos ganhos de rapidez e produtividade.

As empresas costumam chamar de sistema da qualidade ao conjunto de processos controlados e, muitas delas, possuem departamentos específicos, independentes, com a responsabilidade de tratar da melhoria contínua e evolução dos processos. Existem programas que atingem os vários níveis da organização, desde os processos produtivos de operação e manutenção até os processos administrativos da controladoria e do jurídico. Além disso, para uma empresa de serviços, existem dois elos na cadeia de relacionamento que são os clientes e os fornecedores, não sendo possível à empresa dissociar seus processos da interação com seus consumidores e parceiros de negócio. Os acordos de nível de serviço são uma maneira de gerir essa inter-relação.

O problema que se apresenta é justamente que a melhoria e evolução dos processos não têm fim, pois os negócios podem ser sempre melhorados nos requisitos de organização, eficiência e grau de automação. Para tanto, dependendo do porte e do perfil do negócio da empresa, existem, disponíveis no mercado, uma série de metodologias que norteiam ferramentas de sistemas e treinamentos de capacitação, e que prometem revolucionar o sistema de gestão e a relação entre fornecedor – empresa – cliente. Entidades idôneas podem auditar e certificar empresas quanto à eficiência da aplicação de algumas destas metodologias.

Como exemplos de metodologias disponíveis e largamente aceitas no mercado, podemos citar: o COBIT [ISACA 2000c] para gestão da TI inovando através da Governança Tecnológica e o ITIL [OGC 2002a] que padroniza uma série de processos operacionais e de gestão também ligados a TI. O objetivo é criar uma sistemática padronizada suportada por processos, possivelmente automatizados, que seja entendida e que esteja ao alcance de todos numa organização, que possa ser replicada e, sobretudo, permita evolução. O conceito de Governança Tecnológica, do termo em inglês IT Governance, define que a TI é um fator essencial para a gestão financeira e estratégica de uma organização e não apenas como suporte à empresa. Sem ela tornam-se inviáveis as questões básicas da gestão corporativa. No nível macro, a governança de TI trata justamente da integração e uso de processos corporativos suportados pelos pacotes de gestão. Portanto, Governança Tecnológica é a metodologia (e seus processos integrados) de gestão corporativa dos recursos de TI. A proposta deste trabalho é comparar as várias disciplinas das metodologias mencionadas, através do estudo de caso de uma empresa que fornece serviços de tecnologia, verificando a aplicabilidade dessas metodologias nas organizações: como podem melhorar o controle e a evolução dos processos internos, quais características podem viabilizar a automação destes procedimentos e, finalmente, como afetam os profissionais de tecnologia do nível operacional.

2. O COBIT auxilia na conformidade com a Sarbanes?

“A Lei Sarbanes-Oxley foi editada com o objetivo de restaurar o equilíbrio dos mercados por meio de mecanismos que assegurem a responsabilidade da alta administração de uma empresa sobre a confiabilidade da informação por ela fornecida”.

A Sarbanes é, portanto, uma lei que faz com que os executivos sejam responsáveis por estabelecer, avaliar e monitorar a eficácia dos controles internos relacionados a relatórios financeiros. Para muitas organizações, TI será crucial para alcançar estes objetivos, sendo responsável por assegurar a qualidade e integridade das informações geradas pelos sistemas. Neste contexto a adoção do COBIT na Governança de TI auxiliará a manter a conformidade com a Sarbanes, pois no COBIT existem alguns objetivos de controle com este foco.

2.1 O COBIT e a Governança de TI

O COBIT [ISACA 2000d] – Control Objectives for Information and Related Technology – tem por missão explícita pesquisar, desenvolver, publicar e promover um conjunto atualizado de padrões internacionais de boas práticas referentes ao uso corporativo da TI para os gerentes e auditores de tecnologia.

A metodologia COBIT foi criada pelo ISACA – Information Systems Audit and Control Association – através do IT Governance Institute, organização independente que desenvolveu a metodologia considerada a base da governança tecnológica. O COBIT funciona como uma entidade de padronização e estabelece métodos documentados para nortear a área de tecnologia das empresas, incluindo qualidade de software, níveis de maturidade e segurança da informação. Os documentos do COBIT definem Governança Tecnológica como sendo “uma estrutura de relacionamentos entre processos para direcionar e controlar uma empresa de modo a atingir objetivos corporativos, através da agregação de valor e risco controlado pelo uso da tecnologia da informação e de seus processos”.

A Governança Tecnológica considera a área de TI não apenas como um suporte à organização, mas um ponto fundamental para que seja mantida a gestão administrativa e estratégica da organização. O objetivo central é manter processos e práticas relacionados à infraestrutura de sistemas, redes e dispositivos utilizados pela empresa. A análise destes processos deve orientar a organização na decisão de novos projetos e como utilizar tecnologia da informação neles, considerando também a evolução tecnológica, sistemas já existentes, integração com fornecedores, atendimento ao cliente (externo e interno), custo da tecnologia e retorno esperado. A necessidade de integração de sistemas e a evolução tecnológica são fundamentadas nos processos da metodologia, criando-se métricas para auditoria e medição da evolução das atividades destes processos.

Portanto, o COBIT irá indicar através destes objetivos, que algo precisa ser feito, isto é, serão gerados os Planos de Ação que serão desenvolvidos através de processos que, depois de implementados, estarão em conformidade com a Sarbanes.

3. Governança de TI

3.1 Os Processos do ITIL

O ITIL - Information Technology Infrastructure Library – foi desenvolvido pelo governo britânico no final da década de 1980 e provou que possui uma estrutura útil em todos os setores tendo em vista a sua adoção em várias empresas de gerenciamento de serviços. Em meados da década de 1990 o ITIL foi reconhecido mundialmente como um padrão de facto para gerenciamento de serviços.

Os processos do ITIL estão subdivididos em: Gerenciamento de Aplicações, Gerenciamento de Serviços e Gerenciamento de Infraestrutura de Tecnologia de Comunicações e de Informação (TCI).

4. Estrutura do ITIL

O ITIL tem como foco principal, a operação e a gestão da infra-estrutura de tecnologia na organização, incluindo todos os assuntos que são importantes no fornecimento dos serviços de TI. Nesse contexto, o ITIL considera que um serviço de TI é a descrição de um conjunto de recursos de TI. Os serviços de suporte do ITIL auxiliam no atendimento de uma ou mais necessidades do cliente, apoiando, desta forma, aos seus objetivos de negócios. O princípio básico do ITIL é o objeto de seu gerenciamento: a infra-estrutura de TI. O ITIL descreve os processos que são necessários para dar suporte à utilização e ao gerenciamento da infra-estrutura de TI. Outro princípio fundamental do ITIL é o fornecimento de qualidade de serviço aos clientes de TI com custos justificáveis, isto é, relacionar os custos dos serviços de tecnologia e como estes trazem valor estratégico ao negócio. O interesse nesta área deve-se ao fato de que, através de metodologias (processos) padronizadas de Gerenciamento do Ambiente de TI, é possível obter uma relação adequada entre custos e níveis de serviços prestados pela área de TI.

4.1 Gerenciamento de Infraestrutura de TI

Estes processos cobrem todos os aspectos de gerenciamento da infraestrutura de TCI [OGC 2002b] desde a identificação dos requisitos do negócio, passando pelo projeto e implantação até o suporte e manutenção dos componentes da infraestrutura e serviços de TI. Os principais processos são:

4.1.1 Projeto e Planejamento: relacionados com a criação e melhoria da solução de TCI.

4.1.2 Implantação: relacionado com a implantação da solução de TCI e/ou de negócio conforme planejado e com o impacto mínimo nos processos de negócio.

4.1.3 Operação: refere-se à operação e à manutenção diária da infraestrutura de TCI.

4.1.4 Suporte Técnico: refere-se à estruturação e sustentação de outros processos para garantir os serviços implantados.

4.1.5 Gerenciamento de Serviços

O principal objetivo do gerenciamento de serviços é certificar-se que os serviços de TI estão alinhados com as necessidades do negócio da empresa. Os processos de gerenciamento de serviços estão subdivididos em dois grupos: entrega de serviços e suporte de serviços.

5. BSC: BALANCED SCORECARD

Desenvolvido por Roberto Kaplan e David Norton, o BSC (Balanced Scorcard) é um método prático e inovador de gestão de desempenho das empresas e organizações. O objetivo de sua implementação é permitir uma Gestão eficaz do desempenho organizacional, baseando-se na visão estratégica da empresa e traduzindo-a em indicadores de desempenho.

É uma abordagem estratégica de longo prazo, sustentada por sistemas de gestão ,comunicação e medição de desempenho , cuja implementação permite criar uma visão compartilhada dos objetivos em todos os níveis da Organização.

Uma ferramenta muito utilizada para definirmos objetivos estratégicos ou a estratégia da empresa é o Balance Scorecard, este auxilia a definição através do que chamamos de Mapa estratégico, recurso gráfico para ajudar a comunicar uma visão unificada da estratégia. O Mapa é composto de quatro perspectivas (financeira, cliente, processos internos, aprendizado e crescimento), conforme podemos ver na figura abaixo:

6. SLA

Um acordo entre o prestador de serviços e o cliente de TI que define os objetivos chave de serviços em termos de métricas e as responsabilidades das partes e compromisso de parceria verdadeira deve ser desenvolvido entre o provedor de TI e o cliente para que se obtenha um acordo no interesse de ambas as partes.

De outro modo, os SLAs podem cair em descrédito e uma “cultura de achar o culpado” impede qualquer melhoria real na qualidade dos serviços. Os SLAs fornecem a base para gerenciar o relacionamento entre o prestador de serviços de TI e seus clientes e garantir o alinhamento da TI com o negócio.

6.1 Conteúdo do SLA e Objetivos Chave

O conteúdo específico e os objetivos chave que devem ser incluídos nas SLAs devem ser acordados. Cada situação é única e o conteúdo varia, dependendo do tipo de SLA. Existem alguns fatores comuns que normalmente ocorrem, como:

–Introdução

–Horário dos Serviços

–Disponibilidade

–Confiabilidade

–Suporte

–Throughput

–Tempos de resposta

–Mudança

–Continuidade e Segurança

–Cobrança

–Relatórios e Revisões

–Incentivos e Penalidades

–Novos Serviços / Requerimentos

6.2 O Gerenciamento do Ciclo de Vida de SLAs.

• Tempo de Resposta

• Tempo de Resolução

• Mudanças

• ICS

• Disponibilidade

• Serviços de Negócios

• Incidentes

• Problemas

6.3 O novo foco: Negócios

• Perspectiva de componentes de TI

 Servidores

 Banco de dados

 Switches

 Roteadores

• Medição de performance do componentes

 Taxa de transações de banco de dados

 Tempo de resposta do servidor Web

 Disponibilidade de banda de rede

• Perspectiva das áreas de negócio

 Pedidos on-line

 Suporte técnico ao cliente

• Gerenciamento de pedidos a fornecedores

 Medidas de performance de serviços de negócio

 Tempo total para completar um pedido on-line

• Necessidades

 Medição de fatores de qualidade de serviço

 Tempo total das transações

• Medição da qualidade da experiência

 Demora para contatar o suporte

7. Gestão da qualidade

As PME’s dadas as suas características apresentam algumas vantagens que quando bem utilizadas podem levar à construção de vantagens competitivas, tais como: maior flexibilidade administrativa, facilidade de incorporação de novas tecnologias, o talento do pequeno empresário, estrutura organizacional enxuta, capacidade de rápida reação frente às constantes mudanças, criatividade, entre outras (PINHEIRO, 1996).

Em contrapartida, apresentam algumas limitações em quatro áreas distintas que contribuem para um posicionamento desfavorável perante seus concorrentes (BATALHA E DEMORI, 1990), são elas: Produção, finanças, marketing e administração.

Quanto à produção, os gargalos na área produtiva podem ser definidos como deficiência na gestão, incluindo-se aqui, a falta de manutenção preventiva, lay-outs deficientes, ausência de planejamento e controle dos estoques, desde a matéria-prima ao produto acabado, obsolescência de máquinas e ferramentas, despreparo do corpo técnico da empresa e dificuldades de mão-de-obra qualificada.

No que tange às finanças, os problemas oriundos da área financeira são decorrentes da incapacidade das empresas em gerar capital excedente, bem como pelo fato de apresentarem dificuldades em gerir o capital de giro e controlar custos e orçamentos.

Tratando-se da área de Marketing, esta se apresenta marcada pela ausência de qualidade e inovação dos produtos, concentração da carteira de clientes e inexistência de ações voltadas para vendas eficientes. Por último, na área administrativa os problemas são decorrentes da ausência de técnicas administrativas, ou seja, a falta de informação e qualificação gerencial.

Quanto ao regime de trabalho adotado, a maioria das empresas segue horário fixo de trabalho. Uma parcela significativa das empresas opta pelo horário flexível, em especial, as empresas que atuam na área de software e desenvolvimento de sistemas. Constatou-se ainda que com relação às formas de atuação, as empresas em sua maioria trabalham como fabricante de hardware e software e/ou Desenvolvedora/ Integradora de software. Sendo os softwares mais desenvolvidos, os aplicativos comerciais, com um percentual significativo de empresas que utilizam software sob encomenda. Dentre os produtos comercializados, destacam-se os suprimentos. Com relação às estratégias de Marketing, pode-se observar que as visitas de prospecção por indicação de clientes são as mais utilizadas.

Pode-se perceber que as empresas do estado possuem características de pequeno e médio porte, contudo, isso não se constitui uma limitação na hora de fornecer produtos e serviços com qualidade.

8. Sistemas para Internet E Software Livre

Atualmente, a utilização de software livre tem crescido em larga escala e a idéia de que grandes produtos não podem ser produzidos sob a bandeira do FLOSS (Free/Live Open Source Software) tem sido modificada.

8.1 Free/Libre Open Source Software (FLOSS)

Tendo a liberdade como conceito principal, o movimento do software livre diferencia-se do “open source” (código aberto) software. O argumento é que, mesmo que eles produzam software da mesma forma, o software livre tem uma visão política do mundo. Não é somente sobre software, mas suas idéias podem ser aplicadas a quase tudo. Enquanto que, de acordo com a opinião dos propagadores do software livre, o movimento do “código aberto” é somente uma forma de produzir software, os mesmos não possuem um estímulo político ou social que os levam a fazer deste modo.

Embora os dois movimentos sejam separados, em alguns casos eles reúnem suas forças para atingir objetivos comuns. Em um artigo chamado “Lideres do Software livre se unem”2, proposto por Bruce Perens (2001), os dois movimentos se juntaram para criticar as características de controle e a forma fechada do código da Microsoft. A relevância deste manifesto é a tentativa de unir o movimento do Software Livre e o do Código Aberto para lutar contra o monopólio da Microsoft. O artigo foi co-assinado pelos líderes dos dois movimentos e terminaram o texto convidando a Microsoft a fazer parte do movimento em produzir software de código aberto.

9. Linux

Linux é um grande exemplo de projeto colaborativo e pode ser considerado como modelo e forma de motivação para diversos projetos artísticos e culturais apresentados neste artigo. A grande importância do Linux pode ser entendida como social, a maneira com que se dá a colaboração para criar software usando um sistema descentralizado. O projeto iniciou em 1991, com Linus Torvalds, quando ele propagou pela internet a idéia de um novo sistema operativo e pediu sugestões, ajuda e críticas. Linus enviou um email com a pergunta: “o que você gostaria de ver no Linux?”

Linus Torvalds (2001) diz que na criação de linux existem três leis: sobrevivência, vida social e entretenimento. Sendo estes três princípios sua motivação, o primeiro é uma necessidade básica, algo que é imprescindível. O segundo são as implicações sociais de nossas vidas, os valores que as pessoas têm que irão guiar a forma com que fazem as coisas. E o terceiro é sobre o prazer que alguém tem em desenvolver algo, é o interessante e desafiador...

10. Cliente/servidor

A população de microcomputadores nas empresas, no primeiro instante e posteriormente nas residências, através da redução dos custos de fabricação dos computadores e a adição de Sistemas Operacionais mais amigáveis. Fruto principalmente da parceira realiza da entre a Microsoft, que fornecia o MS-DOS e posteriormente as versões do Windows e a Intel, que desenvolveu novas tecnologias de construção de chips e processadores, dando origem a família i386.

O surgimento de linguagens de programação mais amigáveis e voltadas para esta plataforma, facilitando o desenvolvimento de aplicações e permitindo que profissionais de informática, mesmo sem conhecimento do conjunto de instruções, pudessem utilizar uma linguagem de alto nível. O desenvolvimento das tecnologias de periféricos, armazenamento e rede que possibilitaram o surgimento de novas empresas para fornecimento de hardware para esta plataforma, sem a necessidade de tecnologia proprietária. No item de redes de computadores pode-se destacar a consolidação do protocolo TCP/IP como padrão de facto para construção de aplicações do tipo Cliente/Servidor e Web. Uma das consequências foi a enorme expansão da Internet, que permitiu que computadores pudessem trocar dados utilizando qualquer tecnologia através de redes geograficamente distantes e heterogêneas.

Hoje temos um cenário diferente para o desenvolvimento e execução de aplicações. A segurança das informações que trafegam e ficam armazenadas nestes equipamentos é fator decisivo. Se por um lado não temos mais como deixar os computadores fora de uma rede, por outro deve-se possuir mecanismos que minimizem a exposição de informações, sigilosas ou mesmo valiosas, num ambiente vulnerável.

Até recentemente, a segurança era visita como mais uma das fases finais de elaboração de um produto de software, no entanto, os custos associados a falta de segurança são muito grandes:

• Manutenções complexas e custosas

• Falhas de produtividade

• Fugas de informação

• Perda de contratos e gasto imprevisto de recursos de comunicação, entre outros.

Além disso, podemos mencionar outros fatores que agravam a situação como:

• Complexidade e integração de programas: as aplicações não executam de forma solitária, agora fazem parte de um ambiente complexo com inúmeras interações entre aplicações. Hoje o código necessário para produzir uma aplicação sofisticada e multifuncional é gigantesco.

• Necessidade de produzir software rapidamente: a necessidade de lançar novas versões de software, ditada por razões de marketing e financeiras, contribui também significativamente para este problema. Por essa razão, muitos produtos disponíveis atualmente estão repletos de códigos que apenas cumprem parcialmente a sua função, mas não são soluções conceitualmente elegantes, a prioridade reside em colocar para funcionar rapidamente, não importando muito os meios usados. Além disto, os prazos curtos não condizem com fases de teste e revisão do produto.

• Correções de código de fonte fechada: o cliente final de uma aplicação de código de fonte fechada é obrigado a aceitar as correções produzidas pelo fabricante e não dispõe de alternativa. O cliente, em geral, não possui condições para confirmar se as correções divulgadas realmente resolvem o problema ou se geram novos problemas.

• Preparação inadequada dos programadores: muitos fabricantes não compreendem os riscos a que expõem seus clientes quando desenvolvem produtos deficientes. Na raiz deste subproblema parecem estar a preparação inadequada dos programadores, em parte devido ao uso excessivo de ciclos “produção – depuração – revisão” na codificação de software em contra partida a práticas orientadas ao design, estilo de programação, auditorias de códigos entre outros.

De fato, houve uma grande evolução com a criação de mecanismos de modo a prover ao protocolo TCP/IP meios para adicionar segurança no canal por onde os dados trafegam, também observa-se o esforço das organizações de software livre em oferecer alternativas viáveis para suprir as deficiências ainda existentes pra execução segura de aplicações em plataformas proprietárias.

No decorrer deste trabalho serão apresentadas, através da análise de segurança, quais são os problemas encontrados pelas aplicações para se comunicar com segurança em uma rede de computadores, composta por elementos mantidos por soluções proprietárias e de software livre.

11. Apresentação do problema

Para entender como as aplicações são construídas e como trafegamos os dados numa rede do tipo TCP/IP, protocolo utilizado nas redes atuais, é necessário conhecer a sua estrutura, compreender como estas informações chegam a camada de aplicação e são tratadas.

Pode-se iniciar a exposição deste assunto utilizando como exemplo uma aplicação simples, que não requer nenhuma outra implementação adicional, apenas para ilustrar o processo, com contraste com aplicações mais complexas, que necessitam de pesquisas e conhecimentos mais amplos, não somente neste arquitetura, mas também em tecnologias e protocolos proprietárias de redes.

Figura 1:Arquitetura TCP/IP

Na figura, conforme há um exemplo da estrutura em camadas da arquitetura TCP/IP e também das interfaces entre estas camadas. Utiliza-se neste exemplo como meu físico a tecnologia Ethernet, principal tecnologia de rede local utilizada nas empresas/instituições, bastante conhecida e instalada e a aplicação FTP, que funciona de modo Cliente/Servidor.

Basicamente, para se ter uma troca de informações em rede é necessário no mínimo uma estrutura como a apresentada, ou seja, duas máquinas ligadas por uma tecnologia que utilizam o mesmo protocolo de comunicação. Em muitos casos, a Internet é o meio utilizado para interligar os computadores de redes locais geograficamente distantes. A pilha de protocolos Internet é constituída por camadas lógicas nas quais se definem protocolos de comunicação.

A maneira utilizada para fazer chegar a informação entre a aplicação de origem através da rede até a aplicação destino,baseia-se no encapsulamento sucessivo dos dados em pacotes de informação, em função dos protocolos utilizados na origem. Para tal, constrói-se um novo pacote adicionando um cabeçalho adequado ao pacote do protocolo anterior. No destino, executa-se um processo inverso de desencapsulamento dos pacotes de informação (remoção de cabeçalhos) até se restituir aos dados a sua forma original, a qual será tratada pela aplicação receptora.

Figura 2: Encapsulamento TCP/IP de pacotes do Cliente para um Servidor

A figura 2 apresenta este processo numa rede baseada em tecnologia Ethernet. Durante a travessia na rede, os dados circulam em pacotes cujo formato depende dos meios físicos usados, mas contém todo o encapsulamento executado na origem, os dispositivos de interligação de redes podem assim observar os pacotes em trânsito e tomar decisões de encaminhamento baseando-se nos cabeçalhos desses pacotes.

O processo para comunicação pode ser simples, uma máquina “A” abrindo uma conexão com uma máquina “B”, utilizando uma tecnologia para redes locais, porém na realidade existe uma infinidade de tecnologia de redes e protocolos de comunicação.

Deste modo é necessário ampliar esta estrutura de forma a expor a complexidade encontrada fora dos domínios de uma rede local, onde existem outras redes, conhecidas e desconhecidas, com filtros (firewalls), roteadores e outros elementos que estarão no caminho entre as máquinas “A” e “B”.

Figura 3: ração de redes via Internet

12. Modelo cliente/servidor

A escolha do modelo e o modo como são realizados os processamentos, influenciam diretamente no desempenho das aplicações. Atualmente existe uma grande flexibilidade e diversidade destes modelos e muitos são utilizados nas aplicações que executamos diariamente. A exposição destes modelos e arquiteturas nos faz compreender melhor o papel desempenhado em cada uma das extremidades da comunicação entre computadores.

12.1 Elementos do modelo Cliente/Servidor

A maior parte das aplicações de rede é desenvolvida assumindo-se que um dos agentes comunicantes é o cliente e o outro é o servidor, sendo o objetivo da aplicação fornecedor um serviço pré-definido através do servidor. Neste sentido a arquitetura Cliente/Servidor vem sendo desenvolvida há vários anos, porém em pequenos passo.

Uma definição para a arquitetura Cliente/Servidor seria a existência de uma plataforma base para que as aplicações, onde um ou mais Clientes e um ou mais Servidores, juntamente com o Sistema Operacional e o Sistema Operacional de Rede, executem um processamento distribuído.

Em suma, um sistema Cliente/Servidor poderia ser, então, entendido como a interação entre Software e Hardware em diferentes níveis, implicando na composição de diferentes computadores e aplicações de forma distribuída. Para melhor se entender o paradigma Cliente/Servidor é necessário observar que o conceito chave está na ligação lógica e não física. O Cliente e o Servidor podem coexistir ou não na mesma máquina.

12.1.2 Cliente

Cliente, também denominado de “front-end” e “Workstation”, é um processo que interage com o usuário através de uma interface gráfica ou não, permitindo consultas ou comandos para recuperação de dados e análise e representando o meio pelo qual os resultados são apresentados. Além disso, apresenta algumas características distintas.

• É o processo ativo na relação Cliente/Servidor.

• Inicia e termina as conversações com os Servidores, solicitando serviços distribuídos.

• Não se comunica com outros Clientes.

• Torna a rede transparente ao usuário.

12.1.3 Servidor

Servidor, também denominado “back-end”, fornece um determinado serviço eu fica disponível para todo cliente que o necessita. A natureza e escopo do serviço são definidos pelo objetivo da aplicação Cliente/Servidor. Além disso, ele apresenta ainda algumas propriedades distintas:

• É o processo reativo na relação Cliente/Servidor.

• Possui execução continua.

• Recebe e responde às solicitações dos Clientes.

• Não se comunica com outros Servidores enquanto estiver fazendo o papel de Servidor.

• Presta serviços distribuídos.

• Atende a diversos Clientes simultaneamente.

13. Modelos de arquitetura cliente/servidor

Existem cinco tipos de modelos para a implantação da arquitetura Cliente/Servidor em processamentos distribuídos.

A primeira abordagem para um sistema distribuído é a arquitetura Cliente/Servidor Simples. Nesta arquitetura, o Servidor não pode iniciar nada, este somente executa as requisições do Cliente. Existe uma clara função de diferenciação, pode-se estabelecer que o Cliente é o mestre e o Servidor é o escravo, como mostra a figura 4.

Figura 4:Arquitetura C/S simples

14. Arquitetura c/s em dois níveis

A configuração usual Cliente/Servidor encontrada na maioria das empresas. É aquela em que existem vários Clientes requisitando serviços a um único Servidor. Esta arquitetura se caracteriza como sendo centrada no Servidor (Figura 5), porém na visão do usuário, ele imagina que existem vários servidores conectados a somente um cliente, ou seja, centrado no Cliente (Figura 6). Entretanto, com as várias ligações de comunicação possíveis, existe na realidade uma mistura de Clientes e Servidores (Figura 14.3).

Figura 5: Configuração da arquitetura C/S em dois níveis-centrada no servidor

Figura 6: Configuração da arquitetura C/S em dois níveis-centrada no cliente.

Figura 7:Arquitetura centrada nos dois níveis –configuração mista

15. Arquitetura c/s multinível

Nesta arquitetura, ilustrada na Figura 8, permite-se que uma aplicação possa assumir tanto o perfil do Cliente como o do Servidor, em vários graus, em outras palavras, uma aplicação em alguma plataforma será um Servidor para alguns Clientes e, concorrentemente, um Cliente para alguns Servidores.

Figura 8:Arquitetura C/S multinível

16. Desenvolvimento

Embasando-nos no cenário apresentado na proposta deste projeto, para sanar as seguintes falhas da Software Developer:

• Controle de criação, edição e versão dos documentos;

• Cadastramento dos riscos associados aos processos de negócios e armazenar os desenhos de processo;

• Gerenciamento dos documentos e controle dos períodos de retenção e distribuição;

Podemos aplicar a gestão de TI, por meio das boas práticas de ITIL criando plano de gerência de projetos de softwares aliado à gestão eletrônica de documentos, que é um conjunto de tecnologias que permite o gerenciamento de documentos de forma digital. Tais documentos podem ser das mais variadas origens e mídias, como papel, microfilme, som, imagem e mesmo arquivos já criados na forma digital, contendo os itens abaixo descritos de forma detalhada. Este tipo de plano deveria ser adotado ao iniciar-se o desenvolvimento de um novo software, estando assim alinhado com a lei Sarbanes-Oxley e minimizando os problemas hoje enfrentados pela empresa.

Com a aplicação da gestão eletrônica de documentos temos os seguintes ganhos:

• Acesso aos documentos mais rápido através da indexação e classificação dos documentos;

• Busca eficiente de informações relacionadas aos fluxos de trabalho;

• Controle de versões, atualizações e auditoria -> Informações confiáveis;

• Minimização da duplicidade de informação;

Outra ação básica que deveria ser realizada pela Software Developer, é a implementação de toda e qualquer alteração primeiramente em ambiente de teste e somente depois de obter resultados positivos, transportar estas alterações para o ambiente de produção. Com isto os riscos de falhas para seus clientes seriam reduzidos significantemente.

No que toca os serviços de suporte prestados pela Software Developer e suas falhas, tomando como base os princípios de governança de TI, gestão da qualidade e sistemas para internet e software livre, através das seguintes ações a qualidade de seus serviços pode ser melhorada de forma notável e com isto também a empresa estará alinhada com as melhores práticas de governança de TI e pelo ITIL.

Primeiramente um sistema de gestão de incidentes deve ser adotado, bem como um processo de classificação do incidente tem de ser definido.

O que é classificar um incidente? Como essa atividade simples pode aumentar a qualidade do fornecimento de serviços? Antes de qualquer coisa é preciso entender os conceitos e a importância dessa atividade para a Gerência de Incidentes e para os outros processos das melhores práticas ITIL. O que é classificação?

- CLASSIFICAÇÃO = CATEGORIA + PRIORIDADE, onde:

- CATEGORIA = determina o tipo de Item de configuração afetado no incidente (por exemplo: Hardware/Software)

- PRIORIDADE = IMPACTO + URGÊNCIA, sendo que:

- IMPACTO = Impacto que o incidente pode causar nos negócios

- URGÊNCIA = tempo requerido para resolução (relacionado a tempo).

Na prática, a classificação de um incidente pode parecer algo muito simples. Por isso, na maioria das vezes durante a implementação ou no dia a dia do processo não damos a devida importância a essa atividade.

Classificar um incidente é sim uma atividade relativamente simples, mas criar categorias que possam trazer eficiência e melhorar os serviços de uma organização pode ser bastante desafiador.

Quando vamos implementar a Gerência de incidentes das melhores práticas ITIL, é importante investir tempo planejando essa classificação. Qual seria a melhor classificação (sempre pensando no custo benefício para o seu negócio)? É importante ter em mente que o ideal é sempre o máximo de informação, com o mínimo de controle e custo para mantê-la.

Abaixo apresentamos como a correta classificação de um incidente pode contribuir para aumentar a eficiência de uma organização e o fornecimento de serviços.

1. A classificação é usada para definir e/ou selecionar o melhor especialista ou grupo para lidar com o incidente. Ela auxiliará a encaminhar o incidente para os especialistas mais preparados para atendê-lo, evitando que outros grupos de suporte gastem tempo e esforços na solução de incidentes para os quais não foram adequadamente preparados.

2. A classificação também é usada para comparar incidentes e contribuir para melhorar o tempo e qualidade da investigação e diagnóstico . Através da classificação é possível comparar incidentes que já aconteceram e aplicar diagnósticos e soluções já implementados no passado para os incidentes atuais de maneira mais fácil , rápida e precisa.

3. A classificação é usada para identificar a prioridade de atendimento de incidentes, baseada no impacto que o incidente traz para o negócio. Com isso é possível priorizar o atendimento daquilo que realmente causa impacto para o negócio de uma organização (perdas financeiras, de imagem, etc.)

4. A correta classificação auxiliará uma organização a definir quais questões devem ser feitas e checadas durante a abertura do incidente. Pode ser criado um script de perguntas para garantir que as informações necessárias sejam obtidas com o usuário impactado e registradas no momento da abertura e suporte inicial do incidente. Isso evitará perguntas e testes desnecessários com os usuários e melhorará a qualidade e tempo do atendimento do incidente.

Outra falha apontada nos processos da Software Developer é quanto à forma de implementação dos novos releases. Para reduzir o número de outages vivenciados por seus clientes é necessário que o processo de release management seja realizado. Um bom Gerenciamento de Versões deve planejar gerenciar e garantir um empacotamento e uma distribuição de versões ideal, garantindo que todos os aspectos da liberação sejam considerados antes de sua implantação. Este conceito permite agir com pró-atividade na hora de lidar com mudanças típicas ou emergenciais, oferecer um plano de versão alinhado com as exigências resultantes das alterações aprovadas, construir pacotes de versão efetivos para a implementação de uma ou mais mudanças no ambiente de produção, preparar revisões para a versão com o intuito de assegurar ao máximo uma implementação segura e implementar uma versão de acordo com os guias estruturados de implementação.

As atividades de Release Management podem ser representadas por um fluxo de processos que aborda as tarefas fundamentais necessárias para gerenciar liberações com excelência, a seguir iremos conhecer as fases deste processo.

16.1-Release Planning

Na primeira etapa deveremos elaborar um plano que identifique as atividades e os recursos necessários para implementar com sucesso uma nova versão no ambiente de produção. O escopo e o conteúdo da alteração devem ser identificados de acordo com os requisitos, devemos também fazer uma avaliação dos riscos envolvidos e envolver nesta avaliação os grupos apropriados para que seja possível priorizar, planejar e agendar as atividades de liberação. Será necessário também montar uma equipe, alinhar a estratégia com os especialistas e os interessados e por fim documentar e registrar todas as atividades planejadas para a liberação.

16.2-Release Building

Na segunda etapa teremos que identificar e desenvolver os processos, ferramentas e tecnologias necessárias para implementar a nova versão no ambiente de produção. Devemos selecionar uma tecnologia que permita uma liberação estratégica, repetitível e consistente e também teremos que desenhar e construir um Release Package (Pacote de liberação), testando as alterações para garantir o alinhamento com os requisitos e garantir que o pacote seja adicionado à CMDB, como um Release Package pendente, e se necessário adicionar algum script à DSL.

16.3-Acceptance Testing

Esta terceira etapa do processo permite que os desenvolvedores e os representantes do negócio vejam como a liberação e o pacote de liberação (Release Package) são executados juntos em um ambiente que reflete um ambiente de produção. Devemos desenhar e construir um ambiente de testes que simule o ambiente de produção para que seja possível realizar alguns testes fundamentais como se fosse o próprio usuário alinhando o que está sendo desenvolvido com o que foi requisitado e fazer um piloto de teste controlado no ambiente de produção para avaliar os resultados e tomar decisões necessárias para a próxima etapa.

16.4-Release Preparation

Na quarta etapa teremos que preparar o ambiente de produção para a nova versão a ser implementada. Tenha certeza de que os recursos necessários estejam disponíveis e que uma comunicação efetiva vem sendo realizada com relação a esta mudança, assegure também que os treinamentos e atividades com os usuários foram concluídos e confirme que o ambiente está pronto para receber a alteração. Revise a preparação de implementação da liberação em um ambiente de produção e verifique se realmente todas as mudanças relacionadas foram controladas pelo processo de Change Management.

Durante a quinta etapa, a fase de Deployment Process as tarefas e atividades vão depender do tipo e da natureza da liberação e é claro do mecanismo utilizado para executar esta etapa. Selecione um grupo para o desenvolvimento e tenha certeza de que os usuários tenham sido treinados adequadamente para beneficiar ao máximo esta liberação. Implemente a nova versão no ambiente de produção e revise a implementação levando em conta o comentário de todos os envolvidos, encaminhe este feedback ao Change Manager para que ele possa utilizá-lo na fase de Change Review e então conclua com sucesso a seqüência de implementação e revisão.

O fato dos clientes da Software Developer estar reportando que independentemente do tipo de problema não há explicações claras sobre o que levou ao ocorrido, se dá devido à não realização do RCA (Root Cause Analysis) e do processo de gerenciamento de problemas.

Na maioria dos casos, quando os problemas aparecem, a forma habitual para solucioná-los é do tipo atuar na não conformidade localizada e uma ação corretiva (ou uma série de ações) é tomada. Essas ações podem melhorar o desempenho do processo a curto prazo. Mas é questão de tempo para que as falhas voltem a aparecer, e geralmente geram prejuízos ainda maiores do que antes da ação.

Isto acontece porque se tenta buscar a todo custo uma maneira para resolvê-lo, sem antes entender o problema, como ele ocorre, com que freqüência ou quais seus efeitos e, principalmente sem fazer uma análise mais crítica para relacionar o problema com sua verdadeira causa. Agindo desta forma, as falhas em processos continuarão ocorrendo e há a necessidade de constantemente solucionar os problemas localizados.

Isso pode ser evitado se houver o foco atacar a verdadeira causa do problema, evitando que as falhas voltem a ocorrer. É o que se chama de cortar o mal pela raiz. Uma vez que as causas raiz são identificadas, uma ação adequada é tomada e passa-se a monitorar as causas das falhas, atuando no processo antes que os desvios venham a ocorrer. Agindo desta forma, deixamos de conviver com o referido problema, pois a causa foi tratada e passamos a trabalhar de forma preventiva. Para uma eficaz análise de causa raiz deve-se: identificar o problema; identificar as causas potenciais do problema; dentre as causas potenciais, identificar as causas raiz; definir e implementar ações focadas nas causas raiz; e monitorar o processo para avaliar eficácia da ação implementada.

Basicamente, quando se está realizando uma análise de causa raiz, deve-se descobrir o que aconteceu ou está acontecendo, descobrir porque aconteceu e criar barreiras para que os problemas não voltem a ocorrer. A coleta de dados adequados, que comprovem um relacionamento entre a causa e o problema (causa e efeito) sempre deve ser utilizada para dar suporte à tomada de decisão.

Para a realização de uma análise de causa raiz, várias técnicas ou ferramentas podem ser utilizadas:

* Diagrama de Causa e Efeito;

* 5 porquês;

* Brainstorming;

* FMEA e FTA (Faut Tree Analysis);

* Testes de hipóteses;

* Análise de regressão;

* Planejamento de experimentos.

Na análise de causa raiz, se gasta um tempo extra na investigação das causas de não conformidades. Porém, ao se atuar na causa raiz do problema, ganha-se tempo e dinheiro a longo prazo, uma vez que se monitora as causas dos problemas encontrados no processo e são realizadas as ações preventivas.

Junto ao processo de análise de causa raiz, deve ocorrer a atuação do grupo responsável pelo gerenciamento de problemas, que é responsável por minimizar o impacto causado no ambiente da organização por incidentes e problemas decorrentes de erros na infraestrutura, prevenindo o retorno destes incidentes relacionados com tais erros. Para que isso seja possível o Gerenciamento de Problemas busca identificar a causa raiz destes incidentes e começar ações que melhorem ou corrijam a situação. Ao identificar e tomar posse dos problemas que afetam a infraestrutura e os serviços nós deveremos executar ações para reduzir o impacto sofrido e identificar o que poderá ter causado tais anomalias para assim estabelecer uma solução permanente aos problemas identificados.

Ao analisar a tendência de ocorrências nós registraremos informações sobre os incidentes com o pensamento de que poderemos prevenir a organização de problemas futuros priorizando as atividades da equipe. O ponto chave aqui é a identificação pró-ativa de potenciais problemas evitando incidentes antes que eles aconteçam. Deveremos criar Workaround (meios possíveis identificados de se resolver um incidente em particular que permite o serviço voltar ao normal, porém não solucionando o problema de fato) e ter em mente que o objetivo do Incident Management é restaurar um serviço o mais rápido possível e o objetivo do Problem Management é identificar a causa raiz dos incidentes com foco na sua solução permanente durante o ciclo de vida de Problemas/Erros.

As atividades do Gerenciamento de Problemas podem ser representadas por um fluxo de processos que aborda as tarefas fundamentais necessárias para gerenciarmos problemas com excelência, a seguir iremos conhecer as fases deste processo.

16.6-Problem Recording and Classification

Nesta primeira etapa deveremos registrar e classificar os problemas, que na maioria das vezes são identificados pelos processos da incident management ou através das análises de dados feitas pela equipe do problem management. Outras SMFs como Availability Management e Capacity Management podem também durante suas tarefas identificarem problemas e estes deverão ser reportados para a equipe de Problem Management. É importante que os problemas e os incidentes sejam registrados para facilitar o processo de dar prioridade e resolver os problemas, onde a classificação é definida pelo grau do impacto causado pelo problema no ambiente da organização e a urgência da solução exigida.

16.7-Problem Investigation and Diagnosis

Nesta segunda etapa deveremos investigar os problemas e diagnosticar sua causa raiz, o resultado desta análise deverá ser utilizado para ajudar a equipe de Problem Management avaliar os recursos e habilidades necessárias para solucionar o problema. Este processo requer tarefas adicionais como planejamento, coordenação, recursos e comunicação para formalizar a ação.

16.8-Error Control

Nesta terceira etapa desenvolveremos os processos para corrigir com sucesso os erros conhecidos, tendo como objetivo realizar as mudanças necessárias para resolver de uma vez por todas os erros que afetam nossa infra-estrutura de TI prevenindo que incidentes relacionados voltem a acontecer. Para realizar este controle nós deveremos trabalhar em conjunto entre o ambiente de desenvolvimento e produção interagindo diretamente com os processos de Change Management, na busca de uma solução definitiva para o problema.

16.9- Problem Closure

Nesta quarta etapa deveremos registrar todas as informações sobre o problema em nosso sistema de gerenciamento de problemas, salvar as alterações dos Itens de Configuração, os sintomas, e a resolução de todos os problemas para manter uma base de conhecimento bem atualizada. Estas informações estarão disponíveis para prevenir futuros problemas ou executar soluções mais rápidas. Antes de fechar de fato o problema devemos mantê-lo no estado Closed Pending PIR e em seguida executar uma revisão, a Post-Implementation Review (PIR), para atestar que está tudo bem, e por fim fechar realmente o problema. Em alguns casos, por exemplo, no de incidentes deveremos contatar o usuário que sofreu com o problema e verificar se ele não percebeu mais nenhuma anomalia e para problemas mais sérios ou erros conhecidos poderá ser necessária uma revisão formal.

16.10- Proactive Analysis and Problem Reviews

Esta quinta etapa está relacionada com a capacidade de identificar e solucionar problemas e erros conhecidos antes mesmo que incidentes aconteçam, agindo com pró-atividade, minimizando o impacto nos serviços e nos negócios da organização. Deveremos pegar como exemplo algum Major Incident ou um Major Problem que já tenha acontecido e analisar os seus eventos e ações executadas quando ele ocorreu de forma que esta revisão forneça informações úteis para análises futuras garantindo que sejam registradas estas lições aprendidas. Uma boa prática é se reunir com as pessoas que participaram da resolução deste Major Incident ou Major Problem analisado e fazer algumas perguntas, como: O que foi feito corretamente? O que foi feito incorretamente? O que poderia ser feito melhor da próxima vez? Como previr que aconteça de novo? Como agir o mais rápido possível se acontecer novamente? etc.

17. Conclusão

É nítida a necessidade da adoção da gestão de TI bem como da gestão da qualidade na empresa Software Developer. Mediante as necessidades da mesma, concluímos que seria uma boa opção a adoção da ITIL.

ITIL oferece um framework comum para todas as atividades do departamento de TI, como a parte da provisão dos serviços, baseada na infraestrutura de TI. Estas atividades são divididas em processos, que fornecem um framework eficaz para um futuro Gerenciamento de Serviços de TI aprimorado. Cada um destes processos cobre uma ou mais tarefas do departamento de TI, tais como desenvolvimento de serviços, gerenciamento da infraestrutura, fornecimento de serviços e suporte a serviços.

Estes processos propiciam o uso das melhores práticas, fazendo com que o departamento de TI possa adotar independente da estrutura da organização. As melhores práticas da ITIL têm como objetivos: Servir de inspiração para melhorar seus processos de TI; Sugerir onde é possível chegar, pois outras empresas já conseguiram resultados positivos; Sugerir para que servem os processos e práticas; Sugerir por que adotar os processos e práticas. A vantagem da adoção das melhores práticas está no fato de não ter que “reinventar a roda”, adotar práticas já testadas propicia um ganho de tempo e retorno mais rápido sobre o projeto de implementação de uma Gestão de Serviços.

“Na ITIL tudo pode nada deve.” Alguns benefícios que a Software Developer desfrutaria da adoção da ITIL: •Aumento da disponibilidade e confiabilidade dos serviços de TI e melhoria de desempenho dos processos de negócio; • Redução dos custos dos serviços de TI; • Maior eficiência nas respostas aos usuários; • Maior transparência e profissionalismo nas decisões envolvendo TI e negócio; • Aumento da satisfação dos usuários e clientes dado que os provedores sabem e entregam o que se espera deles. E por fim o aumento de seus lucros.

18. REFERÊNCIAS BIBLIOGRÁFICAS

http://www.semasa.sp.gov.br/admin/biblioteca/docs/pdf/35Assemae124.pdf

http://www.ead.fea.usp.br/cad-pesq/arquivos/C02-art04.pdf

http://governadeti.blogspot.com/

http://www.cpqd.com.br/index.php

http://docs.google.com/viewer?a=v&pid=sites&srcid=ZGVmYXVsdGRvbWFpbnxwZWRyb251bm90c3xneDo0ZjJlNGFiN2U5Y2NkYzdh

19-Glossário

Figura 1:Arquitetura TCP/IP............................................................................14

Figura 2: Encapsulamento TCP/IP de pacotes do Cliente para um Servidor........................................................................................................15

Figura 3: ração de redes via Internet.........................................................16

Figura 5: Configuração da arquitetura C/S em dois níveis-centrada no servidor..............................................................................................................17

Figura 7:Arquitetura centrada nos dois níveis –configuração mista..................18

Figura 4:Arquitetura C/S simples...............................................................18

Figura 6: Configuração da arquitetura C/S em dois níveis-centrada no cliente.................................................................................................................19

Figura 8:Arquitetura C/S multinível.............................................................19

UNIVERSIDADE PAULISTA

CURSO SUPERIOR DE TECNOLOGIA

GESTÃO EM TECNOLOGIA DA INFORMAÇÃO

LINDALVA DE SOUZA LIMA

PIM VII

PROJETO INTEGRADO MULTIDISCIPLINAR

GESTÃO DE TI DO SOFTWARE DEVELOPER

Belém – Pará

2014

LINDALVA DE SOUZA LIMA

PIM VII

PROJETO INTEGRADO MULTIDISCIPLINAR

GESTÃO DE TI DO 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: NATÁLIA MORAES

Belém - Pará

2014

Resumo

O objetivo deste trabalho é fazer uma demonstração prática do quadro de estudos e conteúdo das matérias: Gerenciamento de projetos de TI, Empreendorismo e Qualidade de software. Usaremos como objeto de estudos uma empresa “fictícia” Paulista chamada Software Developer cujo afim é o desenvolvimento de aplicativos da área financeira abrangindo os setores de: Sistema de Consórcio, Sistema Financeiro e Sistema de Empréstimos. Após vários problemas, oriundos diretamente da área de produção ou relatados por clientes, terem sido catalogados pela Software Developer uma abrangente ação corretiva deverá ser implantada. A Consulting empresa, fictícia, de consultoria foi contratada com o objetivo de apresentar um estudo contendo analise de impacto, planejamento, desenvolvimento e atuar na implementação de soluções permanentes e orientar na metodologia para a obtenção da certificação CMMI.

Abstract

The objective of this paper is to make a practical demonstration of the framework for studies and content of the materials: IT projects, Entrepreneurship and Quality Management software. We will use as an object of study a "dummy" company called Paulista Software Developer whose order is the application development area a