TrabalhoEntregue_931640

Prévia do material em texto

* Graduação em Sistemas da Informação na Universidade Salvador (UNIFACS), pós-graduação em 
Engenharia de Software na Estácio de Sá. E-mail: alexandhre10@gmail.com. 
QUALIDADE DE SOFTWARE EM PROJETOS SCRUM 
 
Alexandre dos Santos Silva* 
 
RESUMO 
 
Este artigo tem como objetivo demonstrar e caracterizar a qualidade de software 
inserida no contexto de projetos que utilizam a metodologia ágil Scrum. Por muito 
tempo os produtos de software eram desenvolvidos sob a ótica dos modelos 
tradicionais com padrões e técnicas rígidas que não se adaptavam a mudanças, 
cada vez mais tinham custos mais altos e que não geram valor ao cliente. Dessa 
forma, as metodologias ágeis ganharam espaço nos últimos anos com práticas mais 
eficazes de controle e garantia da qualidade, adaptação a mudanças e o enfoque no 
cliente. A metodologia ágil SCRUM é a mais utilizada e a mais difundida atualmente 
por conta da facilidade no controle dos processos, auxilia o planejamento dos 
gestores, reduz os riscos e as falhas e pode se adaptar a qualquer projeto. A 
qualidade de software tem se tornado cada vez mais essencial nos projetos 
atualmente, diversas práticas são empenhadas e desenvolvidas durante o 
desenvolvimento que podem aumentar a confiabilidade do projeto, reduzir custos, 
aumentar a produtividade e atender as especificidades do cliente. 
 
Palavras-chave: Metodologia ágeis, SCRUM, Qualidade de Software, Projetos. 
 
 
INTRODUÇÃO 
Ao longo do desenvolvimento da humanidade a tecnologia foi e vêm sendo 
importante no dia a dia das pessoas, provendo bens e serviços que tornam a vida 
das mesmas mais rápida e prática. Hoje em dia praticamente tudo se converge em 
tecnologia ou necessita da mesma para facilitar a vida do ser humano. Desse modo, 
para que essas soluções possam de fato serem efetivas e gerar valor ao usuário, 
padrões, métricas de desenvolvimento e qualidade de software precisam ser 
seguidos. 
Para aplicar esses padrões de qualidade precisamos estabelecer a forma 
como iremos aplicar, em quanto tempo e evoluir gradativamente o produto final que 
chegará para solucionar os problemas do usuário. Todas essas ferramentas e 
métodos se configuram num esforço temporário com um objetivo final que se 
denomina projeto. Segundo o PMBOK (2017): “Um projeto é um esforço temporário 
empreendido para criar um produto, serviço ou resultado exclusivo. Os projetos e as 
2 
 
 
 
operações diferem, principalmente, no fato de que os projetos são temporários e 
exclusivos, enquanto as operações são contínuas e repetitivas.” 
Todo projeto é composto por um conjunto de ações e abordagens que vão 
permear como a equipe irá agir nesse período, como os processos serão elaborados 
e como as diferentes áreas serão geridas. A escolha da metodologia de software do 
projeto é uma das fases mais importantes e críticas, pois o sucesso do mesmo está 
diretamente ligado à metodologia de software. Cada método tem seus pontos fortes 
e pontos fracos cabe aos pontos focais do projeto conhecerem diversas 
metodologias para que diante dessas opções a mais eficiente seja escolhida. 
Dentro desse contexto, nos últimos anos com a alta demanda de produtos e 
serviços alguns padrões de software precisaram ser revistos e outros criados para 
atender essa evolução. As metodologias tradicionais por muito tempo foram as que 
eram mais usadas nas empresas pelo fato de trazerem regras e padrões de não 
flexíveis. Como as entregas precisaram ser mais rápidas e com muito mais 
qualidade de forma a gerar valor para o usuário. Visando atender a essa aceleração 
do consumo por produtos e serviços de software nos últimos anos que as 
metodologias ágeis ganharam força e vem se tornando cada vez mais comuns nas 
empresas. 
A metodologia SCRUM vem ganhando espaço desde os anos 80 como uma 
nova forma de desenvolvimento e gerenciamento de projetos. Por se basear e 
aplicar em padrões incrementais e iterativos o SCRUM consegue extrair o melhor de 
cada membro da equipe de forma a usar diferentes técnicas que são usadas da 
maneira correta para que todos contribuam para o sucesso final do produto. 
Diante desse cenário precisamos garantir a qualidade do software que será 
entregue ao cliente utilizando algumas dessas técnicas disponibilizadas pelo Scrum. 
São padrões, métricas e certificações que juntam provém testes, verificações e 
análises que visam controlar o desenvolvimento do software, das atividades de 
gestão e de todos eventos que deverão acontecer para que o software seja criado 
incrementalmente. 
Este artigo demonstrará a evolução da metodologia Scrum e sua correlação 
com a qualidade de software. Descrevendo os testes, métricas e conceitos 
relacionados a qualidade e como eles estão inseridos dentro da metodologia. 
 
