Arquivos de ‘ Qualidade

As leis universais do gerenciamento de riscos 31 August 2010 as 10:00 pm de Washington Souza

O termo “gestão de riscos” cobre muitos diferentes tipos de riscos, incluindo riscos estratégicos, riscos financeiros, riscos de reputações, riscos operacionais, riscos de projetos, riscos ambientais, riscos legais, riscos de contratos ou riscos técnicos, bem como governância corporativa, continuidade dos negócios e recuperação de desastres. Enquanto cada área dessas possui suas próprias linguagens, processos e técnicas, existem princípios que se aplicam a todas elas.

Isso pode ser chamado de “leis universais de gestão de riscos”.

A primeira lei de gestão de riscos é que o risco é incerteza. Um risco é alguma coisa no futuro que pode ou não ocorrer. Isso é vital para uma compreensão adequada de risco e sua gestão. Riscos não existem ainda, na verdade eles podiam nunca existir.

Eles são eventos futuros potenciais ou conjunto de circunstâncias ou condições. Isso os faz bem diferentes de coisas que aconteceram no passado ou que atualmente existem no presente. Eventos do passado e do presente podem ser analisados e mensurados, mas eventos futuros podem ser somente imaginados ou estimados. Um risco que pode ou não pode existir no futuro, não pode ser vivenciado diretamente antes dele acontecer. Isso faz que os riscos sejam diferentes dos pontos de atenção, problemas ou restrições.

Em todo tipo de gestão de riscos, o risco está no futuro, e herda a incerteza.

A segunda lei é que o risco importa. Se ele ocorre, o risco terá consequencias que o torna diferente em algum aspecto. Não é possível ter um risco inconsequente, por definição. Enquanto vários tipos de gestão de riscos enfatiza os diferentes tipos de consequencia, todos concordam que um risco deve afetar alguma coisa. Isso é porque riscos são fortemente ligados aos objetivos. Onde quer que em algum campo do esforço humano esteja tentando alcançar alguma coisa, é possível identificar incertezas que podem afetar as chances do sucesso.

Leia o post completo →

+ Glossário de termos comuns em TI Por Washington Souza 24 August 2010 as 12:40 am 1 comentário

Olá pessoal, em TI a cada dia cria-se um novo termo e sempre fica a dúvida “O que é isso?”. Bom, como situações como esta são muito comuns, resolvemos compilar uma lista dos termos mais comuns.

Glossário de termos comuns em TI

Ação Corretiva
Ação realizada para eliminar um problema, não conformidade ou situação indesejada a fim de evitar sua repetição.

Ação Preventiva
Ação realizada evitar a ocorrência de um possível problema, não-conformidade ou defeito.

Agile
Modelo de desenvolvimento de software focado nas pessoas. Não há processos definidos, guias ou instituto certificador. A motivação e o cliente são aspectos primordiais nos métodos ágeis, todavia, praticar Agile é mais uma questão de cultura do que guias e processos.

Análise Crítica de Projeto
Análise completa e sistemática de um projeto a fim de avaliar sua capacidade de atender os requisitos para a qualidade, identificar problemas, se houver, e propor o desenvolvimento de soluções.

Análise de Pontos por Função
Técnica de estimativa de sistemas, também conhecida como FPA – Function Point Analysis, baseada na identificação das funções executadas pelos programas, ao invés de utilizar como base o volume ou a complexidade do código dos programas.
A técnica está baseada na visão externa do usuário, sendo portanto, independente da linguagem utilizada, permitindo calcular o esforço de programação e auxiliando o usuário final a melhorar o exame e avaliação de projetos.

Análise de Requisitos
Conjunto de atividades que permite identificar as necessidades do usuário de modo a obter uma definição clara das características (requisitos) de um sistema. Essas características descrevem o sistema em termos de funcionalidades, desempenho esperado, restrições de projeto, níveis de qualidade esperados, interface com outros elementos do sistema.

Auditoria
Verificação sistemática e independente, para determinar se as atividades da qualidade e seus resultados estão de acordo com o planejado, se foram implementadas com eficácia e se são adequadas.

