QUALIDADE DE

SOFTWARE

Jeanine dos
Santos Barreto
Melhorias de processos
de software
Objetivos de aprendizagem
Ao final deste texto, você deve apresentar os seguintes aprendizados:

 Definir as melhorias de processo de software.

 Descrever os processos de melhoria de software.
 Aplicar os modelos MPS na melhoria de processos de software.

Introdução
Há muitos anos, as estatísticas vêm demonstrando que grande parte
dos projetos de software fracassam durante o seu ciclo de vida, ou são
finalizados sem que atendam aos seus objetivos. Por esse motivo, algumas
organizações e instituições nacionais e internacionais se uniram para
elaborar modelos de processo de melhoria de software que incentivem
as empresas a organizarem e sistematizarem suas práticas de desenvol-
vimento de software, visando a cumprir prazos e orçamentos e entregar
softwares de qualidade, que atendam aos requisitos dos usuários.
Neste capítulo, você vai estudar as melhorias de processos de software,
verificando quais são os processos de melhoria de software e como é a
aplicação dos modelos MPS nesse contexto.

As melhorias de processos de software

Diferentemente de outras áreas de estudo, nas quais são exigidos níveis de
excelência na entrega de projetos e na satisfação de clientes, como a enge-
nharia e a medicina, na ciência da computação, a área de desenvolvimento de
software vem há muito tempo apresentando índices baixos de satisfação dos
seus clientes, conforme Santos e Oliveira (2017).
O Standish Group International Inc. é uma empresa de consultoria inter-
nacional e independente, que foi fundada em 1985 e atua na área de pesquisa
2 Melhorias de processos de software

de Tecnologia da Informação (TI). Os profissionais de desenvolvimento de

software conhecem essa empresa pelas suas pesquisas e seus relatórios es-
tatísticos sobre a implementação de projetos de software e de sistemas de
informação, nos setores público e privado. Seus relatórios demonstram o índice
de fracasso e de sucesso nos projetos de software, as falhas e as possíveis
melhorias para os projetos de tecnologia de informação. Os números não são
muito animadores, apesar de já apresentarem melhoras se comparados aos
anos anteriores.

Para saber mais sobre o Standish Group, acesse o link a seguir.

https://goo.gl/0QZ8X7

Como exemplo, é demonstrado no Quadro 1 o Relatório do Caos do Stan-

dish Group, de 2015, que mostra que 19% dos projetos de software que eram
iniciados fracassavam antes da entrega, 52% eram entregues com falhas,
atrasos ou estouro de orçamento, e apenas 29% eram finalizados com sucesso,
atendendo às necessidades dos clientes.

Quadro 1. Estatísticas sobre a entrega de projetos de software

2011 2012 2013 2014 2015

Projetos 29% 27% 31% 28% 29%

bem-sucedidos

Projetos de 49% 56% 50% 55% 52%

sucesso parcial

Projetos 22% 17% 19% 17% 19%

fracassados

Fonte: Adaptado de Wojewoda e Hastie (2015).

Esses números se tornam assustadores na medida em que fazemos com-

parativos, por exemplo, com a entrega de projetos bem-sucedidos de uma
 Melhorias de processos de software 3

construtora, uma montadora de carros ou uma instituição bancária. Seria

