MESTRADO EM SISTEMAS E COMPUTAÇÃO

MESTRADO EM SISTEMAS E COMPUTAÇÃO

XXXXX XXXXX XXXXXXX XXXXX XXXXXXXXX XXXXXXX

PSTC – UM PROCESSO DE SELEÇÃO DE MODELOS DE CONTRATO PARA PROJETOS ÁGEIS

Salvador 2021

XXXXX XXXXX XXXXXXX XXXXX XXXXXXXXX XXXXXXX

PSTC – UM PROCESSO DE SELEÇÃO DE MODELOS DE CONTRATO PARA PROJETOS ÁGEIS

Dissertação apresentada ao Mestrado em Sistemas e Computação da UNIFACS Universidade Salvador, como requisito parcial para obtenção do título de Mestre.

Orientador: Prof. Dr. Xxxxxx Xxxxxxx Xxxxxxxxx.

Salvador 2021

Ficha Catalográfica elaborada pelo Sistema de Bibliotecas da UNIFACS Universidade Salvador, Laureate Internacional Universities.

Xxxxxxx, Xxxxx Xxxxx Xxxxxxx Xxxxx Xxxxxxxxx

PSTC – um processo de seleção de modelos de contrato para projetos ágeis. / Xxxxx Xxxxx Xxxxxxx Xxxxx Xxxxxxxxx Xxxxxxx. - Salvador, 2021.

174 f.: il.

Dissertação apresentada ao Programa de Pós-Graduação em Sistemas e Computação da Universidade Salvador (UNIFACS), Laureate International Universities, como requisito parcial para obtenção do título de Mestre.

Orientador: Prof. Dr. Xxxxxx Xxxxxxx Xxxxxxxxx.

1. Desenvolvimento de sistema. 2. Projetos ágeis. Computador. I. Fernandes, Sérgio Martins, orient. II. Título.

CDD: 004.6

XXXXX XXXXX XXXXXXX XXXXX XXXXXXXXX XXXXXXX

PSTC – UM PROCESSO DE SELEÇÃO DE MODELOS DE CONTRATO PARA PROJETOS ÁGEIS

Dissertação apresentada ao Programa de Mestrado em Sistemas e Computação da Universidade Salvador – UNIFACS, Laureate International Universities, como requisito parcial para obtenção do grau de Mestre em Sistemas e Computação e aprovada pela seguinte banca examinadora:

Xxxxxx Xxxxxxx Xxxxxxxxx – Orientador                           Doutor em Engenharia da Computação pela Universidade de São Paulo – USP Universidade Salvador – UNIFACS

Xxxxx Xxxxxxx xx Xxxxx                                    Doutor em Ciência da Computação pela Universidade Federal de Pernambuco – UFPE

Universidade Salvador – UNIFACS

Xxxxxxx Xxxxxx xx Xxxxxxx Xxxxx                              Xxxxxx em Difusão do Conhecimento pela Universidade Federal da Bahia – UFBA Universidade do Estado da Bahia – UNEB

Esta pesquisa é dedicada aos meus pais Xxxxxxx Xxxxxxxx xx Xxxxx e Xxxxxx Xxxxxxx xx Xxxxx Xxxxx, que me deram a base do conhecimento, amor, confiança e todo apoio para que eu chegasse até aqui.

Agradeço primeiramente a Deus por me dar motivação, determinação e força para chegar ao fim de mais um desafio que impus na minha vida. Agradeço imensamente a minha família pelo apoio, principalmente ao meu marido Xxxxxxxx Xxxxxxx e ao meu filho Xxxxxx Xxxxxxx, que suportaram minha ausência e se mantiveram ao meu lado.

Agradeço ao meu dedicado e confiante orientador, Prof. Xxxxxx Xxxxxxx Xxxxxxxxx, pela ânsia em promover o melhor da minha pesquisa e por me estimular a novos desafios, sempre acreditando no melhor resultado.

Agradeço também por pessoas que cruzaram o meu caminho trazendo ricas contribuições, que muito engrandeceram esta pesquisa. Primeiramente, agradeço a Xxxxxxx Xxxx, que tanto me fez resolver questões delicadas me ouvindo, ponderando e me dando atenção. Xxxxxxxx também a Xxxxx Xxxxxxxx pelo compromisso e dedicação, e a Xxxxxxxxx Xxxxxxx Xxxxx pela disponibilidade e atenção.

Processos ágeis têm maior probabilidade de sucesso que outras abordagens para desenvolvimento de software, principalmente quanto à adaptação a mudanças ao longo do projeto. A abordagem ágil é muito eficaz e cresce em popularidade. É simples, mas demanda esforço de adaptação da organização a uma nova forma de agir diante a um projeto. Contudo, traz como retorno benefícios de longo prazo, valendo o investimento emocional e pessoal empregado. Os métodos de desenvolvimento ágil de software fortaleceram a segurança, a confiabilidade e a disponibilidade do desenvolvimento. Entretanto, as abordagens ágeis não preveem que seja acordada com o cliente, no momento da contratação do projeto, uma especificação detalhada de requisitos que a equipe de desenvolvimento se compromete a desenvolver integralmente. A falta de confiança do que será entregue ao cliente é uma dificuldade na contratação do projeto, assim como a incerteza de retorno financeiro por parte do fornecedor. Modelos de contratação específicos devem então ser definidos. Esta pesquisa concebeu o Processo de Seleção de Tipo de Contrato – PSTC, que busca contribuir para o sucesso na contratação de projetos ágeis de desenvolvimento de sistemas através da recomendação do tipo de contrato a ser utilizado em um determinado projeto. Foram estabelecidos os conceitos de Formas de contratação e seus Fatores determinantes. Além disto, foi montado um catálogo de tipos de contratos ágeis conforme a Revisão Sistemática da Literatura realizada nesta pesquisa. Neste catálogo são relacionados tipos de contrato que vão além das contratações padrões por tempo e material ou por custo fixo. Esta é uma dissertação científica argumentativa que utilizou o método de procedimento estruturalista e o método de abordagem indutivo, com aplicação das técnicas de Revisão Sistemática da Literatura, Síntese Narrativa, AHP e Experimento.

Palavras-chave: Contratos; Contrato Ágil; Modelos; Processo; Método; Projeto; Desenvolvimento de sistema; Custos; AHP.

Agile processes are more likely to be successful than other software development approaches, especially in terms of adapting to changes throughout the project. This has made the agile approach increasingly popular. It's simple, but it demands an effort to adapt the organization to a new way of doing projects. However, it brings long-term benefits in return, worth the emotional and personal investment employed. Agile software development methods have strengthened product security, reliability, and availability. However, agile approaches do not provide a detailed requirements specification during contract negotiation between customer and contractor. This can lead the client to have little confidence in the project's success during contracting, as well as the uncertainty of the financial return on the part of the supplier. Specific contract models must then be defined. This research conceived the Contract Type Selection Process – PSTC, which seeks to contribute to the success in contracting agile systems development projects by recommending the type of contract to be used in each project. The concepts of Forms of Contracting and their Determinant Factors were established. In addition, a catalog of types of agile contracts was assembled according to the Systematic Literature Review carried out in this research. This catalog lists contract types that go beyond standard time and material or fixed cost contracts. This is an argumentative scientific dissertation that used the method of structuralist procedure and the method of inductive approach, applying the techniques of Systematic Literature Review, Narrative Synthesis, AHP and Experiment.

Keywords: Contracts; Agile Contract; Models, Process; Method; Project; System Development; Costs; AHP.

Figura 1 – Etapas do Método de Abordagem Indutivo. 21

Figura 2 – Aplicação da Abordagem Ágil 24

Figura 3 – Abrangência da abordagem Ágil 24

Figura 4 – Ciclos de Vida de projetos. 25

Figura 5 – Triângulo de ferro – abordagens Preditiva e Ágil 26

Figura 6 – Business Case Preditivo. 28

Figura 7 – Business Case Ágil 29

Figura 8 – Exemplo de Hierarquia de critérios/objetivos. 32

Figura 9 – Fluxo geral do AHP 33

Figura 10 – Desenho de um Experimento. 35

Figura 11 – Desenho de um Experimento. 37

Figura 12 – Distribuição de estudos primários selecionados por Base de Bibliográfica 48

Figura 13 – Passos da síntese narrativa apresentada por Xxxxxxx no seu estudo de caso (Synthesis Process) 56

Figura 14 – Passos da síntese narrativa da RSL 58

Figura 15 – Quadro de Artigos 60

Figura 16 – Quadro de Tipos de Contratos 64

Figura 17 – Formas de Contratação e Fatores determinantes 73

Figura 18 – Formas de Contratação HÍBRIDA e seus Fatores determinantes 74

Figura 19 – Formas de Contratação TETO DE CUSTO e seus Fatores determinantes 74

Figura 20 – Formas de Contratação UNIDADE DE TRABALHO e seus Fatores determinantes 75

Figura 21 – Formas de Contratação BÔNUS/PENALIDADE e seus Fatores determinantes 75 Figura 22 – Gráfico de estudos de Boas práticas de Contratação 77

Figura 23 – Gráfico de estudos de Modelo de Contratação 78

Figura 24 – Gráfico de estudos sobre Confiança entre as partes 79

Figura 25 – Etapas de construção da pesquisa. 83

Figura 26 – Hierarquia de Critérios – Fatores determinantes 86

Figura 27 – Hierarquia de Critérios – Primeiro nível 87

Figura 28 – PSTC - Processo de Seleção do Tipo de Contrato 104

Figura 29 – Experimento do PSTC 109

Figura 30 – Tipos de contrato selecionas no Experimento 125

Tabela 1 – Quadro Metodológico da pesquisa. 20

Tabela 2 – Questões motivacionais para a pesquisa 42

Tabela 3 – Pesquisa de RSLs existentes 43

Tabela 4 – Estrutura PICO & Palavras-chave 46

Tabela 5 – String de busca 47

Tabela 6 – Quantitativo pesquisado na Seleção 48

Tabela 7 – Quantitativo ao final da primeira etapa do processo de Seleção 50

Tabela 8 – Quantitativo ao final da segunda etapa do processo de Seleção 51

Tabela 9 – Quantitativo pesquisado com Snowballing – Conferencias 52

Tabela 10 – Quantitativo pesquisado com Snowballing 52

Tabela 11 – Estudos primários da RSL 52

Tabela 12 – Comparação entre métodos de síntese 55

Tabela 13 – Ferramentas e técnicas da Síntese Narrativa 57

Tabela 14 – Agrupamento dos elementos do Quadro de Artigos 61

Tabela 15 – Agrupamento dos Tipos de Contratos em Formas de Contratação 62

Tabela 16 – Características dos Tipos de Contratos 64

Tabela 17 – Similaridades encontradas nos Tipos de Contratos 68

Tabela 18 – Fatores determinantes por Forma de Contratação 70

Tabela 19 – Escala absoluta de Intensidade de Importância de Saaty 87

Tabela 20 – Matriz de intensidade de importância – Nível 1 – Forma de contratação 88

Tabela 21 – Matriz de intensidade de importância com total – Nível 1 – Forma de contratação 89

Tabela 22 – Matriz de intensidade de importância normalizada – Nível 1 – Forma de contratação 89

Tabela 23 – Cálculo do vetor de Eigen – Nível 1 – Forma de contratação 90

Tabela 24 – Matriz de intensidade de importância – Nível 2 – TETO DE CUSTO 90

Tabela 25 – Matriz de intensidade de importância – Nível 2 – BÔNUS/PENALIDADE 91

Tabela 26 – Matriz de intensidade de importância – Nível 2 – HIBRIDA 91

Tabela 27 – Matriz de intensidade de importância – Nível 2 – UNIDADE DE TRABALHO 92

Tabela 28 – Cálculo do vetor de Eigen – Nível 2 – TETO DE CUSTO 93

Tabela 29 – Cálculo do vetor de Eigen – Nível 2 – BÔNUS/PENALIDADE 93

Tabela 30 – Cálculo do vetor de Eigen – Nível 2 – HIBRIDA 94

Tabela 31 – Cálculo do vetor de Eigen – Nível 2 – UNIDADE DE TRABALHO 94

Tabela 32 – Valor Principal de Eigen – Nível 1 – Forma de contratação 96

Tabela 33 - Índice de Consistência Aleatória Média (RI) 97

Tabela 34 – Taxa de Consistência – CR – Nível 1 – Forma de contratação 97

Tabela 35 – Taxa de Consistência – CR – Nível 2 – TETO DE CUSTO 98

Tabela 36 – Taxa de Consistência – CR – Nível 2 – BÔNUS/ PENALIDADE 98

Tabela 37 – Taxa de Consistência – CR – Nível 2 – HIBRIDA 99

Tabela 38 – Taxa de Consistência – CR – Nível 2 – UNIDADE DE TRABALHO 99

Tabela 39 – Matriz Consolidada de Decisão da Forma de Contratação 102

Tabela 40 – Pontuação da ocorrência do Fator determinante no projeto 105

Tabela 41 – Pontuação para determinação da Forma de Contratação 106

Tabela 42 – Objetos e Diretrizes da Instrumentação 113

Tabela 43 – Dados da Instrumentação 113

Tabela 44 – Formulário de Perfil do Participante do Experimento 114

Tabela 45 – Formulário do Experimento 115

Tabela 46 - Características dos Tipos de Contratos do Experimento 117

Tabela 47 – Questionário de Validação do Experimento 119

Tabela 48 – Dados da Instrumentação – seções do Experimento 120

Tabela 49 – Pontuação para determinação da Forma de Contratação do Experimento 120

Tabela 50 – Características dos Tipos de Contratos do Experimento – Plataforma de Aluguel

.......................................................................................................................................... 123

Tabela 51 – Questionário de Validação do Experimento respondido 126

Tabela 52 – Ocorrências de faltas (FALSE) 127

LISTA DE ABREVIATURAS E SIGLAS

AHP	Analytic Hierarchy Process – Processo de Hierarquia Analítica
AMD	Apoio Multicritério à Decisão
MCA	Multicriteria Analysis Methods – Método de Análise Multicritério
MCDA	Multicriteria Decision Aid – Auxílio à Decisão Multicritério
PROMETHEE	Preference Ranking Organization Method for Enrichment Evaluation
RSL	Revisão Sistemática da Literatura
PSTC	Processo de Seleção de Tipo de Contrato

SUMÁRIO

1 INTRODUÇÃO 15

1.1 CONTEXTUALIZAÇÃO 15

1.2 MOTIVAÇÃO 17

1.3 OBJETIVO 19

1.4 DELIMITAÇÃO DA ABRANGÊNCIA DA PESQUISA 19

1.5 METODOLOGIA 20

1.6 ESTRUTURA DA DISSERTAÇÃO 22

2 REFERENCIAL TEÓRICO 23

2.1 ABORGADEM ÁGIL 23

2.2 TRIÂNGULO DE FERRO 26

2.3 CONTRATO ÁGIL 27

2.4 MODELO DE CONTRATAÇÃO 27

2.5 O ANALYTIC HIERARCHY PROCESS – AHP 30

2.5.1 Métodos de Decisão 30

2.5.2 Breve Histórico do AHP 31

2.6 ESTRATÉGIA EMPÍRICA DE EXPERIMENTO 33

2.6.1 O processo do experimento 34

2.7 CONSIDERAÇÕES FINAIS 41

3 REVISÃO SISTEMÁTICA DA LITERATURA 42

3.1 AVALIANDO A NECESSIDADE DA ELABORAÇÃO DE UMA RSL 42

3.2 PROTOCOLO 44

3.3 INFORMAÇÕES GERAIS 44

3.3.1 Objetivo estruturado 45

3.3.2 Objetivo não estruturado 45

3.4 QUESTÕES DE PESQUISA (RQ – REASERCH QUESTIONS) 45

3.4.1 Critérios pico para questões de pesquisa 46

3.5 IDENTIFICAÇÃO DE ESTUDOS 47

3.6 SELEÇÃO E AVALIAÇÃO DE ESTUDOS 48

3.6.1 Critérios de inclusão e exclusão 48

3.6.2 Processo de seleção dos estudos primários 49

3.7 SÍNTESE DOS DADOS E APRESENTAÇÃO DOS RESULTADOS 54

3.8 SÍNTESE NARRATIVA 56

3.8.1 Elemento 1: desenvolvendo uma teoria 59

3.8.2 Elemento 2: desenvolvendo uma síntese preliminar 59

3.8.2.1 Tabulação 60

3.8.2.2 Agrupamentos e aglomerações 61

3.8.3 Elemento 3: explorando relações dentro e entre estudos 68

3.8.3.1 Descrições qualitativas de casos 69

3.8.3.2 Construindo modelos conceituais/teia de ideias/mapeando conceitos 69

3.8.4 Elemento 4: avaliando a robustez da síntese 75

3.8.4.1 Refletindo criticamente sobre o processo de síntese 76

3.8.5 Conclusões Finais 76

3.9 CONCLUSÃO DA RSL 77

4 APLICAÇAO DO AHP PARA DECISÃO DO TIPO DE CONTRATO 83

4.1 APLICANDO O AHP 84

4.1.1 Hierarquia dos critérios 85

4.1.2 Matriz Comparativa 86

4.1.3 Análise da Consistência 95

4.1.3.1 Calculando o Valor Principal de Eigen (λmax) 96

4.1.3.2 Calculando o Índice de Consistência (CI) 96

4.1.3.3 Calculando a Taxa de Consistência (CR) 96

4.1.3.4 Análise de todas as matrizes 98

4.1.4 Matriz Consolidada de Decisão 100

5 PROCESSO DE SELEÇÃO DE TIPO DE CONTRATO - PSTC 104

5.1 PONTUAÇÃO DOS FATORES DETERMINANTES DO PROJETO 105

5.2 SELEÇÃO DO TIPO DE CONTRATO 108

5.3 CONSIDERAÇOES FINAIS 108

6 VERIFICAÇÃO – O EXPERIMENTO DO PSTC 109

6.1 ESCOPO DO EXPERIMENTO 110

6.2 PLANEJAMENTO DO EXPERIMENTO 111

6.3 OPERAÇÃO 119

6.4 ANÁLISE E INTERPRETAÇÃO 127

6.5 CONCLUSÕES FINAIS DO EXPERIMENTO 128

7 CONSIDERAÇÕES FINAIS 129

7.1 CONCLUSÕES 129

7.2 LIMITAÇÕES DA PESQUISA 130

7.3 CONTRIBUIÇÕES DA PESQUISA 131

7.4 TRABALHOS FUTUROS 131

REFERÊNCIAS 133

APÊNDICE A – QUADRO DE TIPOS DE CONTRATOS 138

APÊNDICE B – REFERÊNCIA DOS FATORES DETERMINANTES 170

1 INTRODUÇÃO

Este capítulo apresenta a dissertação desenvolvida sob o contexto relacionado à Contratação em Projetos Ágeis e descreve a motivação para desenvolvimento desta pesquisa, assim como o problema de pesquisa, objetivos a serem alcançados e a metodologia aplicada a esta pesquisa.

O capítulo é estruturado nas seguintes seções: 1.1 contextualiza um breve panorama da contratação ágil; 1.2 apresenta o problema de pesquisa que a pesquisa visa solucionar; 1.3 detalha os objetivos a serem alcançados; 1.4 estabelece os limites desta pesquisa; 1.5 define a metodologia desta pesquisa e, finalmente, a seção 1.6 descreve os capítulos desta pesquisa.

1.1 CONTEXTUALIZAÇÃO

Em sua pesquisa, Xxxxxx (2014) informa que 46% dos entrevistados indicaram que usaram uma metodologia ágil (por exemplo, SCRUM, Extreme Programming, Feature Driven Development, Lean) para desenvolvimento de software em seu projeto. O uso de métodos ágeis quase dobrou desde 2008, quando uma pesquisa semelhante foi realizada.

O Chaos Report (Standish Group CHAOS Report, 1994) já apontava as principais fontes de falha de um projeto que induzem à aplicação de abordagens ágeis: Falta de informação do usuário (12,8%), Requisitos e especificações incompletos (12,3%) e Mudança de requisitos e especificações (11,8%) (VEIGA, 2017).

Entende-se por bem sucedido o projeto que finalizou no prazo e custo, sendo com desafio o projeto que finalizou e entrou em operação, mas não necessariamente no prazo, custo ou com todas as entregas realizadas. Litchmore (2016) cita que os projetos ágeis de desenvolvimento de software obtiveram mais sucesso do que projetos que utilizam outras metodologias. O mesmo estudo traz que ‘62% dos projetos ágeis foram bem-sucedidos, 35% enfrentaram desafios e 3% falharam’ (LITCHMORE, 2016 apud AMBLER, 2013). O Standish Group (STANDISH GROUP

CHAOS REPORT, 2014) reportou que 16.2% projetos ágeis foram bem-sucedidos, 57.7% encontraram desafios e 31.1% falharam.

