FATEC CURSO ADS

DISCIPLINA TESTES DE SOFTWARE

NOTAS DE AULA
2º. SEM 2023

Prof. Edson Saraiva de Almeida

CENTRO PAULA SOUZA
 Fatec – Curso de Análise e Desenvolvimento de Sistemas
Disciplina – Teste de Software
Prof. Edson Saraiva de Almeida
01 - Fundamentos de Teste de Software

Objetivos de aprendizagem:

• Reconhecer a importância de se contabilizar os custos das falhas para justificar os investimentos no controle da
qualidade.
• Compreender o conceito de qualidade de software e como as atividades de teste contribuem para o controle da qualidade.
• Se familiarizar com um modelo de avaliação da capacidade e de maturidade do processo de teste para identificar um
conjunto de boas práticas que podem ajudar pequenas e médias organizações de desenvolvimento de software na
melhoria de seus processos de desenvolvimento de software e teste.

1 Introdução
Sistemas de software estão se tornado cada vez mais complexos e difíceis de construir e desempenham um papel cada vez mais
importante na economia e na sociedade de maneira geral. Nesse contexto existe uma pressão para que organizações de
desenvolvimento de software se concentrem nas questões de qualidade para se manterem competitivas em um mercado globalizado.
Software de baixa qualidade não é mais aceitável na sociedade. Falhas de software podem resultar em enormes perdas de negócios
ou mesmo se tornar catastróficas, quando por exemplo, envolvem perda de vidas humanas.

O teste de software é uma atividade dinâmica que tem como objetivo executar um programa utilizando algumas entradas em
particular e verificar se seu comportamento está de acordo com o esperado. Caso a execução apresente resultados não esperados,
dizemos que uma falha foi identificada.

O caso de teste da Figura 1 verifica o comportamento do sistema na inclusão de um cliente com sucesso. Neste exemplo, a
especificação do caso de teste inclui a navegação no sistema e a massa de dados. Uma condição de teste (objetivo de teste) estabelece
um cenário de uso da aplicação.

ID (identificador) CT101UC76
Objetivo (condição de teste) Verificar o comportamento do sistema na inclusão de um cliente com sucesso
Pré-condições O cliente CNPJ 15.794.489/0001-98 não está cadastrado
Procedimentos Resultados esperados
1 Selecionar a opção no menu “Cadastrar cliente “ O sistema apresenta a tela de cadastro
No campo “Nome” digitar “Empresa 1” no campo O sistema apresenta a mensagem: “Cliente
2 “CNPJ” digitar “15.794.489/0001-98” no campo endereço cadastrado com sucesso”.
digitar “Rua Frei João” em seguida confirmar a operação.

Figura 1 - Exemplo para uma condição específica de entrada e o resultado esperado

O teste ajuda a medir a qualidade de um software em termos do número de defeitos encontrados durante a execução, portanto o teste
de software consiste em uma atividade de controle da qualidade. O objetivo da atividade de teste de software é encontrar um defeito
ainda não detectado. Um bom caso de teste é aquele que tem alta probabilidade de encontrar um defeito.

A importância da atividade de teste de software como uma das medidas de controle da qualidade está crescendo rapidamente. Como
o mercado está exigindo produtos melhores e mais confiáveis, desenvolvidos e produzidos em menos tempo, com menor custo, a
eficácia da atividade de teste não é mais uma opção é um ingrediente essencial para o sucesso.

1.1 Falhas em Projetos de Software

O Standish Group International, Inc. é uma empresa internacional independente de consultoria em pesquisa de TI fundada em 1985,
que avalia projetos de desenvolvimento de software envolvendo mais de 300 organizações no setor público e privado. No ano de
2015 o relatório foi publicado com a avaliação dos resultados de acordo com os seguintes critérios:

• Sucesso – o projeto foi concluído no prazo, e no orçamento planejado com todas as funções se comportando de acordo
com as especificações
• Parcialmente (existe alguma contestação) – o projeto foi concluído e implantado, mas, com um custo superior ao orçado
e prazo superior ao estimado e oferece algumas das funções originalmente especificadas
• Cancelados – o projeto foi cancelado em algum ponto durante o ciclo de desenvolvimento

No geral, a taxa de sucesso foi de apenas 29%, enquanto os projetos com sucesso parcial (com alguma contestação) representaram
52% e os cancelados representaram 19%. O estudo mostrou também que entre as principais causas de fracasso para os projetos
que tiveram sucesso parcial são: omissão de requisitos 12.8%, especificação de requisitos incompleta 12,3% e mudanças na
especificação de requisitos 11.8%, ou seja, as principais causas de fracasso se devem a fatores associados a engenharia de
requisitos.

1
De acordo com Charette (2005) a maior parte das falhas em projetos de software são previsíveis e evitáveis. Muitas dessas
organizações não consideram a prevenção de falhas como uma questão importante, mesmo que esta visão possa levá-las a falência.
Durante o processo de desenvolvimento de software defeitos são introduzidos na sua construção, existe uma série de atividades,
chamadas coletivamente de “Validação, Verificação e Teste”, ou “VV&T”, com o objetivo de garantir que o modo pelo qual o
software está sendo construído esteja em conformidade com sua especificação.

As atividades de teste de software consomem muito tempo e muitos recursos. Em função de limitações de prazos ou orçamento,
muitas vezes o teste de software é negligenciado e, consequentemente, o software é entregue ao usuário com defeitos que provocam
falhas em seu uso cotidiano. A eficácia do teste de software é um fator importante para se controlar a qualidade de um software e o
custo dessa atividade é limitador de sua aplicação efetiva. Neste contexto é fundamental se utilizar de técnicas que maximizem a
eficácia das atividades de teste a um custo reduzido. A priorização dos casos de teste de maneira a concentrar o esforço de teste em
requisitos que tem mais prioridade e considerar aspectos de testabilidade no processo de desenvolvimento de software pode
aumentar a eficácia das atividades de teste. A análise da causa raiz das falhas permite identificar as necessidades de melhoria para
aprimorar o processo de desenvolvimento de software com a diminuição de defeitos.

No desenvolvimento de software o programador pode cometer um erro que pode levar à introdução de um defeito no código. Um
erro que leva à introdução de um defeito em um produto de trabalho pode levar à introdução de defeitos em outros produtos de
trabalho relacionados.

