impressao (1)

Prévia do material em texto

1 
 
 
 
 
 
 
 
 
 
 
 
QUALIDADE DE SOFTWARE 
AULA 6 
 
 
 
 
 
 
 
 
 
 
 
Prof.a Maristela Regina Weinfurter Teixeira 
 
 
2 
 
CONVERSA INICIAL 
Olá, seja bem-vindo. Assista ao sexto vídeo da professora Maristela 
Regina Weinfurter Teixeira, que irá apresentar e contextualizar esta disciplina, 
bem como os assuntos que serão estudados nesta aula. 
CONTEXTUALIZANDO 
Ao percorrermos os caminhos da gestão e garantia da qualidade no 
desenvolvimento de software, percebemos que há uma concentração bastante 
grande na área de testes, sejam eles inspeções, revisões, validações ou 
verificações. Vimos que há divergências de opiniões, pois quando olhamos 
profundamente para a área de qualidade total, percebemos que não 
conseguimos escapar dos inúmeros documentos, auditorias, controles e 
estatísticas, porém, encontramos um manifesto em prol de metodologias ágeis 
para garantir menos papel e mais produtividade. Parece-nos antagônico então 
pensarmos em qualidade versus agilidade! Observando essas variadas formas 
de se pensar produtividade e qualidade em processos de desenvolvimento de 
software, vamos focar em melhoria contínua, tentando agregar conceitos mais 
conservadores (documentais e grande número de recursos humanos e 
financeiros), bem como para equipes mais ágeis (com poucos recursos e 
focadas num bom custo com um bom prazo de entrega)! 
Assim iniciamos falando sobre o que seria melhoria contínua. E esse 
termo não surge na área de informática, assim como o termo qualidade não é 
proveniente desta. A melhoria contínua tem origem na Terra do Sol Nascente 
(Japão), e o termo original para isso é KAIZEN. Kaizen agrega um significado de 
“melhoria contínua nos âmbitos do trabalho, família, pessoal e social.” (ADAMI, 
2016). O grande propósito do Kaizen consiste no aprimoramento diário e 
constante de nossas atividades (profissionais ou pessoais) para aumento da 
produtividade, poupando tempo, recursos, esforços, bem como humanizando as 
relações. 
Para a administração, a expressão refere-se a uma filosofia de vida e não 
simplesmente a um conjunto de ferramentas. Para Costa Junior (2012), Kaizen 
 
3 
 
é “um processo de aprimoramento contínuo, que consiste na busca de melhorias 
pela inovação dos processos produtivos, dos métodos, dos produtos, das regras 
e dos procedimentos.” Ele procura eliminar problemas por meio da identificação 
de ideias de melhoria, com a participação de todos na resolução dos mesmos. 
Não teremos apenas indicadores de performance, 
mas mediremos a taxa de melhoramentos, aplicando ações de 
melhoria e implementações em um determinado período de tempo 
(COSTA JUNIOR, 2012). 
Ao aplicarmos a ideia do Kaizen, desejamos alguns dos seguintes 
resultados (COSTA JUNIOR, 2012): 
 Melhorias nos processos produtivos; 
 Adaptação ou adequação dos postos de trabalho, das 
máquinas e dos equipamentos; 
 Adequação dos métodos de trabalho; 
 Redução de desperdícios em processos; 
 Capacitação e envolvimento dos colaboradores; 
 Aumento de produtividade. 
 
É interessante notarmos que o Kaizen possui alguns princípios básicos: 
 
1. Abandono de ideias fixas e rejeição do estado atual das coisas; 
2. Não explicar o que não se pode fazer, mas refletir sobre como fazer; 
3. Acatar e utilizar de imediato boas ideias para alcançarmos as melhorias; 
4. Não conseguiremos a perfeição, mas 60% já é um ótimo resultado; 
5. Correção dos erros de imediato e no local; 
6. Dificuldades devem ser encaradas como desafios; 
7. Procurar causas reais para solução perfeita; 
8. Experimentar e validar; e 
9. Melhorias são infinitas. 
 
Nosso esforço nessa aula será buscar e mostrar ideias e alternativas para 
conseguirmos exercitar a filosofia do Kaizen, demonstrando que é possível 
 
4 
 
aplicarmos engenharia de software e qualidade de software, mesmo que com o 
mínimo de documentação, observando que nosso alvo será sempre superar as 
expectativas de nossos usuários! 
 
Pesquise 
Percebemos que melhoria contínua tem origem no Japão. Várias 
ferramentas, técnicas, filosofias que foram incorporadas à Teoria Geral da 
Administração possuem origem em estudos e experimentos japoneses. Busque 
dentro da Engenharia de Software, ou mais precisamente dentro da área de 
qualidade de software visualizar outras técnicas, ferramentas ou métodos que 
possam ter origem nessas filosofias de produtividade. Vamos refletir e analisar 
o quanto podemos melhorar em nossa produtividade e em serviços e processos 
com mais qualidade. 
 
 
TEMA 1: CMMI 
Dentro das estratégias de melhoria contínua, a ideia da CMMI é 
interessante, pois transforma todo o processo de desenvolvimento de software 
em um ambiente controlado e com alta excelência nas definições e execuções 
dos processos. 
Originalmente, CMM (Capability Maturity Model) foi desenvolvida pelo 
Instituto de Engenharia de Software na década de 1990 como uma estrutura da 
SPI (Melhoria do Processo de Software). Evoluiu então para CMMI como um 
metamodelo de processo abrangente e qualificado para colaborar com a 
maturidade do processo de desenvolvimento de software. Esse metamodelo 
representa o processo de duas maneiras diferentes: modelo contínuo e 
encenado. Descreve um processo em duas dimensões (Figura 1). 
 
 
 
5 
 
Figura 1: Dimensões do metamodelo CMMI 
 
Fonte: Pressman, 2011. 
 
