4º . Semestre (2011/2 – Chácara Santo Antonio – 3ª feira) · PDF...

CURSO: Tecnologia em Gestão da Tecnologia da Informação SÉRIE: 4º Semestre TURNO: Noturno DISCIPLINA: GERENCIAMENTO DE PROJETO DE TI

Prof. Paulo R. Dalto e-mail [email protected] Ano 2011/2 pág. 1

4º . Semestre (2011/2 – Chácara Santo Antonio – 3ª feira)

EMENTA E CONTEÚDO PROGRAMÁTICO

CURSO: Tecnologia em Gestão da Tecnologia da Informação

SÉRIE: 4º Semestre

TURNO: Noturno

DISCIPLINA: GERENCIAMENTO DE PROJETO DE TI CARGA HORÁRIA: 60 horas I – Ementa Fundamentos de Gerência de Projetos. Ferramentas para estimativas, avaliações e métricas de qualidade e risco. Maturidade em desenvolvimento de software com CMMI. Gestão de processos com IBM/RUP. II - Objetivos Estimular o aluno no aprofundamento do conhecimento das técnicas de gestão profissional de projetos do PMI. Desenvolver em aula práticas de uso de ferramentas de estimativas, avaliação, otimização e métricas de planejamento, execução e controle de escopo e tempo. Analisar e discutir os fundamentos das certificações CMMI (capability maturity model – integration). Apresentar ao aluno os aspectos fundamentais da auditoria de sistemas do COBIT, que determinam as modernas técnicas de governança corporativa nessa área. III - Conteúdo Programático

• Fundamentos de gerência de projetos em TI (metodologia PMI) • Ferramentas para definição e gerenciamento de Escopo e Tempo em desenvolvimento de software (WBS, PERT/COM, Gantt e MS Project) • Gestão da Qualidade em TI (NBR ISSO 9001/2000) • Gestão dos Riscos em TI • Maturidade em desenvolvimento de software – CMMI • Atual paradigma de gestão de processo de desenvolvimento – IBM/RUP • Governança em TI (metodologia COBIT)



IV - Estratégia de Ensino - Aulas expositivas - Aulas reflexivas com análise de casos - Dinâmica de grupos - Seminários - Vídeos - Debates Será sempre indicada a bibliografia básica e específica necessária ao acompanhamento do curso e orientação do aluno na vida acadêmica e profissional. A exposição será feita por meio de colocação dos pontos a serem discutidos de forma esquemática, seguida de apresentação por parte do professor. V - Estratégias de Avaliação A avaliação será obtida por meio de provas, trabalhos e seminários, dentre outros, bem como pela participação do aluno durante as aulas e demais atividades, a critério do professor e em conformidade com o respectivo plano de ensino. Serão feitas avaliações, assim distribuídas: - Duas Notas do Professor (NP) para as atividades curriculares, com peso 4 (quatro) cada uma, na composição da nota semestral de cada disciplina; - Uma nota referente ao Projeto Integrado Multidiscipinar (PIM), com peso 2 (dois) no cálculo da Média Semestral (MS) de cada disciplina. Esse Projeto será desenvolvido durante o semestre. A MS será: (NP1 x 4 + PIM x 2 + NP2 x 4) / 10. Para a aprovação, a MS deverá ser igual ou superior a 5,0; é exigida a freqüência mínima de 75%. O desempenho do aluno é avaliado numa escala de 0 (zero) a 10 (dez). VI - Bibliografia Básica MEREDITH, Jack R. Administração de projetos: uma abordagem gerencial. 4ª ed. Rio de Janeiro: LTC, 2003. MARTINS, José Carlos Cordeiro. Gerenciando projetos de desenvolvimento de software com PMI, RUP e UML. Rio de Janeiro: Brasport, 2005. VII - Bibliografia Complementar NEGROPONTE, Nicholas. A Vida Digital, 2. ed. São Paulo: Companhia das Letras, 1995. PFLEEGER, Shari lawrence. Engenharia de Software. Teoria e Prática. 2. ed. São Paulo: Pearson Education do Brasil, 2004.



MATERIAL DA NP2 Princípios para o projeto de uma WBS

� A regra dos 100%