Por exemplo, um erro de elicitação de requisitos pode levar a um defeito no documento de especificação de requisitos, o que resulta
em um defeito de programação do código. Se a linha com defeito no código for executada, pode causar uma falha, mas não
necessariamente em todas as circunstâncias. Um defeito no código pode causar uma falha, mas não necessariamente em todas as
circunstâncias, por exemplo, alguns defeitos requerem uma entrada muito específica para disparar uma falha, a qual pode ocorrer
raramente ou nunca ocorrer. Por exemplo, alguns defeitos exigem entradas ou pré-condições muito específicas para provocar uma
falha, que pode ocorrer raramente ou nunca.

Por exemplo, supondo o cálculo de juros no pagamento da fatura tem um defeito, em uma aplicação de e-commerce, resultando em
reclamações do cliente. O código com defeito foi escrito para uma história de usuário que foi descrita de maneira ambígua, devido
à incompreensão do analista de negócio sobre como calcular os juros. Supondo que outros defeitos foram detectados, e esses defeitos
têm sua causa raiz em mal-entendidos semelhantes, a equipe pode ser treinada para reduzir problemas dessa natureza no futuro.

Neste exemplo, as reclamações dos clientes refletem as consequências da falha do software. A falha é identificada ao se calcular de
maneira incorreta o pagamento de juros. O cálculo incorreto no código é um defeito que tem origem na história de usuário descrita
de maneira ambígua que identifica a causa raiz do problema que resultou no erro do analista ao escrever a história do usuário (Figura
2).

Erro Defeito Falha

Figura 2 - Relação entre erro defeito e falha

A análise da causa raiz das falhas identificam as ações ou condições iniciais que contribuíram para introdução de defeitos no
software. Ao analisar a causa-raiz mais significativa pode-se identificar necessidades de melhorias no processo de desenvolvimento
do software que impeçam a introdução de defeitos futuros.

1.2 Custos da Falha

Para o software, os custos das falhas não são claramente compreendidos. Frequentemente, esses custos desaparecem nos custos
gerais de desenvolvimento ou nas despesas operacionais. Os custos para o usuário final também são negligenciados. Pode-se
classificar os custos da qualidade em custos de prevenção e custos de falha. Recomenda-se identificar as atividades realizadas
dentro de cada uma dessas categorias e mensurar os custos associados às atividades. Deve-se, portanto, estabelecer mecanismos
para registrar e estruturar os custos de falhas internas e externas no momento de sua ocorrência (GROTTKE,2009).

A execução de testes pode detectar falhas causadas por defeitos no software em um cenário de uso específico. A depuração
(debug) é a atividade de desenvolvimento que localiza, analisa e corrige esses defeitos Em seguida o teste de confirmação verifica
se as correções resolveram os defeitos e um pacote para implantação é preparado. Uma estimativa da quantidade média de falhas
por dia é calculada e o esforço médio por falha é estabelecido (Tabela 1).

2
 Tabela 1 – Exemplo para estimativa de custo da falha

Falhas dia Quant mês Esforço médio por falha Esforço mês Valor h Custo total
Empresa 1 3 66 6h 396h R$ 60,00 R$ 23.760,00
Empresa 2 2 44 8h 352h R$ 60,00 R$ 21.120,00
Empresa 3 4 88 6h 528h R$ 60,00 R$ 32.680,00

As informações devem ser obtidas nos departamentos de suporte a cliente ou em entrevista dos pares envolvidos no processo de
desenvolvimento e manutenção de software. O custo da prevenção também deve ser calculado, para possibilitar uma gestão
adequada priorizando aspectos que tem maior impacto na ocorrência de uma falha. Organizações que mantem uma disciplina em
contabilizar suas falhas tem mais motivação para investir em qualidade diminuindo o desperdício (Figura 3).

Idealmente os defeitos devem ser removidos na mesma fase do ciclo de vida do processo de desenvolvimento de software, porque
o custo para encontrar e remover defeitos incrementa cada vez que o defeito é encontrado em uma fase posterior na qual foi inserido.

Figura 3 - Estimativa do incremento do custo por fase (GRAHAN, 2021)

Um fator determinante para falhas em projetos de software está relacionado a falta de maturidade na Gestão da Qualidade do
Software (GQS).

2 Qualidade de Software
Para uma organização de desenvolvimento de software não é suficiente afirmar que a qualidade de software é importante, é
necessário definir explicitamente o que quer dizer “qualidade de software” (PRESSMAN, 2006).

Muitas organizações relacionam a atividade de QA (Quality Assurance) com as atividades de testes de software. As atividades de
garantia da qualidade fazem parte de um conceito de gerenciamento da qualidade que envolvem vários aspectos. A qualidade é o
resultado não somente do desenvolvimento de software, mas também dos procedimentos de contratação e treinamento de recursos
humanos, processo de entrega, até como, um colaborador atende ao telefone (GRAHAN, 2021).

A qualidade de software pode ser descrita como um conjunto de características que devem ser alcançadas em um determinado grau
para que o produto atenda às necessidades de seus usuários (Figura 5). Torna-se, portanto, necessário identificar quais são as
características de qualidade necessárias para um determinado produto de software e definir em que grau essas características
precisam ser alcançadas para satisfazer as necessidades dos usuários. Com base nestas características, deve-se estabelecer um
conjunto de atividades que ajudarão a garantir que todo o produto de trabalho gerado no processo de desenvolvimento de software
atende as características de qualidade estabelecidas, realizar atividades de controle de qualidade em todo o projeto e utilizar métricas
para desenvolver estratégias com objetivos de aperfeiçoar o processo de software e, como consequência, a qualidade do produto
(Rocha, 2001).

3
 Figura 4 - Características e subcaracteríscas de qualidade (ESTDALE, 2018)

A suposição fundamental da gerência de qualidade é que a qualidade do processo de desenvolvimento afeta diretamente a qualidade
dos produtos entregues. O gerenciamento da qualidade e a melhoria da qualidade de processo podem gerar softwares com menos
defeitos (SOMMERVILLE, 2011).

