ESTUDO PARA ADOÇÃO E IMPLANTAÇÃO DO NÍVEL G DO MODELO … · ... está a adoção do modelo...

ESTUDO PARA ADOÇÃO E IMPLANTAÇÃO DO NÍVEL G

DO MODELO MPS.BR NAS GERÊNCIAS DE SISTEMAS DE INFORMAÇÃO DAS IFES.

Área temática: Gestão pela Qualidade

Sérgio Luís Lima Corrêa

[email protected]

Mírian Picinini Méxas

[email protected]

Resumo: Currently, much has been discussed and studied ways to improve the software development process aimed

mainly quality. MPS.BR stands for Brazilian Software Process Improvement, proposed and developed by SOFTEX

which aims the improvement of software process and national services model. The MPS.BR is an adaptation of the

maturity of software development process model internationally known as CMMI. This article aims to study the

MPS.BR reference model and propose ways to implement the initial level of this model in G Managements Information

Systems of IFES. The methodology used was a literature review resulting in the identification of the main advantages

and difficulties in implementing the MPS.BR. As a contribution of this research proposes suggestions to minimize the

difficulties identified in order to achieve successful implementation of the model.

Palavras-chaves:

ISSN 1984-9354

XI CONGRESSO NACIONAL DE EXCELÊNCIA EM GESTÃO 13 e 14 de agosto de 2015

2

1 - Introdução

Os ambientes de negócios têm sofrido constantes mudanças devido à globalização e acirrada

competição por espaço no mercado. A sustentabilidade e competitividade de determinada empresa

(pública ou privada) depende também da qualidade de seus produtos ou serviços.

Alcançar competitividade pela qualidade, para as empresas de software, implica tanto na

melhoria da qualidade dos produtos de software e serviços correlatos, como dos processos de produção

e distribuição de software. (SOFTEX, 2012b, p. 5).

Segundo Fonseca (2011, p. 56), a implantação de um modelo internacional como CMMI, por

exemplo, demanda alto investimento. E o propósito do modelo MPS.BR é promover a melhoria do

software por meio do aprendizado das melhores práticas de desenvolvimento, a um custo acessível, em

menos tempo, de acordo com a realidade brasileira.

Embora, a atividade fim da IFES não seja a produção de software e sua missão seja

completamente adversa a isso, ainda assim, existe toda uma complexa estrutura tecnológica que visa

manter e disponibilizar a TI (Tecnologia da Informação) como ferramenta estratégica. Neste sentido,

toda IFES possui algum órgão ou setor dentro de seu organograma responsável pela mobilização de

recursos de TI em seu âmbito. Assim, suas práticas envolvem além da manutenção e disponibilização

de todo arcabouço tecnológico, a análise, modelagem, desenvolvimento, gerenciamento e atualização

dos Sistemas de Informação; o gerenciamento lógico da rede de dados, e ainda, o estudo e a

implementação de novas soluções tecnológicas na IFES.

Neste contexto, uma importante área é a Gerência de Sistemas de Informação, que atua

coordenando o desenvolvimento e a manutenção dos Sistemas de Informação da IFES e que necessita

da adoção constante de “boas práticas” que refletirão na melhoria na prestação de serviços de TI aos

seus clientes. Dentre as determinações que visam essa melhoria, está a adoção do modelo MPS.BR

como processo de melhoria de software, que é composto de sete níveis. Além disso, a instituição não

necessitará implementar todos os níveis de uma vez, pois este esforço pode ser realizado gradualmente

através dos níveis de maturidade do modelo.

Logo, este artigo tem por objetivo o estudo do modelo de referência para melhoria do processo

de software MPS.BR, apontando as principais vantagens e as dificuldades encontradas na sua

implementação, visando propor caminhos para a adoção deste modelo e sua implantação gradual nas

Gerências de Sistemas de Informação das IFES.


3

Além da introdução, este artigo contém mais quatro capítulos. No capítulo 2, o referencial

teórico a respeito do modelo MR-MPS-BR é apresentado, focando principalmente o modelo de

referência para software MR-MPS-SW. No capítulo 3, a metodologia aplicada. O capítulo 4 contém as

considerações finais do artigo e o capítulo 5 as referências bibliográficas.

2 - Referencial Teórico

2.1) Processos de Software

Pressman (2011, p. 40) conceitua processo como um conjunto de atividades, ações e tarefas

realizadas na criação de algum produto de trabalho. No contexto da engenharia de software, um

processo é uma abordagem adaptável que possibilita realizar o trabalho de selecionar o conjunto

apropriado de ações e tarefas com intenção de entregar software dentro do prazo e com qualidade. No

entanto, Pressman (2011, p. 58) adverte que a existência de um processo de software não garante que o

software será entregue no prazo, que estará de acordo com a necessidade do cliente ou que terá

qualidade; e que devem ser combinados com uma prática de engenharia de software consistente.

Segundo Pressman (2011, p. 41), uma metodologia de processo genérica para engenharia de

software compreende cinco atividades: comunicação, planejamento, modelagem, construção e

emprego. Os detalhes do processo de software serão bem diferentes em cada caso de criação de

pequenos programas ou grandes aplicações, mas as atividades metodológicas serão as mesmas.

Ainda segundo Pressman (2011, p. 55), um padrão de processo descreve um problema de

processo encontrado durante o trabalho de engenharia de software, identificando o ambiente onde foi

encontrado e sugerindo uma ou mais soluções comprovadas para o problema. Em termos genéricos,

um padrão de processo fornece um modelo (template).

Sommerville (2011, p. 18) define um processo de software como um conjunto de atividades

relacionadas que levam à produção de software. Ainda segundo Sommerville (2011, p. 18), existem

muitos processos de software diferentes, mas todos incluem quatro atividades fundamentais para a

engenharia de software: 1) especificação de software; 2) projeto e implementação de software; 3)

validação de software e 4) evolução de software.

Sommerville (2011, p. 19), afirma ainda que os processos de software são complexos, que não

existe um processo ideal, e que podem ser melhorados pela padronização.


4

Cunha; et al. (2011, p. 26) afirma que a busca pela padronização de um processo garante a

documentação concisa, facilitando a implementação dos modelos de maturidade. Assim, os processos

de software podem ser aprimorados por meio da padronização de processos.

Os negócios são dinâmicos, as regras de negócio mudam com o passar do tempo. Assim, além

das mudanças oriundas por força do negócio, os processos de software também demandam melhoria

contínua tanto para atender ao negócio da instituição quanto para melhor representarem a realidade.