Veiga (2017) apresenta um estudo desenvolvido pela empresa Hewlett- Packard (HP) em 2014 com mais de 600 desenvolvedores e profissionais de TI que

mostra que 49% das organizações adotam abordagens ágeis por acreditarem que sua aplicação resulta em maior satisfação do cliente. Além disto, cita que o Standish Group (STANDISH GROUP CHAOS REPORT, 2015) analisou os resultados de mais de

10.000 projetos entre 2011 e 2015, destacando que, em geral, para projetos de todos os tamanhos, os projetos ágeis são mais bem-sucedidos do que os projetos em cascata.

No estudo mais recente de 2021, o Standish Group faz uma retrospectiva dos últimos 60 anos de desenvolvimento de software e identifica que a fase ágil, que iniciou em torno de 2000, está dando lugar ao que eles chamam de Período de Fluxo Infinito (Infinite Flow Period), previsto para durar os próximos 20 anos. Nesta visão de projeto, não haverá um plano de gerenciamento de projeto, orçamento financeiro detalhado, cronogramas ou outra forma de plano (PORTMAN, 2021). O Fluxo é um método para gerenciar o desenvolvimento, implementação e manutenção de software por meio de um processo contínuo (THE STANDISH GROUP, 2021).

Contratação de projetos ágeis de desenvolvimento de sistemas tem sido feita há muito tempo e os aspectos legais e estruturais dos contratos são os mesmos de outros contratos das organizações. Contudo, a contratação ágil é impactada pelo nível de conhecimento dos envolvidos no contrato sobre os processos ágeis – em particular, o modelo ágil de detalhamento gradual dos requisitos e o modelo de entregas ágeis, assim como as expectativas das partes (ARBOGAST; LARMAN; VODDE, 2012).

Como citado em Xxxxxxxxx e Xxxxxxxx (2015), a abordagem ágil é muito eficaz e cresceu em popularidade. É simples, mas não é fácil, demandando esforço de adaptação da organização uma nova forma de agir diante a um projeto. Contudo, traz como retorno benefícios de longo prazo, valendo o investimento emocional e pessoal empregado. As abordagens de desenvolvimento ágil de software fortaleceram a segurança, a confiabilidade e a disponibilidade do desenvolvimento. Essa flexibilidade, ou agilidade, entretanto, tem um preço: as abordagens ágeis não preveem que seja acordada com o cliente, no momento da contratação do projeto, uma especificação detalhada de requisitos que a equipe de desenvolvimento se compromete a desenvolver integralmente.

Isso gera uma potencial dificuldade para o fechamento de contratos de desenvolvimento de software, para as duas partes: a falta de confiança e previsibilidade do que será entregue ao cliente, assim como a incerteza de retorno financeiro e lucratividade por parte do fornecedor (LINDSJØRN; MOUSTAFA, 2018).

Os contratos refletem as expectativas e, principalmente, os medos das pessoas. Não é o contrato que define um projeto de sucesso, mas sim as relações baseadas em confiança e colaboração. Assim, o contrato deve ser o instrumento para concretizar o sucesso desta relação que se inicia. Contratos bem-sucedidos contêm mecanismos que apoiam a construção de colaboração e confiança (XXXXXXXX; XXXXXX; VODDE, 2012)

Para enfatizar a importância da contratação ágil, é analisado em Arbogast, Xxxxxx e Vodde (2012) a falsa dicotomia causada pela forma equivocada de se interpretar o terceiro valor Ágil “Colaboração com o cliente mais que negociação de contratos” (BECK, et al., 2001), ou seja, “a colaboração do cliente é boa e o contrato é ruim”. O que o valor ágil traz é que “embora haja valor nos itens à direita, deve-se valorizar mais os itens à esquerda”. Não significa que o contrato está sub-rogado ao esforço colaborativo, mas sim que a colaboração é dominante para a entrega bem- sucedida de um projeto.

Esta pesquisa busca, então, por modelos de contratação específicos de projetos ágeis de desenvolvimento de sistemas, que devem ser definidos objetivando o sucesso da contratação, sem violar os pontos essenciais da abordagem ágil.

1.2 MOTIVAÇÃO

O terceiro valor Ágil “Colaboração com o cliente mais que negociação de contratos” e o primeiro princípio Ágil “1. A nossa maior prioridade é satisfazer o cliente por meio da entrega de valor antecipada e contínua de software”, descritos no Manifesto Ágil (XXXX, et al., 2001), apontam para a preocupação com a satisfação do cliente em um projeto. Conforme Xxxxxxxxx (2016), projetos ágeis são em geral mais bem-sucedidos do que outros projetos, mas projetos ágeis sem escopo flexível para refletir as necessidades e aprendizado do usuário alterado, ou sem entrega frequente ao cliente, tiveram menos do que a média de sucesso na entrega de benefícios ao cliente.

A aplicação dos processos ágeis para desenvolvimento de sistemas traz uma abordagem mais direcionada para o alcance da satisfação do cliente e da própria equipe de desenvolvimento, visto que os dois lados participam ativamente no alcance do sucesso do projeto através das entregas constantes e de aplicação direta e imediata, o que é reforçado também por Xxxxxxxx (2010) quando relata que a

metodologia ágil para estimativa, planejamento e entrega conduz a mitigação de risco em torno do escopo, tempo e qualidade do produto entregue.

Contudo, existem atividades, fora do desenvolvimento propriamente dito, que podem gerar impactos nas estimativas orçamentárias das entregas, além de dificultar o orçamento do projeto:

• Estimativa das atividades extra desenvolvimento (infraestrutura, estrutura física, capacitação da equipe, treinamentos, eventos, etc.);

• Estimativa das atividades fora de escopo, ou seja, novas necessidades e maiores validações ou extensão das rotinas inicialmente pensadas que aparecem ao longo do desenvolvimento;

• Estimativa das atividades de setup do projeto (contratação da equipe, montagem do ambiente de trabalho, montagem da infraestrutura, aquisição de infraestrutura, arquitetura da solução, definição de ambiente de desenvolvimento, definição do padrão do desenvolvimento, definição do padrão do banco de dados, etc.).

• Estimativa da capacidade de desenvolvimento da equipe. Assim como citado no Guia Ágil do PMI, seção 5.2.6 (PMI, 2017), as equipes não conseguem prever com 100% de certeza o que podem entregar, pois não conhecem o inesperado. Assim, através das práticas das retrospectivas para aprendizado e melhoria do processo de desenvolvimento, entende-se com o tempo a velocidade de cada componente da equipe e, finalmente, a capacidade da equipe a cada iteração, seção 5.2.1 (PMI, 2017).

Além disso, como cita Xxxxxxxx (2008), “No momento da negociação do contrato e ao longo do projeto, você não sabe o que não sabe, respeite isso e não tenha medo de admitir.”, são observados desafios nas contratações dos projetos de desenvolvimento sob aplicação dos conceitos ágeis, tanto para o contratante quanto para a contratada. Se todo o “escopo” não é definido e todo o “prazo” não é definido, como compor o orçamento do projeto? Como a contratada deve apresentar a proposta ao cliente para entrega do sistema “pronto”? Como o cliente montará um orçamento do projeto para apresentar corporativamente a organização pagante?

Para atender a diversas nuances de um projeto ágil, foram desenvolvidos diversos modelos de contratações ao longo do tempo. Em 2006, Xxxxxxxx Xxxxxxxx publicou uma lista com várias possibilidades de alguns contratos ágeis, como as seguintes (RUSSO; TACCOGNA; CIANCARINI; MESSINA; SUCCI, 2018):

• preço fixo, escopo fixo, tempo fixo;

• preço fixo, prazo fixo, escopo negociável;

• pagar pelo esforço à medida que for gasto;

• preço máximo com pagamento no aceite incremental;

• entrega incremental com pagamento no aceite incremental;

• preço para cada unidade entregue (ex: taxa fixa para ponto de função);

• taxa básica para cada unidade entregue, mais uma baixa taxa por hora, como incentivo de entrega antecipada.

Esta lista não é exaustiva. Além disto, há diversas interpretações sobre cada modelo de contrato.

Com base nisto, foi formulado o seguinte problema de pesquisa: qual ou quais modelos de contratação ágil podem ser aceitos por clientes que tipicamente demandam contratos com escopo, prazo e custo fixos, preservando a filosofia e as práticas ágeis?

1.3 OBJETIVO

Esta pesquisa visa definir um processo de seleção de tipo de contrato que contribua para o sucesso na contratação de projetos ágeis de desenvolvimento de sistemas através da recomendação do modelo de contratação mais adequado a ser utilizado em um determinado contexto envolvendo cliente, desenvolvedor e características do projeto. Para atingir este objetivo são identificados os seguintes objetivos específicos:

• Identificação de modelos ágeis de contratação existentes;

• Montagem de catálogo de modelos de contratação;

• Elaboração de processo para determinação do modelo de contratação em projetos ágeis de desenvolvimento de sistemas.

1.4 DELIMITAÇÃO DA ABRANGÊNCIA DA PESQUISA

A pesquisa visa contribuir para o sucesso da contratação através da recomendação de um determinado tipo de contrato a ser utilizado na contratação. Não visa analisar os efeitos do tipo de contratação no sucesso do projeto.

Ressalta-se, inclusive, que o tipo de contrato adequado impacta positivamente no sucesso do projeto (RUSSO; TACCOGNA; CIANCARINI; MESSINA; SUCCI, 2018).

1.5 METODOLOGIA

A metodologia desta pesquisa está apresentada na Tabela 1:

Tabela 1 – Quadro Metodológico da pesquisa

Aspecto metodológico	Metodologia
Tipo de pesquisa	Dissertação científica argumentativa
Variáveis independentes	Fatores Determinantes Características de Tipos de Contratos
Variáveis dependentes	Formas de Contratação Tipos de Contrato
Método de abordagem	Indutivo
Método de procedimento	Estruturalista
Técnicas de coleta de dados	Documentação indireta bibliográfica
Embasamento teórico	Revisão da bibliografia

Fonte: Elaborada pela autora desta dissertação (2021).

Por ser uma pesquisa escrita, original, de pesquisa especifica e de resultado aplicado, com interpretação e posicionamento da autora (XXXXXXX; LAKATOS, 2003), esta pesquisa classifica-se como uma dissertação cientifica argumentativa.

Foi utilizado o método de abordagem indutivo para organizar o pensamento visando solucionar o problema-chave da pesquisa através de conclusões mais amplas do que as premissas observadas. O método indutivo possui três etapas: Observação dos fenômenos, Descoberta da relação entre eles e Generalização da relação (XXXXXXX; XXXXXXX, 2003). A Figura 1 ilustra os recursos utilizados em cada etapa da abordagem indutiva.

Figura 1 – Etapas do Método de Abordagem Indutivo

Fonte: Elaborada pela autora desta dissertação (2021).

Na primeira etapa da Observação foi realizada uma Revisão Sistemática da Literatura, quando foi possível obter estudos primários sobre contratação de projetos ágeis de desenvolvimento de sistema. Esta etapa é apresentara do capítulo 3. Com o material observado na primeira etapa, foram aplicados dois métodos para descoberta das relações existentes entre os modelos de contratações observados. A aplicação da Síntese Narrativa é descrita na seção 3.8, que resultou na identificação das variáveis dependentes e independentes, assim como no Catálogo de tipos de contratos. O segundo método aplicado nesta etapa foi o AHP, apresentado no capítulo 4 na seção 4.1, que resultou na Matriz Consolidada de Decisão. Na última etapa, a contribuição do Processo de Seleção de Tipo de Contrato – PSTC é apresentado no capítulo 5 e verificado no capítulo 6.

Os métodos de procedimento são referentes às técnicas de pesquisa empregadas para alcançar os resultados pretendidos na pesquisa científica por meio da busca de respostas às perguntas-chave. Dessa forma, os métodos de procedimento permitem que se identifique a forma como será enfrentado o problema- chave em cada fase da pesquisa. O método de procedimento utilizado nesta pesquisa foi o estruturalista. O método estruturalista analisa o abstrato no mundo real estudando a relação dos elementos. Compreende o fenômeno na essência e não cria um modelo

ideal. Capta fenômenos da realidade, extrai os elementos principais, estrutura um modelo geral que representa a realidade e a partir daí verifica como os elementos se conectam, como os elementos se correlacionam (GODOY, 2021).

1.6 ESTRUTURA DA DISSERTAÇÃO

Esta dissertação está estruturada da seguinte forma:

• Capítulo 0 – 1 INTRODUÇÃO: o primeiro capítulo apresenta a contextualização, motivação e objetivo desta pesquisa, além de detalhar a metodologia aplicada;

• Capítulo 2 – Referencial Teórico: este capítulo aborda assuntos de base teórica necessários para compreensão dos temas desenvolvidos nos capítulos seguintes, sendo eles Abordagem Ágil, Triângulo de Ferro, Contrato Ágil, Modelos de Contratação, AHP e Estratégia empírica de Experimento;

• Capítulo 3 – Revisão sistemática da Literatura: neste capítulo são apresentados todos os passos realizados da RSL realizada, desde o Protocolo até a Síntese Narrativa, que extraiu e analisou todo o material gerado;

• Capítulo 4 – Aplicaçao do AHP para Decisão do Tipo de Contrato: o quarto capítulo apresentada a aplicação do AHP para geração da Matriz Consolidada de Decisão como instrumento vital para o Processo de Seleção de Tipo de Contrato – PSTC;

• Capítulo 5 – Processo de Seleção de Tipo de Contrato - PSTC: neste capítulo é apresentado o processo para identificação dos possíveis Tipos de Contrato para um determinado projeto;

• Capítulo 6 – Verificação – O Experimento do PSTC: este capítulo demonstra o teste do experimento de verificação do PSTC;

• Capítulo 7 – Considerações Finais: neste capítulo são apresentadas as conclusões finais desta pesquisa.

2 REFERENCIAL TEÓRICO

Este capítulo apresenta o levantamento bibliográfico de conceitos necessários para embasamento desta pesquisa. Para alcançar o entendimento da problemática tratada nesta pesquisa, faz-se necessário o conhecimento da Abordagem ágil, do Triângulo de Ferro, do conceito de Contrato ágil e, finalmente, dos pilares do Modelo de Contratação.

Os conceitos do Analytic Hierarchy Process – AHP também são primordiais para entendimento da razão de sua utilização como alicerce do PSTC, assim como os conceitos da Estratégia Empírica de Experimento são importantes para a verificação do PSTC.

2.1 ABORGADEM ÁGIL

A abordagem ágil em projetos é orientada pelo nível de incerteza do projeto, como descreve (PMI, 2017). Projetos com altos níveis de incerteza são orientados para abordagens ágeis, enquanto projetos determináveis, com menor nível de incerteza, são orientados para práticas preditivas.

Um projeto determinável é aquele que possui atividades conhecidas com histórico de resultados bem-sucedido em projetos similares. Um projeto para desenvolvimento de algo novo, exploratório, ou sem projeto similar anterior, está sujeito a muitas incertezas. Estes projetos sujeitos a incertezas podem sofrer muitas mudanças, o que potencialmente implica em maior complexidade e risco. Utilizar abordagens preditivas, que buscam identificar requisitos antecipadamente, nestes tipos de projetos pode causar muitos problemas. Em vez disso, as abordagens ágeis foram criadas para explorar as mudanças como forma de adaptação e entregas em ciclos curtos, como indicado na Figura 2, que indica a aplicação de abordagem ágil em projetos com cenários complexos ou complicados, com altas incertezas.

Figura 2 – Aplicação da Abordagem Ágil

Fonte: Figura 2-5. Modelo de Incerteza e Complexidade Inspirado no Modelo de Complexidade de Stacey (PMI, 2017).

O movimento ágil surgiu em 2001 pelos líderes do pensamento da indústria de desenvolvimento de software através do Manifesto Ágil (BECK, et al., 2001), que trouxe valores e princípios ágeis. A abordagem ágil engloba todas as técnicas, métodos, modelos (frameworks) ou práticas que envolvem estes valores e princípios (PMI, 2017). A Figura 3 apresenta um panorama da abrangência da abordagem ágil.

Figura 3 – Abrangência da abordagem Ágil

Fonte: Figura 2-4. Ágil é um Termo Geral para Muitas Abordagens (PMI, 2017).

O objetivo final do Ágil é implantar um fluxo contínuo de entregas que agregam valor ao cliente e proporcionam resultados para os negócios (PMI, 2017).

Dentre os vários ciclos de vida de processos de desenvolvimento de software, apresentados na Figura 4 conforme o PMI (2017), os ciclos de vida ágeis são aqueles que satisfazem os princípios do Manifesto Ágil (BECK, et al., 2001) tipicamente, uma combinação dos ciclos iterativos e incrementais.

Figura 4 – Ciclos de Vida de projetos

Fonte: Tabela 3-1. Características das Quatro Categorias de Ciclos de Vida (PMI, 2017).

Em um projeto ágil, espera-se que a cada iteração os requisitos mudem, mas em um ciclo, o que foi aprendido na iteração anterior é aplicado no planejamento da próxima iteração. Conforme o PMI (2017), os ciclos de vida ágeis são aqueles que satisfazem os princípios do Manifesto Ágil (XXXX, et al., 2001). Assim, a entrega antecipada e continua de valor faz aumentar a satisfação do cliente, adaptando-se as mudanças.

Em um projeto ágil mudanças nos requisitos são bem vindas, mesmo em etapas mais avançadas do projeto, e há um contínuo aprimoramento do processo a cada iteração: o que foi aprendido na iteração anterior é aplicado na próxima iteração. A entrega antecipada e continua de valor e a flexibilidade em relação a mudanças gera potencialmente uma vantagem competitiva.

2.2 TRIÂNGULO DE FERRO

Como visto em Casanova (2013), os projetos preditivos são orientados ao plano, pois são fortemente dependentes do planejamento atualizado do escopo, prazo e custo, dentre todas as áreas de conhecimento. Já os projetos ágeis são fortemente orientados à satisfação e o valor entregue ao cliente.

O gerenciamento de projeto objetiva realizar as entregas conforme o escopo, prazo, custos e qualidade. O Triângulo de Xxxxx é a representação do íntimo relacionamento entre estas variáveis do gerenciamento do projeto e uma metáfora popular que identifica muito bem o papel integrador do gerente de projeto (CACCAMES; BRAGANTIN, 2012).

A Figura 5 apresenta o Triângulo de Ferro para as abordagens tradicionais e ágeis de gerenciamento de projetos. Para os projetos preditivos, o escopo definido inicialmente deve ser preservado e o projeto finaliza apenas quando todo o escopo for produzido conforme planejado, mesmo que isso gere impactos em custos, prazo ou qualidade. Para os projetos ágeis, o triângulo é invertido de cabeça para baixo, com prazo, custos e qualidade que permanecem fixos. Assim, as mudanças de escopo são esperadas e bem-vindas, porque significam um resultado mais adequado para a realização do valor do negócio. No entanto, é fundamental que a equipe do projeto seja autorizada a tomar decisões de mudança de escopo de forma rápida e contínua durante a execução do projeto (CASANOVA, 2013).

Figura 5 – Triângulo de ferro – abordagens Preditiva e Ágil

Fonte: Adaptado pela autora da Figura 3 – O triângulo de ferro para abordagens tradicionais e ágeis de gerenciamento de projetos (CASANOVA, 2013).

2.3 CONTRATO ÁGIL

Em todo projeto ágil de desenvolvimento de sistemas haverão riscos financeiros e contratuais envolvidos que devem ser devidamente tratados no início do projeto, entre as partes, no momento da contratação. Mas, como enfatizado por Xxxxxx e Xxxxxx (2009), um propósito importante de todos os contratos é definir como os riscos são equilibrados no projeto.

Em Thorup e Xxxxxx (2009) é feita uma metáfora da importância do contrato em um projeto ágil de desenvolvimento de sistemas, como sendo uma pedra angular importante para o desenvolvimento ágil, visto o fato de projetos ágeis acertarem os detalhes do escopo durante o curso do projeto e definir escopo por iteração. A pedra angular é como a pedra fundamental utilizada nas antigas construções, caracterizada por ser a primeira a ser assentada na esquina do edifício, formando um ângulo reto entre duas paredes (PADILHA NETO; MENEZES; SOUSA, 2021). A partir da pedra angular, eram definidas as colocações das outras pedras, alinhando toda a construção. O contrato é a pedra angular do projeto ágil de desenvolvimento, é o elemento de sustentação que dá existência àquilo que será desenvolvido.

Ainda segundo Xxxxxx e Xxxxxx (2009), realizar um contrato ágil tem um objetivo duplo, pois minimiza os riscos de cumprimento de prazo, custo e escopo, uma vez que as decisões são tomadas quando mais conhecimento está disponível, e permite ajustes de escopo com base no feedback constante durante o desenvolvimento. A tendência é resultar em um produto muito mais próximo às necessidades dos usuários.

