Organização com CMMI nível 2

1. CMMI Nível 2

No nível de maturidade 2, uma organização atingiu todas as metas específicas e genéricas das áreas de processos do nível 2 de maturidade. Em outras palavras, os projetos da organização
asseguraram que os requisitos são gerenciados e que os processos são planejados, executados, medidos e controlados.
A disciplina dos processos refletida pelo nível 2 de maturidade ajuda a assegurar que as práticas existentes são mantidas em momentos de stress. Quando estas práticas existem, os projetos são executados e gerenciados de acordo com seus planos documentados.
No nível 2 de maturidade, os requisitos, processos, produtos de trabalho e serviços são gerenciados. A situação dos produtos de trabalho e a entrega dos serviços são visíveis para o gerenciamento em pontos definidos (por exemplo, nos milestones principais e no momento em que as principais tarefas são completadas).
Compromissos são estabelecidos entre os stakeholders relevantes e são revistos conforme necessário. Os produtos de trabalho são revisados com os stakeholders e controlados. Os produtos de trabalho e serviços satisfazem seus requisitos, padrões e objetivos definidos

• As políticas e procedimentos para GERENCIAR o desenvolvimento do software estão definidas e são obedecidas.
• O planejamento de novos projetos é baseado na experiência anterior em projetos semelhantes, de maneira formalizada e não intuitiva.
• Os projetos usam processos que são definidos, documentados, usados, disseminados, medidos, fiscalizados e com rotinas de melhoria
• Os compromissos são assumidos com bases realistas na experiência acumulada e nos requisitos documentados
  
• O desenvolvimento é acompanhado e os planos são revisados de maneira regular quanto aos prazos, custos, estimativas e funcionalidade
• Existem mecanismos formais para a correção de desvios
• A gestão de requisitos formalizada permite um controle do relacionamento com o cliente e
  assegura que o desenvolvimento está obedecendo às suas expectativas
• O relacionamento com eventuais fornecedores subcontratados é controlado e gerenciado
  formalmente
• Toda a definição e estabelecimento dos processos, no nível 2, é feita por projeto, não há necessidade de padronização na organização
• Existe uma clara visibilidade e controle de todos os aspectos GERENCIAIS do desenvolvimento em toda a cadeia gerencial
• Os processos podem ser repetidos com resultados previsíveis
  
• Os processos afetados são puramente gerenciais (não técnicos) e pertencem aos projetos, e não às pessoas

2. Papéis e responsabilidades para os diferentes processos.

A seção seguinte contém todas as áreas de processos que pertencem ao nível de maturidade 2. As áreas de processos do nível de maturidade 2 do CMMI são:

• Gerenciamento de Requisitos (Requirements Management) -REQM
  
• Planejamento do Projeto (Project Planning) - PP
  
• Monitoramento e Controle do Projeto (Project Monitoring and Control) - PMC
  
• Gerenciamento de Acordos com Fornecedores (Supplier Agreement Management) - SAM
  
• Medições e Análises (Measurement and Analysis) - MA
  
• Garantia da Qualidade do Processo e do Produto (Process and Product Quality Assurance) -PPQA
  
• Gerenciamento de Configurações (Configuration Management) - CM
  

Abaixo estão relacionado os processos exigidos no CMMI Nível 2 para cada profissional da organização da área de TI e suas responsabilidades.

Figura 1: Profissionais de TI relacionado

Engenheiro de Processos: O papel engenheiro de processo é responsável pelo processo de desenvolvimento de software. Isso inclui configurar o processo antes da inicialização do projeto e aprimorar o processo regularmente durante o esforço de desenvolvimento. Uma pessoa que atua como engenheiro de processo deve ter vasto conhecimento do desenvolvimento de software. É fundamental que uma pessoa que desempenha este papel tenha boas habilidades de comunicação.

Figura 2 - Artefatos gerados pelo Engenheiro de Processos

Principais Artefatos a Serem Produzidos.

