O modelo MPS.BR é um programa mobilizador de longo prazo, criado em dezembro de 2003, coordenado pela associação para promoção da excelência do software brasileiroSOFTEX. Ele conta com o apoio do MCT, do FINEP, do SEBRAE, do BID. Também conta com o apoio de duas estruturas de apoio para desenvolvimento de suas atividades, o FCC e a ETM. Éatravés delas que o MPS-BR tem a participação de representantes de universidades, instituições governamentais, centros de pesquisa e de organizações privadas, os quais contribuem com suas visões complementares que agregam qualidade ao empreendimento (SOFTEX, 2011).
O MPS.BR tem por finalidade atender ao perfil de empresas com diferentes tamanhos e características, públicas e privadas, devido o valor do custo ser alto para certificações de grandes empresas a SOFTEX tem uma atenção especial às empresas micro, pequenas e de médio porte, trazendo a melhoria de processo do software brasileiro, com duas metas a alcançar a médio e longo prazos, esse modelo visa ser o compatível com os padrões de qualidade aceitos internacionalmente (SOFTEX, 2011).
Este modelo é baseado no modelo CMMI que tem cinco níveis, o MPS.BR fez a inclusão de dois níveis totalizando sete níveis de maturidade. A – Otimização, B – gerenciado quantativamente, C – Definido, D – Largamente definido, E – Parcialmente definido F – Gerenciado e G – parcialmente gerenciado (SOFTEX, 2006).
O MPS.BR se divide em três partes: MR-MPS – Modelo de referência, contém as definições dos níveis de maturidade, processos e atributos do processo, MA-MPS – Modelo de avaliação, contém o processo e o método de avaliação dos requisitos para os avaliadores líderes, avaliadores adjuntos e instituições avaliadoras (IA) e o MN-MPS – Modelo de negócio, descreve as regras de negócio para implementação, avaliação e organização de grupos de empresas (SOFTEX, 2011).
O modelo MPS.BR assim como o CMMI-DEV trabalha com os dois processos da Engenharia de Requisitos, são eles o Desenvolvimento de Requisitos do nível de maturidade D que tem a finalidade estabelecer os requisitos dos componentes do produto, do produto e do clientee a Gerência de Requisitos do nível de maturidade G que tem por finalidade identificar, estabelecer, coordenar e monitorar as atividades, tarefas e recursos que um projeto necessita para produzir um produto e/ou serviço (SOFTEX, 2006).
O modelo MPS.BR possui uma base técnica composta pelas normas da ISO/IEC 12207, ISO/IEC 15504 e é compatível com o modelo CMMI-DEV (WEBER, et. al., 2012).
O modelo MPS.BR se divide em três componentes:
Este modelo define os níveis de maturidade, documentado sob a forma de três guias: guia geral do MPS, guia de Aquisição do MPS e guia de Implementação do MPS (WEBER, et. al., 2012).
Este modelo considera a adesão dos processos estabelecidos para cada nível e contém os requisitos para os avaliadores e os requisitos para averiguação da conformidade com o modelo MR-MPS. Baseado na norma ISO/IEC 15504, este processo verifica a maturidade de uma unidade organizacional na execução dos seus processos de software.
Este modelo contém uma descrição das regras para a implementação do MR-MPS pelas empresas de consultoria, de software e de avaliação (LIEBMAM, 2006).
O MPS.BR está documentado em formato de guias, são elas:
Mostra as definições gerais necessárias para seu entendimento e aplicação, também provê uma definição geral do modelo MPS, detalha o MR-MPS e contém os requisitos que as organizações devem atender para estar em conformidade com o modelo MPS (KALINOWSKI, 2010).
Expõe um processo de aquisição de software e serviços relacionados, também é descrito como uma forma de documento que visa apoiar as organizações que queiram adquirir produtos de software e serviços relacionados no MR-MPS. É baseado na norma ISO/IEC 12207 - (2008), (WEBER; SCALET, 2011).
Nesta guia está descrito o processo e o método de avaliação do MA-MPS, os requisitos para os avaliadores líderes, adjuntos e para as instituições avaliadoras. Também é possível verificar o nível de maturidade de uma unidade organizacional na execução dos seus processos.
A fase de implementação destaca uma série de documentos que por sua vez fornecem orientações sobre como as organizações devem implementar os sete níveis de maturidade conforme estão descritas as no modelo MR-MPS (LIEBMAM, 2006).
Conforme já visto o modelo MR-MPS define sete níveis de maturidade de processos para as organizações, são eles:
A – Em otimização
B – Gerenciado quantitativamente
C – Definido
D – Largamente definido
E – Parcialmente definido
F – Gerenciado
G – Parcialmente gerenciado
Segundo o professor FRANCO (2009) no MR-MPS os níveis de maturidade definem a evolução de cada etapa de processos, permitindo prever o desempenho futuro da organização, embora esses níveis de maturidade sejam baseados no modelo CMMI-DEV o modelo MR-MPS tem uma escala diferente, possibilitando a implementação, avaliaçãoe reconhecimento mais gradual da melhoria de processo de software,facilitandouma melhor adequação para as médias, pequenas e micro empresas, além da possibilidade de realizar as avaliações utilizando mais níveis como opção e obter resultados de melhoria em menos tempo.
O modelo MR-MPS é definido através de níveis de maturidade, sequências e acumulativos. Cada nível de maturidade é uma junção entre processos e capacidade dos processos, ou seja, é composto por um conjunto de processos em um determinado nível de capacidade (WEBER, et. al., 2010).
Os níveis de capacidade são descritos através de nove atributos de processo (AP), conforme definido a seguir:
AP 1.1 O processo é executado
AP 2.1 O processo é gerenciado
AP 2.2 Os produtos de trabalho do processo são gerenciados
AP 3.1 O processo é definido
AP 3.2 O processo está implementado
AP 4.1 O processo é medido
AP 4.2 O processo é controlado
AP 5.1 O processo é objeto de melhorias incrementais e inovações
AP 5.2 O processo é otimizado continuamente
Na classificação dos níveis de maturidade o nível G é o primeiro dos sete níveis crescentes de maturidade e indica que a organização está formalmente comprometida com a qualidade na gerência de projetos e gerência de requisitos.
Todos os processos do MR-MPS são expostos em função de seu propósito e dos resultados esperados para avaliar a sua implementação. Visto que cada processo definido no MPS.BR tem um conjunto de resultados necessários e suficiente para alcançar o propósito do processo. Onde o propósito deste nível é obter o maior número de informações sobre o andamento do projeto, para prover correções para quando houver desvios ou necessidade (SEI, 2006).
2.3.1DRE - Desenvolvimento de requisitos
Segundo a SOFTEX (2011), um desenvolvimento de requisitos criterioso é uma condição fundamental para o sucesso do projeto, pois os requisitos formam uma base para todo o ciclo do projeto, que inicia no desenvolvimento até a manutenção. A evolução para o nível D do MR-MPS envolve somente a definição e implementação de cinco novos processos com o mesmo nível de capacidade dos processos já implantados (DRE, ITP, PCP, VAL e VER). Nesse processo os requisitos são analisados, validados e gerenciados ao longo do ciclo de desenvolvimento ou de manutenção do produto.
Devido à ausência evidente da separação dos diferentes níveis que descrevem os requisitos, se tornam comuns problemas no desenvolvimento de requisitos o que produz erros e dificuldades durante o processo em geral (SOMMERVILLE, 2003).
O MR-MPS também é composto pelo Desenvolvimento de Requisitos (DRE), que define os requisitos do cliente, do produto e dos componentes do produto. Esse processo é responsável por interpretar as necessidades do cliente e elaborar os requisitos do sistema a ser desenvolvido. Veja no quadro abaixo os oito resultados para o desenvolvimento de requisitos que são esperados para esse processo:
DRE 1 |
As necessidades, expectativas e restrições do cliente, tanto do produto quanto de suas interfaces são identificadas. |
DRE 2 |
Um conjunto definido de requisitos do cliente é especificado a partir das necessidades, expectativas e restrições identificadas. |
DRE 3 |
Um conjunto definido de requisitos funcionais e não –funcionais, do produto e dos componentes do produto que descrevem a solução do problema a ser resolvido é definido e mantido a partir dos requisitos do cliente. |
DRE4 |
Os requisitos funcionais e não-funcionais de cada componente do produto são refinados, elaborados e alocados. |
DRE5 |
Interfaces internas e externas do produto e de cada componente do produto são definidas. |
DRE6 |
Conceitos operacionais e cenários são desenvolvidos. |
DRE7 |
Os requisitos são analisados, usando critérios definidos, para balancear as necessidades dos interessados com as restrições existentes. |
DRE8 |
Os requisitos são validados. |
Quadro 3: O processo está estruturado em oito resultados (YOSHIDOME, ET. AL., 2012).
2.3.2 GRE – GERÊNCIA DE REQUISITOS
Dentro do nível G está à gerência de requisitos (REQM – Requirements Management), uma fase muito importante do projeto, pois é na execução dele que ficam indicadores de possíveis sucessos do projeto. É nesse nível que há um planejamento das atividades, dos recursos e das responsabilidades do projeto. Tendo como objetivo principal gerenciar e controlar a evolução dos requisitos (SOUZA, 2010).
A gerência de requisitos identifica os requisitos do produto e componente de produto, determina e mantém um entendimento entre o cliente e a equipe de projeto referente aos requisitos, verifica e cuida das mudanças nos requisitos no decorrer do desenvolvimento do projeto, todas as mudanças devem ser documentadas e a rastreabilidade dos requisitos deve ser mantida para garantir que os objetivos do projeto sejam alcançados.Veja no quadro abaixo como são descritos os cinco resultados que são esperados para o gerenciamento de requisitos:
GRE 1 |
O entendimento dos requisitos é obtido junto aos fornecedores de requisitos. |
GRE 2 |
Os requisitos de software são avaliados com base em critérios objetivos e um comprometimento da equipe técnica com estes requisitos é obtido. |
GRE 3 |
A rastreabilidade bidirecional entre os requisitos e os produtos de trabalho é estabelecida e mantida. |
GRE 4 |
Revisões em planos e produtos de trabalho do projeto são realizadas visando identificar e corrigir inconsistências em relação aos requisitos. |
GRE 5 |
Mudanças nos requisitos são gerenciadas ao longo do projeto. |
Quadro 4: Os cinco resultados esperados do Gerenciamento de requisitos (SOFTEX, 2011).
A capacidade dos processos no MPS é descrita por nove Atributos de Processo (AP). O alcance de todos os APs está detalhado em termos de resultados esperados e é avaliado utilizando os respectivos resultados esperados de atributo de processo (RAP).
No nível G a implementação dos processos deve satisfazer os atributos de processo AP 1.1 e AP 2.1 e para ser considerado um processo “satisfeito” no nível G, o atributo AP 1.1 deve ser caracterizado como T(Totalmente implementado) e o atributo AP 2.1 como T ou L(Largamente implementado).
A capacidade do processo significa caracterizar a habilidade de cada processo afim de,atingir os objetivos de negócio, sejam eles atuais e/ou futuros, estando relacionada com o atendimento aos atributos de cada processo associados aos processos de cada nível de maturidade.
O grau de refinamento e a institucionalização da execução dos processos presentes no nível G são indicados(SOFTEX, 2011).
Para indicar o grau de refinamento e institucionalização da execução dos processos referentes ao nível G, seus atributos de processos devem ser avaliados conforme a tabela 5:
AP 1.1 |
O processo é executado |
|
RAP 1 |
|
O processo atinge seus objetivos |
AP 2.1 |
O processo é gerenciado |
|
RAP 2 |
|
Existe política organizacional estabelecida e mantida para o processo. |
RAP 3 |
|
A execução do processo é planejada |
RAP 4 |
|
Medidas são planejadas e coletadas para monitoração do processo |
RAP 5 |
|
Os resultados necessários para a execução do processo são identificados e disponibilizados |
RAP 6 |
|
As pessoas que executam o processo são competentes em termos de formação, treinamento e experiência |
RAP 7 |
|
A comunicação entre as partes interessadas no processo é gerenciada de forma a garantir o seu envolvimento no projeto. |
RAP 8 |
|
Métodos adequados para monitor a eficácia e a adequação do processo são determinados |
RAP 9 |
|
A aderência dos processos executados às descrições de processo, padrões e procedimentos é avaliada objetivamente e são tratadas as não conformidades. |
Tabela 5: Resultados esperados dos atributos de processos do nível G (SOUZA, 2010).