possível fazer com que os clientes, compradores de apartamentos de um con-
domínio, se sentissem satisfeitos e seguros, sabendo que a cada 100 imóveis
entregues, menos de 30% não cairiam? Ou, ainda, haveria uma forma de manter
os clientes satisfeitos sabendo que menos de 30% dos carros fabricados por
uma montadora seriam seguros e confiáveis? Ou, então, seria possível fazer
clientes investirem em um banco que apresentasse 30% de garantia de que
seu dinheiro estaria seguro?
Em outro estudo, a Universidade Harvard, em uma pesquisa realizada em
2016 sobre a entrega de projetos de TI, concluiu que 70% são entregues fora do
prazo, sendo que a maioria deles são projetos de desenvolvimento de software.
Provavelmente é porque essas estatísticas se repetiram ou se modificaram
muito pouco ao longo dos anos que a área de TI seja considerada, muitas
vezes, como pouco confiável e estressante para os profissionais. Os clientes
e usuários, por outro lado, parecem já estar acostumados com a ideia de que
os projetos de desenvolvimento de software serão entregues em data posterior
à prevista e de que sairão mais caros.
Nesse contexto, é possível elencar alguns motivos que fazem com que os
projetos de software fracassem ou sejam entregues sem atender às necessidades
dos usuários, conforme apontados por Santos e Oliveira (2017). Vejamos abaixo.
Escopo do projeto mal definido ou incompleto: o escopo serve para
identificar tudo o que o software deverá fazer quando estiver pronto e todas as
necessidades dos usuários com relação ao software. Além disso, os analistas
já definem basicamente como vão desenvolver o projeto, e isso tudo deve ser
definido logo no início. Quando o escopo é mal definido, ou é definido de
maneira incompleta, certamente o projeto vai fracassar, pois não vai entregar
o que o usuário deseja.
Um escopo mal feito pode ser consequência de vários problemas, como o
fato de o analista não conseguir entender com clareza e objetividade o que o
usuário precisa, ou ainda quando o usuário não consegue transmitir ao analista
tudo aquilo que deseja e precisa fazer por meio do software. Além disso, é
possível que o analista que levantou os requisitos com o usuário não consiga
transmitir aos desenvolvedores tudo aquilo que lhe foi dito.
O problema de um escopo mal definido fica ainda pior se os usuários
não forem envolvidos em nenhum momento durante o desenvolvimento do
software e se as falhas de comunicação dos requisitos só forem percebidas no
final do projeto, durante a entrega. Isso fará com que o projeto retorne para a
etapa de desenvolvimento, para que as correções sejam feitas. Em vista disso,
depois da definição do escopo, é importante chamar os usuários para que
4 Melhorias de processos de software

analisem, verifiquem e façam a validação de tudo aquilo que foi identificado

como requisitos pelos analistas. É importante também que os usuários sejam
envolvidos de alguma forma durante o desenvolvimento do software, para
verificar se o escopo inicial está sendo seguido.
Identificação de riscos malfeita: a identificação, ou análise de riscos,
consiste em identificar, de maneira antecipada, todos os problemas que podem
acontecer no decorrer do processo de desenvolvimento de um software. Dessa
maneira, é possível indicar todos os fatores que podem acarretar em compro-
metimento de prazos ou de orçamento ao longo do projeto, possibilitando que
a equipe se antecipe, evitando ou minimizando os prejuízos.
Pessoas que não sabem trabalhar em equipe: é preciso que todos os
integrantes do projeto de desenvolvimento do software saibam trabalhar em
equipe, pois, do contrário, a comunicação entre os integrantes e o andamento
global do projeto serão prejudicados. Quanto mais unidos os trabalhadores
estiverem, maior esforço haverá em prol de um único objetivo, que é a en-
trega do projeto com a qualidade que o cliente espera, dentro do prazo e do
orçamento previsto.
Liderança ineficiente no projeto: o líder ou gestor do projeto deve acom-
panhar o andamento de todas as atividades bem de perto, para garantir que
elas sejam feitas com qualidade e dentro do prazo estipulado.
Testes inexistentes ou malfeitos: a realização de testes aumenta signifi-
cativamente a chance de entregar um software com sucesso, pois durante os
testes é possível identificar falhas, instabilidades e problemas de performance.
É preciso que os testes sejam feitos de maneira detalhada e cuidadosa, ve-
rificando se tudo o que foi pedido pelo usuário está sendo entregue, e como
está o desempenho, a segurança e as condições de usabilidade do software.
Quando os problemas são identificados durante a realização dos testes, é
possível que as falhas sejam corrigidas antes que o prazo ou o orçamento seja
comprometido. Do contrário, quando os problemas são identificados somente
depois que o software é entregue, o usuário fica insatisfeito e o trabalho para
corrigir os erros é bem maior, além de o prazo e o orçamento previstos serem
descumpridos.
Ao analisar as principais causas de insucesso nos projetos de software, é
possível perceber que, se houver uma boa gestão ao longo do projeto e uma
equipe comprometida com o objetivo do projeto, a entrega bem-sucedida é
praticamente certa.
Mas não é apenas disso que depende o sucesso na entrega de um software.
É importante lembrar que a qualidade de um software está intimamente ligada
ao processo que é utilizado para desenvolvê-lo. É preciso definir um processo
 Melhorias de processos de software 5