Certificação
Modo pelo qual uma organização independente dá garantia escrita de que um produto, processo ou serviço está em conformidade com os requisitos especificados.

CMMI – Capability Maturity Model Integration
Modelo para avaliação da maturidade dos processos de software de uma organização e para identificação das práticas chave que são requeridas para aumentar a maturidade desses processos.

Confiabilidade
Conjunto de atributos que evidenciam a capacidade do software de manter seu nível de desempenho sob condições estabelecidas durante um período de tempo estabelecido.
Tem como subcaracterísticas: maturidade, tolerância a falhas e recuperabilidade.

Configuração
Relação entre versões de um objeto, ou seja, configuração é uma instância do sistema composta da união de uma versão específica de cada objeto componente. Arranjo de um sistema ou de seus componentes como definidos pelo seu número, natureza e interconexão de suas partes constituintes.

Controle de Versão
Procedimento de gestão do ciclo de vida de um produto. Consiste na identificação formal de modificações solicitadas ou efetuadas e no seu agrupamento, de modo a que fiquem incorporadas, todas elas, em uma determinada configuração do produto, num certo momento. Essa configuração recebe o nome de versão.

Veja o post completo →

+ As sete ferramentas da qualidade Por Washington Souza 13 July 2010 as 12:01 am Nenhum comentário

Ishkawa organizou as sete ferramentas da qualidade após observar que pelo menos 95% dos problemas poderiam ser resolvidos por estas ferramentas. Ele também observou que qualquer trabalhador fabril poderia utiliza-las de forma efetiva. Seu objetivo foi aperfeiçoar o Controle de Qualidade Industrial da década de 1960.

Seu sucesso no Circulo de Controle de Qualidade (CCQ) surpreendeu a todos especificamente quando veio do Japão para o ocidente. Os benefícios aos produtos e serviços japoneses foram tantos que até hoje os produtos daquele país são sinónimo de qualidade.

As sete ferramentas da qualidade são:

  • Diagrama de pareto
  • Diagrama de causa e efeito
  • Histograma
  • Folhas de verificação
  • Gráfico de dispersão
  • Fluxogramas
  • Cartas de controle

Agora, vamos ver como utilizar estas ferramentas de uma forma prática.

Diagrama de pareto

Gráfico de ParetoO principio de Pareto também é muito conhecido como a regra dos 80/20 (alguns também falam de 70/30). Em resumo podemos dizer que:

  • 20% do tempo despendido produz 80% dos resultados
  • 80% de suas ligações telefonicas são destinadas a 20% dos seus contatos
  • 20% das ruas são responsáveis por 80% do trafego (não em São Paulo)
  • 80% dos pedidos em um restaurante vem de 20% do menu
  • 20% de seus clientes são responsáveis por 80% do seu faturamento
  • 80% dos problemas é causado por 20% das pessoas
  • 20% do que deve ser feito ocupa 80% do tempo

Pareto é uma ferramenta fantástica para priorização e focar no que realmente importa. Se há um problema, pareto lhe ajudará a focar.

Diagrama de causa e efeito

Gráfico de Causa x EfeitoO diagrama de causa x efeito (também conhecido como diagrama de Ishikawa) é uma excelente ferramenta utilizada para estruturar hierarquicamente as causas potênciais de um determinado problema (ou oportunidade). Ele permite uma visualização gráfica de todo o “mapa”.

Os elementos são tipicamente organizados em seis categorias:

  • Métodos
  • Matéria prima
  • Mão de obra
  • Maquinas
  • Medições
  • Meio ambiente

Todavia, estes elementos podem ser adaptados.

Um diagrama bem detalhado se parecerá com uma espinha de peixe (como ele também é conhecido) e a partir de uma lista preliminar de causas, as mais prováveis são selecionadas para análise mais aprofundada.

É uma ferramenta primordial em projetos de melhoria, em especial projetos Six Sigma.

Histograma

HistogramaO histograma é uma ferramenta muito utilizada na estatística e apresenta uma representação gráfica da distribuição e frequência dos dados de uma determinada amostra. Normalmente é representado através de barras verticais.