Pequenas empresas de desenvolvimento de software têm dificuldades em relacionar as normas e modelos de qualidade, com as suas
necessidades de negócio e justificar o esforço e o custo em aplicar estas normas às suas práticas de desenvolvimento de software,
considerando que seus recursos são escassos. É fundamental portanto para estas organizações obter evidências das necessidades de
melhoria e treinar mão de obra qualificada em modelos de melhoria de processos de teste, para incorporar práticas de controle da
qualidade no seu processo de desenvolvimento de software.

3 Melhoria do Processo de Teste

Pequenas e médias organizações de desenvolvimento de software influenciam os resultados econômicos de produção de software
no Brasil e no mundo. Muitas dessas organizações desenvolvem software utilizando práticas orientadas ao debug para controle da
qualidade, ou seja, não diferenciam a atividade de teste da atividade de debug. Por outro lado, as atividades de teste de software
consomem muito tempo e muitos recursos. Em função de limitações de prazos ou orçamento, muitas vezes o teste de software é
negligenciado e, consequentemente, o software é entregue ao usuário com defeitos que provocam falhas em seu uso cotidiano.

Identificar um conjunto de práticas de teste de software que possa ser utilizado por pequenas e médias organizações de
desenvolvimento de software, pode ajudar estas empresas a se tornarem mais produtivas e melhorar a qualidade do produto entregue.

A adoção de modelos de qualidade por pequenas e médias organizações de desenvolvimento de software frequentemente é
negligenciada por uma percepção de que estes modelos não são flexíveis ou adaptáveis para esse mercado.

Software Process Improvement (SPI) é a melhoria contínua da qualidade do produto considerando a eficácia do processo. A melhoria
do processo de teste está relacionada ao contexto do processo de desenvolvimento do software. Melhorias no processo de teste
podem indicar que melhorias associadas ou complementares são necessárias para o gerenciamento de requisitos e outras partes do
processo de desenvolvimento. Por outro lado, as melhorias no processo de teste podem ser impulsionadas pelos esforços gerais do
SPI.

A melhoria contínua envolve estabelecer objetivos de melhoria, tomar medidas para alcançá-los e, uma vez alcançados, estabelecer
novos objetivos de melhoria. Modelos de Melhoria Contínua como PDCA (PITTMAN, 1998) ou IDEAL (KAUTZ, 2000) foram
estabelecidos para apoiar este conceito.

3.1 Abordagens baseadas em modelos

Apesar do fato de que o teste pode ser responsável por partes substanciais dos custos do projeto, organizações de desenvolvimento
de software tem muitas dificuldades em estabelecer as diretrizes para um processo de melhoria. No contexto do teste de software
duas abordagens de melhoria podem ser adotadas: (i) utilizar modelos de melhoria que prescrevem as atividades que devem ser
consideradas na melhoria do processo, exemplo Test Maturity Model integrated (TMMi) e TPI Next; (ii) modelos não prescritivos
ou seja não exigem que a melhoria seja realizada em uma ordem específica, exemplo Systematic Test Evaluation Process (STEP)
e o Critical Testing Process (CTP).

4
3.2 Abordagens analíticas
As abordagens analíticas normalmente envolvem a análise de medidas e métricas específicas para avaliar a situação atual em um
processo de teste, decidir quais etapas de melhoria tomar e como medir seu impacto. A abordagem Goal-Question-Metric (GQM)
é um exemplo típico de uma abordagem analítica.

3.3 Outras abordagens

A melhoria do processo de teste pode ser suportada pelo treinamento da equipe no gerenciamento das atividades de teste. A
melhoria também pode ser obtida pelo uso de ferramentas de apoio a automação das atividades de teste. Agencias de regulação
podem estabelecer requisitos para o processo de teste do software.

4 Melhoria baseada em Modelos

Um modelo descreve o que seus autores consideram as melhores práticas. A organização deve avaliar as praticas sugeridas pelo
modelo no contexto da organização. O modelo TMMi (VEENENDAAL,2012) é um modelo para avaliação da capacidade e
maturidade de processos de teste de software na indústria. Originalmente inspirado no CMMi (KHRAIWESH, 2020) o TMMi
fornece um guia para avaliação e melhoria do processo de teste de uma organização. A Figura 4, mostra a estrutura e os
componentes do modelo TMMi. O modelo é estruturado em níveis de maturidade de 1 a 5.

Figura 5 - TMMi níveis de maturidade e áreas de processo

Cada nível de maturidade tem várias áreas de processo (PA – Processs Area), e cada área de processo tem vários objetivos
específicos (SG – specific goals) e práticas especificas (SP –specific practices) (Figura 5).

Figura 6 - TMMi estrutura e componentes

5
Por exemplo, no nível 2 gerenciado, existem cinco áreas de processo (PA – process área).

Figura 7 - TMMi áreas de processo do nível 2

A Figura 7 desdobra a área de processo PA 2 Gerenciado em três objetivos específicos (Specific Goals). O objetivo específico
“SG1” se desdobra e três práticas especificas (Specific Practices).

Figura 8 – Objetivos e práticas especificas da área de processo “PA2.1 – Política de teste e estratégia” com exemplos

A Figura 8 desdobra a área de processo PA 2.4 Projeto de Teste e execução que envolve a automação de teste.

Figura 9 – Objetivos e práticas específicas da área de processo “PA2.4 Projeto de teste e execução” com exemplos

6
Com base nas áreas de processo selecionadas do nível gerenciado, pode-se comparar o modelo com as práticas de teste propostas
pela organização de desenvolvimento de software analisada, considerando se atende, se atende parcialmente ou se não atende as
práticas propostas no modelo (Figura 8).

Figura 10 - Diagnóstico das práticas realizadas na organização

O diagnóstico do processo atual permite que a organização desenvolva um plano de como satisfazer os pontos insatisfatórios para
melhorar seu processo de teste e de desenvolvimento de software.

Referencias