Um dos mais importantes princípios para o projeto de uma WBS é conhecido como a regra dos 100%. O Practice Standard for Work Breakdown Structures (Second Edition), publicado pelo Project Management Institute (PMI) define a regra 100% da forma como se segue:

A Regra 100%... estabelece que a WBS inclui 100% do trabalho definido pelo escopo do projeto e captura todas as entregas – internas, externas, intermediarias – de forma ao trabalho estar

completo, incluído o gerenciamento do projeto. A regra dos 100% é um dos mais importantes princípios que guia o desenvolvimento, decomposição e avaliação da WBS. A aplicação desta regra vale

para todos os níveis na hierarquia: a soma de todos o trabalho dos níveis "filhos" deve ser igual a 100% do trabalho representado pelo

"pai" e a WBS não deve incluir qualquer trabalho que saia do escopo existente do projeto, isto é, ele não pode incluir mais do que 100% do trabalho... É importante lembrar-se que a regra dos

100% também se aplica ao nível de atividades. O trabalho representado pelas atividades de cada pacote deve produzir 100% do trabalho necessário para completar o trabalho do pacote. (p. 8)

Em outras definições deve-se considerar que a soma do trabalho sendo projetado deve ser 100% compatível com o nível "pai", ou seja, não deve conter trabalho a mais nem a menos do que foi proposto no nível imediatamente acima.



� Planeje entregas, não planeje ações � Se o projetista da WBS tenta capturar qualquer detalhe

orientado a ação na WBS, ele irá incluir ações de mais ou de menos. Ações demais excederão 100% do escopo do pai e ações de menos cairão abaixo dos 100% do escopo do pai.

� A melhor forma de ser aderente a Regra dos 100% é definir os elementos da WBS em termos das entregas ou resultados. Isto também assegura que a WBS não exagere na visão dos métodos, permitindo idéias mais criativas e inovadoras por parte dos participantes do projeto.

� Para projeto de desenvolvimento de novos produtos, a técnica mais comum para assegurar a orientação para a saída da WBS é o uso de uma estrutura de quebra do produto.

� Desenvolvimento orientado a aspectos utiliza-se de uma técnica similar a qual emprega uma estrutura de decomposição de aspectos.

� Quando um projeto provê serviços profissionais, uma técnica comum é capturar todas as entregas planejadas para criar uma WBS orientada a entrega. WBS que subdividem o trabalho em fases do projeto (por exemplo: Fase Projeto Preliminar, Fase projeto Critico) devem assegurar que as fases sejam claramente separadas para uma entrega (por exemplo: um documento de revisão de projeto preliminar, ou um documento aprovação da revisão projeto crítico)



� Nível de detalhe (granularidade) e elaboração progressiva � Uma questão a ser respondida no projeto de qualquer

WBS é quando parar de quebrá-lo em elementos menores. Se os elementos finais da WBS são definidos de forma muito abrangente, não deve ser possível rastrear eficientemente a performance do projeto.

� Se os elementos finais da WBS são muito detalhados, será ineficiente manter um rastreamento de um número exagerado de elementos terminais, especialmente se o plano de trabalho é para um futuro distante.

� Um meio termo satisfatório pode ser encontrado no conceito de elaboração progressiva o qual permite que os detalhes da WBS sejam progressivamente refinados antes do trabalho ser iniciado.

� Uma forma de elaboração progressiva em grandes projetos é chamada de planejamento ondas sucessivas o qual estabelece um planejamento de tempo regular para elaboração progressiva.

� Na realidade, um limite efetivo da granularidade da WBS pode ser alcançado quando ela não é maior do que é possível para se gerar saídas planejáveis, e os únicos detalhes remanescentes são as ações. A não ser que estas ações possam ser definidas para aderir a regra dos 100%, a WBS não pode ser mais subdividida.

� Esquema codificação WBS

� É comum para elementos WBS serem numerados sequencialmente para revelar a estrutura hierárquica. Por exemplo 1.4.2 Pneu Traseiro identifica este item como o 3º elemento da WBS, pois há 3 números separados por ponto decimal. Um esquema de codificação também ajuda os elementos WBS serem reconhecidos em qualquer contexto escrito.



