Qualidade de software

Prévia do material em texto

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 
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.
Fonte: Adaptado de Wojewoda e Hastie (2015).
2011 2012 2013 2014 2015
Projetos 
bem-sucedidos
29% 27% 31% 28% 29%
Projetos de 
sucesso parcial
49% 56% 50% 55% 52%
Projetos 
fracassados
22% 17% 19% 17% 19%
Quadro 1. Estatísticas sobre a entrega de projetos de software
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 software2
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 
3Melhorias 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 software4
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 identifi caram, 
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.
5Melhorias 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 confi anç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 software6
  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, 
signifi ca 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 fi m 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 
7Melhorias 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 existeparcialmente.
 ■ 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 software8
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 difi culdades 
para estruturar a melhoria de seus processos, além de possuírem poucos 
recursos fi nanceiros.
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):
9Melhorias 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 software10
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.
11Melhorias 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.
Melhorias de processos de software12
Conteúdo: