marcelo filipe rodrigues urbano processo de …
TRANSCRIPT
MARCELO FILIPE RODRIGUES URBANO
PROCESSO DE QUALIDADE DE SOFTWARE: APLICAÇÃO A EMPRESA
BRASILEIRA DE DESENVOLVIMENTO DE PRODUTOS DE SOFTWARE
Trabalho de Conclusão de Curso apresentado ao
curso MBA em Gestão de Tecnologia da Informação,
de Pós-Graduação lato sensu, Nível de
Especialização, da FGV/IDE como pré-requisito para
a obtenção do título de Especialista.
Orientador: André B. Barcaui
SANTOS – SÃO PAULO
2019
FUNDAÇÃO GETULIO VARGAS
PROGRAMA FGV MANAGEMENT
MBA EM GESTÃO DE TECNOLOGIA DA INFORMAÇÃO
O Trabalho de Conclusão de Curso
Processo de qualidade de software: aplicação a empresa brasileira de
desenvolvimento de produtos de software
elaborado por Marcelo Filipe Rodrigues Urbano
e aprovado pela Coordenação Acadêmica do curso de MBA em Gestão de Tecnologia
da Informação, foi aceito como requisito parcial para a obtenção do certificado do
curso de pós-graduação, nível de especialização do Programa FGV Management.
Santos, 15 de abril de 2019.
André Barcaui
Coordenador Acadêmico Executivo
André Barcaui
Orientador
TERMO DE COMPROMISSO
O aluno Marcelo Filipe Rodrigues Urbano, abaixo assinado, do curso de MBA
em Gestão de Tecnologia da Informação, Turma 57N do Programa FGV
Management, realizado nas dependências da Strong/FGV – Santos/SP, no período
de 26/04/2017 a 27/03/2016, declara que o conteúdo do Trabalho de Conclusão de
Curso intitulado processo de qualidade de software: aplicação a empresa brasileira
de desenvolvimento de produtos de software é autêntico, original e de sua autoria
exclusiva.
Santos, 15 de abril de 2019.
Marcelo Filipe Rodrigues Urbano
AGRADECIMENTOS
À Strong-FGV pela oportunidade que me foi proporcionada, viabilizando a
participação no curso MBA-FGV, sem a qual este trabalho não existiria.
Ao Prof. André Barcaui, no duplo papel de Coordenador Acadêmico e
Orientador. No primeiro, por propiciar as condições adequadas à conclusão com o
nível de qualidade almejado; no segundo, pela condução e retornos que permitiram
o resultado final adequado.
À empresa referida no trabalho pelo nome fantasia UNIDADOS, e aos
responsáveis pelas áreas contatadas, inicialmente, pela abertura que
proporcionaram para que uma situação prática relevante pudesse ser abordada, e
no decorrer das atividades, pela atenção e disponibilidade demonstradas. Justa
menção pessoal ao Diretor de Operações, ao Diretor de Processos e Qualidade, ao
Coordenador de Qualidade e ao Diretor de Pesquisa e Desenvolvimento.
À minha família, em especial à minha esposa Sonia, pelo apoio e
compreensão ao longo de todo o tempo dedicado à criação deste trabalho.
RESUMO
O objetivo deste trabalho é efetuar uma compilação do estágio atual da teoria referente à qualidade de software, seus processos e práticas, e aplicá-lo à análise de um caso real. O estudo teórico foi conduzido com o objetivo de poder ser direcionado à observação efetuada, sendo focados os pontos que poderiam ser aplicáveis à análise. A empresa observada é brasileira, de porte médio-grande, líder em seu mercado, e fornece múltiplos produtos de software, tendo sido constituída através de aquisições gradativas de mais de dez empresas com soluções voltadas ao mesmo segmento. Em consequência, apresenta um quadro altamente heterogêneo, representando um grande desafio prático a qualquer iniciativa em termos de processos e padronização de práticas. Identificamos que já existe consciência da necessidade de melhoria, tendo ações importantes sido implementadas durante os meses em que a acompanhamos para elaboração deste trabalho. As informações observadas foram analisadas e comentadas em relação à base teórica construída, sendo então geradas ao final propostas de melhoria e conclusões sobre oportunidades e limitações.
Palavras-Chave: qualidade; software; processos.
ABSTRACT
The objective of this work is to perform a compilation of the current stage of software
quality theory, its processes and practices, and apply it to the analysis of a real case.
The theoretical study was conducted with the objective of being able to be applied to
the observation made, focusing on the points that could be used in the analysis. The
observed company is Brazilian, medium-sized, leader in its market, and provides
multiple software products, having been constituted through gradual acquisitions of
more than ten companies with solutions focused on the same segment. Therefore, it
presents a highly heterogeneous scenario, representing a great practical challenge to
any initiative in terms of processes and standardization of practices. We identified
that there is already an awareness of the need for improvement, and important
actions have been implemented during the months in which we have followed it to
prepare this work. The observed information was analyzed and commented on the
theoretical basis built, and then proposals for improvement and conclusions on
opportunities and limitations were generated.
Keywords: quality; software; processes.
LISTA DE ABREVIATURAS
CMM - Capability Maturity Model
CMMI - Capability Maturity Model Integration
DevOps – Development & Operations
FINEP - Financiadora de Estudos e Projetos
GCS – Gestão de Configuração de Software
IaaS – Infraestrutura como Serviço (Infrastructure as a Service)
Iac – Infraestrutura como Código (Infrastructure as Code)
ISACA - Information Systems Audit and Control Association
ISO - International Standards Organization
ITIL – Information Technology Infrastructure Library
IXP – Industrial Extreme Programming
MCTI - Ministério da Ciência, Tecnologia e Inovação
MPS-BR – Melhoria de Processos de Software Brasileiro
P&D – Pesquisa e Desenvolvimento
PaaS – Plataforma como Serviço (Platform as a Service)
PDCA – Plan, Do, Control, Act
People-CMM – People Capability Maturity Model
QA – Garantia de Qualidade (Quality Assurance)
RUP – Rational Unified Process
SaaS – Software como Serviço (Software as a Service)
SCRUM – framework ágil para criação de produtos
SEBRAE - Serviço Brasileiro de Apoio às Micro e Pequenas Empresas
SEI - Software Engineering Institute
SLA – Acordo de Nível de Serviço (Service Level Agreement)
SOFTEX - Associação para Promoção da Excelência do Software Brasileiro
SPI – Melhoria de Processo de Software (Software Process Improvement)
SPICE - Software Process Improvement and Capability Determination
TDD – Desenvolvimento Orientado a Testes (Test Driven Development)
TI – Tecnologia da Informação
TSP – Team Software Process
XP – Extreme Programming
LISTA DE FIGURAS E TABELAS
Figura 1: Degradação de software ao longo do tempo .............................................. 16
Figura 2: Modelo cascata segundo Roger Pressman ................................................ 25
Figura 3: Modelo cascata segundo Ian Sommerville ................................................. 26
Figura 4: O modelo V ................................................................................................ 26
Figura 5: Modelo incremental .................................................................................... 29
Figura 6: Modelo espiral de Boehm ........................................................................... 31
Figura 7: Extreme Programming ............................................................................... 37
Figura 8: Industrial XP ............................................................................................... 40
Figura 9: SCRUM Framework ................................................................................... 42
Figura 10: Ciclo DevOps ........................................................................................... 45
Figura 11: Evolução dos custos de correção de erros .............................................. 49
Figura 12: Fatores determinantes da qualidade de software .................................... 70
Figura 13: Áreas do CMMI ........................................................................................ 73
Figura 14: Níveis de capacidade no CMMI ............................................................... 74
Figura 15: Níveis no modelo MPS-BR ....................................................................... 76
Tabela 1: Atributos de um bom software segundo Sommerville................................ 20
Tabela 2: Visões da qualidade segundo Garvin ........................................................ 20
Tabela 3: Dimensões da qualidade segundo Garvin ................................................. 21
Tabela 4: Fatores determinantes da qualidade segundo McCall............................... 22
Tabela 5: Comparativo entre definições do modelo cascata ..................................... 27
Tabela 6: Tipos de revisão de software ..................................................................... 47
Tabela 7: Evolução dos custos de correção .............................................................. 50
Tabela 8: Custos da qualidade e sua falta ................................................................ 52
Tabela 9: Métricas de qualidade de software segundo Pressman ............................ 53
Tabela 10 Níveis de maturidade no CMMI por estágios ........................................... 75
Tabela 11 Documentos do modelo MPS-BR ............................................................ 77
SUMÁRIO
1. INTRODUÇÃO ............................................................................................... 11 2. FUNDAMENTAÇÃO TEÓRICA ...................................................................... 13
2.1 Software ....................................................................................................... 13 2.1.1 Definição .................................................................................................. 13 2.1.2 Importância ............................................................................................... 13 2.1.3 Ciclo de Vida – Evolução e Manutenção .................................................. 14 2.2 Qualidade de Software ................................................................................. 19
2.2.1 Definições e Características ..................................................................... 19 2.2.2 Visões e Dimensões por Garvin ............................................................... 20
2.2.3 Fatores Determinantes da Qualidade segundo McCall ............................ 22 2.2.4 Uma definição sucinta de Qualidade ........................................................ 22 2.3 Engenharia de Software ............................................................................... 23 2.4 Processo de Software ................................................................................... 24
2.5 Modelos de Processos de Software ............................................................. 25 2.5.1 Dirigidos a Planos ..................................................................................... 25
2.5.2 Modelos Ágeis .......................................................................................... 31 2.6 Práticas e Técnicas ...................................................................................... 42 2.6.1 Histórias de usuário (user stories) ............................................................ 42
2.6.2 Desenvolvimento Orientado a Testes (Test Driven Development) ........... 43
2.6.3 Programação em pares - Pair Programming ............................................ 44 2.6.4 Integração Contínua – Continuous Integration ......................................... 44 2.6.5 Teste Contínuo – Continuous Testing ...................................................... 44
2.6.6 Entrega Contínua – Continuous Delivery ................................................. 45 2.6.7 DevOps .................................................................................................... 45
2.6.8 Revisões Técnicas ................................................................................... 46 2.6.9 Refatoração .............................................................................................. 48 2.7 Sobre Requisitos, Análise e Projeto ............................................................. 49
2.8 Gestão da Qualidade .................................................................................... 50 2.8.1 Custo da Qualidade e Custo da Falta da Qualidade ................................ 51 2.8.2 Métricas .................................................................................................... 52
2.8.3 Gestão de Configuração / Gestão de Mudanças ...................................... 54 2.8.4 Verificação x Validação ............................................................................ 55
2.9 Testes de Software ....................................................................................... 55 2.9.1 Objetivos e Princípios ............................................................................... 55
2.9.2 Estratégia (Plano) de Teste ...................................................................... 56 2.9.3 Responsabilidade ..................................................................................... 56 2.9.4 Estágios de Teste ..................................................................................... 57
2.9.5 Testes Manuais e Automatizados............................................................. 58 2.9.6 Teste Baseado em Riscos - Risk Based Testing ...................................... 60
2.9.7 Tipos de Testes ........................................................................................ 61 2.10 Tratamento de Defeitos ................................................................................ 65 2.10.1 Registro .................................................................................................... 66
2.10.2 Classificação ............................................................................................ 67 2.10.3 Soluções ................................................................................................... 68
2.11 Melhoria de Processo de Software ............................................................... 69
2.11.1 Conceitos ................................................................................................. 69 2.11.2 Considerações e limitações ...................................................................... 70
2.11.3 Modelos de Melhoria de Processos de Software ..................................... 71 3. RELAÇÃO DA TEORIA COM A PRÁTICA ..................................................... 78
3.1 Caracterização da Empresa ......................................................................... 78 3.2 Situação inicial observada ............................................................................ 79 3.2.1 Dificuldades e desafios ............................................................................. 81
3.2.2 Resultados de Levantamentos e Pesquisas ............................................. 82 4. PROPOSTA DE MELHORIA .......................................................................... 86
4.1 Ações de reestruturação ............................................................................... 86 4.2 Execução de testes e automação ................................................................. 86 4.3 Tratamento de customizações ...................................................................... 87
4.4 Produtividade e qualidade de novos recursos .............................................. 87 4.5 Qualidade nas iniciativas com métodos ágeis .............................................. 88
4.6 Dificuldade de envolvimento dos usuários .................................................... 88 4.7 Registro e tratamento de defeitos ................................................................. 89 4.8 Posições disponíveis sobre qualidade .......................................................... 90 4.9 Busca e manutenção de certificações (exemplo MPS-BR) .......................... 91
4.10 Alocação da equipe de QA ........................................................................... 91 5. CONCLUSÃO ................................................................................................. 93 REFERÊNCIAS BIBLIOGRÁFICAS .......................................................................... 96
ANEXOS ................................................................................................................... 99
11
1. INTRODUÇÃO
Software de computador vem se tornando a frente tecnológica de maior
relevância para o mundo. Partindo dos primeiros e, pelos padrões de hoje, pouco
ambiciosos, programas destinados a cálculos de volume superior aos possíveis ao
ser humano ou a controle de grandes volumes de dados, atingimos um cenário onde
elementos de software, explícita ou implicitamente, se fazem presentes em
praticamente todas as áreas de avanço da tecnologia e economia modernas.
A proposta deste trabalho é comparar a teoria referente à qualidade de
software com os desafios em uma situação real, observada em empresa de produtos
e serviços de software de porte médio-grande. A empresa em foco apresenta
internamente grande diversidade de situações entre unidades de negócio e linhas de
produtos, que é tratada no documento, sendo apresentadas ao final avaliação e
proposição de ações de melhoria.
Os resultados obtidos ao longo da elaboração permitiram validar a
aplicabilidade e a importância das recomendações que compõem o conhecimento
formalizado na área de processos e qualidade de software, sem deixar de
contemplar pontos que devem ser levados em consideração na situação prática real,
que impõe limites e necessidade de adaptações aos métodos prescritos
formalmente.
Na pesquisa teórica, foi feito uso de múltiplas fontes, de procedências e
características distintas, para construir uma base de informações atualizada,
abrangente, e fiel ao objetivo de ser aplicável à situação prática real observada. O
resultado, compilando os conceitos fundamentais da teoria disponível, cobrindo
métodos tradicionais e ágeis, e incluindo o descritivo de práticas que estão em
evidência nas organizações e podem ser consideradas como no estado da arte, é
então usado no estudo da situação real.
As informações levantadas sobre o histórico e a situação das práticas de
qualidade na empresa traça o cenário atual, que é analisado em comparação à
teoria, permitindo identificar oportunidades e embasar a formulação de propostas de
melhoria e recomendações para a evolução da empresa no aspecto de processos e
qualidade de software.
O conteúdo principal do trabalho está dividido nos quatro capítulos seguintes
a esta Introdução:
• O capítulo 2, Fundamentação Teórica, contém os conceitos colhidos nas
fontes de referência sobre os temas Qualidade de Software e Melhoria de
Processos, abordando, entre outros, modelos de processos, práticas,
12
gestão da qualidade, testes e frameworks aplicáveis. Foram abordados, de
forma sucinta e voltada à prática, os principais aspectos que influenciam a
qualidade de software.
• No capítulo 3, Relação da Teoria com a Prática, apresentamos a empresa
objeto, o histórico e cenário atual da mesma, com as dificuldades e
desafios decorrentes, e os resultados dos levantamentos e pesquisas
efetuados. Neste último ponto, segmentamos as informações obtidas
segundo uma estrutura de tópicos que será retomada na sequência.
• O capítulo 4, Proposta de Melhoria / Análise dos Resultados, apresenta
estes pontos como consequência da análise das informações obtidas a
partir das definições incluídas no capítulo 2, propondo ações e práticas
que podem elevar a qualidade dos processos da empresa. Os itens são
abordados usando a mesma estrutura do capítulo anterior.
• Finalizando o trabalho, a Conclusão, apresentada no capítulo 5, agrega
todo o resultado atingido, acrescentando comentários opinativos e
sugestões adicionais de ações de maior fôlego, que envolvem obtenção
de suporte na hierarquia superior.
13
2. FUNDAMENTAÇÃO TEÓRICA
2.1 Software
2.1.1 Definição
Quando falamos de software, a que nos referimos exatamente? Dependendo
do ponto do qual o tratamos, pois existem múltiplas formas de definir o que é
software.
Uma abordagem simplista vê software como sinônimo de programas de
computador. [SOMMERVILLE] em sua abordagem engenharia de software amplia
este conceito para incluir também todos os elementos de documentação associada e
todos os dados de configurações necessárias à operação normal dos programas.
Do ponto de vista funcional, software é um armazenador, transformador e
distribuidor do produto que se tornou o mais importante na atual era, as informações,
sejam elas simples e de pequeno volume, como dados de uma mensagem de texto
ou um tweet, sejam complexos ou gigantescos como grandes bases de dados ou
arquivos multimídia para streaming.
Também podemos olhar software como produto, serviço, ou uma combinação
de ambos (SOMMERVILLE, 2011). As diversas formas de ofertas de SaaS (software
como serviço) são ilustrativas do quanto podemos variar nessa dimensão.
Muitas outras definições podem ser encontradas, abordando com méritos
aspectos relacionados a softwares, mas, conforme [PRESSMAN] colocou após
apresentar uma delas: “Sem dúvida, poderíamos dar outras definições mais
completas, mas, provavelmente, uma definição mais formal não melhoraria,
consideravelmente, a compreensão do que é software”.
2.1.2 Importância
[PRESSMAN] menciona áreas de negócios, ciência e engenharia, citando
como exemplos, entre outros:
• Criação de novas tecnologias como engenharia genética e nanotecnologia
• Extensão de tecnologias existentes, como telecomunicações
• Alteração radical de segmentos, como por exemplo mídia
• Uso pessoal em massa (aplicativos)
• Relevância de grandes empresas de software superando as grandes
organizações financeiras e industriais tradicionais
• Impacto da disseminação de informação em hábitos de compra, política,
comportamentos sociais
14
A esses pode-se acrescentar a revolução da transformação digital, causando
a criação de negócios totalmente novos, a necessidade de reformulação total de
negócios existentes e, em alguns casos, a extinção dos mesmos.
Observa-se no tocante a softwares algumas tendências de caráter universal:
• Dificuldade em apontar um campo onde não exista ou possa existir
aplicação de recursos computacionais.
• Crescimento da sofisticação e complexidade dos requisitos
demandados das soluções.
• Uso acentuado, caracterizando dependência, do software para tomada
de decisões e controle de operações críticas no dia-a-dia.
• Crescimento do número de usuários dos softwares de sucesso,
induzindo extensão da vida útil, com consequente aumento de
adaptações e novos recursos.
Por tudo que foi elencado acima, vemos que existe uma necessidade de
buscar o aperfeiçoamento dos processos utilizados para criar e evoluir softwares, de
forma a obter produtos e serviços com maior qualidade.
2.1.3 Ciclo de Vida – Evolução e Manutenção
O desenvolvimento do software não termina com a conclusão da primeira
versão e a disponibilização em operação, mas sim continua por toda a vida útil do
mesmo. Depois que o sistema é implantado, para que ele se mantenha útil é
inevitável que ocorram mudanças. Normalmente se dá o nome de manutenção ao
processo de mudança depois da liberação inicial para uso.
Os fatores principais que levam à necessidade de introduzir mudanças nos
softwares podem ser sumarizados em (SOMMERVILLE, 2011):
• Frenética evolução do ambiente de negócios por conta da competitividade,
exigindo que as empresas ofereçam novos produtos, serviços, opções e
recursos adicionais ou alterados para sobreviverem no mercado. Tudo isto
impacta em mudanças nos softwares de forma a suportarem as novas
necessidades: os novos requisitos são essenciais para fornecer valor ao
negócio.
• Mudanças no ambiente de processamento, requerendo atualizações de
cunho tecnológico para permitir a continuidade do uso do software em
plataformas diferentes das usadas quando do desenvolvimento.
• Otimizações que se percebam como necessárias em função de requisitos
não funcionais de tempo de resposta, capacidade, volumes, etc.
15
2.1.3.1 Tipos de Manutenção
Segundo é colocado em [SOMMERVILLE], podemos identificar alguns tipos
de manutenção, e apresenta uma proposta de nomenclatura para os mesmos,
embora cite que podem ser usados outros nomes na prática:
• Manutenção corretiva
o Visa corrigir erros e defeitos, que definimos adiante como nomes
aplicados a falhas do sistema, de acordo com a origem da
identificação.
• Manutenção adaptativa
o Adaptação a novos ambientes de processamento ou a
alterações no ambiente original.
• Mudança perfectiva
o Implementação de novos requisitos.
o Melhoria de estrutura ou desempenho.
2.1.3.2 Distinção entre Erros e Defeitos
Neste trabalho, diferenciaremos erros de defeitos, de acordo com o
ponto/agente envolvidos na identificação (PRESSMAN, 2016):
• Erros são encontrados internamente, antes da entrega para uso em
produção, tanto por pessoas da própria organização desenvolvedora
do software quanto pelo usuário, normalmente durante os ciclos de
teste, revisão e apresentações.
• Defeitos são encontrados externamente, em ambiente de produção,
pelo usuário do software. Sua ocorrência também é denominada
‘incidente’ ou ‘incidente em produção’.
2.1.3.3 Degradação de Software
Conforme apontado por [PRESSMAN], ao contrário do hardware, não ocorre
com o software o fenômeno de desgaste pela ação do tempo e fatores do ambiente
físico. Idealmente, um software, após as correções sobre as versões iniciais, atingiria
um certo nível de defeitos em determinado momento de seu ciclo de vida, que a
partir daí se manteria constante.
16
No entanto, cada mudança efetuada tem o potencial de provocar efeitos
colaterais indesejados, ou seja, introduzir erros ou defeitos, elevando o nível dos
mesmos a outro patamar, seguido por ações de correção, que não conseguem mais
fazer a situação retornar ao patamar anterior. Isso se repete de forma cíclica,
resultando ao longo do tempo em versões de software com número de problemas
crescente, conforme esquematizado na figura 1, adaptada de [PRESSMAN]:
Figura 1: Degradação de software ao longo do tempo
Fonte: Adaptada de PRESSMAN, 2016.
A própria correção de erros e defeitos detectados é uma fonte de mudanças,
portanto pode introduzir novos problemas.
Conforme ressaltado em [MPS-BR], empresas de produtos de software
precisam alcançar competitividade melhorando os produtos de software e os
serviços associados ao mesmo para os clientes. O adequado tratamento dos seus
produtos ao longo do ciclo de vida, evitando a ocorrência dos fatores que podem
levar à degradação, é um fator crítico para se ter sucesso no mercado.
2.1.3.4 Considerações sobre mudanças em sistemas
A dinâmica de evolução de programas, ou seja, das mudanças de software,
vem sendo objeto de estudos há décadas, incluindo levantamentos empíricos de
situações reais. [LEHMAN] apresentou conclusões na forma de algumas leis
relativas à mudança de sistemas, resumidas a seguir:
17
1. Manutenção de sistema é um processo inevitável. O ambiente do
sistema muda, novos requisitos surgem, o sistema deve ser modificado
para continuar útil.
2. Alteração de sistema gera degradação na estrutura do mesmo, indo de
encontro ao que já vimos. Investimento adicional é necessário para
prevenir ou minimizar esse efeito, assim como uma estratégia
inteligente, efetuando alterações de forma mais controlada e planejada.
3. Sistemas de grande porte, pela sua complexidade, têm uma dinâmica
própria, como consequência de fatores estruturais que restringem e
afetam a evolução. Merece citação o fato sistemas complexos aparecem
em empresas de maior porte, onde o processo de decisão e governança
restringe a cadência entre releases.
4. Grandes projetos de programação são inelásticos a mudança de
recursos ou de pessoal. Isso é consistente com a terceira lei; em
equipes grandes os overheads de comunicação são muito onerosos
para a produtividade.
5. Mudanças de funcionalidade muito grandes geram muitos defeitos, que
requerem releases de correção na sequência, resultando em uma média
mais baixa de mudança por release. É mais produtivo manter releases
menores.
6. Satisfação contínua do usuário requer entrega constante de novas
funcionalidades.
7. Sistemas precisam evoluir acompanhando as mudanças em seu
ambiente operacional.
8. Receber e tratar feedback é vital para melhoria de software.
Conforme [SOMMERVILLE], as observações de Lehman parecem sensatas,
devendo ser levadas em consideração. Na prática, situações comerciais ou
restrições de recursos podem fazer com que sejam total ou parcialmente
abandonadas.
2.1.3.5 Relevância dos custos de manutenção e evolução
Os custos de manutenção normalmente representam uma fração majoritária
dos custos totais com softwares. As fontes consultadas citam estatísticas e
estimativas baseadas em estudos e experiência prática: em [SOMMERVILLE] são
mencionados estudos que estimam essa parcela em aproximadamente 2/3, o que
está de acordo com a faixa de 60% a 70% citada em [PRESSMAN].
Fica claro que medidas que possam reduzir custos terão impacto positivo
significativo. Dentre eles citamos:
18
• Na criação do software, investir em arquitetura, práticas, padronização
e documentação que facilite a compreensão e a mudança no futuro,
bem como reduza ao máximo a dependência do conhecimento dos
desenvolvedores originais, sempre passíveis de realocação ou turn
over.
• Durante a manutenção, estar atento a oportunidades de alterar o
software com o mesmo objetivo. Reengenharia, refatoração de código,
pequenas alterações nos programas que preservem a funcionalidade,
podem ser pensadas como manutenção preventiva.
2.1.3.6 Estratégias de customização
Em produtos de software distribuídos a múltiplos clientes, é praticamente
constante a solicitação de customizações de forma a suportar processos de
negócios específicos ou criar integrações com outros elementos componentes da
arquitetura de sistemas do cliente. Mesmo as soluções oferecidas no modelo
Software Como Serviço (SaaS), conceitualmente compartilhadas por vários clientes,
estão sujeitas a este tipo de demanda.
O grande desafio para os fornecedores é atender a essa demanda sem
comprometer a estrutura do produto, o que impactaria em restrições para melhor
eficiência e possibilidade de evolução. Graus de sucesso associados a estratégias
distintas podem ser encontrados na prática. Para efeito deste trabalho,
consideramos duas situações possíveis:
1. Customizações agregadas ao produto de forma controlada: Esta é a
situação ideal, onde customizações são mantidas sempre que possível
em módulos satélites e, quando necessário, agregadas ao produto de
forma planejada para não impactar a estrutura e evolução do mesmo.
É comum o uso de tabelas ou arquivos de configuração por cliente
para habilitar as customizações. Manter este nível requer esforços de
gestão atuantes, podendo representar investimentos iniciais maiores,
com retornos ao longo do tempo.
2. Customizações agregadas ao produto gerando versão específica: Para
gerar a instalação em um novo cliente, uma versão de software é
‘clonada’ e submetida às customizações específicas requeridas
gerando uma linha de código própria. Deixa de ser preservada a
estrutura do produto, tendo como resultado prático a instalação de
cada cliente se tornar um ‘produto de usuário único’, elevando o custo
de atendimento e manutenção e inviabilizando a atualização de
versões ou mesmo o reaproveitamento eficiente de código que foi
criado para outros clientes. Claramente esta situação não é
recomendável e deve ser evitada, embora em alguns casos isso não
19
seja possível, devido a opção do próprio cliente por gerenciar a
evolução da solução de forma autônoma.
2.2 Qualidade de Software
Um software, para oferecer os benefícios esperados, deve apresentar um
conjunto de características que pode ser rotulado como Qualidade. Como apontado
por [AMORIM], para iniciar o entendimento de Qualidade de Software, deve-se partir
do ponto de que há múltiplas definições do significado, tornando difícil a definição.
Tentativas de classificação enfocam apenas algumas de suas características,
deixando de lado outras possíveis abordagens. São muito dependentes do ponto de
vista do avaliador, da cultura e do ambiente envolvidos, ficando algumas delas
sujeitas a considerações subjetivas.
Isso não invalida as tentativas formuladas, pois a definição de um conjunto de
critérios permite entender e avaliar a qualidade, pelo menos em algumas dimensões.
2.2.1 Definições e Características
A teoria referente a qualidade de software é fortemente derivada e segue os
princípios das teorias de qualidade em geral, desenvolvidas por acadêmicos
clássicos, dos quais, com base em [GAR87] destaca-se:
• Joseph Juran, em sua obra seminal, “Quality Control Handbook”,
apresentando os conceitos de custos de falta de qualidade e custos de
obtenção da qualidade, defendendo que os primeiros são muito superiores
aos segundos.
• Armand Feigenbaum, com o conceito de Controle de Qualidade Total,
apontando a necessidade de a qualidade ser tratada por todas as áreas
das organizações
• William Edwards Deming, com a teoria de gestão voltada para a qualidade
total, incluindo a conceituação do modelo PDCA, com alto impacto na
evolução da indústria e economia japonesa.
A partir destes e de outros autores, evoluíram as definições e visões
aplicáveis à qualidade de software, algumas das quais se destacaram e são
apresentadas na sequência.
Em [SOMMERVILLE], são apresentados os “atributos essenciais de um bom
software”, resumidos na tabela 1:
20
Característica Descrição
Manutenibilidade
Ser escrito de forma que possa evoluir. Crítico dada a já vista
inevitabilidade da necessidade de acompanhar as mudanças no ambiente
de negócio.
Confiança e proteção
Inclui confiabilidade, proteção e segurança. Não deve permitir prejuízos
físicos ou econômicos por falhas de sistema. Deve impedir acessos não
autorizados ou prejudiciais.
Eficiência
Uso parcimonioso de recursos de hardware, oferecendo respostas,
capacidade e escalabilidade compatíveis com o ambiente de
processamento utilizado.
Aceitabilidade Adequação ao tipo de usuário, compreensibilidade, usabilidade,
compatibilidade com outros sistemas usados.
Tabela 1: Atributos de um bom software segundo Sommerville
Fonte: Adaptada de Sommerville, 2011.
2.2.2 Visões e Dimensões por Garvin
[GARVIN84] apresenta cinco visões da qualidade, que são um bom exemplo
de como os diferentes enfoques levam a critérios de avaliação diferenciados:
Visão Descrição
Transcendental
Aponta que qualidade não pode ser definida explicitamente, mas pode ser
reconhecida imediatamente. Exemplo: carro da marca Ferrari. É muitas
vezes associada com força de marca no mercado.
Do Fabricante
Considera qualidade como conformidade com as especificações, sem
apresentar erros.
Do Usuário Avaliada pela satisfação do cliente com o produto ou serviço, ou seja,
atendimento às metas do usuário.
De Produto Ligada às características inerentes, como por exemplo, funções e recursos.
Baseada em Valor Percepção em relação a relação custo-benefício, ou a quanto o cliente
estaria disposto a pagar pelo produto.
Tabela 2: Visões da qualidade segundo Garvin
Fonte: Adaptada de GARVIN84, 1987.
21
Em [GARVIN87] são propostas ainda 8 dimensões para a qualidade em geral,
mas que são plenamente aplicáveis também a qualidade de software. Elas cobrem
uma gama que se inicia em critérios objetivos e se estende até a própria estética. A
tabela 3 apresenta resumidamente essas dimensões:
DIMENSÃO DA QUALIDADE A QUE SE REFERE
DESEMPENHO Características operacionais básicas, funções,
recursos, geração de valor para usuários
CARACTERÍSTICAS
Características secundárias que suplementam a
funcionalidade básica, excedendo expectativas
CONFIABILIDADE
Probabilidade de mau funcionamento ou falha,
disponibilidade
CONFORMIDADE
Grau de atendimento a padrões e
especificações
DURABILIDADE
Tempo de vida útil sem degradação devido a
efeitos colaterais de alterações que inviabilize a
continuidade do uso
ATENDIMENTO
Rapidez e facilidade de evolução e reparo,
agilidade, custo envolvido
ESTÉTICA
Subjetiva, fatores envolvidos hoje rotulados
como User Experience, elegância no uso
QUALIDADE PERCEBIDA
Percepções individuais de cada consumidor,
influências de marca, influenciadores
Tabela 3: Dimensões da qualidade segundo Garvin
Fonte: Adaptada de GARVIN84, 1987.
22
2.2.3 Fatores Determinantes da Qualidade segundo McCall
[MCCALL] apresentou uma classificação de fatores determinantes da
qualidade de software, dividindo-os em três grandes grupos:
Operação do
Produto
Correção Atende a especificação e os objetivos do cliente
Confiabilidade Realiza com a precisão exigida a função desejada
Usabilidade Esforço necessário para aprender, operar, preparar
dados de entrada e interpretar as saídas
Integridade Controle de acesso ao software ou dados por
pessoas não autorizadas
Eficiência Volume de recursos computacionais e código
necessários para desempenhar uma função
Revisão do
Produto
Manutenibilidade Esforço envolvido para localizar e corrigir erros
Flexibilidade Esforço necessário para modificar um programa em
operação
Testabilidade Esforço necessário para testar um programa para
garantir o atendimento à funcionalidade requerida
Transição do
Produto
Portabilidade Esforço para transferir o software de um ambiente
para outro
Reusabilidade Capacidade de uso de um programa ou partes dele
em outras aplicações
Interoperabilidade Esforço para integração a outros sistemas
Tabela 4: Fatores determinantes da qualidade segundo McCall
Fonte: Adaptada de McCall, 1977.
2.2.4 Uma definição sucinta de Qualidade
Nota-se que entre os diversos autores há uma convergência em múltiplos
conceitos e características referentes à qualidade, o que está de acordo com a visão
de [PRESSMAN], que coloca que a qualidade de software engloba uma grande
multiplicidade de conceitos. Apresenta ainda uma proposta de definição sucinta:
“Qualidade de software pode ser definida como: uma gestão da qualidade
efetiva aplicada de modo a criar um produto útil que forneça valor mensurável para
23
aqueles que os produzem e para aqueles que o utilizam” (PRESSMAN, 2016, p.
414)
Esta definição enfatiza alguns pontos importantes da qualidade de software,
em especial o primeiro, que abordaremos em maiores detalhes neste trabalho
(PRESSMAN, 2016):
• Qualidade é obtida através de gestão.
• Produto útil entrega com confiabilidade o que o usuário precisa.
• Geração de valor representa entrega de benefícios para a empresa de
software e para os usuários do mesmo.
2.3 Engenharia de Software
A importância do software nas nossas vidas e a necessidade de melhores
resultados – a tão buscada qualidade - no desenvolvimento e evolução dos sistemas
levou a uma conclusão direta de que, independentemente de campo de aplicação e
de como se apresentam, softwares devem ser objeto de processos de engenharia,
originando-se daí toda a extensa disciplina da Engenharia de Software.
Uma definição abrangente da mesma é fornecida em [IEE93]: “Engenharia de
Software: (1) Aplicação de uma abordagem sistemática, disciplinada e quantificável
ao desenvolvimento, operação e manutenção de software; isto é, a aplicação de
engenharia ao software. (2) O estudo de abordagens conforme a definição (1)”.
Esta definição é suficientemente genérica para abranger todo espectro de
atuação da engenharia de software. No entanto, dadas a multiplicidade de situações
que ocorrem, a gradação aplicada em relação aos termos “sistemática”,
“disciplinada” e “quantificável” é o segredo do sucesso ou insucesso no mundo da
prática.
Há um enorme desafio representado pelas grandes diferenças encontradas
em fatores como prazos, recursos (incluindo em alto grau de importância as
pessoas!), custos, concorrência, cultura, riscos e oportunidades. Estes fatores
direcionam decisões relacionadas a engenharia de software muito distintas a cada
situação.
[SOMMERVILLE] reforça que processos de software são complexos,
intelectuais e criativos, dependentes de julgamentos e decisões de pessoas. E que
não existe processo ideal, a maioria das organizações desenvolve os próprios
processos de desenvolvimento de software.
Apesar disso, aponta que existem fundamentos que se aplicam a todos os
tipos de sistemas de software [SOMMERVILLE]:
24
1. O desenvolvimento deve seguir um processo gerenciado e compreendido,
seguindo plano que atenda características específicas tanto do software
quanto da organização.
2. Importância da Confiabilidade, significando manter comportamento
esperado, sem falhas, estar disponível quando necessário, oferecer
segurança contra uso indevido e ataques externos, e do Desempenho, ou
seja, executar de forma eficiente e não desperdiçar recursos.
3. Entender e gerir especificação e os requisitos de software, conhecer e
gerenciar expectativas de clientes e usuários, são importantes para que
um sistema útil possa ser entregue dentro do orçamento e do
cronograma.
4. Deve-se fazer o melhor uso possível dos recursos existentes, significando
buscar o reuso do software já desenvolvido, em vez de escrever um novo.
2.4 Processo de Software
As já vistas definição de [IEE93] que prevê “aplicação de uma abordagem
sistemática, disciplinada e quantificável” e observação de [SOMMERVILLE] sobre
“um processo gerenciado e compreendido” apontam para a necessidade de definir
de um processo a ser adotado no ciclo de vida de softwares.
Para [PRESSMAN], um processo é “um conjunto de atividades, ações e
tarefas realizadas na criação de algum artefato”. Um processo não é rígido, podendo
ser adaptado às necessidades de cada situação, nunca perdendo de vista o objetivo
de entregar software com qualidade satisfatória e dentro do prazo.
Visando definir processos eficientes e passíveis de replicação, foi definida
pelos teóricos da engenharia de software uma variedade de modelos. As definições
existentes se basearam em observação empírica de processos ad hoc e aplicação
de conceitos da teoria de qualidade.
Um modelo pode ser visto como uma descrição geral de processo, definindo o
fluxo de atividades e seus produtos, bem como o papel de cada envolvido,
oferecendo um roteiro para a execução do trabalho.
São apresentados sucintamente a seguir alguns dos principais modelos,
comentando sobre sua adequação a situações reais. Existem muitos outros modelos
que não serão detalhados, como por exemplo prototipação, baseado em
componentes, e orientados a aspectos, que podem ser consultados nas fontes de
referência.
25
2.5 Modelos de Processos de Software
2.5.1 Dirigidos a Planos
[SOMMERVILLE] usa o nome de processos de software dirigidos a planos
para aqueles em que todas as atividades são planejadas com antecedência, e o
progresso é avaliado por comparação com o planejamento inicial.
Já [PRESSMAN] usa a denominação prescritivos, por definirem um conjunto
de elementos (atividades, ações, tarefas, artefatos, gestão de e controle),
acompanhado de um fluxo de trabalho que os encadeia.
2.5.1.1 Cascata
Este modelo também é conhecido como Clássico, Waterfall e Sequencial
Linear, tendo sido o primeiro a ser publicado formalmente, sendo atribuído a Winston
W. Royce em [ROYCE], em trabalho publicado em 1970
Segmenta o processo em uma sequência de etapas a serem executadas de
forma consecutiva e sequencial, onde os artefatos produzidos em cada fase devem
ser aprovados ao final da mesma, sendo assim permitido o início da fase seguinte,
para a qual funcionarão como insumos. Embora o próprio Royce apontasse a
necessidade de feedback e iteração, a maioria das organizações utiliza o modelo
cascata de forma linear unidirecional.
A figuras 2 e 3, mostram duas visões do modelo cascata. Ambas ilustram o
sequenciamento temporal das atividades e, no caso do segundo, o ciclo de
manutenção, que pode acionar atividades em etapas distintas do processo.
Figura 2: Modelo cascata segundo Roger Pressman
Fonte: Adaptada de PRESSMAN, 2016.
26
Figura 3: Modelo cascata segundo Ian Sommerville
Fonte: Adaptada de Sommerville, 2011.
Uma abordagem derivada do modelo em cascata é denominada de Modelo V,
que se refere à forma da imagem onde as etapas do processo de software são
mostradas em correspondência aos vários níveis de teste que são aplicados sobre o
software antes de o mesmo ser considerado apto ao uso. A figura 4 mostra uma
representação desse modelo. Os tipos de teste nela mostrados serão explicados em
maiores detalhes adiante.
Figura 4: O modelo V
Fonte: Adaptada de PRESSMAN, 2016
27
Podemos constatar que há mais de uma forma de apresentar as divisões e
também nomenclaturas diferentes. A tabela 5 mostra alguns exemplos de definições
de modelos em cascata encontrados nas fontes de referência, e uma escala
aproximada de correspondência entre as fases neles previstas, construída a partir
da análise comparativa elaborada para este trabalho.
Ian Sommerville Roger Pressman Edward Yourdon IBM RUP
Definição de Requisitos
Comunicação
Planejamento
Requisitos do Sistema Concepção
Requisitos de Software
Elaboração
Projeto de Sistema e do
Software Modelagem
Análise
Projeto de Programas
Construção
Implementação e Teste
unitário
Construção
Codificação
Integração e Teste de
Sistema Teste
Operação e Manutenção Implantação Operação Transição
Tabela 5: Comparativo entre definições do modelo cascata
Fonte: Elaborada a partir das definições de cada modelo
O modelo em cascata tem sofrido muitas críticas por não atender
adequadamente as necessidades e condições encontradas no mundo real.
Podemos citar entre elas:
• Dificuldade de se obter adequadamente todos os requisitos na fase inicial,
gerando mudanças que colocam em risco o processo pois não há previsão
para tratar incertezas.
• Longo prazo entre tomada de requisitos e entrega do software para testes
de aceitação pelo usuário. Custo de alteração ou de correção de eventuais
erros é muito alto pois a necessidade só é identificada quase no fim do
processo. Considerações sobre este ponto são apresentadas mais adiante
neste trabalho.
• O mesmo longo prazo impõe outro tipo de risco, que vem se agravando
devido ao ambiente de negócios em rápida evolução. Este risco é de que
o produto final entregue não mais atenda às necessidades da
28
organização, por mudanças no mercado, na concorrência, na estratégia da
empresa ou nas pessoas envolvidas.
• Ainda que possa ocorrer algum grau de iteração, conforme recomendado
desde o trabalho de [ROYCE], o tratamento de mudanças identificadas
impacta o processo, que é planejado para respeitar a sequência de fases.
2.5.1.2 Cascata Incremental
Derivado do modelo em cascata puro, tenta adicionar flexibilidade para tratar
situações onde há um grau de conhecimento razoável dos requisitos, mas alguma
incerteza quanto ao escopo final [PRESSMAN].
Divide o trabalho em uma sequência de incrementos, ou seja, conjuntos de
funcionalidades que são construídos e entregues ao usuário em etapas, ficando para
incrementos posteriores os requisitos e funções adicionais ou ainda em elaboração.
Paralelismo é utilizado para aproveitar melhor os diversos perfis de recursos
envolvidos, reduzindo ociosidade e o tempo total para entrega.
[SOMMERVILLE] aponta como vantagens do modelo incremental sobre o
modelo em cascata:
• Menor custo para acomodar as mudanças nos requisitos do cliente. A
quantidade de análise e documentação a ser refeita é muito menor do
que o necessário no modelo em cascata.
• Maior facilidade para obter feedback dos clientes nas demonstrações
do software que já foi implementado. Avaliar a evolução por meio de
documentos de projeto de software não oferece aos clientes a visão
completa.
• Entregas de valor aos usuários a cada incremento, antes do que é
possível com um processo em cascata. Benefícios são obtidos mais
rapidamente.
Já as desvantagens apontadas são:
• Maior dificuldade de controle do processo, sendo muitas vezes
deixados de lado documentos que representem cada versão do
sistema.
• Tendência a degradação estrutural devido às mudanças adicionadas
nos incrementos sucessivos. Necessidade de investimento em
refatoração do software para evitar esse efeito, o que nem sempre
ocorre na medida em que seria necessário
• Sistemas grandes e complexos, envolvendo várias equipes podem
apresentar desafios para gestão em processo incremental. É
necessário desde o início criar uma definição estável de arquitetura e
29
responsabilidades das diferentes equipes, alongando as fases iniciais
do primeiro incremento para atingir o nível de detalhe adequado.
• Desenvolvimento incremental pode não gerar entrega incremental se
houver o risco que instalar o novo software possa interromper os
processos normais de negócios.
A figura 5 representa visualmente um desenvolvimento dividido em três
incrementos, com um grau controlado de paralelismo entre eles.
Figura 5: Modelo incremental
Fonte: Adaptada de PRESSMAN, 2016
2.5.1.3 RUP
Descrito em [RUP], é um modelo linear que identifica quatro fases distintas no
processo de software, sendo nisso similar ao modelo em cascata. No entanto
[SOMMERVILLE] destaca que, ao contrário deste que alinha as fases com as
atividades do processo, as fases do RUP, descritas a seguir, são relacionadas ao
negócio, e não a assuntos técnicos:
• Concepção
o Criação de um business case para o sistema
o Identificação de todas as entidades externas
o Definição das interações
o Avaliação da viabilidade e decisão sobre continuidade ou
cancelamento
30
• Elaboração
o Entender as principais necessidades
o Definir arquitetura da solução de negócios
o Criar o plano do projeto
o Identificar principais riscos
o Modelo de requisitos
• Construção
o Projeto técnico
o Programação
o Testes
o Integração de forma a obter o software funcionando
o Criação da documentação
• Transição
o Implantação em ambiente de operação real
o Documentação operacional
O RUP, como se pode deduzir, apresenta vantagens e desvantagens do
modelo em cascata. A diferenciação ocorre pelo foco no negócio, que traz uma
maior facilidade de entendimento e aceitação pelos usuários, com a contrapartida de
alguma dificuldade para parte das pessoas da área de TI, que prefeririam algo
alinhado com os processos desta área.
2.5.1.4 Espiral
Em [BOEHM], é proposto um modelo de software dirigido a riscos, onde, ao
invés de uma sequência de atividades, o processo de software é representado como
uma espiral, onde em cada volta se representa uma fase do processo de software
conforme visto nos modelos já apresentados.
A cada fase é efetuada a análise e o tratamento de riscos, seguidos de
prototipação e reavaliação. É possível reconhecer e responder a mudanças, já
assumidas como resultantes naturais dos riscos.
A figura 6 apresenta visualmente a estrutura do modelo espiral.
Este modelo, por suas características de avaliação e planejamento baseadas
em risco, exige que se tenha gerentes e técnicos experientes. Pode-se ter
31
desenvolvimento em paralelo de múltiplas partes do projeto, cada uma sendo
abordada de modo diferenciado, o que gera maiores dificuldades de controle.
Figura 6: Modelo espiral de Boehm
Fonte: BOEHM, 1998
2.5.2 Modelos Ágeis
2.5.2.1 Manifesto Ágil
Em 2001, um grupo de estudiosos e práticos de desenvolvimento de software
divulgou o “Manifesto para o desenvolvimento ágil de software”, cujo texto, pode ser
encontrado em www.manifestoagil.com.br:
32
Estamos descobrindo maneiras melhores de desenvolver software, fazendo-o nós mesmos e ajudando outros a fazerem o mesmo. Através deste trabalho, passamos a valorizar: Indivíduos e interações mais que processos e ferramentas Software em funcionamento mais que documentação abrangente Colaboração com o cliente mais que negociação de contratos Responder a mudanças mais que seguir um plano Ou seja, mesmo havendo valor nos itens à direita, valorizamos mais os itens à esquerda.
Esta declaração foi complementada pela organização Agile Alliance com os
“Princípios por trás do manifesto ágil”, encontrados em
http://www.manifestoagil.com.br/principios.html:
Nós seguimos os seguintes princípios: Nossa maior prioridade é satisfazer o cliente, através da entrega adiantada e contínua de software de valor. Aceitar mudanças de requisitos, mesmo no fim do desenvolvimento. Processos ágeis se adequam a mudanças, para que o cliente possa tirar vantagens competitivas. Entregar software funcionando com frequência, na escala de semanas até meses, com preferência aos períodos mais curtos. Pessoas relacionadas à negócios e desenvolvedores devem trabalhar em conjunto e diariamente, durante todo o curso do projeto. Construir projetos ao redor de indivíduos motivados. Dando a eles o ambiente e suporte necessário, e confiar que farão seu trabalho. O Método mais eficiente e eficaz de transmitir informações para, e por dentro de um time de desenvolvimento, é através de uma conversa cara a cara. Software funcional é a medida primária de progresso. Processos ágeis promovem um ambiente sustentável. Os patrocinadores, desenvolvedores e usuários, devem ser capazes de manter indefinidamente, passos constantes. Contínua atenção à excelência técnica e bom design, aumenta a agilidade. Simplicidade: a arte de maximizar a quantidade de trabalho que não precisou ser feito. As melhores arquiteturas, requisitos e designs emergem de times auto organizáveis. Em intervalos regulares, o time reflete em como ficar mais efetivo, então, se ajustam e otimizam seu comportamento de acordo”.
2.5.2.2 Considerações Gerais
[PRESSMAN] qualifica o movimento ágil como uma mudança revolucionária
em relação aos métodos tradicionais, baseados em planos ou prescritivos. Foi o
resultado de uma evolução de ideias que já vinham sendo consideradas para tentar
solucionar os problemas enfrentados com os processos anteriores.
O manifesto ágil, seguido por todas as formulações de metodologias e
práticas, veio como proposta de uma forma melhor de atender às necessidades das
organizações.
[SOMMERVILLE] destaca o ambiente global de negócios, caracterizado por
mudanças rápidas, muitas delas justamente causadas pela rápida e fortíssima
33
influência da tecnologia da informação sobre a cadeia de valor dos negócios e as
forças competitivas do modelo de Porter, conforme apresentado por [JOIA].
É vital se ter rapidez e flexibilidade para aproveitar oportunidades e mercados
emergentes, reagir a efeitos macroeconômicos e enfrentar novos produtos e
serviços concorrentes. Dada a grande dependência de softwares, desenvolvimento,
alteração e entrega rápidos se tornam críticos para permitir resposta a um ambiente
de negócios fluido.
Os métodos tradicionais, com suas características formais e sequenciais,
baseiam-se em definir no início um conjunto completo e estável de requisitos.
Apresentam tempo de entrega relativamente longo e baixa flexibilidade para
alterações solicitadas após as fases iniciais, cuja ocorrência hoje se tornou quase
que uma certeza.
[SOMMERVILLE] comenta que isto leva muitas empresas a buscar uma
implantação mais rápida do software de que necessitam, estando para isso
dispostas a abrir mão de formalização e alguns aspectos de controle, adotando,
portanto, os métodos ágeis. Nestes, como a execução e o planejamento são
gradativos, ocorrem entregas parciais antecipadas e há maior facilidade para
alterações atendendo mudanças necessárias que surjam em meio ao ciclo de
desenvolvimento.
A aplicação plena dos métodos ágeis requer algumas condições cuja
concretização pode ser desafiadora, das quais destaca-se (SOMMERVILLE, 2011):
• Resistência encontrada nas empresas onde o histórico de cultura
gerou processos formais e rígidos, orientados a planos, onde se busca
controle e estabilidade acima de tudo.
o Um exemplo são os processos de Gerência de Mudanças e de
Testes, que evoluíram ao longo do tempo visando maximizar
estabilidade e confiabilidade, e podem ser um obstáculo aos
métodos ágeis.
o Mudar a cultura pode ser um processo demorado, que pode até
requerer mudança de gerenciamento, e forte investimento em
evangelização. Isso é evidenciado particularmente em grandes
empresas, onde os métodos ágeis encontram maiores
dificuldades de introdução.
• Dificuldade de conseguir a presença do cliente junto à equipe de
desenvolvimento, em especial quando houver múltiplos stakeholders
que precisem ter representantes.
o Este fator pode gerar também conflitos na priorização dos itens
a serem atendidos considerando as necessidades das diferentes
áreas.
34
• Características pessoais de integrantes da equipe de desenvolvimento,
que gerem dificuldade para o tipo de contato constante, inclusive com o
cliente, requerido pelo método ágil. [PRESSMAN] dedica todo um
capítulo aos aspectos humanos na engenharia de software,
ressaltando que na verdade são as pessoas que produzem o resultado
final a ser entregue. Equipes ágeis, pela natureza da forma de trabalho,
requerem pessoas adaptadas a interação, aprendizado, colaboração e
mudanças.
• Complexidade de gestão de fornecedores externos em contratos com
escopo e requisitos que podem mudar ao longo da execução.
2.5.2.3 Desafios dos grandes projetos e sistemas
Um ponto que merece destaque são os grandes projetos de software:
grandes sistemas exigem equipes de desenvolvimento muito maiores, onde a
aplicação pura de métodos ágeis não é viável. O aumento exponencial do volume
de interações entre os componentes, impõe desafios ao se tentar tratá-los no
modelo ágil.
O desafio é normalmente enfrentado através de subdivisão em equipes
menores, com a consequente necessidade de um esforço maior de coordenação de
atividades e integração
Observações interessantes sobre este ponto podem ser encontradas em
[MOORE], que se baseou em observação empírica em um grande projeto com
centenas de pessoas distribuídas em dezenas de equipes, e também em
[LEFFINGWELL], que trata de adaptações para uso dos métodos ágeis em grandes
iniciativas. Alguns pontos destacados são:
• Importância de ter pessoas com perfil certo nas equipes ágeis
• Manter os fundamentos dos métodos ágeis
o Planejamento flexível
o Releases frequentes
o Integração contínua (detalhes adiante)
o Desenvolvimento dirigido a testes (detalhes adiante)
o Qualidade de comunicação nas equipes
• Adaptações recomendadas:
o Para o desenvolvimento de sistemas de grande porte, não é
possível focar apenas no código do sistema
o Maior planejamento inicial - projeto, arquitetura, documentação
essencial, divisão de trabalho – que atenda o escopo previsto e
ao mesmo tempo conte com elementos de flexibilidade para
acomodar as inevitáveis mudanças necessárias.
35
o Estabelecer mecanismos de comunicação eficientes entre as
equipes, para que se mantenham atualizadas sobre o progresso
de cada uma.
o Se não for possível a integração contínua, ter construções
frequentes e releases regulares. Normalmente requer
ferramentas de gerenciamento de configuração.
2.5.2.4 Observações da aplicação na prática
Os métodos ágeis vêm sendo utilizados de forma crescente em empresas de
todos os portes, já existindo uma vasta coleção de observações de resultados
auferidos na prática.
Nas empresas de menor porte e mesmo em muitas de porte médio, os
resultados têm sido excelentes.
Como colocado por [SOMMERVILLE], essas empresas não apresentam
grandes estruturas burocráticas que imponham processos rígidos, podendo se
adaptar e adotar novas ideias com facilidades. Startups são terreno altamente fértil
para uso de métodos ágeis, sendo o grande desafio de gestão mantê-los em pleno
funcionamento quando o sucesso leva a um grande crescimento organizacional.
Nas empresas de maior porte, os desafios que já foram comentados têm
levado a maior heterogeneidade de resultados. [SOMMERVILLE] chega a comentar
ter conhecimento de poucas grandes empresas que já tivessem conseguido efetuar
a transição com sucesso para desenvolvimento ágil em toda a organização.
A abordagem metodológica mais apropriada varia de acordo com o tipo de
software e, podemos acrescentar, a organização envolvida. Um equilíbrio entre
processos dirigidos a planos e processos ágeis precisa ser encontrado. Sistemas
críticos podem exigir um processo muito bem estruturado, enquanto sistemas de
suporte a negócios, com requisitos que se alteram rapidamente, podem se beneficiar
da menor formalidade e flexibilidade inerentes aos métodos ágeis.
Atualmente o desenvolvimento de aplicativos vem sendo feito
predominantemente de forma incremental, seja na forma dirigida a planos, seja na
forma ágil, seja mesclando essas abordagens, sendo que esta última vem se
tornando a situação mais comum segundo [SOMMERVILLE].
2.5.2.5 Manutenção e Evolução de Software Ágil
A maioria da teoria encontrada sobre métodos ágeis e os relatos de
experiências com eles está ligada a projetos de desenvolvimento de novos sistemas.
Mas como já mencionamos o volume de recursos requeridos para manutenção e
evolução é superior aos usados para desenvolver novo software, numa relação da
ordem de 2:1 ou até superior.
36
Claramente devemos utilizar processos de engenharia de software que
assegurem maior eficiência para a manutenção e evolução de sistemas já
existentes. [SOMMERVILLE] reporta que o volume de relatos de experiências com o
uso de métodos ágeis na manutenção de software é pequeno, e nos coloca duas
questões pertinentes nesse campo:
• A manutenção de sistemas desenvolvidos em uma abordagem ágil
pode ser feita de forma eficiente, já que no processo de
desenvolvimento ocorre minimização da documentação formal?
• O uso de métodos ágeis para a evolução de um sistema conforme
solicitações de mudança do cliente é adequado?
Não existem respostas fáceis para essas questões, porém têm sido
observadas situações de sucesso, principalmente em cenários híbridos, partindo de
desenvolvimentos que usaram práticas dirigidas a planos, com ou sem mescla de
práticas ágeis, seguidas de evolução conduzida em práticas alinhadas aos princípios
ágeis, às quais são sobrepostos conceitos de processos tradicionais.
Fatores de sucesso apontados são (SOMMERVILLE, 2011):
• Manter o envolvimento e interesse do cliente, de forma a contar com a
participação do mesmo nos pontos críticos do processo.
• Manter sempre que possível a maior parte da equipe de
desenvolvimento, de forma a ter compreensão do sistema sem
necessidade de documentação.
2.5.2.6 Modelos de Processos Ágeis
Existe na teoria diversos modelos de processos ágeis, que podem ser
aplicados em múltiplas variações de acordo com as necessidades e características
de cada empresa.
Analisando essa diversidade, [PRESS] nos coloca os pesos atribuídos a cada
um dos 12 princípios sofrem variações de um para outro, sendo que alguns modelos
ignoram um ou mais desses princípios. Mas todos eles mantêm o “espírito ágil” que
norteou a definição dos mesmos.
A seguir são apresentados alguns dos modelos mais aplicados, que são
Extreme Programming (XP) e SCRUM. Cada um deles prevê a aplicação de
ferramentas técnicas e processos de trabalho que serão simplesmente elencados,
ficando para maiores detalhes em seção posterior.
37
2.5.2.6.1 Extreme Programming - XP
Conforme [PRESSMAN], XP é a abordagem mais utilizada para
desenvolvimento de software ágil. O processo XP prevê a execução cíclica de
quatro atividades, com algumas tarefas-chave associadas a cada uma,
representadas na figura 7, que é adaptada da mesma fonte. Ao final de cada ciclo
tem-se um incremento de software, ou seja, uma nova versão que pode ser entregue
para uso do negócio.
Figura 7: Extreme Programming
Fonte: Adaptado de PRESSMAN, 2016
2.5.2.6.1.1 Planejamento
Efetuado de forma incremental, envolve as atividades de levantamento de
requisitos, que são convertidos em um conjunto de histórias de usuário. Cada
história é escrita pelo cliente, gerando uma ficha ou cartão de história, e inclui a
funcionalidade e os resultados desejados, bem como os critérios de aceitação e o
valor, ou seja, a relevância para o negócio. A equipe de desenvolvimento avalia
cada história e atribui um custo que representa o esforço de desenvolvimento.
Histórias com custos acima de um limite estabelecido são devolvidas ao cliente para
subdivisão e cada uma das resultantes é avaliada novamente (PRESSMAN, 2016).
No planejamento do próximo incremento (versão de software) clientes e
desenvolvedores selecionam as histórias a serem incluídas para entrega na data
38
estabelecida. Na priorização das histórias podem ser aplicados critérios baseados
em valor, risco ou combinações de ambos. Na sequência, os desenvolvedores
dividem essas histórias em tarefas a serem executadas.
O planejamento é feito de forma constante e incremental ao longo de todo o
desenvolvimento. O cliente pode criar novas histórias, alterar, dividir ou eliminar
algumas das já existentes, mudar o valor atribuído a elas, ou seja, a mudança é
assumida como inerente ao processo.
O primeiro release é criado de forma a entregar um conjunto mínimo de
funcionalidades que fornece o valor ao negócio. Seguem-se entregas frequentes de
novos releases de software, adicionando funcionalidades.
2.5.2.6.1.2 Projeto
Busca-se que o projeto seja o mais simples possível, sendo realizado para
atender aos requisitos contidos na história, sem nenhum acréscimo que o
desenvolvedor imagine que venha a ser necessário no futuro (PRESSMAN, 2018).
Sendo normalmente voltado para orientação a objetos o XP estimula o uso de
cartões CRC (classe-responsabilidade-colaborador), que são o único tipo de artefato
incluído neste modelo.
Protótipos são utilizados para avaliação antecipada de soluções pontuais e
prevenção de riscos de implementações incorretas por falha de entendimento e
requisitos incompletos ou dúbios.
2.5.2.6.1.3 Codificação
O desenvolvimento em XP aplica o conceito TDD – Test Driven Development,
ou seja, os testes para uma nova funcionalidade são escritos antes do código que irá
implementar a mesma, tendo como base os critérios de aceitação definidos nas
histórias de usuário. Isso permite que o desenvolvedor foque exatamente no que
deverá ser implementado para “passar” nos testes (PRESSMAN, 2018).
A refatoração (refactoring) do código por todos os desenvolvedores é
estimulada de forma a continuamente aperfeiçoá-lo e preservar a simplicidade e
manutenibilidade durante a execução das mudanças feitas para atender a evolução
dos requisitos. Isso significa que o projeto continua a evoluir ao longo do ciclo de
desenvolvimento.
A programação em pares (pair programming) é recomendada, com os
desenvolvedores trabalham em duplas numa mesma estação de trabalho para criar
o código.
39
A propriedade coletiva também é recomendada, com os desenvolvedores
trabalhando em todas as áreas do sistema, evitando a geração de áreas de
especialização. Todos devem assumir responsabilidades pelo código no seu total, e
qualquer um pode mudar qualquer coisa.
A integração contínua (continuous integration) deve ser aplicada: a cada
tarefa concluída, o resultado é integrado ao todo, e todos os testes de unidade do
sistema devem ser aplicados (continuous testing).
2.5.2.6.1.4 Teste
O XP é fortemente alicerçado em práticas de teste, como uma forma de
identificar erros, inclusive colaterais, que podem ser introduzidos durante a evolução
ou manutenção de softwares (PRESSMAN, 2016).
Usualmente os testes de unidade são escritos sob um framework de testes
automatizados que permitirá executar teste de regressão completo, aplicando todos
eles rapidamente e com baixo custo a cada construção gerada quando o código for
alterado ou refatorado, identificando eventuais problemas em tempo hábil para
correção.
Já os testes de aceitação, tem foco nas funcionalidades e características
visíveis pelo cliente e são executados por ele. São derivados do elenco de histórias
de usuário que foram implementadas na versão de software gerada.
Na descrição das atividades do XP, foram mencionadas algumas técnicas
que, embora não sejam exclusivas de processos ágeis, são previstas nos mesmos
ou apresentam grande frequência de utilização na prática. Estas técnicas foram
sublinhadas no texto de forma a serem destacadas. Definições dessas técnicas são
apresentadas em seções seguintes.
[SOMMERVILLE] coloca que muitas empresas que adotam XP não usam
todas as práticas previstas, adaptando-as à sua organização. Por exemplo, algumas
empresas substituem a programação em pares pela programação individual seguida
de revisões; outras limitam o escopo de refatoração que cada programador pode
fazer; algumas utilizam padrões convencionais de representação de requisitos
convencionais em vez de histórias de usuários. Alguns pontos, no entanto, são
quase que universais: desenvolvimento orientado a testes, integração contínua e
liberação de releases de pequeno porte.
Finalizando, existem definições de práticas que visam adequar o XP a
grandes sistemas, gerando o chamado IXP – Industrial Extreme Programming.
Maiores detalhes podem ser obtidos em http://industrialxp.org, de onde foi obtida a
figura 8, que apresenta os conceitos, práticas e técnicas envolvidos nesta definição.
Podemos observar que os princípios básicos do XP são mantidos, havendo, entre
outras mudanças, um acréscimo de funções de gestão e controle.
40
Figura 8: Industrial XP
Fonte: Disponível em: http://industrialxp.org, 2019. Acesso em: 3 jan. 2019.
2.5.2.6.2 SCRUM
Conforme a definição apresentada em [SCRUM], SCRUM é “Uma Forma
Melhor de Criar Produtos”, apresentado na forma de uma “estrutura através da qual
podem ser tratados problemas adaptativos complexos, entregando produtiva e
criativamente produtos do mais alto valor possível”. Uma colocação importante é que
SCRUM não se restringe ao desenvolvimento de software, podendo ser aplicado ao
ciclo de criação de qualquer produto complexo.
O site referenciado oferece vasta disponibilidade de material e detalhes a
respeito do SCRUM. No entanto, ele pode ser entendido de forma bastante
abrangente apenas com o conciso conteúdo do “The Scrum Guide”, disponível para
download no mesmo site.
SCRUM propõe um processo de aprendizado e evolução baseado em
respeito às pessoas e auto-organização para tratar requisitos mutáveis e resolver
problemas complexos. Não é considerada uma metodologia, e sua aplicação é
coerente com o manifesto ágil e os princípios derivados do mesmo (SCRUM.org,
2019).
Baseia-se num processo cíclico de desenvolvimento incremental, entregando
a cada iteração (denominada Sprint) uma nova versão (Incremento) de software,
contendo funcionalidades adicionais.
41
As funcionalidades (apresentadas normalmente na forma de histórias de
usuário), são selecionadas de uma lista de itens pendentes (Product Backlog) que é
mantida, priorizada e detalhada (refinada) pelo representante do cliente (Product
Owner), e implementadas pelo Time de Desenvolvimento, que deve contar
internamente com todas as competências necessárias para executar o trabalho, no
caso construir um incremento de software utilizável, sem depender de recursos
externos [SCRUM, 2019].
A correta execução das práticas SCRUM na organização é conduzida e
apoiada pelo SCRUM Master.
A duração de todas as Sprints é igual e definida logo no início do projeto.
Os itens do Product Backlog, seguindo a ordem de prioridade definida pelo
Product Owner, são discutidos e avaliados em uma reunião de planejamento –
Sprint Planning (SCRUM.org, 2019).
Nesta reunião, a partir das definições detalhadas de cada história resultantes
do processo de refinamento (grooming) efetuado junto com o Product Owner, o Time
de Desenvolvimento avalia o custo (esforço) de cada uma e sua capacidade de
execução, comprometendo-se com o escopo a ser entregue na Sprint (Sprint
Backlog), constituído por um subconjunto do Product Backlog.
Durante a Sprint, são realizadas diariamente reuniões de curta duração (até
15 minutos), denominadas daily meetings. Nelas ocorre a troca de informações,
compartilhamento de dificuldades e descobertas e avanços realizados e planejados.
Eventuais desvios do planejado e alterações de itens no escopo da Sprint podem ser
negociados com o Product Owner durante a mesma.
Ao final da Sprint, o incremento de software resultante é apresentado ao
Product Owner e eventuais representantes dos clientes que o mesmo considere
adequado, numa reunião denominada Sprint Review (SCRUM.org, 2019).
A Sprint é encerrada com a Sprint Retrospective, reunião onde os membros
do time SCRUM - SCRUM Master, Time de Desenvolvimento e Product Owner –
avaliam as ocorrências durante a Sprint, os pontos positivos e negativos
observados, e definem melhorias adaptativas do processo para a próxima Sprint,
que se inicia imediatamente após.
Na descrição são mencionados papéis, artefatos e eventos descritos no já
referenciado “The SCRUM Guide”. A figura 9 apresenta o ciclo do SCRUM.
Projetos onde SCRUM é aplicado utilizam fortemente práticas ágeis. Seus
conceitos refletem muito do XP, ou vice-versa, sendo muito frequente o uso
conjunto.
42
Figura 9: SCRUM Framework
Fonte: Disponível em: https://www.scrum.org/resources/what-is-scrum, 2019. Acesso em: 3 fev. 2019.
2.6 Práticas e Técnicas
Um grande número de práticas e técnicas vem sendo aplicado nos processos
de engenharia de software. Embora sua popularização esteja em muitos casos
ligada à dos métodos ágeis, várias delas podem ser usados também em conjunto
com processos dirigidos a planos. Nesta seção são apresentadas de forma sucinta
algumas delas.
2.6.1 Histórias de usuário (user stories)
São descrições informais em linguagem comum de um ou mais recursos a
serem implementados em um software, escritas pelo ponto de vista de um usuário
do sistema usando linguagem de negócios ou cotidiana para descrever as
funcionalidades desejadas. São tipicamente usados formatos semelhantes a
(SCRUMHALF, 2019):
“Como <papel ou função do usuário> eu quero <ação ou funcionalidade> para
<resultado ou benefício desejado>”
São usadas em metodologias ágeis como ponto de partida para definir o
escopo e identificar os requisitos, facilitando a comunicação e o entendimento entre
todos os envolvidos.
43
2.6.2 Desenvolvimento Orientado a Testes (Test Driven Development)
[PRESSMAN] cita a definição de Rebecca Wirfs-Brock, de que no Test Driven
Development (TDD) a definição do teste é criada antes do desenvolvimento do
código ao qual o mesmo será aplicado. Os desenvolvedores então trabalham para
gerar código que implemente o necessário para passar no teste.
Esta é uma das técnicas mais importantes para o sucesso dos métodos ágeis,
beneficiando desde o desenvolvimento até a entrega e manutenção de uma solução
de software, e viabilizando as entregas em intervalos menores.
A execução dos testes criados é feita usando um ambiente automatizado.
Cada novo teste é acrescentado ao conjunto de testes previamente existente, que é
executado a cada implementação efetuada no código, permitindo identificar
rapidamente (SOMMERVILLE, 2011):
• Se a implementação do requisito foi feita corretamente
• Se foram introduzidos erros devido a efeitos colaterais resultantes da
mudança no código.
[SOMMERVILLE] coloca como forte argumento para uso de TDD o fato de
ajudar os desenvolvedores a entender o que o novo código deve fazer, facilitando
sua criação. Entre outros benefícios adicionais tem-se:
• Erros são rapidamente detectados, reduzindo o custo de tratá-los. A
depuração é também simplificada, pois após detectado um erro que
não existia antes, basta analisar a parte do código que foi acrescida ou
modificada.
• Todo código gerado tem pelo menos um teste associado, portanto é
executado pelo menos uma vez a cada passagem do conjunto de
testes do sistema.
• Os próprios testes podem ser usados como documentação do sistema,
reduzindo ou até eliminando necessidade de documentação adicional.
• O conjunto de testes do sistema, construído de forma incremental a
cada desenvolvimento de código, está sempre disponível para
execução de testes completos de regressão. Isso quando combinado
com a automatização permite a execução destes testes com
rapidamente e com baixo custo, o que é relevante para identificar erros
gerados por efeitos colaterais nocivos de uma modificação do código
do sistema.
44
2.6.3 Programação em pares - Pair Programming
Consiste em ter os desenvolvedores trabalhando em duplas, usando uma
única estação de trabalho, para criar o código para atender uma história. Essa
colaboração melhora a qualidade das soluções criadas, pela combinação das ideias
de duas pessoas, garante revisão do código em tempo real e ajuda a manter o foco
dos desenvolvedores no que deve ser criado. Dentro da dupla pode haver uma
separação dinâmica de papéis a cada situação (PRESSMAN, 2016).
Esta prática é uma das mais reforçadas no XP, que inclui ainda
recomendação para mudar a composição das duplas ao longo do desenvolvimento
do software, gerando intercâmbio de experiências.
2.6.4 Integração Contínua – Continuous Integration
Consiste em efetuar a construção (build) de uma nova versão do sistema
executável com a maior frequência possível, sendo o objetivo ‘perfeito’ ter isso
ocorrendo a cada código finalizado pelos desenvolvedores e liberado para uso.
Limitantes na prática são o tamanho do sistema, que pode exigir tempos longos para
a construção, e a quantidade de liberações, que pode gerar a execução de uma
construção com frequência excessivamente alta. A solução nesses casos é efetuar a
integração em periodicidade definida, como por exemplo diário (SOMMERVILLE,
2011).
A integração pode ocorrer de forma automática, usando ferramentas
especializadas para tal, ou manual, que vem se tornando menos frequente.
A integração contínua está fortemente ligada ao conceito seguinte, teste
contínuo, podendo ser vista como o passo anterior a ele numa instalação de
desenvolvimento onde ocorram na forma automatizada. Na prática, a integração dos
dois conceitos é tão forte que alguns autores os tratam como um único passo.
2.6.5 Teste Contínuo – Continuous Testing
Os frameworks de testes automatizados permitem aplicar com baixo custo o
conjunto de testes definidos nos mesmos a cada construção (build) gerado por um
processo de integração contínua.
Aqui se potencializa a vantagem do TDD, pois uma regressão com todos os
testes é aplicada à nova versão do sistema. Eventuais erros que apareçam podem
ser mais rápida e facilmente relacionados às mudanças efetuadas no código a partir
da versão anterior, facilitando a solução dos mesmos.
45
2.6.6 Entrega Contínua – Continuous Delivery
Na forma mais direta, pode ser definida como o atendimento ao já visto
terceiro princípio ágil:
“Entregar software funcionando com frequência, na escala de semanas até
meses, com preferência aos períodos mais curtos” (MANIFESTO_AGIL, 2019).
Este resultado é viabilizado por todos os processos e técnicas envolvidos,
como os que vimos até agora, que registram requisitos, produzem código, efetuam
testes e geram versões do sistema ‘prontas’ para uso em ciclos menores.
2.6.7 DevOps
Os conceitos de DevOps apresentam variações de acordo com o teórico ou
organização que os apresenta, mas todos mantém um núcleo comum. A definição
aqui apresentada se baseia em [GUCKENHEIMER], que inicia com:
DevOps é a união de pessoas, processos e produtos para viabilizar a entrega
contínua de valor a nossos usuários finais. A contração de “Dev” e “Ops” se refere a
substituir o Desenvolvimento e Operações como silos para criar equipes
multidisciplinares que agora trabalham em conjunto com práticas e ferramentas
compartilhadas e eficientes. Práticas DevOps essenciais incluem planejamento ágil,
integração contínua, entrega contínua e monitoramento de aplicativos.
A figura 10 mostra o conceito de DevOps de um ciclo que se repete a cada
versão a ser entregue aos clientes.
Figura 10: Ciclo DevOps
Fonte: GUCKENHEIMER, 2019
46
Pode-se abordar DevOps como um processo que estende a Entrega
Contínua, aliando a geração rápida de uma versão do sistema pronta para uso com
as atividades de entrega da mesma no ambiente final de usuário.
Alguns dos conceitos interessantes que são apresentados no artigo são:
• Monitoração e Registro de dados das aplicações em produção para
gerar informações sobre estado das mesmas, uso pelos clientes, que
podem ser usados para validar e direcionar estratégias.
• Uso de Nuvem, seja ela Pública ou Privada, como forma de eliminar
restrições de infraestrutura (enfoque IaaS – Infrastructure as a Service)
ou dispor de ferramentas de produtividade inovadores (usando PaaS –
Plataform as a Service).
• Infraestrutura como Código (IaC – Infrastructure as Code), que
automatiza também o processo de criação, alteração e remoção de
ambientes de hospedagem de aplicações. Scripts de instruções e
configurações são criados e executados para ‘instalar’ o ambiente de
operação do sistema.
2.6.8 Revisões Técnicas
De acordo com [PRESSMAN], revisões técnicas são o mecanismo mais
eficaz para identificar erros logo no início da gestão de qualidade. Descobrir erros
com a máxima antecedência é chave para reduzir custos com softwares, conforme
detalhado adiante, por isso a aplicação de revisões é uma forma eficiente de atingir
esse objetivo.
As revisões podem ser feitas desde o início do processo de software,
avaliando os artefatos do sistema à medida que vão sendo concluídos. Eventuais
ajustes são feitos com antecedência, assegurando custos menores para todo o
processo.
Revisões verificam a qualidade dos entregáveis de projeto, incluindo o
software construído, o código e a documentação e registros do processo. São
realizadas por engenheiros de software, que são pares de quem desenvolveu o
código. De acordo com a situação e disponibilidade de recursos, pode ser criada
uma equipe específica para efetuar as revisões.
Uma revisão pode se basear nos requisitos registrados, nos padrões de
qualidade, processos, documentação e codificação, mas se apoia também na
experiência dos executores. Pode, por exemplo, indicar a falta de algum requisito
importante, funcional ou não funcional, sugerir melhorias na modelagem ou até
indicar possibilidades de reaproveitamento ou adaptação de componentes já
existentes (SOMMERVILLE, 2011).
47
Uma boa prática para maior eficiência na execução de revisões é a utilização
de listas de verificação (check lists) que contém perguntas e pontos a serem
observados a cada tipo de artefato revisto.
Outra prática comum dados os custos e a impossibilidade de efetuar revisões
completas é a abordagem por amostragem, onde se busca verificar os artefatos
mais suscetíveis a erros ou aqueles onde os erros possam gerar consequências
mais graves. [PRESSMAN] menciona a aplicação de métodos estatísticos para
identificação e seleção dos artefatos que serão objeto de revisões.
As conclusões das revisões são documentadas ao nível adequado à situação,
sendo eventuais ações decorrentes executadas pelo responsável por corrigir erros
ou omissões.
[PRESSMAN] define 3 tipos de revisões, descritos resumidamente na tabela
6.
Tipo de Revisão Descrição
Informal
A mais simples de todas, efetuada sem planejamento formal,
envolvendo normalmente duas pessoas.
Pode ser um simples teste de mesa, a inspeção de um artefato, uma
reunião informal. É inerente à programação em pares já vista, onde
ocorre ao longo de todo o desenvolvimento. Listas de verificação
podem ser criadas para melhorar a eficiência deste tipo de revisão.
Walkthrough
Revisão formal em forma de reunião, planejada e preparada
previamente.
Envolve mais pessoas ([PRESSMAN] cita de 3 a 5), seguindo uma
agenda que normalmente se inicia com uma apresentação feita pelo
criador do artefato a ser revisto.
Existe registro formal dos resultados e seguimento das ações
definidas ao final da reunião.
Inspeções
Revisão também formal, que segue um processo bem definido.
Segundo [SOMMERVILLE], embora o foco principal seja o código-
fonte do sistema, podem abranger também outras formas de
representação e seus artefatos, como por exemplo, modelos de
projeto.
É fortemente baseada em conhecimentos dos revisores: do sistema,
do domínio da aplicação, da linguagem utilizada na programação e
do processo de modelagem.
Tabela 6: Tipos de revisão de software
Fonte: PRESSMAN, 2016
48
Um aspecto importante, realçado pelos autores consultados, é que revisões
visam melhorar a qualidade de software e o desempenho de pessoas na equipe de
desenvolvimento.
Devido à exposição gerada pelo processo, os envolvidos podem criar
barreiras e receios. É fundamental que os gestores e líderes estejam atentos a esse
aspecto, garantindo que revisões sejam efetuadas e encaradas de forma construtiva.
No entanto, as inspeções não podem substituir os testes de software. As
inspeções não são boas para descobrir defeitos que surgem devido a interações
inesperadas entre diferentes partes de um programa, problemas de timing ou com o
desempenho do sistema. Além disso, pode ser difícil e caro montar uma equipe de
inspeção, especialmente em pequenas empresas ou grupos de desenvolvimento.
2.6.9 Refatoração
Esta prática é muito recomendada nas metodologias ágeis, mas está limitada
a estas. Consiste em mudar o código do software para atingir melhor organização,
mas sem alterar o comportamento externo. Permite também enfrentar a degradação
causada por sucessivas mudanças de um sistema ao longo do tempo, que já foi
mencionada.
[PRESSMAN] cita como exemplos de ações em uma refatoração:
• Identificação de redundâncias
• Eliminação de elementos não utilizados
• Melhoria ou remoção de algoritmos
• Identificação de não conformidades com requisitos ou modelagem
• Falhas de projeto
• Divisão de componentes de forma a obter menor coesão
Na prática, cuidados devem ser sempre adotados, pois a refatoração de
código pode causar efeitos colaterais involuntários que acabem por alterar o
comportamento externo. Isso pode ocorrer, por exemplo, em processos ágeis onde
todos tenham autorização para alterar qualquer parte do sistema.
Um conjunto de testes automatizados robusto ajuda a mitigar este problema.
[PRESSMAN] cita que já existem ferramentas de refatoração que analisam
automaticamente as alterações efetuadas e geram testes relacionados a mudanças
de comportamento.
49
2.7 Sobre Requisitos, Análise e Projeto
Ao longo deste trabalho são feitas muitas referências a estes pontos comuns
e extremamente importantes em todo processo de software, seja qual forem os
métodos, técnicas ou práticas utilizadas.
Na verdade, as fontes consultadas ressaltam que, para reduzir os custos
envolvidos em correção e impacto sobre os negócios, deve-se buscar identificar
desvios, erros e defeitos com máxima antecedência possível.
A figura 11, adaptada a partir de imagens similares encontrados nas fontes
pesquisadas, representa a evolução dos referidos custos ao longo do ciclo de
desenvolvimento do software, enfatizando a necessidade de uma abordagem de
busca de qualidade desde as fases iniciais.
Figura 11: Evolução dos custos de correção de erros
Fonte: Adaptada de PRESSMAN, 2016
Estudo citado em [PRESSMAN] aponta para um fator multiplicativo dos custos
cujo valor pode superar 100 ou mais quando comparamos custo de correção durante
a fase de requisitos com custo de correção já na fase de manutenção, crescendo a
cada etapa do ciclo de desenvolvimento. A tabela 7 sumariza os resultados desse
estudo.
50
Fase Custo de correção de 1 erro
Requisitos 139
Projeto 455
Codificação 977
Teste 7.136
Manutenção 14.102
Tabela 7: Evolução dos custos de correção
Fonte: PRESSMAN, 2016
A situação prática abordada neste trabalho apresenta como característica a
existência de um grande ativo em produtos já desenvolvidos e evoluídos em alguns
casos por mais de 10 anos, estando, portanto, já bem avançados na fase de
manutenção em produção.
Em consequência deste cenário, não será possível tratar as fases anteriores
já decorridas na aplicação dos fundamentos teóricos aqui apresentados à situação
prática observada.
Não serão, portanto, incluídos neste trabalho detalhes sobre as fases de
Requisitos, Análise e Projetos, o que não significa que as mesmas não sejam
extremamente importantes. Caso se deseje maior aprofundamento a respeito
recomenda-se consultar as fontes de referência, em especial [PRESSMAN] e
[SOMMERVILLE].
2.8 Gestão da Qualidade
Pode-se definir gestão da qualidade de software como um conjunto de
atividades, processos de engenharia software e controles aplicados ao longo das
fases do mesmo, que visa garantir que os produtos de software apresentam alta
qualidade. Esse conjunto recebe o nome de Garantia de Qualidade de Software.
[SOMMERVILLE] coloca que há diferentes formas de entender a Garantia de
Qualidade de Software. Para algumas organizações compreende apenas a definição
de procedimentos, processos e padrões que visam reforçar que a qualidade de
software seja atingida, enquanto que em outras abrange todas as atividades que
possam impactar a qualidade do software entregue aos usuários. Podemos citar
validação, verificação e testes, gestão de mudanças e gestão de configuração.
51
A definição de qualidade, conforme já vimos, pode compreender múltiplos
aspectos e formatos. Deve ser claramente formulada de acordo com as práticas de
organização, e documentada de forma a ser entendida por cada um dos envolvidos
no processo de software.
Todos devem ser responsáveis por ela, e não apenas os responsáveis pela
execução de testes. Como já vimos anteriormente, a busca pela qualidade deve
permear todo o processo; assegurar a qualidade desde o levantamento de
Requisitos permite reduzir significativamente os custos de correção de erros e os
impactos negativos decorrentes da ocorrência de defeitos ante o usuário final.
Exemplos de atividades de Garantia de Qualidade de Software são
apresentados em [PRESSMAN]:
• Elaboração de um Plano de Garantia de Qualidade de Software,
definindo a estratégia a ser adotada pela equipe
• Revisões técnicas durante a modelagem e codificação
• Elaboração de plano e definição do conjunto de testes de software
• Execução dos testes e organização dos resultados dos mesmos
Faz parte de um processo bem estabelecido de qualidade ainda, a coleta de
métricas e a avaliação contínua das mesmas, incluindo a aplicação de métodos
estatísticos, possibilitando identificar pontos de melhoria no processo de software.
2.8.1 Custo da Qualidade e Custo da Falta da Qualidade
Qualidade de software não é um objetivo simples, e para obtê-la há
necessidade de investimento de recursos e de tempo, muitas vezes de grandeza
significativa em relação ao total envolvido no processo de software (PRESSMAN,
2016).
Este fato pode gerar uma tendência a reduzi-los, para obter resultados mais
rapidamente e com menores custos iniciais, adiando as consequências para o
futuro. A contrapartida, conforme já visto, é o crescimento dos custos de tratamento
de erros: quando se deixa de investir em qualidade desde o início do processo, gera-
se um ônus futuro muito superior à economia efetuada.
Este não é, no entanto, o único custo que advém da falta de qualidade do
software, ainda que seja mais simples de mensurar. Estão envolvidos
(SOMMERVILLE, 2011):
• redução de produtividade, pela necessidade de realocar recursos para
correção que comprometem as atividades planejadas e em execução
• necessidade de retrabalho, pois além de tudo a correção rápida que
se faz necessária não é a melhor alternativa e pode gerar novos erros
ou necessidade de futura revisão e refatoração
52
• queda da percepção de qualidade dos produtos e serviços, e
consequente redução da satisfação dos usuários, que pode levar até a
perda de clientes
As múltiplas consequências e custos da falta de qualidade ao longo do
processo de desenvolvimento de software são abordadas em [PRESSMAN], que as
classifica e exemplifica conforme a tabela 8:
Fase Atividades Executadas
Prevenção
Gestão para planejamento e coordenação das atividades de controle e garantia da qualidade
Atividades adicionais para desenvolver modelos completos de requisitos e de projeto
Planejamento de testes
Treinamento para execução dessas atividades
Avaliação
Revisões técnicas
Criação dos artefatos de engenharia de software
Testes e depuração
Falhas
Ocorridas
Internas
(antes da entrega ao usuário)
Correção de erros
Efeitos colaterais da correção
Avaliação de falhas
Externas
(após a entrega ao usuário)
Solução de reclamações
Devolução e substituição de produtos
Suporte pelos canais de atendimento
Garantia do produto
Danos à reputação e perda de vendas
Tabela 8: Custos da qualidade e sua falta
Fonte: PRESSMAN, 2016
2.8.2 Métricas
A busca por critérios objetivos que forneçam medidas precisas sobre a
qualidade de software enfrenta as dificuldades inerentes ao fato de que qualidade de
software envolve muitos aspectos subjetivos (SOMMERVILLE, 2011).
Qualquer métrica referente à qualidade de software é sempre uma avaliação
indireta e incompleta, pois foca apenas um aspecto da mesma. A combinação das
53
métricas coletadas resulta em uma visão melhor da qualidade, mas sempre com os
limites impostos pela componente subjetiva.
[PRESSMAN] apresenta um conjunto extenso de métricas que pode ser
aplicado a qualidade de software, organizado de acordo com a meta relacionada a
uma etapa do processo de software e com o atributo a ser mensurado. A tabela 9
apresenta estas informações de forma resumida. Maiores detalhes sobre o que se
mede em cada um deles podem ser encontrados na referida fonte, página 455.
Meta Atributos
Qualidade dos requisitos
Ambiguidade
Completude
Compreensibilidade
Volatilidade
Rastreabilidade
Clareza do modelo
Qualidade do projeto
Integridade da arquitetura
Completude dos componentes
Complexidade da interface
Padrões
Qualidade do código
Complexidade
Facilidade de manutenção
Compreensibilidade
Reutilização
Documentação
Eficiência do controle de qualidade
Alocação de recursos
Taxa de completude
Eficácia da revisão
Eficácia dos testes
Tabela 9: Métricas de qualidade de software segundo Pressman
Fonte: Adaptado de PRESSMAN, 2016, p. 455.
Na situação prática observada, a única medida atualmente coletada é a
quantidade de incidentes em produção – defeitos – reportada pelos clientes da
empresa de software. Apesar de ser uma medida limitada a um aspecto, não deixa
de ser objetiva, quantitativa e, acima de tudo, altamente relevante, pois representa
uma forma de medir a qualidade segundo o ponto de vista dos usuários finais do
software, a quem o mesmo deve entregar valor.
54
2.8.3 Gestão de Configuração / Gestão de Mudanças
As mudanças são inevitáveis no ciclo de vida de um software e para evitá-las
é necessário que seja efetuado um processo de gestão que assegure uma evolução
em nível de qualidade aceitável. Este processo é denominado Gerenciamento de
Configuração de Software, ou ainda, Gerenciamento de Mudanças, e representa
parte importante do processo de gestão de qualidade. Entregar uma versão do
software com nível baixo de erros não garante que a mesma se mantenha assim ao
longo da vida útil do sistema.
A Gestão de Configuração de Software (GCS) abrange as atividades e os
recursos relacionados à busca da qualidade durante os processos de mudança,
identificando, controlando, auditando e reportando todas as mudanças ocorridas
(PRESSMAN, 2016).
Dado que as mudanças ocorrem desde o próprio projeto de desenvolvimento
inicial do software, a GCS deve ser aplicada ao longo de todo o processo, e não
apenas após a entrega em produção e entrada em ciclo de manutenção e evolução.
Como consequência, fazem parte dos processos de GCS todos os envolvidos no
processo de software. [PRESSMAN] menciona que em alguns casos são criados
papéis adicionais especializados em GCS.
A temporalidade é uma distinção bastante evidente com relação às atividades
de suporte de software: estas se iniciam apenas quando da entrega em produção. A
distinção mais relevante, no entanto, é que enquanto suporte envolve atividades de
engenharia de software, GCS abrange atividades de rastreamento e controle.
Todos os componentes e artefatos envolvidos na construção e
processamento de um sistema podem ser incluídos como objetos de ações da GCS,
recebendo o nome de Itens de Configuração de Software. Dentre eles podem ser
mencionados:
• Documentos de requisitos
• Modelos, documentos, diagramas de projeto
• Código fonte de programas
• Dados usados (por exemplo, tabelas de domínio e referência)
• Arquivos de configuração
• Ambiente de desenvolvimento usado
Os itens de configuração de software são armazenados em um Repositório,
que deve oferecer recursos como: registro de relacionamento entre itens; controle de
versões e alterações; compartilhamento com restrições de acesso de acordo com os
papéis envolvidos.
55
Para uma empresa de software em que um produto pode ser disponibilizado
para vários clientes, pode haver várias versões do mesmo em desenvolvimento e
em uso ao mesmo tempo. [SOMMERVILLE] destaca que a falta de procedimentos
de GCS efetivos pode levar a dificuldades para localizar a versão correta de um
componente, desperdício de esforço alterando código indevido ou até a entrega de
versões incorretas para os clientes.
2.8.4 Verificação x Validação
Estes dois fatores estão relacionados à qualidade de software e podem ser
erroneamente considerados sinônimos ou ter sua aplicação invertida, a exemplo dos
conceitos de eficiência e eficácia.
• Validação busca assegurar que o software criado segue os requisitos
do cliente, ou seja, se foi desenvolvido o que se desejava.
• Verificação apura se uma funcionalidade específica é executada
corretamente, ou seja, se foi desenvolvido corretamente.
Conforme [PRESSMAN], um grande elenco de atividades está envolvido na
avaliação dos dois conceitos, muitos dos quais já foram abordados. A eles se juntam
os testes de software, que são muito importantes, mas não podem ser
superestimados. Testes permitem estimar alguns aspectos da qualidade e encontrar
erros, mas a qualidade em si é resultado de todo o processo de software.
2.9 Testes de Software
2.9.1 Objetivos e Princípios
Os testes de software têm como objetivo encontrar o máximo possível de
erros em programas, de modo a que os mesmos possam ser corrigidos antes da
entrega aos clientes (PRESSMAN, 2016).
Detectar e corrigir internamente um erro evita que o mesmo seja identificado
pelo cliente. Um erro detectado externamente pode ter impacto ser muito mais
elevado.
Em muitos casos se considera como teste bem sucedido aquele que não
encontrou erros, quando na verdade o ponto de vista é oposto: quanto mais erros se
encontrar nos testes melhor a qualidade do software entregue aos clientes e
menores os impactos sobre o negócio e os custos de corrigi-los em produção, que
como já vimos são muito mais elevados.
56
Ao se definir os testes a serem aplicados a um software, são incluídas
condições múltiplas, sendo que algumas delas devem representar cenários
extremos que possam ocorrer no uso de forma a tentar provocar erros. Experiência
anterior sobre testes que têm sido eficazes na descoberta de defeitos ajuda a elevar
a possibilidade de detectar erros (PRESSMAN, 2016).
2.9.2 Estratégia (Plano) de Teste
Define a abordagem a ser adotada durante os testes de um software. Contém
as opções definidas para cada situação específica, segundo o domínio e as
características do software, os recursos disponíveis, a cultura da organização e das
equipes envolvidas (PRESSMAN, 2016).
A definição é feita combinando conhecimentos específicos de vários papéis,
como por exemplo, responsáveis pelo desenvolvimento, especialistas em testes e
gerentes de projeto.
Um planejamento adequado resulta em estratégia que permite o uso eficaz
dos recursos alocados para a execução dos testes. Estes recursos podem
representar fração importante do total envolvido em todo o processo de software e
devem ser usados de forma a maximizar os resultados em termos de detecção de
erros.
2.9.3 Responsabilidade
Em algumas situações as tarefas de teste são executadas pela própria equipe
de desenvolvimento do software. Dado que testes tem como objetivo achar a maior
quantidade de erros possível, é previsível a ocorrência de um conflito de interesses:
quem desenvolveu deve tentar achar erros no produto desenvolvido. A tendência é
que se projetem testes que confirmem que o produto funciona, o que significa que
erros podem se tornar defeitos, que são potencialmente mais graves (PRESSMAN,
2016).
A solução mais adotada, quando se consegue alocar recursos para isso, é
contar com um grupo independente para executar os testes. Esse grupo recebe
muitas vezes denominações que se confundem com o processo como um todo:
Gerência de Qualidade de Software, Qualidade de Software, Garantia de Qualidade
(em inglês com as iniciais QA).
O grupo independente não atua sozinho: ao longo dos testes é fundamental
que os desenvolvedores estejam disponíveis para receber a comunicação dos erros,
analisar os resultados obtidos (evidências) e, se a necessidade for confirmada,
efetuar as correções, gerando um novo incremento de software a ser submetido
novamente aos testes (PRESSMAN, 2016).
57
Nas metodologias ágeis há uma sobreposição dessas abordagens: em muitos
casos os recursos de teste são membros do próprio time de desenvolvimento (com
os riscos já vistos); em outros, existe uma equipe de teste separada.
A abordagem mais adequada é fortemente dependente da situação, e envolve
a cultura da organização e das pessoas envolvidas. Não é incomum uma estrutura
hibrida, onde o time de desenvolvimento conta com recursos de teste, que atua até a
liberação de uma versão de software, que é então submetida a um ciclo de testes
por parte da área de QA.
2.9.4 Estágios de Teste
Conforme [SOMMERVILLE], um sistema de software comercial passa por três
estágios de teste:
• Testes em desenvolvimento
Incluem todas os testes realizados pela própria equipe de
desenvolvimento do sistema, embora possa haver envolvimento de outros
recursos. Algumas vezes especialistas em testes atuam lado-a-lado com
os desenvolvedores, em outras um grupo de testadores independente é
utilizado.
Os testes são executados de forma muito similar ao modelo V, partindo do
nível mais baixo, que é cada segmento de código, passando por
agrupamentos de componentes e finalmente atingindo o nível de módulos
ou do sistema como um todo.
Após concluídos os testes em desenvolvimento e resolvidos os erros
encontrados de forma a atender os critérios de qualidade definidos, a
versão do sistema é classificada como candidata a ser entregue ao cliente,
tornando-se um release.
• Testes de release
Este teste é efetuado sobre um release liberado pela equipe de
desenvolvimento, e normalmente é executado por uma equipe com o
papel de QA já visto.
Embora pareça muito similar ao teste de sistema, o foco do teste de
release é validar o atendimento aos requisitos enquanto que o do teste de
sistema é verificar se o desenvolvimento foi correto.
Esta equipe é responsável por verificar de forma independente que o
software apresenta qualidade adequada para ser entregue aos usuários,
através da aplicação de um elenco de testes pré-definido a partir dos
requisitos (teste funcional) e acompanhando todo o processo de correção
58
dos erros encontrados por parte dos desenvolvedores que atuam lado a
lado durante esta fase.
• Testes de usuário
Após concluídos os testes de release com resultados adequados, o
sistema é disponibilizado para um período de testes por parte dos usuários
finais do sistema.
[SOMMERVILLE] menciona três tipos de testes de usuário:
o Teste alfa => usuários atuam junto com a equipe de
desenvolvimento para testar um novo software em processo
avançado de construção, fornecendo feedback que pode realinhar
inclusive os requisitos do mesmo.
o Teste beta => uma versão praticamente final de um novo software é
testada por um grupo de usuários para confirmação e coleta de
sugestões de ajustes finais.
o Teste de aceitação => os clientes testam o release de um sistema
para verificar se está apto a implantação em ambiente de produção.
Testes alfa e beta são normalmente associados ao lançamento de novos
sistemas e produtos, ou a grandes versões evolutivas dos mesmos, ocorrendo
apenas quando previstos na estratégia do produtor do software. Já os testes de
aceitação são prática generalizada nas organizações, sendo os últimos efetuados
antes de aprovar a implantação de um release.
Os testes de usuário são baseados na experiência, e buscam identificar se as
funcionalidades incluídas no release estão funcionando corretamente, além de poder
confirmar que não foram introduzidos efeitos colaterais indesejados durante a
mudança do software.
Naturalmente, a abordagem de teste pelo usuário parte de uma visão de
negócio, priorizando os pontos principais, de certa forma similar a uma estratégia de
Teste Baseado em Riscos, que veremos adiante. Alguma forma de suporte
metodológico pode ser prestada pela equipe de QA aos usuários para execução
desta fase.
2.9.5 Testes Manuais e Automatizados
Em um teste manual, uma pessoa (o testador) executa o programa, utiliza um
conjunto de dados de teste e compara os resultados obtidos com os esperados.
Eventuais diferenças são registradas tornando-se evidências de possíveis erros e
informadas aos desenvolvedores.
59
Já os testes automatizados são efetuados através de um programa que é
executado para testar o sistema ou partes do mesmo. Os parâmetros que definem
os testes executados, os dados a serem utilizados e as saídas esperadas são
fornecidos de uma ou mais formas:
• definidos através de interfaces do próprio programa
• carregados a partir de arquivos ou repositórios
• capturados (aprendizado) por módulos do próprio programa a partir da
execução manual do sistema através de sua interface de usuário
O registro das diferenças também é feito de forma automática, alimentando
uma base de evidências que fica disponível para os desenvolvedores. Também
podem ser acionadas interfaces para comunicar as ocorrências às equipes
envolvidas.
Testes automatizados, uma vez definidos, normalmente apresentam tempos
de execução e custos consideravelmente inferiores aos dos testes manuais, portanto
são bastante atrativos para as organizações, sendo crescentemente utilizados. Um
caso exemplar de aplicação são testes de regressão, vistos adiante, onde a cada
construção do software se deseja executar uma grande quantidade de testes para
verificar se efeitos colaterais indesejados foram introduzidos.
Para o sucesso na sua adoção, é importante que sejam estabelecidos
objetivos realistas em relação aos testes automatizados, muitas vezes cercados de
expectativas exageradas e alguns mitos. Nesse sentido podem ser citados
(TESTING EXCELLENCE, 2019):
• Testes automatizados apenas verificam o que foi definido pela pessoa
que os criou, dependendo da qualidade da mesma. Além disso, não
oferecem os benefícios da aplicação de julgamento e exploração
adicional possibilitados nos testes manuais.
• Testes automatizados não garantem 100% de cobertura, pois as
combinações de formas de operação e uso de um sistema tipicamente
são tão numerosas que podem ser consideradas quase infinitas. Além
disso, mais testes não implicam melhor qualidade ou confiabilidade.
Mais importante que o número é a cobertura dos pontos importantes.
• O retorno do investimento não é tão rápido quanto se pode imaginar,
pois além do custo de parametrizar o software de teste, que tende a
ser superior ao tempo de executar os testes manualmente, todo o
ambiente de software e infraestrutura deve ser preparado para
executar a automação.
• Automatizar testes unitários é importante para verificar cada porção de
funcionalidade, mas não é suficiente. Os defeitos vistos pelos usuários
60
e os erros mais complexos e difíceis de solucionar ocorrem quando da
execução integrada e devem ser objeto de testes automatizados
também.
• Testes a nível de interface de usuário apresentam desafios à
automação: além da execução mais lenta do que a nível de
componentes, estão sujeitos a mudanças na camada de apresentação
visando melhorar a experiência do usuário, que irão requerer
redefinição dos testes existentes para evitar que sejam apontadas
falhas indevidamente.
Automação de testes é um investimento que requer um longo prazo para
obter os benefícios. O conjunto de testes criado não pode ficar estático no tempo,
requerendo acompanhamento e atualização contínuos para acompanhar a evolução
dos softwares.
Também não elimina a necessidade de testes manuais, apenas pode
executar eficientemente testes de caráter mais repetitivo, ou gerar rapidamente
massas de dados cobrindo um conjunto de situações desejado. Os recursos
humanos são liberados para testes onde o julgamento aumenta a qualidade da
detecção de erros.
Na prática, os melhores resultados são obtidos quando se usa uma
combinação testes manuais e automatizados.
2.9.6 Teste Baseado em Riscos - Risk Based Testing
Teste Baseado em Riscos é uma abordagem de priorização dos testes de
uma aplicação, onde se visa assegurar que as funcionalidades, módulos e funções
onde a ocorrência de erros apresente maior impacto ou probabilidade sejam
testadas antes das demais.
[GURU99] apresenta a definição de risco como a ocorrência de evento incerto
com efeito positivo ou negativo sobre os critérios de sucesso de um projeto.
Teste Baseado em Riscos é aplicável, entre outros, a situações onde
restrições de tempo, recursos e orçamento possam limitar o escopo da aplicação de
testes. Desta forma busca-se através da priorização obter o melhor retorno possível.
Também podemos apontar que ao testar pontos críticos antes se garante um prazo
maior para solução de eventuais erros encontrados nos mesmos.
A identificação e avaliação dos riscos podem ser efetuadas de várias formas,
incluindo oficinas (workshops), listas de verificação (checklists), entrevistas, design
61
thinking, brainstorming, lições aprendidas em projetos anteriores, consulta a
especialistas com conhecimento do negócio a que se aplica o sistema.
2.9.7 Tipos de Testes
Podem ser aplicados a um software, de acordo com suas características e o
estágio onde se encontra, diversos tipos de teste, que são descritos na sequência.
Conforme é reforçado por [PRESSMAN] a abordagem de teste incremental se
revela a que apresenta melhores resultados: começa a nível de unidades, continua
conforme estas são integradas e conclui com os testes a nível de sistema.
2.9.7.1 Unidade
Verifica o software no seu menor nível, que é um componente ou módulo
elementar. O foco é validar a lógica e a estrutura de informações interna à unidade.
Conforme já visto, práticas modernas recomendam que estes testes sejam
definidos antes da própria codificação, podendo inclusive ser usados como
especificação total ou parcial pelos desenvolvedores.
Para execução dos testes de unidade é necessário que exista um módulo
adicional, que não faz parte do sistema, capaz de acionar a unidade testada,
fornecendo entradas e estímulos e recebendo o retorno da execução da mesma. A
arquitetura e padrões de desenvolvimento devem prever este requisito e ser
seguidos por todos os desenvolvedores.
Automação de testes pode e deve ser adotada sempre que possível neste
nível, estando disponíveis no mercado ferramentas que podem ser adaptadas à
situação de cada organização.
2.9.7.2 Integração
O foco deste teste é verificar se as unidades, que funcionam adequadamente
de forma isolada conforme resultados do teste anterior, apresentam os resultados
esperados quando funcionam em conjunto formando um módulo de maior
complexidade.
Algumas das causas de erros neste nível citadas em [PRESSMAN] são:
• Perda de dados transmitidos pelas interfaces entre unidades
• Efeito inesperado de um componente sobre outro
• Combinações de subfunções que não geram a funcionalidade desejada
• Problemas em estruturas de dados comuns a várias unidades
62
Representa uma aplicação da estratégia incremental, onde o sistema é
testado em módulos menores, o que facilita identificar erros de interfaces e suas
causas. Pode ser executada de forma Ascendente ou Descendente:
• Ascendente => inicia-se pelas unidades elementares na base da
arquitetura e vai-se criando e testando módulos cada vez maiores até
se chegar ao sistema completo. A cada etapa os módulos de controle
criados para acionar os módulos testados são substituídos pelo módulo
real, até se ter todo o sistema funcionando a partir da interface inicial
apresentada ao usuário.
• Descendente => o teste parte da interface inicial e à mesma vão sendo
agregadas sucessivamente as camadas de funcionalidades acionadas.
O próprio sistema é o módulo de controle para execução dos testes.
Existem duas formas de abordagem distintas:
o Na primeira, cada camada é totalmente testada, permitindo
verificar a navegação do sistema em cada nível e a execução
das funcionalidades relativas ao mesmo.
o Na segunda, cada ‘caminho’ de navegação do sistema é testado
até que se chegue ao nível mais elementar. Desta forma é
possível verificar um módulo ou funcionalidade completa antes
de passar para o seguinte.
Automação pode ser aplicada também neste nível, havendo limitações
apenas no tocante a operação de interface de usuário, que vem sendo cobertas de
forma cada vez mais abrangente pelas ferramentas disponíveis combinadas a uma
arquitetura de software que a viabilize.
2.9.7.3 Fumaça (Smoke)
Este teste pode ser aplicado periodicamente durante o desenvolvimento,
como uma forma de teste de integração envolvendo onde periodicamente
(diariamente é a situação ideal) se constrói uma versão do software completo e se
percorre as principais funcionalidades do sistema de forma a verificar a estabilidade
do mesmo (PRESSMAN, 2016).
Erros de integração de maior gravidade podem então ser detectados e
tratados com antecedência proporcionando maior segurança da sanidade do
desenvolvimento em progresso.
Este tipo de teste remete aos conceitos já apresentados de Integração
Contínua e Teste Contínuo, sendo normalmente executado com o suporte de
ferramentas de automação de construção e execução de testes.
63
2.9.7.4 Regressão
O objetivo deste teste é identificar se as alterações introduzidas em uma
versão do software causaram erros devido a efeitos colaterais indesejados. Para
isso é executado um conjunto de testes previamente selecionado. [PRESSMAN],
classifica esses testes em: testes gerais que percorram as funcionalidades de todo o
software; testes dos mais suscetíveis a impacto pelas alterações efetuadas; testes
focando os componentes alterados.
Existem limites à cobertura deste conjunto de testes, que são impostos pela
disponibilidade de recursos e de tempo, especialmente em grandes sistemas. A
correta seleção do que testar requer expertise, indo desde conhecimentos do
negócio até arquitetura de construção da aplicação. Podem ser aplicados conceitos
de Teste Baseado e Riscos para maximizar os benefícios dos testes de regressão,
direcionando os recursos para os pontos onde defeitos em produção gerem os
maiores impactos.
O conjunto de testes de regressão cresce à medida que o sistema evolui, e a
cada versão é necessário reavaliar o que deve ou não continuar a fazer parte do
mesmo.
Testes de regressão são ponto onde podem ser obtidos muitos benefícios
com a aplicação de autômatos de teste como forma de reduzir custos e permitir
executar um volume de testes maior no mesmo tempo.
2.9.7.5 Validação
Tem o objetivo de verificar o comportamento do sistema em relação aos
requisitos estabelecidos pelo usuário, onde devem estar incluídos os critérios de
validação a serem aplicados. Por uma série de motivos que não serão detalhados
aqui, nem sempre um software que funciona corretamente faz exatamente o que o
usuário espera. Os testes de validação visam detectar este tipo de situação de forma
a permitir que decisões sejam tomadas e ações de correção executadas. São
aplicados a uma versão considerada adequada após os testes de integração.
Este teste, na classificação de 3 estágios encontrada em [SOMMERVILLE] já
mencionada, abrange também os testes pelo usuário, nas formas alfa, beta e
aceitação.
2.9.7.6 Recuperação
Este é o primeiro tipo de teste abordado que não se refere a requisitos
funcionais, ou seja, onde não se testa o atendimento a funcionalidades de negócio.
Seu objetivo é medir o sucesso na construção do sistema em evitar ou minimizar
64
prejuízos por indisponibilidade para uso, perda ou corrupção de informações
(PRESSMAN, 2016).
O sistema é deliberadamente submetido a situações de falha, como por
exemplo operação em forma indevida, quedas de energia, comunicação ou
servidores. É então verificado o comportamento quando do reinício de operação
normal e também o tempo necessário para que isso ocorra.
2.9.7.7 Segurança
O objetivo aqui é verificar se o sistema conta com recursos que protejam
contra invasões e violações e suportem os três aspectos principais da segurança em
relação ao sistema, a seus módulos e programas, a suas funcionalidades, e às
informações por ele tratadas e armazenadas (PRESSMAN, 2016):
• Disponibilidade => estar disponíveis quando necessário
• Integridade => impedir corrupção ou alteração não autorizada.
• Confidencialidade => ser acessível apenas a usuários autorizados,
com segregação de acordo com o perfil atribuído a cada um
Embora não exista proteção total contra invasões, deve-se ter como meta
elevar o esforço e custo das mesmas a nível acima do eventual benefício obtido, o
que é uma forma eficiente de dissuadir tentativas de ataque. São efetuadas
tentativas de invasão que visam avaliar se a proteção existente atende os critérios
estabelecidos.
2.9.7.8 Esforço (Stress)
O objetivo destes testes é submeter o sistema a condições extremas, além
das assumidas ou incluídas nos requisitos funcionais e, principalmente, não
funcionais, de forma a forçar o sistema (PRESSMAN, 2016).
Como exemplo de condições anormais, podemos citar fluxos de entrada,
interações externas, valores limites de dados, uso forçado das funcionalidades que
exigem maiores recursos de memória, acesso a armazenamento físico ou
processamento.
Ferramentas podem ser utilizadas para automatizar a execução de alguns
testes deste, gerando demandas difíceis de serem atingidas manualmente. Dados
colhidos são registrados de forma a avaliar o comportamento e possíveis
oportunidades de melhoria. Finalizando, este tipo de teste é muitas vezes ligado ao
teste de desempenho.
65
2.9.7.9 Desempenho (Performance)
Neste teste, que em alguns pontos se relaciona ao teste de esforço já visto, o
sistema é submetido a uma carga de trabalho intensa, ainda que dentro das
condições normais de operação previstas nas especificações (PRESSMAN, 2016).
Pode-se testar desempenho desde o teste unitário, passando por todos os
níveis de integração, e culminando com a aplicação ao sistema inteiro, o que permite
apurar o comportamento do mesmo em situações com todas as interfaces em
execução.
São executadas operações que simulam grandes quantidades de usuários
simultâneos, processamento de grandes volumes de informações, e executados
processos de uso intensivo de recursos de hardware.
Novamente a execução e coleta de resultados se valem de automatização. As
informações obtidas permitem detectar situações que levem a degradação ou até
falha, de forma a permitir a definição de ações a serem tomadas.
2.9.7.10 Disponibilização (Configuração)
Na teoria este seria o último teste aplicado antes de entregar o sistema ou
uma nova versão para o(s) cliente(s). São criados os diversos ambientes
operacionais (softwares + infraestrutura) onde será feita a instalação do mesmo,
incluindo a versão anterior do sistema que estiver em uso em cada um dos mesmos,
se existir (PRESSMAN, 2016 e SOMMERVILE, 2011).
Em cada ambiente são aplicados os procedimentos, scripts e eventuais
programas criados para a instalação. Os resultados obtidos permitem verificar a
adequação de todos esses elementos, indicando se há necessidade de correções
nos mesmos. Na sequência é efetuado o teste da nova versão do sistema, que pode
combinar um ou mais dos testes já vistos.
2.10 Tratamento de Defeitos
A experiência permite afirmar que, por melhores que sejam os processos e
tecnologias e pessoas envolvidas, por maiores que sejam os prazos e recursos
financeiros disponíveis, todo software irá apresentar erros ao ser utilizado em
produção. Aos erros descobertos neste ambiente externo, onde o ‘teste’ é feito pelo
próprio usuário, se dá o nome de defeitos (PRESSMAN, 2016).
Como já vimos ao abordar Custo da Falta de Qualidade, defeitos (falhas em
ambiente externo) acarretam uma série de ônus adicionais aos da simples correção
técnica dos erros, incluindo perda de imagem, reputação ou clientes, e prejuízos ao
negócio pela falha ou indisponibilidade de sistemas. Desta forma, o tratamento dos
66
defeitos assume grande importância para a qualidade da experiência de utilização
de software como um todo.
Todo um processo de atendimento, comunicação com o usuário e solução
está envolvido, mas foge ao escopo deste trabalho. Frameworks voltados a serviços,
como por exemplo o ITIL, fornecem especificações e detalhes sobre todas as
atividades aqui envolvidas. Na sequência, abordaremos apenas aquelas
relacionados à busca de melhoria de qualidade de software.
Como já vimos no item Métricas, a qualidade de software oferece desafios
complexos a tentativas quantitativas, sendo necessário recorrer a medidas indiretas.
Podemos considerar as estatísticas referentes a defeitos de software como
métricas macro, pois englobam a ocorrência de qualquer falha que bloqueie ou
prejudique o objetivo final já mencionado: gerar valor entregando benefícios para os
usuários do mesmo e para a organização de software que o desenvolveu.
Dentro da atual prioridade a processos com foco em geração de valor, visão e
experiência do usuário, esta é uma métrica altamente relevante. [PRESSMAN]
coloca que há um crescimento da aplicação da garantia da qualidade estatística, ou
seja, em tornar a abordagem da qualidade de forma mais quantitativa. Aponta ainda
passos a serem seguidos para tal que, aplicados ao nosso caso podem ser descritos
como:
• Coletar informações sobre erros e defeitos de software, categorizando-
os;
• Buscar identificar a causa de cada um;
• Avaliar estatisticamente a relevância de cada causa e, aplicando
princípios como o de Pareto (80% dos defeitos podem ser rastreados
até 20% de todas as causas possíveis), identificar quais são as mais
prioritárias para acionamento de medidas de melhoria;
• Atuar sobre o subconjunto das causas prioritárias.
2.10.1 Registro
O registro adequado de todos os defeitos é o primeiro passo para embasar
ações visando melhorar a qualidade do software percebida pelo usuário. Para que
sejam passíveis de tratamento adequado, defeitos não podem simplesmente
registrados em formato livre e não estruturado. Faz-se necessário que, ao informar
uma ocorrência de defeito, sejam fornecidas de forma padronizada informações que
permitam identificar tanto quanto for viável e aplicável (DEVMEDIA, 2019):
• O que está sendo considerado como defeito.
• Módulo do software onde ocorreu.
• Circunstâncias ou sequência de operações que o gerou.
67
• Evidências do defeito (capturas de tela, arquivos processados,
registros de log, etc.).
• Versão do software e componentes do ambiente de execução do
mesmo.
• Gravidade do defeito.
• Consequências já geradas pelo mesmo (impacto nos negócios).
• Consequências de não solução (idem).
• Número de usuários impactados.
• Observações em formato livre contendo esclarecimentos adicionais.
Para a coleta destas informações normalmente são utilizados produtos
especializados que possam ser customizados, preferencialmente via
parametrização, de acordo com as características de cada software, organização
desenvolvedora e organizações usuárias. Pode também ser desenvolvida solução
própria, que é prática menos frequente dada a qualidade (o conceito objeto do nosso
trabalho aparece aqui não por acaso!) e custo competitivo das alternativas
existentes.
As ferramentas mais usadas abrangem todo o processo de suporte e
atendimento, até o encerramento da ocorrência, mas como já vimos serão
abordados neste trabalho apenas a aspectos relacionados a qualidade de software.
O acesso à ferramenta deve ser disponibilizado diretamente aos usuários:
para prevenir conflitos de interesses e permitir uma correta apuração de qualidade
(não apenas do software, mas de todo o processo de serviço), o registro dos
defeitos deve ser feito por eles, e não por quem desenvolve e suporta.
2.10.2 Classificação
A partir do registro de um defeito, uma série de ações deve ser efetuada.
Todo o ciclo de atendimento, suporte e solução estão envolvidos. Como já
mencionamos, vamos tratar apenas dos aspectos relacionado à qualidade de
software, que compreendem (SOMMERVILLE, 2011):
• Análise do defeito.
• Solicitação de informações adicionais quando necessário.
• Identificação da causa (aqui pode-se encontrar desde falha na
identificação de requisitos até mudanças no ambiente de execução do
software, passando por todas as fases do ciclo de desenvolvimento e
entrega em produção).
• Avaliação do impacto (pode ser usada como fator de ponderação,
elevando a prioridade de causas que, embora gerem menor quantidade
de defeitos, representam impactos graves).
68
2.10.3 Soluções
2.10.3.1 Defeitos (pontuais)
A solução de um defeito registrado não necessariamente implica em resolver
a causa identificada para o mesmo. Isto ocorre quando (SOMMERVILLE, 2011):
• as consequências do defeito são irreversíveis: corrigir a causa não
elimina os impactos já gerados;
• é inviável permanecer com o defeito durante o tempo requerido para
desenvolver a correção da causa;
• não é possível definir claramente uma solução para a causa no
momento;
• a correção da causa, pela sua complexidade ou menor prioridade, irá
requerer um tempo significativo e uma forma de conviver com a causa
do defeito deve ser estabelecida até lá.
Nestes casos, uma solução envolvendo uma alternativa de contorno ou um
ajuste (por programa, script ou manualmente) deve ser criada e aplicada.
2.10.3.2 Causas
Uma vez que uma causa é identificada e eleita para solução, de acordo com a
ordem de prioridade atribuída, todas as recomendações do processo de software
deveriam ser aplicadas de forma a garantir a qualidade do resultado final, ou seja,
da nova versão do software entregue ao cliente.
Em situações com alto impacto para os negócios, correções de emergência
podem ser necessárias. [SOMMERVILLE] menciona que isto muitas vezes leva a
opção pela solução mais rápida, e não a mais adequada. Além disso, atividades que
possam impactar a rapidez da entrega, como documentação, revisões e alguns
ciclos de testes, são deixadas de lado.
Este fator contribui muito para a degradação da qualidade do software ao
longo do tempo. Embora no momento da pressão seja comum que se declare um
compromisso de rever (e se necessário refatorar) a solução rápida assim que a
emergência cessar, em muitos casos não é isso que ocorre na prática.
69
2.11 Melhoria de Processo de Software
Em [PRESSMAN] encontramos uma definição sucinta de melhoria de
processo de software (SPI, do inglês Software Process Improvement), descrita como
englobando “um conjunto de atividades que levarão a um melhor processo de
software e, em consequência, uma maior qualidade do software fornecido, dentro do
prazo de entrega”.
Esta busca de melhoria vem de encontro a tudo que foi abordado até agora
sobre a importância e os desafios relacionados à obtenção de qualidade de
software.
2.11.1 Conceitos
Há espaço em muitas organizações, para melhorias no processo de software,
e na verdade um grande número delas já se lançou a iniciativas nesse sentido. Nem
sempre os resultados esperados foram atingidos, pois deixaram de considerar
alguns pontos chave de alta relevância.
Inicialmente, deve sempre ser considerado que não existe um processo 'ideal'
de software, portanto não se pode simplesmente ‘copiar’ o que está tendo sucesso
em outro lugar. Cada organização deve encontrar seu ‘melhor processo’, levando
em consideração aspectos como (PRESSMAN, 2016 E SOMMERVILLE, 2011):
• Tipo de software desenvolvido.
• Processos ou práticas correntes.
• Cultura da organização/pessoas, valores, grau de formalidade,
tamanho.
• Recursos disponíveis para investimento na melhoria.
• Melhores práticas de engenharia de software da indústria em geral.
• Casos de sucesso em empresas que desenvolvem software similar.
• Oportunidades de padronização, como facilitador para comunicação,
treinamento, automatização e mudança para métodos novos.
Os fatores que determinam a qualidade do produto de software, conforme
encontramos em [SOMMERVILLE], são mostrados na figura 12.
70
Figura 12: Fatores determinantes da qualidade de software
Fonte: Adaptada de SOMMERVILLE, 2011
A mensagem a ser registrada é que a qualidade do processo é importante,
mas não suficiente e decisiva para a qualidade final do produto. No tópico seguinte
são apresentadas considerações mais detalhadas a respeito.
2.11.2 Considerações e limitações
Ao contrário dos segmentos onde se originou a teoria de processos de
qualidade, produtos de natureza intelectual, como é o caso de software, agregam ao
relacionamento da qualidade de produto com a qualidade de processo níveis de
complexidade não diretamente controláveis. Em muitas situações, habilidades,
adaptabilidade e experiências das pessoas envolvidas determinam a qualidade do
software muito mais do que o processo adotado.
Vimos no tópico anterior os quatro fatores apresentados em
[SOMMERVILLE]. A importância relativa de cada um deles é totalmente dependente
de cada situação, conforme nos coloca a mesma fonte.
Para projetos grandes, divididos em subsistemas criados por equipes
separadas, o processo, incluindo comunicação, integração e gestão, assume maior
importância, devendo ser adotado um maior grau de formalização. Em contrapartida,
projetos pequenos podem ter sucesso com processos mais leves, sendo os métodos
ágeis o grande exemplo prático, já em sua declaração estabelecendo que se
colocam pessoas acima de processos. Neles, a qualidade dos membros da equipe é
um fator mais determinante dos resultados.
Projetos grandes apresentam uma distribuição de tempo diferente dos
menores. Neles, a fração do tempo destinada a comunicação e troca de informações
é maior, o que reduz o tempo correspondente a desenvolvimento de código. Neles o
benefício de tecnologias e ferramentas mais sofisticadas fica mais diluído do que
nas situações onde uma porção maior do tempo é dedicada à codificação.
71
Finalmente, se não houver recursos suficientes para suportar os custos, ou se
o tempo definido for irrealista, a qualidade de produto será afetada. Sem ambos não
há como adotar um processo adequado, mesmo pessoas excelentes gerarão
resultados inferiores a seu potencial, escopo ou qualidade serão prejudicados.
Este último fator explica o insucesso de alguns projetos: a concorrência gera
pressões não controláveis para entregar antes do possível ou a um custo/preço
abaixo do mínimo razoável, o que acaba gerando gerado resultados inferiores aos
esperados.
Dentro do conceito de que para melhorar um processo é necessário gerenciá-
lo, o que por sua vez requer que o processo seja medido, faz parte de toda iniciativa
nessa área o estabelecimento de critérios para avaliação dos elementos envolvidos.
2.11.3 Modelos de Melhoria de Processos de Software
Diversas entidades elaboraram e divulgam modelos de melhoria de processos
de software a partir da compilação de conjuntos de melhores práticas e organização
dos processos envolvidos em áreas e níveis de evolução crescente rumo ao objetivo
de oferecer um caminho para atingir melhor qualidade de software.
Cada um desses modelos incorpora (PRESSMAN, 2016):
• Definição dos elementos que devem estar contemplados no processo
de software.
• Formas de avaliação de cada um desses elementos em relação ao
que é proposto no modelo e de consolidação dos resultados obtidos.
• Estratégias de apoio às organizações para implementar os processos
no nível necessário.
O resultado final da avaliação é exposto como o ‘nível de maturidade’ atingido
pela organização em relação ao processo, o que leva os modelos de melhoria a
serem conhecidos como modelos de maturidade.
O principal modelo de maturidade adotado atualmente a nível global é o
CMMI. Para o mercado brasileiro foi desenvolvido o modelo MPS-BR. As principais
características desses dois modelos são apresentadas na sequência.
2.11.3.1 CMMI
O modelo CMMI (Capability Maturity Model Integration) é um modelo de
treinamento e avaliação de melhorias de processos de software. Foi criado
evoluindo a partir de do modelo CMM (Capability Maturity Model) criado pelo SEI
(Software Engineering Institute), definido de forma abrangente em 1993, com o
objetivo de melhorar as capacidades da indústria norte-americana de software. É
72
administrado pelo Instituto CMMI, um subsidiário do ISACA (Information Systems
Audit and Control Association), tendo a última versão sido publicada em 2018
(ISDBRASIL, 2019).
O CMMI é utilizado mundialmente há décadas, tendo sido obtidos excelentes
resultados. Incorpora um conjunto testado e comprovado de boas práticas em itens
como desenvolvimento de produtos, prestação de serviços, e aquisições. Tem obtido
sucesso quando aplicado com uma diversidade de métodos e técnicas, incluindo
abordagens ágeis.
Trata-se de um modelo abrangente e muito complexo, cuja descrição
completa envolve extensiva lista de processos e volumosa documentação.
Apresentaremos a seguir uma compilação sucinta das principais características do
CMMI.
Na versão 2.0 são definidas 20 áreas relacionadas a melhoria de processos
de software. Estas áreas são agrupadas em 9 áreas de capacidade, que por sua vez
são agrupadas em 4 categorias. A estrutura está apresentada na figura 13.
73
Figura 13: Áreas do CMMI
Fonte: ISDBRASIL, 2019
Uma área é avaliada de acordo com uma série de características, cada uma
destas com metas pré-definidas, e enquadrada em uma escala que representa a
Capacidade atingida, apresentada na figura 14.
Visando auxiliar as organizações nas iniciativas de melhoria, o modelo
apresenta para cada uma das áreas uma compilação de boas práticas, que orientam
sobre como alcançar uma meta. Não é obrigatória a adoção de nenhuma dessas
práticas recomendadas, pois o objetivo é atingir a meta. Cada organização pode
adotar o que for mais aplicável à sua realidade.
74
Figura 14: Níveis de capacidade no CMMI
Fonte: ISDBRASIL, 2019
A avaliação CMMI atribui a cada uma das áreas de processos um nível de
capacidade segundo a escala vista na figura 14. Para atingir um nível, é necessário
atingir todas as metas relacionadas ao mesmo, garantindo ainda que o mesmo
ocorra para todos os níveis inferiores, quando existirem. Níveis mais baixos podem
ser atingidos apenas aplicando boas práticas, mas os níveis mais elevados
requerem um compromisso com a medição e a melhoria de processos.
Em paralelo a esta forma de aplicar o CMMI, que é denominada Contínua,
existe a alternativa da aplicação por Estágios. Nesta segunda, as mesmas áreas de
processos são divididas em conjuntos, cada um deles correspondendo a um nível de
Maturidade. As metas e práticas são as mesmas do modelo Contínuo, e um nível de
maturidade é atingido se todas as metas e práticas das áreas envolvidas forem
atingidas, sendo a escala similar à de capacidade.
A tabela 10 apresenta de forma resumida cada nível de maturidade.
75
Nível Foco
Executado Executar
Repetível Gerenciamento básico de projeto
Definido Padronização de processo
Controlado quantitativamente Gerenciamento quantitativo
Otimizante Melhoria contínua de processo
Tabela 10 Níveis de maturidade no CMMI por estágios
Fonte: Adaptada de PRESSMAN, 2016
Associada ao CMMI foi definida e criada a estrutura de avaliação e
certificação, que permite atestar o nível de qualidade dos processos de software da
organização perante os envolvidos.
Uma consideração final que deve ser colocada é sobre a decisão de aplicar
ou não o CMMI na organização e buscar certificação no mesmo. Por se tratar de um
modelo muito extenso e demandante, os custos envolvidos são elevados ao ponto
de inviabilizar sua adoção em organizações menores que não apresentem projetos
grandes e de alta duração. Cada organização deve avaliar sua situação, recursos e
cultura, de forma a embasar a opção pró ou contra o uso do CMMI detalhado.
[PRESSMAN] coloca que independentemente da mesma, o espírito do modelo deve
ser sempre adotado, pois visa atender os aspectos determinantes do sucesso na
entrega de software.
2.11.3.2 MPS-BR
O modelo MPS-BR é uma iniciativa criada em dezembro de 2003 sob
coordenação da Associação para Promoção da Excelência do Software Brasileiro
(SOFTEX) em 2003. Recebeu o apoio, entre outros, do Ministério da Ciência,
Tecnologia e Inovação (MCTI), da Financiadora de Estudos e Projetos (FINEP) e do
Serviço Brasileiro de Apoio às Micro e Pequenas Empresas (SEBRAE).
O programa tinha como uma das principais metas contribuir para melhorar a
competitividade das empresas brasileiras, em especial as de porte micro a médio, na
produção de software com qualidade, divulgando e apoiando a adoção de modelos
de melhoria de processos de software. Com isso se buscava propiciar a oferta de
produtos e serviços com padrões internacionais de qualidade.
76
Da mesma forma que no CMMI, é prevista e definida estrutura de avaliação e
certificação das organizações em qualidade de processos de software, medida de
acordo com as definições do MPS-BR. Estas são baseadas em normas nacionais e
internacionais, e no próprio CMMI. A escala é similar à deste, embora prevendo
maior granularidade em alguns níveis, subdivididos de forma a permitir evolução
gradativa, conforme mostra a figura 15. Maiores detalhes podem ser vistos em
[MPS-BR].
Quanto à apresentação, o MPS-BR é composto por um conjunto de modelos
de referência, aos quais se somam guias de implementação, avaliação e aquisição.
Os documentos que o descrevem são apresentados na forma de guias disponíveis
gratuitamente no site da SOFTEX – www.softex.com.br, e são descritos na tabela
11, elaborada a partir de [MPS-BR]:
Figura 15: Níveis no modelo MPS-BR
Fonte: Construída a partir de definição MPS-BR
77
Documento Descrição
Guia Geral MPS de
Software
Estrutura dos modelos MPS
Detalhamento do Modelo de Referência MPS para Software (MR-
MPS-SW), seus componentes e definições
Guia Geral MPS de
Serviços
Estrutura dos modelos MPS
Detalhamento do Modelo de Referência MPS para Serviços (MR-
MPS-SV), seus componentes e definições
Guia Geral MPS de
Gestão de Pessoas
Estrutura dos modelos MPS
Detalhamento do Modelo de Referência MPS para Gestão de Pessoas
(MR-MPS-RH), seus componentes e definições
Guia de Avaliação
Processo e o método de avaliação MA-MPS
Requisitos para avaliadores líderes e adjuntos, e para Instituições
Avaliadoras (IA)
Guias de Implementação Documentos contendo orientações para implementar os níveis de
maturidade descritos nos Modelos de Referência
Guia de Aquisição de
Software
Processo de aquisição de software e serviços correlatos, baseado nas
definições do MR-MPS-SW
Tabela 11 Documentos do modelo MPS-BR
Fonte: MPS-BR, 2019.
Ao oferecer às organizações uma alternativa mais leve em relação à adoção
de modelos mais exigentes, como o próprio CMMI, busca-se atender aquelas que
não conseguiriam implantá-los. Na prática, os custos e esforços envolvidos no MPS-
BR podem ser avaliados como médios, o que ainda tem influência na opção pela
sua adoção.
2.11.3.3 Outros
Muitos outros modelos de maturidade/melhoria de processos foram definidos.
Encontramos em [PRESSMAN], entre outros, referências aos modelos People-CMM.
SPICE e TSP. Cada um deles se direciona mais para um elemento do processo ou
busca de conformidade com normas, como por exemplo as da ISO (International
Standards Organization).
A diversidade de modelos não significa que a aplicação dos mesmos seja
mutuamente exclusiva em sua totalidade. Como exemplo, podemos citar o People-
CMM que é voltado a gestão de pessoas, conhecimento e inovação, e pode ser
aplicado em conjunto com outro modelo mais geral, como o CMMI ou SPICE.
78
3. RELAÇÃO DA TEORIA COM A PRÁTICA
Neste ponto do trabalho aplicamos os elementos levantados na
fundamentação teórica para efetuar a avaliação das práticas de qualidade em uma
empresa brasileira de produtos de software e serviços de manutenção,
customização, desenvolvimento, implementação e consultoria, que será denominada
UNIDADOS.
Descrevemos a situação atual, conforme obtido através de entrevistas, coleta
de documentos e apresentações, bem como as medidas já em curso voltadas a
qualidade de software.
Efetuamos a comparação com a teoria vista anteriormente e, nas seções
seguintes, apresentamos resultados, comentários e proposições de ações que
possam resultar em aumento da qualidade dos softwares entregues aos clientes.
3.1 Caracterização da Empresa
A UNIDADOS é uma empresa brasileira fundada no final da década de 1990
com o objetivo de desenvolver sistemas e produtos de software para o mercado
brasileiro, que entrega valor a seus clientes a partir da qualidade dos produtos e dos
serviços associados a eles. Suas estruturas de receitas e custos são diretamente
impactadas por esse aspecto, tanto no resultado imediato, quanto em imagem e
resultados futuros.
Após um período inicial de crescimento orgânico com recursos próprios,
colocou em prática uma estratégia de captação de investimentos, voltados
principalmente ao crescimento via aquisições de empresas que ofereciam produtos
complementares aos originais ou voltados a outros segmentos do mercado, com o
objetivo de aproveitar sinergias operacionais, tecnológicas e comerciais.
O sucesso continuado da estratégia resultou até o momento em mais de uma
dezena de aquisições, sendo algumas delas de empresas cujo porte era comparável
ao do núcleo original à época, e que continuaram atuando com sucesso em seus
respectivos mercados.
Como resultado, a UNIDADOS tornou-se líder no setor, tendo constituído um
portfólio de produtos e soluções bastante diversificado. Cada um deles conta com
equipe distinta dedicada, sendo hoje identificados gerencialmente mais de 10 grupos
de desenvolvimento, número que vem crescendo com as novas aquisições.
O número total de colaboradores se aproxima da casa do milhar, estando
geograficamente distribuídos, principalmente em 3 grandes capitais brasileiras,
sendo a maior delas a matriz em São Paulo. Quanto a penetração no mercado, os
79
produtos e serviços da UNIDADOS são utilizados por aproximadamente 300
clientes.
A empresa oferece soluções voltadas para execução nas instalações dos
clientes, lado a lado com outras disponíveis no modelo Software como Serviço
(SaaS, do inglês Software as a Service), onde os clientes acessam de forma
compartilhada uma instalação hospedada em servidor contratado e administrado
pela UNIDADOS.
3.2 Situação inicial observada
O processo de incorporação das empresas adquiridas pela UNIDADOS se
caracterizou por um alto nível de manutenção da independência das estruturas de
desenvolvimento, manutenção e suporte aos produtos de cada uma. A consolidação
ocorreu principalmente nas áreas comercial, administrativa e financeira, que hoje
operam de forma mais centralizada.
Dos pontos que foram determinantes para que a manutenção da
independência ocorresse, destacam-se:
• Heterogeneidade das plataformas de tecnologia
Originalmente a UNIDADOS se caracterizava como uma Microsoft ®
house, ou seja, uma empresa cujos produtos de software eram criados
usando principalmente as ferramentas desse fornecedor, sempre que
possível atualizadas de forma a acompanhar as versões mais recentes.
Para ganhos de produtividade, agilidade e mesmo de qualidade,
algumas das unidades da empresa desenvolveram frameworks de
desenvolvimento que eram usados para criar a maioria das soluções
oriundas do núcleo original.
À medida que aquisições foram sendo efetuadas, produtos criados
usando ferramentas de outros fornecedores, ou mesmo versões mais
antigas de ferramentas Microsoft ®, passaram a compor o elenco de
soluções, sendo natural a manutenção das áreas oriundas dessas
empresas como ‘ilhas’ de desenvolvimento’, segregadas por uso de
tecnologias incompatíveis. Podemos encontrar no portfólio atual
soluções utilizando plataformas Oracle®, Java e até mesmo aplicação
cliente-servidor em plataforma cliente-servidor Centura® (no momento
esta última está sendo reescrita como parte dos investimentos da
empresa em P&D).
• Áreas de negócios distintas
80
A UNIDADOS atende clientes em áreas bastante distintas. Cada uma
dessas áreas apresenta características de negócio diferenciadas,
requerendo da gestão de produtos e das equipes atuando nos mesmos
conhecimentos específicos que induzem à manutenção da separação
entre equipes.
• Distribuição geográfica
Algumas empresas adquiridas estavam localizadas em localidades
relativamente distantes, sendo esta situação mantida até hoje, por uma
combinação de fatores envolvendo custos físicos e riscos relacionados
à retenção de recursos humanos críticos, que restringem a
movimentação das mesmas para junto ou próximo à estrutura central
da empresa. Isto se evidenciou ainda mais em aquisições recentes,
onde as empresas incorporadas ficam distantes dos núcleos principais.
• Nível de maturidade/qualidade não uniforme
As novas empresas apresentavam, quando de sua aquisição, níveis
bastante diferenciados. Enquanto parte delas vinha de um histórico de
certificação MPS-BR, outras ainda adotavam práticas menos
abrangentes em relação ao aspecto qualidade de processos e
software.
Além das verticais de produtos, a empresa mantém ainda algumas estruturas
operacionais relevantes:
• Diretoria de consultoria e projetos sob medida
Opera de forma totalmente autônoma em relação às de produtos. Não
será tratada neste trabalho, porém em contatos menos formais e
estruturados, tivemos conhecimento de que nela estão sendo
introduzidas metodologias e práticas ágeis. Por exemplo, recentemente
foi formalizada a contratação de um SCRUM Master experiente para
atuar como ponto focal para direcionar essas iniciativas.
• Diretoria de pesquisa e desenvolvimento
Dentro da estratégia da UNIDADOS, fortemente baseada em produtos
de software, faz parte a manutenção de investimentos em melhoria e
redesenvolvimento de produtos, sendo o caso citado acima um
exemplo. Para abrigar estas iniciativas foi criada uma estrutura
separada, na qual se praticam largamente de abordagens de inovação,
e existe forte uso de práticas e métodos ágeis.
• Iniciativa de inovação
A UNIDADOS instituiu ainda uma plataforma colaborativa, com
personalidade jurídica distinta, onde investe em fomento de iniciativas
81
de inovação, com programas de atração de empresas e startups para
disseminação e aplicação de conceitos. Programas de capacitação
teórica e prática, formação de rede de contatos entre empresários,
investidores e parceiros, uso de processos e práticas modernas e
inovadoras, entre outros, fazem parte da estrutura oferecida.
3.2.1 Dificuldades e desafios
Os fatores elencados acima contribuíram para elevar a dificuldade de se
implementar um processo corporativo de engenharia de software, incluindo-se a
gestão da qualidade. Como resultado, a UNIDADOS partiu de uma situação muito
similar a um grupo ou condomínio de empresas de software, com baixa integração
de processos e trocas de metodologias e experiências entre elas.
No momento em que estabelecemos os contatos iniciais com a alta gestão da
empresa, foi-nos exposta a preocupação com a qualidade dos softwares
distribuídos, refletida principalmente na quantidade de incidentes reportados pelos
clientes em relação a defeitos encontrados nos mesmos.
Também foi mencionada a dificuldade de atuar nesse sentido, devido à
carência de informações que permitissem identificar as causas dos defeitos. Os
esforços das equipes de produtos estavam altamente dirigidos para resolver os
problemas no dia-a-dia, sendo menor a dedicação a ações visando diagnóstico das
causas, planejamento e melhoria dos processos.
Outro ponto que nos foi apresentado é a grande diferença entre as várias
unidades de produtos no aspecto qualidade e processos. Em contraposição a
estruturas que vinham com ou de certificação MPS-BR e mantinham um nível mais
elevado, havia áreas em estágios muito incipientes e dependentes de iniciativa
pessoal dos colaboradores envolvidos na entrega ao cliente.
A área de qualidade da empresa, então em nível de coordenação, era nesse
momento responsabilidade de um executivo que acumulava outras funções
altamente demandantes, prejudicando o foco em atuar nessa frente.
Neste cenário, o escopo de atuação da área de Qualidade era muito restrito,
com influência limitada na definição e monitoramento de práticas e padrões. A área
atuava principalmente como um centro de prestação de serviços de testes de
regressão sobre novas versões produzidas, ou seja, entrava em cena só após a
execução todas as fases do processo de desenvolvimento anteriores.
Os efeitos negativos mais relevantes eram fortemente alinhados ao que vimos
na teoria, em relação a custos da falta de qualidade. Vários dos aspectos não eram
claramente mensuráveis, mas todos eles podem ser assumidos como presentes:
• Custo de retrabalho e correção de erros.
• Nível de ações emergenciais elevado.
82
• Solução de efeitos colaterais das correções, especialmente as efetuadas em regime de urgência.
• Suporte e atendimento a reclamações.
• Risco de danos à imagem dos produtos, serviços ou da empresa.
• Perda de clientes e/ou vendas.
3.2.2 Resultados de Levantamentos e Pesquisas
São apresentados a seguir os resultados coletados nos levantamentos e
contatos com os responsáveis pela qualidade. Optou-se por efetuar a classificação
dos mesmos já direcionada ao alinhamento com as propostas e análises que serão
apresentadas na seção seguinte.
3.2.2.1 Ações de reestruturação
Durante os contatos mais recentes para elaboração deste trabalho,
identificamos que ações de reestruturação já haviam sido adotadas em relação a
qualidade de software, que descreveremos em maior detalhe adiante. Às
informações relatadas neste detalhamento buscaremos acrescentar os resultados de
levantamentos e pesquisas efetuados junto à área, permitindo uma visão mais
abrangente e atualizada da situação.
A primeira delas foi a designação de um Diretor de Tecnologia e Processos
de Software, incluindo a Gerência de QA. Para esta posição foi nomeado um
profissional oriundo da área de processos de uma das empresas adquiridas que
tinha a certificação MPS-BR. Em paralelo, recursos desta mesma empresa
assumiram funções de liderança da área de QA, potencializando o aprendizado e
experiência obtidos durante a obtenção da certificação já mencionada.
3.2.2.2 Execução de testes e automação
As novas funcionalidades dos produtos são normalmente testadas pelas
respectivas verticais, mantendo-se a área de QA fortemente voltada à execução de
testes regressivos. Para agilizar a execução e reduzir o custo dos mesmos,
investimentos em testes automatizados vêm sendo feitos. Segundo o responsável,
busca-se obter uma relação custo-benefício com automação favorável, uma vez que
existem testes onde o investimento na automação e em posteriores atualizações não
atinge retorno considerado satisfatório.
83
3.2.2.3 Tratamento de customizações
Quanto à estratégia de execução de customizações solicitadas pelos clientes,
encontramos nas diferentes verticais de produtos os dois tipos de situação definidos
anteriormente:
• Customizações agregadas ao produto de forma controlada
Alguns dos produtos da UNIDADOS se enquadram nesta categoria,
fazendo uso de arquivos de configuração por cliente para habilitar as
customizações.
Merecem destaque aqui os produtos oriundos de empresas com
processos de software mais evoluídos, como por exemplo, as
certificadas em MPS-BR, e também os produtos oferecidos no modelo
SaaS, estes pela própria natureza intrínseca de oferecer uma versão
compartilhada.
• Customizações agregadas ao produto gerando versão específica
Esta situação aparece em muitos produtos da UNIDADOS, em alguns
casos devido a práticas legadas originadas nas empresas adquiridas.
Em outros, foi provocada pelo próprio cliente ao optar por gerir a
evolução de forma autônoma, em produtos onde existe o processo de
customização controlada na maioria dos clientes.
3.2.2.4 Produtividade e qualidade de novos recursos
Existem dificuldades na assimilação de novos recursos, envolvendo o tempo
para aprendizado de ferramentas utilizadas e assimilação das características. tanto
dos softwares em si, quanto do negócio suportado. Este fator gera baixa
produtividade e riscos de impacto na qualidade do desenvolvimento. Períodos onde
ocorrem índices de rotatividade mais elevados podem ser críticos.
3.2.2.5 Qualidade nas iniciativas com métodos ágeis
Foi reportado que o histórico de qualidade nas entregas efetuadas aplicando
métodos ágeis mostra resultados deficientes ou inconsistentes. As equipes de
desenvolvimento vêm focando na entrega rápida, muitas vezes disponibilizando
versões incrementais que apresentam índices de erros e defeitos elevados.
3.2.2.6 Dificuldade de envolvimento dos usuários
Um ponto importante para atingir a qualidade, que é o envolvimento do
usuário, interagindo ao longo de todo o ciclo de desenvolvimento, vem apresentando
84
dificuldades. Mesmo na fase de testes de aceitação, que deveriam ser conduzidos
pelos usuários, há problemas em conseguir essa participação.
Isto pode ser uma das causas dos problemas de qualidade já citados nas
entregas ágeis, uma vez que estes métodos têm como condição básica de sucesso
a presença constante do usuário junto à equipe que está criando o software.
3.2.2.7 Registro e tratamento de defeitos
Até recentemente cada produto/vertical da UNIDADOS apresentava um
processo próprio de registro de defeitos (erros reportados pelos clientes).
Enquanto alguns produtos ofereciam ao cliente acesso direto a um portal de
registro de defeitos, em outros as equipes recebiam as notificações por correio
eletrônico ou telefone, efetuando a posteriori o registro em meio magnético
(incluindo-se aqui planilhas).
Não era feito de forma geral o controle de severidade, impacto, número de
usuários/ número de clientes afetados, cumprimento de SLA. Também não existia
acompanhamento formal do tratamento do defeito, eventual solução de contorno,
identificação da causa ou solução, e providências pendentes.
Uma iniciativa de implantação de ferramenta unificada de registro dos defeitos
foi iniciada em 2018, sendo que a implantação está sendo efetuada gradativamente
nas diversas unidades.
3.2.2.8 Posições disponíveis sobre qualidade
Tivemos acesso a duas posições utilizadas na UNIDADOS, cada uma delas
com finalidade específica:
• Defeitos reportados pelos clientes
Esta posição é apresentada à Diretoria mensalmente. São reportados a
nível total e por produto as quantidades de defeitos reportadas pelos
clientes, mês a mês e acumuladas. Também são apresentadas as
metas estabelecidas para cada item.
O exemplo parcial extraído desta posição está incluído como Anexo II a
este trabalho.
• Erros encontrados pela área de qualidade
Esta posição, também mensal, mostra a quantidade de erros
encontrados pela equipe de QA nos testes de produtos efetuados a
cada mês.
85
O anexo III apresenta duas visões extraídas deste documento: dados
mensais por aplicação, em formato de tabela, e gráfico de evolução
mensal para um produto específico.
3.2.2.9 Busca e manutenção de certificações (exemplo MPS-BR)
Nos contatos a nível executivo superior e também a nível de diretoria de
processos e qualidade, colhemos a avaliação de que obter ou manter a certificação
MPS-BR envolve custos relativamente elevados, sem contrapartida de valorização
direta pelos clientes. O mesmo se aplica a certificações mais onerosas, como o
CMMI.
A decisão de empresa é, portanto, não investir mais na obtenção desse tipo
de certificação, porém continuar mantendo processos relevantes previstos na
mesma e aplicáveis à cultura, realidade e recursos da UNIDADOS.
3.2.2.10 Alocação da equipe de QA
No histórico da UNIDADOS encontramos uma sequência de mudanças na
alocação dos recursos especializados em testes em relação às verticais de produtos
e de projetos.
Em determinado ponto foi constituída uma equipe apartada, que atuava como
centro de serviços de QA, incluindo fábrica de testes, para toda a empresa.
Resultados positivos eram obtidos em alguns aspectos, porém alguns
inconvenientes e movimentos internos levaram à sua extinção, sendo os recursos
distribuídos pelas equipes, situação esta que se estendeu por vários anos. O
resultado ao longo do tempo foi uma redução da atenção a esta atividade,
impactando a qualidade como um todo.
Em momento intermediário, foi novamente criada a área, sendo os recursos
de qualidade alocados na mesma, o que garantiria em tese a dedicação focada a
esse importante aspecto. Esta era a situação quando iniciamos este trabalho, sendo
os resultados sujeitos à influência de todos os fatores envolvidos no cenário
apresentado.
Tivemos conhecimento de que atualmente está sendo planejado que
novamente os recursos de teste sejam alocados junto às verticais de produto. Os
motivos são diversos, incluindo-se aqui o argumento de que manter os recursos de
QA diretamente nas equipes de produtos propicia melhor conhecimento da área de
negócios e consequentemente melhor definição dos testes.
86
4. PROPOSTA DE MELHORIA
Os resultados obtidos nos levantamentos e contatos com representantes da
UNIDADOS foram analisados aplicando-se os conceitos pesquisados na
fundamentação teórica, sendo os comentários e propostas de solução apresentados
nesta seção.
Conforme já mencionado, a estrutura utilizada para apresentar as
informações obtidas foi criada de forma a ser replicada neste ponto do trabalho,
portanto seguiremos os mesmos tópicos. Na seção seguinte incluímos alguns
pontos adicionais que se afiguram como oportunidades de melhoria.
4.1 Ações de reestruturação
A designação de um executivo focado nos temas tecnologia, processos de
software e qualidade é uma ação acertada no sentido de aumentar a relevância
deste tema na empresa. A escolha do executivo e de elementos chave na estrutura
de unidades oriundas de empresas com histórico de maior qualidade em processos
permite que se tenha uma gestão qualificada afeita às necessidades nesse ponto.
No entanto, o sucesso das ações desta diretoria é fortemente dependente da
colaboração recebida da parte das verticais de produtos, que por sua vez é
fortemente influenciada pela postura dos executivos seniores em decisões de
estabelecimento de prioridades, alocação de recursos e em situações de conflito que
possam surgir.
Não havendo o apoio nos escalões mais elevados, é tendência inexorável das
organizações o relaxamento de políticas e processos voltados à qualidade, sob
múltiplos pretextos, levando ao insucesso total ou parcial qualquer iniciativa da área.
Não acreditamos que a UNIDADOS seja distinta da grande maioria das empresas
nesse aspecto, pelo que há necessidade de acompanhamento constante da alta
gestão.
4.2 Execução de testes e automação
O fato de a área de QA estar direcionada à execução de testes regressivos
representa uma subutilização do conhecimento disponível na equipe, que poderia
ser aplicado à definição e até execução de testes durante o ciclo de
desenvolvimento.
Esta iniciativa permitiria que as verticais de produto recebessem apoio desde
fases anteriores, aculturando-as e podendo com o tempo colaborar para detecção
precoce e redução de erros e retrabalho durante a própria codificação.
A área poderia ainda assumir postura consultiva e divulgadora em termos de
processos de software, o que criaria a cultura da empresa nesse sentido. Isto vai de
encontro ao que vimos no item 2.8, sobre a responsabilidade compartilhada pela
87
qualidade de software. Para sua concretização, todos os envolvidos devem ter
conhecimento adequado a respeito.
Quanto a automação de testes, os investimentos devem ser mantidos. Pode-
se buscar a evolução ou substituição de ferramental e frameworks de forma a tornar
mais rápida e barata a execução de testes unitários, introduzindo em maior escala
práticas como TDD, Integração Contínua e Testes Contínuos. Já Entrega Contínua e
DevOps se mostram como fora do horizonte de curto e médio prazos, sendo passos
para um futuro mais distante.
Para ajudar a otimizar o retorno com a automação, pode-se aplicar análises
como Risk Based Testing, visto no item 2.9.6, onde as prioridades são estabelecidas
com base em fatores como quantidade de defeitos, custos de correção em
produção, impactos para os clientes, etc.
4.3 Tratamento de customizações
Dado o significativo portfólio de versões que se tornaram específicas para um
cliente, não vemos grandes oportunidades de melhorias nesse item.
Estratégias e processos podem ser adotados para evitar disseminação de
novos casos, conforme observado no item 2.1.3.6, estando aqui envolvidas decisões
de arquitetura de produtos e aplicação de customizações. Devem ser ponderados
custos futuros contra economia inicial pela decisão de criar uma versão segregada.
Embora com menor probabilidade de sucesso, pode-se buscar, quando for
efetuada uma nova implementação, identificar possibilidades de refatoração parcial
das versões de alguns clientes, de forma a trazê-las mais próximo de uma estrutura
compartilhada. A partir desta identificação, decisões poderiam ser tomadas para
reduzir o passivo legado por essa multiplicidade de versões.
4.4 Produtividade e qualidade de novos recursos
Para reduzir os problemas oriundos do tempo envolvido no aprendizado
requerido pelos novos recursos, deve ser implementada uma política de gestão do
conhecimento voltada a esse ponto.
Uso de recursos simples de eficiência comprovada, como bases de
conhecimento, wikis, FAQ, além de incentivo à criação de registro e
compartilhamento de soluções já encontradas requerem recursos financeiros
pequenos em relação ao retorno potencial.
Numa escala superior, temos a aplicação de treinamentos periódicos, tanto
em aspectos técnicos das ferramentas usadas e dos próprios produtos, quanto em
características dos negócios que os mesmos de destinam a suportar.
A diretoria de tecnologia e processos pode assumir o papel de divulgar,
treinar e suportar as verticais de produtos, disseminando conceitos de processos,
88
padrões e práticas, como os que vimos na fundamentação teórica, aplicados à
realidade de cada área.
Isso pode ser feito através de treinamentos presenciais ou remotos, usando
ou não recursos de e-learning, bem como alocação temporária de recursos junto às
equipes de desenvolvimento.
4.5 Qualidade nas iniciativas com métodos ágeis
Um risco que sempre é apontado como ponto negativo dos métodos ágeis é a
redução ou até ausência de foco em documentação, processos, qualidade e testes.
Este risco foi abordado no item 2.5.2.5, onde são elencadas situações e
recomendações referentes ao processo de evolução como um todo. No tocante ao
assunto testes, já podem ser vivenciadas muitas situações práticas, onde equipes
trabalhando sob XP / SCRUM incluem apenas analistas de requisitos e
desenvolvedores, o que contraria a recomendação vista no item 2.5.2.6.2, sobre
dispor de todas as competência necessárias, Qualidade e testes tornam-se uma
preocupação menor ou ausente, face às pressões por entregas rápidas. Como
resultado, ficam expostos ao Product Owner ou aos usuários finais erros e defeitos
que um tratamento mais especializado em qualidade detectaria antecipadamente.
A solução recomendada para este ponto é um composto de duas ações:
• Recursos de qualidade são incorporados como membros da equipe de
desenvolvimento ágil, adicionando as competências de que o mesmo
carece nesse ponto. Isto contempla, por exemplo, a definição do
SCRUM, vista no item de que o time de desenvolvimento deve incluir
todas as capacidades e habilidades necessárias a produzir um
incremento válido de software.
• Cada incremento, inclusive parciais gerados durante um ciclo ou sprint,
pode ser submetido a integração e testes contínuos, automatizados
e/ou executados manualmente pela equipe de qualidade da empresa,
garantindo um teste independente.
Outro ponto importante que vem afetando estas iniciativas é o nível de
envolvimento dos usuários, abordado no próximo item.
4.6 Dificuldade de envolvimento dos usuários
Conforme vimos na fundamentação teórica, o envolvimento dos usuários é
ponto chave para o sucesso na entrega de software, sendo que nos métodos ágeis
se prescreve a presença contínua dos mesmos junto à equipe de desenvolvimento
(item 2.5.2.1) ao longo de todo o ciclo.
Esta definição fundamental se choca com a realidade vivenciada nas
empresas, onde pressões de custos levam a quadros de pessoal reduzidos e com
89
grande acúmulo de atividades, o que torna difícil liberar recursos para constante
participação no desenvolvimento de softwares.
Na situação da UNIDADOS, uma dificuldade adicional é o fato de se tratar de
uma fornecedora de software externa à organização do usuário, com acréscimo de
fatores de localização geográfica e de uso da solução por múltiplos clientes, com
exceção das customizações, que são direcionadas a um único. Envolver os clientes
sempre será altamente desafiador, porém algumas ações típicas de mercado podem
ser tentadas para minorar as dificuldades encontradas.
A primeira delas é tentar incentivar a formação de comunidades de usuários
dos produtos, para o que se pode recorrer a histórico de experiências com os
antigos grupos de usuários, às quais se adicionem recursos da era digital, como
listas de discussão, blogs, eventos via Internet, sem abrir mão de métodos mais
tradicionais como workshops, cafés da manhã presenciais, etc.
Para conseguir nível adequado de adesão é importante que seja clara para os
clientes a proposta de valor destas iniciativas.
Outra ação adotada por algumas empresas é convidar alguns clientes para
atuarem como testadores beta de novas versões. Incentivos monetários,
exclusividade de uso por período inicial, possibilidade de induzir a evolução, são
exemplos de formas de tornar esta participação atrativa.
4.7 Registro e tratamento de defeitos
O registro de defeitos já vem sendo um ponto de ação na UNIDADOS, com o
objetivo de uniformizar as informações. Gradativamente, está sendo implantada,
para cada produto, ferramenta acessada via portal Internet através da qual os
clientes efetuam o registro diretamente, sem interferências que possam distorcer as
informações. A ferramenta usada permite customização para suportar os passos
seguintes do processo, controlando o fluxo de informações e comunicação e os
tempos de solução e atendimento a SLA.
O resultado será a geração de uma base de informações estatísticas
saneada, que representa um passo adiante da situação atual. Para atender de forma
integral aos requisitos de registro e permitir posterior tratamento, devem ser
incluídas informações completas conforme vimos no item 2.10.1.
A partir do registro de um defeito, deve ser efetuado o tratamento, com
retorno ao cliente em caso de necessidade de informações adicionais. Aqui estão
incluídas análise, categorização, identificação de causa e avaliação do impacto,
resultando em categorização e priorização do mesmo.
A solução do defeito é o passo seguinte, podendo ser provisória ou definitiva,
de acordo com a dificuldade e urgência envolvidas na solução. No primeiro caso,
devem ser registradas as pendências de revisão ou refatoração no futuro. Estas
90
devem ser objeto de priorização por critérios estatísticos para direcionar ações de
melhoria.
Desta forma se implementa todo o ciclo de tratamento definido no item 2.10,
permitindo controlar e direcionar as ações de melhoria.
4.8 Posições disponíveis sobre qualidade
Tivemos acesso a duas posições utilizadas na UNIDADOS, cada uma delas
com finalidade específica:
• Defeitos reportados pelos clientes
Considerando a relevância da avaliação baseada em geração de valor
e experiência do usuário, esta pode ser considerada uma métrica
relevante, ainda que possamos encontrar oportunidades de melhoria.
A primeira delas advém do ponto já abordado no item referente à
registro de defeitos: existe ainda discrepância entre unidades e
produtos na obtenção e armazenamento dessas informações. A
solução para isso está sendo endereçada através de implantação de
ferramenta única de registro, acessada diretamente pelos clientes.
Ainda no mesmo foco, o elenco de informações registradas deve ser
completo, seguindo o que vimos na fundamentação teórica no item
2.10.1, permitindo análises baseadas em impacto e severidade, que
influenciam diretamente na experiência e valor para o cliente.
Estatísticas apontando a incidência de defeitos de maior gravidade
para o cliente devem ser incluídas, pois permitem direcionar ações de
melhoria com melhor resultado do investimento.
Finalizando, devem ser efetuados consolidação e ajuste para permitir a
comparação entre produtos. Por exemplo, um produto com 5 clientes
que tenha um defeito, potencialmente gerará 5 registros de defeitos. A
situação é muito diferente quando se tem muitas dezenas de clientes:
um único erro poderá gerar muito mais registros de defeitos.
Para ajustar esse ponto, a proposta é manter a atual posição, de
caráter quantitativo bruto, e complementá-la com uma consolidada. O
processo de tratamento deverá permitir que, após a análise, seja
possível a atribuir a causa a cada defeito, viabilizando a consolidação
de tudo que for registrado em consequência de mesma.
• Erros encontrados pela área de qualidade
Esta posição pode ser encarada como o resultado do sucesso da área
de qualidade em encontrar erros, ou seja, uma forma de medir a
produtividade da mesma.
91
No entanto, o simples número total não é suficiente para direcionar
ações de melhoria. Informações como tipo de teste executado,
quantidade de cenários executados x erros encontrados, estatística de
distribuição de severidade dos erros, entre outros, são recomendados
como indicadores mais representativos.
Da mesma forma que nos defeitos, deve-se efetuar uma análise dos
erros encontrados e associá-los a sua causa raiz. Isso permitiria ir além
da simples correção, com as verticais de produtos identificando os
pontos de melhoria com maior possibilidade de retorno do esforço
realizado, conforme abordado no item anterior.
4.9 Busca e manutenção de certificações (exemplo MPS-BR)
A decisão de não investir na busca ou manutenção de certificações como
MPS-BR pode ser entendida do ponto de vista de gestão eficiente de recursos
escassos, uma vez que não representa diretamente valor perceptível pelo cliente
final. Como apontado no item 2.11.3.2, o custo envolvido é significativo, mesmo em
um framework definido com o objetivo de reduzi-lo.
Existe em contrapartida o risco de redução do foco em melhoria de
processos, que acaba sendo uma consequência do processo que leva à certificação,
enfatizado até pelo investimento que estiver sendo efetuado para tal.
Para mitigar esse risco, será necessária uma forte atuação da área de
qualidade e processos, respaldada de forma clara e presente pela alta gestão da
empresa.
Cumpridas estas condições, a filosofia de manter os processos relevantes
previstos no modelo, abordada ao final do item 2.11.3.1, passará a apresentar
melhores perspectivas de sucesso.
4.10 Alocação da equipe de QA
A existência de uma equipe de qualidade independente das estruturas de
desenvolvimento é recomendada por todas as fontes, devido a situações como a
que foi citada no item 2.9.3, que trata da responsabilidade pela execução de testes
de software. Existe uma tendência natural a acomodação e complacência quando os
recursos de qualidade são parte integrante das equipes de desenvolvimento, pelo
conflito de interesses envolvido quando se aponta erro no software.
Por outro lado, o distanciamento entre a área de qualidade e as áreas de
desenvolvimento, agravado pelos fatores geográficos e de culturas distintas
agregadas na UNIDADOS, gera maior dificuldade de comunicação, conhecimento e
entendimento das necessidades. Existe também a fricção entre as equipes de
92
qualidade e de produtos que, aparentemente, tem objetivos distintos que podem
levar a situações de conflito.
A oscilação da empresa entre esses dois modelos evidencia a dificuldade de
adotar qualquer um dos dois extremos, com as pressões levando a mudanças de
política periodicamente.
93
5. CONCLUSÃO
O objetivo deste trabalho foi identificar elementos de teoria formal referentes a
processos e práticas relacionados à qualidade de software, e na sequência usá-los
para avaliar uma situação prática real, para o que nos foi dada oportunidade em uma
empresa líder de seu segmento no mercado nacional.
Foi possível identificar a correspondência entre os autores consultados e as
situações práticas encontradas. Em um ciclo de realimentação, alguns resultados do
levantamento levaram a aprofundamento da pesquisa teórica, contribuindo para o
aprendizado e melhorando o produto final.
Constatamos que a empresa apresenta um cenário altamente desafiador para
a implantação de processos de melhoria de software. Num mercado competitivo que
demanda agilidade e respostas a curto prazo, inclusive nos próprios resultados
financeiros, podem ser compreendidas algumas opções que levaram à situação
atual. No entanto, custos gerados por deficiência na qualidade já são percebidos, o
que levou à intensificação de esforços para evoluir nesse ponto. Claramente,
existem grandes oportunidades de melhoria dos resultados obtidos.
O resultado da análise mostra que muitas das medidas já em prática estão de
acordo com as recomendações vistas na fundamentação teórica, sendo identificados
e apresentadas algumas sugestões complementares. Outras medidas, que não
seguem exatamente a previsão teórica, devem ser monitoradas para detectar
possíveis desvios. Eventualmente devam ser objeto de revisão e adaptação que
mantenha as vantagens buscadas sem incorrer em riscos já conhecidos.
Este é particularmente o caso da transferência dos recursos de teste para a
equipe de desenvolvimento. A recomendação aqui é pela adoção de um modelo
híbrido, onde recursos de qualidade atuem vinculados às equipes de
desenvolvimento sob supervisão, monitoramento e avaliação constante da área
central de qualidade, que deve contar com poderes necessários para tal.
A área de qualidade deve ainda manter uma equipe independente própria
para formulação de definições e políticas, treinamento e suporte aos recursos
distribuídos e às verticais de produtos, execução de tipos especializados de testes, e
também para executar periodicamente ações especiais de verificação detalhada
direcionadas a um produto ou módulo.
Outro ponto que representa oportunidade de melhoria é a busca de sinergia e
troca de experiências envolvendo equipes ou unidades onde os processos de
software se apresentem em estágio superior. Um movimento neste sentido deverá
enfrentar reações naturais, que devem ser abordadas via condução hábil e
colaborativa acompanhada de apoio de gestão superior.
94
Já vemos este movimento em fase inicial, tendo em vista que uma área com
processos mais avançados já assumiu esse papel ao fornecer os recursos que
lideram as iniciativas visando melhor qualidade.
A diretoria de pesquisa e desenvolvimento também se destaca nesse
aspecto. A experiência nela obtida oferece a oportunidade de interação com as
verticais de produtos para compartilhamento de resultados. O fato de atuar na
mesma organização, mesma cultura, mesmos mercados e, em muitos casos, estar
desenvolvendo para as mesmas linhas de produto, tornam esse conhecimento muito
mais aplicável do que casos de grande sucesso oriundos de organizações externas.
Outra oportunidade com grande potencial de trazer retornos relevantes é a
plataforma de inovação instituída pela UNIDADOS. Pode-se buscar, respeitando as
limitações de cultura e recursos, e sempre ponderando que se trata de um ambiente
de experimentação prática, fomentar a participação de recursos das verticais de
produtos nas iniciativas dessa plataforma, de modo a vivenciar experiências que
possam ser adaptadas para gerar evolução e valor para as estruturas atuais.
Durante o trabalho, foi elaborado o formulário de levantamento sobre
processos, práticas e qualidade de software, incluído como Anexo I. Este
questionário foi enviado à Diretoria de Tecnologia e Processos de Software, para
centralização do encaminhamento às diversas áreas de produtos e coleta do
retorno.
No formulário são abordados de forma sucinta os seguintes itens:
• Processos de software.
• Técnicas e ferramentas.
• Organização da qualidade de software.
• Tipos de teste executados.
• Tratamento de defeitos.
• Melhoria de processos.
Não foi possível obter o retorno dos resultados em tempo hábil para inclusão
e análise neste trabalho. Acreditamos que os mesmos poderão ser úteis para ajudar
a planejar a evolução de processos na UNIDADOS, e que o próprio formulário pode
servir como base para criar uma estrutura mais extensiva de avaliação e
acompanhamento das diferentes unidades.
Adicionalmente, poderá desempenhar o papel de ferramenta de avaliação dos
processos usados em empresas em momento de aquisição, que é situação
frequente na história da empresa, permitindo medir e planejar os esforços
necessários para melhor integrá-las neste aspecto.
95
A convergência das iniciativas em andamento, acrescidas da aplicação de
propostas formuladas, pode ser, em momento oportuno, formalizada como uma
política ou programa a nível da empresa como um todo.
Na elaboração do mesmo, a área de processos e qualidade pode ter papel de
liderança, porém o envolvimento e colaboração das áreas de produtos é condição
implícita para o sucesso. É preferível negociar, traçar e atingir com sucesso objetivos
de forma gradual, porém constante e crescente, a impor mudanças ambiciosamente
fora da realidade que terão de ser rapidamente descartadas em situações críticas.
O patrocinador deste programa deverá contar com nível de alçada suficiente
para oficializar metas, alocar os recursos necessários e atuar para garantir o efetivo
cumprimento das ações definidas.
96
REFERÊNCIAS BIBLIOGRÁFICAS
AMORIM, Luan F. Histórico da qualidade: uma passagem pela produção e as
suas ferramentas. Disponível em
<<https://www.administradores.com.br/artigos/academico/historico-da-qualidade-
uma-passagem-pela-producao-e-as-suas-ferramentas/89498/>> Acesso em 29 jan
2019.
BOEHM, B. W. A Spiral Model of Software Development and Enhancement. IEEE
Computer, v. 21, n. 5,1988, p. 61-72.
CMMI. What is CMMI®? <<Disponível em <<https://cmmiinstitute.com/cmmi/intro>>.
Acessado em 27 fev 2019.
DEVMEDIA. Gestão de defeitos: Ferramentas Open Source e melhores práticas
na gestão de defeitos. Disponível em <<https://www.devmedia.com.br/gestao-de-
defeitos-ferramentas-open-source-e-melhores-praticas-na-gestao-de-
defeitos/8036>>. Acessado em 13 fev 2019.
GUCKENHEIMER, Sam. What is DevOps? Disponível em:
<<https://docs.microsoft.com/en-us/azure/devops/learn/what-is-devops>> Acesso em
6 fev 2019.
GARVIN, D. What Does ‘Product Quality’ Really Mean? Sloan Management
Review, Fall 1984, p. 25–45.
GARVIN, D. Competing on the Eight Dimensions of Quality. Harvard Business
Review, November 1987, p. 101–109.
GURU99. Risk Based Testing: Approach, Matrix, Process & Examples.
Disponível em <<https://www.guru99.com/risk-based-testing.html>> Acesso em 12
fev 2019.
97
ISDBRASIL. CMMI-Dev V2.0 Potencializando benefícios para sua organização.
Disponível em <<http://www.isdbrasil.com.br/artigos/cmmi2.0.php>> Acesso em
29/02/2019.
JOIA, Luiz Antonio. Et al. Gestão Estratégica da Tecnologia da Informação. 1ª ed.
Editora FGV, 2012.
LEFFINGWELL, D. Scaling Software Agility: Best Practices for Large
Enterprises. Addison-Wesley, 2007.
LEHMAN, M., et al.; Metrics and Laws of Software Evolution—The Nineties View. 4th
International Software Metrics Symposium, IEEE, 1997,
MANIFESTO_AGIL. Manifesto para o desenvolvimento ágil de software.
Disponível em <<http://www.manifestoagil.com.br>> Acessado em 27 jan 2019.
MCCALL, J., P. Richards, and G. Walters; Factors in Software Quality. NTIS, 1977.
MOORE, E; Spens,,J.; Scaling Agile: Finding your Agile Tribe. Agile 2008
Conference. IEEE Computer Society, Toronto, 2008, p. 121-124.
MPS-BR Guia Geral Software. Softex, 2016.
PRESSMAN, Roger S.; Maxim, Bruce R. Engenharia de Software: Uma
Abordagem Profissional. McGraw Hill, Porto Alegre, 2016.
ROYCE, W. W. Managing the Development of Large Software Systems:
Concepts and Techniques. Proc. WESCON, 1970.
RUP – Rational Unified Process – Best Practices for Software Development Teams.
Rev 11/01 Rational Software, 2001
SCRUM.org. What is Scrum? Disponível em
<<https://www.scrum.org/resources/what-is-scrum>> Acessado em 19 jan 2019.
98
SCRUMHALF. User Stories – O que são? Como Usar? Disponível em
<<http://blog.myscrumhalf.com/2011/10/user-stories-o-que-sao-como-usar/>>
Acessado em 30 jan 2019.
SMARTBEAR. What is Automated Testing Disponível em
<<https://smartbear.com/learn/automated-testing/what-is-automated-testing/>>
Acessado em 14 fev 2019.
SOMMERVILLE, I. Engenharia de Software. Person Prentice Hall, 2011.
TESTING EXCELLENCE. Common Myths of Test Automation – Software
Testing Disponível em <<https://www.testingexcellence.com/common-myths-test-
automation/>> Acessado em 14 fev 2019.
YORDON, E. Análise Estruturada Moderna Editora Campus, 1990.
99
ANEXOS
Anexo I - Formulário - Levantamento sobre Qualidade e Processos de Software
Grupo Item Observações XXXXX YYYYY ...
Existe definição formal de processos Sim / Não
Aplicação deles -e monitorada Sim / Não/NA
Inserção de documentação de código
Mandatória,
Recomendada
ou Opcional
Usa métodos ágeis Sim / Não
Usa XP (Extreme Programming) Sim / Não
Usa SCRUM Sim / Não
Outro método ágil Informar
Mantém backlog de itens para evolução Sim / Não
Se há backlog, existe método de
priorizaçãoSim / Não/NA
Usa frameworks de desenvolvimento Sim / Não
Desenvolvimento incremental Sim / Não
Orientação a Objetos Sim / Não
Prototipação Sim / Não
TDD - Desenvolvimento Dirigido a Testes Sim / Não
Refatoração de código Sim / Não
Programação em pares Sim / Não
Integração contínua Sim / Não
Revisão requisitos Sim / Não
DevOps Sim / Não
Revisão projeto Sim / Não
Revisão código Sim / Não
Testes automatizados Sim / Não
Testadores na equipe de
desenvolvimentoSim / Não
Equipe de QA independente Sim / Não
Planejamento de testes Sim / Não
Gestão de Configuração Sim / Não
Processos
de software
Técnicas e
Ferramentas
Organização
da
Qualidade
de Software
100
Testes de unidade Sim / Não
Testes de integração Sim / Não
Testes de fumaça Sim / Não
Testes de regressão Sim / Não
Testes de aceitação Sim / Não
Testes de validação Sim / Não
Testes de recuperação Sim / Não
Testes de segurança Sim / Não
Testes de esforço Sim / Não
Testes de desempenho Sim / Não
Testes de disponibilização Sim / Não
Teste Baseado em Riscos Sim / Não
Ferramenta especializada para registro Sim / Não
Registro de defeitos pelos clientes Sim / Não
Análise estatística das causas Sim / Não
Priorização das causas para correção Sim / Não
Existe iniciativa interna em andamento Sim / Não
Certficação CMMI Sim / Não
Certificação MPS-BR Sim / Não
Outra Certificação Informar
Melhoria de
Processos
Tipos de
teste
executados
Tratamento
de Defeitos
101
Anexo II - Relatório Estatístico Acumulado - Defeitos apontados pelos clientes
Apresentado em nível de diretoria.
102
Anexo III - Relatório de Erros encontrados pela área de Qualidade
Anexo III – A - Dados mensais por aplicação
Anexo III – B - Dados mensais para uma aplicação (exemplo)