3 
 
 
 
METODOLOGIAS ÁGEIS 
O desenvolvimento de software cada vez mais vem se tornando um desafio 
devido a diversos problemas encontrados pelas empresas para especificar e 
gerenciar os requisitos. Segundo Ambler (2002) modelagem Ágil (AM) é uma 
metodologia baseada na prática para modelagem efetiva de sistemas baseados em 
software, é também uma coleção de práticas, guiadas por princípios e valores que 
podem ser aplicados por profissionais de software no dia a dia. 
 Podemos dizer que as metodologias ágeis são mais adaptáveis em relação 
aos modelos tradicionais e provêm uma maior segurança em caso de alterações 
constantes dos requisitos do projeto. Para um modelo ser ágil segundo Ambler 
(2002), ele precisa atender as seguintes características: 
 Tabela 1 - Características para um modelo ser ágil 
1. Ele atende seu propósito. 
2. Ele é inteligível. 
3. Ele é suficientemente preciso. 
4. Ele é suficientemente consistente. 
5. Ele é suficientemente detalhado. 
6. Ele provê um valor positivo. 
7. Ele é tão simples quanto possível. 
Fonte: Ambler (2002) 
 
Ainda segundo Abrahamsson (2003), as metodologias ágeis constituem uma 
nova classe de metodologias de desenvolvimento de software criada para atender à 
crescente pressão do mercado por processos mais ágeis e leves, com ciclos de 
desenvolvimento cada vez mais curtos. Segundo Fowler (2005), os métodos ágeis 
são conjuntos de técnicas e padrões de desenvolvimento de software, desenvolvidos 
ao longo dos últimos anos, com a finalidade de tornar o desenvolvimento dos 
softwares mais acelerado, dar a possibilidade de controlar o custo e melhorar cada 
vez mais a qualidade do produto que será entregue. 
4 
 
 
 
Fowler (2005) explica ainda que as metodologias ágeis são mais adaptativas 
ao invés de predeterminantes, ou seja, dentro da metodologia ágil já está previsto 
mudanças constantes durante o projeto e todos os membros da equipe precisam 
estar aptos. As metodologias tradicionais enfrentam diversos problemas pois 
possuem processos mais fixos e não suscetíveis a alterações e isso implica em 
atrasos na entrega do projeto e aumento excessivo do custo. 
Segundo Schwaber e Sutherland (2011), um dos principais requisitos para se 
definir se um método pode ser classificado como ágil é a construção incremental no 
lugar de entregar um produto total no final do projeto, as equipes precisam ter a 
autonomia de se organizar, colaborar entre si, praticar o feedback com clareza, se 
adaptar facilmente a novos cenários, realizar testes constantes e manter sempre 
pequenos ciclos de desenvolvimento. 
Segundo Bessa e Arthaud (2018, p.181), o termo “Metodologias Ágeis” 
tornou-se popular em 2001 quando houve uma reunião de especialistas em 
processos de software representando diversos métodos ágeis que se reuniram para 
abordar novas formas de aumentar o desempenho de seus projetos. Perceberam 
que algumas práticas e princípios que seguiam eram comuns e geram valor ao 
projeto. A partir daí se juntaram para estabelecer o Manifesto ágil com suas 
filosofias, valores e princípios. 
A tabela a seguir traz os 12 princípios que compõem o manifesto ágil: 
Tabela2 - 12 princípios que compõem o manifesto ágil 
1 Entregar o software de forma eficaz e satisfatória para o cliente de modo a 
gerar valor ao seu negócio. 
2 Uma das vantagens dos métodos ágeis é que mudanças nos requisitos não 
irão impactar no projeto. 
3 Outra vantagem é poder entregar o software em menos tempo. 
4 Todos os membros da equipe devem estar sincronizados em prol do projeto. 
5 Dar a todos os membros da equipe ambiente estruturado e motivado para 
exercer seu trabalho. 
6 Conversas one to one são mais eficazes para transmitir informações dentro 
da equipe. 
7 Entregas de software funcionando são métricas de progresso do projeto. 
8 Todos os envolvidos no projeto devem manter um ritmo constante de 
5 
 
 
 
desenvolvimento. 
9 Cuidados relacionados à qualidade garantem a primazia do projeto. 
10 Simplicidade é uma das características principais dos métodos ágeis. 
11 Equipes auto-organizáveis promovem melhor qualidade ao projeto. 
12 De tempos em tempos a equipe se auto avalia para planejar possíveis ajustes 
de modo a tornar o desenvolvimento mais eficaz. 
 Fonte: J. Highsmith et al. (2001) 
 