� EAE - Estrutura Analítica da Entrega � Devido a sua simplicidade, a EAP é utilizada por muitos

desenvolvedores de software, que produzem e documentam suas análises através do bloco de notas.

� Entretanto, a metodologia de desenvolvimento ágil de software não é, de um modo geral, baseada em projetos; e sim em entregas fracionadas e constantes.

� Desse modo, surge uma variação da EAP: a EAE, ou seja, Estrutura Analítica de Entrega.

� Essa estrutura herda os princípios da EAP, entretanto, é aplicada em outro nível do processo, sendo destinada ao planejamento das entregas que compõe o projeto como um todo.

Gerenciamento do Tempo do Projeto • O Gerenciamento do Tempo do Projeto envolve os processos

necessários para gerenciar o término pontual do projeto.

Definir as Atividades • Identificar as atividades que devem ser realizadas para produzir

as entregas (pacotes de trabalho) do projeto:

- Pacote de trabalho - Atividade 1 - Atividade 2 - Atividade 3 - Atividade n

Seqüenciar as Atividades

• O sequenciamento das atividades envolve a identificação e documentação dos relacionamentos entre as atividades;

• As dependencias podem ser de 3 tipo: � Obrigatórias � natureza do trabalho, exigidas

contratualmente. “É obrigatório construir a parede antes de colocar as portas”.

� Arbitradas � boa prática, metodologia. “Acho que devemos pintas a parede antes de colocar o carpete”.

� Externas � fora do controle da equipe de projeto. “Depende de algum fator externo, entrega de um fornecedor, aprovações do governo, etc“.



Estimar os Recursos da Atividade • Determinar os tipos de recursos:

� Materiais, pessoas, equipamentos ou suprimentos; � Características (habilidades, tipo, etc)

• Em que quantidades serão necessários para executar as atividades do projeto.

Estimar as Durações da Atividade

• Duração é o temo necessário para completar a atividade � número de períodos de trabalho (horas, dias, semanas ou meses)

• São influenciadas por: � Recursos (quantidade, disponibilidade, habilidades...) � Produtividade (ambiente, compartilhamento...) � Restrições e Premissas (físicas, externas, ambienteais ...) � Informações históricas � Riscos

• Reservas para contingências: � Reservas de tempo ou buffer; � Compensação de riscos; � Deve ser documentada claramente; � Pode ser adicionada à duração da atividade ou ao final do

projeto; � Pode ser reduzida ou eliminada pelo gerente do projeto.

• Cuidado com o jogo do “engana-engana” das estimativas. • Duração vs. Esforço:

� Duração � o tempo esperado para uma atividade ser concluída dado o esforço e recursos disponíveis. Ex. 2 dias

� Esforço � também chamado de Empenho, ou Trabalh, é a quantidade de unidades de mão-de-obra necessária para concluir um atividade. Ex. 16 hh



Cronograma • O cronograma é um instrumento de planejamento e controle

semelhante a um diagrama, em que são definidas e detalhadas minuciosamente as atividades a serem executadas durante um período estimado.

• Em nível gerencial, um cronograma é um artefato de controle importante para levantamento dos custos de um projeto e, a partir deste artefato, pode ser feita uma análise de viabilidade antes da aprovação final para a realização do projeto.

� Desenvolver o Cronograma:

� Duração das atividades � Calendários � Restrições � Premissas � Antecipações e esperas � Disponibilidade dos recursos � Riscos � Lista de atividades e seus atributos � Diagrama de Rede � Duração das atividades

� Pontos de Cotroles -- Marcos:

� Definir no cronograma os pontos em que e deve aferir os resultados parciais para efetuar controle;

� Esses pontos são os Marcos ou Milestones; � Compare os resultados com as expectativas; � Produtos, serviõs ou resultados do projeto a serem

entregues para o cliente são chamados de entregas, ou deliverables;

� Momentos de entrega dos produtos do projeto são bons ponto de controle.

� Desenvolver o Cronograma // Método do Caminho crítico:

� Sem considerar as limitações de recursos, calcula as datas de início e término mais cedo e início e término mais tarde para todas as atividades do diagrama de rede;

� Caminho crítico: • O caminho mais longo no diagrama de rede; • Não tem folgas, qualquer atraso em alguma