que seja capaz de unir as competências disponíveis na equipe de projeto ao

que o usuário espera do produto final. Foi por isso que surgiram modelos de
maturidade, que servem para ajudar as empresas produtoras de software a bus-
carem uma melhoria constante nos seus processos produtivos. O aprendizado
desses modelos é demorado e a sua implementação exige esforço e trabalho
de todos os envolvidos, mas os resultados obtidos geralmente são animadores.

Os processos de melhoria de software

A crescente utilização de computadores e dispositivos móveis, para toda e
qualquer atividade do dia a dia, fez com que a demanda por softwares evo-
luísse de maneira muito rápida nos últimos anos. As empresas identificaram,
na utilização dos softwares, uma maneira de competir no mercado de forma
estratégica. Por isso, os produtores de software precisam se preocupar, cada
vez mais, em entregar softwares de qualidade para os clientes.
Um processo de desenvolvimento de software pode ser entendido como o
conjunto de todas as atividades e papéis que são envolvidos na idealização, na
fabricação, nos testes e na implantação de um software, conforme Koscianski
e Soares (2006). Manter processos de qualidade para a produção de software
não vai garantir que ele seja entregue com qualidade, atendendo aos requisi-
tos do usuário, dentro do prazo e do orçamento previsto, mas vai aumentar
consideravelmente a probabilidade de isso acontecer. É provável que o fato
de as empresas produtoras de software não adotarem uma padronização nos
métodos, ferramentas e procedimentos de desenvolvimento de software gere
quantidades expressivas de projetos não concluídos, por cancelamento, ou
projetos concluídos que não satisfazem aos seus clientes.
É importante que o processo de desenvolvimento de software seja feito de
maneira organizada, sistemática e disciplinada, para que as chances de obter
sucesso na entrega dos produtos para o cliente sejam maiores. Essa forma de
trabalhar pode trazer outros ganhos, como o aumento na competitividade, a
capacidade de assumir riscos maiores e demandas mais complexas, o aumento
na qualidade dos produtos entregues, o aumento na produtividade, a diminuição
de custos de produção e a diminuição ou a eliminação do retrabalho.
Para assegurar que os softwares sejam produzidos com qualidade e com
níveis de maturidade excelentes, algumas organizações criaram modelos, que
estabelecem diretrizes para as práticas e os processos de desenvolvimento de
software, a fim de trazer uma melhoria contínua e a redução de problemas
na entrega.
6 Melhorias de processos de software

A seguir, serão detalhados dois dos principais modelos de processo de

melhoria de software, com base em Koscianski e Soares (2006).

Modelo Seis Sigma