Segundo Jeon et al (2011), as metodologias ágeis têm como principal foco 
oferecer satisfação ao cliente, capacidade de adaptação a mudanças e agregar 
produtos de maior qualidade e em um tempo muito menor do que metodologias 
tradicionais. 
Sfetsos e Stamelos (2010) descrevem que metodologias ágeis dispõe de 
padrões e práticas que conferem a qualidade do projeto e proporcionam elocução 
contínua no software. Dentro desse contexto, a metodologia SCRUM é a mais 
difundida na comunidade de desenvolvimento de software. Segundo Schwaber e 
Beedle (2011), o SCRUM é uma metodologia ágil, mas seu foco está no 
desenvolvimento iterativo e incremental em contraponto às práticas da engenharia 
de software tradicionais. 
De acordo com levantamento do IGTI (2017), o Scrum é o framework ágil 
mais famoso entre as empresas brasileiras, presente em 74% delas por sua 
eficiência na otimização de processos e sua versatilidade: ele se adapta facilmente a 
diversas áreas e não fica restrito apenas ao desenvolvimento de tecnologias. 
 
Figura 1 
Desenvolvimento ágil em números, no Brasil e no Mundo IGTI 
Fonte: IGTI (2017) 
6 
 
 
 
SCRUM 
Segundo Bessa e Arthaud (2018) o SCRUM foi criado na década de 1990 por 
Jeff Sutherland, com base em conceitos tradicionais da engenharia de produção 
como Lean e a Teoria das Restrições Explorada por Takeuchi e Nonaka (1986) no 
artigo “The new product development game”, no qual descrevem as vantagens da 
utilização de times pequenos, multidisciplinares e auto gerenciáveis no 
desenvolvimento de produtos. 
 Segundo Vasconcelos e Mello (2012) o nome Scrum surgiu da comparação 
entre desenvolvedores e jogadores de Rugby. Scrum é a denominação da rápida 
reunião que ocorre quando os jogadores de Rugby vão iniciar um lance. Segundo 
Schwaber e Beedle (2002), o SCRUM tem por finalidade definir um processo de 
desenvolvimento de projetos em que as pessoas sejam o centro de atenção e 
enfoque. 
Desse modo podemos perceber que o Scrum é um conjunto de práticas e 
padrões que visam facilitar e guiar o desenvolvimento do software de forma que as 
pessoas e que os processos possam ter uma capacidade facilitada de mudança 
caso necessário. 
Ainda segundo Schwaber e Sutherland (2011, p.3), Scrum pode ser definido 
como um framework onde as pessoas têm a facilidade de resolver problemas 
complexos, com o objetivo final de entregar um produto com o maior valor agregado 
ao cliente de forma incremental e iterativa. 
Segundo Sulman (2016, p.16) o SCRUM representa um conjunto de valores, 
princípios e práticas que fornecem uma base para se integrar a outras técnicas e 
facilitar o desenvolvimento de software. Os principais atores da metodologia Scrum 
são: 
Scrum Master: Segundo Bessa e Arthaud (2018, p.183), este seria o 
responsável por garantir que todas as regras do Scrum sejam aplicadas e que o 
projeto progrida de forma satisfatória e ágil. É responsável por tratar e eliminar os 
impedimentos do projeto. 
Product Owner: Segundo Vasconcelos e Mello (2012, p.561) é o responsável 
por definir quais são os requisitos e qual é o grau de importância e prioridade de 
cada um deles. Necessita dominar muito bem as regras de negócios do cliente e 
ajuda ao time tirando dúvidas quanto às funcionalidades. 
7 
 
 
 
Scrum Team: Time de desenvolvimento normalmente. 
Os principais elementos do SCRUM são: 
Product backlog: Funcionalidades que foram coletadas através de reuniões 
com os envolvidos do projeto e o cliente e são definidas por ordem de prioridade. 
Sprint: Ciclo de um conjunto de atividades com um tempo pré-determinado, 
Segundo Abrahamsson et al. (2002), a sprint normalmente dura de uma a quatro 
semanas, mas não há uma regra para isto; as equipes que decidem a duração a ser 
adotada para o projeto; 
Sprint backlog: Funcionalidades que foram mapeadas para que o time de 
desenvolvimento implemente naquele Sprint. 
Reunião diária ou Daily: Primeira reunião do dia logo pela manhã, feita em 
pé, para que os membros em que basicamente três perguntas são respondidas por 
cada membro sobre suas responsabilidades Rising e Janoff (2000): O que foi feito 
ontem? O que será feito hoje? Há algum obstáculo à realização das atividades? 
Sprint Planning meeting ou Reunião de Planejamento: 
Reunião de Planejamento da Sprint do que será entregue ao final da sprint, 
juntamente com o PO (Product Owner), normalmente o cliente, são decididas as 
funcionalidades que serão implementadas e colocadas no Backlog da Sprint. 
Sprint Review meeting ou Reunião de Revisão: Sempre ao final de cada 
Sprint o time deve apresentar o produto desenvolvido a partir do backlog da sprint. 
Sprint Retrospective meeting ou Reunião de Retrospectiva: Após a 
reunião de Review é feita a reunião de retrospectiva onde os membros do time 
podem indicar pontos positivos e negativos que viveram durante a Sprint, lições 
aprendidas e sugestões de melhorias. 
 
 
 