• Avaliação da Organização de Desenvolvimento: A Avaliação da Organização de Desenvolvimento descreve o status atual da empresa de software em termos de atuais processos, ferramentas, competências e atitudes das pessoas, clientes, concorrentes, tendências técnicas, problemas e áreas de melhoria.
• Caso de desenvolvimento:O Caso de Desenvolvimento descreve o processo de desenvolvimento escolhido para ser seguido no projeto.
• Templates Especificos de Projeto: São os templates para relatórios e artefatos de documento usados no projeto. Podem existir também templates para modelos e elementos de modelagem, como o modelo de design.

Gerente de Projeto: O papel gerente de projeto aloca recursos, ajusta as prioridades, coordena interações com clientes e usuários e geralmente mantém a equipe do projeto concentrada na meta certa. O gerente de projeto também estabelece um conjunto de práticas que garantem a integridade e a qualidade dos artefatos do projeto.

As habilidades e a experiência necessárias para desempenhar o papel Gerente de Projeto dependem do tamanho e da complexidade técnica e de gerenciamento do projeto, porém, em graus variados. Para desempenhar o papel Gerente de Projeto conforme definido pelo Rational Unified Process (RUP), você deve:

• ter experiência no domínio do aplicativo e no desenvolvimento de software
• ter habilidades de análise e gerenciamento de riscos, estimativa, planejamento e análise de decisões
• ter habilidades de apresentação, comunicação e negociação
• mostrar capacidade de liderança e de desenvolver o espírito de equipe
• ter boa capacidade de gerenciamento de tempo e triagem e um histórico de decisões acertadas tomadas rapidamente em situações de stress
• ter boas habilidades de relacionamento interpessoal e mostrar opinião sensata na seleção de pessoal
• ser objetivo na definição e avaliação do trabalho, assegurando a participação de toda a equipe
• compartilhar a visão de arquitetura, mas ser pragmático no escopo e na implementação de planos e completamente honesto na avaliação dos resultados
• ter como objetivo agregar valor ao cliente na forma de software que atenda (ou ultrapasse) às expectativas do cliente.

Figura 3 - Artefatos gerados pelo Gerente de Projeto

Principais artefatos a serem produzidos.

• Avaliação de Interação: captura o resultado de uma iteração, até que ponto os critérios de avaliação foram respeitados, as lições aprendidas e as mudanças que devem ser feitas.
• Plano de Interação: Um conjunto de atividades e tarefas divididas por seqüências de tempo, com recursos atribuídos e dependências de tarefas, para a iteração; um plano sofisticado.
• Caso de Negócio: fornece as informações necessárias do ponto de vista de um negócio, para determinar se vale ou não a pena investir no projeto.Para um produto de software comercial, o Caso de Negócio deve incluir um conjunto de suposições sobre o projeto e a ordem de importância do retorno do investimento (ROI) se essas suposições forem verdadeiras. Por exemplo, o retorno do investimento terá importância cinco, se concluído em um ano, dois, se concluído em dois anos, e um número negativo, após esse tempo. Essas suposições são verificadas novamente no fim da fase de Elaboração, quando o escopo e o plano estiverem definidos com mais exatidão.
• Plano de Garantia de Qualidade é um artefato que oferece uma visão clara de como a qualidade do produto, do artefato e do processo será garantida. Ele contém o Plano de Revisão e Auditoria e faz referência a uma série de outros artefatos desenvolvidos durante a fase de Iniciação. Ele é mantido no decorrer do projeto.
• Plano de Desenvolvimento de Software é um artefato composto e abrangente que reúne todas as informações necessárias ao gerenciamento do projeto. Ele inclui vários artefatos separados, desenvolvidos durante a Fase de Iniciação, e é mantido durante todo o projeto.
• Avaliação de Status: Um dos objetivos do processo é assegurar que as expectativas de todas as partes estejam sincronizadas e consistentes. A Avaliação de Status periódica fornece um mecanismo que permite gerenciar as expectativas de cada pessoa durante o ciclo de vida do projeto.
• Ordem de trabalho: é o meio pelo qual o Gerente de Projeto comunica à equipe responsável o que deve ser feito e quando. A ordem passa a ser um contrato interno entre o Gerente de Projeto e aqueles que têm a responsabilidade de cumpri-lo.
  