O Seis Sigma é um modelo que visa a implementar a qualidade por meio
da melhoria contínua dos processos de produção de bens ou serviços, da
otimização das operações, da diminuição ou eliminação de defeitos e falhas,
envolvendo todos os aspectos que possam trazer confiança e credibilidade
junto aos clientes da empresa.
A expressão sigma remete à capacidade que um processo possui de ser
executado sem falhas, ou de reduzir a diferença que existe entre o resultado
esperado pelos clientes e aquele efetivamente entregue, sempre buscando
a perfeição. A implantação do Seis Sigma proporciona uma compreensão
detalhada de todos os processos e procedimentos utilizados na fabricação dos
produtos, possibilitando ajustes e melhorias antes não identificados.
Geralmente é impossível que uma empresa alcance a eliminação total de
defeitos e erros nos processos de produção, mas é importante saber que a apli-
cação do Seis Sigma aumenta a sistematização e a padronização dos processos,
proporcionando um aumento na qualidade e, até mesmo, na lucratividade, em
decorrência da nova forma de trabalho. A utilização do Seis Sigma altera os
paradigmas e traz uma nova política de trabalho, em que se busca a melhoria
contínua e progressiva dos processos.
Apesar de ter sido criado pela Motorola, no ano de 1986, o modelo Seis
Sigma ficou conhecido mundialmente por meio da empresa General Electric
(GE), no final da década de 1990, que investiu algo em torno de 450 milhões
de dólares na implementação do Seis Sigma e obteve ganhos em torno de
1,5 bilhão de dólares. Essa lucratividade veio em consequência da confiança
que os clientes passaram a depositar na empresa depois da consolidação do
método nos processos.
Inicialmente, o Seis Sigma foi estruturado pela Motorola com quatro fases,
que formavam o método MAIC (measure, analyse, improve, control), que, em
português, pode ser traduzido pelas fases medir, analisar, melhorar e controlar.
Depois disso, a GE aperfeiçoou esse modelo, definindo um Seis Sigma em
cinco fases, que formavam o método DMAIC (define, measure, analyse,
improve, control), traduzidos pelas fases definir, medir, analisar, melhorar e
controlar, conforme abaixo:
 Melhorias de processos de software 7

 Definir: essa é a fase em que se identificam os problemas e todas as

situações que podem melhorar ao longo dos processos, tomando-se
uma visão do cliente; ou seja, são identificados todos os pontos que
podem ser melhorados para aumentar a qualidade do produto oferecido
e a satisfação dos clientes.
 Medir: essa é a fase em que os processos são medidos e mapeados,
registrando seus resultados e a estimativa da capacidade de curto e
longo prazo de cada processo, para identificar até que ponto podem
sofrer mudanças.
 Analisar: nessa fase, cada processo deve ser verificado para que se
possa identificar quando, onde e quais os motivos que levam os defeitos
a ocorrerem.
 Melhorar: nessa fase, cada produto é analisado para que sejam identifi-
cadas as características que devem ser melhoradas para que os objetivos
com a sua fabricação sejam atingidos, sejam eles de desempenho ou
financeiros.
 Controlar: essa fase foi idealizada para que os processos novos ou
modificados sejam documentados e monitorados durante a sua execução,
visando a identificar maneiras de garantir e perpetuar os ganhos obtidos.

Com relação aos processos de desenvolvimento de software, o Seis Sigma

estabelece que, quanto maior for o controle sobre cada processo, menor será a
sua capacidade de resultar em falhas e problemas. Além disso, quanto mais o
desenvolvedor se preocupar com o resultado de cada processo, mais o resultado
do seu trabalho tende a se aproximar da necessidade do usuário.

Modelo CMMI
O CMMI, ou Capability Maturity Model Integration, que, em português,
significa algo como integração do modelo de maturidade da capacidade, foi
criado como uma forma de garantir a maturidade na capacidade de desenvol-
vimento de software, a fim de obter melhor qualidade nos produtos entregues,
servindo de guia e estabelecendo diretrizes para a melhoria dos processos.
O CMMI apresenta duas formas de representação:

1. Representação contínua: formada por níveis de capacidade, que per-

mitem selecionar a área ou o processo que deverão ser melhorados na
empresa. Cada processo tem um nível de capacidade que vai de 0 a 5
8 Melhorias de processos de software

e que são cumulativos, ou seja, cada nível atingido exige que os níveis
inferiores tenham sido atingidos. Os níveis são:
■ 0 = incompleto: o processo não existe ou existe parcialmente.
■ 1 = executado: o processo satisfaz às metas que foram especificadas
pela área onde ele é executado.
■ 2 = gerenciado: o processo é executado e planejado de acordo com
cada projeto.
■ 3 = definido: o processo está documentado, padronizado e integrado
em um processo de software que é padrão na empresa.
■ 4 = gerenciado: todo o processo é controlado de maneira quantitativa,
por meio de métricas para medir seu desempenho.
■ 5 = em otimização: as métricas do nível 4 auxiliam na melhoria
contínua do processo.
2. Representação por estágios: formada por níveis de maturidade, que
permitem indicar o estágio de evolução dos processos. São cinco níveis
de maturidade, em que cada um serve de base para o próximo:
■ 1 = inicial: poucos processos de desenvolvimento definidos, e o
sucesso depende do esforço de cada integrante da equipe.
■ 2 = repetível: políticas de desenvolvimento e gerenciamento de
software definidas e seguidas por todos.
■ 3 = definido: o processo de desenvolvimento de software está do-
cumentado, padronizado e integrado em um processo padrão para
o funcionamento da empresa.
■ 4 = gerenciado: existem métricas para medir o desempenho dos
processos de software e dos produtos de software entregues.
■ 5 = otimizado: existe a melhoria contínua dos processos, baseada
nas métricas do nível 4.

Quando uma empresa possui certificação CMMI, isso quer dizer que ela
é capaz de entregar produtos de software com qualidade para seus clientes,
além de conseguir cumprir prazos acordados, dentro do orçamento previsto,
atendendo às necessidades do cliente para cada projeto.

Aplicação dos modelos MPS na melhoria de

processos de software
O MPS.BR, ou Melhoria do Processo de Software Brasileiro, é um modelo
criado pela Softex, que é a Associação para a Promoção da Excelência do
 Melhorias de processos de software 9

Software Brasileiro, em parceria com o Ministério da Ciência, Tecnologia,

Inovações e Comunicações (MCTIC), no ano de 2003. Seu objetivo principal
é melhorar a capacidade de desenvolvimento de software, serviços e práticas
de gestão de recursos humanos nas empresas de TI, principalmente as micro,
pequenas e médias, pois geralmente são as que apresentam mais dificuldades
para estruturar a melhoria de seus processos, além de possuírem poucos
recursos financeiros.

Para saber mais sobre o MPS.BR, acesse o link a seguir.

https://goo.gl/brFG3T

O modelo MPS.BR tem o propósito de oferecer um modelo de processos

de software com um preço acessível, que possibilite às empresas de menor
porte se organizarem nas suas atividades de desenvolvimento de software.
Segundo Santos e Oliveira (2017), o MPS.BR é formado por três guias:

1. Guia geral: apresenta a descrição geral do modelo MPS.BR, detalhando

o seu modelo de referência.
2. Guia de aquisição: traz recomendações para a compra de software e
de serviços.
3. Guia de avaliação: traz a descrição detalhada de todos os elementos
e processos de avaliação de software que são baseados no modelo
MPS.BR.

O modelo MPS.BR apresenta sete níveis de maturidade, dois a mais do que

o modelo CMMI. Essa é uma vantagem, pois ele possibilita que a implantação
do modelo seja mais lenta e gradual, o que é perfeito para as empresas menores.
Os níveis de maturidade são muito importantes, porque representam qual o
nível de domínio e conhecimento das empresas em relação aos seus processos
de desenvolvimento de software e, ainda, como esse conhecimento é aplicado
para que os resultados obtidos sejam efetivos.
A estrutura do modelo MPS.BR é formada por três componentes distintos,
apresentados na Figura 1, que são, conforme apontam Santos e Oliveira (2017):
10 Melhorias de processos de software

1. Modelo de referência: estabelece todos os requisitos que devem ser

cumpridos pelas empresas que querem se adequar e estar em confor-
midade com o modelo MPS.BR. Estão definidos níveis de maturidade,
que são uma combinação entre os processos e a capacidade de cada
um deles, a fim de que a empresa consiga visualizar sua possibilidade
futura de desempenho, de acordo com o nível em que se encontra. Em
outras palavras, encontrar-se em um nível faz com que a empresa se
organize e se planeje para o futuro, melhorando áreas e processos que
não estão apresentando bons resultados. Os níveis de maturidade desse
modelo são cumulativos, ou seja, se uma empresa se encontra em um
determinado nível, significa que ela já atingiu os requisitos do nível
anterior. São eles:
■ A = em otimização: esse é o melhor nível em que uma empresa
pode se encontrar, que representa a total maturidade da empresa.
Nesse nível existem processos para analisar possibilidades de ino-
vação nos processos e na própria organização, demonstrando uma
busca por melhoria contínua e constante evolução, para aumentar a
competitividade no mercado.
■ B = gerenciado quantitativamente: esse nível envolve uma gerência
quantitativa do projeto de desenvolvimento de software, possibili-
tando calcular o desempenho do processo organizacional. Existe
um monitoramento e uma determinação dos projetos em relação
aos objetivos reais de qualidade e desempenho, o que garante que o
produto entregue terá a qualidade esperada.
■ C = definido: nesse nível já existem processos mais avançados,
como o gerenciamento de riscos e a análise de decisão e resolução
de problemas. Os riscos são identificados, avaliados e tratados para
evitar atrasos no cronograma, e as decisões são analisadas e melho-
radas, se necessário.
■ D = largamente definido: esse é um nível de maturidade intermedi-
ário, que traz um bom gerenciamento de requisitos, com utilização
de técnicas para medir e garantir a qualidade do software entregue,
fazendo sua validação e verificação. A empresa define os requisitos
bem no início do projeto e se preocupa em cumprir todos eles à risca,
validando cada um deles ao longo do projeto.
■ E = parcialmente definido: nesse nível os processos são bem or-
ganizados, e existe uma política de treinamento na empresa. Os
processos são bem gerenciados, os clientes são envolvidos durante
o desenvolvimento e os princípios de trabalho são bem definidos.
 Melhorias de processos de software 11

A empresa está organizada para fabricar softwares e enxerga isso

claramente.
■ F = gerenciado: aqui já existe uma maturidade maior, e uma garantia
de qualidade do produto entregue, em conformidade com o que foi
planejado e com os recursos definidos no início do projeto.
■ G = parcialmente gerenciado: esse é o pior nível em que uma em-
presa pode se encontrar. Aqui existe gerência de projeto e de requi-
sitos, mas bem superficial, o que quer dizer que a empresa consegue
identificar e monitorar as atividades do projeto e, ainda, adequar-se
às modificações de requisitos que acontecem ao longo dos projetos.
2. Método de avaliação: estabelece os processos a serem seguidos pelos
avaliadores das empresas.
3. Modelo de negócio: estabelece as regras que devem ser seguidas para
a implementação do MPS.BR nas empresas.

Figura 1. Estrutura do modelo MPS.BR.

Fonte: Henrique (2014, documento on-line).

Os níveis de maturidade são muito importantes para que a empresa entenda

onde ela está, onde pretende chegar e o que é preciso fazer para que esse ob-
jetivo seja atingido. Muitas empresas entendem que não é preciso alcançar o
nível A de maturidade para que seus produtos sejam entregues com qualidade.
Então, entender onde está é essencial para que a empresa possa definir qual
é o caminho a seguir e qual é a meta a ser atingida.
12 Melhorias de processos de software

HENRIQUE. Melhoria do processo de software brasileiro. 2014. Disponível em: <https://

www.devmedia.com.br/melhoria-do-processo-de-software-brasileiro/29915>. Acesso
em: 25 jan. 2019.
KOSCIANSKI, A.; SOARES, M. S. Qualidade de software. São Paulo: Novatec, 2006.
SANTOS, L. D. V.; OLIVEIRA, C. V. S. Introdução à garantia de qualidade de software. Timburi,
SP: Cia do Ebook, 2017.
WOJEWODA, S.; HASTIE, S. Stwithandish group 2015 chaos report: q&a with Jennifer
Lynch. 2015. Disponível em: <https://www.infoq.com/articles/standish-chaos-2015>.
Acesso em: 25 jan. 2019.
Conteúdo: