O modelo CMMI – (Capability Maturity Model Integration) é uma evolução do CMM – (Capability Maturity Model). Este modelo é uma abordagem de melhoria de processos que fornece às organizações os elementos essenciais de processos efetivos, o que melhorará o seu desempenho (SEI, 2006). O modelo CMMI foi desenvolvido para complementar e unificar o CMM, tornando-o um modelo único de processos integrando diferentes disciplinas e classifica os cinco níveis de maturidade em inicial, Gerenciado, Definido, Gerenciado quantativamente e em otimização (SEI, 2006). O modelo CMMI abrange três áreas de interesse: CMMI for Development (CMMI-DEV) – processo de desenvolvimento de produtos e serviços, CMMI for Service (CMMI-SVC) – processo de empresa prestadora de serviço e CMMI for Acquisition (CMMI-ACQ) – processo de aquisição e terceirização de bens e serviço. O foco deste trabalho será o CMMI-DEV, uma comparação da área da engenharia de requisitos que envolvem o desenvolvimento e gerenciamento de requisitos com o modelo MPS.BR.

            O modelo CMMI-DEV possui duas áreas que trabalham com a engenharia de requisitos, o desenvolvimento de requisitos que identifica as necessidades do cliente e torna essas necessidades em requisitos de produto e o Gerenciamento de requisitos que gerencia os requisitos de produtos do projeto e dos componentes de produto. O conjunto de requisitos de produto é analisado para gerar uma solução conceitual de alto nível. O conjunto de requisitos é então alocado para estabelecer um conjunto inicial de requisitos de produto. Outros requisitos que ajudam a definir o produto são derivados e alocados aos componentes de produto e descrever claramente o desempenho do produto, suas características de design e seus requisitos de verificação, de forma que o desenvolvedor possa entendê-los e utilizá-los (SEI, 2006).

O modelo CMMI foi desenvolvido para trabalhar com dois caminhos de melhoria de processos, o primeiro é a representação contínua que possibilita para a organização utilizar a ordem de melhoria para atender os objetivos de negócios da empresa, o segundo é a representação por estágio que disponibiliza uma sequê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 (COSTA, 2010).

A representação contínua e por estágio foram projetadas para mostrar resultados essencialmente equivalentes, mesmo sendo uma delas para melhoria de processos e a outra para avaliação de processos. A representação contínua disponibiliza para organização uma sequência de melhorias para atender os objetivos de negócios e reduzir as áreas de risco da organização, permite também comparações dentro e entre as organizações referentes a uma área de processo ou pela comparação de resultados através do uso de estágios equivalentes. A representação por estágios oferece uma sequência comprovada de melhorias, começando com práticas básicas de gerenciamento e progredindo por um caminho pré-definido e comprovado pelos níveis sucessivos, cada um servindo como base para o próximo nível, permitirá comparação dentro e entre as organizações pelo uso de níveis de maturidade, oferecendo uma classificação única que resume os resultados de avaliações (CHRISSIS, KONRAD e SHRUM, 2011).

Comparando as duas representações, é possível notar que a representação contínua disponibiliza uma abordagem flexível à melhoria de processos ao contrário da representação por estágio que não permite uma abordagem tão flexível. Embora as duas representações tenham suas diferenças e igualdades, ambas são equivalentes dependendo da necessidade de melhoria que a organização necessitar.

Todas as áreas de processo do CMMI são as mesmas tanto na representação contínua como em estágio. Na representação em estágio, as áreas de processo estão organizadas por níveis de maturidade e na representação contínua estão organizadas em níveis de capacidade. (CHRISSIS, KONRAD, e SHRUM, 2011).

A representação contínua trabalha com processos individuais, atribuindo o nível de capacidade para cada processo. Esses níveis caracterizam as capacidades da organização referente a cada área de processo, essa capacidade é uma maneira intermediária para melhorar de forma incremental os processos correspondentes a uma determinada área de processo. Estes níveis estão classificados em seis partes, numerados de 0 a 5 e são medidos pelo atendimento de metas específicas e genéricas que se aplicam a uma área de processo. Cada nível de capacidade compreende um conjunto pré-definido de áreas de processos (SOUSA, 2006).