Seu funcionamento é mais ou menos assim: Imagine uma escala de zero a vinte, você divide em barras de 2 em 2, ou seja, se o dado for 1 ou 2 você coloca ma barra “1-2”, se o dado for 3 ou 4 você coloca um ponto na barra “3-4” e assim por diante. Você pega sua amostra e vai colocando nessas “caixinhas” e no final você terá a distribuição dos seus dados.

Com uma evolução do histograma é possível identificar a estabilidade e capacidade de um determinado processo.

Folhas de verificação

Veja o post completo →

+ Entrevista com o CMMI Lead Appraiser Antonio Braga Por Washington Souza 12 July 2010 as 12:01 am Nenhum comentário

Estamos estreando nossa sessão de entrevistas com um convidado de peso, o CMMI Lead Appraiser Antonio Braga. O Sr. Antonio Braga já realizou mais de 60 avaliações SCAMPI CMMI no Brasil e exterior e hoje é uma das maiores referencias sobre CMMI aqui no Brasil.

Nesta nova sessão você encontrará quinzenalmente entrevistas com pessoas que são referência em engenharia de software em geral. Mas… vamos a entrevista…

Entrevista com Antonio Braga

Blog CMMI: Algumas empresas acham que CMMI aumenta o custo, o que você diria a elas?
Braga: CMMI não aumenta o custo. O CMMI é composto pela melhores praticas no desenvolvimento de sistemas. O CMMI incentiva o trabalho segundo processos, sistematização, o que evita re-trabalho e define exatamente as atividades que devem ser seguidas.

Agora muito cuidado deve ser tomado pelas empresas ao definir seus processos e na criação de guias e regras de customização (tailoring) para evitar a criação de camisas-de-força, que engessem seu trabalho.

Blog CMMI: O que uma empresa precisa para iniciar com CMMI?
Braga: O apoio da alta gerencia é fundamental. Um projeto de melhoria de processos compatíveis com o CMMI deve ser iniciado somente quando a organização tem bem definido os benefícios que ira atingir com tal projeto.

A partir daí deve ser alocado um grupo (pode ser uma pessoa) ou ate alocação parcial, para ser responsável pela definição dos processos. Este deve ser primariamente um trabalho de facilitador com o pessoal que efetivamente usa os processos na prática.

Blog CMMI: Quais os pontos que as empresas mais devem ter atenção em um programa de melhoria CMMI?
Braga: Primeiro, os benefícios que a empresa vai atingir.
Não há mágica, não é um trabalho rápido, requer amadurecimento da organização e do pessoal envolvido, isso nos lembra que o primeiro M de CMMI é justamente Maturidade.
Definição de funções, alocação de pessoal e treinamento são fundamentais.

Blog CMMI: Quais os benefícios que uma empresa pode obter com o CMMI?
Braga: O SEI realizou algumas pesquisas sobre este assunto. De um modo geral as empresas que melhoram seus processos usando o CMMI como referência, encontram benefícios como:

  • Aumento de produtividade: Não se re-inventa a roda, o que deve ser feito esta definido.
  • Diminuição de custo: A partir da redução do re-trabalho e aumento de produtividade.
  • Estimativas mais corretas: Isso gera propostas mais adequadas o que pode representar mais negócios. Estimativas mais corretas evitam projetos deficientes.
  • Qualidade: A padronização dos processos e uso das melhores práticas te leva a gerar produtos de melhor qualidade.
  • Aumento da Satisfação do cliente: Há um aumento de satisfação por parte do cliente através da entrega de produtos de melhor qualidade e nos prazos acordados.

Veja o post completo →

+ Os dez mandamentos da solução de problemas na qualidade total Por Washington Souza 11 July 2010 as 12:58 am Nenhum comentário

1. Terás consciência dos problemas
Falar que não o problema não existe não o eliminará, a primeira e principal ação para a resolução de problemas é admitir sua existência. Tipicamente há problemas em todo lugar e consequentemente há oportunidades de melhorias em todo lugar.
.
2. Deverás entender as condições reais através de dados
Lembre-se sempre de tomar decisões com base em dados. Um conjunto correto de dados vale mais que 100 palpites. Esqueça também aquela velha história de que “não temos dados”, use os que você tem pois estes são seus dados e se você gostaria de tê-los de outra forma, melhore-os e posteriormente faça outra coleta.
.
3. Usarás métodos de gerenciamento da qualidade meticulosamente e efetivamente
Não é a qualidade que deixa caro seu projeto, o que deixa ele caro é a falta de qualidade, e já que você sabe disso, porque não tentar aumentar a qualidade? Fazendo isto, com certeza seu custo será reduzido. Lembre-se também de usar a ferramenta certa para cada problema.
.
4. Arregaçaras as mangas e trabalharás, fazendo o máximo uso de tecnologia, experiência e intuição
Há um velho ditado que diz: “Quanto mais eu trabalho, mais sorte eu tenho”, então, o trabalho duro e uso de técnicas avançadas são indispensáveis (e não matam ninguém). Não tenha medo de usar técnicas novas, muitas vezes, serão estas que terão mais efeito. Conheça (e compreenda) as 7 ferramentas da qualidade.
.
5. Seguirás cuidadosamente passo a passo a metodologia de solução de problemas
Um atalho muitas vezes pode destruir o efeito (afinal, porque você acha que existe o passo a passo?). Estes somente devem ser utilizados com sabedoria e quando do conhecimento correto dos métodos. Não arrisque pular algo se você não conhece ou não o compreende.
.
6. Analisarás completamente as causas, e não demorarás a agir
Ação! Uma vez conhecidas as causas, estas devem ser tratadas o quando antes. Utilize técnicas de análise de causa e efeito (CAR) e identifique as causas reais do problema (e não as que as pessoas acham que são as causas). Se você direcionar ações a uma causa incorreta, seu problema persistirá.
.
Veja o post completo →

+ Entrevista sobre Six Sigma para a LG Por Washington Souza 30 June 2010 as 8:01 pm Nenhum comentário

LG: O que é Six Sigma?

Washington: O Six Sigma (ou seis sigma) é um modelo que foi criado inicialmente pela Motorola para melhoria de processos e redução de defeitos. Define-se como um defeito, uma anomalia em um produto ou serviço contra suas especificações iniciais. O Six sigma é altamente utilizado no planejamento estratégico para prover mudanças significativas nas organizações. Ele é aplicado tanto na redução de defeitos quanto na busca de oportunidades de melhoria.

Dentro do Six Sigma, existe uma “metodologia” muito difundida que é o DMAIC. Este método tem por objetivo guiar as pessoas na elaboração de um projeto Six Sigma e é dividido em cinco fases:

D – Define: Nesta fase é definido o problema ou oportunidade e quantificação do mesmo bem como o benefício esperado. A equipe do projeto (com Black Belts e Green Belts) é definida e realiza-se o primeiro estudo de viabilidade do projeto. No final desta fase o Champion define se o projeto continuará ou não.

M – Measure: Definem-se quais fatores serão medidos e inicia-se a coleta de dados. Uma boa prática é identificar logo nesta fase os fatores (X’s) que podem influenciar no problema (Y). Para isto, uma técnica muito utilizada é o diagrama de causa x efeito (ishikawa).

A – Analyse: Nesta fase são realizados todos os testes nos dados e testes estatísticos para identificar quais fatores influenciam de fato no problema (ou oportunidade). O conhecimento em estatística básica é fundamental para os primeiros projetos.

I – Improve: Nesta fase são definidas melhorias para cada um dos fatores (que tem correlação com o problema). Após a análise de viabilidade, são selecionadas as melhorias e um plano de implantação das mesmas é elaborado.

C – Control: Define-se o método de controle e realiza-se o controle propriamente dito. Após o período piloto, o Black Belt verifica se as mudanças realmente trouxeram resultados (e quanto foi o resultado).

“Assim como Pareto (uma das técnicas utilizadas), o Six Sigma foca no que realmente esta trazendo problema, ou seja, 80% dos problemas vêm de 20% das causas”.