2.4 MODELO DE CONTRATAÇÃO

Um modelo de contratação dita o acordo realizado entre o cliente e o fornecedor referente a como serão realizadas as atividades até o final do projeto. No modelo de contratação está definido como serão realizadas as entregas, o processo do desenvolvimento, como será realizado o pagamento, seja mediante ao esforço realizado ou ao produto entregue ou ao tempo realizado ou marco alcançado ou benefício atingido, se haverá penalidades ou bônus, valores fixos ou variáveis referentes aos serviços a serem praticados, ou seja, todos os aspectos que devem ser previamente regulados antes da execução do projeto.

Os clientes de projetos preditivos decidem investir em projetos mediante uma análise de um business case que apresenta: alocação de recursos, escopo, prazos, custos, retorno do investimento – ROI, benefícios, riscos, lucros (DABRYTSKI, 2016). Em projetos preditivos, onde o escopo é totalmente conhecido, o business case é construído no início do projeto e apresenta todos estes pontos para decisão. Na Figura

6 é a presentado o fluxo de um projeto preditivo quando o business case é completamente criado no início do projeto.

Figura 6 – Business Case Preditivo

Fonte: Adaptação pela autora desta dissertação (DABRYTSKI, 2016).

Em um projeto ágil, contudo, como o escopo em sua essência é a parte variável devido ao desconhecido e incertezas do projeto, o business case não consegue ser elaborado completamente no início do projeto, pois todo o seu escopo só será conhecido ao final de todas as iterações (sprints). Ou seja, para criar um business case conforme a Figura 6, seria necessário planejar todas as iterações do projeto, o que o torna inviável e contrário à proposta ágil.

Para que o business case seja ágil ele tem que ser capaz de decolar (litf off) ou extrapolar o projeto, projetando-o para o futuro (DABRYTSKI, 2016), logo na primeira

iteração de preparação do projeto, comumente chamada de Sprint 0, mesmo sem ter todo o escopo. A Figura 7 apresenta o fluxo de elaboração do business case ágil.

Figura 7 – Business Case Ágil

Fonte: Adaptação elaborada pela autora dissertação (DABRYTSKI, 2016).

Mas, como fazer o business case em apenas uma iteração de duas semanas? A estratégia é a simplificação, um dos princípios ágeis (BECK, et al., 2001). Três simplificações são sugeridas (DABRYTSKI, 2016):

• Inversão do Triângulo de ferro (flip triangle): fixar o custo e prazo, ou seja, definir o orçamento geral do projeto e o prazo geral do projeto como limites máximos e entender quantas iterações cabem neste custo e prazo.

• Orçamento por equipe: determinar o custo da equipe com todos os profissionais participantes e não mais controlar o custo da hora por profissional, detalhadamente.

• Orçamento das demais despesas separadamente: as despesas com infraestrutura, licenças de software e outras despesas ficam controladas separadamente, pois demandam controle menos detalhado.

O entendimento de como um projeto ágil é concebido, como é elaborado seu business case e como ele será executado é importante para a definição do modelo de contratação. Todos esses elementos do projeto são considerados nesta pesquisa para a definição do modelo de contratação.

2.5 O ANALYTIC HIERARCHY PROCESS – AHP

O Analytic Hierarchy Process, AHP, ou Processo de Hierarquia Analítica será utilizado nesta pesquisa como método multicritério na decisão pela melhor forma de contratação a ser utilizada em um projeto ágil de desenvolvimento de sistema que está sendo negociado entre partes. No capítulo 4 será detalhado todo o processo de adaptação do AHP ao processo decisório desta pesquisa.

2.5.1 Métodos de Decisão

Como visto em Xxxxxx, Xxxxxx e Xxxxx (2009) e em Xxxxxxx, Xxxxxx e Simonetto (2010), tanto na vida particular como em organizações, buscam-se decisões entre alternativas disponíveis que tragam uma opção com melhor desempenho, retorno ou acordo entre as partes. Xx Xxxxxxx, Xxxxxx e Simonetto (2010), é enfatizado que o ser humano utiliza também, além do racional, todo o modelo pré-definido de experiências e vivências obtidas ao longo da vida para aplicar em suas escolhas.

Mas, nem sempre as alternativas trazem escolhas simples e diretas, ou seja, com apenas um critério a escolher. Processos complexos de escolha, com múltiplas ponderações, são mais difíceis de serem concluídos. Estes tipos de processos necessitam de métodos que ajudem a todos os envolvidos a entenderem o processo e ajudem até mesmo a como decidir de forma planejada, coerente e consistente.

Decidir o tipo de contrato a ser utilizado num processo de contratação de um projeto ágil de desenvolvimento de sistemas dentre os 31 tipos de contratos obtidos na RSL é um cenário de decisão complexo e de multicritério, como será visto no capítulo 4. Assim como em Barros, Xxxxxx x Xxxxx (2009), a escolha do tipo de contrato é um método multicritérios, pois vai necessitar de apoio na tomada de decisão, sendo consideradas diversas variáveis ou critérios para a priorização e seleção de alternativas, com clareza e, consequentemente, transparência.

Existem vários métodos multicritérios que poderiam ser aplicados, contudo, o método escolhido foi o AHP. Como citado em Xxxxxx e Xxxxxx (2012), o AHP

transforma uma comparação em pares dos critérios qualitativos, muitas vezes baseados em experiência, em números, o que viabiliza a comparação e priorização entre os critérios. A conversão de dados empíricos em valores quantitativos é o principal diferencial do AHP com relação a outras técnicas comparativas.

O PROMETHEE é um método multicritério de decisão desenvolvido por XX Xxxxx, que utiliza como base a relação de superação ou sobreclassificação. Este método requer dois tipos de informação: pesos relativos de importância entre os critérios de decisão e uma função definida pelos decisores quanto à preferência entre os critérios. A determinação dos pesos de importância não é determinada pelo método, pois entende-se que os decisores conseguem definir os pesos facilmente e de forma apropriada (MACHARIS; SPRINGAE; DE BRUCKER; XXXXXXX, 2004).

Comparando-se os dois métodos multicritérios de análise (multicriteria analysis methods - MCA) mais utilizados, sendo o AHP e o Preference Ranking Organisation MeTHod for Enrichment Evaluations (PROMETHEE), verifica-se que o método AHP tem uma vantagem que o distingue de decomposição do problema de decisão em hierarquia de critérios. PROMETHEE não oferece essa possibilidade de estruturação (MACHARIS; SPRINGAE; DE BRUCKER; XXXXXXX, 2004).

Além disto, o AHP integra no seu processo a checagem de integridade final dos seus resultados (MACHARIS; SPRINGAE;DE BRUCKER; XXXXXXX, 2004). A

aplicação do limite de inconsistência e a possibilidade de gerenciar este problema são frequentemente consideradas como vantagens do método AHP.

O AHP é altamente aplicável em situações que requeiram estruturação, medição, e / ou síntese, conforme Forman e Gass (2001), que citam áreas em que o AHP foi bem sucedido quando empregado: seleção de uma alternativa entre muitas, alocação de recursos, previsão, gestão da qualidade total, reengenharia de processos de negócios, implantação de função de qualidade, e o balanced scorecard.

2.5.2 Breve Histórico do AHP

O AHP foi criado pelo matemático Xxxxxx X. Saaty (18 de Julho de 1926 – 14 de Agosto de 2017), enquanto professor da Wharton School da Universidade da Pensilvânia (1969–79), sendo depois professor da Universidade de Pittsburgh.

O AHP é uma metodologia para estruturação, medição e síntese, assim como descrito em Forman e Gass (2001). O AHP tem sido aplicado a uma ampla gama de

situações problemáticas: selecionar entre alternativas concorrentes em um ambiente multi-objetivo, a alocação de recursos escassos e a previsão.

O AHP é provavelmente a abordagem de MCA mais conhecida e mais amplamente utilizada segundo (MACHARIS; SPRINGAE;DE BRUCKER; XXXXXXX, 2004). Em Forman e Gass (2001), o AHP é apresentado para resolução de problemas em cenários de multicritérios. Particularmente, apresenta uma etapa de comparações de alternativas aos pares, convertendo preferências individuais em pesos de escala de proporção que são combinados em pesos aditivos lineares para as alternativas associadas. Esses pesos resultantes são usados para classificar as alternativas e assim auxiliar o tomador de decisão em fazer uma escolha ou prever um resultado. São três etapas de tomada de decisão (BARROS; MARINS; XXXXX, 2009):

(1) construção de uma hierarquia,

(2) definição de prioridades e

(3) consistência lógica

Na primeira etapa, constrói-se uma hierarquia de critérios que seja facilmente comparável e analisável, o que Xxxxxx (2010) comenta ser uma decomposição do problema. A Figura 8 exemplifica uma hierarquia de critérios conforme o AHP. Estes critérios serão priorizados entre si, par a par, em uma etapa seguinte, utilizando uma escala de importância devidamente adaptada ao problema decisório em questão, quando, finalmente, todo o processo decisório é analisado quanto a sua integridade e consistência.

Figura 8 – Exemplo de Hierarquia de critérios/objetivos

Fonte: Figura 1 - Exemplo de hierarquia de critérios/objetivos (XXXXXX, 2010).

A Figura 9 apresenta o fluxo consolidado das ações realizadas para uma completa análise do AHP. A aplicação do AHP será apresentado no capítulo 4.

Figura 9 – Fluxo geral do AHP

Fonte: Figura 2. Fluxograma do Procedimento Analítico do AHP (DA COSTA ; BELDERRAIN, 2009).

2.6 ESTRATÉGIA EMPÍRICA DE EXPERIMENTO

Experimento (Controlled Experiment) é uma das três estratégias empíricas de estudos, sendo as demais Pesquisa (Survey) e Estudo de Caso (Case study). Segundo Xxxxxx (2000), a aplicação de cada uma depende do objetivo da avaliação, sejam técnicas, métodos ou ferramentas, além das condições para a investigação empírica.

Em engenharia de software, Experimento é uma pesquisa empírica que manipula uma variável ou fator do cenário em estudo. Geralmente são feitos em ambiente de laboratório, com alto nível de controle. Ao experimentar, os sujeitos são atribuídos a diferentes tratamentos aleatoriamente. O objetivo é manipular uma ou mais variáveis e controlar todas as outras variáveis em níveis fixos (XXXXXX, et al., 2000).

O Quase-experimento é uma variação similar ao Experimento, contudo as atribuições não são feitas de forma randômica, mas surgem das características dos próprios sujeitos ou objetos.

Um Experimento é uma investigação formal, rigorosa e controlada, além do forte aspecto quantitativo. Durante o Experimento, as diferentes variáveis são medidas e manipuladas, tendo os dados coletados e submetidos a análises estatísticas. Contudo, dados qualitativos podem ser coletados para ajudar na interpretação dos dados (XXXXXX, et al., 2000).

O Experimento utiliza o controle e manipulação diretos e precisos. A manipulação pode ser feita em uma situação simulada (off-line situation) ou em situação real (on-line situation). A situação simulada é feita em laboratório simulando um cenário da vida real. A situação real é excetuada em um contexto da vida real, o que reduz o nível de controle da situação (XXXXXX, et al., 2000).

Outra característica do Experimento é ser ou não automatizado. Os experimentos humanos (human-oriented) diferem dos experimentos automatizados (technology-oriented) pela aplicação da técnica a ser utilizada e pelo nível de controle, visto que em um experimento humano não é possível utilizar mais de uma técnica em um mesmo trecho de código, por exemplo.

A aplicação do Experimento é vasta, como por exemplo confirmar teorias, explorar relacionamentos, validar medidas, dentre outras aplicações, sendo a maior força de poder investigar em quais situações as afirmações são verdadeiras e poder fornecer um contexto no qual certos padrões, métodos e ferramentas são recomendados para uso (WOHLIN, et al., 2000).

2.6.1 O processo do experimento

Inicialmente, é formulada uma hipótese sobre uma idéia de um relacionamento de causa e efeito. O experimento vem como possibilidade de avaliar esta hipótese. No desenho do experimento, são elencados vários tratamentos, valores que a variável estudada pode assumir. O experimento é realizado e são obtidos os resultados, surgindo os relacionamentos entre o tratamento e o resultado. Ao final, são obtidas conclusões sobre a relação entre a causa e o efeito para o qual a hipótese foi formulada.

Quatro conceitos são importantes para o entendimento do Experimento: Variáveis, Tratamentos, Objetos e Sujeitos.

As variáveis podem ser dependentes e independentes, conforme a Figura 10. As variáveis dependentes (ou variáveis de resposta) mudam conforme as variáveis independentes, que são as variáveis estudadas, e que são manipuladas e controladas no processo. Frequentemente, há apenas uma variável dependente em um experimento.

Figura 10 – Desenho de um Experimento

Fonte: Adaptado pela autora, desta dissertação, da Fig. 6.3 Ilustration of na experiment (XXXXXX, et al., 2000).

O tratamento é a aplicação de um objeto por um sujeito. Xxxxxx (2000) traz um exemplo, de um objeto ser um documento que deve ser revisado com diferentes técnicas de inspeção. As pessoas que aplicam o tratamento são chamadas de sujeitos ou participantes. As características dos objetos e dos sujeitos podem ser variáveis independentes. Em experimentos orientados para humanos, os seres humanos são os sujeitos, aplicando diferentes tratamentos aos objetos.

Um experimento consiste em um conjunto de testes (às vezes chamados de trilhas), onde cada teste é uma combinação de tratamento, sujeito e objeto (WOHLIN, et al., 2000). Exemplo: Um teste pode ser aquela pessoa N (sujeito) usa o novo método de desenvolvimento (tratamento) para desenvolver o programa A (objeto).

O Experimento possui um processo definido com etapas executadas sequencialmente (WOHLIN, et al., 2000). Estas são as etapas:

• Escopo

• Planejamento

• Operação

• Análise e interpretação

• Apresentação e embalagem

Na primeira etapa é definido o Escopo do experimento quanto a objetivos e metas. Este escopo será planejado na sequencia, para garantia do sucesso do experimento. Em seguida, entra-se na etapa de operação, quando os testes serão realizados e medidos. Todos os dados são analisados e interpretados na etapa seguinte, para finalmente serem apresentados os resultados na última etapa.

O processo não deve ser um modelo em cascata "verdadeiro"; não se presume que uma atividade seja necessariamente concluída antes do início da próxima atividade. A ordem das atividades no processo indica principalmente a ordem de início das atividades. Em outras palavras, o processo é parcialmente iterativo e pode ser necessário voltar e refinar uma atividade anterior antes de continuar com o experimento.

A base do experimento é definida na etapa de escopo, sendo utilizado o modelo GQM para definição de objetivo e hipótese, originalmente apresentado por Xxxxxx e Xxxxxxx (XXXXXX, et al., 2000):

Analizar < Objetivo(s) do estudo > com o propósito de < Propósito >

com respeito ao < Foco na Qualidade > pelo ponto de vista da < Perspectiva > no contexto do < Contexto >

Como Objetivo do estudo está o que será estudado no experimento, que podem ser métricas, teorias, processos. Como exemplo, um processo de inspeção ou um processo de contratação, como o caso desta pesquisa. O Propósito define qual é a intenção do experimento. O foco na qualidade é o principal efeito em estudo no experimento. O Foco na Qualidade visa definir qual efeito é estudado, que pode ser eficácia, custo, confiabilidade, etc. A Perspectiva reflete a visão ou ponto de vista que se pretende analisar. Exemplos de perspectivas são desenvolvedor, gerente de projeto, cliente e pesquisador. O Contexto é em qual ambiente o estudo será conduzido. O contexto define brevemente os Sujeitos envolvidos e Objetos (artefatos de software) que serão usados no experimento (WOHLIN, et al., 2000).

A etapa de Planejamento é orientada em sete passos representados na Figura 11 (XXXXXX, et al., 2000). De forma geral, após definido o objetivo na etapa de

xxxxxx, a seleção do contexto seleciona o ambiente no qual o experimento será executado. Em seguida, ocorre a formulação da hipótese, a seleção das variáveis independentes e dependentes, assim como os sujeitos são definidos. Os próximos passos são a escolha do tipo de desenho do experimento, a instrumentação e, enfim, a validação do experimento.

Figura 11 – Desenho de um Experimento

Fonte: Fig. 8.1 Planning phase overview (XXXXXX, et al., 2000).

1 – Seleção do Contexto

Neste passo, é planejada a ambientação do experimento. Assim, o contexto do experimento pode ser caracterizado de acordo com quatro dimensões:

• Situação: Simulada (off-line) ou Real (on-line)

• Público: Estudantes ou Professional

• Problemas: Maquetes/Simuladores ou Problemas reais

• Amplitude: Especifica ou Geral 2 – Formulação da Hipótese Existem dois tipos de hipóteses:

• H0 ou Nula (Null): Uma hipótese nula, H0, afirma que não há tendências ou padrões reais subjacentes no ambiente do experimento; as únicas razões para diferenças em nossas observações são coincidências. Esta é a

hipótese de que o experimentador deseja rejeitar com a maior significância possível.

• H1: Uma hipótese alternativa, H1, por exemplo, é a hipótese a favor da qual a hipótese nula é rejeitada.

O teste de hipóteses envolve diferentes tipos de riscos. Ou o teste rejeita uma hipótese verdadeira ou o teste não rejeita uma hipótese falsa. Esses riscos são chamados de erro-tipo-I e erro-tipo-II:

Erro-tipo-I: Ocorreu um erro-tipo-I quando um teste estatístico indicou um padrão ou relacionamento, mesmo que não haja realmente um padrão real. Ou seja, o erro-tipo-I é a probabilidade de rejeitar H0, embora os dois métodos encontrem, em média, o mesmo número de falhas.

Erro-tipo-II: Ocorreu um erro-tipo-II quando um teste estatístico não indicou um padrão ou relacionamento, mesmo que não haja realmente um padrão real. Ou seja, o erro-tipo-II é a probabilidade de não rejeitar H0, embora os dois métodos em média tenham meios diferentes.

Para medir a capacidade do teste estatístico revelar um padrão verdadeiro nos dados coletados, foi criado o conceito da Potência (Power). A potência de um teste estatístico é a probabilidade de que o teste revele um padrão verdadeiro se H0 for falso. Um experimentador deve escolher um teste com a maior potência possível (WOHLIN, et al., 2000).

3 – Seleção das Variáveis

As variáveis independentes são aquelas variáveis que podemos controlar e alterar no experimento. O efeito dos tratamentos é medido na(s) variável(eis) dependente(s). Frequentemente, há apenas uma variável dependente e, portanto, deve ser derivada diretamente da hipótese.

Além da determinação das variáveis dependentes e independentes, são determinados também os valores que as variáveis realmente podem assumir. Isto inclui a determinação da escala de medição, assim como os limites da análise estatística.

4 – Seleção dos Sujeitos

Os sujeitos do experimento são definidos neste passo. Esta seleção é também chamada como amostra de uma população.

A amostra da população pode ser de dois tipos: probabilística ou não probabilística. A diferença entre as duas é que na amostra probabilística, a probabilidade de seleção de cada sujeito é conhecida e na amostra não probabilística é desconhecido. Nas probabilísticas as escolhas são randômicas e nas outras por conveniência.

5 - Escolha do tipo de desenho do experimento

A escolha do desenho está diretamente ligada ao sucesso do experimento. Três princípios devem ser analisados separadamente ou em conjunto: randomização, bloqueio e balanceamento.

A randomização se aplica à alocação dos objetos, sujeitos e em que ordem os testes são realizados. O bloqueio é usado eliminar sistematicamente o efeito indesejado na comparação entre os tratamentos, aumentando a precisão do experimento. Enquanto que o balanceamento é desejável porque ele tanto simplifica quanto fortalece a análise estatística dos dados.

Em Wohlin (2000) são sugeridos quatro tipos de desenhos:

• Um fator com dois tratamentos.

• Um fator com mais de dois tratamentos.

• Dois fatores com dois tratamentos.

• Mais de dois fatores cada um com dois tratamentos.

Esta pesquisa utilizou o desenho Um fator com dois tratamentos. Com esse tipo de experimento, compara-se dois tratamentos entre si. O mais comum é comparar as médias da variável dependente para cada tratamento.

Exemplo de um experimento: O objetivo é investigar se um novo método de desenho produz software com qualidade superior ao método de desenho usado anteriormente. O fator neste experimento é o método de desenho e os tratamentos são o novo e o antigo método de desenho. A variável dependente pode ser o número de falhas encontradas no desenvolvimento.

6 – Instrumentação

São três os tipos dos instrumentos para um experimento: objetos, diretrizes e instrumentos de medição. Objetos podem ser, por exemplo, especificações ou documentos de código de sistema. As diretrizes são necessárias para orientar os participantes do experimento. As diretrizes incluem, por exemplo, descrições de processos e listas de verificação. As medições em um experimento são realizadas por

meio da coleta de dados. Em experimentos intensivos em humanos, os dados geralmente são coletados por meio de formulários manuais ou em entrevistas.

O objetivo geral da instrumentação é fornecer meios para realizar as atividades e monitorá-las, sem afetar o controle do experimento.

7 - Validação do Experimento

O planejamento tem um recurso para garantir a qualidade do processo de Experimento. A análise da validade dos resultados faz este papel. A validade pode ser dividida em quatro classes principais: validade interna, externa, de construção e de conclusão. Assim, os resultados são analisados quantos os pontos de vista da confiabilidade dos resultados (interno), conforme o contexto (externo), a causa e o efeito proposto (construção), e a relação entre o tratamento e o resultado (conclusão) (XXXXXX, et al., 2000).

A etapa seguinte é a Operação, ou seja, quando acontece a coleta dos dados para serem analisados. Esta etapa é realizada em três passos: preparação, execução e validação dos dados. No passo de preparação, os tratamentos são aplicados aos sujeitos e também o material necessário é preparado, como, por exemplo, os formulários de coleta de dados. Os participantes são informados sobre a intenção do experimento, quando devem ter o seu consentimento e eles devem estar comprometidos. Na execução é quando os sujeitos realizam suas tarefas de acordo com diferentes tratamentos e os dados são coletados. No último passo, os dados coletados são validados.

Os dados coletados durante a operação fornecem as contribuições para esta etapa de Análise e interpretação. A primeira etapa da análise é tentar entender os dados usando estatísticas descritivas. Eles fornecem uma visualização dos dados, que ajudam a entender e interpretar os dados informalmente.

Esta etapa acrescenta uma importante atividade de interpretação, pois pode determinar a rejeição da hipótese. Isso forma a base para a tomada de decisões e conclusões sobre como usar os resultados do experimento.

A última etapa de Apresentação e embalagem se preocupa com a divulgação devida das descobertas para possíveis públicos diversos. Isso inclui principalmente a documentação dos resultados, que pode ser feita por meio de um artigo de pesquisa para publicação, um pacote de laboratório para fins de replicação ou como parte da base de experiência de uma empresa.

Duas atividades devem ser atendidas nesta etapa final: as lições aprendidas e os resultados do experimento devem ter sido devidamente arquivados, pois é importante facilitar a replicação do experimento.

2.7 CONSIDERAÇÕES FINAIS

Os conceitos da abordagem ágil e de contratação ágil, apresentados neste capítulo, concretizam a necessidade de realização de uma Revisão Sistemática da Literatura para atingir os objetivos desta pesquisa.

Com a identificação de modelos de contratação e montagem de uma base de dados de tipos de contrato, será possível introduzir o processo de decisão de multicritérios estruturado pela aplicação do AHP, atingindo o objetivo de construção do PSTC.

Por último, através do experimento será possível verificar a aplicação do PSTC de forma prática e em cenário real.

3 REVISÃO SISTEMÁTICA DA LITERATURA

Este capítulo apresenta a Revisão Sistemática da Literatura (RSL) que foi realizada para identificar e analisar tipos distintos de contratos para projetos ágeis de desenvolvimento de sistemas em contextos distintos. Será apresentado o protocolo da revisão, assim como a análise resultante.

3.1 AVALIANDO A NECESSIDADE DA ELABORAÇÃO DE UMA RSL

Uma RSL é conduzida por meio de um processo que envolve três fases (XXXXXXXXX; XXXXXXXX; FABBRI; FERRARI, 2017): Planejamento, Condução e Publicação dos resultados.

A fase de planejamento tem como objetivo identificar a real necessidade para a execução de uma RSL. Antes de iniciar o planejamento da revisão, é importante identificar se já existem estudos secundários sobre o mesmo tema. Caso não haja um estudo secundário sobre o tema e esse tema seja de relevância para a comunidade científica da área, justifica-se a realização da RSL (XXXXXXXXX; XXXXXXXX; FABBRI; FERRARI, 2017).

Inicialmente, foram levantadas as questões motivacionais para realização de uma RSL:

Tabela 2 – Questões motivacionais para a pesquisa

Pergunta	Resposta
Qual a razão para a pesquisa?	Facilitar a contratação – particularmente para clientes externos à organização que desenvolverá o software – de projetos de desenvolvimento de software ágeis, que a priori não implicam em definição detalhada de requisitos nas etapas inicias do projeto, o que pode dificultar a contratação por clientes que não ainda confiem no fornecedor e / ou não conheça a filosofia ágil.
O que se espera saber sobre o assunto?	Quais são as diferentes formas de contratação de projetos ágeis de desenvolvimento de software definidas na literatura, e as características específicas de cada uma delas.
Para que vai ser usado o resultado desta revisão sistemática?	Construir um catálogo de formas de contratação e tipos de contrato, e prover diretrizes sobre em qual contexto cada um deles é adequado.

Fonte: Elaborada pela autora desta dissertação (2021).

A seguir, foi realizada uma pesquisa não estruturada da literatura em bases bibliográficas (por exemplo, IEEE Xplorer, ACM Digital library e ScienceDirect).

Nesta pesquisa foram identificados inicialmente 12 artigos, apresentados na Tabela 3 dos quais um foi excluído por descrever um levantamento bibliográfico, mas que não se enquadra no processo de Mapeamento Sistemático (MS) ou de Revisão Sistemática da Literatura (RSL). Além disto, seis RSLs não eram recentes (anteriores a 2011).

Tabela 3 – Pesquisa de RSLs existentes

Titulo	Autor(es)	Palavras-chave	Data	Tipo
Systematic literature reviews in software engineering – A systematic literature review	Xxxxxxx Xxxxxxxxxx, X. Xxxxx Xxxxxxxx, Xxxxx Xxxxxx, Xxxx Xxxxxx, Xxxx Xxxxxx, Xxxxxxx Xxxxxxx	Systematic literature review Evidence-based software engineering Tertiary study Systematic review quality Cost estimation	2008	RSL
Systematic literature reviews in software engineering – A tertiary study	Xxxxxxx Xxxxxxxxxx, Xxxxxxxx Xxxxxxxxx, Xxxxx Xxxxxx, X. Xxxxx Xxxxxxxx, Xxxx Xxxxxx, Xxxxxxx Xxxxx, Xxxxxxx Xxxxxxx	Systematic literature review Mapping study Software engineering Tertiary study	2010	RSL
An Initial Mapping Study on MDE4IoT	Xxxxxx Xxxxx, Xxxxxxxxx Xxxxx, Xxxxxxxx Xxxxx	Model-driven engineering, internet of things, mapping study	2018	MS
THE PERCEPTION OF COMPANIES ON THE MOTIVATION, STRATEGIES AND BENEFITS OF THE ADOPTION OF SOFTWARE PROCESS IMPROVEMENT: A SYSTEMATIC MAPPING	Xxxxxxx Xxxxx xx Xxxxxxxxx, Xxxxx Xxxxxxx xx Xxxxx	XXX, Software, processes, improvement, Strategies	2017	MS
A Systematic Review Identifies a Lack of Standardization in OLAP Queries on Cloud Computing	Xxxxxx Xxxxxxxxx X. xx Xxxxx, Xxxxxxxx Xxxxxx, Xxxxx Xxxxxxx xx Xxxxx		2017	RSL
Estimativa de Projetos de Aplicativos Móveis: Um Mapeamento Sistemático da Literatura	Ervili X. X. xx Xxxxx, Tayana Conte		2017	MS
Lessons from applying the systematic literature review process within the software engineering domain	Xxxxx Xxxxxxxx, Xxxxxxx X. Xxxxxxxxxx, Xxxxx Xxxxxx,Xxxx Xxxxxx, Xxxxxxx Xxxxxx	Systematic literature review; Empirical software engineering	2006	RSL
Procedures for Performing Systematic Reviews	Xxxxxxx Xxxxxxxxxx		2004	RSL
Systematic Review in Software Engineering	Xxxxx Xxxxxxxxx, Xxxxx Xxxxx Xxxx, Xxx Xxxxxxx Xxxx Xxxxxx, Xxxxxxxxx Xxxxx Xxxxxxxxx		2005	RSL

Titulo	Autor(es)	Palavras-chave	Data	Tipo
Guidelines for Snowballing in Systematic Literature Studies and a Replication in Software Engineering	Xxxxx Xxxxxx	Systematic literature review, systematic mapping studies, snowballing, snowball search, replication	2014	RSL
Modelos de Colaboração no Desenvolvimento Distribuído de Software: uma Revisão Sistemática da Literatura	Xxxxxxx Xxxxx, Xxxxxxxx Xxxxx, Xxxxxx Xxxxxxxxxxxx, Xxxx Xxxxxxx xx Xxxxxxx, Xxxxxxx X. X. Xxxxxx, Xxxxxx Xxxxx		2009	RSL

Fonte: Elaborada pela autora desta dissertação (2021).

Uma análise dos textos identificou que nenhum deles correspondia à motivação previamente definida. Desta forma, entende-se que a RSL proposta está devidamente em linha com a necessidade de realização deste esforço.

3.2 PROTOCOLO

Para registro e elaboração do protocolo foi utilizada a ferramenta Start, fornecida pelo Laboratório de Pesquisa em Engenharia de Software – LAPES (2020).

3.3 INFORMAÇÕES GERAIS

Definida a real necessidade do estudo e sua contextualização, esta pesquisa seguiu para a elaboração do protocolo da RSL. O protocolo de pesquisa foi desenvolvido seguindo todos os pontos apresentados na bibliografia utilizada para elaboração de um planejamento que permita uma RSL de sucesso. Os artigos de RSL, conforme a Tabela 3, deram embasamento para a estruturação do protocolo, sendo utilizados como referência na elaboração da RSL:

• Xxxxxxxxx, Xxxxxxxx, Xxxxxx e Ferrari (2017) e Biolchini, Mian, Natali e Travassos (2005) apresentam os elementos para elaboração e execução de um protocolo;

• Xxxxxxxxxx (2007) detalha a estrutura PICO;

• Xxxxxx (2014) explica a técnica do snowballing para obtenção de estudos primários e

• Xxxxxx, Xxxxxxxx e Xxxxxxx (1994) descrevem a técnica Goal Question Metric.

3.3.1 Objetivo estruturado

Foi utilizado o modelo Goal Question Metric (GQM) sugerido por Xxxxxx, Xxxxxxxx e Rombach (1994), para definição dos objetivos de forma estruturada, garantindo que os aspectos importantes do estudo sejam definidos antes do planejamento e da execução.

O objetivo estruturado se apresenta conforme abaixo:

• Analisar estudos primários existentes

• Com o propósito de identificar modelos de contratação de projetos ágeis de desenvolvimento de sistemas

• Com relação ao sucesso da contratação do projeto, propiciando segurança e previsibilidade ao cliente das entregas do projeto e lucratividade do projeto ao fornecedor.

• Do ponto de vista das partes contratante e contratada

• No contexto de organizações que desenvolvem software para clientes externos à Organização (seja outra área da empresa ou outra empresa) e a própria organização cliente.

3.3.2 Objetivo não estruturado

O objetivo dessa revisão sistemática é identificar estudos primários existentes que abordem modelos de contratação de projetos ágeis de desenvolvimento de sistemas, objetivando o sucesso da contratação do projeto, propiciando segurança e previsibilidade ao cliente das entregas do projeto e lucratividade do projeto ao fornecedor.

3.4 QUESTÕES DE PESQUISA (RQ – REASERCH QUESTIONS)

Foram elaboradas as questões primárias e secundárias para esta pesquisa. Questões primárias:

RQ1: Existem modelos de contratação de projetos ágeis?

RQ2: Quais as propriedades e diretrizes referentes a cada modelo de contratação proposto?

Questões secundárias:

RQ3: Existem recomendações ou critérios de aplicação dos modelos de contratação conforme características dos projetos?

RQ4: Existem perfis de clientes identificados nos modelos de contratação?

3.4.1 Critérios pico para questões de pesquisa

O conjunto de critérios PICO, utilizados na Medicina, tem o objetivo de estruturar uma questão de pesquisa: P (população, paciente ou problema), I (intervenção), C (comparação, controle ou comparador) e O (resultados, do termo em inglês outcomes) (FELIZARDO; XXXXXXXX; XXXXXX; FERRARI, 2017). Estes

critérios foram adaptados à engenharia de software, conforme descrito em Kitchenham (2007).

Segue a estrutura PICO para esta pesquisa:

Tabela 4 – Estrutura PICO & Palavras-chave

População	Processos e projetos ágeis de desenvolvimento de sistema, que estão em fase de contratação.	Palavras-chave
		•Project, development, engineering
		•Process, method, methodology, practice
Intervenção	Contratos para Projetos ágeis de desenvolvimento de sistemas;
	Orçamentos;	•Procurement
	Propostas.	•Costs
		•Contracts, Proposals,
Comparação	Contrato tradicional com escopo e tempo fixos.
		•Agile Contract •Fixed price •Fixed scope
Resultado (Outcome) esperado ao final da RSL	Estudos propostos na literatura que reportam as formas de contratação eficientes em projetos ágeis de desenvolvimento de sistemas.

Fonte: Elaborada pela autora desta dissertação (2021).

Em Felizardo, Xxxxxxxx, Xxxxxx e Ferrari (2017), salienta-se a importância das palavras-chave que irão compor as strings de busca. É neste ponto, que é direcionada a atividade de extração de dados.

Inicialmente, foi utilizada uma string de busca com todas as palavras-chave identificadas na estrutura PICO. Contudo, a aplicação desta string, que continha muitas palavras-chave, trazia um universo muito restrito de estudos primários. A string original evoluiu para uma string que trazia uma boa amostra de estudos primários.

Tabela 5 – String de busca

String original de busca

(Project OR development OR engineering OR Process OR method OR methodology OR technique OR approach) AND

Agile AND

(Budget OR Costs OR Procurement OR Contracts OR Proposals OR Estimating OR Estimation OR (Costs AND estimation)) AND

( (Success AND agile AND contract) OR (Fixed AND bid AND agile) OR (Fixed AND price AND Agile) OR (Fixed AND price AND contract) OR (Budget AND failure) OR (Costs AND failure) )

String final de busca

((Agile AND Contracts) AND ("Software Engineering") AND (Project OR Procurement OR Practices OR Model))

Fonte: Elaborada pela autora desta dissertação (2021).

3.5 IDENTIFICAÇÃO DE ESTUDOS

Neste ponto, busca-se fazer um planejamento de como serão alcançados os estudos direcionados para a RSL. Assim, são os instrumentos desta busca: palavras- chave, strings de busca, critérios de seleção das fontes de busca, lista das fontes de busca e a estratégia de busca (XXXXXXXXX; XXXXXXXX; XXXXXX; FERRARI, 2017).

Conforme Felizardo, Xxxxxxxx, Xxxxxx e Ferrari (2017), a estratégia de busca é a forma com que os estudos serão procurados nas fontes estabelecidas. Foram escolhidas 4 bases bibliográficas: ACM Data Library, IEEE, Science e Springer. Estas bases exportam as pesquisas em arquivos texto do tipo biblioteca (bib) ou em arquivo texto separado por vírgulas (CSV), o que facilitou a manipulação dos dados identificados.

Foram obtidos 1902 estudos primários para realizar a seleção. Dentre eles, 13 estudos estavam em duplicidade, o que definiu o tamanho da amostra a 1889 estudos a serem selecionados, conforme Xxxxxx 6 a seguir. O gráfico da Figura 12 apresenta a distribuição entre as bases bibliográficas onde a Springer ocupa o primeiro lugar com 51% dos estudos primários pesquisados, seguidos da ACM com 27% e a Science Direct com 20%, a IEEE com 1% apenas, num total de 17 estudos.

Tabela 6 – Quantitativo pesquisado na Seleção

Base Bibliográfica	Quantidade pesquisados	Quantidade duplicados
ACM DL	522	7
IEEE	17	6
SCIENCE DIRECT	386	0
SPRINGER	977	0
SUB-TOTAL	1902	13
TOTAL	1889

Fonte: Elaborada pela autora desta dissertação (2021).

Figura 12 – Distribuição de estudos primários selecionados por Base de Bibliográfica

Fonte: Elaborada pela autora desta dissertação (2021).

3.6 SELEÇÃO E AVALIAÇÃO DE ESTUDOS

3.6.1 Critérios de inclusão e exclusão

Nesta etapa foram definidos os critérios de inclusão e exclusão, estratégia para seleção dos estudos e a avaliação da qualidade dos estudos (XXXXXXXXX; XXXXXXXX; FABBRI; FERRARI, 2017).

Critérios de inclusão e exclusão guiam a seleção de estudos primários que sejam relevantes para aquela RSL (XXXXXXXXX; XXXXXXXX; XXXXXX; FERRARI, 2017).

Uma vez definidos os critérios de inclusão (Insert Criteria-IC) e exclusão (Exclude Criteria-EC), definiu-se a estratégia para seleção dos estudos. Esta consiste tanto em estabelecer as etapas da seleção (seleção inicial, seleção final e revisão da

seleção), quanto a maneira como os critérios de inclusão e exclusão deverão ser aplicados durante essas etapas, ou seja, é preciso definir se para aceitar um estudo basta que ele satisfaça um ou alguns dos critérios de inclusão, ou, eventualmente, todos eles (XXXXXXXXX; XXXXXXXX; XXXXXX; FERRARI, 2017).

A seguir, os critérios de inclusão e exclusão definidos:

IC1: Artigos sobre modelos, formas, métodos ou práticas em contratação de projetos ágeis

IC2: Os artigos devem ser datados a partir de 2011

IC3: Artigos de estudos primários

IC4: Artigos escritos nas línguas portuguesa ou inglesa. EC1: Artigos que não se referem ao estudo em questão EC2: Artigos de literatura informal

EC3: Artigos apresentando a metodologia de elaboração de RSL ou ML

EC4: Artigos duplicados, quando o mesmo artigo é publicado em mais de uma revista, jornal ou ambiente acadêmico.

EC5: Estudos que não estejam disponíveis livremente para consulta na web ou nas bases bibliográficas.

3.6.2 Processo de seleção dos estudos primários

Foi adotada a seguinte estratégia (Selection Criteria – SC), de etapas sucessivas, para identificação dos estudos primários:

SC1: Realizar a análise do título, conforme os critérios de inclusão e exclusão. Os artigos com títulos com critérios de inclusão válidos seguem para a próxima etapa SC2 e os demais são excluídos;

SC2: Realizar a leitura e análise do resumo(abstract). Os artigos com resumo com critérios de inclusão válidos seguem para a próxima etapa SC3 e os demais são excluídos;

SC3: Realizar a leitura e análise da introdução. Os artigos com introdução com critérios de inclusão válidos seguem para a próxima etapa SC4 e os demais são excluídos;

SC4: Por fim, os estudos selecionados devem ser lidos na íntegra, extraídos os dados considerados relevantes e registrados os critérios de qualidade (Quality Criteria

– QC).

Para validação dos trabalhos a serem utilizados como referências, foram adotados os seguintes critérios de qualidade:

QC1: Os objetivos da pesquisa estão claramente definidos? ={Sim,Não,N/A}

QC2: Existe uma clara descrição do contexto no qual a pesquisa foi realizada?

={Sim,Não,N/A}

QC3: O trabalho é adequadamente referenciado (apresenta trabalhos relacionados/semelhantes e baseia-se em modelos e teorias da literatura)?

={Sim,Não,N/A}

QC4: O estudo relata de forma clara e não ambígua os resultados?{ Totalmente, Parcialmente,Não atende}

QC5: Os objetivos ou questões do estudo são alcançados?{ Totalmente, Parcialmente,Não atende}

QC6: Apresenta modelo de contratação?{Sim,Não,N/A}

QC7: Apresenta boa prática de contratação?{Sim,Não,N/A}

A Tabela 7 apresenta o quantitativo ao final da primeira etapa do processo de seleção, tendo sido realizadas as estratégias SC1, SC2 e SC3.

Tabela 7 – Quantitativo ao final da primeira etapa do processo de Seleção

	Quantidade
Pesquisados	1902
Duplicados	13
Rejeitados	1861
ACEITOS	28

Fonte: Elaborada pela autora desta dissertação (2021).

A Tabela 8 apresenta o quantitativo de artigos após a leitura completa (SC4) dos 28 artigos, rentando apenas 17 artigos aceitos. Como esta quantidade não representa uma quantidade suficiente para uma revisão sistemática da literatura, foi utilizada a técnica de snowballing que será apresentada a seguir.