De acordo com o SEI (2006) os seis níveis de Capacidade do CMMI, são:

0. Incompleto

1. Executado

2. Gerenciado

3. Definido

4. Gerencialmente quantitativamente

5. Em Otimização.

De acordo com o SEI (2006), a representação por estágio refere-se à maturidade global da organização, a principal preocupação não é se os processos individuais são executados ou incompletos, e sim o seu ponto de partida chamado de “inicial”. Os níveis de maturidade são numerados de 1 a 5. Cada nível de maturidade compreende um conjunto pré-definido de áreas de processos.

1. Inicial

2. Gerenciado

3. Definido

4. Gerenciado Quantitativamente

5. Otimizado

ÁREAS DE PROCESSO

Uma área de processo é um grupo de práticas relacionadas em uma área, quando executadas de forma coletiva, satisfazem a um conjunto de metas consideradas importantes para trazer uma melhoria significativa naquela área. (SEI, 2010)

O modelo CMMI-DEV é composto por 22 áreas de processo, disponibilizadas em ordem alfabética de seus acrônimos em inglês:

• Análise e Resolução de Causas (CAR)
• Gestão de Configuração (CM)
• Análise e Tomada de Decisão (DAR)
• Gestão Integrada de Projeto +IPPD (IPM +IPPD)⁶
• Medição e Análise (MA)
• Implantação de Inovações na Organização (OID)
• Definição dos Processos da Organização +IPPD (OPD +IPPD)⁶
• Foco nos Processos da Organização (OPF)
• Desempenho dos Processos da Organização (OPP)
• Treinamento na Organização (OT)
• Integração de Produto (PI)
• Monitoramento e Controle de Projeto (PMC)
• Planejamento de Projeto (PP)
• Garantia da Qualidade de Processo e Produto (PPQA)
• Gestão Quantitativa de Projeto (QPM)
• Desenvolvimento de Requisitos (RD)
• Gestão de Requisitos (REQM)
• Gestão de Riscos (RSKM)
• Gestão de Contrato com Fornecedores (SAM)
• Solução Técnica (TS)
• Validação (VAL)
• Verificação (VER)

2.2.2 DESENVOLVIMENTO DE REQUISITOS

O desenvolvimento de requisitos está presente na área de processo da engenharia do CMMI, no níveltrês de capacidade, ele trata do levantamento, análise, coleta, desenvolvimento de requisitos de clientes, de produto e de componente de produto. (BALMANT, 2011). Seu objetivo é produzir e analisar os requisitos de cliente, de produto e do componente de produto. Juntos esses requisitos cuidam das necessidades dos stakeholders relevantes ao projeto, incluindo aquelas adequadas às várias fases do ciclo de vida de produto e atributos de produto. (PETRY, 2011).

Através do desenvolvimento de requisitos é possível identificar as necessidades do cliente e explicar como as necessidades se tornam requisitos de produto.

Segundo SOUZA (2009), o desenvolvimento de requisitos detalha os requisitos de alto nível em outros de baixo nível e os atribuí a categorias para desenvolvimento posterior, define também interfaces entre os requisitos e outras áreas necessárias para completa-los, definem e documentam adequadamente as necessidades, conceitos e cenários operacionais, funcionalidades desejadas, asseguram o cumprimento e consistência dos requisitos, negocia as necessidades, exigências e restrições, valida os requisitos contra os riscos nas fases iniciais do projeto.

A área de desenvolvimento de requisitos está dividida em três grupos. O primeiro é a meta específica para desenvolver requisitos de cliente, onde é definido um conjunto completo de requisitos do cliente que será utilizado no desenvolvimento dos requisitos do produto. O segundo é a meta específica para desenvolver requisitos do produto, onde é definido um conjunto completo de requisitos de produto e componentes de produto para utilização no designdos mesmos. O terceiro é a meta específica para analisar e validar os requisitos, ou seja, gerar e entender os requisitos. Veja no quadro abaixo as identificações das metas e práticas específicas para o desenvolvimento de requisitos:

Meta específica

Prática específica

Desenvolver requisitos do cliente

Coletar necessidades dos stakeholders;

Descobrir necessidades;

Transformar necessidades dos stakeholders, expectativas, restrições e interfaces em requisitos do cliente.

Desenvolvimento de requisitos do produto

Estabelecer requisitos do produto e componentes.

Alocar requisitos aos componentes;

Identificar requisitos de Interface.

Análise e validação dos requisitos

Estabelecer conceitos operacionais e cenários;

Estabelecer uma definição da funcionalidade requerida;

Análise de requisitos;

Avaliar custo do produto, cronograma e risco;

Validar requisitos;

Validar requisitos com Métodos compreensivos.

Tabela 1. Metas e práticas específicas de desenvolvimento de requisitos(CORRÊA, et. al., 2004).

2.2.3 GERENCIAMENTO DE REQUISITOS

A área de processo de gerenciamento de requisitos tem como objetivo identificar os requisitos funcionais e não funcionais do produto e as correspondentes mudanças (TONINI, CORVALHO, SPINOLA, 2008).

O processo do gerenciamento de requisitos fornece a base para o desenvolvimento de projetos, isto é, ele é o processo que faz a ligação com basicamente todas as outras áreas no modelo CMMI e está presente no nível dois de maturidade (SOUSA, 2006).

Esta área garante que os planos e produtos do projeto continuem em linha com os requisitos (VALLE, et. al. 2010), ela expõe as atividades para conseguir controlar as alterações dos requisitos e assegurar que outros planos e dados relevantes permaneçam atualizados (SEI, 2006). Outro ponto de vista importante do gerenciamento de requisitos é a possibilidade de rastrear o impacto na solução de falhas nosoftware ou nas solicitações de mudanças vindas dos usuários (AMARAL, 2010).

Segundo SOUSA (2006), o gerenciamento de requisitos tem como principal função fornecer auxílio para administrar os requisitos do produto e do componente de produto, identificando as possíveis inconsistências entre os requisitos e os planos e produtos de trabalho do projeto. Veja no quadro abaixo como estão classificadas as metas e práticas específicas para o gerenciamento de requisitos:

SG 1: Gerenciar Requisitos

SP 1.1: Obter entendimento dos requisitos

SP 1.2: Obter comprometimento aos requisitos

SP 1.3: Gerenciar mudanças dos requisitos

SP 1.4: Manter rastreabilidade bidirecional dos requisitos

SP 1.5: Identificar inconsistências entre o trabalho do projeto e os requisitos.

Quadro 2: Classificação das metas e práticas específicas (SEI, 2006).       

• SG 1 – O gerenciamento de requisitos é responsável por manter o conjunto de requisitos atualizados e aprovado no decorrer do projeto, realizar a administração das alterações nos requisitos, firmar a relação entre os requisitos, o projeto e o produto de trabalho. Também faz parte dessa gerência identificar as inconsistências em relação aos requisitos, planos de projeto e produtos de trabalho, a fim de tomar decisões corretivas.
• SP 1.1 – Aumentar o entendimento com os fornecedores dos requisitos a respeito do entendimento dos mesmos, a fim de evitar mudar o sentido original dos requisitos, os critérios são estabelecidos para mostrar os caminhos mais adequados.
• SP 1.2 – Conseguir o compromisso dos participantes do projeto, determina acordos e compromissos entre aqueles responsáveis por realizar as atividades necessárias para implementar os requisitos.
• SP 1.3 – Esta prática está relacionada a mudanças nos requisitos na medida em que eles irão progredir no decorrer do projeto, seu foco está no controle das versões da especificação de requisitos e nas mudanças da especificação de requisitos.
• SP 1.4 – Manter a rastreabilidade bidirecional entre os requisitos e produtos de trabalho, é uma associação diferenciada entre os requisitos relacionados, implementações e verificações.
• SP 1.5 – Reconhece as inconsistências entre os planos e produtos de trabalho do projeto e os requisitos (SILVA, 2010).