Principais Repositórios de dados e documentos a serem utilizados pelo projeto

• Métricas de Projeto: O artefato de métricas de projeto é o repositório ativo de dados de métricas do projeto. Ele contém as métricas mais atuais de produto, processo, recursos e projeto no nível primitivo e derivado

Gerente de Controle de Mudanças: O papel gerente de controle de mudança supervisiona o processo de controle de mudanças. Normalmente, este papel é desempenhado por um Comitê de Controle de Configuração (ou Mudança) (CCB), formado por representantes de todas as partes interessadas, incluindo clientes, desenvolvedores e usuários. Em projetos pequenos, um único membro da equipe, como o gerente de projeto ou o arquiteto de software, pode desempenhar esse papel.

Figura 4: Artefatos produzidos pelo gerente de controle de mudanças

Principais artefatos a serem produzidos

• Solicitação de Mudanças: As mudanças nos artefatos de desenvolvimento são propostas através de Solicitações de Mudança (CRs). As Solicitações de Mudança são usadas para documentar e controlar defeitos, solicitações de melhorias e qualquer outro tipo de solicitação de mudança no produto. A vantagem das CRs é que elas fornecem um registro das decisões e, devido a seu processo de avaliação, garantem que os impactos das mudanças sejam entendidos no projeto.

Gerente de Configuração: Disponibiliza o ambiente e a infra-estrutura geral de Gerenciamento de Configuração (CM) para a equipe de desenvolvimento do produto. A função de CM oferece suporte à atividade de desenvolvimento de produtos para que os desenvolvedores e integradores tenham espaços de trabalho adequados para criar e testar seus trabalhos e, dessa forma, permite que todos os artefatos fiquem disponíveis para inclusão na unidade de implantação, conforme necessário. O gerente de configuração também deve assegurar que o ambiente de CM facilite a revisão do produto e as atividades de controle de mudanças e defeitos. O gerente de configuração também é responsável por redigir o Plano CM e relatar estatísticas de andamento com base nas solicitações de mudança.

Figura 5 - Artefatos e repósitorios de responsabilidade do Gerente de Configuração

• Plano CM: O Plano de Gerenciamento de Configuração (CM) descreve todas as atividades do Gerenciamento de Controle de Configuração e Mudança (CCM) que serão executadas durante o ciclo de vida do produto ou do projeto. Ele detalha o cronograma de atividades, as responsabilidades atribuídas e os recursos necessários, como equipes, ferramentas e computadores.
• Registro de Auditoria de Configuração: identifica uma baseline, qualquer artefato necessário ausente e requisitos reprovados ou testados de forma incompleta.

Principais Repositórios de dados e documentos a serem utilizados pelo projeto

• Repositório de Projeto:Local que fica armazenado todas as mudanças de configuração do projeto

Revisor do Projeto: O papel revisor do projeto é responsável por avaliar os artefatos de planejamento e de avaliação do projeto nos principais pontos de revisão do ciclo de vida do projeto. Esses eventos de revisão são importantes porque marcam pontos nos quais o projeto pode ser cancelado se o planejamento for inadequado ou se o andamento se mostrar intoleravelmente improdutivo.

Figura 6 - Artefatos produzidos pelo revisor de projetos

Principais artefatos a serem produzidos

• Registro de revisão: é criado para capturar os resultados da revisão de um artefato de projeto.

Gerente de Teste: tem a responsabilidade geral pelo êxito do esforço de teste. O papel envolve defesa da qualidade e dos testes, planejamento e gerenciamento de recursos e resolução de problemas que representam um obstáculo para o esforço de teste. Isso inclui:

• Negociar a finalidade e os produtos liberados do esforço de teste
• Assegurar o planejamento e o gerenciamento apropriados dos recursos de teste
• Avaliar o andamento e a eficácia do esforço de teste
• Defender o nível apropriado de qualidade mediante a correção de Defeitos importantes
• Defender um nível apropriado de enfoque na testabilidade durante o processo de desenvolvimento de software

Figura 7 - Gerente de Testes

Principais artefatos a serem produzidos

• Lista de problemas: A Lista de Problemas fornece ao Gerente de Projeto uma maneira de registrar e acompanhar problemas, exceções, anormalidades ou outras tarefas incompletas que requeiram atenção em termos de gerenciamento do projeto. Em geral, são itens que não estão sendo acompanhados durante o Gerenciamento de Mudança ou como tarefas no Plano de Projeto ou no Plano de Iteração, embora possam ser provenientes deles.
• Solicitação de Mudanças: As mudanças nos artefatos de desenvolvimento são propostas através de Solicitações de Mudança (CRs). As Solicitações de Mudança são usadas para documentar e controlar defeitos, solicitações de melhorias e qualquer outro tipo de solicitação de mudança no produto. A vantagem das CRs é que elas fornecem um registro das decisões e, devido a seu processo de avaliação, garantem que os impactos das mudanças sejam entendidos no projeto.

Analista de Sistemas: O papel analista de sistemas lidera e coordena a identificação de requisitos e a modelagem de casos de uso, delimitando o sistema e definindo sua funcionalidade; por exemplo, estabelecendo quais são os atores e casos de uso existentes e como eles interagem

Figura 8 - Artefatos e repositórios gerados pelo Analista de Sistemas

Principais Artefatos a serem Produzidos

• Plano de Gerenciamento de Requisitos: Descreve a documentação de requisitos, os tipos de requisitos e seus respectivos atributos de requisitos, especificando as informações e os mecanismos de controle que devem ser coletados e usados para avaliar, relatar e controlar mudanças nos requisitos do produto.
• Guia de modelagem de Casos de Uso: Descreve como modelar os casos de uso.
• Solicitação dos principais envolvidos: Este artefato contém qualquer tipo de solicitação dos principais envolvidos (cliente, usuário final, pessoal de marketing etc.) em relação ao sistema que será desenvolvido. Ele também pode conter referências a qualquer tipo de fonte externa com a qual o sistema deve estar de acordo.
• Visão: A visão que os envolvidos têm do produto a ser desenvolvido, em termos das necessidades e características mais importantes. Por conter uma descrição dos requisitos centrais pretendidos, ela proporciona a base contratual para requisitos técnicos mais detalhados.

Principais Repositórios de dados e documentos a serem utilizados pelo projeto

• Atriburtos de Requisitos: Este artefato contém um repositório de dependências, atributos e requisitos de projeto para controlar a partir de uma perspectiva de gerenciamento de requisitos.

Revisor do Modelo de Negócio: O revisor do modelo de negócios participa das revisões formais do modelo de casos de uso de negócios e do modelo de objetos de negócios.

Figura 9 - Revisor do modelo de negócio

Analista do Processo de Negócio: lidera e coordena a modelagem de casos de uso de negócios, definindo e delimitando a organização que está sendo modelada; por exemplo, estabelecendo quais são os atores de negócios e casos de uso de negócios existentes e como eles interagem.

Figura 10 - Analista do Processo de Negócio

Principais Artefatos a serem Produzidos

• Documento da Arquitetura de negócio: O Documento de Arquitetura de Negócios fornece uma visão geral abrangente do negócio, usando diversas visões arquiteturais diferentes para descrever diferentes aspectos do negócio.
• Guia de modelagem de Negócio: Descreve as diretrizes de modelagem de negócios.
• Avaliação da Organização Alvo: A Avaliação da Organização-alvo descreve o status atual da organização em que o sistema deverá ser implantado. A descrição é em termos de processos atuais, ferramentas, competências de pessoas, atitudes de pessoas, clientes, concorrentes, tendências técnicas, problemas e áreas de melhoria.

Analista de Teste: O papel Analista de Teste é responsável por inicialmente identificar e posteriormente definir os testes necessários, monitorar a abrangência dos testes e avaliar a qualidade geral obtida ao testar os Itens de Teste-alvo. Este papel também envolve a especificação dos Dados de Teste necessários e a avaliação do resultado dos testes conduzidos em cada ciclo de teste. Às vezes, este papel também é denominado Designer de Teste ou considerado parte do papel Testador. Este papel é responsável por:

• Identificar os Itens de Teste-alvo a serem avaliados pelo esforço de teste
• Definir os testes apropriados necessários e quaisquer Dados de Teste associados
• Coletar e gerenciar os Dados de Teste
• Avaliar o resultado de cada ciclo de teste

Figura 11 - Principais artefatos produzidos pelo Analista de Testes

Principais Artefatos a serem Produzidos

• Plano de Testes: A definição das metas e dos objetivos dos testes no escopo da iteração (ou projeto), os itens-alvo, a abordagem adotada, os recursos necessários e os produtos que serão liberados.
• Lista de ideias de teste: É uma lista enumerada de idéias, geralmente formada parcialmente e que identifica possíveis testes úteis a serem conduzidos.
• Caso de testes: É a definição (geralmente formal) de um conjunto específico de inputs de teste, condições de execução e resultados esperados, identificados com a finalidade de avaliar um determinado aspecto de um Item de Teste-alvo.
• Modelo de Analise de Carga de Trabalho: Modelo que identifica um ou mais perfis de carga de trabalho destinados a definir com precisão o estado de interesse de um sistema no qual a avaliação do software e/ou de seu ambiente operacional pode ser realizada. Os perfis de carga de trabalho representam possíveis condições a serem simuladas e comparadas aos Itens de Teste-alvo em uma ou mais Configurações de Ambiente de Teste.

Principais Repositórios de dados e documentos a serem utilizados pelo projeto

• Dados de Testes: A definição (geralmente formal) de um conjunto de valores de entrada de teste que são usados durante a execução de um teste, e os resultados esperados mencionados para fins de comparação durante a execução de um teste.
• Resultados de testes: Um conjunto de informações resumidas determinadas pela análise de um ou mais Registros de Teste e Solicitações de Mudança, que permitem uma avaliação relativamente detalhada da qualidade dos Itens de Teste-alvo e do status de cada esforço de teste. Muitas vezes, é também consultado como um repositório maior de vários Resultados do Teste.

3. Conclusões

A implantação do nível de maturidade CMMI nível 2, exige um time de profissionais com conhecimentos tecnicos e do negócio. Para atingir este nível de maturidade uma serie de artefatos e profissionais são necessários, sendo uma tarefa trabalhosa e que exige que o gerente de projeto mostre os resultados para a alta gerencia para justificar a implementação pois o seu retorno não e imediato.
Uma boa prática e a utilização dos artefados gerados RUP - Rational Unified Process e adapta-los ao CMMI.

Embora RUP cobre 97 por cento das exigências de CMMI para Maturidade Nível 2, e necessário utilizar práticas adicionais. Isso é porque não inclui as duas áreas ed processo do Nível 2 .

O RUP é construído em uma arquitetura extensível que lhe permite adaptar o processo a suas necessidades. Como e o caso dos niveis do CMMI, o qual podemos utilizar os artefatos do RUP
4. Referências

[1] Rational Unified Process, http://www.wthreex.com/rup/index.htm, Acessado em 06/12/2008

[2] CMMI (2008). CMMI Web Site. Disponível em http://www.sei.cmu.edu/cmmi/ . Acesso em: 07/12/08.

[3]Fernandes, Aguinaldo A.; Abreu, Vladimir F. (2008). Implantando a Governança de TI: Estratégia à Gestão dos Processos e Serviços. 2. ed – Rio de Janeiro, Brasport.

[4] A CMMI maturity Level 2 assessment of RUP, Artigo disponivel em http://www.ibm.com/developerworks/rational/library/dec05/grundmann/index.html?S_TACT=105AGX15&S_CMP=EDU

[5] Vivatanavorasin, Vivatanavorasin, A Process Model Designer And Tool Development for Supplient Agreement Management of CMMI: Capability Level 2, Computer Society, 2006

[5] Reaching CMM Levels 2and 3 with the Rational Unified Process, Rational Software White Paper, 2007