• CHARETTE, Robert N. Why software fails. IEEE spectrum, v. 42, n. 9, p. 36, 2005
• ESTDALE, John; GEORGIADOU, Elli. Applying the ISO/IEC 25010 quality models to software product. In: Systems,
Software and Services Process Improvement: 25th European Conference, EuroSPI 2018, Bilbao, Spain, September 5-7,
2018, Proceedings 25. Springer International Publishing, 2018. p. 492-503.
• GROTTKE, M.; GRAF, C. Modeling and Predicting Software Failure Costs. 33rd Annual IEEE International Computer
Software and Applications Conference, 2009.
• GRAHAM, Dorothy; BLACK, Rex; VAN VEENENDAAL, Erik. Foundations of software testing ISTQB Certification.
Cengage Learning, 2021.
• KAUTZ, Karlheinz; HANSEN, Henrik Westergaard; THAYSEN, Kim. Applying and adjusting a software process
improvement model in practice: the use of the IDEAL model in a small software enterprise. In: Proceedings of the 22nd
international conference on Software engineering. 2000. p. 626-633.
• PRESSMAN, R., Engenharia de Software, 6ed., São Paulo: McGraw-Hill, 2006 (cap 13 – estratégias de teste)
• SOMMERVILLE, I., Engenharia de Software, 9ed., São Paulo: Pearson Prentice Hall, 2011 (Cap. 2, 26)
• PITTMAN, William D.; RUSSELL, Gregory R. The Deming cycle extended to software development. Production and
inventory management journal, v. 39, n. 3, p. 32, 1998.
• ROCHA, A. R. C., MALDONADO, J. C., WEBER, K. C. Qualidade de Software: Teoria e Prática. São Paulo: Prentice
Hall, 2001
• VAN VEENENDAAL, Erik; WELLS, Brian. Test maturity model integration (TMMi). TMMI Foundation (www.
tmmifoundation. org), Uitgeverij Tutein Nolthenius, 2012.
• KHRAIWESH, Mahmoud. Measures of Organizational Training in the Capability Maturity Model Integration (CMMI).
International Journal of Advanced Computer Science and Applications, v. 11, n. 2, 2020.

7
 Fatec - Curso: Análise e Desenvolvimento de Sistemas
Disciplina – Teste de Software
Prof. Edson Saraiva de Almeida
02 - Atividades de Controle da Qualidade no Processo de Desenvolvimento de Software
Objetivos de aprendizagem - Reconhecer a importância de se estabelecer um modelo de processo de referência para
desenvolvimento de software. Compreender o conceito de pronto nos modelos de processo de desenvolvimento de software
(Clássico, Modelo V, Interativo e Incremental e Computação Orientada a Serviços). Aplicar atividades de controle da qualidade no
processo de desenvolvimento de software para argumentar com base em informações confiáveis, se um artefato está concluído e
segue as diretrizes de qualidade estabelecidas para o projeto (definição de pronto). Compreender o conceito de melhoria de processo

1 Introdução
O primeiro passo, para organizar as atividades que devem ser realizadas em uma empresa na produção de software, é estabelecer o
Processo de Desenvolvimento de Software (PDS). Para o sucesso no estabelecimento e na evolução dos processos de software, além
de conhecer os métodos e processos de engenharia de software, é fundamental que outros aspectos sejam considerados. Por exemplo,
as características do produto, do projeto, a cultura organizacional, as necessidades estabelecidas pelo cliente, o ambiente, as
tecnologias utilizadas, devem ser consideradas.

Um PDS estabelece um conjunto de atividades que devem ser seguidas na construção do software. Um requisito básico de qualidade
relacionado ao processo de desenvolvimento é que a atividade deve ser sistemática e passível de repetição, independentemente de
quem as execute. Quanto ao produto de software, é também fundamental que sua qualidade seja independente de quem a produziu.

2 Modelos de Processo
Modelos de processos são prescritivos, definem um conjunto de atividades, marcos e produtos de trabalho para permitir a entrega
de software com qualidade. Atividade é um passo do processo que produz mudanças de estado visíveis externamente ao produto de
software. Exemplos de atividades seriam teste do software, elicitação de requisitos, implementação etc. Produto de trabalho é um
artefato produzido ou consumido em uma atividade. Modelos de processos podem ser adaptados, para atender as necessidades da
equipe em projetos específicos. Existem normas e modelos de qualidade que apoiam a definição de processos de desenvolvimento
de software a NBR ISO/IEC 12207 (ISO,1998) é um exemplo. É possível utilizar normas e modelos de qualidade para se definir o
processo de desenvolvimento de software para projetos específicos, considerando as particularidades de cada projeto.

O modelo descritivo de um processo inclui as atividades e eventualmente subatividades e os artefatos gerados como produto de
trabalho. A descrição do modelo de processo pode ser realizada utilizando linguagem natural (texto) ou em uma linguagem mais
formal, por exemplo, utilizando uma notação gráfica.

Nos modelos de processo preditivos (Cascata) o desenvolvimento do projeto é linear através de fases sequenciais distintas, os
objetivos são determinados no início do projeto e só podem ser alterados através de um controle formal. Esse modelo é
particularmente adequado quando o produto deve ser entregue completo para ter valor. Nos modelos de processo interativo e
incremental, o produto é desenvolvido por meio de ciclos de interações sucessivas, cada interação inclui novas funcionalidades
(incrementos) na versão anterior do produto, obtendo vantagem das lições anteriormente aprendidas. Nestes modelos uma visão de
alto nível é desenvolvida para o empreendimento em geral, mas o escopo detalhado é elaborado a cada interação. Em modelos
adaptativos ou ágeis o desenvolvimento do trabalho é realizado por meio de pequenos ciclos interativos e incrementais, geralmente
com duração e recursos fixos, essa abordagem é particularmente apropriada quando existe indefinição do escopo.

2.1 Modelo Cascata

O modelo em cascata, algumas vezes chamado de ciclo de vida clássico, Cascata ou Watefall, sugere uma abordagem sistemática e
sequencial para desenvolvimento de software que começa com a especificação dos requisitos pelo cliente e progride até a
implantação do software acabado. Devido ao encadeamento de uma fase em outra, esse modelo é conhecido como modelo cascata
(Figura 1). O modelo é caracterizado pelos seguintes aspectos (SOMMERVILLE, 2007, Cap 4, pag 44):
• O resultado de cada fase consiste de um ou mais documentos aprovados (“assinados”)
• A próxima fase só é iniciada quando a fase anterior estiver concluída e aprovada. (uma definição comum de “Pronto” deve
ser compartilhada por aqueles que realizam o trabalho e por aqueles que aceitam o resultado do trabalho)
O modelo cascata pode ser descrito utilizando à notação proposta pelo método IDEF0 (Marca e McGowan 1993). Os elementos
básicos de um diagrama IDEF0, são apresentados na Figura 1. As caixas representam as atividades; as setas entrando no lado
esquerdo da caixa representam as entradas (artefatos) que serão transformadas pela atividade para produzir os resultados,
representados pelas setas do lado direito da caixa. As setas entrando pela borda superior da caixa são os controles, ou seja, o que
dirige ou restringe as atividades (definição de pronto). As setas que entram pela borda inferior da caixa representam os mecanismos,
os meios pelos quais os artefatos serão transformados pela atividade tipicamente descrevem recursos humanos ou ferramentas
utilizadas.

8
 Atividade

Figura 11 IDEF0 (Marca, 1993)

A Figura 2 apresenta um exemplo de um processo que segue o modelo Cascata (Waterfall) considerando os critérios de aceitação
por fase utilizando o IDEF0 para descrever o processo.

Figura 12 – Exemplo de descrição para um processo de desenvolvimento de software utilizando o IDEF0

A Tabela 1 descreve o detalhamento do diagrama IDEF0 para o processo da Figura 2:

Tabela 2 - Detalhamento das atividades do processo

Atividade1 - Análise de Requisitos

Entrada Necessidades identificadas pelo cliente
Regras – 1 – os requisitos serão documentados utilizando o modelo de casos de uso da UML
estabelece como a 2 – os requisitos serão priorizados de acordo com a criticidade para o negócio e a probabilidade de falhas
qualidade será 3 - esta fase será considerada concluída quando for realizada a reunião entre a equipe de desenvolvimento
atingida e o cliente para estabelecer o “de acordo” no documento de requisitos
Saída Diagrama de casos de uso e especificação de casos de uso
Mecanismos A atividade é de responsabilidade da equipe de desenvolvimento

Atividade2 – Projeto
Entrada Diagrama de casos de uso e especificação de casos de uso
Regras – Esta atividade será considerada concluída quando a análise de rastreabilidade entre o DER – Diagrama de
estabelece como a Entidade e Relacionamentos e o documento de requisitos não identificarem inconsistências
qualidade será
atingida
Saída Diagrama de Entidade e Relacionamentos utilizando a notação “crows foot”
Mecanismos A atividade é de responsabilidade da equipe de desenvolvimento, MySQL Workbench

9
 Atividade3 - Codificação
Entrada 1 - Diagrama de casos de uso e especificação de casos de uso -
2 – Diagrama de entidade e relacionamento
Regras – Será considerada concluída quando a análise de rastreabilidade entre o código e as funções solicitadas no
estabelece como a documento de requisitos não identificarem inconsistências
qualidade será
atingida
Saída Código executável
Mecanismos A atividade é de responsabilidade da equipe de desenvolvimento

Atividade4 – Teste
Entrada 1 – Especificação de UC
2 - Código executável
Regras – Será considerada concluída quando 100% dos casos de teste prioritários rastreáveis para os requisitos
estabelece como a obtiverem satisfatório
qualidade será
atingida
Saída 1 – Casos de Teste
2 - Relatório de Teste
Mecanismos A atividade é de responsabilidade da equipe de desenvolvimento

Vantagens do modelo cascata:

• Visão de alto nível - apresenta uma visão de alto nível e sugere aos desenvolvedores a sequência de eventos esperada
para a entrega do software.
• Desenvolvimento em estágios - o desenvolvimento de um estágio deve terminar antes do próximo começar
• Produtos intermediários - explicita os produtos intermediários necessários para começar o próximo estágio de
desenvolvimento.
• Marcos – fornecem marcos bem definidos associados a cada atividade do processo, os gerentes podem se utilizar do
modelo para estabelecer os critérios de qualidade que definem a conclusão de cada fase (marco), a decomposição por
fases também facilita a estimativa do término do projeto.
Desvantagens do modelo cascata:
• Fluxo sequencial - projetos reais raramente seguem o fluxo sequencial que o modelo propõe
• Mudanças - o modelo tem dificuldades para acomodar as incertezas naturais que existem no começo do projeto
• Risco - uma versão executável do programa não vai ficar disponível até o projeto terminar – um erro grosseiro pode ser
desastroso.
• Estados de bloqueio - alguns membros da equipe precisam esperar que outros membros completem tarefas dependentes.
Deve ser utilizado quando os requisitos forem bem compreendidos e houver pouca probabilidade de mudanças radicais durante o
desenvolvimento do sistema (PRESSMAN, 2006; SOMMERVILLE, 2007). Este cenário ocorre quando o mercado está bem
definido, o domínio onde o software será utilizado está estabelecido os clientes são conhecidos.

10
2.2 Critérios de conclusão por fases

A condução de inspeções de software tem se demonstrado uma alternativa atraente para garantir o nível de qualidade adequado na
qualidade de documentos de requisitos de software. A possibilidade de identificar defeitos ainda na fase inicial do projeto tem levado
organizações a se preocuparem cada vez mais com a condução de inspeção em requisitos.

Segundo Basili et al. (1996), uma técnica de leitura pode ser caracterizada como uma série de passos para a análise individual de
um artefato de software de forma a permitir a obtenção do entendimento necessário para a execução de uma determinada tarefa.

Uma técnica de leitura visa a apoiar a obtenção de uma compreensão sobre um determinado artefato. Essa compreensão deve ser
suficiente para que a pessoa possa entender: (a) quais partes do artefato contêm informações importantes para a tarefa, e (b) como
a compreensão dessas informações contribui para a satisfação dessa tarefa.

Uma técnica de leitura na perspectiva dos requisitos pode identificar anomalias na rastreabilidade entre os documentos de
especificação de requisitos. A falta de rastreabilidade entre os documentos pode indicar uma anomalia.

Neste exemplo, marcadores simbolizados por triângulos, podem identificar as classes que devem ser incluídas no diagrama de
classes do domínio da aplicação.

ID Estória de Usuário Estimativa H/H Prioridade (A/M/B)

REQ01 Como vendedor, eu quero cadastrar o cliente de maneira

que seja possível obter informações de vendas.

Uma análise de rastreabilidade entre o diagrama de classes do domínio e o documento de especificação de requisitos pode
identificar anomalias na documentação.

11
2.3 Modelo V
O Modelo V foi desenvolvido para minimizar alguns dos problemas identificados na utilização da modelo cascata tradicional. Os
defeitos eram encontrados nas fases finais do ciclo de desenvolvimento. No Modelo V o teste é iniciado o mais cedo possível no
ciclo de vida. O modelo estabelece uma série de atividades que devem ser executadas antes da codificação. Estas atividades
devem ser executadas em paralelo com o ciclo de desenvolvimento do software. Existem diversos fatores que podem colaborar
para ocorrência de erros, por isso, a atividade de testes é dividida em fases com objetivos distintos (Figura 3). De uma forma geral
pode-se dividir a atividade de teste nas seguintes fases: teste de unidade, teste de integração e teste de sistemas.

Figura 13- Modelo V

Vantagens – atividades de teste como planejamento e projeto acontecem antes da codificação iniciar, defeitos são encontrados em
fases iniciais do ciclo de desenvolvimento de software.
Desvantagens – semelhantes a do modelo cascata, pouco flexível a mudanças nos requisitos
Critérios de seleção – este modelo pode ser selecionado com objetivos de melhoria do processo, quando a organização está
enfrentando problemas com o modelo cascata, incluindo atividades de controle da qualidade que são realizadas em todas as fases
do processo de desenvolvimento antecipando a descoberta de defeitos, ou quando o cliente exige evidências da realização das
atividades de teste nas fases intermediarias.

2.4 Desenvolvimento de software incremental

Atualmente o trabalho de software é executado em ritmo rápido. Mudanças frequentes sujeitas a um volume sem fim de
modificações. O modelo cascata é frequentemente inadequado para este tipo de trabalho. O aumento da demanda e a pressão por
prazos exigiu novos modelos de processo para ajudar a reduzir o tempo de desenvolvimento. Em um processo de entrega incremental
um esboço dos requisitos é identificado pelos clientes e divididos em vários incrementos. Cada incremento proporciona um
subconjunto da funcionalidade do sistema (Figura 4).

Figura 14- Processo de desenvolvimento iterativo (SOMMERVILLE, 2007)

O cliente identifica, em linhas gerais, os serviços a serem fornecidos pelo sistema, a atribuição de serviços aos incrementos depende
da ordem de prioridade dos serviços — os serviços de mais alta prioridade são implementados e entregues em primeiro lugar. Uma
vez que os incrementos do sistema tenham sido identificados, os requisitos dos serviços a serem entregues no primeiro incremento
são definidos em detalhes, e esse incremento é desenvolvido. Durante o desenvolvimento, podem ocorrer mais análises de requisitos
para incrementos posteriores, mas mudanças nos requisitos do incremento atual não são aceitas (Figura 5).

Figura 15 - Cada iteração pode ser considerada um mini-cascata

12
Cada iteração produz software funcional diferentemente da modelo cascata (tradicional). Existe verificação a cada etapa para obter
confirmação do cliente. Para facilitar a compreensão pode-se pensar na iteração com uma analogia do modelo cascata, cada iteração
pode ser considerada um mini-cascata (Figura 5).

Critérios de seleção – Os principais requisitos estão definidos mais alguns detalhes podem evoluir com o tempo, esta abordagem
permite diminuir os riscos antes que se faça muitos investimentos no projeto. Este modelo de processo é adequado quando existe
necessidades de entregas parciais, disponibilização um retorno mais rápido para o cliente, liberando software integrado e testado
que pode ser instalado no ambiente de produção.

3 Scrum

Scrum é um processo ágil que permite manter o foco na entrega do maior valor de negócio, no menor tempo possível (Figura 6).
Esta abordagem permite entregas rápidas e inspeção contínua do software em produção (em intervalos de duas a quatro semanas).
As necessidades do negócio é que determinam as prioridades do desenvolvimento do software. As equipes se auto-organizam para
definir a melhor maneira de entregar as funcionalidades de maior prioridade. O Scrum é fundamentado nas teorias empíricas de
controle de processo.

O coração do Scrum é a Sprint, que tem duração de 2 a 4 semanas durante o qual um “Pronto” (versão incremental potencialmente
utilizável do produto) é criado. As Sprints são compostas por uma reunião de planejamento da Sprint, reuniões diárias, o trabalho
de desenvolvimento, uma revisão da Sprint e a retrospectiva da Sprint. A reunião de planejamento da Sprint responde as seguintes
questões: (1) Qual é o objetivo da Sprint? (2) O que pode ser entregue como resultado do incremento da próxima Sprint? (3) Como
o trabalho necessário para entregar o incremento será realizado?

A Reunião Diária é mantida no mesmo horário e local para reduzir a complexidade logística. Durante a reunião os membros do
Time de Desenvolvimento respondem três perguntas: (1) O que eu fiz ontem que ajudou o Time de Desenvolvimento a atender a
meta da Sprint? (2) O que eu farei hoje para ajudar o Time de Desenvolvimento atender a meta da Sprint? (3) Eu vejo algum
obstáculo que impeça a mim ou o Time de Desenvolvimento no atendimento da meta da Sprint?

O Time Scrum é composto pelo Product Owner, o Time de Desenvolvimento e o Scrum Master. Times Scrum são auto-organizáveis
e multifuncionais. Times auto-organizáveis escolhem qual a melhor forma para completarem seu trabalho, em vez de serem dirigidos
por outros de fora do Time. Times multifuncionais possuem todas as competências necessárias para completar o trabalho sem
depender de outros que não fazem parte da equipe.

O modelo de time no Scrum é projetado para aperfeiçoar a flexibilidade, criatividade e produtividade. Os artefatos mantidos pelo
Scrum são o backlog de produto e backlog da Sprint.

Figura 16 - Cerimônia do Scrum

O Sucesso no uso do Scrum depende das pessoas se tornarem mais proficientes na vivência dos cinco valores Scrum
comprometimento, coragem, foco, transparência e respeito. As pessoas se comprometem pessoalmente em alcançar estes objetivos
do Time Scrum. O Time Scrum precisa ter coragem para fazer a coisa certa e trabalhar em problemas difíceis. Todos focam no
trabalho da Sprint e nos objetivos do Time Scrum. O Time Scrum e seus stakeholders concordam em estarem abertos a todo o
trabalho e aos desafios com a execução dos trabalhos. Os membros do Time Scrum respeitam uns aos outros para serem pessoas
capazes e independentes.