Tabela 8 – Quantitativo ao final da segunda etapa do processo de Seleção

	Quantidade
ACEITOS ANTES SC4	28
Duplicados	1
Rejeitados SC4	10
ACEITOS	17

Fonte: Elaborada pela autora desta dissertação (2021).

3.6.2.1 Snowballing

Ao final da segunda etapa do processo de seleção, muitos estudos foram excluídos e apenas 17 estudos foram selecionados. Considerou-se importante aumentar a quantidade de estudos primários a serem analisados. Para isso, foi utilizada a técnica de snowballing (WOHLIN, 2014), nas seguintes etapas:

• Analisar referências dos estudos selecionados

• Buscar artigos dos autores dos trabalhos previamente selecionados com mais estudos selecionados

• Aplicar o protocolo em revistas e anais de conferenciais de grande expressão.

O mesmo processo de seleção anteriormente aplicado (SC1, SC2, SC3 e SC4) foi utilizado durante o snowballing.

A etapa 1 do snowballing identificou mais 3 artigos. Na etapa 2, foram selecionados os autores Xxxxx Xxxxxxxxx e Xxxxxxxx Xxxxxxx. Foram encontrados mais 5 artigos, sendo 4 de Jorgensen e 1 de Gaebert.

Na terceira etapa do snawbolling, pesquisou-se artigos em conferências renomadas na área de engenharia de software. A Tabela 9 apresenta um resumo da pesquisa realizada com os quantitativos de títulos lidos, resumos lidos, introduções lidas, resultando em apenas um artigo aceito na primeira fase de seleção (SC1, SC2, SC3). Após a fase SC4 de leitura completa do artigo, o artigo foi rejeitado.

Tabela 9 – Quantitativo pesquisado com Snowballing – Conferencias

CONFERENCIA	Qtd Títulos	Qtd Resumo	Qtd Introdução	Qtd Aceito
SBES	258	1	0	0
ICSE	1365	1	0	0
SBSI	329	2	0	0
SEKE	1332	2	0	0
XP - Agile Processes in Software Engineering and Extreme Programming	247	7	0	1
TOTAL	3531	13	0	1

Fonte: Elaborada pela autora desta dissertação (2021).

A Tabela 10 apresenta o quantitativo final de 25 artigos aceitos com o processo de snowballing. O processo de seleção foi finalizado entendendo-se que todo o esforço possível foi realizado para obtenção de artigos consistentes com o objetivo da RSL.

Tabela 10 – Quantitativo pesquisado com Snowballing

	Quantidade
ACEITOS ANTES snowballing	17
Referencias dos estudos selecionados	3
Demais artigos dos autores com mais estudos selecionados	5
Jornais, revistas e anais de conferenciais	0
ACEITOS	25

Fonte: Elaborada pela autora desta dissertação (2021).

De forma consolidada, a Tabela 11 apresenta os estudos primários finais selecionados da RSL:

Tabela 11 – Estudos primários da RSL

Estudo primário	Referencia
Contracting Agile Developments for Mission Critical Systems in the Public Sector	(RUSSO; TACCOGNA; CIANCARINI; MESSINA; SUCCI, 2018).

Estudo primário	Referencia
Experience of Executing Fixed Price Off-Shored Agile Project	(BANERJEE; XXXXXXXXXX; KANAKALATA, 2011).
Challenges with Lack of Trust in Agile Projects with Autonomous Teams and Fixed-Priced Contracts	(LINDSJØRN; MOUSTAFA, 2018).
What Contributes to the Success of IT Projects? Success Factors, Challenges and Lessons Learned from an Empirical Study of Software Projects in the Norwegian Public Sector	(MOHAGHEGHI; XXXXXXXXX, 2017).
Early Phase Cost Models for Agile Software Processes in the US DoD	(ROSA; XXXXXXX; XXXXX; XXXXX, 2017).
Relationships Between Project Size, Agile Practices, and Successful Software Development: Results and Analysis	(XXXXXXXXX, 2019).
Rolling Out a Mission Critical System in an Agilish Way. Reflections on Building a Large-Scale Dependable Information System for Public Sector	(XXXXX; MIKKONEN, 2015).
Contracting in Agile Software Projects: State of Art and How to Understand It	(ZIJDEMANS; STETTINA, 2014).
Agile Technical Management of Industrial Contracts: Scrum Development of Ground Segment Software at the European Space Agency	(SANTOS; FLENTGE; BEGIN; NAVARRO, 2011).
adVANTAGE: A Fair Pricing Model for Agile Software Development Contracting	(BOOK; GRUHN; STRIEMER, 2012).
How Agile Development Can Transform Defense IT Acquisition	(CHANG; MESSINA; XXXXXXXXXX, 2016).
Cost Estimation in Agile Software Development Projects	(LANG; CONBOY; KEAVENEY, 2013).
Contract Design and Uncertainty in Software Development Projects	(GAEBERT, 2014).
The Fixed-Price Contract: A Challenge for the Software Development Project	(GAEBERT, 2015).
Supplier ranking by multi-alternative proposal analysis for agile projects	(XXX-XXXXX; XXXXXXX; XXXXXXXX, 2012).
A survey on the characteristics of projects with success in delivering client benefits	(XXXXXXXXX, 2016).
Simple Method Proposal for Cost Estimation from Work Breakdown Structure	(XXXXXXXX; XXXXX, 2015).
Ex post adaptations and hybrid contracts in software development services, Appl. Econ. 45 (32) (2013) 4533–4544.	(FINK; LICHTENSTEIN; WYSS, 2013).
Adapting funding processes for agile IT projects: an empirical investigation. European Journal of Information Systems, 22(2), pp. 191-205.	(XXX; XXXXX; XXXXXX, 2013).
Direct and Indirect connections between type of contract and software project outcome. Xxxxxx.xx/xxxxxxxxxxxx.	(XXXXXXXXX; XXXXXXXXXX; GRIMSTAD, 2017).
Reliable Customers and Credible Fixed-Price Contracts for Software Development Projects: A Study of one Supplier’s Contracts	(GAEBERT, 2015).
Better Selection of Software Providers Through Trialsourcing	(XXXXXXXXX, 2016).

Estudo primário	Referencia
What We Do and Don’t Know about Software Development Effort Estimation	(XXXXXXXXX, 2014).
Software development contracts: The impact of the provider’s risk of financial loss on project success	(XXXXXXXXX, 2017).
The Use of Precision of Software Development Effort Estimates to Communicate Uncertainty	(XXXXXXXXX, 2016).

Fonte: Elaborada pela autora desta dissertação (2021).

3.7 SÍNTESE DOS DADOS E APRESENTAÇÃO DOS RESULTADOS

Conforme Felizardo, Xxxxxxxx, Xxxxxx e Ferrari (2017), o objetivo da seção Síntese dos dados e apresentação dos resultados é documentar como serão extraídos os dados dos estudos considerados relevantes para responderem às questões de pesquisa da RSL e como esses dados serão sumarizados e divulgados. Assim, contém itens como estratégia de extração e sumarização de dados e estratégia de publicação.

Os dados são mapeados em formulário para que os dados a serem extraídos sejam registrados de maneira uniforme para todos os estudos e, em atividades posteriores, analisados e sumarizados (FELIZARDO; XXXXXXXX; XXXXXX; FERRARI, 2017). Nesta RSL, a extração e registro dos dados foram feitos, a cada leitura completa dos artigos, utilizando uma planilha eletrônica com a identificação de propriedades, critérios, elementos e tipos de contratos, assim como todas as características que diferenciassem ou que fossem distintas entre os artigos. Ao final, a planilha eletrônica base da extração foi remodelada e foi origem para todas as análises desta pesquisa.

Em Felizardo, Xxxxxxxx, Fabbri e Ferrari (2017), para cada questão, devem ser coletados dados referentes aos diferentes campos estabelecidos no formulário de extração de dados, definido inicialmente no protocolo da revisão. Além disto, o formulário definido em fase de planejamento, não quer dizer que ele não seja alterado durante a execução da RSL. Inevitavelmente, com o andar da execução, alguns novos pontos que sejam relevantes são levados a alteração do formulário.

Após a extração e coleta dos dados devidamente classificados, é realizada uma sumarização a ser apresentada. Ainda segundo Xxxxxxxxx, Xxxxxxxx, Xxxxxx e Ferrari (2017), esta sumarização tem como objetivo principal combinar os dados extraídos de cada um dos estudos primários considerados. A síntese pode ser

elaborada por diferentes métodos que estruturem a lógica entre o que é apresentado nos estudos primários e as conclusões geradas pela RSL.

Em Felizardo, Xxxxxxxx, Xxxxxx e Ferrari (2017) são apresentados alguns métodos de síntese de dados como apresentados na Tabela 12, que orientou a escolha pelo método mais adequado a ser utilizado nesta RSL.

Tabela 12 – Comparação entre métodos de síntese

	Métodos de síntese
	Meta-análise	Narrativa	Temática	Comparativa qualitativa
Pontos Fortes	Permite afirmar com uma margem de segurança a existência ou não de um efeito e seu tamanho médio (PICKARD et al., 1998)	Pode construir explicações ricas que incluem comentários e abstrações de alto nível (DIXONWOODS et al.,2005)	Segue um processo de síntese flexível e permite sintetizar diferentes tipos de estudos (DIXON- WOODS et al., 2005)	Segue um processo de síntese transparente, sistemático e lógico; encoraja uma abordagem evolucionária e integrativa do conhecimento ao permitir a síntese de estudos secundários e primários (XXXXX-XXXXX et al., 2005)
Pontos Fracos	Falta de informação sobre os estudos e os dados dos experimentos podem dificultar a adoção do método; homogeneidade e qualidade dos estudos incluídos impactam a confiabilidade da síntese (PICKARD et al., 1998)	Segue um processo de síntese informal que pode ser criticado pela falta de transparência (DIXONWOODS et al., 2005)	Se considerar apenas os temas reportados pelos estudos incluídos, restringirá os de ordem mais elevada que podem aparecer (DIXONWOODS et al., 2005)	Depende da transformação de evidências qualitativas em quantitativas; considera a ausência de evidência como evidência da ausência (XXXXXXXXXX et al., 2005)
Tipo de evidências	Quantitativa	Quantitativa e Qualitativa	Quantitativa e Qualitativa	Quantitativa e Qualitativa
Exemplo de questão de pesquisa	O uso de uma nova ferramenta melhora a produtividade de desenvolvimento (sem nenhum efeito prejudicial na qualidade) em comparação com o uso de uma ferramenta existente? (XXXXXXX et al., 1998)	Em quais áreas de teste não funcional têm sido aplicadas meta- heurísticas de busca? (XXXXX et al., 2009)	Quais são os desafios de coordenação apresentados por dimensões de dispersão nos resultados de projetos globais de desenvolvimento de software? (XXXXXXXXX et al., 2015)	A RS tem como objetivo comparar os resultados de estudos empíricos sobre a eficácia de diferentes técnicas para elicitação de requisitos? (XXXXX et al., 2006)

Fonte: Tabela 5.1 - Comparação entre métodos de síntese (FELIZARDO; XXXXXXXX; XXXXXX; FERRARI, 2017).

Diante dos tipos de estudos primários selecionados e das características das extrações e análises obtidas, o método Síntese Narrativa, conforme Felizardo, Nakagawa, Fabbri e Ferrari (2017), foi identificado como o método mais apropriado a ser aplicado na síntese desta RSL. Métodos quantitativos sintetizam experimentos controlados e os métodos qualitativos buscam estabelecer uma conexão forte entre

as evidências e os resultados para viabilizar a replicação e confirmação da análise por revisores externos. Mas, a Síntese Narrativa se configura um método misto como será apresentado na próxima seção.

3.8 SÍNTESE NARRATIVA

O método de Síntese Narrativa procura construir uma história a partir das evidências encontradas nos estudos incluídos. Os passos recomendados para conduzir essa síntese são (XXXXXXX, et al., 2009) :

(i) desenvolvimento de uma teoria;

(ii) desenvolvimento de uma síntese preliminar;

(iii) exploração de relacionamentos dentro e entre estudos, e

(iv) avaliação da robustez do produto da síntese. Estes passos são apresentados na Figura 13:

Figura 13 – Passos da síntese narrativa apresentada por Xxxxxxx no seu estudo de caso (Synthesis Process)

Fonte: Orientação Metodológica de Teste sobre a Conduta de Síntese Narrativa em Revisões Sistemáticas, (XXXXXXX, et al., 2009).

Como descrito em Xxxxxxx (2009), este método é comumente usado para criar um resumo narrativo dos resultados dos estudos de uma RSL. Este método não dispensa métodos quantitativos e estatísticos, mas estes podem ser agregados.

Segundo Xxxxxxxxx, Xxxxxxxx, Xxxxxx e Ferrari (2017), no primeiro passo é traçada uma possível teoria para os objetivos, contexto e resultados dos estudos. Em seguida, os estudos primários são analisados através de tabulações, agrupamentos ou traduções, quando são extraídas as suas características e conexões. Para demonstrar as conexões e relacionamentos encontrados nesta fase, é possível que surjam análises qualitativas ou representações gráficas. Ao final, procede-se a validação das conclusões encontradas, o que pode ser feito com análise crítica sobre o processo da síntese em si, assim como obtendo-se critica com os autores dos estudos da RSL.

A Tabela 13 organiza uma lista de possíveis ferramentas apresentadas em Rodgers (2009), que podem ser utilizadas neste método. A Figura 13 apresenta como o autor descreveu as ferramentas ou técnicas utilizadas (relevantes) e as que não foram aplicadas na síntese narrativa exemplificada no seu estudo primário.

Tabela 13 – Ferramentas e técnicas da Síntese Narrativa

Passo	Ferramenta/Técnica
Desenvolvendo uma teoria	Textos descritivos
Desenvolvendo uma síntese preliminar	Tabulação
	Agrupamentos e aglomerações
	Textos descritivos
	Transformando dados: construindo uma rubrica comum
	Tradução de dados
	Contagem de votos como uma ferramenta descritiva
Explorando relações dentro e entre estudos	Construindo modelos conceituais/teia de ideias/mapeando conceitos
	Descrições qualitativas de casos
	Representação visual dos relacionamentos entre as características e resultados dos estudos
	Exame de variáveis de moderador e análises de subgrupo
	Triangulação conceitual
	Tradução recíproca

Passo	Ferramenta/Técnica
	Triangulação investigativa e metodológica
Avaliando a robustez da síntese	Best evidence synthesis
	Checking the Synthesis product with authors of primary studies
	Reflecting critically on the synthesis process
	Use of validity assessment

Fonte: Elaborada pela autora conforme (XXXXXXX, et al., 2009).

Seguindo o método e a mesma didática aplicada por Xxxxxxx (2009), a Figura

14 apresenta as ferramentas que foram utilizadas na Síntese Narrativa desta RSL. Na sequencia, seguem as considerações de cada ferramenta ou técnica aplicada nesta síntese narrativa.

Figura 14 – Passos da síntese narrativa da RSL

Fonte: Elaborada pela autora desta dissertação (2021).

3.8.1 Elemento 1: desenvolvendo uma teoria

Neste passo inicial desenvolve-se uma teoria que norteia a analise a ser realizada dos dados extraídos dos estudos primários. Nesta pesquisa foi elaborada a seguinte teoria:

É possível orientar o uso de tipos de contratações a partir de características do projeto de desenvolvimento de sistema a ser realizado.

3.8.2 Elemento 2: desenvolvendo uma síntese preliminar

No desenvolvimento da síntese preliminar, é traçado um paralelo de análise se as questões de pesquisa desta RSL foram respondias com os elementos extraídos dos estudos. A Síntese Narrativa traz ferramentas para esta análise. As questões primárias e secundárias foram apresentadas na seção 3.4.

Nem todos os 25 estudos responderam diretamente as questões de pesquisa da RSL. A RQ4 (RQ4: Existem perfis de clientes identificados nos modelos de contratação?) não foi respondida, pois, mesmo que houvesse sido feito um mapeamento, não foi encontrado relacionamento direto entre o tipo do cliente (Público, Privado, Misto) ou segmento (Industria, Serviço, Varejo, etc.) ou outro tipo de perfil de cliente com os modelos de contratação.

Além disto, novos elementos sugiram e, mesmo que inesperados, foram incorporados à análise. Visando mapeá-los, o passo inicial foi criar uma base de dados na fase de extração, buscando identificar todos estes elementos e em quais estudos apareceram e como foram utilizados. A Figura 15 representa o esta base de dados dos estudos primários da RSL.

Figura 15 – Quadro de Artigos

Fonte: Elaborada pela autora desta dissertação (2021).

3.8.2.1 Tabulação

A Figura 15 mostra a base de dados que foi montada ao longo do processo de extração. A estrutura da planilha base de extração é formada por linhas que representam cada estudo primário descrito por seu título, código na base de dados da ferramenta Start (ID Paper), autores, fonte bibliográfica, abstract/resumo, situação de seleção (Status/Selection podendo assumir os valores ACCEPT, REJECT ou DUPLICATED), situação de extração (Status/ Extraction podendo assumir os valores ACCEPT, REJECT ou DUPLICATED), prioridade de leitura após seleção (Reading Priority podendo assumir os valores LOW, HIGH ou VERY_HIGH), Score (calculado pela ferramenta Start), ano, fonte de publicação (Journal), palavras chave (Keywords) e comentários.

Para cada estudo foram acrescidas colunas com as questões primárias (RQ1 e RQ2) e secundárias (RQ3 e RQ4) para que fossem respondidas a cada leitura.

Na seção 3.8.2.2 serão descritas as classificações dos elementos encontrados nos estudos e como estes elementos foram agrupados e relacionados até formarem duas bases de dados de conceitos primordiais para esta pesquisa: FATORES DETERMINANTES e TIPOS DE CONTRATOS.

3.8.2.2 Agrupamentos e aglomerações

No Quadro de Artigos foram extraídas quatro categorias, além de terem sido identificados alguns casos que, após a análise global tornaram-se, sem relevância. A Tabela 14 lista os agrupamentos realizados na base de dados de extração dos estudos primários da RSL.

Tabela 14 – Agrupamento dos elementos do Quadro de Artigos

Tipo de contrato

Sem relevância ou variação entre os artigos

Dados do estudo de caso ou ambiente do artigo

Característica a ser considerada para definição do modelo – Fator determinante

Característica a ser considerada para definição do modelo – Expoente

Fonte: Elaborada pela autora desta dissertação (2021).

Assim que um novo elemento era identificado na leitura de um estudo, uma nova coluna era criada na base de extração e pintada conforme a cor da legenda de agrupamento conforme a Tabela 14. A cor verde será explicada na seção 3.8.3.1. A cor vermelha só foi aplicada ao final da análise da extração, quando não houve identificação de conexão ou relacionamento entre o elemento e as conclusões da RSL. Os elementos agrupados nas cores amarelo e rosa, ao final, foram utilizados para a formação do conceito de Fator Determinante de Forma de Contratação, que será utilizado no capítulo 4. Contudo, os elementos de cor amarelo são característicos ou expoentes no estudo primário em questão, ou seja, não se repete em outros estudos ou são mais próprios do autor em questão.

Outra técnica de agrupamento utilizada foi a criação do conceito de Formas de Contratação. Os tipos de contratos foram agrupados em Formas de Contratação para melhor apresentação e facilidade de entendimento do tipo de contrato a ser selecionado para o projeto ágil em questão.

Forma de Contratação foi um conceito criado como produto da Síntese Narrativa. Uma Forma de Contratação apresenta as características comuns de todos os tipos de contratos agrupados, padronizando a descrição de cada tipo de contrato individualmente. A Tabela 15 apresenta as Formas de Contratação estruturadas nesta pesquisa.

Tabela 15 – Agrupamento dos Tipos de Contratos em Formas de Contratação

FORMA DE CONTRATAÇÃO		DESCRIÇÃO
TC	TETO DE CUSTO	Contrato com custos fixos. O tempo e o escopo podem variar, mas as duas partes se alinham no início do contrato a preço que será pago pelo cliente se o provedor entregar tudo o que foi prometido.
BN	BÔNUS/PENALIDADE	Contrato que tem um custo extra se o projeto tiver um desempenho melhor do que o esperado. No início do projeto, as duas partes se alinham sobre quais bônus serão pagos e as premissas dos mesmos. O mesmo referente às penalidades caso o desempenho não seja atingido.
HD	HÍBRIDA	Contrato que utiliza um tipo de contrato para cada fase do projeto. Geralmente, cada fase do projeto utiliza o tipo de contrato que melhor se adapta às suas entregas.
UT	UNIDADE DE TRABALHO	Contrato que tem o custo determinado por unidade de tempo. A unidade de tempo pode ser definida por hora, semana, mês, iteração (sprint) ou qualquer outra porção de tempo. O cliente não tem os requisitos de sistema completos e pode terminar o projeto a qualquer momento. O cliente paga exatamente pelo esforço despendido pelo desenvolvedor, contratando as unidades de tempo de trabalho que forem necessárias. O cliente seleciona o fornecedor com a melhor competência e concorda com um preço pelo tempo de trabalho para diferentes tipos de habilidades e por outras despesas necessárias para entregar o produto ou serviço desejado.

Fonte: Elaborada pela autora desta dissertação (2021).

A utilização da técnica de agrupamento foi importante para facilitar a diferenciação entre os tipos de contratos. Como foram identificados 31 tipos de contratos, muitos apresentavam características muito próximas e que definiam uma mesma categoria de tipo de contrato. Assim, surgiram as Formas de Contratação para facilitar a classificação do tipo de contrato. Todos os tipos de contrato serão apresentados na seção 0 a seguir.

Cada Forma de Contratação tem sua característica mais forte, a TETO DE CUSTO não é simplesmente uma contratação de custo fixo (Fixed Price) como inicialmente se identifica. Esta forma de contratação determina que existe um valor total acordado entre as partes e que não haverá mecanismo para ultrapassar este teto contratado. Esta forma de contratação é amplamente utilizada e mais facilmente encontrada como mostra a Figura 23. O cliente possui uma falsa ideia de proteção por utilizar esta forma de contratação, pois acredita que tendo um valor já determinado, o seu risco financeiro já está minimizado ou até mesmo aniquilado. Contudo, corre risco de contratação de desenvolvedor sem a devida ou sem a melhor competência para o trabalho, além de levar a transtornos futuros devido a altas taxas de mudanças do

escopo quando estes modelos são aplicados. Diversos estudos primários da RSL salientam estes riscos de utilização desta forma de contratação. Foram catalogados 13 tipos de contratos da forma de contratação TETO DE CUSTO.

A forma de contratação UNIDADE DE TRABALHO tem foco na unidade de medida do custo do trabalho contratado. Deve ser determinada a unidade de tempo de medição da unidade de trabalho. A unidade de trabalho engloba todos os tipos de profissionais que compõem o período de tempo contratado. Como exemplo, pode-se contratar por iteração (sprint), sendo uma iteração quinzenal. Assim, o cliente paga exatamente pelo esforço despendido pelo desenvolvedor, contratando as unidades de tempo de trabalho que forem necessárias.

As formas de contratação BÔNUS/PENALIADADE e HIBRIDA não são facilmente identificadas, mas possuem claramente suas distinções. A forma de contratação BÔNUS/PENALIADADE apresenta uma forma de premiação caso um objetivo, previamente pactuado no início do contrato, seja alcançado. Em alguns tipos de contrato, é possível existir um acordo de penalidade de uma das partes caso o objetivo não seja alcançado.

A forma de contratação HIBRIDA pode utilizar um tipo de contrato para cada fase do projeto. Geralmente utilizada em projetos com fases distintas ou entregas distintas, determinando tipos de contratos distintos que melhor se adequam a cada fase do projeto.

3.8.2.3 Textos descritivos

Como cada estudo primário descreve os tipos de contratos de forma distinta, foi necessário consolidar de uma forma textual única todos os tipos de contratos em um quadro chamado de Tipos de Contratos, conforme apresentado na Figura 16 – Quadro de Tipos de Contratos.

Os 31 tipos de contrato foram descritos textualmente e através de características para que sejam adequadamente descritos. Os tipos de contratos estão descritos no Apêndice A.

Figura 16 – Quadro de Tipos de Contratos

Fonte: Elaborada pela autora desta dissertação (2021).

Cada tipo de contrato apresenta uma descrição textual, a forma de contratação de que faz parte, as referências dos estudos primários que foram citados, e suas características que foram identificadas nas leituras dos artigos e catalogadas nesta RSL.

Foram identificadas 20 características possíveis de tipos de contratos. Todas as características foram extraídas dos estudos primários lidos desta RSL. Contudo, nem todo tipo de contrato apresenta todas as características. As características foram organizadas conforme a Tabela 16, sendo utilizada na Descrição da característica uma forma de identificar se a característica está presente no tipo de contrato que está sendo descrito no quadro da Figura 16.

Tabela 16 – Características dos Tipos de Contratos

CARACTERÍSTICA		DESCRIÇÃO
TRIÂNGULO DE FERRO	Escopo/ Requerimentos	Contratação com escopo Fixo ou Negociável?
	Prazo	Contratação com prazo Fixo ou Negociável?
	Custo	Contratação com custo Fixo ou Negociável?
COMPARTI LHAMENTO	Compartilhamento de riscos	Contratação com compartilhamento de riscos (prazo, escopo, custo, responsabilidades, decisões) entre Cliente e Desenvolvedor, Sim ou Não?
	Risco Financeiro	De qual parte é o risco financeiro: Cliente, Desenvolvedor ou Ambos?

CARACTERÍSTICA		DESCRIÇÃO
MOTIVAÇÃO	Motivação pela melhor performance – Desenvolvedor	O Desenvolvedor possui motivação para desempenhar a sua melhor performance no projeto, Sim ou Não?
	Motivação pela qualidade da entrega – Desenvolvedor	O Desenvolvedor sente-se motivado para entregar o sistema com qualidade, Sim ou Não?
	Motivação pela qualidade da entrega – Cliente	O Cliente sente-se motivado para que o sistema seja entregue com qualidade, Sim ou Não?
PAGAMENTO EXTRA	Bônus por melhor desempenho	O Desenvolvedor receberá bônus por melhor desempenho alcançado, Sim ou Não?
	Penalidade por baixo desempenho	Desenvolvedor recebe penalidade por baixo desempenho alcançado, Sim ou Não?
	Cliente paga por escopo extra	Cliente paga por escopo extra, Sim ou Não?
	Cliente paga por prazo extra	Cliente paga por prazo extra, Sim ou Não?
	Cliente paga por Pacote de Flexibilidade de Trabalho (10-15%)	Cliente paga por Pacote de Flexibilidade de Trabalho, Sim ou Não? O Cliente e o Desenvolvedor podem acordar um Pacote de Flexibilidade de Trabalho para cobrir pequenas mudanças solicitadas durante o projeto (geralmente em torno de 10-15% do volume do contrato).
PROJETO	Compreensão segura e estável dos requisitos de software	Cliente possui compreensão segura e estável dos requerimentos a serem desenvolvidos, Sim ou Não?
	Fase de Checagem	A contratação prevê uma Fase de Checagem, Sim ou Não ? Uma Fase de Checagem (Checkpoint Phase) é um período de x iterações (sprints) ou um escopo de desempenho de y pontos de historias (storypoints), que atuam como uma fase de teste da cooperação entre Cliente e Desenvolvedor.
CONTROLE	Controle do Prazo	O controle do Prazo será realizado pelo Desenvolvedor ou Cliente?

CARACTERÍSTICA		DESCRIÇÃO
	Controle do Custo	O controle do Custo será realizado pelo Desenvolvedor ou Cliente?
PAGAMENTO	Comportamento de preço fixo – Preço baixo	O Cliente escolhe o Desenvolvedor com forte foco no preço baixo e competência satisfatória, Sim ou Não?
	Pagamento por Aceite de Entrega	Aceite da entrega determina o pagamento, ou seja, o Cliente só efetua o pagamento da entrega realizada pelo Desenvolvedor mediante o seu aceite, Sim ou Não?
	Pagamento por custos incorridos pelo Desenvolvedor	Custos realizados determina o pagamento, ou seja, o Cliente efetua pagamento ao Desenvolvedor à medida que este realiza custos no projeto, Sim ou Não?

Fonte: Elaborada pela autora desta dissertação (2021).

Inicialmente, as características que definem o triângulo de ferro, apresentado na seção 2.2, são as mais expressivas para diferenciar um tipo de contrato do outro, podendo assumir os valores fixo (FIXED) ou variável (VARIABLE). Como exemplo, caso o tipo de contrato tenha aplicação para projetos de escopo fixo, quando os requerimentos já são determinados pelo cliente e o fornecedor compromete-se a entregar exatamente estes requerimentos, a característica Escopo/ Requerimentos apresentará o valor FIXO.

Outra característica muito importante em contratação é o compartilhamento dos riscos do contrato sejam financeiros ou não. Os riscos podem ser de ordem de prazo, escopo, custo, responsabilidades ou decisões a serem tomadas ao longo do projeto. O risco financeiro fica bem definido a depender do tipo de contrato escolhido, como, por exemplo, o tipo de contrato Pagamento por Sprint que possui o Risco Financeiro do Cliente, enquanto que o tipo de contrato Preço fixo, tempo fixo, escopo negociável possui o Risco Financeiro do Desenvolvedor, ou com Risco Financeiro como Ambos temos como exemplo o tipo de contrato adVANTAGE. Não se tem uma prevalência do tipo de Risco Financeiro, pois dentre os 31 tipos de contrato, 39% são de risco do Cliente, 39% de risco do Desenvolvedor e 22% de Ambos.

A motivação para o melhor desempenho (performance), em tempo, escopo ou custo, ou melhor entrega de qualidade é um conjunto de características que devem ser observadas quanto aos objetivos a serem alcançados pelas partes contratantes.

Os tipos de contrato com custo fixo tendem a não motivar o desenvolvedor a melhor qualidade da entrega, mas o motiva a melhor performance de tempo, pois precisa entregar o mais rápido possível o que foi contratado. 78% dos tipos de contrato com a característica Xxxxx FIXO apresentam a característica Motivação pela qualidade da entrega – Desenvolvedor como NÃO, assim como 52% dos tipos de contratos com a característica Motivação pela melhor performance – Desenvolvedor são de custo fixo. As características de pagamentos extras são em algumas situações determinantes para se identificar o tipo de contrato a ser implantado num determinado contrato, deixando totalmente explicitadas as expectativas entre as partes. A Tabela

16 apresenta os tipos de pagamentos extra encontrados na RSL.

Duas características expressivas do projeto, que terá um tipo de contrato, são analisadas: Compreensão segura e estável dos requisitos de software e a existência de uma Fase de Checagem. Para projetos com clientes com domínio dos requisitos, 64% dos tipos de contrato são de custo fixo. A Fase de Checagem aparece nos estudos primários (RUSSO; TACCOGNA; XXXXXXXXXX; MESSINA; SUCCI, 2018) e

(ZIJDEMANS; STETTINA, 2014), sendo uma característica marcante no tipo de contrato adVANTAGE de forma de contratação HÍDRIDA.

São descritas as características da parte que controla os prazos e os custos do projeto. 22,5% dos tipos de contratos apresentam controle tanto de tempo como de custos de ambas as partes, cliente e desenvolvedor. 32% dos tipos de contrato possuem tanto a característica de controle de custos quanto de tempo pelo desenvolvedor, sendo contratos de custo fixo. Tipos de contratos com características de controle de tempo e custos pelo cliente não possuem contratos de custo fixo.

Por fim, as características de pagamento do fornecedor definem o momento e a forma de pagamento do cliente ao fornecedor. Assim, ao se escolher um tipo de contrato, todas as características definem diretamente o modo de contratação e as consequências deste tipo de contrato.

3.8.2.4 Tradução de dados

Esta técnica busca integrar temas e conceitos relatados em estudos (XXXXXXX, et al., 2009). Foi utilizada na tradução dos tipos de contrato. Foram encontrados 37 tipos de contratos nos 25 artigos da amostra da RSL. Contudo, ao realizar a síntese narrativa, foi possível identificar duplicidades de termos o que foi

necessário realizar uma padronização e eliminação de duplicidades, chegando aos 31 tipos de contratos finais. A Tabela 17 apresenta as similaridades encontradas:

Tabela 17 – Similaridades encontradas nos Tipos de Contratos

TIPO DE CONTRATO DESCRIÇÃO ENCONTRADA NO ARTIGO REFERENCIA

Uniformização ou padronização dos termos

Fixed-price, fixed-time, fixed-scope contracts	Fixed-price
Time and Material Contracts	T&M
Fixed-price, fixed-time, negotiable-scope contracts	Fixed-price with variable scope
Fixed-price,fixed-scope contracts	Fixed-scope
Fixed-price, fixed-time contracts	Fixed-time

Eliminação de duplicidades e similaridades

Collaborative Agile Contracts	Agile Collaboration Agreement
Time and material (T & M) price with Fixed scope and Cost ceiling	T&M contracts with a price cap	(FINK; LICHTENSTEIN; WYSS, 2013).
Time and Material Contracts	Paying for effort as it gets spent	(RUSSO; TACCOGNA; XXXXXXXXXX; MESSINA; SUCCI, 2018).
Payment per Sprint	Sprint Contract	(XXX-XXXXX; XXXXXXX; MILSTEIN, 2012).
Incremental delivery with payment on incremental	Phased Development	(XXX-XXXXX; XXXXXXX; XXXXXXXX, 2012).
Não é um tipo de contrato, mas uma forma de avaliação de fornecedor em um bid ou licitação. É uma sugestão para que fornecedores ofereçam propostas com mais de uma forma ou tipo de contrato.	Multi-Alternative Proposal	(XXX-XXXXX; XXXXXXX; MILSTEIN, 2012).

Fonte: Elaborada pela autora desta dissertação (2021).

3.8.3 Elemento 3: explorando relações dentro e entre estudos

Segundo Xxxxxxx (2009), as relações de interesse são de dois tipos amplos:

(1) aquelas entre as características dos estudos individuais e suas descobertas relatadas e (2) aquelas entre as descobertas de diferentes estudos.

Nesta RSL foram utilizadas três técnicas de exploração de relações de interesse que são apresentadas nas seções a seguir. Destas técnicas surgiram as maiores contribuições desta pesquisa que serão aplicadas nos capítulos 4 e 5.

3.8.3.1 Descrições qualitativas de casos

Esta técnica é utilizada para descrever os estudos de casos identificados nos estudos primários lidos e extraídos na RSL. Conforme Xxxxxxx (2009), esta técnica permite que o revisor extraia em detalhes quaisquer aspectos de estudos individuais que podem não ter parecido relevantes no início da síntese. Não foi utilizado resumo ou um formulário como exemplificado em Xxxxxxx (2009), mas os detalhes dos estudos primários foram informados na planilha de extração Quadro de Artigos, adaptados nos campos (verdes), principalmente em Comments, Perfil do Cliente, Perfil do Contratado e Projeto/Case Study.

3.8.3.2 Construindo modelos conceituais/teia de ideias/mapeando conceitos

Em Xxxxxxx (2009), o objetivo desta técnica é tornar explicativa a lógica por trás das análises e/ou investigações realizadas. Construir uma figura ou estrutura que resulte numa forma de ligar os processos descritos anteriormente e as questões / ideias resultantes juntos a fim de estruturar a síntese.

Dos estudos primários extraídos nesta RSL, foi possível identificar elementos de projetos apresentados em estudos de casos que relacionados ao contexto de contratação puderam dar forma ao conceito de FATOR DETERMINANTE para uma determinada forma de contratação, conforme descritos na Tabela 15Tabela 15.

Um fator determinante apenas não determina sozinho uma forma de contratação, mas ajuda a indicar qual a melhor forma de contratação que se deve utilizar.

Foram identificados elementos em determinados estudos primários lidos, que em alguns casos se repetiram em outros estudos (como exemplos gerenciamento de benefício, confiança, etc.). A Tabela 18 apresenta os fatores determinantes identificados, assim como sua descrição, sigla (short name) e graduação (podendo assumir os valores ALTO, MÉDIO ou BAIXO) de determinação para a forma de contratação. O Apêndice B apresenta as referências dos estudos que foram base para a formação dos fatores determinantes.

Além dos fatores identificados explicitamente nos estudos lidos, foram acrescidos mais quatro fatores (PROJECT COMPLEXITY, PROJECT BY DELIVERABLES, DIFFERENT CLIENTS, BY DEMAND) que foram identificados implicitamente nos estudos, mas que possuem grande importância nos

relacionamentos com as formas de contratação, desde sua conceituação, como por exemplo, o fator PROJECT BY DELIVERABLES que significa Projeto com entregas bem determinadas ao longo do projeto, ou seja, um projeto com este elemento tem uma alta tendência de determinar uma forma de contratação hibrida.

O capítulo 4 vai apresentar o processo desenvolvido para melhor identificar qual o tipo de contrato que um projeto deve utilizar. A primeira fase de identificação fará uso da identificação de todos os fatores determinantes do projeto em questão. Assim, a formação deste conceito foi o primeiro passo importante desta pesquisa.

Tabela 18 – Fatores determinantes por Forma de Contratação

FATOR DETERMINANTE		FORMA DE CONTRATAÇÃO
		Bônus	Teto de Custo	Híbrida	Unidade de Trabalho
FALTA DE CONFIANÇA	Cliente desconfia que o fornecedor não possui experiência e idoneidade.	BAIXO	ALTO	BAIXO	BAIXO
PERFIL TECNICO DO CLIENTE	Conhecimento técnico da equipe cliente.	MÉDIO	BAIXO	MÉDIO	ALTO
ENVOLVI MENTO DO CLIENTE	Dedicação da equipe cliente ao projeto.*1	MÉDIO	BAIXO	MÉDIO	ALTO

*1 A equipe cliente estará participando ativamente do projeto.

	Credibilidade
	do cliente
	permite o uso
CREDIBILI DADE	de contratos
DO CLIENTE	confiáveis de
	custo fixo com
	sucesso.*2
		MEDIO	ALTO	MÉDIO	MÉDIO

*2 O uso do termo confiabilidade é técnico, não apenas no sentido moral. Um parceiro de mercado é confiável, se ele age de forma compreensível, se ele toma decisões racionais devido aos seus interesses transparentes e promessas anteriores.

HISTORICO DO	Histórico de
FORNECE DOR	prestação de serviço do
	fornecedor. *3	BAIXO	BAIXO	MÉDIO	ALTO

FATOR DETERMINANTE	FORMA DE CONTRATAÇÃO
	Bônus	Teto de Custo	Híbrida	Unidade de Trabalho

*3 Cliente conhece o fornecedor quanto sua experiência técnica e cumprimento de pactos.

	Baixo risco
	financeiro
	potêncial do
	fornecedor.
	Cliente
	conhece o
BAIXO RISCO	histórico
FINANCEI RO DO	financeiro do
FORNECE DOR	fornecedor e
	julga o risco
	mediante o
	histórico de
	relacionamento
	e confiança. *4
		BAIXO	MÉDIO	MÉDIO	ALTO

*4 Se a incerteza de custo do projeto for muito baixa, se houver uma forte relação de confiança entre o cliente e o desenvolvedor que garanta flexibilidade e alta qualidade do trabalho independente do tipo de contrato, ou se o desenvolvedor souber disso serão compensados por perdas em um estágio posterior (como na fase de manutenção) o risco de problema do projeto devido a tais contratos pode ser aceitavelmente baixo.

	Existe
	expressa
	necessidade de
	comunicação
COMUNICAÇÃO	entre as partes,
INTENSA	havendo um
	ritmo intenso
	de
	comunicações.
	*5	ALTO	BAIXO	ALTO	ALTO

*5 As partes precisam ouvir cada uma e alinhar as expectativas.

INCERTEZA DOS REQUERI MENTOS	Incerteza nas especificações de
	requerimentos.
	*6	BAIXO	BAIXO	MÉDIO	ALTO

*6 No momento da assinatura do contrato, as especificações dos requisitos estão incompletas, voláteis ou requisitos pouco claros.

	Cliente e
	fornecedor
	desejam
COMPORTAMENTO	colaborar para
COLABORATIVO	fechar as
	lacunas de
	requisitos em
	aberto.*7	MÉDIO	BAIXO	MÉDIO	ALTO

*7 Ambos colaborando para definições de especificações dos requisitos completas.

FATOR DETERMINANTE		FORMA DE CONTRATAÇÃO
		Bônus	Teto de Custo	Híbrida	Unidade de Trabalho
RANKING DE FORNECE DORES	Comparação e pontuação de fornecedores envolvidos em um processo de contratação.*8	BAIXO	ALTO	MÉDIO	ALTO

*8 A comparação visa a escolha do melhor fornecedor conforme os critérios (prazo, custo, qualidade, etc.) estabelecidos.

FOCO NO BENEFICIO DO CLIENTE Identificação e monitoramento dos benefícios do projeto.*9
ALTO
BAIXO
MÉDIO
MÉDIO

*9 Ter os benefícios do projeto bem definidos na contratação e bem monitorados ao longo do projeto muito mais do que seguir a risca os requisitos descritos (Benefit management).

RISCO REDUZIDO
Utiliza a prática "Desenvolvedor agrada o cliente". *10
BAIXO
ALTO
MÉDIO
MÉDIO

*10 Trata o cliente como um parceiro de negócios e gera confiança, então o cliente ver que o desenvolvedor tem o mesmo interesse no projeto. O desenvolvedor escuta o cliente mesmo que não concorde e faça exatamente o que o cliente deseja, mas faz o possível para entender.

PRAZO DE RISCO Utiliza a prática de prazo de risco. *11
BAIXO
ALTO
MÉDIO
MÉDIO

*11 Prática utilizada como segurança de cumprimento de prazo em contratos de tempo fixo (ou seja, acrescenta umas semanas no prazo caso tenha problemas para cumprir o prazo).

	Projeto com
	alta
COMPLEXI DADE	complexidade
DE PROJETO	de entrega,
	tempo ou
	equipe.	MÉDIO	BAIXO	ALTO	MÉDIO
	Projeto com
PROJETO POR ENTREGÁ VEIS	entregas bem determinadas ao longo do
	projeto.	MÉDIO	BAIXO	ALTO	MÉDIO
	Projeto com
	entregas a
CLIENTES	diferentes
DIVERSOS	clientes ao
	longo do
	projeto.*12	MÉDIO	BAIXO	ALTO	MÉDIO

*12 Exemplos: patrocinadores, clientes, centros de custos, dentre outros.

FATOR DETERMINANTE		FORMA DE CONTRATAÇÃO
		Bônus	Teto de Custo	Híbrida	Unidade de Trabalho
	Projeto com
PROJETO POR DEMANDA	entrega para uma demanda específica de
	data *13	ALTO	BAIXO	MÉDIO	MÉDIO

*13 Exemplos: data de inauguração, data de abertura, xxxxx xxxxxxxxxxxxx (atingimento de meta), dentre outros.

Fonte: Elaborada pela autora desta dissertação (2021).

3.8.3.3 Representação visual dos relacionamentos entre as características e resultados dos estudos

Neste ponto da síntese, o objetivo é elaborar visões que ajudem ao entendimento dos relacionamentos dos conceitos e resultados obtidos. Foram construídas figuras que agrupam os conceitos dos fatores determinantes, formas de contratação e os tipos de contratos de cada forma de contratação, conforme apresentado na Figura 17.

Figura 17 – Formas de Contratação e Fatores determinantes

Fonte: Elaborada pela autora desta dissertação (2021).

As figuras a seguir apresentam cada forma de contratação com seus respectivos tipos de contrato.

Figura 18 – Formas de Contratação HÍBRIDA e seus Fatores determinantes

Fonte: Elaborada pela autora desta dissertação (2021).

Figura 19 – Formas de Contratação TETO DE CUSTO e seus Fatores determinantes

Fonte: Elaborada pela autora desta dissertação (2021).

Figura 20 – Formas de Contratação UNIDADE DE TRABALHO e seus Fatores determinantes

Fonte: Elaborada pela autora desta dissertação (2021).

Figura 21 – Formas de Contratação BÔNUS/PENALIDADE e seus Fatores determinantes

Fonte: Elaborada pela autora desta dissertação (2021).

3.8.4 Elemento 4: avaliando a robustez da síntese

Ainda segundo Xxxxxxx (2009), no final do processo de síntese, a análise do relacionamento dentro e entre os estudos descritos devem levar a uma avaliação geral da força das evidências disponíveis para tirar conclusões sobre a base de uma síntese narrativa. Conforme o tipo desta RSL, foi utilizada uma das técnicas disponibilizadas para esta etapa da síntese, que foi descrita a seguir.

3.8.4.1 Refletindo criticamente sobre o processo de síntese

Esta técnica é uma análise pelo próprio autor da Síntese Narrativa sobre o processo utilizado, realizando a análise de forma generalizada e ampla.

Existe uma outra técnica de classificação de robustez da Síntese Narrativa que poderia ter sido aplicada. A técnica de Força da evidência (Strength of evidence) realiza uma análise individual e detalhada de cada estudo primário participante da RSL (POPAY, et al., 2006). São utilizados 4 critérios distintos: confiabilidade (trustworthiness), adequação (appropriateness), relevância (relevance) e peso total de evidencia (overall weight of evidence).

Mesmo que esta pesquisa não tenha aplicado a técnica de Força da evidência propriamente dita, considera-se que os estudos primários da RSL são confiáveis, adequados e de fontes relevantes, seguindo os critérios de avaliação de robustez. Isto devido ao fato destes estudos terem vindos de fontes confiáveis como ACM, IEEE, Springer e Science Direct, que possuem processos internos de garantia de qualidade e coerência dos estudos que disponibilizam, com os quais os conteúdos foram passados por peer review e seguem um processo rigoroso de revisão.

Além disto, a Síntese Narrativa também foi aplicada seguindo um processo rigoroso bem estabelecido, como o máximo de adequação ao que foi orientado por Xxxxxxx (2009). Por poder existir um certo grau de subjetividade na síntese, esta análise procurou ser bastante rigorosa para tratar esta subjetividade. Contudo, o resultado alcançado foi muito bom e muito rico, resultando na base conceitual desta pesquisa para concretização do Processo de Seleção de Tipo de Contrato – PSTC a ser apresentado no capítulo 5.

3.8.5 Conclusões Finais

A Síntese Narrativa teve uma enorme contribuição para esta pesquisa. Foram muitos os resultados, principalmente para validar a qualidade dos estudos obtidos na RSL, gerando conteúdo de base para estruturação e elaboração do Processo de Seleção de Tipo de Contrato – PSTC a ser apresentado no capítulo 5.

Seguem os resultados da Síntese Narrativa:

• Fatores determinantes

• Formas de contratação

• Relação entre Fatores determinantes e Forma de contratação

• Características de tipos de contratos

• Tipos de contratos

• Catálogo de tipos de contratos

3.9 CONCLUSÃO DA RSL

A RSL que iniciou com um desafio na obtenção de estudos primários atuais e em vasta quantidade, resultou num conteúdo consistente e de irrefutável contribuição, acima do esperado.

Seguem as análises e considerações referentes aos estudos desta pesquisa:

1. Dentre os estudos que apresentam boas práticas de contratação, ou seja, QC7: Apresenta boa prática de contratação?: Sim, sendo 22 estudos (88% dos estudos), Teto de Custo é a forma de contratação mais citada com 54% e Híbrida é a forma de contratação menos citada com 10%.

Figura 22 – Gráfico de estudos de Boas práticas de Contratação

Boas práticas de Contratação

13%

23%

Bônus/Penalidade

Teto de Custo

10%

Híbrida

Unidade de Trabalho

54%

Fonte: Elaborada pela autora desta dissertação (2021).

2. Teto de custo (52%) é a forma de contratação mais citada entre estudos (15, sendo 60% dos estudos) que apresentam modelo de contratação (QC6: Apresenta Modelo de contratação? : Sim) e Híbrida e Bônus/Penalidade (ambos 13%) são as formas de contratação menos citadas entre estudos (15, sendo 60% dos estudos)

que apresentam modelo de contratação (QC6: Apresenta Modelo de contratação?

: Sim).

Figura 23 – Gráfico de estudos de Modelo de Contratação

Modelo de Contratação

22%

13%

Bônus/Penalidade

Teto de Custo

13%

Híbrida

Unidade de Trabalho

52%

Fonte: Elaborada pela autora desta dissertação (2021).

3. A confiança (trust) entre clientes e fornecedores é um ponto forte de atenção que pode definir o tipo de contrato. 11 estudos (44% do total dos 25 estudos da RSL) apontam a confiança como fator de sucesso de projetos e redução de conflitos em contratos. O nível de confiança é tratado por Xxx, Xxxxx e Xxxxxx (2013), que indicam que a confiança construída ao longo do tempo entre o cliente e o desenvolvedor possibilita os clientes a aceitarem um acordo sem termos fechados. Xxxxxxxxx, Xxxxxxxxxx e Grimstad (2017) citam que experiência anterior (experience from previous projects) com o fornecedor facilita uma contratação do tipo Mão-de-obra&Material (Time&Material) devido a confiança existente. A importância da experiência anterior com sucesso com um fornecedor impacta na continuidade de uma próxima contratação. Xxxxxxxx, Xxxxxxxxxx e Xxxxxxxxxx (2011) chegam, inclusive, a citar o trust quotient como uma forma de quantificar o nível de confiança entre as partes. Destes estudos, 3 se referem a clientes públicos (PÚBLICO), 4 se referem a ambos os tipos de clientes (AMBOS) e os outros não se referem a tipo de cliente.

Figura 24 – Gráfico de estudos sobre Confiança entre as partes

Confiança / Trust

19%

16%

12%

Bônus/Penalidade

Teto de Custo Híbrida

Unidade de Trabalho

53%

Fonte: Elaborada pela autora desta dissertação (2021).

4. Os tipos de cliente (PÚBLICO ou PRIVADO) aparecem na mesma intensidade. Dos 14 estudos que não citam a confiança, a maioria é de clientes públicos, com 5 estudos. Xxxxxxxxx (2016) se refere ao tipo de cliente AMBOS com 42% dos clientes do setor privado e 58% do setor público. Apenas um estudo é do setor privado, sendo que este fala sobre modelos híbridos de contratos.

5. Dentre os 11 estudos, os mesmos do item 3 acima, Teto de custo foi o mais citado (53%), conforme o gráfico da Figura 24. Contudo, esta forma de contratação é aplicada para contratações sem forte confiança entre as partes, como visto em Lindsjørn e Xxxxxxxx (2018), quando cita que contratos de custo fixo são preferidos como forma de redução de riscos e proteção contra fornecedores incompetentes caso eles não cumpram com escopo, prazo ou custo acordados, prevendo não haver perdas financeiras. Ainda em Lindsjørn e Moustafa (2018), os clientes geralmente escolhem contratos de custo fixo por desejarem saber o quanto o sistema custará, assim como qualquer outro produto que se adquire. Acreditam que assim terão o real controle dos custos. A falta de confiança no fornecedor pode se formar em várias formas: credibilidade do fornecedor (não fala a verdade/mente quanto a estimativas e trabalho feito) ou capacidade do fornecedor (provider expertise), ou seja, o cliente não acredita que o fornecedor tem experiência para cumprir o escopo com qualidade e prazo. Em Lindsjørn e Xxxxxxxx (2018), a falta de confiança na capacidade de entrega do desenvolvedor, ou seja, na sua

experiência profissional na área, é vista como uma das causas mais obvias que indica que o cliente não confia no fornecedor.

6. A comunicação intensa entre cliente e fornecedor é outro ponto explorado em 8 estudos (32% do total dos 25 estudos da RSL), apresentando que quanto maior a intensidade da comunicação durante o projeto, maior o sucesso do projeto e, principalmente, menores os transtornos de ajustes contratuais e financeiros do projeto. A intenção ou disponibilidade do cliente para manter a comunicação durante o projeto pode sugerir a definição do modelo de contratação, ou seja, se o cliente estará constantemente em comunicação com a equipe do projeto, este é um fator determinante para 3 das 4 formas de contratação.

7. O conhecimento técnico do cliente (IT knowlegde/Client competence) aparece em 12 estudos (48% do total dos 25 estudos da RSL), argumentando que se o cliente possuir um nível de conhecimento técnico em TI, maior será o sucesso do projeto e principalmente menores os transtornos de ajustes contratuais e financeiros do projeto, visto que o cliente entende a intensidade ou o impacto da mudança. O nível de conhecimento técnico do cliente para o projeto foi sugestivo para modelos de contratação, ou seja, se o cliente disponibilizar técnicos para o projeto, então pode-se determinar fortemente o Unidade de Trabalho como forma de contratação.

8. O envolvimento (client involvement) do cliente é outro ponto explorado em 11 estudos (44% do total dos 25 estudos da RSL), apresentando que quanto maior o envolvimento do cliente durante o projeto, maior o sucesso do projeto e principalmente menores os transtornos de ajustes contratuais e financeiros do projeto. Sugerindo que a intenção ou disponibilidade do cliente para o projeto possa definir o modelo de contratação, ou seja, se o cliente estará disponível ou se compromete a estar envolvido, então pode-se determinar fortemente a Unidade de Trabalho como forma de contratação.

9. Altamente citado dentre os estudos que tratam o assunto em específico, com 20 estudos (80% do total dos 25 estudos da RSL), a incerteza de requisitos (Cita nível de incerteza para definição do modelo=Y) é talvez a mais importante causa de mudanças que trazem impactos nos patamares contratados. Um dos princípios ágeis é a aceitação da mudança como uma forma de aprimoramento do sistema entregue (“welcome changing requirements”). Mesmo a mudança sendo tratada como um princípio ágil, as incertezas de requisitos determinam fortemente a forma de contratação que irá se adequar ao ritmo destas mudanças.

10. Dentre estes 20 estudos que entendem o impacto da incerteza dos requisitos, 3 deles, ou seja 15% do total dos 25 estudos da RSL, definem o défcit de abismo dos requisitos ou deficit requirement gaps, ou seja, no momento da contratação os requisitos não estão ainda completos ou totalmente conhecidos ou detalhados, ou ainda não estão concretos ou maduros.

11. Apenas 4 estudos (16% do total dos 25 estudos da RSL) citam modelos de contratação em licitação, sendo dois estudos em organização pública e um dos estudos não direciona público ou privado, pois apresenta uma pesquisa interessante sobre métricas para escolha de fornecedores, indicando o modelo AUCB para ranking de fornecedores.

12. O autor Xxxxx Xxxxxxxx traz, em três dos seus estudos (12% do total dos 25 estudos da RSL), um pilar de análise do gerenciamento de benefício dos clientes no projeto como boa prática nas contratações. Ele defende que o planejamento e monitoramento da gestão de benefícios no projeto são fatores de sucesso para a entrega de valor ao cliente.

13. Apenas um estudo utiliza o conceito de Prazo de Risco como boa prática no momento de contratação, conforme descrito na Tabela 18. Pode ser utilizado como uma medida para determinação do modelo de contratação.

14. Apenas um estudo utiliza o conceito de Risco Reduzido como boa prática em contratação, conforme descrito na Tabela 18. Atenção a este tipo de prática, pois o próprio estudo finaliza citando que é preciso encontrar um modelo de contratação que traga confiança entre as partes em contratos ágeis e mudanças durante o projeto.

15. Apenas um estudo apresenta como boa prática, além de entregas regulares em tempos curtos, utilizar também contratação em tempos curtos (short development and delivery timelines) para ambientes de regras rígidas como os de órgãos de segurança do governo (Cita ou Utiliza curtos prazos de contratação nas regras de contratação=U). Como solução, indica contratar os projetos como Serviço e não como produto (Cita ou Utiliza contratação de desenvolvimento de sistemas como Serviço e não como Produto=U) para driblar as leis e regras de entregas, quando as entregas (produtos) devem estar totalmente definidas em momento de contratação.

16. Um estudo traz uma análise interessante na identificação do comportamento das partes contratantes, utilizando os conceitos da Teoria dos Jogos (Game theory),

aplicando quatro cenários entre os atores do projeto (Prisioner's dylema). Esta análise foi utilizada como um dos fatores determinantes para um modelo de contratação, descrito como Comportamento colaborativo, conforme a Tabela 18.

4 APLICAÇAO DO AHP PARA DECISÃO DO TIPO DE CONTRATO

Neste capítulo será demonstrada a contribuição do AHP para decisão da forma de contratação e, depois, no capítulo 5 será apresentado o Processo de Seleção de Tipo de Contrato – PSTC – com a utilização das características dos tipos de contratos identificados na RSL para, finalmente, determinar o tipo de contrato mais adaptável ao projeto em questão.

No capítulo 3, foram apresentados os produtos gerados pela Síntese Narrativa da RSL: Fatores determinantes, Forma de contratação, Características de tipos de contratos e Tipos de contratos. A Figura 25 apresenta as etapas de construção desta pesquisa, a partir destes conceitos. Este capítulo e o próximo capítulo detalham as duas etapas.

Figura 25 – Etapas de construção da pesquisa

Fonte: Elaborada pela autora desta dissertação (2021).

4.1 APLICANDO O AHP

Decisão é a atividade de maior impacto nesta pesquisa, pois é abordado um processo decisório para contribuir na melhor utilização de um modelo de contratação para um determinado projeto ágil de desenvolvimento de sistemas desde a sua concepção. Os conceitos de decisão foram apresentados no capítulo 2, na seção 2.5.1.

No momento de concepção de um projeto, lança-se mão de premissas e propriedades de um projeto que descrevem o cenário que este projeto deverá atuar ou ser desenvolvido. Este capítulo apresenta o processo que norteia, neste momento de contratação e a partir destas premissas e propriedades, a definição da melhor forma de contratação do projeto.

Dos estudos primários da RSL foram extraídos fatores que podem orientar a determinação do modelo de contratação mais adequado ao cenário do projeto em questão, conforme apresentados no capítulo anterior. Contudo, estes fatores devem ser priorizados e devidamente pontuados para que embasem a definição da forma de contratação e, mais detalhadamente, sugira o tipo de contrato a ser utilizado. Como estes fatores não são numéricos e sua comparação não é direta, esta pesquisa sugere a aplicação da técnica de Analytic Hierarchy Process (AHP), ou Processo de Hierarquia Analítica, na priorização da forma de contratação a ser utilizada no projeto.

Esta pesquisa utiliza o AHP como processo de apoio à decisão da melhor forma de contratação a ser utilizada em uma contratação que se iniciará em um projeto ágil de desenvolvimento de sistema. O AHP é aplicado uma única vez nesta pesquisa, pois a base da decisão são os fatores determinantes obtidos na RSL. Na seção 7.4, são apresentadas possibilidades de novas aplicações do AHP para revisar as ponderações de determinação da Forma de contratação ou para aperfeiçoamento e evolução do PSTC.

As próximas três seções seguirão o método sugerido por Saaty para alcance deste objetivo, seguindo as três etapas citadas na seção 0. Os conceitos de decisão e do AHP que embasaram esta pesquisa foram apresentados no capítulo 2, no seção 2.5.

4.1.1 Hierarquia dos critérios

Os critérios utilizados foram os Fatores determinantes identificados na RSL e apresentados na Tabela 18. Um Fator determinante não determina sozinho uma Forma de contratação, conforme a Tabela 15, mas uma composição de fatores será determinante. A Figura 17 apresenta a hierarquia de critérios a ser utilizada no AHP, onde cada Forma de contratação possui determinados Fatores determinantes que foram identificados nos estudos primários da RSL.

A hierarquia dos critérios foi composta em dois níveis: no primeiro nível foi utilizada a Forma de contratação e no segundo nível foi utilizado o Fator determinante. Conforme apresentado na Tabela 18, o Fator determinante com impacto mais alto (graduação ALTO) para determinação da Forma de contratação foi classificado como critério da hierarquia da Forma de contratação em questão. Como exemplo, o Fator determinante FALTA DE CONFIANÇA, ou Cliente desconfia que o fornecedor não possui experiência e idoneidade, que pode determinar contratações de BÔNUS/PENALIDADE, TETO DE CUSTO, HIBRIDA ou UNIDADE DE TRABALHO,

contudo, quando este fator se apresenta fortemente em um cenário de contratação, dificilmente um contrato de bonificação, hibrida ou por unidade de trabalho, que necessita fortemente de confiança entre as partes terá sucesso em sua contratação e em sua execução. Assim, apenas ter este fator não determina unicamente que deve- se buscar um tipo de contrato TETO DE CUSTO, deve-se analisar os demais fatores. A próxima etapa do processo AHP explica como dar a ponderação devida aos fatores para identificar de forma combinada qual a melhor forma de contratação a ser aplicada no cenário de projeto em estudo.

A Figura 26 apresenta a hierarquia de critérios com os dois níveis conforme descrito acima.

Figura 26 – Hierarquia de Critérios – Fatores determinantes

Fonte: Elaborada pela autora desta dissertação (2021).

4.1.2 Matriz Comparativa

Após a definição da hierarquia dos critérios, a próxima etapa é a definição da Matriz de intensidade de importância dos Fatores determinantes (critérios). Nesta etapa é realizado o passo mais particular do AHP, quando são comparados os critérios um a um em pares. Segundo Xxxxxx (2010), esta etapa visa determinar a importância relativa entre os critérios e seu peso relativo no tema que está sendo analisado.

A Tabela 19 foi elaborada conforme orientação de Xxxxx (1988), quando explica que as comparações em pares são o diferencial do AHP e a sua característica fundamental. A prioridade para os principais critérios deve ser inicialmente estabelecida para, assim, julgá-los em pares por sua importância relativa, gerando uma matriz de comparação de pares. Julgamentos usados para fazer as comparações são representados por números retirados da escala fundamental.

Tabela 19 – Escala absoluta de Intensidade de Importância de Saaty

Escala	Avaliação Numérica	Recíproco
Extremamente mais determinante	9	1/9
Muito mais a extremo	8	1/8
Muito mais determinante	7	1/7
Mais a muito mais	6	1/6
Mais determinante	5	1/5
Ligeiramente a mais	4	1/4
Ligeiramente mais determinante	3	1/3
Igual a ligeiramente	2	1/2
Igualmente determinante	1	1

Fonte: Adaptado de Saaty (1988).

Na aplicação do AHP, a Escala absoluta de Intensidade de Importância é adaptada conforme o critério adotado. A Tabela 19 foi uma adaptação, pois a graduação do julgamento será pela determinância ou intensidade do Fator determinante (critério).

A matriz será elaborada conforme os dois níveis compostos da hierarquia dos critérios: Forma de contratação e Fator determinante. Inicialmente, foi elaborada a matriz pelas formas de contratação, ou seja, pelo primeiro nível:

Figura 27 – Hierarquia de Critérios – Primeiro nível

Fonte: Elaborada pela autora desta dissertação (2021).

Foi elaborada a Tabela 20 para o primeiro nível da hierarquia de critérios, conforme a Figura 27:

Tabela 20 – Matriz de intensidade de importância – Nível 1 – Forma de contratação

TETO DE CUSTO		BÔNUS/ PENALIDADE	HIBRIDA	UNIDADE DE TRABALHO
TETO DE CUSTO	1	3	5	7
BÔNUS/ PENALIDADE	1/3	1	3	5
HIBRIDA	1/5	1/3	1	3
UNIDADE DE TRABALHO	1/7	1/5	1/3	1

Fonte: Elaborada pela autora desta dissertação (2021).

A leitura da matriz se dá da seguinte forma: os critérios são distribuídos da maior determinância para a menor determinância, da esquerda para a direita da tabela de forma horizontal, assim como de cima para baixo da tabela de forma vertical. Como exemplo, TETO DE CUSTO é Ligeiramente mais determinante (3) do que BÔNUS/PENALIDADE; que é Mais determinante (5) do que HIBRIDA; que é Muito mais determinante (7) do que UNIDADE DE TRABALHO. Assim, TETO DE CUSTO é o mais determinante entre eles. É como se fosse uma expressão de comparação: TETO DE CUSTO > BÔNUS/ PENALIDADE > HIBRIDA > UNIDADE DE TRABALHO, logo TETO DE CUSTO > UNIDADE DE TRABALHO.

A comparação de um critério com ele mesmo sempre resulta no valor 1, correspondendo a Igualmente determinante na Tabela 19 – Escala absoluta de Intensidade de Saaty.

A matriz é preenchida no seu triângulo inferior à diagonal da matriz com os valores recíprocos informados no triângulo superior à diagonal da matriz. Ou seja, como exemplo, a comparação entre TETO DE CUSTO é Ligeiramente mais determinante (3) do que BÔNUS/ PENALIDADE, remete ao valor recíproco para Ligeiramente mais determinante (3) de 1/3 entre BÔNUS/PENALIDADE e TETO DE CUSTO, ainda conforme a Tabela 19 – Escala absoluta de Intensidade de Saaty.

A determinância foi atribuída pela autora conforme as informações extraídas da análise sistemática realizada na RSL, sendo a contribuição deste trabalho.

Segundo Xxxxxx e Xxxxxx (2012), os pesos relativos a cada critério são obtidos normalizando-se a matriz comparativa. A normalização é feita pela divisão entre cada valor da planilha com o total de cada coluna. A Tabela 21 apresenta a

matriz comparativa preparada com os referidos totais para a realização da normalização.

Tabela 21 – Matriz de intensidade de importância com total – Nível 1 – Forma de contratação

TETO DE CUSTO		BÔNUS/ PENALIDADE	HIBRIDA	UNIDADE DE TRABALHO
TETO DE CUSTO	1	3	5	7
BÔNUS/ PENALIDADE	1/3	1	3	5
HIBRIDA	1/5	1/3	1	3
UNIDADE DE TRABALHO	1/7	1/5	1/3	1
TOTAL	1,676	4,533	9,333	16,000

Fonte: Elaborada pela autora desta dissertação (2021).

A Tabela 22 apresenta os dados de peso relativo entre os critérios:

Tabela 22 – Matriz de intensidade de importância normalizada – Nível 1 – Forma de contratação

TETO DE CUSTO		BÔNUS/ PENALIDADE	HIBRIDA	UNIDADE DE TRABALHO
TETO DE CUSTO	1/1,676= 0,59659	0,66176	0,53571	0,4375
BÔNUS/ PENALIDADE	(1/3)/1,676=0,19886	0,22059	0,32143	0,3125
HIBRIDA	(1/5)/1,676=0,11932	0,07353	0,10714	0,1875
UNIDADE DE TRABALHO	(1/7)/1,676=0,08523	0,04412	0,03571	0,0625

Fonte: Elaborada pela autora desta dissertação (2021).

Ainda segundo Xxxxxx e Xxxxxx (2012), a determinação da contribuição de cada critério na meta global é calculada a partir do vetor de prioridade ou vetor de Eigen. O vetor de Eigen é utilizado por Saaty para apresentar os pesos relativos entre os critérios. Na maioria dos casos (XXXXXX, 2010), utiliza-se o cálculo aproximado do vetor de Eigen, que é obtido através da média aritmética dos valores de cada um dos critérios. Observa-se que o somatório dos valores do vetor sempre totaliza 1 (um). A Tabela 23 apresenta o cálculo do vetor de Eigen e, além disto, apresenta em forma de percentual do peso relativo de cada critério na meta global.

Tabela 23 – Cálculo do vetor de Eigen – Nível 1 – Forma de contratação

TETO DE CUSTO		BÔNUS/ PENALIDADE	HIBRIDA	UNIDADE DE TRABALHO	Vetor de Eigen	%
TETO DE CUSTO	0,59659	0,66176	0,53571	0,4375	0,557892	56%
BÔNUS/ PENALIDADE	0,19886	0,22059	0,32143	0,3125	0,263345	26%
HIBRIDA	0,11932	0,07353	0,10714	0,1875	0,121873	12%
UNIDADE DE TRABALHO	0,08523	0,04412	0,03571	0,0625	0,05689	6%
					1	100%

Fonte: Elaborada pela autora desta dissertação (2021).

Contudo, apenas com estes critérios, não se define a forma de contratação do projeto. Para isto, esta pesquisa utilizou a aplicação do AHP com um segundo nível de determinação. Para o segundo nível da hierarquia de critérios foi construída uma matriz para cada conjunto de fatores de cada forma de contratação, de acordo com a hierarquia definida na Figura 26, apresentadas nas tabelas Tabela 24, Tabela 25, Tabela 26 e Tabela 23 a seguir.

Tabela 24 – Matriz de intensidade de importância – Nível 2 – TETO DE CUSTO

FALTA DE CONFIANÇA		CREDIBILIDAD E DO CLIENTE	RANKING DE FORNECEDO RES	RISCO REDUZIDO	PRAZO DE RISCO
FALTA DE CONFIANÇA	1	1	3	5	7
CREDIBILIDAD E DO CLIENTE	1	1	3	5	5
RANKING DE FORNECEDO RES	1/3	1/3	1	3	5
RISCO REDUZIDO	1/5	1/5	1/3	1	3
PRAZO DE RISCO	1/7	1/5	1/5	1/3	1

Fonte: Elaborada pela autora desta dissertação (2021).

Tabela 25 – Matriz de intensidade de importância – Nível 2 – BÔNUS/PENALIDADE‌

	FOCO NO BENEFICIO DO CLIENTE	BAIXO RISCO FINANCEIRO DO FORNECEDOR	COMUNICAÇÃO INTENSA	PROJETO POR DEMANDA
FOCO NO BENEFICIO DO CLIENTE	1	3	5	7
BAIXO RISCO FINANCEIRO DO FORNECEDOR	1/3	1	3	5
COMUNICAÇÃO INTENSA	1/5	1/3	1	3
PROJETO POR DEMANDA	1/7	1/5	1/3	1

Fonte: Elaborada pela autora desta dissertação (2021).

Tabela 26 – Matriz de intensidade de importância – Nível 2 – HIBRIDA

	PROJETO POR ENTREGÁVEIS	COMPLEXIDADE DE PROJETO	COMUNICAÇÃO INTENSA	CLIENTES DIVERSOS
PROJETO POR ENTREGÁVEIS	1	3	5	7
COMPLEXIDADE DE PROJETO	1/3	1	3	5
COMUNICAÇÃO INTENSA	1/5	1/3	1	3
CLIENTES DIVERSOS	1/7	1/5	1/3	1

Fonte: Elaborada pela autora desta dissertação (2021).

Tabela 27 – Matriz de intensidade de importância – Nível 2 – UNIDADE DE TRABALHO

	INCERTEZ A DOS REQUERI MENTOS	COMPOR TAMENTO COLABO RATIVO	PERFIL TECNICO DO CLIENTE	ENVOLVI MENTO DO CLIENTE	HISTORI CO DO FORNE CEDOR	COMUNI CAÇÃO INTENSA
INCERTEZA DOS REQUERIMEN TOS	1	3	5	5	7	9
COMPORTA MENTO COLABORA TIVO	1/3	1	3	3	5	7
PERFIL TECNICO DO CLIENTE	1/5	1/3	1	3	5	5
ENVOLVIMEN TO DO CLIENTE	1/5	1/3	1/3	1	3	3
HISTORICO DO FORNECEDOR	1/7	1/5	1/5	1/3	1	1
COMUNICAÇÃO INTENSA	1/9	1/7	1/5	1/3	1	1

Fonte: Elaborada pela autora desta dissertação (2021).

Análogo ao que foi aplicado ao primeiro nível da hierarquia de critérios, foi calculado o vetor de Eigen para cada grupo de critérios (Fatores determinantes) de cada Forma de contratação, chegando-se as tabelas abaixo:

Tabela 28 – Cálculo do vetor de Eigen – Nível 2 – TETO DE CUSTO

	FALTA DE CONFI ANÇA	CREDIBI LIDADE DO CLIENTE	RANKING DE FORNECE DORES	RISCO REDUZI DO	PRAZO DE RISCO	Vetor de Eigen	%
FALTA DE CONFIANÇA	0,37367	0,36585	0,39823	0,34884	0,33333	0,363984	36%
CREDIBILIDADE DO CLIENTE	0,37367	0,36585	0,39823	0,34884	0,23810	0,344936	34%
RANKING DE FORNECE DORES	0,12456	0,12195	0,13274	0,20930	0,23810	0,165329	17%
RISCO REDUZIDO	0,07473	0,07317	0,04425	0,06977	0,14286	0,080955	8%
PRAZO DE RISCO	0,05338	0,07317	0,02655	0,02326	0,04762	0,044795	4%
						1	100%

Fonte: Elaborada pela autora desta dissertação (2021).

Tabela 29 – Cálculo do vetor de Eigen – Nível 2 – BÔNUS/PENALIDADE

	FOCO NO BENEFI CIO DO CLIENTE	BAIXO RISCO FINANCEI RO DO FORNE CEDOR	COMUNICA ÇÃO INTENSA	PROJETO POR DEMAN DA	Vetor de Eigen	%
FOCO NO BENEFICIO DO CLIENTE	0,596590909	0,661764706	0,535714286	0,4375	0,557892	56%
BAIXO RISCO FINANCEIRO DO FORNE CEDOR	0,198863636	0,220588235	0,321428571	0,3125	0,263345	26%
COMUNICA ÇÃO INTENSA	0,119318182	0,073529412	0,107142857	0,1875	0,121873	12%
PROJETO POR DEMANDA	0,085227273	0,044117647	0,035714286	0,0625	0,05689	6%
					1	100%

Fonte: Elaborada pela autora desta dissertação (2021).

Tabela 30 – Cálculo do vetor de Eigen – Nível 2 – HIBRIDA

	PROJETO POR ENTREGÁ VEIS	COMPLEXI DADE DE PROJETO	COMUNICA ÇÃO INTENSA	CLIENTES DIVER SOS	Vetor de Eigen	%
PROJETO POR ENTRE GÁVEIS	0,59659	0,66176	0,53571	0,43750	0,557892	56%
COMPLEXIDA DE DE PROJETO	0,19886	0,22059	0,32143	0,31250	0,263345	26%
COMUNICA ÇÃO INTENSA	0,11932	0,07353	0,10714	0,18750	0,121873	12%
CLIENTES DIVERSOS	0,08523	0,04412	0,03571	0,06250	0,05689	6%
					1	100%

Fonte: Elaborada pela autora desta dissertação (2021).

Tabela 31 – Cálculo do vetor de Eigen – Nível 2 – UNIDADE DE TRABALHO

	INCER TEZA DOS REQUE RIMEN TOS	COM PORTA MENTO COLA BORATI VO	PERFIL TECNI CO DO CLIEN TE	ENVOLVI MENTO DO CLIENTE	HISTO RICO DO FORNE CEDOR	COMU NICA ÇÃO INTEN SA	Vetor de Eigen	%
INCERTE ZA DOS REQUERI MENTOS	0,50319	0,59886	0,51370	0,39474	0,31818	0,34615	0,445804	45%
COMPOR TAMENTO COLABO RATIVO	0,16773	0,19962	0,30822	0,23684	0,22727	0,26923	0,234819	23%
PERFIL TECNICO DO CLIENTE	0,10064	0,06654	0,10274	0,23684	0,22727	0,19231	0,15439	15%
ENVOLVIME NTO DO CLIENTE	0,10064	0,06654	0,03425	0,07895	0,13636	0,11538	0,088687	9%
HISTORI CO DO FORNE CEDOR	0,07188	0,03992	0,02055	0,02632	0,04545	0,03846	0,040431	4%
COMUNI CAÇÃO INTENSA	0,05591	0,02852	0,02055	0,02632	0,04545	0,03846	0,035868	4%
							1	100%

Fonte: Elaborada pela autora desta dissertação (2021).

O cálculo do vetor de Eigen permite obter o peso relativo de cada Fator determinante para determinação de cada Forma de contratação. Ele determina a participação ou o peso daquele critério no resultado total da meta (XXXXXX, 2010). No exemplo da Tabela 31, o critério INCERTEZA DOS REQUERIMENTOS determina 45% da Forma de contratação UNIDADE DE TRABALHO, ou seja, o projeto que apresenta esta característica, tem um peso de 45%, apenas neste critério, para ser indicado a utilizar esta Forma de contratação.

4.1.3 Análise da Consistência

Conforme descrito por (XXXXXX; XXXXXX; XXXXX, 2009), a inconsistência surge quando algumas pontuações na matriz de comparação se contradizem com outras. Assim, o próximo passo é verificar a consistência dos dados. A verificação visa captar se os tomadores de decisão foram consistentes nas suas opiniões para a tomada de decisão (XXXXXX; XXXXXX, 2012).

Como exemplo, para validar a consistência da matriz da Forma de contratação UNIDADE DE TRABALHO, os cálculos vão validar se realmente tendo a relação dos valores informados INCERTEZA DOS REQUERIMENTOS > COMPORTAMENTO COLABORATIVO > PERFIL TECNICO DO CLIENTE > ENVOLVIMENTO DO CLIENTE > HISTORICO DO FORNECEDOR > COMUNICAÇÃO INTENSA, pode-se afirmar que INCERTEZA DOS REQUERIMENTOS > PERFIL TECNICO DO CLIENTE e que também PERFIL TECNICO DO CLIENTE > COMUNICAÇÃO INTENSA, dentre

outros, além disto, pode-se confirmar que não haverá a situação inconsistente de INCERTEZA DOS REQUERIMENTOS < COMUNICAÇÃO INTENSA.

É importante verificar a consistência dessas pontuações efetuando uma série de cálculos que indicam consistência ou não da matriz de comparação (BARROS, MARINS; XXXXX, 2009). De forma geral, Saaty orienta os seguintes passos:

- Calcular o Valor Principal de Eigen (λmax)

- Calcular o Índice de Consistência (CI)

- Calcular a Taxa de Consistência (CR)

4.1.3.1 Calculando o Valor Principal de Eigen (λmax)

O Valor Principal de Eigen é a soma ponderada do produto do total normalizado de cada critério pelo Vetor de Eigen do critério correspondente. A Tabela 32 apresenta os valores conforme a Tabela 23 referente a matriz da Forma de contratação.

Tabela 32 – Valor Principal de Eigen – Nível 1 – Forma de contratação

	TETO DE CUSTO	BÔNUS/ PENALIDADE	HIBRIDA	UNIDADE DE TRABALHO	Valor Principal de Eigen (λmax) (Soma dos produtos)
TOTAL (A)	1,67619	4,53333	9,33333	16,00000
Vetor de Eigen (B)	0,55789	0,26335	0,12187	0,05689
Produto (A*B)	0,93513 (=1,67619*0,55789)	1,19383	1,13748	0,91024	4,17668 (=0,93513 +1,19383+1,13748+ 0,91024)

Fonte: Elaborada pela autora desta dissertação (2021).

4.1.3.2 Calculando o Índice de Consistência (CI)

O próximo passo consiste em calcular um Índice de Consistência (CI) através da fórmula (XXXXXX; XXXXXX; XXXXX, 2009):

CI = (λmax - n) / (n – 1)

Sendo n = 4, pois são quatro critérios neste cálculo e sendo o Valor Principal de Eigen igual a 4,17668, o CI é então calculado:

CI = ( λmax -n ) / (n -1)

= (4,17668 – 4 ) / ( 4 – 1)

= 0,05889

4.1.3.3 Calculando a Taxa de Consistência (CR)

Ainda conforme Xxxxxx, Xxxxxx e Xxxxx (2009), para chegar ao CR basta dividir o CI pelo Índice de Consistência Aleatória Média (RI), uma constante cujo valor dependerá da dimensão da matriz que está sendo analisada. A Tabela 33 apresenta os Índices de Consistência Aleatória Média.

Tabela 33 - Índice de Consistência Aleatória Média (RI)

N	RI
1	0
2	0
3	0,58
4	0,9
5	1,12
6	1,24
7	1,32
8	1,41
9	1,45
10	1,49

Fonte: adaptado de Saaty (1988).

No caso do cálculo do CR para o Nível 1 de Forma de contratação, o RI obtido é de 0,9, pois quantidade de critérios é de 4. O CR obtido é de 7%, como pode ser verificado na Tabela 34.

Tabela 34 – Taxa de Consistência – CR – Nível 1 – Forma de contratação

	TETO DE CUSTO	BÔNUS/ PENALIDADE	HIBRIDA	UNIDADE DE TRABALHO	Valor Principal de Eigen (λmax)
TOTAL	1,67619	4,53333	9,33333	16,00000
Vetor de Eigen	0,55789	0,26335	0,12187	0,05689
Produto	0,93513	1,19383	1,13748	0,91024	4,17668
n		4	RI		0,9
CI = ( λmax -n ) / ( n -1 )					0,05889
CR = CI / RI					0,06544 7%

Fonte: Elaborada pela autora desta dissertação (2021).

A matriz será considerada consistente se a razão for menor que 10% (XXXXXX, 2010), o que neste caso (7%) acontece:

CR = CI / RI < 0,1 ~ 10%

4.1.3.4 Análise de todas as matrizes

Todas as matrizes de comparação foram analisadas quanto à consistência e se apresentaram consistentes com as taxas inferiores a 10%, como podem ser comprovadas nas tabelas a seguir.

Tabela 35 – Taxa de Consistência – CR – Nível 2 – TETO DE CUSTO

	FALTA DE CONFIANÇA	CREDIBILI DADE DO CLIENTE	RANKING DE FORNECE DORES	RISCO REDUZIDO	PRAZO DE RISCO	Valor Principal de Eigen (λmax)
TOTAL	2,67619	2,73333	7,53333	14,33333	21,00000
Vetor de Eigen	0,36398	0,34494	0,16533	0,08096	0,04480
Produto	0,97409	0,94283	1,24548	1,16036	0,94070	5,26345
n		5	RI			1,2
CI = ( λmax -n ) / ( n -1 )						0,06586
CR = CI / RI						0,05881 6%

Fonte: Elaborada pela autora desta dissertação (2021).

Tabela 36 – Taxa de Consistência – CR – Nível 2 – BÔNUS/ PENALIDADE

	FOCO NO BENEFICIO DO CLIENTE	BAIXO RISCO FINANCEIRO DO FORNECEDOR	COMUNICAÇÃO INTENSA	PROJETO POR DEMANDA	Valor Principal de Eigen (λmax)
TOTAL	1,67619	4,53333	9,33333	16,00000
Vetor de Eigen	0,55789	0,26335	0,12187	0,05689
Produto	0,93513	1,19383	1,13748	0,91024	4,17668
n		4	RI		0,9
CI = ( λmax -n ) / ( n -1 )					0,05889
CR = CI / RI					0,06544 7%

Fonte: Elaborada pela autora desta dissertação (2021).