8 
 
 
 
Figura 2 
GERENCIAMENTO ÁGIL DE PROJETOS COM SCRUM + PMBOK 
Fonte: Fábio Cruz e Project Builder 
 
QUALIDADE DE SOFTWARE: VISÃO GERAL 
O atual panorama em que vivemos se caracteriza por muitas mudanças e 
novas definições. Dessa forma, os projetos precisam estar preparados para se 
reorganizar o mais rápido possível em face dessas mudanças. As metodologias, 
frameworks e o gerenciamento do projeto têm grande parte nesse controle de novos 
requisitos e alteração dos atuais. 
Um dos grandes desafios dos atuais gestores é controlar os fatores externos 
e internos ligados aos projetos. Os fatores externos são mais difíceis de controlar e 
prever e dessa forma a empresa deve se encontrar preparada e organizada para 
quaisquer imprevistos. Uma boa gestão do projeto e uma metodologia de software 
bem escolhida proporciona ao gestor um domínio significativo do processo. 
Uma empresa para ser competitiva deve conhecer todos os fatos e dados de 
seu contexto empresarial. A informação deve envolver todo o contexto do ambiente, 
as ameaças e oportunidades no que se denomina “informação competitiva” Lopes 
(2007). De posse da informação competitiva a empresa consegue se antecipar ao 
mercado, oferecer melhores produtos e serviços e um crescimento estratégico. 
9 
 
 
 
Segundo Silva (2020a) cada vez mais se torna necessário uma análise da 
qualidade de produtos ou serviços, partindo do pressuposto que os usuários cada 
vez mais são exigentes e querem alta disponibilidade. Um produto que tenha alta 
performance, tenha suas funcionalidades intuitivas e gere valor ao seu negócio se 
torna cada vez mais importante para o usuário. 
Segundo Sommerville (2011, p.454), as dificuldades relacionadas à qualidade 
de software foram detectadas em meados de 1960 com o desenvolvimento de 
grandes sistemas. Os softwares eram lentose de baixa confiabilidade, com elevado 
custo de manutenção e baixo reuso, dessa forma, novos padrões tiveram que ser 
adotados para controlar a qualidade e no decorrer do século XX novos softwares de 
testes também foram desenvolvidos com a finalidade agregar mais valor ao projeto. 
Conforme a quinta edição da pesquisa de Qualidade e Produtividade no Setor 
de Software Brasileiro – 2001 MCT/SEPIN (2002), existem quatro tipos de produto 
de software: 
Tabela 3 - Quatro tipos de produto de software 
Uso Geral Softwares que são usados por um 
grande público e desenvolvidos 
conforme requisitos específicos. 
Uso Específico Softwares para clientes específicos, 
baseados em especificações mais 
inflexíveis. 
Para Internet Implementados com a finalidade de 
criar sites. 
Embutidos Softwares que vem juntamente com o 
hardware escolhido. 
 Fonte: MCT/SEPIN (2002) 
 
 
De acordo com Lopes (2007), a qualidade deixou de ser um diferencial 
competitivo e se tornou obrigação entre as empresas que querem estar sempre à 
frente do mercado. Ainda segundo Lopes (2007) alguns fatores que devem ser 
levados em conta são: 
● Quem define se suas aspirações foram atendidas ou não é o cliente; 
10 
 
 
 
● Diante das opções oferecidas ao cliente, ele decide se fica numa 
empresa ou vai para concorrência, nesse caso, o cliente vai para onde enxerga que 
está sendo mais bem atendido; e 
● Todo o processo de criação, validação, manutenção etc. do produto 
entram como fatores que influenciam se as expectativas do cliente foram atendidas 
ou não e criam uma identidade do mesmo com o produto. 
 Figura 3 
 A Árvore e o Balanço no Desenvolvimento de Software 
 Fonte: Blog do Takemura (2012) 
 
QUALIDADE DE SOFTWARE: DEFINIÇÃO 
Qualidade de projeto refere-se às características que os projetistas 
especificam para um produto. A qualidade dos materiais, as tolerâncias e as 
especificações de desempenho, todos são fatores que contribuem para a qualidade 
de um projeto. Quanto mais materiais de alta qualidade forem usados, tolerâncias 
mais rígidas e níveis de desempenho maiores forem especificados, a qualidade de 
projeto de um produto aumentará se o produto for fabricado de acordo com essas 
especificações (PRESSMAN 2011, p.359). 
11 
 
 
 