Ele possui uma série de níveis, que são devidamente avaliados por 
profissionais especializados pelo Instituto de Engenharia de Software 
(CMM07 apud PRESSMAN, 2011): 
Nível 0: Incompleto – a área de processo (por exemplo, 
gerenciamento de requisitos) não funciona ou não atinge todas as 
metas e objetivos definidos pela CMMI para a capacidade nível 1 para 
a área de processo. 
Nível 1: Executado – todas as metas específicas da área de processo 
(definida pela CMMI foram satisfeitas. Estão sendo executadas as 
tarefas necessárias par produzir os artefatos definidos. 
Nível 2: Controlada – todos os critérios do nível de capacidade 1 
foram satisfeitos. Além disso, todo o trabalho associado com a área de 
processo está de acordo com uma política definida em termos de 
organização; todas as pessoas que estão fazendo o trabalho têm 
acesso a recursos adequados para executar o trabalho; os 
interessados são envolvidos ativamente na área de processo conforme 
necessário; todas as tarefas e produtos são monitorados, controlados 
e revisados; e são avaliados quanto à conformidade com a descrição 
de processo. (CMM07). 
 
6 
 
Nível 3: Definido – todos os critérios do nível de capacidade 2 foram 
satisfeitos. Além disso, o processo é adaptado com base no conjunto 
de processos padronizados da organização de acordo com as regras 
de adaptação da organização, e dos produtos acabados, medidas e 
outras informações de melhoria de processo para agregar valores ao 
processo organizacional (CMM07). 
Nível 4: Controlado quantitativamente – todos os critérios do nível 
de capacidade 3 foram satisfeitos. Além disso, a área de processo é 
controlada e melhorada usando medição e avalição quantitativa. São 
estabelecidos objetivos quantitativos para qualidade e desempenho de 
processo e utilizados como critérios no controle do processo. (CMM07). 
Nível 5: Otimizado – todos os critérios do nível de capacidade 4 foram 
satisfeitos. Além disso, a área de processo é adaptada e otimizada 
usando meios quantitativos (estatísticos) para atender à mudança de 
necessidades do cliente e melhorar continuamente a eficiência da área 
de processo em consideração. 
A CMMI define cada área de processoem termos de metas específicas e 
as práticas específicas para que as metas sejam atingidas. Práticas específicas 
são refinamentos de uma meta, que são transformadas em uma série de 
atividades relacionadas ao processo. (PRESSMAN, 2011). 
A Figura 2 ilustra as áreas de processo, necessárias para cada nível de 
maturidade da CMMI. 
 
 
 
 
 
 
 
 
7 
 
Figura 2: Áreas de Processo da CMMI 
 
 
Com a implantação da CMMI em uma empresa que desenvolva software, 
certamente atingiremos muitos dos níveis desejados em termos de qualidade 
dos processos e dos produtos finais. E isso não sairá barato. Envolverá muito 
recurso humano e de capital, porém, dependendo do tamanha da empresa, o 
retorno disso virá a médio e longo prazo, com a conquista de maiores e melhores 
clientes que prezam pela excelência na prestação de serviços e produção de 
software. 
Leitura obrigatória 
SOMMERVILLE, 2011 
 
 
 
8 
 
TEMA 2: KANBAN 
O método Kanban, aplicado ao desenvolvimento de software, percorre a 
ideia de não sobrecarregar a equipe de criação do software. Contém princípios 
básicos que consideram que a equipe deve iniciar uma nova tarefa quando é 
capaz de realizá-la. Deve aceitar mudanças incrementais e evolutivas 
estimuladas pelo método Kanban, respeitando os atuais processos, papéis 
e responsabilidades. Mas o que é Kanban e no que ele poderá nos auxiliar na 
garantia da qualidade de processo e de software? 
“Kanban é uma palavra japonesa que significa ‘cartão ou cartaz’, que pode ser 
utilizada como cartão ou carta Kanban e tem a finalidade de representar um 
sinal.” (COSTA JUNIOR, 2012). 
Ainda segundo Costa Junior (2012): 
Kanban é uma ferramenta de informação que auxilia a fabricação 
correta de produtos, nas quantidades corretas e no tempo correto, em 
todos os estágios da produção. Por isso, constitui-se em um sistema 
físico de controle da movimentação de materiais ou de contêiner, que 
se faz como o uso de cartões. 
Uma das grandes vantagens da utilização de Kanban fica por conta de 
suas características de fácil gerenciamento das ordens de produção, fácil 
compreensão por toda a organização e baixo custo de implementação. Além 
claro, da rapidez nas tomadas de decisões e autonomia nas decisões pelo 
sequenciamento das ordens de produção. 
Como cita Costa Junior (2012), basicamente a ferramenta é composta por 
1. Fila de espera (sequenciador da produção); 
2. Quadro Kanban (gerenciamento das ordens); 
3. Padronização dos contêineres (cartões); 
Parece simples? Sim, e é bastante simples, por isso a ideia da junção de 
Kanban a processos de desenvolvimento de software ágeis. 
 
9 
 
O Kanban, na área de TI, torna-se digital, mas o conceito de quadro e 
cartões continuam os mesmos. Algumas empresas preferem até adotar a forma 
física, pois a visualização em painéis, tabuleiros, lousas e paredes cria uma 
sensação de movimento e evolução do processo. Um dos pontos importantes do 
Kanban aplicado para garantia da qualidade encontra-se na busca pela 
maturidade da produção. Isso é fundamental para a equipe que busca aprender 
a construir código de alta qualidade e equilíbrio no trabalho em andamento para 
cumprimento de metas e prazos. Aqui a qualidade está atrelada à velocidade no 
nível de produção, no desempenho da equipe e na 
eliminação de retrabalhos. A figura 3 nos exemplifica um modelo de sinalizador 
visual Kanba. 
Figura 3: Sinalizador visual Kanban 
 
Fonte: Mariotti, 2016. 
 
O Kanban auxilia no rastreio e demonstração visual do progresso das 
atividades em andamento e na redução rápida do lead-time. Lead-time consiste 
no tempo decorrido entre a entrada da solicitação pelo cliente até o momento da 
 
10 
 
disponibilização para o mesmo do software. Para quem atua de acordo com a 
metodologia Scrum, um dos desafios enfrentados é o atraso na entrega 
conforme o Sprint. A entrega em atraso representa riscos e afeta o desempenho 
da produção, bem como o resultado de valor entregue para o cliente. Ele espera 
que todos atuem em conjunto em cada atividade, não iniciando outra até que 
cada atividade seja encerrada. 
Então o Kanban vem agregar em muito um excelente requisito para 
aplicarmos garantia de qualidade em nossos processos de desenvolvimento de 
software para os quais não temos nem tempo, recursos humanos e financeiros 
para adoção de metodologias mais elaboradas. 
 
Leitura obrigatória 
COSTA JUNIOR, 2012 
MARIOTTI, 2016 
 
Saiba mais 
 http://www.sabesim.com.br/Kanban-
landing/?gclid=CKapyaH0gc0CFVIFkQodxGoP8w 
 
 
TEMA 3: DESENVOLVIMENTO BASEADO EM TESTE 
 Uma nova tendência é o desenvolvimento com base em teste 
(test-driven development – TDD). Nesse tipo de desenvolvimento os requisitos 
para um componente de software servem de base para a criação de uma série 
de casos de teste que exercitam a interface e tentam encontrar erros nas 
estruturas de dados e funcionalidade fornecida pelo componente. Ela não é 
exatamente uma nova tecnologia, mas uma tendência que enfatiza o projeto de 
casos de testes antes que o próprio código-fonte exista! (PRESSMAN, 2011). 
Como o TDD funciona? Vamos observar a Figura 4. 
 
11 
 
 
 
 
Figura 4: Fluxo de funcionamento do TDD 
 
Fonte: Pressman, 2011. 
O processo segue um fluxo procedural (figura 4), para o qual criamos cada 
caso de teste, escrevemos um segmento de código, executamos os testes e os 
refazemos (corrigimos) até que estejam de acordo com cada caso de teste. Logo, 
nosso sistema será escrito em pequenos 
incrementos (subfunções) e nenhum código é escrito sem um caso de teste bem 
definido. Os testes comandam o projeto detalhado de componentes e códigos-
fontes resultantes. 
Aqui fica mais uma tendência para os desenvolvedores de metodologias 
ágeis, num caso bem aderente ao método XP (Extreme Programming). Entramos 
novamente então com a prática de garantia de qualidade, porém de forma mais 
simplificada, enxuta e que apoia o processo de desenvolvimento. Em 
consonância com método ágeis, teremos um feedback rápido sobre novas 
 
12 
 
funcionalidades, um código mais limpo, segurança no Refactoring, segurança na 
correção de bugs, mais produtividade, aplicação flexível. Refactoring ou 
refatoração é o momento que analisamos nosso código para nosso teste passar. 
Retiramos duplicidades, renomeamos variáveis, extraímos métodos, classes, 
interfaces e utilizamos algum padrão conhecido. Nosso código ficará mais 
funcional após a refatoração. (GAMA, 2016). 
 
Leitura obrigatória 
SOMMERVILLE, 2011 
Saiba mais 
http://agiledata.org/essays/tdd.html 
 
TEMA 4: QUALIDADE DE SOFTWARE E O BRASIL 
O Brasil iniciou uma proposta na década de 1996 para alcance da 
excelência do software brasileiro, criando a SOFTEX (Associação para 
Promoção da Excelência do Software Brasileiro). Dentre as iniciativas da 
associação, encontravam-se fomento e promoção da indústria brasileira de 
software e serviços de TI, capacitando e promovendo a criatividade, 
competência e fonte de talentos. Abaixo do Ministério da Ciência, Tecnologia e 
Inovação (MCTI), tornou-se um programa que beneficia mais de 2 mil empresas 
em todo o território nacional por meio de uma rede de 20 agentes regionais 
(SOFTEX, 2016). 
Dentro do Programa SOFTEX temos o Projeto denominado MPS.BR, 
criado em 2003. Nada mais é que um projeto que visa impulsionar a melhoria da 
capacidade de desenvolvimento de software e serviços para empresas 
brasileiras. (SOFTEX, 2016). 
 
13 
 
Uma das iniciativas desse projeto resultou no desenvolvimento do Modelo 
de Referência para Melhoriado Processo de Software Brasileiro 
(MPS-SW), levando em consideração normas e modelos internacionalmente 
reconhecidos, além de boas práticas da engenharia de software e necessidades 
de negócio da indústria de software brasileira. (SOFTEX, 2016). Veja Figura 5 a 
seguir. 
Com o MPS-SW foi possível estabelecer um caminho economicamente 
viável para que organizações, incluindo as pequenas e médias 
empresas, alcancem os benefícios da melhoria de processos e da 
utilização de boas práticas da engenharia de software em um intervalo 
de tempo razoável. Ele trouxe para a indústria nacional ganhos 
comprovados de competitividade, por isso é considerado um marco 
que representa a evolução da qualidade do software desenvolvido no 
país. (SOFTEX, 2016) 
Figura 5: Componentes do Modelo MPS 
 
“A iniciativa conta com o financiamento do Banco Interamericano de 
Desenvolvimento (BID), a Financiadora de Estudos e Projetos (FINEP), o 
 
14 
 
Ministério da Ciência, Tecnologia e Inovação (MCTI) e o Serviço Brasileiro de 
Apoio às Micro e Pequenas Empresas (SEBRAE).” (SOFTEX, 2016). 
As bases do MPS.BR são encontradas em: 
1. ISO/IEC 12207:2008 
2. ISO/IEC 15504 
3. ISO/IEC 20000 
4. CMMI-DEV 
5. CMMI-SVC 
Da mesma forma que a CMMI, o MPS.BR possui níveis de avaliação para 
classificar os processos de desenvolvimento de software de empresas 
brasileiras. Em geral, o CMMI é altamente dispendioso para implantação. Uma 
excelente proposta do Programa SOFTEX foi a criação de uma forma de 
certificação nacional, a qual pode ser implantada em colaboração com várias 
empresas por meio de uma das regionais do Programa Softex. 
‘Você pode pensar: mas eu vou implantar o MPS.BR em colaboração com 
meus concorrentes? Não é essa a visão que você deve ter. Você deve pensar 
que se você, como empresa de desenvolvimento de software, deseja seguir 
métodos, padrões e métricas que lhe garantam maior confiabilidade em seus 
processos e produtos, é a forma mais acessível e rápida. 
Leitura obrigatória 
SOFTEX, 2016 
 
TEMA 5: GRANDES DESAFIOS 
Uma grande tendência para a área de computação é inegável, o software 
se tornará cada vez mais complexo. Se observarmos o que estudamos até aqui 
sobre testes de software, utilizamos apenas software convencional, orientado a 
objetos e para Web. Mas quando olhamos ao nosso redor, o que vemos? 
 
15 
 
Software embarcado (automóveis, eletrodomésticos, etc.), computadores 
descartáveis, interação com um ambiente (conjunto de periféricos, 
computadores e outros aparelhos), e por aí a fora. Assim, poderíamos catalogar 
um pouco sobre as nossas novas características a serem abordadas para a 
garantia da qualidade do processo de desenvolvimento de software 
(PRESSMAN, 2011): 
 
1. Multifuncionalidade: um conjunto cada vez maior de funções num único 
dispositivo. Exemplo: celular que serve para comunicação, fotos, 
calendário, mídias digitais, entre tantas outras utilidades. 
 
2. Temporização: dispositivos digitais reagindo a estímulos 
externos. Sensores que fazem com que se dependa menos da 
intervenção humana. 
 
3. Novas interações com o ser humano: teclado e mouse são periféricos 
que deixaremos de ver em breve. Então, modelar outros tipos de interação 
se tornam um desafio cada vez maior. 
 
4. Arquiteturas complexas: várias CPUs, barramentos sofisticados, 
sensores, interface humana mais sofisticada, componentes de segurança. 
Exemplo? Automóveis. 
 
5. Sistemas heterogêneos distribuídos: componentes de tempo real 
embutido e conectado por meio de redes sem fio ou Internet. 
 
6. Criticidade: sistemas que envolvem um nível altíssimo de questões de 
segurança. Exemplo: aviões. 
 
7. Variabilidade de manutenção: o tempo útil de nossos dispositivos 
digitais não se prolonga além de 3 anos. Mas automóveis, aviões entre 
outros ainda terão um tempo maior de vida. 
 
16 
 
No que isso interfere na garantia da qualidade de processos de software? 
Certamente teremos no futuro uma disciplina de Qualidade de Software I e II 
para cobrirmos todas as necessidades de variação de acoplamento entre 
software, hardware e comunicação. 
 
Leitura obrigatória 
SOMMERVILLE, 2011 
CAMPOS, 2016 
 
TROCANDO IDEIAS 
Refletir sobre a introdução da garantia de qualidade, utilizando metas, 
métricas, estatísticas e padrões em projetos de desenvolvimento de software. 
Quais seriam os custos para introduzirmos tantas avaliações, correções e 
padronizações? Precisaríamos de profissionais habilitados para tais tarefas, ou 
bastaria utilizarmos o próprio pessoal do desenvolvimento? 
 
SÍNTESE 
Estudamos até aqui sobre elementos importantes para garantia da 
qualidade. Tanto o gerenciamento quanto a garantia da qualidade querem 
assegurar que o software tenha poucos defeitos e esteja em conformidade com 
padrões de manutebilidade, confiabilidade e portabilidade. Os padrões são muito 
importantes para a garantia de qualidade, pois, por meio de suas melhores 
práticas, oferecem uma base para construção de software de boa qualidade. O 
processo de documentação, que é um elemento bastante importante dentro da 
área de qualidade, pode ser baseado num conjunto de procedimentos da 
garantia de qualidade sugeridas pela ISO 9001. Optar por revisões e inspeções 
garantirão melhoria no processo e no produto. As revisões dos entregáveis são 
 
17 
 
técnicas usadas para avaliação da qualidade, enquanto que inspeção de 
programas ou revisão em pares buscam possíveis erros e omissões. Quando 
falamos em medição de software, usamos coleta de dados quantitativos capazes 
de subsidiarem métricas de software para garantir a qualidade tanto do produto 
quanto do processo. 
 
REFERÊNCIA 
ADAMI, A. Kaizen. Disponível em: 
<http://www.infoescola.com/sociedade/Kaizen/>. Acesso em: maio de 2016. 
COSTA JUNIOR, E. L. Gestão em processos produtivos. Curitiba: 
Intersaberes, 2012. 
GAMA, A. Test Drive Development: TDD simples e prático. Disponível em: 
<http://www.devmedia.com.br/test-driven-development-tdd-simples-e-
pratico/18533>. Acesso em: 2016 em maio de 2016. 
PRESSMAN, R. S. Engenharia de software: uma abordagem profissional. 7. 
ed. Porto Alegre: AMGH, 2011. 
LÉLIS, E. C. Gestão da qualidade. São Paulo: Pearson Prentice Hall, 2012. 
MARIOTTI, F.S. Kanban: o ágil adaptativo: introduzindo Kanban na equipe 
ágil. Disponível em: 
<http://www.garcia.pro.br/EngenhariadeSW/artigosMA/A6%20-%2045-6-
%20Kanbam.pdf>. Acesso em: maio de 2016. 
SHIGUNOV NETO, A. Introdução à gestão da qualidade e produtividade: 
conceitos, história e ferramentas. Curitiba: InterSaberes, 2016. 
SOFTEX. Disponível em: <http://www.softex.br/mpsbr/>. Acesso em: maio de 
2016. 
 
18 
 
GUIA GERAL DO MPS.BR. Disponível em: <http://www.softex.br/wp-
content/uploads/2013/07/MPS.BR_Guia_Geral_Software_2012-c-ISBN-1.pdf>. 
Acesso em: maio de 2016. 
SOMMERVILLE, I. Engenharia de software. 9. ed. São Paulo: Pearson 
Prentice Hall, 2011. 
XIV Simpósio Brasileiro de Qualidade de Software. Anais. 17-21 de agosto de 
2015. Manaus. Disponível em: 
<https://drive.google.com/file/d/0B4ZBCAydIkutSUFuVVhCdXVnbDA/view>. 
Acesso em: maio de 2016.