2.2) O Modelo de Referência MR-MPS

O MPS.BR visa basicamente a melhoria da qualidade do software desenvolvido em instituições

públicas ou privadas segundo a realidade brasileira. Softex (2012b, p. 6) afirma que qualidade é fator

crítico de sucesso para a indústria de software; e que empresas produtoras de software visam alcançar

competitividade pela qualidade implicando na melhoria da qualidade dos produtos de software e

serviços correlatos. Outro objetivo do modelo é promover um setor de software competitivo

nacionalmente e internacionalmente.

Atualmente tem se dado muita importância ao processo como garantia de se obter um software

de qualidade e mais robusto quanto a falhas. A qualidade do software está diretamente ligada à

qualidade do processo utilizado no seu desenvolvimento. Além disso, a manutenção do software para

corrigir uma provável falha em sua execução, será mais facilmente corrigida quando houver um

processo formalizado, ou seja, documentado e gerenciado (planejado, monitorado e ajustado

(SOFTEX, 2012a, p.10)).

De acordo com Fernandes e Abreu (2012, p. 313), fica cada vez mais evidente que os processos

de software precisam ser tratados de forma integrada e interdisciplinar; e que abordagens integradas

desta natureza estão presentes nos modelos de maturidade criados para avaliar e acreditar nas

organizações de software.

Ainda segundo Fernandes e Abreu (2012, p. 330), em dezembro de 2003, a Softex lançou o

programa MPS.BR, baseado no modelo CMMI for Development (CMMI-DEV) (SEI, 2010a), no

modelo de avaliação de software ISO 15504 e nas melhores práticas de engenharia de software; e uma

de suas metas é disseminar o modelo por todo país, com custo e prazos razoáveis, tanto para o mercado

de pequenas empresas quanto para as grandes corporações.

Softex (2012, p. 4) define o Modelo MPS.BR como um programa mobilizador, de longo prazo,

criado em dezembro de 2003, coordenado pela Associação para Promoção da Excelência do Software


5

Brasileiro (SOFTEX), que conta com apoio do Ministério da Ciência, Tecnologia e Inovação (MCTI),

Financiadora de Estudos e Projetos (FINEP), Serviço Brasileiro de Apoio às Micro e Pequenas

Empresas (SEBRAE) e Banco Interamericano de Desenvolvimento (BID/FUMIN).

Segundo Softex (2012a, p. 12), uma das metas do Programa MPS-BR foi definir um modelo de

melhoria de processo de software e serviços, visando preferencialmente micro, pequenas e médias

empresas de forma a atender suas necessidades e ser reconhecido nacional e internacionalmente como

um modelo aplicável à indústria de software e serviços.

O modelo MPS é definido em consonância com a Norma Internacional ISO/IEC 12207:2008

(ISO/IEC, 2008a) e ISO/IEC 20000:2011 (ISO/IEC, 2011b), adaptando-a as necessidades da

comunidade de interesse. O MR-MPS-SW (Modelo de Referência MPS para Software) é compatível

com o CMMI-DEV (SEI, 2010a) e o MR-MPS-SV (Modelo de Referência MPS para Serviços) é

compatível com o CMMI-SVC (SEI, 2010b) (SOFTEX, 2012a, p. 13).

Boria; et al. (2013, p. 7) orienta que o MPS é um modelo de desenvolvimento organizacional

por níveis, que define os processos que a organização deve implementar e os resultados esperados

dessa ação, para ir avançando de nível em nível.

De acordo com Boria; et al. (2013, p. 33), o modelo MR-MPS é uma valiosa ferramenta que

permite à empresa interessada na melhoria de seus processos entender o que já tem implementado e o

que falta, além de sugerir os próximos passos. A desvantagem de um modelo é que os caminhos de

implementação são múltiplos e dependem da empresa em questão.

Ainda segundo Boria; et al. (2013, p. 35), no MR-MPS, à medida que a organização evolui

pelos níveis de maturidade, a capacidade para realizar os processos deve melhorar da mesma forma.

No entanto, os benefícios em termos de desempenho não surgem do rigor com que estes são

implementados, mas da cultura que é gerada por sua aplicação correta e consistente. A capacidade para

realizar os processos é manifestada pela implementação dos Atributos de Processo (AP), que por sua

vez é manifestada pela implementação dos Resultados esperados dos Atributos de Processo (RAP).

Kalinowski; et al., (2010, p. 12) afirma que o modelo MPS.BR é um mecanismo para

estabelecer um caminho economicamente viável para que organizações brasileiras alcancem os

benefícios da implementação de boas práticas da engenharia de software.

2.2.1) A estrutura do Modelo MR-MPS


6

Softex (2012a, p. 6) afirma que o modelo MPS baseia-se nos conceitos de maturidade e

capacidade de processo para a avaliação e melhoria da qualidade e produtividade de software e

serviços correlatos e que possui quatro componentes: Modelo de Referência MPS para Software (MR-

MPS-SW), Modelo de Referência MPS para Serviços (MR-MPS-SV), Método de Avaliação (MA-

MPS) e Modelo de Negócio (MN-MPS). Cada componente é descrito por meio de guias e/ou

documentos do programa MPS.BR:

Guia Geral MPS de Software: contém a descrição geral do modelo MPS e detalha o Modelo de

Referência MPS para Software (MR-MPS-SW), seus componentes e as definições comuns

necessárias para seu entendimento e aplicação;

Guia Geral MPS de Serviços: contém a descrição geral do modelo MPS e detalha o Modelo de

Referência MPS para Serviços (MR-MPS-SV), seus componentes e as definições comuns

necessárias para seu entendimento e aplicação;

Guia de Aquisição: descreve um processo de aquisição de software e serviços correlatos. É

descrito como forma de apoiar as instituições que queiram adquirir produtos de software e

serviços correlatos apoiando-se no MR-MPS-SW;

Guia de Avaliação: descreve o processo e o método de avaliação MA-MPS, os requisitos para

avaliadores líderes, avaliadores adjuntos e Instituições Avaliadoras (IA);

Guia de Implementação: série de documentos que fornecem orientações para implementar nas

organizações os níveis de maturidade descritos no Modelo de Referência MR-MPS-SW.

Softex (2012a, p. 13 e 14) descreve resumidamente o papel dos modelos e guias assim:

O Modelo de Referência MPS para Software MR-MPS-SW e para Serviços MR-MPS-SV

contém os requisitos que os processos das unidades organizacionais devem atender para estar

em conformidade com o MR-MPS-SW e MR-MPS-SV respectivamente;

O Guia de Aquisição é um documento complementar destinado a organizações que pretendam

adquirir software e serviços. O Guia de Aquisição não contém requisitos do MR-MPS-SW e

MR-MPS-SV, mas boas práticas para a aquisição de software e serviços;


7

O Guia de Implementação nas partes 1 a 7 sugere formas de implementar cada um dos níveis

do MR-MPS-SW. A parte 8 sugere formas de como uma unidade organizacional que faz

Aquisição de produtos pode implementar o MR-MPS-SW. As partes 9 e 10 sugerem formas

com que Fábricas de Software e Fábricas de Testes, respectivamente, podem implementar o

MR-MPS-SW. A parte 11 apresenta um mapeamento do MR-MPS-SW e o CMMI-DEV que

auxilia as organizações nas iniciativas de melhoria de processos de software multimodelos. As

explicações presentes no Guia de Implementação não constituem requisitos do modelo e devem

ser consideradas apenas em caráter informativo;

O Guia de Avaliação contém o processo e o método de avaliação MA-MPS;

O Modelo de Negócio MN-MPS descreve regras de negócio para implementação do MR-MPS-

SW e MR-MPS-SV pelas Instituições Implementadoras.

A seguir, a Figura 1 apresenta os componentes do Modelo MPS.

Figura 1: Componentes do Modelo MPS

Fonte: (SOFTEX, 2012a, p. 14)

Kalinowski; et al. (2010, p. 12) ressalta que o modelo MPS contém apenas resultados exigidos

para processos e para atributos de processo, não determinando os métodos, técnicas e ferramentas que

devem ser empregados para alcançar estes resultados.


8

2.3) O Modelo de Referência MPS para Software (MR-MPS-SW)

Segundo Fernandes e Abreu (2012, p. 332), todos os guias são focados em cada um dos seus

sete níveis de maturidade e também em organizações específicas (que adquirem software, fábricas de

software e instituições avaliadoras).

O modelo MR-MPS-SW possui (3) guias: Guia Geral MPS de Software, Guia de Aquisição e

Guia de Implementação.

O Guia Geral MPS de Software contém as definições dos níveis de maturidade, processos e

atributos do processo; o Guia de Aquisição é um documento complementar para a aquisição de

software e o Guia de Implementação é uma série de treze documentos que fornecem orientações para

implementar nas organizações os níveis de maturidade descritos no Modelo de Referência MR-MPS-

SW.

2.3.1) Os Níveis de Maturidade

O Modelo de Referência MPS para Software (MR-MPS-SW) define níveis de maturidade que

são uma combinação entre processos e sua capacidade (SOFTEX, 2012a, p. 17).

De acordo com Fernandes e Abreu (2012, p. 333), corroborado por Softex (2012a, p. 17), os

níveis de maturidade do modelo MPS estabelecem patamares de evolução dos processos e representam

estágios de melhoria para a implementação de processos em uma organização. O nível de maturidade

em que se encontra uma organização permite prever o seu desempenho futuro ao executar um ou mais

processos.

Segundo Softex (2012a, p. 17), no modelo de referência para software MR-MPS-SW, a escala

de maturidade se inicia no nível G e progride até o nível A.

Ainda de acordo com Softex (2012a, p. 18), o progresso e o alcance de um determinado nível de

maturidade do MR-MPS-SW se obtêm quando são atendidos os propósitos e todos os resultados

esperados dos respectivos processos e os resultados esperados dos atributos de processo estabelecidos

para aquele nível. Esclarece ainda que o objetivo da divisão em 7 estágios é possibilitar uma

implementação e avaliação adequada às micros, pequenas e médias empresas. A possibilidade de se


9

realizar avaliações considerando mais níveis também permite uma visibilidade dos resultados de

melhoria de processos em prazos mais curtos.

Assim, o modelo MR-MPS-SW define (7) níveis de maturidade, mostrados a seguir no quadro

1.

Quadro 1 – Níveis de Maturidade do MR-MPS

A Em Otimização

B Gerenciado Quantitativamente

C Definido

D Largamente Definido

E Parcialmente Definido

F Gerenciado

G Parcialmente Gerenciado

Fonte: (FERNANDES e ABREU, 2012, p. 333)

No modelo MPS.BR, a instituição inicia no nível G (primeiro estágio de maturidade) e vai

progredindo gradualmente até o nível A (mais maduro). A seguir, o quadro 2 apresenta uma

comparação entre os níveis dos modelos CMMI e MPS.BR.

Quadro 2 – Comparação entre os níveis dos modelos CMMI e MPS.BR.

Níveis de Maturidade do CMMI Níveis de Maturidade do MPS.BR

5 A (Em Otimização)

4 B (Gerenciado Quantitativamente)

3,5 C (Definido)

3 D (Largamente Definido)

2,5 E (Parcialmente Definido)

2 F (Gerenciado)

1 G (Parcialmente Gerenciado

Fonte: Adaptado de (COUTO, 2007) apud (FONSECA, 2011, p. 60)

Segundo Kalinowski; et al. (2010, p. 6), cada um dos níveis de maturidade apresenta um

conjunto de processos e atributos de processos que indicam onde a instituição tem que investir esforço

para melhoria, de forma a atender aos seus objetivos de negócio e ao MR-MPS.

Os níveis são acumulativos, ou seja, se a organização está no nível F, esta possui o nível de

capacidade do nível F que inclui os atributos de processo dos níveis G e F para todos os processos

relacionados no nível de maturidade F (que também inclui os processos de nível G) (SOFTEX, 2012a,

p. 18).


10

2.3.2) Os Atributos de Processo do MR-MPS

Os processos no MR-MPS-SW são descritos em termos de propósito e resultados. O propósito

descreve o objetivo geral a ser atingido durante a execução do processo. Os resultados esperados do

processo estabelecem os resultados a serem obtidos com a efetiva implementação do processo

(SOFTEX, 2012a, p. 18). Ainda segundo Softex (2012a, p. 18), a capacidade do processo é

representada por um conjunto de atributos de processo (AP) descrito em termos de resultados

esperados.

Fernandes e Abreu (2012, p. 333) afirma que o MPS-BR possui dezenove processos,

distribuídos entre os níveis de maturidade. Fernandes e Abreu (2012, p. 336) afirma que o MPS-BR

possui nove atributos de processos (AP).

A seguir, o quadro 3 apresenta os Atributos de Processo do modelo MR-MPS.

Quadro 3 – Atributos de Processo do modelo MR-MPS

Atributos de Processo (AP) Mede o quanto ..

AP 1.1 (o processo é executado) O processo atinge seu propósito.

AP 2.1 (o processo é gerenciado) A execução do processo é gerenciada.

AP 2.2 (os produtos de trabalho do processo são

gerenciados)

Produtos de trabalho produzidos pelo processo são gerenciados

apropriadamente.

AP 3.1 (o processo é definido) Um processo padrão é mantido para apoiar a implementação do

processo definido.

AP 3.2 (o processo está implementado) O processo padrão é efetivamente implementado como um processo

definido para atingir seus resultados.

AP 4.1 (o processo é medido)

Os resultados de medição são usados para assegurar que a execução

do processo atinja os seus objetivos de desempenho e apoie o

alcance dos objetivos de negócio definidos.

AP 4.2 (o processo é controlado) O processo é controlado estatisticamente para produzir um processo

estável, capaz e previsível dentro de limites estabelecidos.

AP 5.1 (o processo é objeto de inovações)

As mudanças no processo são identificadas a partir da análise de

defeitos, problemas, causas comuns de variação de desempenho e

da investigação de enfoques inovadores para a definição e

implementação do processo.

AP 5.2 (o processo é otimizado continuamente)

As mudanças na definição, gerência e desempenho do processo têm

impacto efetivo para o alcance dos objetivos relevantes de melhoria

do processo.

Fonte: (FERNANDES e ABREU; 2012, p. 336)

Cada AP contém um conjunto de resultados de atributo de processo (RAP) utilizados para

avaliar a implementação de um AP (KALINOWSKI; et al., 2010, p. 6).

A seguir, o quadro 4 apresenta os Níveis de Maturidade, Processos e Atributos de Processo

correspondentes.


11

Quadro 4 – Níveis de Maturidade, Processos e Atributos de Processo correspondentes

Nível Processos Capacidades (AP)

A (sem processos adicionais) 1.1, 2.1, 2.2, 3.1, 3.2, 4.1*, 4.2*, 5.1*, 5.2*

B Gerência de Projetos (evolução) 1.1, 2.1, 2.2, 3.1, 3.2, 4.1*, 4.2*

C Gerência de Riscos, Desenvolvimento para

Reutilização, Gerência de Decisões 1.1, 2.1, 2.2, 3.1, 3.2

D Desenvolvimento de Requisitos, Integração do

Produto, Projeto e Construção do Produto, Validação,

Verificação 1.1, 2.1, 2.2, 3.1, 3.2

E

Avaliação e Melhoria do Processo Organizacional,

Gerência de Projetos (evolução), Gerência de Recursos

Humanos, Gerência de Reutilização, Definição do

Processo Organizacional

1.1, 2.1, 2.2, 3.1, 3.2

F Aquisição, Garantia da Qualidade, Gerência de

Configuração, Gerência de Portfólio de Projetos,

Medição

1.1, 2.1, 2.2

G Gerência de Projetos, Gerência de Requisitos 1.1, 2.1

Fonte: (KALINOWSKI; et al., 2010, p. 7)

Softex (2012a, p. 24) ressalta que alguns processos podem ser excluídos, total ou parcialmente,

do escopo de uma avaliação MPS por não serem pertinentes ao negócio da unidade organizacional que

está sendo avaliada. Cada exclusão deve ser justificada no Plano de Avaliação.

2.4) A implementação do MR-MPS-SW iniciando pelo nível G

O nível G é o primeiro nível de maturidade do MR-MPS-SW e o objetivo da implantação deste

nível é nortear a organização para que ela seja capaz de gerenciar parcialmente seus projetos de

desenvolvimento de software (CUNHA; et al., 2011, p. 23).

Dois pontos são desafiadores na implantação do nível G: (1) mudança de cultura

organizacional, orientando a definição e melhoria dos processos de desenvolvimento de software; (2)

definição do conceito acerca do que é “projeto” para a organização (SOFTEX, 2012b, p. 7).

Boria; et al. (2013, p. 36) orienta que para uma empresa que não tem processos bem definidos e

que amadureça por meio dos níveis do MPS, começando pelo nível G: a empresa precisa, primeiro, ter

o controle das tarefas, a partir dos requisitos, para poder cumprir seus compromissos. Ao invés de

correr para implementar o que o cliente quer, a equipe faz uma pausa para planejar e entre as tarefas

planejadas está o monitoramento. Surge a cultura básica de projetos. Os benefícios do Nível G se

manifestam em um melhor foco no negócio, porque os compromissos assumidos são compreendidos e

honrados. Há entendimento suficiente do estado do projeto para administrar as expectativas dos


12

clientes e existe, da mesma maneira, uma maior transparência. O estado do projeto é comunicado e

compartilhado. As expectativas são documentadas, explicadas e a alta gerência trabalha com

informação verídica. O outro resultado importante deste nível é a instituição de uma nova disciplina,

pela qual as equipes revisam e atualizam os compromissos. Estes são respeitados e todos os esforços

são feitos para que isso seja realizado com transparência.

Como resultado da adoção dessas práticas espera-se que a Gerência de Sistemas melhore seu

desempenho, o que pode vir a ser um indicativo cumprido no PDTI (Plano Diretor de Tecnologia da

Informação) da instituição.

Segundo Cunha; et al. (2011, p. 25) os benefícios adquiridos pela implementação do nível G

são:

• Obtenção de base histórica dos projetos devido às atividades de documentação;

• Estabelecimento de plano de gerenciamento e acompanhamento dos projetos;

• Capacidade de gerenciar mudança de requisitos;

• Capacidade de medir de forma padronizada os esforços, prazos e custos dos projetos;

• Reconhecimento da organização no mercado de TI;

• Início da busca de padronização do processo.

A padronização do processo não é obrigatória para certificação do nível G do MPS.BR, apenas

para certificação do nível E. Conforme estudos de caso foi verificado que a maioria das empresas

busca a padronização do seu processo logo no início da implementação do nível G (CUNHA; et al.,

2011, p. 26).

A implementação dos níveis G e F é um passo significativo em uma organização de

desenvolvimento de software (KALINOWSKI; et al., 2010, p. 7).

2.4.1) O processo Gerência de Projetos (GPR)

O propósito do processo Gerência de Projetos é estabelecer e manter planos que definem as

atividades, recursos e responsabilidades do projeto, bem como prover informações sobre o andamento

do projeto que permitam a realização de correções quando houver desvios significativos no

desempenho do projeto (SOFTEX, 2012b, p. 7).

Softex (2012b, p. 9) recomenda ser conveniente definir o que é um projeto antes de entrar no

processo de Gerência de Projetos. No MPS.BR, a definição de projeto é “um empreendimento


13

realizado para criar um produto. O projeto se caracteriza por temporalidade e resultado, produto único

e elaboração progressiva”.

Softex (2012b, p. 10) tece comentários adicionais para implementação em diferentes tipos de

organização: adquirentes de software, fábrica de software e fábrica de teste; tecendo comentários

também para cada resultado esperado.

A Gerência de Projetos possui dezenove resultados esperados no nível G. A seguir, o quadro 5

apresenta os resultados esperados do processo de Gerência de Projetos no nível G.

Quadro 5 – Resultados esperados do processo de Gerência de Projetos no nível G

Sigla Resultados Esperados Comentários

GPR1 O escopo do trabalho para o projeto é definido O escopo do projeto define todo o trabalho necessário, e

somente ele, para entregar um produto que satisfaça as

necessidades, características e funções especificadas para o

projeto, de forma a concluí-lo com sucesso.

GPR2 As tarefas e os produtos de trabalho do projeto são

dimensionados utilizando métodos apropriados

O escopo do projeto, identificado na forma dos seus

principais produtos de trabalho e das tarefas do projeto, deve

agora ser decomposto em componentes menores, mais

facilmente gerenciáveis e possíveis de serem dimensionados.

GPR3 O modelo e as fases do ciclo de vida do projeto

são definidos

O ciclo de vida de um projeto consiste de fases e atividades

que são definidas de acordo com o escopo dos requisitos, as

estimativas para os recursos e a natureza do projeto, visando

oferecer maior controle gerencial.

GPR4 O esforço e o custo para a execução das tarefas e

dos produtos de trabalho são estimados com base

em dados históricos ou referências técnicas

As estimativas de esforço e custo são, normalmente,

baseadas nos resultados de análises utilizando modelos e/ou

dados históricos aplicados ao tamanho, atividades e outros

parâmetros de planejamento.

GPR5 O orçamento e o cronograma do projeto, incluindo

a definição de marcos e pontos de controle, são

estabelecidos e mantidos

As dependências entre tarefas são estabelecidas e potenciais

gargalos são identificados utilizando métodos apropriados

(por exemplo, análise de caminho crítico).

GPR6 Os riscos do projeto são identificados e o seu

impacto, probabilidade de ocorrência e prioridade

de tratamento são determinados e documentados

Projetos têm riscos e estes precisam ser dentificados,

analisados e priorizados.

GPR7 Os recursos humanos para o projeto são

planejados considerando o perfil e o conhecimento

necessários para executá-lo

O planejamento de recursos humanos determina funções,

responsabilidades e relações hierárquicas do projeto. As

funções do projeto podem ser designadas para pessoas ou

grupos, os quais podem ser internos ou externos à

organização.

GPR8 Os recursos e o ambiente de trabalho necessários

para executar o projeto são planejados

Faz referência à necessidade de se planejar, com base na

EAP (ou estrutura equivalente), as tarefas e prever os

recursos e o ambiente necessários, incluindo, por exemplo,

equipamentos, ferramentas, serviços, componentes, viagens e

requisitos de processo.

GPR9 Os dados relevantes do projeto são identificados e

planejados quanto à forma de coleta,

armazenamento e distribuição. Um mecanismo é

estabelecido para acessá-los, incluindo, se

pertinente, questões de privacidade e segurança

Os dados do projeto são as várias formas de documentação

exigidas para sua execução, por exemplo: relatórios; dados

informais; estudos e análises; atas de reuniões;

documentação; lições aprendidas; artefatos gerados; itens de

ação; e indicadores.

GPR10 Um plano geral para a execução do projeto é

estabelecido com a integração de planos

específicos

O objetivo deste resultado esperado é garantir que todos os

planos que afetam o projeto estejam integrados e que a

dependência entre estes planos tenha sido identificada e

levada em consideração durante o planejamento, conciliando

o trabalho a ser realizado aos recursos e condições

existentes.


14

GPR11 A viabilidade de atingir as metas do projeto é

explicitamente avaliada considerando restrições e

recursos disponíveis. Se necessário, ajustes são

realizados

O estudo de viabilidade considera o escopo do projeto e

examina aspectos técnicos (requisitos e recursos), financeiros

(capacidade da organização) e humanos

(disponibilidade de pessoas com a capacitação necessária).

GPR12 O Plano do Projeto é revisado com todos os

interessados e o compromisso com ele é obtido e

mantido

Para obter compromissos dos interessados relevantes, é

importante revisar o planejamento com eles e conciliar as

diferenças existentes entre os recursos estimados e

disponíveis.

GPR13 O escopo, as tarefas, as estimativas, o orçamento e

o cronograma do projeto são monitorados em

relação ao planejado

A aderência aos diversos planos deve ser avaliada

continuamente durante todo o ciclo de vida do projeto.

GPR14 Os recursos materiais e humanos bem como os

dados relevantes do projeto são monitorados em

relação ao planejado

O objetivo deste resultado esperado é garantir que o projeto

seja monitorado em relação aos itens planejados referentes a

recursos materiais e recursos humanos (ver GPR7 e GPR8).

GPR15 Os riscos são monitorados em relação ao

planejado

No decorrer do projeto novos riscos podem ser identificados

para o projeto e os parâmetros dos riscos já identificados

podem ser alterados (ver GPR6).

GPR16 O envolvimento das partes interessadas no projeto

é planejado, monitorado e mantido

Devem ser identificados os interessados relevantes no

projeto, em que fases eles são importantes e como eles serão

envolvidos (comunicações, revisões em marcos de projeto,

comprometimentos, entre outros).

GPR17 Revisões são realizadas em marcos do projeto e

conforme estabelecido no planejamento

Revisões em marcos do projeto não devem ser confundidas

com o acompanhamento descrito em GPR13, GPR14 e

GPR15, que é derivado do acompanhamento do dia-a-dia do

projeto. Os marcos do projeto precisam, portanto, ser

previamente definidos ao se realizar o planejamento do

projeto.

GPR18 Registros de problemas identificados e o resultado

da análise de questões pertinentes, incluindo

dependências críticas, são estabelecidos e tratados

com as partes interessadas

As atividades de revisão em marcos (GPR17) e de