Ou seja, Pressman (2011) sugere que quanto maiores forem as métricas 
aplicadas ao projeto, ao produto, quanto mais testes forem feitos, quanto mais 
ferramentas eficazes forem empregadas o produto será de maior qualidade e 
confiabilidade. Ainda conforme Pressman (2011, p.359) a qualidade do projeto está 
intimamente ligada à conformidade em relação aos requisitos e a qualidade de 
conformidade está ligada às metas de desempenhos traçadas pela equipe que são 
atendidas no decorrer do desenvolvimento. 
Segundo Sommerville (2011, p.457), qualidade de software não é somente 
verificar se o produto foi implementado corretamente, mas se o mesmo atende aos 
requisitos não funcionais do sistema. Sommerville (2011, p.457) propõe ainda que 
esses atributos podem estar relacionados a confiança, usabilidade, eficiência e 
manutenibilidade, mas que é impossível de um projeto ser eficiente em todos esses 
atributos. 
Pressman (2011, p.360) enfatiza ainda que existem pontos importantes na 
qualidade de software: 
1. A gestão da qualidade efetiva pressupõe que uma infraestrutura eficaz 
possibilita um software de qualidade, aspectos administrativos e o bom 
gerenciamento de mudanças criam mecanismos maiores de controle e 
equilíbrio. 
2. O produto útil tem que atender as expectativas do usuário, ter 
conformidade em relação a requisitos não funcionais implícitos e 
oferecer confiabilidade. 
3. Um produto de software de qualidade deve agregar valor para a 
empresa e o cliente. Para a empresa significa ter um menor gasto com 
manutenção e correção do software e para o cliente significa atender 
às suas demandas. 
Segundo Pressman (2011, p.361), sugere uma proposta de categorização 
dos fatores que acometem a qualidade de software: 
 
Tabela 4 - Fatores que acometem a qualidade de software 
Correção O quanto um programa satisfaz a sua especificação e atende 
aos objetivos da missão do cliente. 
Confiabilidade O quanto se pode esperar que um programa realize a função 
pretendida com a precisão exigida. 
12 
 
 
 
Eficiência A quantidade de recursos computacionais e código exigidos por 
um programa para desempenhar sua função. 
Integridade O quanto o acesso ao software ou dados por pessoas não 
autorizadas pode ser controlado. 
Usabilidade Esforço necessário para aprender, operar, preparar a entrada 
de dados e interpretar a saída de um programa. 
Facilidade de 
manutenção 
Esforço necessário para localizar e corrigir um erro em um 
programa. 
Flexibilidade Esforço necessário para modificar um programa em operação 
Testabilidade Esforço necessário para testar um programa de modo a garantir 
que ele desempenhe a função destinada 
Portabilidade Esforço necessário para transferir o programa de um ambiente 
de hardware e/ou software para outro 
Reusabilidade O quanto um programa [ou partes de um programa] pode ser 
reutilizado em outras aplicações — relacionado com o 
empacotamento e o escopo das funções que o programa 
executa. 
Fonte: Pressman (2011, p.362) 
 
Figura 4 
Fatores de qualidade de software 
Fonte: Pressman (2011, p.362) 
 
QUALIDADE DE SOFTWARE APLICADA EM PROJETOS SCRUM 
Em projetos de software atuais que utilizam a metodologia ágil SCRUM 
entende-se que todos os membros da equipe têm um papel importante na garantia 
da qualidade do software. A boa execução dos processos do SCRUM garante a 
grande probabilidade de que o produto final seja de qualidade, Porém, muitas vezes 
13 
 
 
 
não existe uma definição clara de papéis e responsabilidades para cada pessoa no 
time a respeito da qualidade do produto, que atividades e artefatos e ferramentas 
estão sob sua responsabilidade e como compartilham os mesmos Negrello (2013). 
Ainda segundo Negrello (2013), problemas como realizar a qualidade de 
software, como e quando realizar são perguntas complexas que precisam de uma 
integração de dois componentes importantes dentro de um projeto: processos e 
ferramentas. 
Segundo Pressman (2011, p.370), a qualidade de software é uma ação 
constante de métodos de engenharia de software com boas práticas de gestão de 
projetos. Dessa forma, existem quatro grandes atividades que as equipes utilizam 
para controlar a qualidade de um projeto: 
Tabela 5 - Quatro grandes atividades para controlar a qualidade 
Métodos de engenharia de software Primeiro passo ao criar um projeto é 
entender o problema a ser resolvido e 
aplicar os métodos corretos da 
engenharia de software para aumentar 
a probabilidade de entregar um produto 
de qualidade. 
Técnicas de gerenciamento de software As mudanças constantes nos requisitos 
precisam estar bem explícitas e 
técnicas específicas de gerenciamento 
de projetos quando bem empregadas 
aumentam a qualidade do produto. 
Controle de qualidade Antes do início de cada projeto algumas 
métricas de qualidade são 
estabelecidas e constantemente 
precisam ser revisadas para garantir 
que o produto atenda a essas métricas. 
Garantia da qualidade Alguns relatórios e métodos podem ser 
utilizados de modo a avaliar de forma 
efetiva todos os passos e processos 
que garantem a qualidade. 
. 
Fonte: Pressman (2011, p.370) 
 