atividade implica no atraso do projeto; • Pode mudar no andamento do projeto; • Pode haver mais de um caminho crítico no

projeto; • Atividades do caminho crítico requerem

atenção especial



� Compressão/Cashing do Cronograma: � Redução da duração das atividades, normalmente

aumentando os recursos e custos; � Análise de custo/benefício para obter a maior

compressão com o menor custo; � Nem sempre é visivel; � Comprimir sempre as atividades que estão no

caminho critico e considerar aquelas que sofrem menos aumento de custo;

� Paralelistmo, ou caminho rápido (fast tracking); • Atividades que normalmente seriam

executadas em sequencia são feitas em paralelo;

• Aumenta o risco e pode causar retrabalho no projeto;

• Requer maior domínio das atividades.

Gerenciamento dos Custos do Projeto

• Processos envolvidos em estimativas, orçamentos e controle de custos, de modo que o projeto possa ser terminado.

� Estimar os Custos:

� A precisão da estimativa de um projeto aumentará conforme o mesmo progride no seu ciclo de vida;

� As estimativas devem ser refinadas durante o curso do projeto



Gerenciamento da Qualidade do Projeto • Processos para assegurar que o projeto satisfaça as

necessidades para as quais foi criado. • O Gerenciamento da Qualidade deve abordar tanto o

gerenciamento do projeto quanto o produto do projeto. • Conformidade com os requerimentos e adequação ao uso que se

propõe: � Conformidade � verificado pela equipe; � Adequação � verificado pelo cliente.

• Não fornecer escopo extra (“gold plating”); • Prevenção antes de inspeção; • Zero defeito; • Alto nível de envolvimento da equipe; • A alta gerência lidera e participa

� Plano de Gerenciamento da Qualidade:

� Como será implementada a politica de qualidade; � Deve definir os procedimentos para o controle da

qualidade, a garantia da qualidade e a melhoria contínua dos processos do projeto.

Gerenciamento dos Recursos Humanos do Projeto

• Processos que organizam e gerenciam a equipe do projeto; � Definição da Equipe:

� Descrição dos recursos humanos disponíveis: • Competências e proficiência • Experiência prévia • Interesses pessoais • Características pessoais • Disponibilidade

� Papéis e Responsabilidades: � Quem faz o que ? � Quem decide o que ?

Obs.: os papéis no projeto devem estar claramente designados aos stakeholders apropriados.



Gerenciamento das Comunicações do Projeto

� A importância da comunicação: � Toma 90% do tempo do Gerente de Projeto; � Afeta todas as partes interessadas no projeto; � Fator determinante de sucesso ou fracasso do projeto; � Correlação direta entre a capacidade de comunicação e o

desempenho do projeto.

� Plano de Gerenciamento das Comunicações: � Quem deve receber quais informações ? � Quais são as reais necessidades de informação ? � Qual informação é necessária, de que tipo ? � Em que formato e meio deve ser transmitida a informação? � Com que frequência ? � Qual é o fluxo de informações ? �



Gerenciamento dos Riscos do Projeto • Processo sistemático de identificação, análise e respostas aos

riscos do projeto. • Inclui maximizar a probabilidade e as consequências de um

evento positivo e minimizar as de eventos negativos que possam ocorrer no projeto.

� Identificar os Riscos:

� Processo contínuo e interativo; � Os riscos devem ser validados; � Quanto mais cedo começar, melhor; � Quanto mais riscos identificados, melhor; � Seja específico; � Não tente fazer tudo de uma só vez; � Produza uma Lista de Riscos.

� Avaliação de Probabilidade e Impacto de Riscos:

� Probabilidade: qual é a chance que o risco ocorra ? � Impacto: consequencia que trará ao projeto se o