monitoramento (GPR13, GPR14 e GPR15) do projeto

possibilitam a identificação de problemas que estejam

ocorrendo nos projetos. É natural que problemas e desvios

em relação ao planejamento aconteçam durante a execução

dos projetos. Estes problemas e desvios devem ser analisados

e registrados, por exemplo, por meio de ferramentas

específicas, planilhas ou outros tipos de mecanismos de

gerenciamento de problemas.

GPR19 Ações para corrigir desvios em relação ao

planejado e para prevenir a repetição dos

problemas identificados são estabelecidas,

implementadas e acompanhadas até a sua

conclusão

Como resultado do acompanhamento do projeto (GPR13,

GPR14 e GPR15) e das revisões em marcos (GPR17),

problemas são identificados, analisados e registrados

(GPR18). Ações corretivas devem ser estabelecidas para

resolver problemas que possam impedir o projeto de atingir

seus objetivos se não forem resolvidos de forma adequada.

Fonte: Adaptado de (SOFTEX, 2012b, p. 11-29)

2.4.2) O processo Gerência de Requisitos (GRE)

O propósito do processo Gerência de Requisitos é gerenciar os requisitos do produto e dos

componentes do produto do projeto e identificar inconsistências entre os requisitos, os planos do

projeto e os produtos de trabalho do projeto. (SOFTEX, 2012b, p. 30).

Softex (2012b, p. 30) orienta que esse processo gerencia todos os requisitos recebidos ou

gerados pelo projeto, incluindo requisitos funcionais e não-funcionais, bem como os requisitos


15

impostos ao projeto pela organização. Outra atribuição do processo é documentar as mudanças nos

requisitos e suas justificativas.

Softex (2012b, p. 31) orienta que é fundamental para assegurar um bom entendimento das

necessidades do cliente e dos requisitos do projeto e, consequentemente, aumentar as chances de

sucesso do projeto. E ainda, que cabe á Gerência de Requisitos identificar os requisitos do produto e

dos componentes do produto do projeto, bem como estabelecer e manter um acordo entre o cliente e a

equipe de projeto sobre esses requisitos; também é objetivo da Gerência de Requisitos controlar e

tratar as mudanças nos requisitos ao longo do desenvolvimento.

Softex (2012b, p. 30) tece comentários adicionais para implementação em diferentes tipos de

organização: adquirentes de software, fábrica de software e fábrica de teste; tecendo comentários

também para cada resultado esperado.

A Gerência de Requisitos possui cinco resultados esperados no nível G. A seguir, o quadro 6

apresenta os resultados esperados do processo de Gerência de Requisitos no nível G.

Quadro 6 – Resultados esperados do processo de Gerência de Requisitos no nível G

Sigla Resultados Esperados Comentários

GRE1 O entendimento dos requisitos é obtido junto aos

fornecedores de requisitos

O objetivo deste resultado é garantir que os requisitos

estejam claramente definidos a partir do entendimento dos

requisitos realizado junto aos fornecedores de requisitos.

Informações sobre esses fornecedores podem ser

identificadas no plano

do projeto, bem como informações sobre como será a

comunicação com eles. Essas comunicações devem ser

registradas formalmente em atas, e-mails, ferramentas de

comunicação ou outros meios.

GRE2 Os requisitos são avaliados com base em critérios

objetivos e um comprometimento da equipe técnica

com estes requisitos é obtido

A avaliação e aprovação por parte do cliente após o

entendimento dos requisitos por si só não é suficiente para

que os requisitos sejam refinados e refletidos em modelos

de análise e projeto para a codificação. A avaliação dos

requisitos deve envolver, além do cliente, também, a

equipe técnica da organização, podendo ser realizada de

diversas formas.

GRE3 A rastreabilidade bidirecional entre os requisitos e os

produtos de trabalho é estabelecida e mantida

Este resultado indica a necessidade de se estabelecer um

mecanismo que permita rastrear a dependência entre os

requisitos e os produtos de trabalho. Ter definida a

rastreabilidade facilita a avaliação do impacto das

mudanças de requisitos que possam ocorrer, por exemplo,

nas estimativas do escopo, nos produtos de trabalho ou nas

tarefas do projeto descritas no cronograma.

GRE4 Revisões em planos e produtos de trabalho do

projeto são realizadas visando a identificar e corrigir

inconsistências em relação aos requisitos

A consistência entre os requisitos e os produtos de

trabalho do projeto deve ser avaliada e os problemas

identificados devem ser corrigidos.

GRE5 Mudanças nos requisitos são gerenciadas ao longo

do projeto

Durante o projeto, os requisitos podem mudar por uma

série de motivos. Destaforma, requisitos adicionais podem

ser incorporados no projeto, requisitos podem ser retirados

do projeto e/ou mudanças podem ser feitas nos requisitos

já existentes.


16


2.4.3) Os Atributos de Processo do nível G

Softex (2012a, p. 18) orienta que no modelo MR-MPS-SW, à medida que a organização evolui

nos níveis de maturidade, um maior nível de capacidade para desempenhar o processo deve ser

atingido. E que o atendimento aos atributos do processo (AP), pelo atendimento aos resultados

esperados dos atributos do processo (RAP), é requerido para todos os processos no nível

correspondente ao nível de maturidade, embora eles não sejam detalhados dentro de cada processo.

Numa avaliação, segundo o MA-MPS, é exigido, para se considerar um processo

“SATISFEITO” no nível G, que o atributo de processo AP 1.1 seja caracterizado como T (Totalmente

implementado) e que o atributo de processo AP 2.1 seja caracterizado como T (Totalmente

implementado) ou L (Largamente implementado) (SOFTEX, 2012b, p. 38).

A seguir no quadro 7, os atributos de processo AP 1.1 e AP 2.1, aplicáveis no nível G, são

descritos com detalhes.

Quadro 7 – Atributos de Processo AP 1.1 e AP 2.1 no nível G

Atributo de Processo Comentário Resultado Esperado

AP 1.1 - O processo é

executado

Este atributo evidencia o

quanto o processo atinge o

seu propósito.

RAP1 - O processo atinge seus resultados definidos

AP 2.1 - O processo é

gerenciado

Este atributo evidencia o

quanto a execução do

processo é gerenciada.

RAP2 - Existe uma política organizacional estabelecida e

mantida para o processo

RAP3 - A execução do processo é planejada

RAP4 - (Para o nível G) A execução do processo é

monitorada e ajustes são realizados