As atividades de garantia da qualidade de software são focadas na prevenção 
de defeitos e problemas, que podem surgir nos produtos de trabalho. Definição de 
padrões, metodologias, técnicas e ferramentas de apoio ao desenvolvimento fazem 
parte deste contexto Vasconcelos (2006). Ou seja, os padrões e métodos de 
14 
 
 
 
engenharia de software e da metodologia SCRUM precisam ser utilizados de forma 
eficiente pelos atores do projeto de modo aumentar a probabilidade de o produto 
atender asmétricas especificadas. 
Segundo Sommerville (2011, p.455), essas métricas e atributos de qualidade 
devem estar contidos num plano de qualidade que estabelece quais qualidades 
serão avaliadas durante o processo de desenvolvimento. Essas definições servem 
de base para que tanto a equipe de desenvolvimento quanto os engenheiros de 
software não se percam em quais atributos de qualidade realmente importam. 
 
Figura 5 
Gerenciamento de qualidade e desenvolvimento de software 
Fonte: Sommerville (2011, p.455) 
 
Sommerville (2011, p.456) sugere que Humprey (1989) propôs uma estrutura 
básica para um plano de qualidade: 
1. Introdução ao produto: Descrição do produto, mercado em que atua 
e as aspirações de qualidade; 
2. Planos de produto: Datas relacionadas a release do produto e quando 
ele será disponibilizado para o usuário; 
3. Descrições de processo: Processos de desenvolvimento geram 
padrões que devem ser seguidos no desenvolvimento do produto. 
4. Metas de Qualidade: Metas e planos de qualidade que descrevem os 
atributos críticos de qualidade do produto. 
5. Riscos e gerenciamento de riscos: Descreve os riscos e as ações 
que devem ser tomadas diante de cada um deles. 
 
15 
 
 
 
NORMAS E PADRÕES DE QUALIDADE DE SOFTWARE 
Normas e padrões de qualidade vêm sendo adotadas com o intuito de 
aumentar a qualidade do software e garantir que o mesmo atenda as especificidades 
elucidadas durante as fases de planejamento do projeto. 
Dessa forma, segundo Balthazar (2007) a Norma NBR 13596, elenca 
algumas características relacionadas à qualidade e propõe um modelo de processo 
de avaliação de produto de software. Ainda segundo Balthazar (2007), a norma NBR 
13596 vem sendo substituída pela NBR ISO/IEC 9126. 
Segundo Cordeiro e Frreitas (2008. p,4), a norma de qualidade ISO/IEC 9126 
é composta por duas partes: 
 Tabela 6 - Partes do modelo de qualidade do produto de software da Norma NBR ISO/IEC 9126 
Qualidade Interna e Externa Especifica seis características para a 
qualidade de software e são divididas 
em sub características: funcionalidade, 
confiabilidade, usabilidade, eficiência, 
manutenibilidade e portabilidade 
Qualidade de Uso Especifica características que tem 
relação a visão do usuário em relação 
ao software: 
Fonte: Cordeiro e Frreitas (2008. p,4) 
 
Aline e André (2008. p,4), descrevem ainda que existem outras normas como 
a ISO/IEC 15504 que segundo que caracteriza a avaliação do processo de 
desenvolvimento. A ISO/IEC 14598 que designa requisitos básicos para medição e 
avaliação de produtos de software. A ISO/IEC 12207 fornece uma organização de 
passos para os processos que são aplicados durante a aquisição de produtos de 
software. 
As normas descritas elas podem se referenciar ao produto ou ao processo, 
normas voltadas ao produto vão fornecer padrões básicos de qualidade que os 
produtos devem seguir. Já as normas voltadas para o processo vão descrever 
padrões básicos que o ciclo de vida dos processos deve seguir para garantir a 
qualidade. 
Existem outros padrões que são seguidos como modelos para garantir a 
qualidade durante o desenvolvimento como o CMMI (Capability Maturity Model 
16 
 
 
 
Integration), é um modelo que reúne boas práticas para atividades de engenharia de 
software que cobre desde a elucidação dos requisitos até a entrega e manutenção. 
CMMI tem a finalidade de guiar o que a organização precisa fazer para 
melhorar seus processos e não definir os processos para a organização (CMMI, 
2018). Kasse (2008) descreve que para que uma empresa atinja um nível 
satisfatório de maturidade no processo de desenvolvimento do software, seu foco 
total tem que se concentrar em qualidade. 
O CMMI tem como foco principal atuar no desenvolvimento de melhoria 
contínua nos processos para que possíveis erros possam ser mapeados, 
solucionados da forma correta e que todas as etapas de desenvolvimento possam 
ser executadas de maneira correta. 
O CMMI mapeia 5 níveis de maturidade que são eles: 
1. Nível 1 Inicial: O processo é abstrato e baseado nas experiências dos 
envolvidos; 
2. Nível 2 Repetível: O projeto é controlado de forma simples; 
3. Nível 3 Definido: Os processos seguem um padrão de organização; 
4. Nível 4 Gerenciado: Métricas são estabelecidas para obter total 
controle do projeto; 
5. Nível 5 Otimização: Melhoria contínua como base para evolução dos 
processos. 
 
 
Figura 6 
Níveis de Maturidade do CMMI 
Fonte: Zhang Lina e Shao Dan (2011) 
 