risco ocorrer; � Usar indicadores subjetivos (ex: Alto, Médio e

Baixo); � Associar a valores numéricos (ex: Alto = 0,9 // Média

= 0,5 // Baixo = 0,1); � Os indicadores e os valores numéricos são definidos

pela organização e podem ser adequados ao projeto específico.

� Registro de Riscos (atualizações):

� Resultado: • Classificação geral dos riscos dos projetos:

o Quais serão Tratados; o Quais serão analisados de forma

quantitativa.

� Realizar a Análise Quantitativa de Riscos: � Realizada nos riscos que foram priorizados pelo

processo de Realizar a Análise Quantitativa; � Estimar valores para Probabilidade e Impacto (%, $; � Usa ferramentas e técnicas, tais como:

• Análise de Valor Monetário Esperado (VME); • Análise de Árvore de decisão; • Modelagem e simulação � técnica de Monte

Carlo.



� Estratégia para Riscos Negativos ou Ameaças: � Estratégia de respostas (para riscos negativos):

• Eliminar � eliminar o risco, evitando-o totalmente;

• Transferir � passar a responsabilidade e o custo (parcial ou total) da consequência para um terceiro;

• Mitigar � reduzir a probabilidde e/ou impacto do risco, ação realizada independente do risco ocorrer ou não;

• Aceitar: o Passiva � não faz nada, só

documenta e lida com o problema se ocorrer;

o Ativa � cria uma Reserva de Contingência (tempo, dinheiro, recursos, etc) para ser utilizada caso o risco ocorra. Pode criar um Plano de Contingência, para ser acionado caso o risco ocorra.

� Planejar as Respostas aos Riscos:

� Atualização do Registro dos Riscos: • Descrição dos riscos; • Responsáveis por acompanhar os riscos; • Resultados de análisees qualitativas e

quantitativas; • Respostas para cada risco; • Ações de resposta, com custos e prazos

planejados; • Planos de Contingência.



Gerenciamento das Aquisições do Projeto • Processos para comprar ou adquirir os produtos, serviços ou

resultados necessários externos à equipe do projeto para reallizar o trabalho;

� Responsabilidades do Gerente de Projetos:

� Conhecer as políticas de aquisições/compras da empresa;

� Decidir se faz ou compra (análise make or buy); � Entender os termos e condições contratuais; � Conhecer os vários tipos de contratos:

• Preço fixo, Custo reembolsáveis + Remuneração, tempo e Material;

� Administrar os riscos, utilizando o contrato para mitigar ou transferir parte deles sempre que possível;

� Ajustar o cronograma de aquisições ao cronograma do projeto;

� Se envolver na negociação do contrato, quando possível, de forma a proteger a integridade do projeto, tendo habilidade para garantir se o trabalho será completado.

• Resultado: como os processos de aquisição serão gerenciados

desde os documentos de aquisições até o fechamento do contrato;

• O que deverá ser adquirido . . .



Gerenciamento dos Recursos Humanos do Projeto

� Mobilizar a Equipe do Projeto: � Negociação:

• Disputa por recursos entre projetos; • Disputa dos recursos entre o projeto e as

áreas funcionais; • Atenção aos potenciais conflitos,

especialmente em múltiplos projetos;

� Resultado: Lista da Equipe do Projeto � podem ser mobilizados ao longo do projeto, de acordo com o cronograma

Área Função Nome Contato

PMO Gerente de Projetos

Paulo Rogério Ramal 33

Engenharia Engenheiro Senior Luis Carlos Ramal12 ACME S.A. Consultor Mariana Silva Tel. 5555-4444

� Desenvolver a Equipe do Projeto: � Treinamento:

• Inclui as atividades nocessárias para aprimorar as competências dos membros da equipe do projeto;

• Pode ser formal ou informal; • Coaching, mentoring; • Custo é do projeto.

� Atividades de Construção da Equipe: • Pode ser desde cinco minutos em uma

reunião do projeto até um treinamento experiencial ao ar livre com facilitadores profissionais;

• Estimula a comunicação para o desenvolvimento da confiança e estabelecimento de boas relações de trabalho.



� Gerenciar a Equipe do Projeto: � Observações e Conversas:

• Usadas para manter o contato com o trabalho e as atitudes dos membros da equipe do projeto; Ação Proativa!!

� Avaliações do desempenho do Projeto: • Feedback construtivo para os membros da

equipe do projeto. � Gerenciamento de Conflitos:

• Os conflitos são inevitáveis em um ambiente de projeto;

• As origens dos conflitos podem incluir recursos escassos, prioridades de cronograma e estilos de trabalhos pessoais;

• Um gerenciamento de conflitos bem sucedido resulta em maior produtividade e em relacionamentos de trabalho positivos.



Gerenciamento das Comunicações do Projeto

� Distribuir Informações: � Reuniões �� os Gerentes de Projeto participam de

um grande número de reuniões, um dos grandes desafios modernos é tornar essas reuniões sempre efetivas:

• Planejamento • Horários (início e término) • Agenda • Cumprimento de Agenda • Liderança • Disciplina dos Participantes • Documentação

� Reuniões de Acompanhamento: • Regularidade • Discussão dos relatórios • Avaliação de desempenho • Acompanhamento dos riscos • Ações corretivas • Realinhamento das metas • Comunicação aberta • Feedback para a equipe • Atas e Pautas de Reunião e Documentação

Gerenciar as Expectativas das Partes Interessadas

• Agir proativamente sobre as EXPECTATIVAS deles, utilizar a estratégia desenvolvida no inicio;

• Usar o Registro das Questões para mostrar que suas necessidades estão sendo atendidas;

• Um dos maiores problemas dos gerentes de projetos é ficar distante das partes interessadas e ao final, entregarem algo que não é o esperado por elas. Não seja uma caixa preta seja transparente !!!

Gerenciar das Aquisições do Projeto • Agir proativamente sobre as EXPECTATIVAS deles, utilizar a

estratégia desenvolvida no inicio;



http://www.alessandroalmeida.com/files/Workshop.ConhecendoCMMI.pdf link: http://pt.wikipedia.org/wiki/Estrutura_anal%C3%ADtica_do_projeto



CMMI

( http://pt.wikipedia.org/wiki/CMMI )

Conceito

� O CMMI (Capability Maturity Model Integration) é um modelo de referência que contém práticas (Genéricas ou Específicas) necessárias à maturidade em disciplinas específicas (Systems

Engineering (SE), Software Engineering (SW), Integrated Product

and Process Development (IPPD), Supplier Sourcing (SS)). Desenvolvido pelo SEI (Software Engineering Institute) da Universidade Carnegie Mellon, o CMMI é uma evolução do CMM e procura estabelecer um modelo único para o processo de melhoria corporativo, integrando diferentes modelos e disciplinas.

� O CMMI foi baseado nas melhores práticas para desenvolvimento e manutenção de produtos. Há uma ênfase tanto em engenharia de sistemas quanto em engenharia de software, e há uma integração necessária para o desenvolvimento e a manutenção.

� A versão atual do CMMI (versão 1.3) foi publicada em 27 de outubro de 2010 e apresenta três modelos:

� CMMI for Development (CMMI-DEV), voltado ao processo de desenvolvimento de produtos e serviços.

� CMMI for Acquisition (CMMI-ACQ), voltado aos processos de aquisição e terceirização de bens e serviços.

� CMMI for Services (CMMI-SVC), voltado aos processos de empresas prestadoras de serviços.

� Uma das premissas do modelo é "A qualidade é influenciada pelo processo", e seu foco é "Melhorar processo de uma empresa".



Histórico

� Os processos de melhoria nasceram de estudos realizados por Deming (Out of the Crisis), Crosby (Quality is Free: The Art of Making Quality Certain) e Juran, cujo objetivo principal era a melhoria da capacidade dos processos. Entende-se por capacidade de um processo a habilidade com que este alcança o resultado desejado.

� Um modelo tem como objetivo estabelecer - com base em estudos, históricos e conhecimento operacional - um conjunto de "melhores práticas" que devem ser utilizadas para um fim específico.

� O CMMI tem como origens em três outros modelos de maturidade - SW-CMM (SEI Software CMM), EIA SECM (Electronic Industries

Alliances's Systems Engineer Capability Model) e IPD-CMM (Integrated Product Development CMM).

Dimensões

� O CMMI foi construído considerando três dimensões principais: pessoas, ferramentas e procedimentos. O processo serve para unir essas dimensões.

Disciplinas

� O processo inclui quatro disciplinas ou corpos de conhecimento (body of knowledges), sendo eles:

o Engenharia de sistemas o Engenharia de software o Desenvolvimento integrado de produtos e processos (IPPD -

Integrated Product and Process Development) o Fontes de abastecimento (Supplier sourcing)

� A engenharia de software é similar à engenharia de sistemas em relação às áreas de processo, apenas com enfoque diferente nos processos. As áreas de processo requeridas para engenharia de sistemas são as mesmas para engenharia de software, mas o nível de maturidade que é diferente.



Representações

� O CMMI possui duas representações: "contínua" ou "por estágios". Estas representações permitem à organização utilizar diferentes caminhos para a melhoria de acordo com seu interesse.

Representação Continua

� Possibilita à organização utilizar a ordem de melhoria que melhor atende os objetivos de negócio da empresa. É caracterizado por Níveis de Capacidade (Capability Levels):

• Nível 0: Incompleto (Ad-hoc) • Nível 1: Executado • Nível 2: Gerenciado / Gerido • Nível 3: Definido • Nível 4 Gerenciado Quantitativamente (Quantitatively

managed) • Nível 5 Otimizado (Optimizing)

� Nesta representação a capacidade é medida por processos separadamente, onde é possível ter um processo com nível um e outro processo com nível cinco, variando de acordo com os interesses da empresa.

� No nível 1(um) o processo é executado de modo a completar o trabalho necessário para produzir o trabalho necessário. No nível 2(dois) é sobre planejar a execução e confrontar o executado contra o que foi planejado. No nível 3(três) o processo é construído sobre as diretrizes do processo existente, e é mantido uma descrição do processo. No nível 4(quatro) é quando o processo é gerenciado quantitativamente através de estatísticas e outras técnicas. No nível 5(cinco) o processo gerido quantitativamente é alterado e adaptado para atender às necessidades negociais/estratégicas da empresa.

� A representação contínua é indicada quando a empresa deseja tornar apenas alguns processos mais maduros, quando já utiliza algum modelo de maturidade contínua ou quando não pretende usar a maturidade alcançada como modelo de comparação com outras empresas.



Representação Por Estágios

� Disponibiliza uma seqüência pré-determinada para melhoria baseada em estágios que não deve ser desconsiderada, pois cada estágio serve de base para o próximo. É caracterizado por Níveis de Maturidade (Maturity Levels):

• Nível 1: Inicial (Ad-hoc) • Nível 2: Gerenciado / Gerido • Nível 3: Definido • Nível 4: Quantitativamente gerenciado / Gerido

quantitativamente • Nível 5: Em otimização

� Nesta representação a maturidade é medida por um conjunto de processos. Assim é necessário que todos os processos atinjam nível de maturidade dois para que a empresa seja certificada com nível dois. Se quase todos os processos forem nível três, mas apenas um deles estiver no nível dois a empresa não irá conseguir obter o nível de maturidade três.

� Esta representação é indicada quando a empresa já utiliza algum modelo de maturidade por estágios, quando deseja utilizar o nível de maturidade alcançado para comparação com outras empresas ou quando pretende usar o nível de conhecimento obtido por outros para sua área de atuação.



Áreas de Processo

� O modelo CMMI v1.2 (CMMI-DEV) contém 22 áreas de processo. Em sua representação por estágios, as áreas são divididas da seguinte forma:

Nível 1: Inicial (Ad-hoc)

� Não possui áreas de processo.

Nível 2: Gerenciado / Gerido

� Gerenciamento de Requisitos - REQM (Requirements Management)

� Planejamento de Projeto - PP (Project Planning) � Acompanhamento e Controle de Projeto - PMC (Project

Monitoring and Control) � Gerenciamento de Acordo com Fornecedor - SAM (Supplier

Agreement Management) � Medição e Análise - MA (Measurement and Analysis) � Garantia da Qualidade de Processo e Produto - PPQA

(Process and Product Quality Assurance) � Gerência de Configuração - CM (Configuration Management)

Nível 3: Definido

� Desenvolvimento de Requisitos - RD (Requirements Development)

� Solução Técnica - TS (Technical Solution) � Integração de Produto - PI (Product Integration) � Verificação - VER (Verification) � Validação - VAL (Validation) � Foco de Processo Organizacional - OPF (Organizational

Process Focus) � Definição de Processo Organizacional - OPD (Organizational

Process Definition) � Treinamento Organizacional - OT (Organizational Training) � Gerenciamento Integrado de Projeto - IPM (Integrated Project

Management) � Gerenciamento de Riscos - RSKM (Risk Management) � Análise de Decisão e Resolução - DAR (Decision Analysis

and Resolution)



Nível 4: Quantitativamente gerenciado / Gerido

quantitativamente

• Desempenho de Processo Organizacional - OPP (Organizational Process Performance)

• Gerenciamento Quantitativo de Projeto - QPM (Quantitative Project Management)

Nível 5: Em otimização

• Gestão de Processo Organizacional - OPM (Organizational Process Management)

• Análise Causal e Resolução - CAR (Causal Analysis and Resolution)

Modelos e áreas de processo

� As áreas de processo variam com base no modelo escolhido, não sendo as mesmas áreas para todos os modelos (CMMI-DEV, CMMI-ACQ ou CMMI-SVC).



ISO/IEC 15504

A ISO/IEC_15504, também conhecida como SPICE, define um "processo para relatórios técnicos no assessoramento em desenvolvimento de software", e similarmente ao CMMI possui níveis de maturidade para cada processo. O CMMI não é baseado nesta norma, mas sim compatível.

Histórico de Avaliações

� Até o ano de 2002, os EUA tinham realizado 1,5 mil avaliações de CMMI, a Índia feito 153, o Reino Unido 103 e o Brasil apenas 15. Em 2004 a TATA Consultancy Services (empresa indiana) alcançou o nível 5 em todas as unidades da empresa, tendo sido avaliada inclusive a unidade brasileira (a primeira empresa presente no Brasil a receber o nível máximo na avaliação).

� Entre abril de 2002 e junho de 2006 foram conduzidas 1581 avaliações em 1377 organizações. Segue abaixo o resultado obtido pelas empresas na avaliação (resultados encaminhados para o SEI até 30 de junho de 2006):

o 18,2%: nível 5 (Optimizing); o 4,4%: nível 4 (Quantitatively Managed); o 33,8%: nível 3 (Defined); o 33,3%: nível 2 (Managed); o 1,9%: nível 1 (Initial); o 8,4%: sem qualificação (Not Given).



� No Brasil, as empresas listadas a seguir conseguiram a certificação no nível 3:

1997

• Xerox do Brasil

2001

• DBA Engenharia de Sistemas • EDS S • Ericsson • Motorola

2003

• IBM Fábrica de Software • Stefanini

2004

• Accenture Delivery Center • CI&T

2005

• Accenture • Instituto de Pesquisas Eldorado • Politec

2006

• Instituto Atlantico • Qualitas

2007

• Atos Origin • C.E.S.A.R – Recife Center • Itaú • TIVIT • Spress Informática S/A • Vetta Technologies



2008

• 7COMm • B2Br – Business to Business Informática • Kaizen Consultoria e Serviços • Senior Sistemas • Serasa

2009

• Accenture Brazil • CINQ Technologies • e-Core • CWI Software Ltda • CPqD • DATUM • CITS – Centro Internacional de Tecnologia de Software • Hold • NTConsult • Synapsis Brasil Ltda • T-Systems do Brasil • Tlantic SI • Triad System • Unisys Corporation • Sofhar Gestão e Tecnologia

2010

• BSI Tecnologia • Inovare • Itatec • Resource IT Solutions (Fábrica de Projetos) • Resource IT Solutions (Fábrica de Código)

2011

• Chemtech



� O nível 4 foi alcançado pelas empresas:

2003

• EDS

2006

• Ci&T

� Já as empresas abaixo conseguiram realizar a certificação até o final, ou seja, alcançaram o nível 5 do CMMI (por ano da certificação):

2004

• TCS (TATA Consultancy Services) Brazil

2005

• Accenture SP • IBM Brazil • EDS - Electronic Data Systems • Stefanini IT Solutions

2007

• Ci&T[1] • CPM Braxis[2]

2009

• Instituto Atlântico[3] • BRQ IT Services

2011

• Spread Systems [4]

4º . Semestre (2011/2 – Chácara Santo Antonio – 3ª feira) · PDF...

Documents

Transcript of 4º . Semestre (2011/2 – Chácara Santo Antonio – 3ª feira) · PDF...