RAP5 - As informações e os recursos necessários para a

execução do processo são identificados e

disponibilizados

RAP6 - (Até o nível F) As responsabilidades e a

autoridade para executar o processo são definidas,

atribuídas e comunicadas

RAP7 - As pessoas que executam o processo são

competentes em termos de formação, treinamento e

experiência

RAP8 - A comunicação entre as partes interessadas no

processo é planejada e executada de forma a garantir o

seu envolvimento

RAP9 - (Até o nível F) Os resultados do processo são

revistos com a gerência de alto nível para fornecer

visibilidade sobre a sua situação na organização

RAP10 - (Para o nível G) O processo planejado para o

projeto é executado


17


2.5) Vantagens e dificuldades na implementação do MR-MPS-SW

Segundo Rodrigues; Kirner (2010, p. 43), as principais vantagens ou benefícios adquiridos com

a implementação do modelo, destacados na literatura, são: melhoria no gerenciamento de projetos de

desenvolvimento; redução de custos; menor tempo de resposta; aumento de produtividade; melhoria no

cumprimento de prazos e custos; entre outras.

Segundo Rodrigues; Kirner (2010, p. 44), as dificuldades enfrentadas com a implementação do

modelo, destacados na literatura, são: limitação de recursos humanos; limitação de recursos

financeiros; falta de comprometimento gerencial; resistência a mudanças por parte dos colaboradores;

treinamentos inadequados ou insuficientes; falta de consultoria adequada; entre outras.

2.6) Sugestões para implementação do MR-MPS-SW

Em média, as empresas gastaram 1 (um) ano e 6 (seis) meses para implementar o modelo de

melhoria de processo MPS.BR Nível G (CUNHA; et al., 2011, p. 28).

Nas conclusões do trabalho de Cunha; et al. (2011, p. 28-29), onde foram realizados estudos de

caso em quatro empresas que passaram pelo processo de implementação e que também obtiveram a

certificação no nível G, foi possível detectar algumas experiências ou recomendações importantes para

implementação do nível G do modelo MPS.BR tais como:

A padronização dos processos pode permitir maior definição de uma metodologia de

desenvolvimento para orientar os colaboradores no desenvolvimento de suas atividades;

A necessidade da formação de uma equipe de implementação estimulando a participação

integral de todos colaboradores;

A necessidade que a equipe de implementação tenha pelo menos 2 (dois) integrantes

consultores de instituições implementadoras. Com o auxílio desses consultores, a

instituição pode criar uma nova metodologia de desenvolvimento durante a implementação

do modelo de melhoria de software;


18

A produção de artefatos exigidos pela implementação do modelo exige mais tempo de

trabalho tornando o processo pouco produtivo; e isso pode criar uma resistência dos

colaboradores em relação às mudanças ocorridas em suas atividades diárias;

O tempo disponibilizado para a auditoria do processo é insuficiente para apresentar todos

os resultados esperados, aumentando a possibilidade de erros de interpretação das

evidências;

A qualidade do serviço prestado pela consultoria é melhor, quando as instituições são da

mesma região;

As orientações apresentadas no Guia de Implementação do modelo MPS.BR trazem

informações “do que deve ser feito”, mas não ofereceram sugestões suficientes e objetivas

de “como devem ser feito”;

Basear somente na documentação disponibilizada pela Softex não foi suficiente para

implementar o processo proposto pelo modelo MPS.BR, tornando as empresas

dependentes de consultorias externas.

Ainda segundo as conclusões do trabalho de Cunha; et al. (2011, p. 29), a implementação do

modelo MPS.BR foi relevante pela identificação de melhoria dos processos e pelos benefícios obtidos

pelas empresas participantes, embora essas mesmas empresas apontem dificuldades significativas para

a efetiva implementação do modelo.

3 – Metodologia

A metodologia deste artigo de natureza qualitativa, iniciou-se com uma pesquisa bibliográfica

para a compreensão de conceitos sobre melhoria de processo de software e em seguida do modelo de

referência MPS.BR. Este tipo de pesquisa é desenvolvido a partir de material já elaborado, constituído

principalmente de livros e artigos científicos (GIL, 2008, p. 50).

Baseado na revisão da literatura foi possível também entender o modelo MPS.BR e identificar

sugestões e recomendações visando a implementação do nível G do modelo MR-MPS para a melhoria

de processo de software nas Gerências de Sistemas de Informação das IFES.


19

Segundo Moresi (2003, p. 9), a natureza da pesquisa qualitativa é descritiva e não requer o uso

de métodos e técnicas estatísticas. Quanto aos fins, essa pesquisa pode ser considerada descritiva e

explicativa. Segundo Gil (2008, p. 28), as pesquisas descritivas têm como objetivo a descrição das

características de determinada população ou fenômeno ou o estabelecimento de relações entre

variáveis; as pesquisas explicativas têm como objetivo identificar os fatores que determinam ou que

contribuem para a ocorrência dos fenômenos.

4 – Considerações Finais

O objetivo desse estudo do modelo para melhoria do processo de software MPS.BR foi

bastante elucidador, visto que foram observadas as principais vantagens e as principais dificuldades

encontradas na literatura sobre a implementação do modelo. As sugestões apresentadas por Cunha; et

al. (2011, p. 29), foram elencadas e, de certa forma, tem por objetivo minimizar as dificuldades

relatadas em trabalhos de outros autores.

Então, através da revisão da literatura e de experiências relatadas nesse trabalho, sugere-se que

as implementações em outras empresas sejam levadas em consideração para se evitar procedimentos

equivocados e colocar ênfase nos procedimentos corretos. Logicamente, devem ser guardadas as

proporções das particularidades inerentes a cada instituição que busquem passar pelo processo de

implementação do modelo MPS.BR.

Conclui-se, portanto, que para se atingir o objetivo da adoção, implementação e a respectiva

avaliação no nível G do modelo MPS.BR na Gerência de Sistemas de Informação das IFES, além das

experiências ou recomendações relatadas nessa pesquisa, outros fatores bastante importantes também

devem ser levados em consideração:

(1) apoio irrestrito da administração superior;

(2) estabelecimento de metas claras;

(3) capacitação prévia dos colaboradores envolvidos na implementação do modelo MPS.BR;

(4) minimização da causa de resistência à mudanças por parte dos colaboradores através da

conscientização dos benefícios a serem alcançados;


20

(5) IFES são instituições públicas onde existe certa burocracia regulatória, tornando-se

necessário licitar previamente o serviço externo de consultoria e avaliação para evitar