LG: O que representa a metodologia Six Sigma para a melhoria de processos de TI e como ela pode ser aplicada para a prestação de serviços nessa área?

Washington: Apesar de pouco utilizado na TI, o Six Sigma é um dos melhores meios para se implementar processos de melhoria em nossa área, pois ele segue um ciclo definido que vai desde a identificação do problema até a implementação de melhorias que vão afetar as causas reais dos problemas (ou oportunidades). Muitas empresas de TI “descobrem” o Six Sigma quando estão indo para os níveis de maturidade CMMI 4 ou MPS.Br B, isso porque estes níveis requerem um processo de melhoria quantitativo e não qualitativo como nos níveis anteriores.

Em TI podemos utilizar este modelo para melhorias em projetos de melhoria de alto impacto como, por exemplo: “Reduzir a taxa de defeitos”, “Melhorar a Satisfação dos Clientes”, “Aumentar a produtividade” e outros.

Veja o post completo →

+ Pesquisa de Qualidade no Setor de Software Brasileiro de 2009 Por Washington Souza 24 June 2010 as 1:00 am 1 comentário

O SEPIN (Secretaria de Política de Informática – MCT) acaba de divulgar a nova edição da Pesquisa de Qualidade no Setor de Software Brasileiro. Lançada originalmente em 1993, teve cinco edições bianuais até a publicação da ultima edição em 2002. A pesquisa é bem interessante e responde diversas dúvidas que temos sobre o nosso mercado de TI. Você ficará sabendo de coisas interessantes como: “Você sabia que a região sudeste praticamente concentra metade da TI brasileira?” e “Que a maioria das empresas de TI é de pequeno porte?” entre outras.

O relatório esta bem detalhado e você encontrará também:

  • Em qual região estão as empresas de TI
  • Qual o percentual de capital estrangeiro médio
  • Volume médio de faturamento (nacional e externo)
  • Qual o tipo de software e ramo de atuação onde há mais foco
  • O que as empresas levam em conta para selecionar um fornecedor
  • Avaliações CMMI e MPS.Br
  • Tipos de métricas utilizadas para dimensionamento
  • E outras informações.

Download da Pesquisa de Qualidade no Setor de Software Brasileiro de 2009

Dica enviada pelo professor Renato Della Volpe

+ Qualidade e a copa do mundo Por Washington Souza 19 June 2010 as 8:11 pm Nenhum comentário

Em tempos de copa do mundo, obviamente não podemos deixar de tocar no assunto, mas, vamos falar de copa do mundo e qualidade, mais especificamente da bola utilizada na copa do mundo. Aparentemente, o processo de criar uma bola de futebol não tem muito segredo, mas, não é bem assim. Segundo a Adidas, a Jabulani (bola oficial da copa) é a mais moderna e com mais tecnologia de todos os tempos. E é interessante que mesmo assim, muitos jogadores e goleiros tem criticado a pelota. O mais interessante é que isso acontece sempre, em toda copa, e depois o pessoal acaba se adaptando e a mesma vira objeto de desejo. Será que com essa será diferente?

O processo de qualidade da FIFA é bem rígido e eles não escolheriam qualquer bola para um evento tão importante quanto a Copa, então, ele criaram vários critérios para definir o que seria a bola ideal.

Assim como nos projetos, são definidos diversos critérios que definem o que é um bom projeto ou um bom serviço, e alguns mais críticos possuem um critérios de qualidades maiores que outros como por exemplo um sistema em um avião ou um sistema hospitalar. Nesses casos, um erro significa vidas.

Voltando a bola, a FIFA possui dois níveis de qualidade oficiais:

Inspecionadas pela FIFA

São bolas comuns (muito boas) que devem atender um conjunto de critérios e passar por alguns testes

A bola deve ser esférica e fabricada de couro A circunferência deve estar entre 68cm e 70cm à pressão normal Deve ter peso entre 410g e 450g e a pressão ao nível do mar deve ficar entre 600 e 1.100 g/cm2

Veja o post completo →

+ Dez mitos sobre as práticas genéricas Por Washington Souza 14 June 2010 as 10:34 pm Nenhum comentário