Três pilares apoiam a implementação de controle de processo no Scrum: transparência, inspeção e adaptação. Manter a transparência
implica que aspectos significativos do processo devem estar visíveis aos responsáveis pelos resultados. Esta transparência estabelece
um padrão comum para que os observadores compartilharem um mesmo entendimento das fases do processo. Por exemplo, uma
linguagem comum que estabelece o processo de desenvolvimento, deve ser compartilhada por todos os participantes.

13
Os usuários Scrum devem frequentemente inspecionar os artefatos Scrum e o progresso com objetivo de detectar desvios. Esta
inspeção não deve ser tão frequente que atrapalhe a própria execução das tarefas. As inspeções são mais benéficas quando realizadas
de forma cuidadosa por inspetores especializados no trabalho a se verificar. Se um inspetor determina que um ou mais aspectos de
um processo desviou para fora dos limites aceitáveis, e que o produto resultado será inaceitável, o processo ou o material sendo
produzido deve ser ajustado. O ajuste deve ser realizado o mais breve possível para minimizar mais desvios.

O planejamento da qualidade é realizado a cada iteração durante o desenvolvimento do produto. Na fase de conclusão do Sprint o
controle da qualidade é realizado durante a “Revisão do Sprint” e na reunião de Retrospectiva. Na reunião de Retrospectiva o time
discute o processo de desenvolvimento para avaliar o que agregou valor e qual aspecto não atendeu as expectativas da equipe. Neste
momento, poderão ser feitas sugestões de melhoria que serão revisadas pelo time para o próximo Sprint. Uma definição comum de
“Pronto” deve ser compartilhada por aqueles que realizam o trabalho e por aqueles que aceitam o resultado do trabalho. A definição
do “Pronto” busca orientar o time para que tenha um entendimento comum a respeito do que significa uma entrega pronta – análise
estática do código, testes de unidade, testes de integração e aceitação concluídos.

3.1 Artefatos do Scrum

Os artefatos do Scrum representam trabalho ou o valor para o negócio. São concebidos para maximizar a transparência das
necessidades de informação para gerenciar o projeto. Cada artefato contém um compromisso, para assegurar que fornece
informação que aumenta a transparência e o foco, contra o qual o progresso pode ser medido (SCHWABER, 2011):

• Para o Product Backlog o compromisso é definido no Product Goal.

• Para o Sprint Backlog o compromisso é definido no Sprint Goal.
• Para o Increment o compromisso é definido no Definition of Done.
Estes compromissos existem para reforçar o empirismo e os valores do Scrum para o time de desenvolvimento e para os
stakeholders

3.2 Product Backlog

O Product Backlog é uma lista emergente e ordenada do que é necessário para melhorar o produto. Os itens do Product Backlog são
ordenados por prioridade. Os itens no topo da lista devem estar mais detalhados e serem mais bem compreendidos por todos do
Time. Dessa forma, são os itens elegíveis a serem desenvolvidos nas próximas Sprints.

Por outro lado, os itens menos prioritários são aqueles que ainda não estão bem compreendidos, precisam ser refinados para melhor
detalhamento e serão desenvolvidos em algum momento nos próximos Sprints. Imagina-se que com mais detalhes, a estimativa seja
mais assertiva e seja mais fácil atingir o Objetivo do Sprint dentro do Timebox.

O critério utilizado para ordenação do Backlog é definido pelo PO, que pode utilizar diversas técnicas conforme a necessidade,
como por valor, por prazo (caso seja uma ação de marketing ou determinação legal), por risco, por dependência técnica ou de
negócio.

Já a estimativa é de responsabilidade do Time de Desenvolvimento que são os executores. Contudo, o PO ajuda na determinação e
entendimento do escopo.

O Product Backlog pode ser mantido em uma planilha Excel (Figura 7). Um exemplo de um projeto é apresentado abaixo. Essa
planilha Excel mostra cada item do Product Backlog com uma priorização genérica (Muito Alta, Alta, etc.) feita pelo Product Owner.
DEEP é o acrônimo que significa que o backlog deve ser: Detalhado apropriadamente, Estimado, Emergente e Priorizado.

As estimativas são realizadas pelos desenvolvedores, ainda com alguma imprecisão e são utilizadas para uma visão inicial do
esforço. Na reunião de planejamento do Sprint, durante o detalhamento do Sprint Backlog esta estimativa é refinada.

Figura 17 – Product Backlog parcial para o SIG de Vendas e Suprimentos

14
Uma das principais atividades da reunião de planejamento do sprint é decidir quais estórias incluir no sprint. Mais
especificamente, quais estórias do product backlog serão implementadas no sprint que está sendo planejado (Sprint Backlog).

3.3 Sprint Backlog

No início de cada Sprint, o Dono do Produto e a equipe realizam um Sprint Planning Meeting para negociar quais itens do Product
Backlog serão desenvolvidos durante o Sprint. O Product Owner é responsável por declarar quais itens são os mais importantes para
o negócio. A equipe de desenvolvimento é responsável por selecionar a quantidade de trabalho que eles sentem que podem
implementar sem acúmulo de dívida técnica. A equipe “puxa” o trabalho do Produto Backlog para o Sprint Backlog. O Backlog da
Sprint é um conjunto de itens do Backlog do Produto selecionados para a Sprint (representado na forma de um Quadro de Tarefas),
juntamente com o plano para entregar o incremento "Pronto" e atingir a Meta da Sprint (JAMES, 2010).

No caso do Sistema Integrado de Gestão para Vendas e Suprimentos, supondo que a função “Manter Cliente” foi selecionada para
este Sprint, as tarefas identificadas para implementação do Sprint seriam:

ID Tarefa
1 Desenvolver o modelo de domínio da aplicação (diagrama UML)
2 Desenvolver a visão lógica da arquitetura (diagrama da UML visão 4 + 1 – KRUCHTEN, 1995)
3 Implementar a camada de persistência (Model) – ClienteRepository, Cliente, Endereço
4 Implementar a camada de serviço – ClienteServicoI, ClienteServico
5 Implementar a camada de API Web – ClienteController
6 Implementar a camada de visão – FormCliente.

O Scrum não prescreve um formato específico de como o Sprint Backlog deve ser organizado, sendo que o formato mais comum
entre os times ágeis é o quadro de atividades (board, Kanban, etc), seja ele físico ou virtual. Neste quadro geralmente o time cria
colunas com as fases de desenvolvimento de cada item, como TO DO, DOING e DONE, onde os itens que devem ser feitos na
sprint iniciam na coluna TO DO, passam para a coluna DOING quando um desenvolvedor pega um deles para trabalhar e
finalmente é colocado na coluna DONE quando o item é concluído.

Figura 18 - Quadro de acompanhamento das tarefas do sprint

3.4 Definição de pronto

Uma Definição de Pronto (Definition of Done) é um artefato Scrum usado para garantir a qualidade do produto desenvolvido a
cada iteração (Sprint). Um documento, um contrato entre os membros do Time Scrum e demais envolvidos para que todos
entendam o que um produto “pronto” (done) significa.

O exemplo abaixo estabelece uma definição de pronto para o projeto SIG-VS:

1) Todas as histórias de usuário associadas ao incremento estão concluídas (revisão por pares, análise de rastreabilidade entre
os requisitos, modelo de domínio, modelo de projeto e o código)
2) O código está revisado e segue as diretrizes de codificação da equipe (relatório do SonarLint).
3) Todas as funcionalidades implementadas estão testadas. Um roteiro de teste foi especificado estabelecendo as condições
de teste e os testes foram realizados com sucesso, os casos de teste foram submetidos a uma revisão por pares.
4) A documentação necessária está atualizada.
5) A versão foi atualizada no repositório de controle de versão seguindo o processo de gerência de configuração estabelecido
na organização.

15
Exemplo de um roteiro de teste simplificado:

REQ01 – Como vendedor, eu quero cadastrar o cliente, de maneira que seja possível obter informações do cliente em uma venda.

ID CPF Nome CEP Resultado esperado

REQ01CT01 87391319716 José da Silva 01208000 Cadastro realizado com sucesso
REQ01CT02
REQ01CT03
...

4 Ciclo de avaliação e melhoria de processos

Um outro aspecto fundamental, ao se definir o processo de desenvolvimento de software em uma organização, está relacionado ao
estabelecimento de um processo de evolução do processo de desenvolvimento, de modo que essa evolução seja sistemática e
disciplinada. Atualmente, existe uma procura constante da sociedade por softwares mais baratos e melhores, consequentemente,
muitas empresas de desenvolvimento de software voltaram-se para a melhoria de processos de software como uma forma de
melhorar a qualidade dos seus produtos, reduzindo custos ou acelerando seus processos de desenvolvimento.

A melhoria de processos implica a compreensão dos processos existentes e sua mudança para aumentar a qualidade de produtos
e/ou reduzir custos e o tempo de desenvolvimento. Duas abordagens podem ser utilizadas:

• A abordagem de maturidade de processo, a qual se centra em melhorar o gerenciamento de processos e projetos e em

introduzir boas práticas de engenharia de software em uma organização. O nível de maturidade de processos reflete o grau
em que as boas práticas técnicas e de gerenciamento foram adotadas nos processos de desenvolvimento de software da
organização. Modelos como CMMI ou MPS.BR estabelecem diversos níveis de maturidade no CMMi de 1 a 5 no MPS.BR
de A a G. Em cada um desses níveis os processos são continuamente melhorados com base em um entendimento
quantitativo das causas comuns de desvios no desempenho (tipicamente erros ou gargalos no processo). A melhoria
contínua é obtida com inovações e melhor uso de tecnologias. Objetivos quantitativos de melhoria de processos são
estabelecidos, continuamente revisados de acordo com os negócios da organização e usados como critério no
gerenciamento. Os efeitos da implantação da melhoria de processos são medidos e avaliados. A melhoria de processos é
uma tarefa de todos, não apenas uma ordem específica dos níveis hierárquicos mais altos. Desta forma, é possível que seja
criado um ciclo de melhoria contínua dos processos, evitando-se acomodação. Os principais objetivos dessa abordagem
são produtos de melhor qualidade e previsibilidade de processo.
• O desenvolvimento ágil, permite flexibilidade e promove abordagens leves de melhoria de processos que podem afetar
positivamente o retorno sobre o investimento de uma empresa e consequentemente ajudar a empresa a sobreviver no longo
prazo. No Scrum durante as reuniões de retrospectiva, ao final de cada Sprint, o Time inspeciona o trabalho realizado para
criar um plano de melhorias/adaptação do processo de desenvolvimento, a serem aplicadas na próxima Sprint.
De acordo com Sommerville (2011) os objetivos quantitativos de melhoria de processos são estabelecidos, continuamente revisados
de acordo com os negócios da organização. O aprimoramento de processos é uma atividade cíclica, conforme mostrado na Figura
4.

Figura 19 - ciclo de melhoria de processos (SOMMERVILLE, 2011)

16
O aprimoramento de processos compreende três estágios principais:

1.Medição de processo. Os atributos do projeto atual ou dos produtos são medidos. O objetivo é melhorar as medidas de acordo
com os objetivos da organização envolvida na melhoria de processos. Isso forma uma linha base que ajuda a decidir se as melhorias
no processo foram eficazes.

2.Análise de processo. O processo atual é avaliado e os gargalos e pontos fracos são identificados. A análise pode centrar-se levando
em consideração as características de processo, como agilidade do processo e produtividade.

3.Mudanças de processo. As mudanças de processos são propostas para resolver alguns dos pontos fracos identificados no processo.
Elas são introduzidas e o ciclo recomeça para a coleta de dados sobre a eficácia das mudanças.

Referencias

MARCA, D., and McGowan, C., IDEF0 - SADT Business Process and Enterprise Modelling, Electric Solutions Corporation,
1993.
NBR ISO / IEC 12207:1995. Tecnologia de informação-Processos de ciclo de vida de software - Rio de Janeiro: ABNT, 1998
ROMANO, Daniele; PINZGER, Martin. A genetic algorithm to find the adequate granularity for service interfaces. In: 2014 IEEE
World Congress on Services. IEEE, 2014. p. 478-485.
SOMMERVILLE, I., Engenharia de Software, 9ed., São Paulo: Pearson Prentice Hall, 2011 (Cap. 2, 26)
SMART, John Ferguson. BDD in Action. New York: Manning Publications, 2014.

17