Engenharia
Nesta seção você encontra artigos voltados para testes, processo,
modelos, documentação, entre outros
Maturidade em Desenvolvimento de Software
O caso do MPS.BR – Melhoria de Processo do Software Brasileiro
Aline Rodrigues
alinecrodrigues@gmail.com
Analista de Sistemas graduada em Bacha-
relado de Sistemas de Informação pela
Faculdade Ruy Barbosa e pós-graduanda
em Engenharia de Software na pós gradu-
ação Ruy Barbosa. Atua como analista de
requisitos no Instituto do Meio Ambiente
pela Avansys Tecnologia, na liderança de
projetos, de desenvolvimento, supervisão
de equipe técnica, especificação e detalha-
mento de requisitos.
Roberto B. Figueredo
beto.boscolo@gmail.com
Bacharel em Sistemas de Informação pela
Faculdade Ruy Barbosa. Pós-graduando
em Engenharia de Software pela Faculdade
Ruy Barbosa. Há quatro anos atuando como
desenvolvedor e analista de sistemas.
Rodrigo Spínola
rodrigo@sqlmagazine.com.br
Doutor e Mestre em Engenharia de Sof-
tware pela COPPE/UFRJ.
Diretor de Operações – Kali Software
(www.kalisoftware.com)
Editor Chefe – SQL Magazine | WebMobile |
Engenharia de Software Magazine
Professor do Curso de Pós-Graduação em
Engenharia de Software da Faculdade
Ruy Barbosa.
N
o Brasil, devido em parte à
grande quantidade de empre-
sas prestadoras de serviços de
software que estão surgindo no mer-
cado, os clientes passaram a exigir um
maior nível de qualidade.
As grandes empresas desenvolvedoras
de software investem muito dinheiro em
busca da obtenção de uma certificação
com o intuito de atingir um nível de pro-
dutividade e qualidade internacionais e
principalmente uma diferenciação no
mercado nacional. Desenvolver e dar
suporte a sistemas de software é uma
tarefa desafiadora. Esse desafio passa
a ser ainda maior para as pequenas e
médias empresas brasileiras. O custo de
implantação de um modelo de maturi-
dade de software internacional, como é
o caso do CMMI, é elevadíssimo, muitas
vezes fora da realidade das empresas
brasileiras.
Edição 37 - Engenharia de Software Magazine
De que se trata o artigo?
Este artigo apresenta o MPS.BR abordando suas
principais definições e destacando seus níveis ini-
ciais de maturidade.
Para que serve?
O MPS.BR define um modelo de melhoria e ava-
liação de processos de software com o foco nas
pequenas e médias empresas brasileiras. Ele es-
tabelece um modelo de processos de software e
um método de avaliação de processos de modo a
garantir que o MPS.BR está sendo empregado de
forma coerente com as suas definições.
Em que situação o tema é útil?
A discussão deste tema é útil para empresas que
tenham interesse no modelo de maturidade de-
finido pelo MPS BR e para profissionais da área
de software que queiram atualizar seu conheci-
mento sobre o assunto.
A partir da constatação de que as
empresas brasileiras precisariam de
um modelo que se adequasse à sua
realidade, a Softex, em parceria com o
governo e universidades iniciou em 2003
o Programa de Melhoria de Processo
27
de Software Brasileiro – MPS. BR. O MPS.BR é uma solução
brasileira totalmente compatível com o modelo CMMI e em
harmonia com as normas ISO/IEC 12207 e 15504. Neste con-
texto, neste artigo apresentaremos o MPS.BR destacando seus
níveis iniciais de maturidade.
MPS.BR
O MPS.BR define um modelo de melhoria e avaliação de
processos de software com o foco nas pequenas e médias em-
presas brasileiras, de modo a atender as suas necessidades de
negócio e ser reconhecido nacional e internacionalmente como
um modelo aplicável à indústria de software. Ele estabelece um
modelo de processos de software e um método de avaliação
de processos de modo a garantir que o MPS.BR está sendo
empregado de forma coerente com as suas definições.
Principais Conceitos
Alguns conceitos são essenciais para o entendimento do
modelo. A maioria deles são tirados de normas como ISO
12204 e ISO 15504:
• Processo de software: framework para todas as tarefas que
são necessárias para construir software de alta qualidade
(PRESSMAN, 2007);
• Atributo de processo: característica mensurável da capa-
cidade do processo aplicável a qualquer processo (ISO/IEC
15504-1, 2004);
• Resultado esperado: um resultado observável do sucesso
do alcance do propósito do processo (ISO/IEC 12207:1995/
Amd 1:2002);
• Capacidade do processo: uma característica da habilidade
do processo atingir os objetivos de negócio atuais ou futuros
(ISO/IEC 15504-1, 2004). Essa capacidade é representada por
um conjunto de atributos de processo que são descritos em
termos de resultados esperados. Expressa o grau de refina-
mento e institucionalização com que o processo é executado
na organização. Para uma organização passar para um nível
mais alto de maturidade cada processo deve alcançar um nível
maior de capacidade.
• Ativo de processo: qualquer coisa que a organização consi-
dere útil para atingir os objetivos do processo como políticas,
processos definidos, lições aprendidas, templates de documen-
tos, padrões, material de treinamento (SEI, 2006);
• Perfil do Processo: conjunto de pontuação de atributos de
processo para um processo avaliado (ISO/IEC 15504-1, 2004).
Guias MPS.BR
O modelo MPS.BR é descrito por meio de quatro documentos
em formato de guias. São eles: guia geral, guia de implemen-
tação, guia de aquisição e guia de avaliação.
Guia Geral
Descreve de forma detalhada todo o MPS.BR assim como as de-
finições sobre cada um dos documentos que compõem o modelo.
Nesse documento encontram-se todos os conceitos relacionados
ao MPS.BR, a descrição detalhada de cada nível de maturidade
28 Engenharia de Software Magazine - Maturidade em Desenvolvimento de Software
e dos processos que fazem parte de cada nível, seus propósitos,
além da descrição dos atributos de processo, que são requeridos
para o alcance de determinado nível de maturidade e o resultado
esperado dos processos e dos atributos de processo.
O Guia Geral é destinado a todas as organizações interessadas
em melhorar os seus processos de software e a instituições cujo
objetivo é implementar ou avaliar o modelo. Essas instituições
devem ser autorizadas, mediante convênio com a Softex com
base em um parecer do Fórum de Credenciamento e Controle.
Guia de Implementação
Fornece orientações para implementar os níveis de maturida-
de descritos no modelo de referência MR-MPS, detalhando os
processos contemplados nos respectivos níveis de maturidade
e os resultados esperados com a implementação dos processos.
O guia de implementação é dividido em 10 partes iniciando
com a implementação do nível mais baixo de maturidade, nível
G. Os demais documentos seguem com a implementação dos
demais níveis e a partir da parte 8 passa a descrever orientações
para a implementação do modelo de referência para organiza-
ções que adquirem software, que trabalham como uma Fábrica
de Software ou Fábrica de Testes de software.
Guia de Aquisição
Descreve um processo de aquisição de software e serviços
correlatos visando servir como um guia para empresas que
adquirem esses serviços. O guia detalha todas as atividades e
tarefas envolvidas, descreve os produtos de trabalho e fornece
exemplos de como os principais documentos são preenchidos.
São considerados nesse contexto tanto o produto de softwa-
re propriamente dito como os serviços relacionados ao seu
desenvolvimento como manutenção, suporte, implantação,
treinamento, configuração do software e do ambiente opera-
cional, entre outros. Também é ajustado para aquisições de
produtos de prateleira, produtos personalizados ou de domínio
específico tanto por instituições privadas como por institui-
ções públicas. O guia possui diversos anexos apresentando
sugestões de modelos de documentos que podem utilizados
e personalizados pelos compradores.
Guia de Avaliação
Tem o objetivo de verificar a maturidade organizacional na
execução dos seus processos de software. Este guia descreve
as atividades e tarefas a serem realizadas para verificar se a
organização alcançou determinado nível de maturidade. Esse
processo permite a avaliação objetiva de uma organização ou
unidade organizacional, permite que se atribua um nível de
maturidade com base no resultado da avaliação tanto para
uma unidade como para a organização como um todo, sendo
aplicável a qualquer domínio na indústria de software e a
organizações de qualquer tamanho.
A avaliação tem início com a seleção de uma Instituição Ava-
liadora que registrará a avaliação na base de dados confidencial
da Softex. De acordo com o Guia de Avaliação, para que uma
avaliação tenha sucesso, é necessário:
 PROC ESS O

• Comprometimento do patrocinador, de modo que todos os

recursos necessários estejam disponíveis para a execução da
avaliação;
• Motivação por parte dos participantes da avaliação, respon-
sabilidade do gerente da unidade organizacional;
• Fornecimento de feedback de modo que seja possível que
a organização discuta sobre os resultados da avaliação fa-
zendo com que a avaliação seja significativa para a unidade
organizacional;
• Confidencialidade das informações durante a avaliação
para que nenhum entrevistado se sinta ameaçado e para que
todos possam se expressar livremente. Também abrange as
informações contidas nos documentos;
• Todos os membros devem perceber que a avaliação resul-
tará em benefícios que os ajudarão no desempenho do seu
trabalho.
• Os patrocinadores e colaboradores da unidade organizacional
Figura 1. Comparação entre os modelos MPS.BR e o CMMI
devem confiar nos avaliadores, afinal, a avaliação deve chegar
a um resultado representativo para eles.

Níveis de Maturidade
Os níveis de maturidade do MPS.BR, como no CMMI, esta-
belecem patamares de evolução de processos caracterizando
estágios de melhoria da implementação de processos organi-
zacionais. Essa divisão, embora baseada no CMMI, tem uma
graduação diferente. O MPS.BR subdividiu dois níveis do
modelo CMMI para melhor se adequar à realidade das micro e
pequenas empresas brasileiras. Na Figura 1 temos um quadro
comparativo entre os níveis de maturidade MPS.BR e os níveis
de maturidade do CMMI.
Essa maior graduação de níveis de maturidade possibilita
às empresas brasileiras uma evolução mais gradual e com
um custo inferior a sua equivalente internacional. Um maior
número de níveis possibilita também uma comparação mais
precisa entre unidades intra e inter-organizacionais. Figura 2. ฀ ฀ ฀ ฀ ฀ ฀
Assim, o MPS.BR define 7 níveis de maturidade: A (Em
Otimização, B (Gerenciado Quantitativamente), C (Defini- processo é executado na organização. Um determinado nível
do), D (Largamente Definido), E (Parcialmente Definido), F de capacidade de um processo é atingido quando os resultados
(Gerenciado), G (Parcialmente Gerenciado) conforme mostra esperados de cada atributo de processo requerido para aquele
a Figura 2. nível é atingido. É necessário que todos os processos requeridos
para determinado nível de maturidade atinjam os resultados
Processos esperados dos atributos requeridos para aquele nível.
De acordo com (PRESSMAN, 2006), processo de software é Os níveis de capacidade dos processos são cumulativos.
um framework contendo todas as atividades necessárias para Para uma organização avançar do nível de maturidade G
a construção de software de qualidade. No MPS.BR eles são para o nível F, é necessário que todos os processos, tanto os
descritos em termos de propósitos e resultados esperados, ou de nível G como os de nível F, estejam no nível de capacida-
seja, os objetivos gerais a serem atingidos pelo processo e os de relativo ao nível de maturidade F. Assim, os processos
resultados que se espera que o processo gere pela sua efetiva do nível G devem possuir todos os atributos de processo
implementação. Esses resultados podem ser artefatos como do nível F.
documentos e componentes de software ou podem ser apenas
uma mudança no estado do processo. Atributos de processo
Na versão mais recente do MPS.BR são descritos nove atri-
Capacidade dos processos butos de processo:
A capacidade do processo é a propriedade que expressa • AP 1.1: O processo é executado: o processo atinge o seu
o grau de refinamento e institucionalização com que cada propósito não importando de que maneira ele é executado.

Edição 37 - Engenharia de Software Magazine 29

• AP 2.1: O processo é gerenciado: a execução do processo
é gerenciada. Uma política organizacional é mantida para o
processo, planejamento da execução, monitoramento e ajustes
realizados para atender o que foi planejado, entre outras ativi-
dades de gerenciamento.
• AP 2.2: Os produtos de trabalho do processo são gerencia-
dos: gerenciamento apropriado de todos os artefatos gerados
na execução do projeto.
• AP 3.1: O processo é definido: medida de quão padroniza-
dos estão os processos. Processos que possuem esse atributo
seguem um padrão definido para a sua execução. Significa
que em todos os projetos da organização esse projeto deverá
ser executado de acordo com diretrizes definidas.
• AP 3.2: O processo está implementado: o processo está sendo
efetivamente implementado como um processo definido para
atingir os seus resultados. Coleta e análise de dados são reali-
zadas para que esse processo passe a ser mais bem entendido
pela organização e para que sejam identificados em que pontos
do processo podem ser feitas melhorias contínuas.
• AP 4.1: O processo é medido: a partir do conjunto de pro-
cessos padronizados da empresa, medições são realizadas
nos processos relevantes da organização. Esse atributo é uma
medida de quanto os resultados das medições são usados para
melhoria de processos.
• AP 4.2: O processo é controlado: medida de quanto o pro-
cesso é controlado utilizando-se dados estatísticos.
• AP 5.1: O processo é objeto de inovações: medida de
quanto as mudanças no processo são identificadas a partir
de análise de causas comuns de variação do desempenho e
da investigação de enfoques inovadores para a definição e
inovação do processo. São definidos objetivos de melhoria
no processo. Dados são coletados a partir de medições feitas
estatisticamente para identificar causas comuns de variação
do desempenho do processo.
• AP 5.2: O processo é otimizado continuamente: medida de
quanto as mudanças têm impacto efetivo para o alcance dos
objetivos relevantes de melhoria do processo.
Descrição dos níveis de maturidade
Como visto, o modelo MPS.BR é composto por 7 níveis de
maturidade. Para uma organização adquirir a certificação ní-
vel A de maturidade, ela deve ter implementados todos os 22
processos descritos no modelo. Com a versão 1.2 do modelo,
foi introduzido um novo conceito, de evolução de processos.
Isso significa que ao invés de um nível de maturidade mais
elevado possuir um novo processo de Gerência de Projetos,
por exemplo, existe a evolução desse processo que aparece no
primeiro nível de maturidade. Essa evolução ocorre também
para o processo Gerência de Configuração.
Aqui, serão descritos com um maior nível de detalhes o nível
G de maturidade, pois esse é o ponto de partida para uma or-
ganização que deseja adequar seus processos para o MPS.BR.
Nele aparecem dois processos requeridos: o processo Gerência
de Projeto, que aparece em outros níveis mas com um nível de
capacidade maior e o processo Gerência de Requisitos.
30 Engenharia de Software Magazine - Maturidade em Desenvolvimento de Software
Nível G – Parcialmente Gerenciado
Este nível demonstra a importância do gerenciamento de
projetos para a organização que pretende obter um modelo de
maturidade de processo. A organização sai de um ambiente
“caótico” onde processos improvisados são utilizados e o
sucesso depende de verdadeiros “heróis” fazendo com que
constantemente o projeto ultrapasse o orçamento previsto.
Para uma organização poder se considerar como sendo do
nível G de maturidade, deve implementar os dois processos
requeridos, Gerência de Projetos e de Gerência de Requisitos e
esses processos devem possuir atributos de processo de nível
1.1 e 2.1, explicados anteriormente.
Gerência de Projetos
O propósito desse processo, de acordo com o guia geral, é
o estabelecimento de planos que definem as atividades, re-
cursos e habilidades do projeto, bem como o provimento de
informações sobre o andamento do projeto que permitam a
realização de correções quando houver desvios significativos
no desempenho do projeto. Esse processo tem a característica
de evoluir conforme a organização cresce em nível de matu-
ridade. Novos resultados são esperados para esse processo
a partir do momento que a organização atinge o nível E de
maturidade e novos resultados são incorporados.
Nesse nível, a gerência de projeto passa a ser desempenhada
baseada em um processo definido para a organização como um
todo. Quando a organização evolui para o nível B de maturi-
dade, esse processo de gerenciamento passa a ser gerenciado
quantitativamente refletindo a alta maturidade que se espera
da organização. Alguns resultados esperados evoluem e novos
são incorporados.
Conforme descrito no Guia Geral, os resultados esperados
para o processo de Gerência de Projetos são:
1. O escopo do trabalho para o projeto é definido;
2. As tarefas e os produtos de trabalho do projeto são dimen-
sionados utilizando métodos apropriados;
3. O modelo e as fases do ciclo de vida do projeto são
definidas;
4. (Até o nível F). O esforço e o custo para a execução das ta-
refas e dos produtos de trabalho são estimados com base em
dados históricos ou referências técnicas; (A partir do nível E)
O planejamento e as estimativas das atividades do projeto são
feitos baseados no repositório de estimativas e no conjunto de
ativos de processo organizacional;
5. O orçamento e o cronograma do projeto, incluindo marcos
e/ou pontos de controle, são estabelecidos e mantidos;
6. Os riscos do projeto são identificados e o seu impacto,
probabilidade de ocorrência e prioridade de tratamento são
determinados e documentados;
7. Os recursos humanos para o projeto são planejados conside-
rando o perfil e o conhecimento necessários para executá-lo;
8. As tarefas, os recursos e o ambiente de trabalho necessário
para executar o projeto são planejados;
9. Os dados relevantes do projeto são identificados e planeja-
dos quanto à forma de coleta, armazenamento e distribuição.

Um mecanismo é estabelecido para acessá-los, incluindo, se
pertinente, questões de privacidade e segurança;
10. (Até o nível F). Planos para a execução do projeto são esta-
belecidos e reunidos no Plano do Projeto; (A partir do nível E).
Um plano geral para a execução do projeto é estabelecido com
a integração de planos específicos;
11. A viabilidade de atingir as metas do projeto, considerando
as restrições e os recursos disponíveis, é avaliada. Se necessário,
ajustes são realizados;
12. O Plano do Projeto é revisado com todos os interessados e o
compromisso com ele é obtido;
13. (Até o nível F). O progresso do projeto é monitorado com
relação ao estabelecido no Plano do Projeto e os resultados são
documentados; (A partir do nível E) O projeto é gerenciado
utilizando-se o Plano do Projeto e outros planos que afetam o
projeto. Os resultados são documentados;
14. O envolvimento das partes interessadas no projeto é
gerenciado;
15. Revisões são realizadas em marcos do projeto e conforme
estabelecido no planejamento;
16. 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;
17. Ações para corrigir desvios em relação ao planejado e para
prevenir a repetição dos problemas identificados são estabele-
cidas, implementadas e acompanhadas até a sua conclusão;
18. (Nos níveis E, D e C) Um processo definido para o projeto
é estabelecido de acordo com a estratégia para adaptação do
processo da organização; (Nos níveis A e B). Os sub-processos
mais adequados para compor o processo definido para o projeto
são selecionados com base na estabilidade histórica, em dados de
capacidade e em outros critérios previamente estabelecidos;
19. (A partir do nível E) Produtos de trabalho, medidas e expe-
riências documentadas contribuem para os ativos de processo
organizacional;
20. (A partir do nível B) Os objetivos para a qualidade e para o
desempenho do processo definido para o projeto são estabele-
cidos e mantidos.
Como pode ser observado, nem todos os resultados espera-
dos descritos acima valem para o nível de maturidade G, mas
como esse processo aparece em outros níveis de maturidade
como uma evolução, os resultados esperados foram descritos
todos aqui.
Gerência de Requisitos
O objetivo desse processo é gerenciar os requisitos dos pro-
dutos e componentes e identificar as possíveis inconsistências
entre os requisitos.
Conforme descreve o Guia Geral, o processo Gerência de
Requisitos possui cinco resultados esperados:
1. O entendimento dos requisitos é obtido junto aos fornece-
dores de requisitos;
2. Os requisitos de software são aprovados utilizando critérios
objetivos;
PROC ESS O
3. A rastreabilidade bidirecional entre os requisitos e os pro-
dutos de trabalho é estabelecida e mantida;
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;
5. Mudanças nos requisitos são gerenciadas ao longo do
projeto.
Diferentemente do processo de Gerência do Projeto, que
possui uma característica evolutiva, todos os resultados es-
perados são requisitos obrigatórios para o alcance do nível
de maturidade G. Esse processo é requisito obrigatório para a
progressão aos demais níveis de maturidade.
Nível F – Gerenciado
O nível F, assim como todos os níveis subseqüentes, possui
todos os processos descritos no nível G acrescido de mais qua-
tro processos. Todos os processos acumulados até aqui devem
satisfazer os atributos de processo AP 1.1, AP 2.1, AP 2.2.
Os processos requeridos para esse nível são:
1. Aquisição: gerenciamento da aquisição de produtos e
serviços;
2. Gerência de Configuração: tem como objetivo estabelecer e
manter a integridade de todos os produtos de trabalho de um
processo ou projeto e disponibilizá-los a todos os membros
do projeto;
3. Garantia da Qualidade: assegurar que os produtos de tra-
balho e a execução dos processos estejam em conformidade
com os planos e recursos pré-definidos;
4. Medição: coletar e analisar dados relativos aos produtos
desenvolvidos.
Nível E – Parcialmente Definido
Nesse nível o processo Gerência de Projetos sofre sua primei-
ra evolução, retratando o propósito do nível E de estabelecer
um processo de gerenciamento definido. Todos os processos
passam a ter os atributos de processo AP 3.1 e AP 3.2.
Os processos desse nível são:
1. Avaliação e Melhoria do Processo Organizacional: avaliar
a contribuição dos processos padrão da organização;
2. Definição do Processo Organizacional: estabelecer e man-
ter um conjunto de ativos de processo organizacional e padrões
usáveis e aplicáveis às necessidades de negócio;
3. Gerência de Recursos Humanos: prover os recursos huma-
nos necessários e manter suas competências consistentes com
as necessidades do negócio;
4. Gerência de Reutilização: gerenciar o ciclo de vida dos
ativos reutilizáveis.
Nível D – Largamente Definido
O nível de maturidade D denota um novo estágio de pa-
dronização da organização. Novos processos são integrados
ao modelo exigindo que todos os processos anteriores sejam
definidos como padrão da organização.
Os processos desse nível são:
Edição 37 - Engenharia de Software Magazine 31
1. Desenvolvimento de Requisitos: estabelecer os requisitos
do produto e do cliente;
2. Integração do Produto: compor os componentes do
produto;
3. Projeto e Construção do Produto: projetar e desenvolver a
solução para atender os requisitos do cliente;
4. Validação: assegurar que o produto atende o propósito para
o qual foi especificado;
5. Verificação: confirmar que cada serviço ou produto atende
os requisitos especificados.
Nível C – Definido
Nesse nível o processo Desenvolvimento para Reutilização
sofre evolução para refletir os atributos de processo requeridos
para esse nível.
Os processos desse nível são:
1. Desenvolvimento para Reutilização: identificar opor-
tunidades para reutilização e estabelecer um programa de
reutilização para desenvolver ativos a partir de engenharia
de domínios da aplicação;
2. Gerência de Riscos: identificar, analisar, tratar, monitorar
e reduzir continuamente os riscos.
Nível B – Gerenciado Quantitativamente
Para este nível de maturidade não existe nenhum processo
novo. Mais uma vez o conceito de evolução de processo atri-
bui novos resultados esperados para o processo Gerência de
Projetos. No nível B a gerência de projetos deve ser efetuada
utilizando-se dados estatísticos coletados a partir da análise
dos processos padrões da organização. Essa análise quanti-
tativa deve ser feita para outros processos relevantes para a
empresa. Nesse nível, dois atributos de processo são reque-
ridos para os processos em que a análise quantitativa é mais
relevante, AP 4.1 e AP 4.2.
Nível A – Em Otimização
Para uma organização ser considerada como sendo do nível
mais alto do modelo MPS.BR, nível A, ela deve ter todos os
processos implementados e padronizados na organização, bem
como prover análise quantitativa para determinados processos
e que esses dados constantemente coletados possam servir para
32 Engenharia de Software Magazine - Maturidade em Desenvolvimento de Software
a contínua otimização dos processos de software. Com isso,
um novo processo aparece nesse nível, a Análise de Causas
de Problemas e Resolução, cujo principal objetivo é identificar
causas de defeitos e de outros problemas e tomar ações para
prevenir suas ocorrências no futuro.
Conclusão
A qualidade de software, especialmente em projetos grandes,
está diretamente ligada à maneira como o trabalho de desen-
volvimento é realizado durante todas as fases do ciclo de vida.
Para grandes empresas de desenvolvimento, como fábricas de
software, a existência de um processo bem definido dentro da
organização é essencial para a manutenção da qualidade do
produto desenvolvido e para o reaproveitamento de compo-
nentes utilizados em projetos anteriores. Além disso, a grande
quantidade de concorrentes no mercado vem forçando essas
empresas a se “certificarem” em modelos de maturidade. Para
pequenas e médias empresas, adotar um modelo de maturi-
dade como o CMMI pode ser muito caro. Por isso, a adoção de
um modelo mais adequado à sua realidade, como o MPS.BR,
pode trazer benefícios de curto prazo com custos inferiores
aos modelos internacionais.
Referências
International Organization for Standardization and International Electrotechnical Comission.
ISO/IEC 15504 - http://www.iso.org/iso/iso_catalogue/. Acesso em 05/04/2011
PRESSMAN, R. S. Engenharia de Software, 6ª edição, Macgraw Hill, 2006.
SOFTEX, Guia Geral v1.2 – http://www.softex.br/mpsbr - Acesso em: 30/03/2011
SOFTEX, Guia de Avaliação – http://www.softex.br/mpsbr - Acesso em: 05/04/2011
SOFTEX, Guia de Implementação – http://www.softex.br/mpsbr - Acesso em: 05/04/2011
Dê seu feedback sobre esta edição! Feedback
eu
s
Dê
A Engenharia de Software Magazine tem que ser feita ao seu gosto.
sobre e
Para isso, precisamos saber o que você, leitor, acha da revista! ta s
edição
Dê seu voto sobre este artigo, através do link:
www.devmedia.com.br/esmag/feedback