Antes de iniciarmos, temos que ter em mente que as práticas genéricas são elementos mandatários do CMMI e seu objetivo central é a institucionalização, mas… o que é institucionalização?

O CMMI define como institucionalização: “A maneira de se fazer negócios que uma organização segue rotineiramente como parte de sua cultura corporativa”. Em outras palavras, o jeito que as coisas são feitas aqui.

Diversos elementos podem atrapalhar a implementação das práticas genéricas como menosprezar a importância da institucionalização, foco apenas nas práticas específicas ou até mesmo sub-estimar o tempo e esforço necessário para sua implementação.

Vamos falar da Generic Goal 2:

  • GP 2.1 Estabelecer uma política organizacional
  • GP 2.2 Planejar o processo
  • GP 2.3 Prover recursos
  • GP 2.4 Atribuir responsabilidades
  • GP 2.5 Treinar as pessoas
  • GP 2.6 Gerenciar configurações
  • GP 2.7 Identificar e envolver stakeholders relevantes
  • GP 2.8 Monitorar e controlar o processo
  • GP 2.9 Analisar aderência objetivamente
  • GP 2.10 Revisar o status com a alta direção

Mitos sobre práticas genéricas

GP 2.1 Mito 1: “Tudo que precisamos fazer é escrever algumas políticas e pedir para o CIO assina-las”

  • As políticas podem virar um papel que nunca ninguém irá ler
  • As políticas devem definir claramente o que deve ser feito
  • Se as políticas documentarem o que a alta gerência realmente acredita ser importante, as chances delas serem seguidas aumentam considerávelmente.

GP 2.2 Mito 2 “Um plano para cada área de processo”

  • O perigo dos infinitos planos “Aqui esta o plano para coletar as métricas de PPQA”
  • O planejamento apropriado deve ser realizado para cada área de processo envolvido
  • Garantir tempo, esforço e custo suficiente para executar as tarefas necessárias para realizar cada processo

GP 2.3 Mito 3: “Esta prática e apenas para garantir que teremos pessoas suficientes”

  • O risco de focar apenas em pessoas: “Nunca teremos pessoas suficientes”
  • Recursos INCLUEM custo, instalações, ferramentas e obviamente pessoas
  • “Recursos adequados” quer dizer que o processo pode ser seguido naturalmente sem restrições de custo, prazo ou pessoas

GP 2.4 Mito 4: “As pessoas não precisam da descrição de seu serviço”

  • Não assuma que as pessoas compreenderam suas responsabilidades e nível de autoridade
  • Defina claramente papéis e responsabilidades que alinhem as pessoas ao serviço realizado
  • Faça as pessoas compreenderem seus papel e defina a autoridade necessária para realizar seu trabalho

Veja o post completo →

+ As 10 desculpas mais comuns para não iniciar um programa de melhoria CMMI ou MPS.Br Por Washington Souza 28 May 2010 as 10:05 pm 1 comentário

  1. Eu não tenho tempo para isso… Volte mais tarde?- Não existe melhor hora que agora para implementar um processo de melhoria em seu projeto
    - Não há tempo para melhorar, mas há tempo para fazer errado?
    - Discuta o projeto e discuta seus pontos problemáticos e identifique oportunidades de melhoria
  2. Eu não acredito nisto (ou não vejo benefício nenhum)
    - Mostre o ROI (retorno sobre o investimento) que o programa trará
    - Peça para outros gerentes de projetos falarem dos benefícios de um programa de melhoria
    - Mostre pesquisas de mercado
  3. Meus clientes estão contentes com meu trabalho. Não preciso mudar nada
    - Novamente, discuta os pontos problemáticos do projeto
    - “Você não gostaria de deixar seus clientes mais contentes?”
    - (“Somente uma pessoa mediocre acha que sempre esta fazendo seu melhor” – William Somerset Maugham)
    - Sempre pode-se melhorar – Veja os dados por exemplo de melhorias Six Sigma
  4. É apenas moda, daqui a pouco passa e inventam outra
    - Mostre o quanto o mercado tem adotado modelos como CMMI e MPS.Br
    - O CMMI existe desde os anos noventa – será que isto é uma moda?
    - No Brasil mais de 300 empresas já passaram por avaliações CMMI ou MPS.Br
  5. É muito caro
    - Mostre os dados de ROI
    - Você já tentou isso antes? Se sim, me mostre os dados de custo.
    - O programa se paga rapidamente com o retorno com qualidade e produtividade
    - Você já conhece o custo da não qualidade de sua empresa?
  6. Não é aplicável ao meu projeto (aqui é diferente)
    - Peça para o gerente de projetos descrever como o projeto é gerenciado. Depois identifique as oportunidades onde o programa de melhoria de processos pode ajudar.
    - Os principios são os mesmos, os modelos podem ajudam em qualquer tipo de projeto
  7. Meu cliente não paga por isso
    - Seu cliente não tem que pagar por qualidade, isto é obrigação da empresa
    - As “melhores práticas” são coisas que você deve fazer de qualquer jeito
    - Se você não fizer, seu concorrente vai fazer antes de você
  8. Veja o post completo →

+ O que muda com o CMMI 1.3? Por Washington Souza 20 May 2010 as 12:01 am 2 comentários

Com a chegada do CMMI 1.3, muitos estão se perguntando: “O que vai mudar no CMMI 1.3?”. Esperado para novembro de 2010, esta versão incluirá melhorias em todos os modelos CMMI (CMMI-DEV 1.3, CMMI-ACQ 1.3 e CMMI-SVC 1.3).

Este update também trará melhorias ao método de avaliação SCAMPI e treinamentos CMMI relacionados. Segundo o SEI, as mudanças não irão exigir grandes mudanças ou reciclagem dos modelos implementados.

As principais mudanças no modelo serão:

Maior esclarecimento sobre Alta Maturidade

Como já é de conhecimento, quando você realiza uma avaliação SCAMPI, seu resultado reflete um nível de maturidade da organização. Organizações iniciantes no CMMI são tipicamente classificadas como Baixa Maturidade enquanto aquelas que tem mais tempo ou tem obtido melhores resultados são consideradas “exemplares de alta maturidade”.

Na versão 1.3, uma das grandes mudanças será um melhor esclarecimento e entendimento do que é Alta Maturidade. Foi criado um time com foco em alta maturidade e os membros dessa equipe tem se concentrado em fazer mudanças que melhorem a clareza do que é e como alcançar este nível.

O SEI sabe que na versão 1.2, alta maturidade está confuso levanto à uma variedade infinita de interpretações e é exatamente este ponto que eles querem resolver. Quer um exemplo: Pergunte a 5 pessoas o que é um modelo de desempenho e você terá 5 respostas diferentes (e provavelmente nenhuma certa).

A equipe pretende esclarecer os seguintes pontos:

  • O papel do material informativo nas avaliações de alta maturidade
  • O significado e uso dos modelos de processos e modelagem de processos
  • Como os objetivos de negócio estão ligados à alta maturidade
  • O que são causas comuns e como devem ser utilizadas
  • O que se espera de alta maturidade no desempenho individual de cada processo
  • A seleção, definição e o nível de instanciação dos subprocessos

A equipe de Alta Maturidade do SEI está focada nas PAs OPP – Organization Process Performance, QPM – Quantitative Project Management, OID – Organizational Innovation and Deployment e CAR – Causal Analysis and Resolution.

Veja o post completo →

+ Resultado da enquete: O que mais te irrita em um projeto Por Washington Souza 16 May 2010 as 7:23 pm Nenhum comentário

O resultado de nossa primeira enquete foi dentro do esperado (pelo menos do que eu esperava). Quase metade respondeu que o que mais irrita e a má qualidade. O segundo colocado foi uma surpresa, pois com 27% dos votos, a Baixa experiência da equipe realmente irrita nossos leitores – Os fornecedores de serviços de TI devem prestar bastante atenção nesses dois fatores que abocanharam quase 75% dos votos.

Resultado da enquete: O que mais te irrita em um projeto

Obrigado por participarem da enquete!