17 
 
 
 
No cenário brasileiro nós temos o MPS.BR como um modelo de melhoria de 
processo de software com objetivo de auxiliar as empresas a caminharem para a 
melhoria contínua dos processos e disseminar os padrões da engenharia de 
software durante o desenvolvimento dele. 
O MPS.BR é um modelo de melhoria de processos de software que foi criado 
em 2003, de acordo com a realidade de empresas brasileiras, com o objetivo de 
propor um modelo de processo para alcançar a Melhoria do Processo de Software 
Brasileiro Koscianki e Soares (2007). 
Uma das metas do Programa MPS.BR é definir e aprimorar um modelo de 
melhoria e avaliação de processo de software e serviços, visando preferencialmente 
às micro, pequenas e médias empresas (mPME) (SOFTEX, 2012a). 
 
CONCLUSÃO 
Este trabalho teve por objetivo contextualizar e analisar como a qualidade de 
software hoje em dia é um aspecto fundamental no desenvolvimento de projetos e 
como sua interação com o SCRUM promove produtos que conferem mais valor ao 
cliente, produtos mais fáceis de manter e evoluir. 
O estudo foi realizado com a finalidade de compreender e explicitar que as 
metodologias ágeis junto com suas práticas e características são essenciais no 
desenvolvimento de software, tem o enfoque nas pessoas e que conjunto de todos 
esses fatores atestam o controle e a garantia da qualidade. Foi feita uma pesquisa 
exploratória a fim de colher mais informações a respeito dos métodos ágeis e sua 
evolução sistemática. 
Diante das pesquisas dos autores citados percebe-se que os métodos ágeis 
possuem e principalmente o SCRUM possuem práticas que contribuem para a 
qualidade de software. E por mais que não sejam métodos novos vem permeando o 
desenvolvimento dos produtos e evoluindo durante os anos. 
As atividades de qualidade desempenhadas pela equipe conferem ao gerente 
de projeto condições suficientes para controlar o produto que está sendo 
desenvolvido, controlar as entregas incrementais ao cliente e avaliar se eles 
atendem aos níveis de requisitos funcionais e não funcionais elucidados 
anteriormente. 
18 
 
 
 
Desse modo, as análises feitas nos estudos citados no trabalho descrevem 
que a qualidade de software provê práticas e padrões que auxiliam as equipes a 
evoluir exponencialmente e entregar produtos que conferem mais valor ao cliente. A 
comunicação se torna um fator essencial para esse progresso visto que as 
informações trafegam de forma mais eficaz e as mudanças não têm um grande 
impacto diante do projeto. Podemos concluir que a qualidade de software é um dos 
pilares fundamentais do SCRUM e vem permeando o sucesso progressivo das 
entregas de software nos últimos anos. 
 
REFERÊNCIAS 
 
AMBLER, W, Scott. Modelagem Ágil (AM): Um apanhado geral, Versão online. 
Disponível em: http://www.agilemodeling.com/shared/AMPanfleto.pdf. Acesso em: 
20 abr. 2021. 
ABRAHAMSSON, P. et al. New directions on agile methods: a comparative 
analysis. In: International Conference On Software Engineering, 25., 2003, Portland. 
Anais eletrônicos […]. Portland: ICSE, p. 244-254, 2003. 
FOWLER, M. Continuous integration. 2006. Disponível em: 
http://martinfowler.com/articles/continuousIntegration.html. Acesso em: 20 abr. 2021. 
SCHWABER, Ken.; SUTHERLAND, Jeff. Scrum Guide. 2011. Disponível em: < 
http://www.scrum.org/Scrum-Guides >. Acesso em: 20 abr. 2021. 
BESSA, Thiago.; ARTHAUD, Daniel. Metodologias ágeis para o desenvolvimentode softwares. 2018. Revista Ciência e Sustentabilidade, ISSN 2447-4606. 
JEON, S. et al. Quality Attribute driven Agile Development. 2011. 
SFETSOS, P.; STAMELOS, I. Empirical Studies on Quality in Agile Practices: A 
Systematic Literature Review. Seventh International Conference on the Quality 
of Information and Communications Technology, 2010. 
SCHWABER, Ken; BEEDLE, Mike. Agile Software Development with Scrum. [S.l]: 
Prentice Hall, 2002. 
IGTI. Desenvolvimento ágil em números, no Brasil e no Mundo. 2017. Disponível 
em: https://www.igti.com.br/blog/desenvolvimento-agil-em-numeros/. Acesso em: 20 
abr. 2021. 
TAKEUCHI, H; NONAKA, I.; The new product development game. Harvard 
Business Review, Cambridge, n. 1, jan./feb., 1986. 
19 
 
 
 
VASCONCELOS, Bernardo.; MELLO, Carlos Henrique. Aplicação do método ágil 
scrum no desenvolvimento de produtos de software em uma pequena empresa 
de base tecnológica. 2012. Gest. Prod.,São Carlos, v. 19, n. 3, p. 557-573, 2012. 
SULMAN, Daniel. UM ESTUDO COMPARATIVO DE METODOLOGIAS ÁGEIS NO 
DESENVOLVIMENTO DE APLICATIVOS MÓVEIS. 2016. Disponível em: 
https://www.cin.ufpe.br/~tg/2016-2/dsae.pdf. Acesso em: 22 abr. 2021. 
ABRAHAMSSON, Pekka, SALO Outi. Agile Software Development Methods – 
Review and Analysis. Espoo 2002, VTT Publications 478 107. 
RISING, L.; JANOFF, N. S. The Scrum Software Development Process for Small 
Teams. 2000. 
LOPES, Kátia. QUALIDADE DE SOFTWARE. 2007. Disponível em: 
http://www.facom.ufu.br/~bacala/QS/apostila_QS_Katia.pdf. Acesso em: 22 abr. 
2021. 
SILVA, S. (2002a) Avaliação da Qualidade de Software Através da Usabilidade. 
Congresso Fenasoft 2002, São Paulo. 
SOMMERVILLE, Ian. Engenharia de Software 9. ed. Tradução Kalinka Oliveira, 
Ivan Bosnic. São Paulo: Persson, 2011. 
MCT/SEPIN. Qualidade e Produtividade no Setor de Software Brasileiro: 2001. 
BrasíliaDF, Brasil, 2002. 
PRESSMAN, Roger S. Engenharia de Software: Uma abordagem profissional 7. 
ed. Tradução Ariovaldo Griesi, Mario Moro Fecchio. Porto Alegre, RS: McGraw-Hill 
Education, 2011. 
NEGRELLO, Ana. Métodos Ágeis e Qualidade: Como Conciliar? 2013. Disponível 
em:http://www.ceavi.udesc.br/arquivos/id_submenu/787/gabriel_linardi___qualidade
_de_software_na_metodologia_agil.pdf. Acesso em: 23 abr. 2021. 
VASCONCELOS, Alexandre Marcos Lins de., [et. al]. Engenharia de Software para 
Software Livre 1. Lavras: UFLA, 2006. 
HUMPHREY, W. Managing Software Process, Mass.:Addison Wesley, 1989. 
BALTHAZAR, Glauber da Rocha. Visão Geral da Qualidade de Software. 2007. 
Disponível em: http://re.granbery.edu.br/artigos/MjUw.pdf. Acesso em: 23 abr. 2021. 
CORDEIRO, Aline G, FRREITAS, André L. P. O cenário atual da qualidade de 
software. 2007. Disponível em: https://www.researchgate.net/profile/Andre-Luis-
Freitas/publication/267623024_O_cenario_atual_da_qualidade_de_software/links/54
20 
 
 
 
5395830cf2cf51647c1b44/O-cenario-atual-da-qualidade-de-software.pdf Acesso em: 
23 abr. 2021. 
Kasse, T. (2008). Practical insight into CMMI. Artech House computing library. 
CMMI. About CMMI® Institute. 2018. Disponível em: https://cmmiinstitute.com/. 
Acesso em: 23 abr. 2021 
KOSCIANKI, Andre; SOARES, Michel S. Qualidade de Software: Aprenda as 
metodologias e técnicas mais modernas para o desenvolvimento de software. 
2ª Edição. São Paulo: Novatec Editora, 2007. 
SOFTEX, 2012a, MPS.BR - Melhoria de Processo do Software Brasileiro, Guia 
Geral de Software, Associação para Promoção da Excelência do Software 
Brasileiro – SOFTEX 
PMI - PROJECT MANAGEMENT INSTITUTE. Guia PMBOK®: Um Guia para o 
Conjunto de Conhecimentos em Gerenciamento de Projetos, sexta edição, 
Pennsylvania: PMI, 2017. 
COCKBURN, Alistair; HIGHSMITH, Jim. 2001. Disponível em: 
http://alistair.cockburn.us. Acesso em: 20 abr. 2021 
TAKEMURA. A Árvore e o Balanço no Desenvolvimento de Software, 2012. 
Disponível em:http://blogdotakemura.blogspot.com/2012/05/arvore-e-o-balanco-no-
desenvolvimento.html. Acesso em: 20 abr. 2021