UNIVERSIDADE PAULISTA

ANDERSON AFONSO IZAIAS RA A66IFC-5 ALEXANDRE ALVES MOURA RA A668GB-7 FBIO AUGUSTO CASTILHO RA A6621C-7 FERNANDO CANISIO LIMA RA A664CC-0

CONSULTING Consultoria para Implantao do CMMI nvel 2

SO PAULO 2011

ANDERSON AFONSO IZAIAS RA A66IFC-5 ALEXANDRE ALVES MOURA RA A668GB-7 FBIO AUGUSTO CASTILHO RA A6621C-7 FERNANDO CANISIO LIMA RA A664CC-0

CONSULTING Consultoria para Implantao do CMMI nvel 2

Trabalho de aplicao e desenvolvimento dos conhecimentos adquiridos no 3 semestre de Gesto da Tecnologia da Informao apresentado Universidade Paulista UNIP.

Orientadora: Prof Liliam Sakamoto

UNIP Anchieta 2011 AGRADECIMENTOS Agradecemos a Deus em primeiro lugar por sempre nos d inspirao; Aos nossos familiares e amigos, pelo apoio e compreenso nos momentos de ausncia em funo do desenvolvimento do PIM; professora Liliam Sakamoto, pelas orientaes to bem vindas e por acreditar na nossa capacidade.

importante criar dificuldades para os que tm talento. As facilidades os limitam.

(Bernardo Rocha de Rezende) RESUMO Nos dias atuais algumas empresas desenvolvedoras de software criam sua prpria metodologia de trabalho. Devido concorrncia, a preocupao das empresas est voltada muito mais na nfase dos custos do que em qualidade agregada ao produto. O objetivo da pesquisa abordar a melhoria nos processos de software segundo os principais modelos de qualidade e de maturidade de softwares existentes no mercado empresarial. Para obter vantagem competitiva, bem como a satisfao dos clientes, as empresas devem buscar a maturidade dos processos, eliminar as falhas operacionais e atualizar-se continuamente na tecnologia empregada. Isso requer uma interao das pessoas, dos processos e da empresa como um todo. Baseado no estudo da Empresa Software Developer, verificou-se que a melhoria dos processos de software deve ocorrer primeiramente nos processos que por sua vez influenciar diretamente na qualidade do produto final. O trabalho concluiu que os modelos de qualidade e maturidade servem como base para a melhoria dos processos. Palavras-chave: Modelos de qualidade, modelos de maturidade.

ABSTRACT Nowadays some companies software developers create their own working methods. Due to competition, the business concern is focused far more emphasis on cost than quality added to

the product. The objective of this research is to address the improvement in software processes according to the main models of quality and maturity of existing software in the enterprise market. To gain competitive advantage and customer satisfaction companies should seek the maturity of processes, eliminate operational failures and continuously upgrade the technology used. This requires an interaction of people, processes and the organization as a whole. Based on the study by the Software Developer, it was found that the improvement of software processes must occur first in the processes which in turn greatly influence the final product quality. The study concluded that the quality and maturity models serve as the basis for process improvement. Keywords: models of quality, maturity models.

SUMRIO 1. INTRODUO 1 2

1.1 Empresa Software Developer 1.2 Empresa Consulting 2 2. GOVERNANA DE TI 2 2.1 Governana 2 2.2 BSC 2 2.3 Governana Corporativa 2.4 Governana de TI 2.4.1 SOX 2.4.2 COBIT 2.4.3 CMMI 2.4.4 ITIL 5 7 11 13 15 4 3

2.4.5 Outsourcing 2.4.6 SLA 16

2.5 Governana Corporativa versus Governana de TI 17 3. SISTEMAS PARA INTERNET E SOFTWARE LIVRE 3.1 Arquitetura Cliente/Servidor 3.2 Aplicaes em quatro camadas 3.3 Sistemas distribudos 20 18 19 18

3.4 Conceitos bsicos de Software Livre 21 3.5 Novos modelos de Negcio na Internet 3.6 Comrcio Eletrnico 3.7 Marketing na Internet 3.8 Sites de buscas 3.9 E-mail marketing 25 25 25 24 25 23

3.10 Programa de fidelizao 3.11 Links patrocinados 25 3.12 Compra coletiva 3.13 Banners 26 26 26

3.14 Redes Sociais

4. QUALIDADE DE SOFTWARE 27 4.1 Qualidade do Processo versus Qualidade do Produto 4.2 ISO 28 4.3 ISO/IEC 9126 4.4 ISO 25000 30 4.5 ISO 9000-3 32 4.6 ISO 9001 32 29 28

4.7 ISO 12207 32 4.8 CMMI 4.9 MPS.BR 33 33

4.10 SPICE ISO 15504 35 5. GERENCIAMENTO DE PROJETOS DE TI 5.1 Scrum 38 39 41 36

6. EMPREENDEDORISMO 7. GESTO DA QUALIDADE CONCLUSO 43

REFERNCIAS 44 ANEXOS 46

1. INTRODUO O PIM (Projeto Integrado Multidisciplinar) refere-se ao desenvolvimento de um trabalho no formato de um projeto de acordo com as normas da ABNT. Os objetivos gerais do PIM faz parte do Programa Pedaggico dos Cursos Superiores de Tecnologia da UNIP - Universidade Paulista, buscando inserir o aluno nas prticas gerenciais fundamentadas nos conhecimentos tericos adquiridos em sala de aula, com carter prtico complementar do processo de ensino e aprendizagem. Os objetivos especficos do PIM desenvolver no aluno a prtica da realizao de pesquisa cientfica, elaborando um trabalho conclusivo e suas ponderaes. O grupo do PIM representar uma consultoria fictcia chamada Consulting que fica localizada em So Paulo Capital. Esta consultoria foi contratada por uma empresa desenvolvedora de software para consrcios, chamada Software Developer, tambm localizada em So Paulo - SP, com o objetivo de entregar um estudo contendo analise de impacto, planejamento, desenvolvimento e como implementar e obter a certificao CMMI nvel 2, o qual foi definido pelo orientador do PIM. O desenvolvimento do PIM est estruturado em duas partes: A primeira parte terica apresenta no captulo 1 a Introduo, no captulo 2 - Governana de TI, no captulo 3 - Sistemas para Internet e Software Livre, no captulo 4 - Qualidade de Software, no captulo 5 - Gerenciamento de Projetos de TI e no captulo 6 - Empreendedorismo sempre demonstrando como elas podem ser empregadas para a correo das deficincias vividas pela rea de TI da empresa Software Developer. Na segunda parte a empresa Consulting desenvolver uma proposta tcnica contendo anlise e sugesto dos erros para a certificao CMMI nvel 2 levantando os requisitos voltados ao planejamento para auxiliar na identificao e correo das ineficincias dos processos, na execuo sempre objetivando a obteno da maturidade dos processos e finalmente nos custos totais do projeto.

1.1 Empresa Software Developer A software Developer uma empresa que desenvolvedora de softwares. Seu principal produto so sistemas de consrcios para instituies financeiras. Os sistemas desenvolvidos pela Software Developer apresentam falhas quando j esto em funcionamento no ambiente de trabalho dos seus clientes, o que gera parada dos servios e prejuzos.

Consciente dos problemas apresentados em seus sistemas a empresa resolveu buscar certificao CMMI (Capability Maturity Model Integration) nvel 2 para a maturidade dos seus processos. 1.2 Empresa Consulting A Consulting uma empresa de Consultoria especializada em preparar empresas que buscam certificaes CMMI. Vale salientar que a empresa no um rgo certificador autorizado pela SEI (Software Engineering Institute). 2. GOVERNANA DE TI 2.1 Governana No passado, os modelos de gesto das empresas eram centralizados na figura do proprietrio, onde a superviso direta era a caracterstica principal deste modelo. Nos dias atuais, o proprietrio da organizao descentralizou suas atividades quebrando o velho paradigma de que so os olhos do dono que engordam a boiada assumindo a funo de gestor da organizao, contando com ferramentas gerenciais que o auxiliam nos processos da organizao como um todo. 2.2 BSC O BSC (Balanced Scorecard) sistema de gesto estratgica criado pelos professores Robert Kaplan e David Norton da Universidade Harvard dos Estados Unidos em 1992, visa integrao e balanceamento de todos os principais indicadores de desempenho existentes em uma empresa, desde os financeiros e administrativos at os relativos aos processos internos, estabelecendo objetivos da qualidade para funes e nveis relevantes dentro da organizao, ou seja, o desdobramento dos indicadores corporativos em setores, com metas claramente definidas. Assim, esse modelo traduz a misso e a estratgia de uma empresa em objetivos e medidas tangveis, fazendo o alinhamento estratgico da TI com o negcio. O Balanced Scorecard baseado em quatro perspectivas: * Financeira - Para sermos bem sucedidos financeiramente, como deveramos ser vistos pelos nossos acionistas? * Clientes - Para alcanarmos nossa viso, como deveramos ser vistos pelos nossos clientes? * Processos internos - Para satisfazermos nossos clientes, quais processos de negcios deveram alcanar a excelncia? * Aprendizado - Para alcanarmos nossa viso, como sustentaremos nossa capacidade de mudar e melhorar? Essas perspectivas formam um conjunto coeso e interdependente, com seus objetivos e indicadores se inter-relacionando e formando um fluxo ou diagrama de causa. 2.3 Governana Corporativa

Para o IBGC (Instituto Brasileiro de Governana Corporativa), "sistema pelo qual as organizaes so dirigidas, monitoradas e incentivadas, envolvendo os relacionamentos entre proprietrios, conselho de administrao, diretoria e rgos de controle. As boas prticas de governana corporativa convertem princpios em recomendaes objetivas, alinhando interesses com a finalidade de preservar e otimizar o valor da organizao, facilitando seu acesso ao capital e contribuindo para a sua longevidade". Pode-se dizer que formada por um conjunto de prticas, regras, costumes, leis, polticas e regulamentos que tem como finalidade a transparncia e regular o modo como uma empresa administrada e controlada, favorecendo os interesses mtuos de acionistas, administradores, funcionrios e fornecedores. A Governana Corporativa tem como objetivo criar, recuperar e garantir a confiabilidade para os seus acionistas criando um conjunto eficiente de mecanismos, tanto de incentivos quanto de monitoramento, a fim de assegurar que o comportamento dos executivos esteja sempre alinhado com o interesse dos acionistas. A boa Governana Corporativa evita os abusos de poder, erros estratgicos e fraudes. A boa governana formada por 8 caractersticas: 1. Participao; 2. Estado de direito; 3. Transparncia; 4. Responsabilidade; 5. Orientao por consenso; 6. Igualdade e inclusividade; 7. Efetividade e eficincia; 8. Prestao de conta. A estrutura da Governana Corporativa: * CEO (Diretor Executivo) Responsvel pela avaliao da diretoria e presta contas ao conselho de administrao; * Conselho fiscal Indicado pelos acionistas e deve acompanhar a auditoria independente; * Auditoria independente Verifica as demonstraes financeiras. Com a quebra da bolsa de valores de Nova York em 1929, as empresas foram obrigadas a serem mais transparentes com seus acionistas surgindo ento a necessidade de um cuidado maior por parte dos proprietrios assim surgindo o nascimento da Governana Corporativa. Deste modo ela est estreitamente relacionada com a transparncia e a tica nos negcios. 2.4 Governana de TI

Para o ITGI (IT Governance Institute), a Governana de T.I responsabilidade do conselho e dos executivos. parte integral da Governana Corporativa e consiste das estruturas e processos de organizao e liderana que garantam que a T.I sustente e expanda as estratgias e os objetivos da Organizao. A Governana de TI tem como principal objetivo atender s necessidades de negcio da organizao. Para que isso seja possvel, as organizaes esto exigindo que seus departamentos de TI estejam cada vez mais estruturados de modo a serem flexveis, eficientes, padronizados, com elevada qualidade no produto e no nvel de servio, alm de estarem constantemente buscando por reduo de custos e tempo. A Governana de TI apresenta quatro objetivos. O primeiro a busca efetiva do custo da TI, o segundo a utilizao efetiva dos recursos, o terceiro a utilizao de TI para o crescimento e o quarto trata do atendimento do negcio e a utilizao da TI para flexibilizar o negcio. Mudanas consideradas simples e pouco complexas pelas demais reas da organizao, tornam-se complexas e, por vezes, acabam impedindo a realizao de um negcio. Buscando obter uma flexibilidade maior, os autores abordam como alternativa a procura pela soluo mais simples para o ambiente organizacional em questo. Focar em solues simples, que no onerem a estrutura pode viabilizar uma srie de negcios para a organizao, garantindo assim o aumento do alinhamento com o negcio e uma maior efetividade da TI. As melhores prticas da Governana de TI so: * SOX; * COBIT; * CMMI; * ITIL. 2.4.1 SOX Empresas que buscam entrar na bolsa de valores de Nova York, necessrio ser aderente a lei Sarbanes - Oxley, tambm conhecida como SOX, uma lei americana promulgada em 30 de julho de 2002 pelos Senadores Paul Sarbanes e Michael Oxley para aperfeioar os controles financeiros das empresas que possuem capital na Bolsa de Nova York, incluindo algumas empresas brasileiras. O motivo que fez esta lei entrar em vigor foi a onda de escndalos financeiros americanos envolvendo as empresas Eron (energia), Worldcom (telecomunicaes), entre outras empresas, que geraram prejuzos financeiros atingindo milhares de investidores. A lei prev multas que variam de 1 milho 5 milhes de dlares e penas de recluso entre 10 a 20 anos para os CEOs (Diretores Executivos) e CFOs (Diretor Financeiro) das empresas. O objetivo da SOX aperfeioar os controles financeiros das empresas e apresentar eficincia na governana corporativa, a fim de evitar que aconteam novos casos de escndalos como os mencionados.

A SOX busca a transparncia na gesto financeira das organizaes, credibilidade na contabilidade, auditoria e a segurana das informaes para que sejam realmente confiveis. Com a aplicao desta lei haver a adequao dos controles internos da organizao a SOX, portanto: 1 Adequao dos controles internos da empresa; 2 Alinhamento da governana corporativa com os novos parmetros; 3 Conhecimento de todas as atividades de controle. Durante a implantao desta lei na organizao a TI tem importncia fundamental nesse processo. A TI responsvel pelo controle, segurana da informao e sistemas, portanto, dever estar alinhada com o negcio na adequao desta Lei para garantir s regras de transparncia fiscal e financeira. Para atender as necessidades da SOX, as reas de TI contam com alguns frameworks que se aplicados asseguram a conformidade com as melhores prticas de processos, tais como: * COBIT - Governana em TI; * ITIL - Gesto de servios de TI; * DRI - Plano de continuidade de negcios; * ISO 149977 (BS-7799) - gesto de segurana da informao/PSI; * CMMI - Gesto para o desenvolvimento de software. A cultura da empresa precisa ser alterada para atender os requisitos da SOX, no incio da adequao a esses novos padres podem aumentar os custos na empresa, porm a mdio e longo prazo esses controles passaro a ser um diferencial para atrair novos investimentos e segurana aos acionistas. 2.4.2 COBIT O COBIT (Control Objectives for Information and related Technology) um framework de controle para governana de TI atualizado, internacionalmente aceito para a adoo pelas organizaes e usado no dia-a-dia pelos gerentes de negcio, profissionais de TI e de auditoria. O COBIT no foca na execuo e sim no que precisa ser alcanado, ele focado no controle. Totalmente compatvel com outros frameworks e normas, tais como BSC, ITIL, CMMI, PMBOK, PRINCE2 e ISO.

PRINCIPAIS CARACTERSTICAS

FOCADO NO NEGCIO | - Olha para TI a partir da perspectiva do negcio;- Enxerga os requisitos do negcio e traduz isso para a TI;- Em todos os processos existe um link com as metas do negcio e as metas da TI; | ORIENTADO A PROCESSOS gerenciamento;| | - Organiza as atividades de TI em processos para facilitar seu

BASEADO EM CONTROLES | - Para cada processo de TI h objetivos de controle;- Estes controles so desenhados para dizer o que poder ser feito em cada processo. | ORIENTADO POR MTRICAS | - Fornece um conjunto de indicadores que permitem a organizao medir o desempenho das atividades, dos processos e o desempenho da TI como um todo;- O COBIT est agrupado em 4 domnios, os quais possuem 34 processos, e estes processos possuem 318 objetivos de controle. | Fonte: Disciplina Governana de TI 3 semestre 2011 |

Tabela 2.1: Principais caractersticas do COBIT.

DOMNIOS DO COBIT

Os domnios mapeiam as reas de responsabilidades tradicionais da TI, planejar, construir, executar e monitorar.

PLANEJAR E ORGANIZAR (PO) | - Cobre estratgias e tticas e se preocupa com a identificao da forma como a TI pode contribuir para alcanar os objetivos do negcio;- A realizao da viso estratgica precisa ser planejada, comunicada e gerenciada por vrias perspectivas diferentes;- Como a organizao e a infraestrutura de TI devem estar instaladas. | ADQUIRIR E IMPLEMENTAR (AI) | - Para realizar a estratgia de TI, solues precisam ser identificadas, desenvolvidas ou adquiridas, bem como implementadas e integradas com os processos de negcio;- Mudanas e manuteno dos sistemas existentes so cobertas por esse domnio para garantir que as solues continuam atendendo aos objetivos de negcio. | ENTREGAR E SUPORTAR (DS) | - Preocupa-se com as entregas reais dos servios necessrios que abrangem as operaes tradicionais sobre os aspectos de segurana e continuidade, incluindo tambm treinamento;- Para poder entregar os servios ser necessrio criar processos de suporte. Esse domnio inclui tambm o processamento de dados pelos sistemas de aplicaes. |

MONITORAR E CONTROLAR (ME) | - Processos de TI precisam ser avaliados e monitorados continuamente nos aspectos de qualidade e conformidade com base nos requisitos de controle;- Neste domnio gerenciamos o desempenho, monitoramos os controles internos, a conformidade regulatria e de governana. |

Tabela 2.2: Domnios do COBIT. Requisitos de negcios: * Eficcia; * Eficincia; * Confidencialidade; * Integridade; * Disponibilidade; * Confiabilidade; * Integridade.

Recursos de ti: * Aplicaes; * Informaes; * Infraestrutura; * Pessoas.

MODELOS DE MATURIDADE DO COBIT Os modelos de maturidade COBIT tm origem no CMMI, fornecem escalas que ajudam a medir o estgio em que cada um dos 34 processos se encontram na organizao.

A escala de maturidade possui 6 nveis: 0 Inexistente | Falta total de processos 1 Inicial | |

| A organizao reconhece que existe a necessidade de melhorias.

2 Repetvel | Os processos seguem procedimentos parecidos e so seguidos por diferentes pessoas, no existe treinamento formal e comunicao. | 3 Definido | Processos padronizados, comunicados e documentados |

4 Gerenciado | Os processos passam a ser medidos e monitorados, existe a tomada de decises para aes de correes. | 5 Otimizado | o mais alto nvel da maturidade, os processos so ajustados a melhoria contnua. |

Tabela 2.3: Nveis de Maturidade do COBIT.

A Matriz RACI (Responsible, Accountable, Consulted and Informed) usada dentro do COBIT para definir e distribuir as responsabilidades e papis envolvidos em um processo. A sigla significa: * R o responsvel pela execuo da tarefa; * A o responsvel pelos resultados; * C quem ser consultado e fornecendo conselhos; * I quem ser informado durante o processo. Desenvolvimento de Software | Diretor | Definir | I Projetar Desenvolver Testar | I Implantar | R/A |I |C |R |I |C | R/A |A |A |R |I |R |R |I |A | |I |I | |I | | | | Gerente | Analista | Financeira

Tabela 2.4: Matriz RACI. 2.4.3 CMMI O CMMI foi desenvolvido na dcada de 80 pela SEI (Software Engineering Institute), para avaliar a qualidade dos softwares desenvolvidos por empresas dos Estados Unidos.

O CMMI (Capability Maturity ModelIntegration) uma metodologia de melhores prticas. A proposta do CMMI prover a melhoria dos processos das organizaes para gerenciar, desenvolver e manter seus produtos (Softwares). reconhecido mundialmente por atestar a maturidade dos processos de desenvolvimento das organizaes. O CMMI tem como origens trs outros modelos de maturidade: * SW-CMM (SEI Software CMM); * EIA SECM (Electronic Industries Alliances's Systems Engineer Capability Model); * IPD-CMM (Integrated Product Development CMM). NVEIS DE MATURIDADE O modelo para avaliao da maturidade dos processos de software corresponde a5 nveis de maturidade:

Nvel 1 - Inicial | Organizaes nesse nvel possuem um processo mnimo de desenvolvimento, capaz de orientar as macro-tarefas no nvel operacional. | Nvel 2 - Repetvel | Organizao nesse nvel tem capacidade de gerenciar um ciclo de desenvolvimento, isto , um projeto. A maioria das empresas brasileiras est buscando certificao nesse nvel.| Nvel 3 - Definido | Organizaes orientadas a projetos. Alm dos fluxos de atividades, gerenciam os aspectos organizacionais, tcnicos e de integrao de equipes e fornecedores em funo da definio do processo. | Nvel 4 - Gerenciado | Gerencia o processo com mtricas quantitativas atravs do tempo. Conseguem avaliar o desempenho dos vrios ciclos de desenvolvimento e comparar seus indicadores, obtendo previsibilidade. | Nvel 5 - Otimizado | Organizaes nesse nvel controlam e avaliam os processos quantitativamente, podendo intervir em sua especificao para otimiz-lo continuamente. o mais alto nvel de maturidade definido pelo CMMI. |

Tabela 2.5: Nveis de maturidade do CMMI. ESCOPO DE AVALIAO A avaliao pode ser relativa a uma determinada unidade de negcios, e no empresa como um todo, ou seja, empresa pode prestar servios de desenvolvimento e manuteno, avaliando apenas a um desses servios.

Toda avaliao conduzida por um assessor autorizado pela SEI. TIPOS DE AVALIAO * SCE (Software Capability Evaluation) Este mtodo utilizado para a seleo de fornecedores de softwares, acompanhamento do processo de contratao, e avaliao de processos internos. A orientao deste mtodo para a tomada de decises quanto seleo de fornecedores, melhoria do desempenho da gerncia de contratos e direcionamento para rea de aquisies da organizao. * SCAMPI (Standard CMMI Appraisal Method for Process Improvement) So os indicados para empresas com foco na prestao de servios. Basicamente o SCAMPI verifica as seguintes fontes de informao: * Instrumentao aplicada ao processo (tecnologia, infra, guias de referncia, etc.); * Entrevistas e questionrios aplicados equipe; * Apresentaes da equipe para os auditores; * Documentao gerada pelo processo; TEMPO MDIO DE IMPLANTAO NVEL | TEMPO | DESAFIOS |

Do nvel 1 para o nvel 2 | 22 meses | - A implantao do CMMI um programa de longo prazo;- Necessidade de rever os processos internos;- Alta administrao compromissada com a qualidade;- Equipes dedicadas. | Do nvel 2 para o nvel 3 Do nvel 3 par ao nvel 4 Do nvel 4 para o nvel 5 | 21 meses | 25 meses | 15 meses | | | | | | |

Dados de acordo com o SEI de abril/2003.

Tabela 2.6: Tempo mdio de implantao do CMMI. 2.4.4 ITIL O ITIL (Information Technology Infrastructure Library) uma referncia para gerenciamento de processos de TI, foi criado pela secretaria de comrcio (Office of Government Commerce, OGC) da Inglaterra, a partir de pesquisas realizadas por consultores, especialistas e doutores, para desenvolver as melhores prticas para a gesto da rea de TI nas empresas privadas e pblicas.

 importante ressaltar que o ITIL no uma metodologia, um conjunto de melhores prticas para a gesto de servios em TI e para o alinhamento desta rea com os negcios da empresa, cada empresa pode adaptar o uso das prticas ao seu contexto e momento.

O foco deste modelo descrever os processos necessrios para gerenciar a infraestrutura de TI com eficincia e eficcia de modo a garantir os nveis de servio acordados com os clientes internos e externos. O ITIL composto por mdulos, sendo os mais importantes o Suporte de Servios e o Entrega de Servios. CARACTERSTICAS DO ITIL * Modelo de referncia para processos de TI no proprietrio; * Adequado para todas as reas de atividade; * Independente de tecnologia e fornecedor; * Baseado nas melhores prticas; * Referncia para a implementao de processos de TI; * Checklist testado e aprovado; * O que fazer e o que no fazer. CONFLITOS NAS ORGANIZAES COM A REA DE TI * Proviso de servios inadequada; * Falta de comunicao e entendimento com os usurios; * Gastos excessivos com infraestrutura; * Justificativas insuficientes ou pouco fundamentadas para os custos da proviso dos servios; * Falta de sintonia entre mudanas na infraestrutura e os objetivos de negcio; * Entrega de projetos com atrasos e acima do oramento. DESAFIOS DO ITIL * Incrementar a efetividade dos servios; * Estender o ciclo de vida da tecnologia; * Remover gargalos; * Racionalizar a complexidade; * Assegurar a aderncia evoluo dos negcios.

RESULTADOS DO ITIL * Fortalecimento dos controles e da gesto dos ambientes de TI; * Orientao a processos com significativa reduo nos tempos de execuo e distribuio de servios; * Diminuio gradativa da indisponibilidade dos recursos e sistemas de tecnologia da informao, causados por falhas no planejamento das mudanas e implantaes em TI; * Elevao dos nveis de satisfao dos clientes internos e externos com relao disponibilidade e qualidade dos servios de TI; * Reduo dos custos operacionais de TI; * Reconhecimento da capacidade de gerenciamento pelos acionistas, colaboradores e clientes. 2.4.5 Outsourcing O outsourcing uma das modalidades que mais tem crescido na rea de TI. Seu conceito vem evoluindo ao longo dos anos, tornando-se um importante fator de competitividade para as empresas. Numa traduo simplificada, nada mais do que uma terceirizao de servios. Com a terceirizao da TI, as empresas podem dedicar-se integralmente ao foco principal das suas atividades chaves, terceirizando apenas atividades intermedirias, favorecendo uma melhor qualidade dos servios e maior disponibilidade do pessoal interno da empresa. A terceirizao trs vantagens e benefcios como a reduo de custos, melhor abordagem de negcio e melhoria da qualidade do servio prestado buscando quais as melhores prticas e as maneiras de aderir terceirizao, como escolher os parceiros adequados e de que forma medir seus resultados. Na relao da TI com o outsourcing, mais do que um contrato, preciso estabelecer uma relao de parceria de negcios que traga uma vasta gama de habilidades e pontos fortes. Uma boa consultoria pode determinar o que melhor para o cliente. Um especialista em TI bem preparado tem condies de avaliar e planejar como a tecnologia vai apoiar a evoluo dos negcios da empresa. Por ter a tecnologia como seu negcio principal e o custo de infraestrutura e mo-de-obra compartilhada entre outros contratantes, a empresa de outsourcing tende a ter uma maior capacidade evolutiva. A incorporao do SLA (Service Level Agreement) discrimina as garantias de qualidade, quantidade, modalidade e preciso dos diferentes servios a serem oferecidos. Vale a pena avaliar a performance do outsourcing com base num amplo conjunto de resultados e no limitar a avaliao apenas ao fator "reduo de custos". Os projetos podem ser customizados e at mesmo exclusivos. O pagamento pode ser feito sob demanda, ou seja, a empresa contratante s deve pagar pelo servio consumido. 2.4.6 SLA

O SLA (Service Level Agreement) tem como objetivo firmar um acordo de nvel de servio. a chave para iniciar um relacionamento de sucesso com o cliente. Atravs desse documento o prestador de servio traduz as expectativas do cliente em objetivos a serem entregues, porm, penalidades podero ser aplicadas se esses objetivos no forem alcanados. Para um SLA bem definido, devem-se levar em considerao os seguintes aspectos: * Conhecer as necessidades dos usurios do servio; * Entender como o servio suportar os negcios do cliente bem como os impactos que lhes poder causar; * Estabelecer nveis alcanveis e que possam, de fato, ser medidos; * Criar um modelo de custos que suporte os nveis de servio oferecidos ao cliente; * Especificar nveis de servio para todos os componentes do servio principal, incluindo as partes terceirizadas; * Definir acordos com as reas internas e externas responsveis pela execuo do servio. A eficcia na definio e gesto do SLA a base para a entrega de servios com qualidade. A formalizao das expectativas do cliente e o entendimento claro entre as partes do que foi contratado e o que ser entregue esclarece a percepo sobre o servio, tornando-o mensurvel e objetivo, devendo ir alm da pura medio e ser um instrumento de suporte melhoria contnua dos servios e dos processos de negcio nas empresas. 2.5 Governana Corporativa versus Governana de TI EQUIPE EXECUTIVA | |

GOVERNANA CORPORATIVAMECANISMOSAtivos fsicos, humanos e financeiros. GOVERNANA DE TIMECANISMOSAtivos de informaes e TI. |

Tabela 2.7: Governana Corporativa versus Governana de TI. A Governana de TI no uma rea isolada na empresa, ou seja, no subordinada, parte integrante da Governana Corporativa, mantendo o sincronismo necessrio para o alcance dos objetivos, permitindo a criao de valor e garantindo que no sejam feitos investimentos em projetos que no estejam alinhados com os objetivos do negcio e que os mecanismos de controle e gesto da TI estejam implantados adequadamente. A TI faz parte da equipe executiva da empresa, sendo esta responsvel pelo alinhamento estratgico entre a Governana Corporativa e a Governana de TI. As responsabilidades na Governana de TI fazem parte do framework de Governana Corporativa e deve fazer parte tambm da agenda de planejamento estratgico dos diretores da empresa, alis, qualquer planejamento estratgico que a empresa venha a fazer a TI deve ser comunicada. Abaixo dessa equipe executiva, existem os principais ativos da companhia:

* Ativos da Governana Corporativa ativos fsicos, humanos e financeiros; * Ativos da Governana de TI ativos de informao e TI. Na tomada de deciso necessrio fazer uma anlise de risco sobre um processo que deve ser extremamente estruturado para gerenciar e controlar as iniciativas de TI nas empresas para garantir o retorno dos investimentos adicionando uma melhoria nos processos empresariais. nesse cenrio ento, que a Governana de TI aparece com importncia vital para o negcio. Existem vrias ferramentas como, por exemplo, o BSC (Balanced Scorecard), COBIT e ITIL que, combinadas podem ser usadas como um mecanismo de medio e gerenciamento sistmico poderoso para suportar a implantao dos processos de Governana de TI e o necessrio alinhamento entre TI e negcio. O alinhamento entre TI e os objetivos organizacionais tem sido observado como um dos principais fatores de agregao de valor e de retorno de investimentos (ROI). O primeiro objetivo a busca efetiva do custo da TI (a utilizao de TI para o crescimento e atendimento do negcio) seguida pela utilizao efetiva dos recursos (a utilizao da TI para flexibilizar o negcio). Mudanas consideradas simples e pouco complexas pelas demais reas da organizao, tornam-se complexas e, por vezes, acabam impedindo a realizao de um negcio. Buscando obter uma flexibilidade maior, os autores abordam como alternativa a procura pela soluo mais simples para o ambiente organizacional em questo. Focar em solues simples, que no onerem a estrutura pode viabilizar uma srie de negcios para a organizao, garantindo assim o aumento do alinhamento com o negcio e uma maior efetividade da TI. 3. SISTEMAS PARA INTERNET E SOFTWARE LIVRE 3.1 Arquitetura Cliente/Servidor A arquitetura Cliente/Servidor refere-se ao compartilhamento do trabalho entre o cliente e o servidor de forma que cada qual cuida da tarefa que pode realizar mais eficientemente. uma arquitetura de rede, onde existem dois mdulos bsicos na rede: o Servidor e os Clientes. O Servidor alguma mquina da rede que responsvel por servir os Clientes da rede com aquilo que solicitado. Os Clientes so as mquinas que solicitaram informaes que esto contidas no Servidor. no servidor que normalmente ficam os sistemas mais pesados da rede, tais como o banco de dados. As mquinas clientes so menos poderosas, pois no rodam aplicativos que requerem tantos recursos das mquinas. 3.2 Aplicaes em quatro camadas * Cliente: Navegador; * Apresentao: Servidor Web, onde sero feitas as alteraes de interface;

* Lgica (Regras do Negcio): Servidor de Aplicaes, onde sero feitas as alteraes nas regras do negcio, quando necessrias; * Dados: Servidor de Banco de Dados, com todas as informaes necessrias.

Figura 3.1: Arquitetura Cliente/Servidor em quatro camadas Para acessar a aplicao, o cliente acessa o endereo da aplicao utilizando o seu navegador, por exemplo, http://www.empresa-xy.com/sistemas/rh.aspx. Todo o acesso do cliente ao Banco de Dados feito de acordo com as regras contidas no servidor de Aplicaes. O cliente no tem acesso ao Banco de Dados, sem antes passar pelo servidor de Aplicaes. Com o deslocamento da camada de apresentao para um servidor Web resolvemos o problema de termos que atualizar a aplicao em centenas ou milhares de computadores cada vez que uma interface precisar de alteraes. Neste ponto, a atualizao de aplicaes uma tarefa mais gerencivel, muito diferente do que acontecia no caso do modelo de duas camadas. Os servidores de Aplicao, Web e Banco de Dados no necessitam serem servidores separados, isto , uma mquina pode fazer o papel de cada um dos servidores. O conceito de servidor de Aplicao, servidor Web ou servidor de Banco de Dados um conceito relacionado com a funo que o servidor desempenha. Podemos ter em um mesmo equipamento estes diferentes servidores. Claro que questes de desempenho devem ser levadas em considerao. Tambm podemos ter a funcionalidade do servidor de Aplicaes distribuda atravs de vrios servidores, com cada servidor tendo alguns componentes que formam parte da funcionalidade da aplicao. Este modelo onde temos componentes em diversos equipamentos conhecido como Modelo de Aplicaes Distribudas. Tambm podemos colocar os componentes em mais do que um servidor para obtermos um melhor desempenho, ou redundncia, no caso de um servidor falhar. 3.3 Sistemas distribudos Um sistema distribudo aquele que definido como um conjunto de unidades de processamento independentes, que atravs da troca de comunicao e gerenciamento de sincronizao pode processar uma aplicao em diferentes localidades em sistemas com caractersticas prprias diferentes, dando a impresso ao usurio que toda a aplicao gerenciada por um sistema nico. Quando falamos em sincronizao, temos o conceito de sincronizao em um sistema centralizado e no sistema distribudo. No sistema centralizado a sincronizao feita atravs do compartilhamento de reas de memria, j no sistema distribudo a sincronizao ocorre atravs da troca de mensagens. A aplicao no sistema distribudo pode ser dividida em diferentes partes e ser processada em diversos ncleos de processamento.

O objetivo criar a iluso que a aplicao ou as aplicaes esto sendo processadas em um nico sistema, permitindo a sensao que tudo isso ocorre sem o compartilhamento de reas de memria, no entanto, a sincronizao feita a partir de trocas de mensagens. Faz parte do objetivo a situao da aplicao ser processada de modo que o ambiente que opera, fornea situaes favorveis ao compartilhamento de recursos, sabendo que diferentes recursos estaro disponveis em unidades de processamento diferentes.

* Deve fornecer mecanismos para sincronizar processos; * Gerenciar a comunicao entre processos; * Lidar com o problema de deadlock; * Tratar as vrias falhas que no so encontradas em um sistema centralizado. CARACTERSTICAS PRINCIPAIS DE UM SISTEMA DISTRIBUDO * Compartilhamento de recursos; * Estendibilidade; * Escalabilidade; * Tolerncia a falhas; * Transparncia; * Heterogeneidade. VANTAGENS DOS SISTEMAS DISTRIBUDOS * Compartilhamento de recursos; * Velocidade; * Confiabilidade; * Comunicao. 3.4 Conceitos bsicos de Software Livre Software Livre qualquer programa de computador que pode ser usado, copiado, estudado, modificado e redistribudo sem nenhuma restrio. A liberdade de tais diretrizes central ao conceito, o qual se ope ao conceito de software proprietrio, mas no ao software que vendido almejando lucro (software comercial). A maneira usual de distribuio de software livre anexar a este uma licena de software livre e tornar o cdigo fonte do programa disponvel. Software Livre o software disponibilizado, gratuitamente ou comercializado, com as premissas de liberdade de instalao; plena utilizao; acesso ao cdigo fonte; possibilidade de modificaes/aperfeioamentos para necessidades especficas; distribuio da forma original ou modificada, com ou sem custos. So

softwares com cdigo-fonte aberto, ou seja, com seus cdigos de criao disponveis ao usurio para que qualquer pessoa possa modific-los e adapt-los s suas necessidades e o resultado de aperfeioamentos desse software pode ser liberado e redistribudo para outros usurios, sem a necessidade de permisso do fornecedor do cdigo original. Os softwares livres do livre acesso aos seus cdigos-fontes e so regidos pelas quatro leis bsicas da liberdade definidas pela FSF (Free Software Foundation). VANTAGENS | RISCOS |

- Custo social baixo;- No se fica refm de tecnologia proprietria;- Independncia de fornecedor nico;Desembolso inicial prximo de zero;- Robustez e segurana;- Possibilidade de adequar aplicativos e redistribuir verses alteradas;- Suporte abundante e gratuito;Sistemas e aplicativos geralmente muito configurveis. | - Plataformas ainda muito novas e talvez deixem de existir;- Falta de continuidade e atualizao;- Pulverizao de fornecedores;Parcerias de empresas como a Oracle, Sun e IBM do um pouco mais de garantia, mas ainda h o risco de, a certa altura, elas conclurem que aquilo no rentvel e tomarem outro rumo. |

Tabela 3.1: Vantagens e desvantagens do software livre. Os desafios e pontos fracos do uso de softwares livres muitas vezes se confundem assim como ao utilizar qualquer outro tipo de ferramenta de TI. Exige-se pessoal capacitado e treinamento para os usurios dos softwares. Por mais simples que as verses se tornem e/ou mais semelhantes que fiquem quando comparadas a outros desenvolvidos por grandes empresas, as pessoas que muitas vezes necessitam do software precisam passar por uma capacitao que vise reeducao para o uso destas novas ferramentas. Os pontos so fracos inerentes s liberdades j que so softwares modificveis, so contornados na maioria das vezes pelo uso cada vez mais comum de pessoal especfico, qualificado para trabalhar com tais ferramentas sem deixar passar os riscos correntes no uso dessas liberdades proporcionadas. 3.5 Novos modelos de Negcio na Internet * LOJAS VIRTUAIS: Amazon, Cisco, Submarino, Americanas.com, etc.; Realizam vendas pela Internet para um segmento de seus clientes oferecendo produtos, servios e informaes tanto no mercado B2B quanto no B2C. * INFOMEDIRIOS: Yahoo, IG, UOL, AOL, Globo.com, etc.; Atuam como intermedirias na distribuio e venda de contedo, informaes, entretenimento ou experincias agregando valor atravs da atrao de grandes nmeros de usurios. * BROKERS: Mercado Livre, Lokau, Arremate, Webmotors, Planeta Imvel, etc.;

Atuam como brokers ou intermedirios na distribuio e venda de contedo, informaes, conhecimento ou experincias, adicionando valor a uma atividade ou transao necessria para a realizao da venda para um dado segmento de clientes. * AVALISTAS DE CONFIANA: Certising, Verising, ICVerify, CyberCash, Tradesafe etc.; Criam uma atitude de credibilidade entre vendedores e compradores oferecendo um ambiente seguro no qual se pode estabelecer consentimentos, permisses e acordos explcitos entre compradores e vendedores, para que possam realizar trocas de valores com garantia de segurana e privacidade. Existem avalistas de pagamento e avalistas de confiana. * CAPACITADORES DE E-BUSINESS: Federal Express, Correios, DoubleClick, Onsale etc.; Criam e mantm uma infraestrutura, real ou virtual, na qual provedores de produtos e servios podem realizar transaes de modo seguro e confivel na Internet. * PROVEDORES DE INFRAESTRUTURA (E-MARKETSPACE): BcomB, Mercado Eletrnico, Aerochain etc. Agregam comunidades de interesse em torno de uma infraestrutura comum, atravs da Internet, oferecendo servios que viabilizam as transaes entre Novos Modelos de Negcio na Internet, compradores e vendedores de cada rea de interesse e englobam todos os servios mencionados anteriormente. 3.6 Comrcio Eletrnico O comrcio eletrnico ou e-commerce a compra e venda de mercadorias ou servios por meio da internet, onde as chamadas Lojas Virtuais oferecem seus produtos e formas de pagamento online. O comrcio eletrnico um meio facilitador dos negcios, tornando o processo de venda fcil, seguro, rpido e transparente reduzindo os custos das empresas que atuam neste segmento e estimulando a competitividade, ou seja, a produo, promoo, venda e distribuio de produtos por meio de redes de telecomunicao. * E-COMMERCE: Marketing, vendas, compra de produtos e servios pela internet; * E-BUSINESS: Aumenta o desempenho do negcio por meio de conectividade. Conecta as cadeias de valores entre negcio (B2B) e entre negcio e consumidor (B2C). VANTAGENS * Maior possibilidade de comparao de preos; * Grande variedade de produtos. DESVANTAGENS

* No capaz de reproduzir a funo social dos shoppings; * Alto custo para vender online materiais pesados e difceis de transportar.

3.7 Marketing na Internet O marketing na internet qualquer esforo promocional realizado por meio da web, ou seja, o marketing de produtos ou servios na Internet. Esse marketing pode ser feito de vrias formas, onde o custo, o retorno a longo prazo e o trabalho de gerenciamento varia de acordo com cada alternativa ou opo escolhida. 3.8 Sites de buscas Os Sites de busca so de longe a forma mais popular de localizao de informaes e produtos na web. O ponto forte dessa estratgia o fato que a maior parte dos sites de busca so gratuitos, embora haja uma tendncia muito forte de cobrana por parte dos grandes sites que prestam esse servio. 3.9 E-mail marketing As pesquisas de comportamento do usurio indicam que receber e enviar e-mails disparado a atividade mais realizada pelos internautas seguida de longe pela leitura de notcias e diverso. A grande fora do E-mail Marketing sua agilidade como canal de comunicao com o cliente que autorizou a abertura desse canal. A comunicao autorizada possibilita o conhecimento e o melhor atendimento das necessidades do cliente. 3.10 Programa de fidelizao Um programa de fidelizao a montagem de rede de sites que divulgam o negcio e enviam potenciais clientes para o site do comerciante em troca de comisses sobre as vendas. 3.11 Links patrocinados Os anncios so a pea fundamental na disputa pelo cliente e as empresas reservam parte expressiva de seus oramentos em anncios na TV, Rdio e mdia impressa. A grande novidade so os links patrocinados - anncios pagos em sites de busca - que esto ganhando fatias expressivas dos recursos destinados publicidade online. 3.12 Compra coletiva O sistema de divulgao atravs da compra coletiva a mais nova forma de divulgao da Internet. Trata-se de uma parceria entre o comerciante e o site de compra coletiva para a divulgao de uma oferta com grande taxa de desconto (geralmente em torno de 60%). As ofertas duram um perodo curto de tempo, mas o suficiente para trazer uma grande quantidade de novos visitantes para o comrcio. O site de compra coletiva cobra cerca de 30% da receita de vendas e o principal retorno do comerciante so os clientes que retornam ao estabelecimento aps conhec-lo. 3.13 Banners O Banner uma forma interessante e de fcil operacionalizao para a gerao de trfego e divulgao de marca, desde que observada relao custo/beneficio, ou seja, o retorno em termos de visitas trazidas pelo banner, quantidade de impresses e o investimento realizado para sua publicao. Existem 4 tipos de banners:

* Esttico; * Animado; * Interativo; * Anncios pop-ups. 3.14 Redes Sociais A agilidade na propagao de informaes e o grande volume de usurios tornaram o twitter um alvo para estratgias de marketing digital assim como ocorre em outras redes sociais como o orkut e o facebook. Em geral a estratgia consiste em gerar um fato novo que atraia a ateno dos seguidores e os motive a visitar o site; estimular uma determinada ao que pode ser uma compra, o preenchimento de um cadastro, download de um arquivo, entre outros. 4. QUALIDADE DE SOFTWARE A qualidade um termo subjetivo e que varia de pessoa para pessoa, ou seja, no h uma definio exata. Um cliente pode avaliar a qualidade de um produto ou servio pela sua satisafao ou simplismente pelo preo. Um produtor pode definir como qualidade oferecer um produto ou servio conforme as exigncias dos clientes. Existem 3 tipos de vises diferentes a respeito dos atributos da Qualidade de Software: VISES E ATRIBUTOS VISO | ATRIBUTOS USURIO | |

| Facilidade de uso, desempenho do software, preo, etc.

DESENVOLVEDOR clientes. |

| Facilidade de manuteno e conformidade com os requisitos dos

ORGANIZAO | Cumprimento dos prazos, produtividade, custos.

Tabela 4.1: Vises e atributos da qaulidade. Processos de Software so roteiros de elaborao de software que devem contemplar fases, subfases e pontos de avaliao da qualidade. ALGUNS TIPOS DE AVALIAO DE SOFTWARE ALTERAO | Manuteno, Flexibilida, Estabilidade. |

TIPOS DE OPERAES | Correo, Confiabilidade, Eficincia, Integridade, Usabilidade. | ADAPTAO A NOVOS AMBIENTES | | Portabilidade, Reusabilidade, Interoperabilidade.

Tabela 4.2: Alguns tipos de avaliao de software. USO DO PRODUTO CORRETITUDE | Cumpre as especificaes e objetivos do cliente. EFICINCIA | Requistos necessrios para o funcionamento. | | |

INTEGRIDADE | Controle de acesso aos dados. USABILIDADE | Facilidade de uso. |

Tabela 4.3: Uso do produto software.

ALTERAO DO PRODUTO MANUTENSO | Localizao e reparo de erros. | FLEXIBILIDADE | Modificao. | TESTABILIDADE | Testes do produto. |

Tabela 4.4: Alterao do produto software. TRANSIO DO PRODUTO PORTABILIDADE REUSABILIDADE | Facilidade de adaptar o produto em outros ambientes. | Reutilizao do programa ou partes dele. | |

INTEROPERABILIDADE | Acoplar um sistema a outro |

Tabela 4.5: Transio do produto software. 4.1 Qualidade do Processo versus Qualidade do Produto Investir em um processo de qualidade altomaticamente se garante a qualidade do produto. Os estudos sobre qualidade de software so voltados para o melhoramento dos processos de desenvolvimento de software. Os processos de desenvolvimento de software envolvem profissionais capacitados, ferramentas, procedimentos e mtodos.

Figura 4.1: Ciclo de desenvolvimento do software. 4.2 ISO Nos dias atuais a qualidade dos produtos se tornou uma obrigao, empresas que buscam a satisfao dos seus clientes precisam investir na qualidade de seus processos. Investir em normas ISO (International Organization for Standardization) no mais uma vantagem competitividade e sim quase uma obrigao. uma maneira de se adequar as exigncias do mercado, embora para alguns clientes ainda seja um diferencial na hora de escolher um produto. Exitem empresas que buscam parceiros de negcios tambm aderentes a alguma norma de qualidade, pois a qualidade do seu produto final depende da qualidade do produto do seu parceiro de negcio. 4.3 ISO/IEC 9126 A ISO/IEC 9126 uma norma para qualidade de software que prope um enquadramento no qual definido um conjunto de caractersticas que permitem avaliar a qualidade do produto software. composta das seguintes partes: * ISO/IEC 9126-1 - Modelo de Qualidade; * ISO/IEC 9126-2 - Mtricas Externas; * ISO/IEC 9126-3 - Mtricas Internas; * ISO/IEC 9126-4 - Mtricas de Qualidade em Uso 9126-1: Modelo de Qualidade Este Modelo de Qualidade se divide em duas partes: * Qualidade interna e externa; * Qualidade no uso. A Qualidade interna so caractersticas que avaliam o produto segundo uma viso interna da empresa e define estratgias de desenvolvimento e critrios para a avaliao e verificao durante o desenvolvimento do software. A Qualidade externa so caractersticas que avaliam o produto segundo uma avaliao externa da empresa quando o software executado e avaliado atravs de testes em ambientes simulados ao do cliente. A Qualidade no uso uma viso do usurio sobre a qualidade do produto em uso em um ambiente especfico. medida em relao ao resultado da utilizao e suas caractersticas representam o efeito da qualidade interna e externa. 9126-2: Mtricas Externas

Tem o propsito de determinar a taxa de implementao das funes definidas na especificao de requisitos. medida atravs de relatrios de avaliao e especificao de requisitos. 9126-3: Mtricas Internas As mtricas so mensuradas atravs da funcionalidade (adequao ao uso), confiabilidade (tolerncia a falhas), usabilidade (facilidade de aprendizagem), eficincia (comportamento em relao ao tempo), manuteno (facilidade de modificao) e portabilidade (adaptao a outros ambientes). 9126-4: Mtricas de Qualidade em Uso mensurada atravs da eficincia nas tarefas que esto completas corretamente, a frequncia com a qual aparecem erros, o tempo que a tarefa leva para se tornar completa, a eficincia da tarefa em relao ao uso, a produtividade/econmia com os custos dos utilizadores, a proporo da produtividade em relao ao tempo que se gasta para desenvolver aes produtivas e a frequncia com que se utiliza a ajuda do software. 4.4 ISO 25000 A ISO 25000 ou Square (Software Product Quality Requirements and Evaluation) uma das normas mais importantes em relao caracterizao e medio de qualidade do produto software. composta das normas ISOs 9126 e 14598.

ISO 25000 (Square)

9126-1 | Modelo de qualidade | 9126-2 | Mtricas externas 9126-3 | Mtricas internas | | |

9126-4 | Mtricas de qualidade em uso 14598-1 14598-2 14598-3 14598-4 14598-5 14598-6 | Guia de avaliao |

| Planejamento e Gerenciamento de avaliaes | | Processo de avaliao para desenvolvedores | | Processo de avaliao para adquirentes | Processo de avaliao para avaliadores | Documentao de mdulos de avaliao | | |

Tabela 4.6: Composio ISO 25000.

A reorganizao da norma est dividida em cinco tpicos e cada diviso compe um conjunto de documentos que trata de um assunto independente. REORGANIZAO DA NORMA | Requisitos de qualidade | Modelo de qualidade | Avaliao | |

| Gerenciamento de qualidade | | Medies | |

Tabela 4.7: Reorganizao da norma ISO 25000. * Gerenciamento de qualidade esta diviso est voltada a todos os possveis usurios dela (gerentes, avaliadores, programadores, etc.); * Modelo de qualidade Corresponde a ISO 9126-1 e define um modelo de hierarquia das caractersticas de qualidade descrevendo o que se espera do produto; * Medio Descreve diversos aspectos relacionados realizao dessa tarefa e prope tambm uma srie de mtricas que podem ser utilizadas ou adaptadas a uma necessidade especfica; * Requisitos de qualidade Especifica valores para garantir a qualidade; * Avaliao Avalia a qualidade a partir de medies confrontadas a um modelo definido pelo usurio. 4.5 ISO 9000-3 Fornece diretrizes para a aplicao da norma ISO 9001 para empresas de desenvolvimento, suporte e manuteno de software. Sua aplicao independe de tecnologia, modelos de ciclo de vida, processos de desenvolvimento, sequncia de atividades ou estrutura organizacional. 4.6 ISO 9001 A norma ISO 9001 um padro internacional que especifica os requisitos necessrios para um Sistema de Gesto da Qualidade para apresentar uma maior compatibilidade com a famlia da ISO 14000. aplicvel a empresas que atuam em projeto, desenvolvimento, produo, instalao e assistncia tcnica. Essa norma apresenta oito princpios para a gesto da qualidade: 1. Foco no cliente atender as necessidades dos clientes; 2. Liderana praticar a habilidade de liderana dentro da empresa; 3. Envolvimento das pessoas envolver as pessoas de todos os nveis nas tomadas de decises;

4. Abordagem de processo as atividades e os recursos relacionados devem ser gerenciados como um processo; 5. Abordagem sistmica para a gesto identificar, entender e gerenciar processos interrelacionados no sentido de atingir os objetivos; 6. Melhoria contnua - a melhoria contnua da organizao deve ser o seu objetivo permanente; 7. Abordagem de fatos para a tomada de deciso - decises eficazes so baseadas na anlise de dados e informaes; 8. Benefcios mtuos nas relaes com fornecedores a relao de benefcios mtuos aumenta a habilidade de ambos em agregar valor. 4.7 ISO 12207 O objetivo da ISO/IEC 12207 estabelecer uma estrutura comum para os processos de ciclo de vida de software. Os processos da ISO/IEC 12207 so agrupados de acordo os objetivos principais do ciclo de vida de software. Este agrupamento possui 3 classes de processos: Processos Fundamentais, Processos de Apoio e Processos Organizacionais. * Processos Fundamentais - so basicamente todas as atividades que a empresa executa nos servios de desenvolvimento, manuteno ou operao de software; * Processos de Apoio processos para auxilio de outro processo; * Processos Organizacionais auxiliam no gerenciamento dos processos de toda a organizao. 4.8 CMMI O CMMI (Capability Maturity Model Integration) um conjunto de melhores prticas que prover a melhoria dos processos das organizaes para gerenciar, desenvolver e manter seus produtos (Softwares). Possui 5 nveis de maturidade os quais so: * Nvel 1 Inicial; * Nvel 2 Repetvel; * Nvel 3 Definido; * Nvel 4 Gerenciado; * Nvel 5 Otimizado. 4.9 MPS.BR O MPS.BR um programa para Melhoria de Processo do Software Brasileiro, est em desenvolvimento desde dezembro de 2003 e coordenado pela Associao para Promoo da

Excelncia do Software Brasileiro (SOFTEX). Busca-se que o MPS.BR seja adequado ao perfil de empresas com diferentes tamanhos e caractersticas, pblicas e privadas, seja compatvel com os padres de qualidade aceitos internacionalmente e que tenha como pressuposto o aproveitamento de toda a competncia existente nos padres e modelos de melhoria de processo j disponveis. Possui 7 nveis de maturidade: NVEL | DEFINIO A B | PROCESSOS | | Anlises de Causas de Problemas e Resolues |

| Em Otimizao

| Gerenciado Quantitativamente |

| Gerncia de Projetos GPR (evoluo)

C | Definido | Gerncia de Riscos GRIDesenvolvimento para Reutilizao DRUGerncia de Decises GDE | D | Largamente Definido | Verificao - VERValidao - VALProjeto e Construo do Produto - PCPIntegrao do Produto - ITPDesenvolvimento de Requisitos - DRE | E | Parcialmente Definido | Gerncia de Projetos - GPR (evoluo)Gerncia de Reutilizao GRUGerncia de Recursos Humanos GRHDefinio do Processo Organizacional DFPAvaliao e Melhoria do Processo Organizacional - AMP | F | Gerenciado | Medio MEDGarantia da Qualidade GQAGerncia de Portflio de Projetos GPPGerncia de Configurao GCOAquisio - AQU | G GPR | Parcialmente Gerenciado | | Gerncia de Requisitos GREGerncia de Projetos -

Fonte: Portal da RENAPI Rede de Pesquisa e Inovao em Tecnologias Digitais

Tabela 4.8: Nveis de maturidade MPS.BR. Comparando os sete nveis de maturidade do MPS.BR com o CMMI, conforme a figura 4.2, temos:

Figura 4.2: Comparao dos nveis do MPS.BR com o CMMI. 4.10 SPICE ISO 15504 A ISO/IEC 15504 ou SPICE (Software Process Improvement and Capability Determination) define um modelo de referncia que identifica e descreve um conjunto de processos para a boa prtica da engenharia de software e define seis nveis de capacidade que podem ser utilizados como mtrica para avaliar os processos de uma empresa e tambm um guia para a orientao da melhoria.

Os nveis de capacidade so: * 0: Incompleto h falhas gerais no propsito dos processos; * 1: Executado o propsito dos processos so geralmente alcanado; * 2: Gerenciado os processos so realizados de acordo com procedimentos especficos; * 3: Estabelecido os processos so definidos, executados e gerenciados; * 4: Previsvel os processos so executados dentro de controles definidos e as mtricas de desempenho so coletadas e analisadas; * 5: Otimizando melhorias contnuas dos processos. O Modelo de referncia SPICE define duas dimenses como base para o processo de avaliao: * Avaliao do processo define um conjunto de processos para a boa prtica da engenharia de software; * Avaliao da capacidade baseia o modelo de avaliao conforme a ISO 12207. Esta norma est sendo desenvolvida desde 1993 pela ISO em conjunto com a SPICE com base nos modelos j existentes como ISO 9000 e CMM. A avaliao de processo de software, segundo a norma, uma investigao e anlise disciplinada de processos selecionados de uma empresa em relao a um modelo de avaliao de processo. 5. GERENCIAMENTO DE PROJETOS DE TI O PMBOK (Project Management Body of Knowledge) um guia que descreve o conjunto de conhecimentos e as melhores prticas em Gerenciamento de Projetos. cedido gratuitamente aos membros do PMI (Project Management Institute) e para o seu programa de desenvolvimento profissional fornece a certificao PMP (Project Management Professional). O material genrico podendo ser aplicado em qualquer tipo de projeto. O PMBOK completo inclui prticas tradicionais comprovadas que so amplamente aplicadas, bem como, prticas inovadoras que esto surgindo na profisso. O guia tambm fornece um vocabulrio comum entre a profisso e a prtica para falar e escrever sobre gerenciamento de projeto. baseado em processos e sub-processos para descrever de forma organizada o trabalho a ser realizado durante um projeto. As reas de conhecimento do PMBOK caracterizam os principais aspectos envolvidos em seu gerenciamento: Integrao, Escopo, Tempo, Custos, Qualidade, Recursos Humanos, Comunicao, Riscos e Aquisies. Conforme a figura 5.1 os principais determinantes para o objetivo de um projeto representado por Escopo, Tempo, Custos e Qualidade.

Figura 5.1: reas de conhecimento do PMBOK.

* Integrao - Identificar, definir, combinar, unificar e coordenar os processos de gerenciamento; * Escopo - Assegurar que o escopo do projeto cumpra somente e apenas o necessrio para o seu trmino; * * * * * * * Tempo - Gerenciar a pontualidade das atividades; Custos - Gerenciar os custos para que o oramento no saia da linha de base; Qualidade - Gerenciamento da qualidade; Recursos Humanos - Organizar e gerenciar a equipe; Comunicao - Gerenciar as informaes do projeto; Riscos - Gerenciamento dos riscos; Aquisio - Gerenciar as aquisies do projeto em termos de compra ou venda. Os 5 grupos de processo so:

Figura 5.2: Grupos de processos do PMBOK * Iniciao - Compreende o Termo de Abertura do Projeto que autoriza a iniciao do projeto ou fase. Esse termo de abertura um documento formal entre a empresa contratante e a empresa contratada; * Planejamento - Esta fase compreende o desenvolvimento de aes necessrias para alcanar os objetivos do projeto; * Execuo - Nesta fase sero postas em prtica as aes definidas conforme o planejamento do projeto; * Monitoramento e Controle - Compreende o processo de acompanhamento, reviso e regulao do progresso para atender aos objetivos de desempenho conforme o plano de gerenciamento do projeto; * Encerramento - Compreende o processo de Formalizao de Encerramento de todas as atividades de todos os grupos de processos do projeto ou fase, arquivar as lies aprendidas durante o projeto, encerramento de contrato e liberao da equipe. 5.1 Scrum Scrum uma metodologia gil para gerncia de projetos. Ela foi baseada em uma jogada de Rudby. Ela baseada em ciclos de 30 dias chamados Sprints, onde se trabalha para alcanar objetivos definidos. Estes objetivos so representados no Backlog, que uma lista que descrimina as atividades para fazer e que constantemente atualizada e repriorizada.

PAPIS * Equipe - Entregam solues, geralmente formada por um grupo pequeno (entre 5 e 9 pessoas), trabalham de forma auto gerenciada; * Product Owner - Responsvel pela viso de negcios do projeto, ele define e prioriza o Backlog. Geralmente o papel desempenhado pelo cliente; * Scrum Master - Sua principal misso garantir o uso do Scrum, removendo obstculos e assegurando que as prticas de Scrum esto sendo executadas com eficincia. FUNCIONAMENTO * Definio do Backlog - Todas as funcionalidades ou mudanas no produto so definidas pelo Product Owner no Backlog. Esta lista prioriza para as necessidades dos clientes ou demandas do mercado. Os itens do topo da lista so destacados para serem entregues no final do prximo Sprint; * Andamento do Sprint - Durante o Sprint, os itens do Backlog que devem ser entregues so agora tratados no Sprint Backlog. As tarefas agora so responsabilidade da Equipe, que tem autonomia para decidir como elas devem ser executadas; * Reunies Dirias - O Scrum Master se reune diariamente com a Equipe num mesmo horrio, para que se reporte: * O que foi feito ontem? * O que se pretende fazer hoje? * Quais so os impedimentos que esto atrapalhando a execuo das tarefas? * Revises - No final do Sprint a Equipe demonstra os resultados para o Product Owner e demais interessados, de forma que os itens do Backlog sejam considerados prontos e ento possa se iniciar um novo Sprint. 6. EMPREENDEDORISMO O conceito "empreendedorismo" foi utilizado pelo economista Joseph Schumpeter em 1950 como sendo uma pessoa com criatividade e capaz de fazer sucesso com inovaes. Mais tarde, em 1967 com Kenneth E. Knight e em 1970 com Peter Drucker foi introduzido o conceito de risco, uma pessoa empreendedora precisa arriscar em algum negcio. Em 1985 com Gifford Pinchot foi introduzido o conceito de Intraempreendedor, uma pessoa empreendedora, mas dentro de uma organizao. O empreendedor aquele que faz as coisas acontecerem, se antecipa aos fatos e tem uma viso de futuro da organizao. aquele que assume riscos e comea algo novo. D significncia a palavra empreendedor. O mtodo a ser utilizado pelo cliente Software Developer, atravs da consultoria da empresa Consulting, orientar o seu cliente que todo empreendedor deve conversar com todos os diferentes nveis sociais de pessoas sobre variados temas, pesquisar novas patentes de produtos e tipos de licenciamentos que possam definir estratgias de negcios, estar atento

aos grandes acontecimentos sociais, visitar institutos de pesquisa, universidades, feiras, empresas, participar de congressos, eventos de entidades de classe e etc. Pergunta: como selecionar a melhor ideia e oportunidade? A Consulting sugere que seja feita a anlise dos seguintes aspectos: 1. Quem compra e quem no compra esse produto ou servio? 2. Qual o mercado alvo? 3. Qual o retorno que este negcio pode proporcionar? 4. Quais so as vantagens competitivas desse negcio e como poderiam ser superadas? 5. Qual a equipe que transformar essa ideia em negcio? 6. At que ponto o empreendedor est comprometido com este negcio? As respostas para essas questes vo servir de balizador para a avaliao da oportunidade. Critrios quantitativos podem aumentar o grau de atratividade do negcio. No existe regra para declarar se uma oportunidade boa ou ruim, mas depois dessa anlise, o empreendedor ter mais subsdios para decidir continuar a explorao dessa ideia ou no. Essa analise segue um padro de pesquisa, dentro daquilo em que o nvel do cliente Software Developer vem utilizando atualmente, ficando em aberto a possibilidade de aplicaes de estratgia de negcios, para cada nvel em que o cliente vier a alcanar. 7. GESTO DA QUALIDADE A definio da qualidade contempla caractersticas prprias, pois abrange a subjetividade da relao de produtos vendidos e de produtos comprados. Necessidades de qualidade adequao ao uso, surge uma variedade de possveis interpretaes, mas ao mesmo tempo indica um caminho que conduz reflexo e ao: a qualidade deve ser orientada para o seu consumidor. A Gesto da Qualidade o fator fundamental nos processos de qualquer empresa. Hoje em dia, seja a empresa de pequeno, mdio ou grande porte, com o aumento da competitividade, das exigncias de qualidade, meio ambiente e restries de mercado, a empresa Software Developer contratou os servios da empresa Consulting que tem como objetivo aperfeioar os processos, estreitar o relacionamento entre o seu cliente e o pblico alvo procurando meios para conseguir esses incrementos de forma organizada, com base em princpios cientficos previamente testados a um baixo custo de implantao. Implantada a gesto da qualidade nos processos do cliente Software Developer, ser necessrio a utilizao de tcnicas da Qualidade Total que envolve algumas ferramentas seguindo mtodos totalmente estruturados que viabilizam a implantao da Qualidade Total em todas as ferramentas. Pode-se notar a nfase dada ao Controle da Qualidade, pois a maior parte delas so aes direcionadas avaliao da qualidade em processos e em produtos.

Logo, as ferramentas mais usuais da qualidade so: 1. Histogramas; 2. Folhas de checagem (Folha de Controle de Dados); 3. Diagrama de Causa e Efeito (Diagrama de Ishikawa); 4. Diagrama de Pareto (Anlise ABC); 5. Grficos de Controle (Grfico de Shewhart); 6. Diagramas de Disperso; 7. Fluxogramas. Atravs da Gesto da Qualidade, o cliente Software Developer futuramente, visa estabelecer a certificao ISO 9000. Essa norma exige critrios para um adequado gerenciamento do negcio, tendo como foco principal a satisfao do cliente e consumidor, atravs de uma srie de aes, dentre as quais podemos destacar: * A empresa precisa estar totalmente comprometida com a qualidade (considerando qualidade igual satisfao do cliente), desde os nveis gerenciais at os operacionais; * Adequar o gerenciamento dos recursos humanos e materiais necessrios para as operaes do negcio; * Existncia de procedimentos, instrues e registros de trabalho formalizando todas as atividades que afetam a qualidade; * Monitoramento dos processos atravs de indicadores e tomada de aes quando os objetivos pr-estabelecidos no so alcanados.

CONCLUSO A maturidade de um setor de desenvolvimento de uma empresa representa maior qualidade nos seus produtos e servios. De uma forma geral, pode trazer maior retorno sobre os investimentos e uma resposta positiva por parte de seus clientes. O CMMI uma metodologia que se tornou base nos processos de desenvolvimento das organizaes que procuram produzir produtos com maior qualidade focada nas necessidades dos clientes, pois se o processo de desenvolvimento tiver qualidade o produto final ter qualidade proporcional. O longo tempo e o custo gerados so os maiores problemas encontrados na implantao do CMMI podendo afastar muitas empresas que possuem a cultura de no fazer investimentos na qualidade de seus produtos. Ao contrrio do que possam parecer, esses investimentos, a mdio tempo, podem trazer resultados de importncia vital para as empresas que aderem a essa metodologia.

Uma certificao CMMI no deve ser considerada uma vantagem competitiva e sim uma comprovao da qualidade dos produtos desenvolvidos pela empresa, tornando-se assim um grande atrativo para clientes e parceiros de negcios.

REFERNCIAS CMMI para Desenvolvimento Verso 1.2. Software Engineering Institute. Disponvel em: < http://www.sei.cmu.edu/library/assets/whitepapers/CMMI-DEV_1-2_Portuguese.pdf>. Acesso em: 09 de Setembro de 2011. COMO FUNCIONA O CONSRCIO. CAIXA CONSRCIOS. Disponvel em: <http://www.caixaseguros.com.br/portal/site/CaixaConsorcios/menuitem.8a9dfe35c4ada856 b39e01b130e001ca/?vgnextoid=a14714dd9e572110VgnVCM100000790110acRCRD>. Acesso em: 10 de Setembro de 2011. Como Funciona. CONSRCIO REMAZA NOVATERRA. Disponvel em: <http://www2.remaza.com.br/consorcio/consorcio.asp?txt_acao=como_funciona>. Acesso em: 10 de Setembro de 2011. CMMI. DevMedia. Disponvel em: <http://www.devmedia.com.br/post-3530-CMMI-Capability-Maturity-Model-Integration.html>. Acesso em: 15 de Setembro de 2011. PMBOK Guia do Conhecimento em Gerenciamento de Projetos. Soft Expert. Disponvel em: <http://www.softexpert.com.br/norma-pmbok.php>. Acesso em: 06 de Outubro de 2011. O que governana corporativa. Invest Pedia. Disponvel em: <http://www.investpedia.com.br/artigo/O+que+e+governanca+corporativa.aspx>. Acesso em: 01 de Dezembro de 2011. Gerncia de TI - Vantagens do Outsourcing em TI. iMasters. Disponvel em: <http://imasters.com.br/artigo/6428/gerencia/vantagens_do_outsourcing_em_ti/>. Acesso em: 01 de Dezembro de 2011. ISSO/IEC 12207 Processos Fundamentais. Plug masters. Disponvel em: <http://www.plugmasters.com.br/sys/materias/539/1/ISO%7B47%7DIEC-12207-ProcessosFundamentais>. Acesso em: 02 de Dezembro de 2011. Impresses do 8 Encontro Mensal da ALATS-SP. QualidadeBR. Disponvel em: <http://qualidadebr.wordpress.com/tag/mpsbr/>. Acesso em: 02 de Dezembro de 2011. PRINCPIOS DA GESTO DA QUALIDADE. QUALIDADE.ENG.BR. Disponvel em: <http://www.qualidade.eng.br/artigos_principios_qualidade.htm>. Acesso em 03 de Dezembro de 2011. Criar EAP - Exemplos de EAP. TenStep. Disponvel em: <http://www.tenstep.com.br/br/TenStepPB/open/5.3.01.1TS.htm>. Acesso em: 05 de Dezembro de 2011.

Matriz RACI. Tecnologia e Gesto. Disponvel em: <http://tecnologiaegestao.wordpress.com/2010/08/12/matriz-raci/>. Acesso em: 03 de Dezembro de 2011. O CMMI e o gerenciamento da qualidade de projetos de software. O gerente. Disponvel em: <http://ogerente.com.br/rede/projetos/gerenciamento-da-qualidade-de-projetos>. Acesso em: 07 de dezembro de 2011. Metodologias - Nveis de Maturidade do MPS.BR. Portal da RENAPI. Disponvel em: <http://www.renapi.gov.br/qualidade/metodologia/finalidade>. Acesso em: 10 de Dezembro de 2011. SANCHEZ, IVAN. Scrum em 2 minutos. Coding Dojo Floripa. Disponvel em; <http://dojofloripa.wordpress.com/2007/02/07/scrum-em-2-minutos/>. Acesso em: 13 de Dezembro de 2011.

ANEXOS ANEXO A - Proposta Tcnica para Prestao de Servios em Consultoria para Certificao em CMMI.

PROPOSTA TCNICA PARA PRESTAO DE SERVIOS EM CONSULTORIA PARA CERTIFICAO EM CMMI |

Dezembro de 2011 SUMRIO 1. APRESENTAO 1.1 A Consultoria 1.2 Diferenciais 1.3 Principais servios oferecidos 2. EAP (Estrutura Analtica do Projeto) 2.1 Planejamento 2.2 Execuo 2.3 Encerramento 3. SLA

1. APRESENTAO So Paulo, 15 de Dezembro de 2011,

Empresa Software Developer So Paulo SP Prezados Diretores, Primeiramente agradecemos a Software Developer, pela oportunidade de apresentarmos nossa Proposta Tcnica para Prestao de Servios em Consultoria para Certificao em CMMI (Capability Maturity Model Integration). Nossa qualificao tcnica para este trabalho est sustentada principalmente no nvel dos profissionais alocados para este desafio. com inteira satisfao que lhes enviamos a nossa Proposta Tcnica para Prestao de Servios em Consultoria para Certificao em CMMI a V.Sas. a empresa Software Developer. Propomo-nos a realizar um servio eficiente e eficaz para atender as expectativas da empresa nos melhores padres de qualidade tcnica com uma equipe de profissionais capacitados e comprometidos com os objetivos do projeto. Asseguramos que no vamos poupar esforos para cumprir as nossas tarefas e vamos focar em satisfazer as necessidades da Software Developer. 1.1 A Consultoria A Consulting presta servios de implementao de processos com base no CMMI-DEV verso 1.2, modelo amplamente reconhecido para melhoria de processos de software e difundido em milhares de empresas em todo o mundo. Alm de ser muito usado no contexto de empresas de desenvolvimento de software, o CMMI um dos poucos modelos que possui um conjunto de prticas aplicveis realidade das empresas de engenharia de sistemas, que integram hardware e software. Nossa experincia cobre os contextos de fbricas de software e de projetos, alm de empresas que desenvolvem produtos e servios de software. Por trabalhar com organizaes que atuam em diferentes domnios de negcio, conhecemos as particularidades inerentes aos seus processos e prticas. 1.2 Diferenciais

Nossa equipe conta com profissionais que, alm de atuarem como consultores, vivenciam o dia-a-dia da definio e implementao de processos como participantes de grupos de melhoria de processos e analistas de qualidade em empresas formalmente avaliadas com base no modelo CMMI. Nossos consultores tambm atuam como membros de equipes de avaliaes oficiais, o que permite a execuo de servios de anlises de gaps, avaliaes informais de processos e preparao de seus clientes para avaliaes formais com maior segurana. 1.3 Principais servios oferecidos * Consultoria para melhoria de processos com base no modelo CMMI; * Treinamentos e workshops sobre as disciplinas relacionadas s reas processos; * Apoio equipe de melhoria de processos e de garantia da qualidade; * Avaliaes intermedirias para identificao de gaps nos processos; * Avaliaes informais e preparao para avaliaes oficiais CMMI. Estamos honrados em apresentar nossa proposta e estamos disposio para sanar quaisquer dvidas.

Sem mais, Empresa Consulting. 2. EAP (Estrutura Analtica do Projeto)

BSC (Balanced Scorecard) PERSPECTIVAS | OBJETIVOS FINANCEIRA | | | INDICADORES | METAS | | | | AES |

1. Aderir a Lei Sarbanes-Oxley (SOX) | 1. Estabelecer Governanas.Alinhamento das Governanas.Alinhamento das Governanas. | 1. Valor de Mercado Interno e Externo. | 1. Bolsa Valores de Nova York. | 1. Se adequar a Lei.2. Auditorias.3. Comprovao de Valores Demonstrados. | CLIENTE | | | | |

1. Melhoria na qualidade de atendimento.2. Melhoria nas atualizaes dos softwares. | 1. Implantar um helpdesk eficiente.2. Melhorar o desenvolvimento das atualizaes. | 1. Pesquisa de satisfao do atendimento.2. Reduo de reclamaes dos clientes. | 1. > 90 %2. > 90 % | 1. Implantar software de helpdesk eficaz.2. Estrutura, Profissionais e equipamentos adequados. |

PROCESSOS INTERNOS |

1. Armazenar desenhos e Cadastramento dos riscos dos processos.2. Comunicao3. Controle de criao, edio e verso dos documentos.4. Gerenciamento de aquisies.5. Melhoria de helpdesk.6. Melhoria nas correes dos softwares. | 1. Documentar os processos.2. Melhorar a comunicao.3. Gerenciar controle.4. Priorizar aquisies.5. Atendimento eficaz.6. Melhoria nos processos. | 1-2-3. Reduo de trabalho.4. Reduo dos gastos5. Pesquisa de satisfao do atendimento.6. Reduo de reclamaes e aumento de clientes. | 1-2-3. < 80%4. < 45%5. > 90%6. < 90% | 1. Gerenciar documentos.2. Integrar as equipes.3. Gerenciar documentos.4. Evitar desperdcios.5. Criar formulrio de pesquisa.6. Ajuste dos processos segundo as melhores prticas. | APRENDIZADO | | | | |

1. Capacitar e qualificar equipe2. Documentao das lies aprendidas. | 1. Funcionrios alinhados com o negcio.2. Evitar erros conhecidos. | 1. Conscientizao da equipe sobre o objetivo do negcio.2. Reduo de ndice de erros. | 1. 100%2. < 80% | 1. Programa de Comunicao.2. Criar documentao. |

2.1 Planejamento 1. ETAPA I PLANEJAMENTO 1.1 Coleta de requisitos Pergunta Chave: O processo de desenvolvimento do produto planejado, executado, medido e controlado e as prticas existentes so mantidas, mesmo nos momentos de crise podendo repetir a experincia para novos projetos? A Coleta de Requisitos um processo que visa documentar todas as funcionalidades e caractersticas do produto e do projeto, atendendo as expectativas e necessidades das partes interessadas. Foi escrito e documentado o que foi solicitado e combinado, o documento formal est com a assinatura do solicitante, onde o mesmo est ciente de como os processos foram feitos. Na comunicao com stakeholders foram coletadas detalhadamente todas as informaes do produto, onde observamos, entendemos e registramos tudo que o cliente Software Developer solicitou sobre o produto referido. Logo aps discutimos e traduzimos esses requisitos com a equipe do projeto. Na documentao foi informado se caso houvesse a necessidade de mudanas e alteraes no decorrer da coleta de requisitos das informaes, haveria a necessidade de uma reunio com os stakeholders para chegar numa tomada de deciso, definindo a necessidade da mudana. As ferramentas utilizadas para coletar os requisitos na proposta do cliente Software Developer foram: 1. Entrevistas;

2. Dinmicas de grupo; 3. Oficinas; 4. Tcnicas de criatividade em grupo (brainstorming, mapas mentais, etc.); 5. Tcnicas de tomada de decises em grupo; 6. Questionrios e Pesquisas; 7. Observaes e Prottipos.

1.1.1 Anlise da maturidade atual dos processos O levantamento de requisitos apurados na empresa mostrou que ela se encontra em um estado em que os processos no esto funcionando adequadamente. A empresa se encontra em nvel 1 com alguns processos no nvel 2. ANLISE DO CMMI CMMI DEV 1.2 NVEL DE MATURIDADE 2: REPETVEL | PROCESSOS | | PROCESSOSCONFORME Gesto de Requisitos (REQM) | Planejamento de Projeto (PP) | | PARCIAL | * | * | | | NO CONFORME | | | * | * | | * | | | | | | |

Monitoramento e Controle de Projeto (PMC) | Gesto de Acordo com Fornecedores (SAM) Medio e Anlise (MA) | | * | |

Garantia da Qualidade de Processo e Produto (PPQA) | Gesto de Configurao (CM) | | * | |

1.1.2 Identificao das falhas dos processos As falhas identificadas foram as seguintes: a) Controle de criao, edio e verso dos documentos; b) Cadastramento dos riscos associados aos processos de negcios e armazenar os desenhos de processo; c) Gerenciamento dos documentos e controle dos perodos de reteno e distribuio; d) Alguns mdulos bsicos do sistema apresentam falhas quando j esto em produo;

e) O Gestor da rea de TI definiu como prioridade na empresa investir na aquisio de smartphones e VoIP e colocar o projeto de troca de mquinas usadas para testes de programas desenvolvidos (IBM com AIX 5.2). Vale destacar que as mquinas de desenvolvimento e produo so SUN Solaris 10; f) Os problemas dos clientes so anotados em um caderno para depois ser feito uma avaliao pessoal de quanto crtico o chamado para ento classifica-lo. Essa classificao se torna diferente dependendo do analista que atende; g) Quando identificada uma falha feita a correo, porm essa correo j enviada direto para o cliente ocasionando paradas que impactam diretamente em suas operaes; h) Independente do tipo de problema, no h explicaes claras da causa raiz e normalmente no so aplicadas as correes nos demais ambientes dos clientes, o que deveria ser parte de uma ao corretiva baseada nas lies aprendidas; 1.2 Estimar o tempo O tempo ser estimado conforme o cronograma do item 1.2.1 do projeto. 1.2.1 Desenvolver o cronograma

1.3 Estimar os custos CUSTOS ETAPA I - PLANEJAMENTO | | HRA/MS | VLR/HR | TOTAL

PROFISSIONAL | QUANTIDADE | TEMPO | Gerente |1 | 2 meses | 2 meses |1 |1 | 176 | 176

| 130,00 | 100,00 | 176 | 176

| R$ 45.760,00 | | R$ 35.200,00 |

Coordenador | 1 Analista de Negcio Analista de Sistema

| 2 meses | 2 meses

| 80,00 | R$ 28.160,00 | | 50,00 | R$ 17.600,00 |

TOTAL | R$ 126.720,00

CUSTOS ETAPA II - EXECUO | PROFISSIONAL | QUANTIDADE | TEMPO | Gerente |1 | 7 meses | 176 | HRA/MS | VLR/HR | TOTAL

| 130,00

| R$ 160.160,00

Coordenador | 1 Analista de Negcio Analista de Sistema Analista de Teste

| 7 meses |3 |2 |1

| 176

| 100,00 | 176 | 176 | 176

| R$ 123.200,00

| 2 meses | 2 meses | 2 meses

| 80,00 | R$ 84.480,00 | | 50,00 | R$ 35.200,00 | | 45,00 | R$ 15.840,00 |

TOTAL | R$ 418.880,00

CUSTOS ETAPA III - ENCERRAMENTO

| | HRA/MS | VLR/HR | TOTAL

PROFISSIONAL | QUANTIDADE | TEMPO | Gerente |1 | 3 meses | 3 meses | 176 | 176

| 130,00 | 100,00

| R$ 68.640,00 | | R$ 52.800,00 |

Coordenador | 1

TOTAL | R$ 121.440,00

CUSTOS TOTAL DO PROJETO ETAPA I PLANEJAMENTO

| | R$ 126.720,00 | | |

ETAPA II EXECUO | R$ 418.880,00 ETAPA III - ENCERRAMENTO

| R$ 121.440,00

TOTAL | R$ 667.040,00

TABELA RACI ATIVIDADES | GerentedeProjetos | CoordenadordeProjetos | AnalistadeSistema | AnalistadeTeste | Coleta de Requisitos |R |A |R |C |I |C ||A |R | |R |A |R |R || | | AnalistadeNegcio

Anlise da maturidade atual dos processos Identificao das falhas dos processos | I

Desenvolver o cronograma Estimar os custos |R

|R |A |R |C |A

|A |C |A |C |R |R |R |C

|C |I |I |R | |C |A |

|I |I |I |A

|I | |I |

Valor/hora por profissional Corrigir as falhas Testes | I |C |I |C

Treinamento dos funcionrios | A Termo de encerramento do projeto SLA |R |R |A |C

|C |I

|C |I

| |I |

Legenda:R: ResponsvelA: ResponsvelC: ComunicadoI: Informado

1.3.1 Valor/hora por profissional CUSTOS DE PROFISSIONAIS |

TIPO DE PROFISSIONAL | VALOR/HORA | QUANTIDADE | Gerente de Projetos | R$ 130,00 |1 | |1 | | | |

Coordenador de Projetos Analista de Negcio Analista de Sistemas Analista de Teste

| R$ 100,00 |3 |3 |1

| R$ 80,00 | R$ 50,00 | R$ 45,00

2.2 Execuo 2. ETAPA II EXECUO 2.1 Corrigir as falhas PROPOSTA DE CORREO DA FALHA (a) Criar um Formulrio Mestre, simples, porm eficaz, para gerenciar todos os documentos da empresa desde a criao at a reteno como mostra o modelo na pgina seguinte. | Formulrio Mestre Histrico do Documento Responsvel | | | Alteraes |

| Ultima atualizao

Fenando C. Lima |

| 15/12/11

|-

DocN | Descrio do documento SD-1 SD-2 SD-3 SD-4 SD-5 SD-6 SD-7 SD-8

| Verso | 00

| Data | | 28/10/11 | 00 | | |

| Especificao de Recebimento

| Formulrio de Gerenciamento de Verses

| 28/10/11 | 28/10/11 |

| Formulrio de Gerenciamento de Aquisies | 00 | Matriz de Gerenciamento de Risco | Lies Aprendidas | 00 | 00

| 28/10/11 | |

| 28/11/11 | 00

| Termo de Homologao

| 28/11/11

| Termo de Encerramento do Projeto | 00 | Termo de Abertura do Projeto | | 00

| 28/11/11 | 28/11/11

| |

Exemplo de Formulrio para gerenciamento de documentos em geral. PROPOSTA DE CORREO DA FALHA (b) Desenvolver um Formulrio Matriz de Gerenciamento de Risco para os eventos negativos que podem ocorrer durante um projeto. Vide exemplo na pgina seguinte.

| Matriz de Gerenciamento de Risco | | SD-4 | |

| Doc N

Histrico do Documento

Verso | Autor | Data | Revisor 00 | Fernando C. Lima | | Solicitao N | Projeto

| Data | Alteraes

| | 29/10/11 |-

| 28/10/11

| Anderson Afonso

| Referncia dos Processos

| |

MGR-1 | Consultoria de como implementar e obter a certificao CMMI nvel 2 Gerenciamento do Escopo do Projeto |

N | Fonte | Descrio Limite | Stat |

|I

|P

|V

| Consequncia | Ao | Resp | Data

1 | Escopo do projeto | Gerenciamento da qualidade | 3 conformidades | Minimizar-fazer a garantia/controle da qualidade ||P | 2 | Escopo do projeto | Gerenciamento de mudanas | 3 Atraso no cronograma | Minimizar-evitar mudanas desnecessrias ||P | | Preenchimento N | | | |

|3 |9 | No | Gerente de Projetos

|3 |9 | | Gerente de Projetos

| Nmero sequencial

Fonte | Fonte do risco Descrio I P V

| Descrio do risco

| Valor de Impacto (1=Baixo, 2=Mdio, 3=Alto) | | Valor da Probabilidade (1=Baixo, 2=Mdio, 3=Alto) | |

| Valor da Pontuao do risco (Probabilidade x Impacto) | |

Consequncia | Consequncia do risco Ao | Ao para tratamento do risco Resp | Responsvel pela ao |

Data Limite Stat

| Data limite de concluso do risco

| |

| Status em que o risco se encontra (P=Pendente ou F=Fechado) |

Exemplo de Matriz para Gerenciamento de Riscos do Projeto PROPOSTA DE CORREO DA FALHA (c) Criar um corpo padro de documento para a padronizao dos processos da empresa como no exemplo na pgina seguinte.

| Especificao de Recebimento | | SD-1 |

| Doc N

Histrico do Documento

| | Data | Alteraes | | 28/10/11 |-

Verso | Autor | Data | Revisor 00 | Fernando C. Lima | | Produto |

| 28/10/11

| Anderson Afonso

Monitor de LCD para computador - 17 Fornecedor | | |

Computer Accessories Ltda Cdigo interno do produto ER-1 |

Tempo de validade do produto | No mnimo 5 anos Tipo de embalagem | | |

De acordo com a embalagem do fornecedor Caractersticas crticas de inspeo |

-Garantia do produto (mnimo 1 ano)-Suporte ps-venda conforme acordado na aquisio | Documento de referncia | |

Baseado na especificao tcnica do fornecedor

Exemplo de um corpo padro para documentos PROPOSTA DE CORREO DA FALHA (d) Todos os mdulos devem ser testados e documentados antes de serem enviados para os clientes. PROPOSTA DE CORREO DA FALHA (e) Para qualquer aquisio que o gestor venha a fazer, necessrio comprovar sua priorizao como o fato de investir na compra de smartphones e VoIP e atrasar a troca das mquinas usadas para testes de software, onde o desenvolvimento de software feito em mquinas IBM AIX 5.2 e os testes em SUN Solaris 10.

A Consulting prope, seguindo as boas prticas do mercado que, futuramente o ambiente de desenvolvimento e testes deva usar mquinas compatveis para evitar problemas quando os softwares j estiverem em uso nos clientes. Possivelmente essa deve ser a causa de alguns problemas que j esto ocorrendo. Outra proposta de soluo a virtualizao do ambiente de desenvolvimento: empresas como por exemplo a IBM oferecem servios de virtualizao que tem se demostrado muito eficazes. Para a aquisio de produtos e/ou servios necessrio utilizar um formulrio que indique atravs de um checklist o melhor fornecedor ou produto com base na pontuao de algumas perguntas que podem ser elaboradas para um determinado propsito. Vide o exemplo na pgina seguinte.

| Gerenciamento de Aquisies | Doc N | | SD-3 | |

Histrico do Documento

Verso | Autor | Data | Revisor 00 | Fernando C. Lima | | Descrio do Produto |

| Data | Alteraes

| | 28/10/11 |-

| 28/10/11

| Anderson Afonso

Monitor de LCD para computador 17 | Descrio Fornecedor 1 Computer Accessories Ltda Descrio Fornecedor 2 Technology Ltda | | | | |

Descrio Fornecedor 3 IT Development | Item 2 |

| Discriminao do item | Avaliao Fornecedor 3 | |1 |2 |3

| AvaliaoFornecedor 1 | |1 |2 |3 |1

| Avaliao Fornecedor

|2

|3

| Em relao a garantia do produto? | |X | |

|X

|X

| Em relao a qualidade do produto (marca e modelo)? | |X | | |X | | | Em relao ao valor do produto? | | |X | |8 |4 (2=Bom) |7 | | |X

|X

|X

Total de pontos NOTAS: (1=Ruim)

| (3=timo) |

Exemplo de Gerenciamento de Aquisies.

PROPOSTA DE CORREO DA FALHA (f) As boas prticas do mercado utilizam softwares livres com licena GPL, onde possvel distribuir, alterar e utilizar todo o cdigo fonte do aplicativo. O mercado dispe do software livre de help desk OcoMon usado para abrir chamados de clientes internos e externos da empresa. Os clientes internos utilizam a abertura de chamado atravs de um usurio e os clientes externos, por exemplo, via telefone. um aplicativo simples de ser manuseado com verso em portugus e que pode atender a necessidade da empresa Software Developer. Para problemas j ocorridos e solucionados, o OcoMon guarda as informaes em seu banco de dados podendo ajudar o analista no entendimento e soluo do chamado. A seguir a tela de abertura de chamado:

Tela inicial do software de help desk OcoMon.

PROPOSTA DE CORREO DA FALHA (g) Antes de serem executadas as atualizaes nos clientes elas devem ir para um ambiente de testes. Quando for enviado para o cliente e antes de sua instalao, documentar o sistema do cliente no estado em que se encontra para o caso de algum erro ou defeito, poder voltar ao estado anterior. PROPOSTA DE CORREO DA FALHA (h) Um mtodo para se chegar a soluo desse problema utilizar a ferramenta de qualidade mais comum entre as empresas chamada de Diagrama de Causa e Efeito (Ishikawa) ou Espinha de Peixe. Ele usado para analisar as causas potenciais de um determinado problema utilizando

as informaes ao redor das causas e atravs de uma anlise minuciosa na identificao do efeito causador do problema. Vide o diagrama a seguir:

Diagrama de Ishikawa (Causa e Efeito). Quanto as lies aprendidas, documentar todas as resolues dos problemas resolvidos em um formulrio que guarde as lies aprendidas durante um projeto conforme exemplo da pgina seguinte.

| Lies Aprendidas | | SD-5 |

| Doc N

Histrico do Documento

| | Data | Alteraes | | 28/10/11 |-

Verso | Autor | Data | Revisor 00 | Fernando C. Lima | | N Solicitao | Projeto |

| 28/10/11

| Anderson Afonso

MGR-1 | Consultoria de como implementar e obter a certificao CMMI nvel 2 Item | Data | rea de Conhecimento | | | | | | | | | | | | | | | | Evento | Lies Aprendidas

| |

Exemplo de Lies Aprendidas. 2.2 Testes Conforme o cronograma do projeto. 2.2.1 Monitoramento e Controle Conforme o cronograma do projeto. 2.3 Homologao

Para as fases ou produtos entregues durante o projeto ser utilizado um Termo de Homologao contendo os respectivos resultados parciais ou totais do projeto e os responsveis pela homologao com a validao positiva ou negativa. 2.3.1 Termo de homologao Vide o exemplo na pgina seguinte.

| Termo de Homologao | | SD-6 | |

| Doc N

Histrico do Documento

Verso | Autor | Data | Revisor 00 | Fernando C. Lima | | N Solicitao | Projeto| | | | |

| Data | Alteraes

| | 28/10/11 |-

| 28/10/11

| Anderson Afonso

Gerente do Projeto

Tipo de Homologao | Parcial

| Total |

RESULTADOS DA HOMOLOGAO Fase | Descrio | | | | | Sim | | | | Validado | No | | | | | | |

| | Comentrios | | | | |

RESPONSVEIS PELA HOMOLOGAO | Fase | Nome | Departamento | | | | | Assinatura |

Exemplo do Termo de Homologao. 2.4 Treinamento dos funcionrios Conforme o cronograma do projeto. 2.3 Encerramento 3. ETAPA III ENCERRAMENTO 3.1 Lies aprendidas As lies aprendidas durante todo o projeto sero armazenadas e documentadas em um Formulrio de Lies Aprendidas para os prximos projetos que apresentarem o mesmo segmento como mostra o exemplo na pgina seguinte.

| Lies Aprendidas | | SD-5 |

| Doc N

Histrico do Documento

| | Data | Alteraes | | 28/10/11 |-

Verso | Autor | Data | Revisor 00 | Fernando C. Lima | | N Solicitao | Projeto | Item | |

| 28/10/11

| Anderson Afonso

| Data | rea de Conhecimento | | | | | | | | | |

| Evento

| Lies Aprendidas

Formulrio para armazenamento de Lies Aprendidas. 3.2 Termo de encerramento do projeto O encerramento do projeto ser atravs do Termo de Encerramento do Projeto como mostrado na pgina seguinte.

| Termo de Encerramento do Projeto | Doc N | | SD-7 | | | Data | Alteraes

Histrico do Documento

Verso | Autor | Data | Revisor 00 | Fernando C. Lima |

| | 28/10/11 |-

| 28/10/11

| Anderson Afonso

Produto(s) Entregue(s) | Alteraes Efetuadas | Alteraes posteriores | Motivo do encerramento

| | | | |

VALIDAO

| | De acordo | | | | | Assinatura |

Nome | Departamento | | | | | Sim | | |

| No | | | | | | |

Consideraes Finais |

Termo de Encerramento do Projeto. 3. SLA Na pgina a seguir o modelo de SLA (Service Level Agreement).

INSTRUMENTO PARTICULAR DE CONTRATO DE PRESTAO DE SERVIOS IDENTIFICAO DAS PARTES CONTRATANTES

CONTRATANTE: Software Developer, Nacionalidade Brasileira, Rua Antnio lobo , n110, Bairro Santo Amaro, Cep 090900-60, Cidade So Paulo, no Estado SP. E-MAIL DE CONTATO CONTRATADA: Consulting CONSULTORIA EM MELHORIA DE PROCESSOS LTDA, com sede em So Paulo, Cep 090600-720, no Estado do So Paulo, inscrita no C.N.P.J. sob o n 10.732.140/0001-08. E-mail de contato: pim4@uol.com.br As partes acima identificadas tm, entre si, justas e acertadas o presente Contrato de Prestao de Servios com o objetivo de entregar um estudo contendo analise de impacto, planejamento, desenvolvimento e como implementar e obter a certificao CMMI nvel 2, que se reger pelas clusulas seguintes e pelas condies descritas no presente. As partes elegem em comum acordo o meio eletrnico como forma de declarar vontades e consentir, em substituio a qualquer outro meio de contratar, sendo prova certa do negcio, equiparando-se ao contrato escrito e assinado presencialmente. A aceitao das condies do contrato ser declarada por meio eletrnico, atravs da conferncia prvia por parte do Contratante das condies de fornecimento do servio, devendo conferir os seus dados cadastrais e submeter aceitao das condies contratuais atravs do clique do boto de acordo. DO OBJETO DO CONTRATO Clusula 1 - O presente mtodo tem como objetivo a certificao CMMI nivel 2, bem como a prestao de servios de consultoria da Consulting para o CONTRATANTE. EAP Pargrafo primeiro - A CONTRATADA disponibilizar ao CONTRATANTE, alm do servio de gerenciamento de processos, os seguintes servios adicionais que podero ser contratados opcionalmente: 1 ETAPA ser executada pela CONTRATADA onde ser feito a coleta de requisitos, anlise de maturidade, identificao de falhas, estimao de tempo, desenvolvimento do cronograma e estimao de custos 2 ETAPA ser executada pelo CONTRATANTE, onde o mesmo disponibilizar os seus key users, para estarmos coletando informaes para o planejamento e execuo do projeto, com a criao de acesso e monitoramentos para a CONTRATADA. 3 ETAPA ser executado pela CONTRATADA, onde ser feito a correo de falhas nos processos, teste, monitoramento e controle, homologao e treinamento de funcionrios . Clusula 2 So obrigaes da CONTRATADA:

I) Garantir absoluto sigilo sobre todos os processos, frmulas, rotinas e quaisquer outros dados que venham a ser disponibilizados pelo CONTRATANTE CONTRATADA; II) Disponibilizar o manual do usurio on-line mantendo-o atualizado, sempre que novas implementaes forem realizadas; III) No est includo na presente prestao de servio o suporte tcnico de desenvolvimento ou instalao de pginas HTML ou de scripts CGI, Perl, PHP, Java, MySQL ou qualquer outra linguagem de desenvolvimento em Internet, nem mesmo operao de aplicativos como Front Page, Dreamweaver, Flash ou quaisquer outros. O suporte tcnico limita-se apenas prestao do servio de gerenciamento de processos e os servios adicionais contratados; VI) O suporte tcnico ser prestado via meio eletrnico, segundo os dados abaixo: a) E-mail: suportepim3@uol.com.br (24 horas por dia, 7 dias por semana com prazo de resposta de at 72 horas); V) A CONTRATADA responsvel pelos encargos trabalhistas, previdencirios, fiscais e comerciais resultantes da execuo do Contrato; DO FORO Clusula 3. As partes elegem o foro da comarca de So Paulo, para dirimir quaisquer dvidas oriundas deste Contrato de Prestao de Servios e de eventuais comunicaes e/ou aditamentos, renunciando expressamente a outro por mais privilegiado que seja. E, por estarem assim justos e contratados, firmam o presente instrumento, em duas vias de igual teor, juntamente com 2 (duas) testemunhas.

So Paulo, __ de _____________ de ____