atrasos ou insucesso da implementação do modelo MPS.BR.

5 – Referências Bibliográficas:

BORIA, Jorge Luiz; RUBINSTEIN, Viviana L.; RUBINSTEIN, Andrés. A História da Tahini-

Tahini: Melhoria de Processos de Software com Métodos Ágeis e Modelo MPS. 9. ed. Brasília:

Ministério da Ciência, Tecnologia e Inovação, 2013. 201 p.

CUNHA, Izabella B. A.; DIAS, Kesia J.A.N.; RESENDE JUNIOR, Humberto C. Dificuldades

encontradas na implementação MPS.BR Nível G: Estudo de Caso. 2011. Disponível em: <

http://revistas.unibh.br/index.php/dcet/article/view/330>. Acesso em: 22 dez. 2014.

FERNANDES, Aguinaldo A.; ABREU, Vladimir F. Implantando a GOVERNANÇA DE TI: da

Estratégia à Gestão de Processos e Serviços. – 3. ed. – Rio de Janeiro: Brasport, 2012. 615 p.

FLICK, Uwe. Introdução à Metodologia de Pesquisa: um guia para iniciantes. – 1. ed. – São Paulo:

Penso Editora, 2012. 256 p.

FONSECA, Letícia R. Um Caso de Simbiose entre o Modelo “Melhoria de Processos do Software

Brasileiro” (MpsBr) e Aprendizagem Organizacional: um Estudo em uma Organização de

Desenvolvimento de Software. 2011. Disponível em: <http://revistagt.fpl.edu.br/get/article/view/282>.

Acesso em: 22 dez. 2014.

GIL, Antônio Carlos. Métodos e técnicas de pesquisa social. – 6. ed. – São Paulo: Atlas, 2008. 206 p.

ISO/IEC (INTERNATIONAL ORGANIZATION FOR STANDARDIZATION/ INTERNATIONAL

ELECTROTECHNICAL COMISSION). ISO/IEC 12207 Systems and software engineering–Software

life cycle processes, Geneve: ISO, 2008a.

ISO/IEC (INTERNATIONAL ORGANIZATION FOR STANDARDIZATION/ INTERNATIONAL

ELECTROTECHNICAL COMISSION). ISO/IEC 20000 Information Technology–Service

Management, Geneve: ISO, 2011b.

KALINOWSKI, Marcos et al. MPS.BR: Promovendo a Adoção de Boas Práticas de Engenharia

de Software pela Indústria Brasileira. In: CIBSE – XIII CONGRESO IBEROAMERICANO EN

“SOFTWARE ENGINEERING”, 13., 2010, Cuenca. Rio de Janeiro: Softex, 2010. p. 12 - 16.

Disponível em: <http://www.softex.br/wp-

content/uploads/2013/09/CIBSE2010_MPSBR_CameraReady.pdf>. Acesso em: 27 nov. 2014.

MORESI, Eduardo (Organizador). Pró-reitoria de Pós-graduação – PRPG (Org.). Metodologia da

Pesquisa. Brasília: Universidade Católica de Brasília – UCB, 2003. 108 p. Disponível em:

<http://www.inf.ufes.br/~falbo/files/MetodologiaPesquisa-Moresi2003.pdf>. Acesso em: 27 jun. 2014.


21

PMI. A guide to the Project Management Body of Knowledge (PMBOK) – Fifth edition –

Newtown Square, 2013. Disponível em:

<http://quantfinancenotes.files.wordpress.com/2013/09/project-management-body-of-knowledge-

pmbok-guide-5th-ed.pdf>. Acesso em: 30 mai. 2014.

PRESSMAN, Roger S. Engenharia de Software: uma abordagem profissional. – 7. ed. – Porto

Alegre: AMGH, 2011. 780 p.

RODRIGUES, Juliana França; KIRNER, Teresa Gonçalves. Benefícios, Fatores de Sucesso e

Dificuldades da Implantação do Modelo MPS.BR. Disponível em:

<http://www.lbd.dcc.ufmg.br/colecoes/sbqs/2010/TT3_rodrigues.pdf>. Acesso em: 09 jan. 2012.

SEI (SOFTWARE ENGINEERING INSTITUTE). CMMI for Development (CMMI-DEV), Version

1.3, Technical Report CMU/SEI-2010-TR-033.Pittsburgh, PA: Software Engineering Institute,

Carnegie Mellon University, 2010a. Disponível em: <http://www.sei.cmu.edu/reports/10tr033.pdf>.

Acesso em: 22 jan. 2013.

SEI (SOFTWARE ENGINEERING INSTITUTE). CMMI for Services, Version 1.3, Technical

Report CMU/SEI-2010-TR-034.Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon

University, 2010b.

SOFTEX (ASSOCIAÇÃO PARA PROMOÇÃO DA EXCELÊNCIA DO SOFTWARE

BRASILEIRO). MPS.BR - Melhoria de Processo do Software Brasileiro: Guia Geral MPS de

Software. São Paulo, 2012a. Disponível em: <http://www.softex.br/wp-

content/uploads/2013/07/MPS.BR_Guia_Geral_Software_2012.pdf>. Acesso em: 22 jan. 2013.

SOFTEX (ASSOCIAÇÃO PARA PROMOÇÃO DA EXCELÊNCIA DO SOFTWARE

BRASILEIRO). MPS.BR - Melhoria de Processo do Software Brasileiro: Guia de Implementação –

Parte 1: Fundamentação para Implementação do Nível G do MR-MPS-SW:2012. São Paulo, 2012b.

Disponível em: < http://www.softex.br/wp-

content/uploads/2013/07/MPS.BR_Guia_de_Implementacao_Parte_1_2013.1.pdf>. Acesso em: 22

jan. 2013.

SOMMERVILLE, Ian. Engenharia de Software. – 9. ed. – São Paulo: Pearson Prentice Hall, 2011.

529 p.

WIKIDOT. MPS.BR Qualidade de Software: Melhoria de Processos do Software Brasileiro -

MPS.BR. Disponível em: <http://qualidade.wikidot.com/mpsbr-qualidade-de-software>. Acesso em:

28 nov. 2013.

ESTUDO PARA ADOÇÃO E IMPLANTAÇÃO DO NÍVEL G DO MODELO … · ... está a adoção do modelo...

Documents

Transcript of ESTUDO PARA ADOÇÃO E IMPLANTAÇÃO DO NÍVEL G DO MODELO … · ... está a adoção do modelo...