1.uma Abordagem para o Desenvolvimento de Softwares Que Utilizam Blockchain - Compressed

FUNDAÇÃO EDSON QUEIROZ
UNIVERSIDADE DE FORTALEZA
CENTRO DE CIÊNCIAS TECNOLÓGICAS
MESTRADO EM INFORMÁTICA APLICADA
SAMANTHA KELLY SOARES DE ALMEIDA
UMA ABORDAGEM PARA O DESENVOLVIMENTO DE SOFTWARES QUE

UTILIZAM BLOCKCHAIN
FORTALEZA
2017
SAMANTHA KELLY SOARES DE ALMEIDA

UTILIZAM BLOCKCHAIN
Dissertação apresentada ao Curso de Mestrado

em Informática Aplicada da Universidade de
Fortaleza (UNIFOR), como requisito parcial
para obtenção do título de Mestre em
Informática Aplicada.
Orientador: Prof. Dr. Adriano Bessa

Albuquerque.
FORTALEZA
2017
ALMEIDA, SAMANTHA KELLY SOARES DE.
UTILIZAM BLOCKCHAIN / SAMANTHA KELLY SOARES DE ALMEIDA. - 2017 118
f.
Dissertação (Mestrado Acadêmico) - Universidade de Fortaleza. Programa de Mestrado em

Informática Aplicada, Fortaleza, 2017.
Orientação: ADRIANO BESSA ALBUQUERQUE.
1. Desenvolvimento de Software. 2. Processo. 3. Blockchain. 4. Startup. I. ALBUQUERQUE,

ADRIANO BESSA. II. Título.
A Deus e à minha família.
AGRADECIMENTOS
Agradeço a Deus por seu amor, misericórdia e providência em todos os momentos

desta caminhada, permitindo que por sua graça eu alcançasse mais essa vitória ao longo da
vida.
Agradeço ao meu esposo Rafael Menezes pelo companheirismo e apoio despendido ao
longo desse processo difícil em nossa família, permitindo que através do seu amor eu
chegasse ao final desta luta vitoriosa.
Agradeço à minha filha Sara Menezes, que por tantas vezes dormiu no carro me
aguardando concluir as disciplinas, brincou sozinha porque a mamãe estava estudando e
bravamente suportou com graça, alegria e maturidade essa difícil caminhada.
Agradeço aos meus pais Nádia e Robervan pelo apoio e por terem sempre acreditado
no meu potencial, mesmo que as condições financeiras não fossem favoráveis.
Agradeço aos meus sogros Cristina e Jorge por terem sido meu apoio e de minha
família em muitos momentos, demonstrando amor, cuidado e sendo vitais no alcance dessa
vitória.
Agradeço ao meu orientador Adriano Bessa, pela paciência, insistência e competência
demonstrada ao longo desse processo de construção.
Agradeço a Prof.ª Dr.ª Maria Elizabeth Sucupira Furtado e Prof.ª Dr.ª Andreia
Rodrigues Silva, pelo aceite do convite para composição da banca avaliadora, na certeza que
trarão valorosas contribuições para melhoria desta pesquisa.
Agradeço à empresa VTI, pelas horas cedidas durante a disciplina de Construção e
Análise de Algoritmos, permitindo que eu participasse presencialmente das aulas na
universidade.
Agradeço à Fundação Cearense de Apoio ao Desenvolvimento Científico e
Tecnológico – FUNCAP – pelo apoio financeiro, que me permitiu cumprir com os
compromissos assumidos perante a Unifor.
Desejo que você
Não tenha medo da vida, tenha medo de não

vivê-la.
Não há céu sem tempestades, nem caminhos
sem acidentes.
Só é digno do pódio quem usa as derrotas
para alcançá-lo.
Só é digno da sabedoria quem usa as lágrimas
para irrigá-la.
Os frágeis usam a força; os fortes, a
inteligência.
Seja um sonhador, mas una seus sonhos com
disciplina, pois sonhos sem disciplina
produzem pessoas frustradas.
Seja um debatedor de ideias. Lute pelo que
você ama.
Augusto Cury
UTILIZAM BLOCKCHAIN
RESUMO
Ultimamente a tecnologia de Cadeia de blocos (Blockchain) vem ganhando visibilidade no

mercado. A popularização deste conceito pode ser atribuída ao sucesso exponencial da
criptomoeda Bitcoin, lançada em 2008 por Satoshi Nakamoto. A visão disruptiva dessa
tecnologia e as diversas possibilidades de aplicação em negócios distintos vêm gerando uma
série de mudanças e investimentos no mercado, destacando-se principalmente o setor
financeiro. O surgimento de diversas Fintechs (Startups do setor financeiro) voltadas a
softwares que utilizam Blockchain demonstra os investimentos ocorridos para o avanço dessa
tecnologia. Neste trabalho, foi realizada uma pesquisa bibliográfica a fim de compreender o
estado da arte de Blockchain e foi também executada uma experiência de uso, onde foi
desenvolvido um aplicativo utilizando esta tecnologia, sendo fonte de informações para a
definição detalhada de um processo de desenvolvimento de software, baseado em Lean
Startup, para apoiar startups a trabalharem com projetos que envolvam Blockchain.
Palavras-chave: Desenvolvimento de Software, Processo, Blockchain, Startups.

AN APPROACH TO DEVELOPING SOFTWARE THAT USES BLOCKCHAIN
ABSTRACT
Lately Blockchain technology has been gaining market visibility. The popularization of this
concept can be attributed to the exponential success of the Bitcoin cryptocurrency, launched
in 2008 by Satoshi Nakamoto. The disruptive vision of this technology and the diverse
possibilities of application in different businesses have been generating a series of changes
and investments in the market, especially the financial sector. The emergence of several
Fintechs (Startups in the financial sector) focused on software using Blockchain demonstrates
the investments made to advance this technology. In this work, a bibliographical research was
carried out in order to understand the state of the art of Blockchain and an experience of use
was developed, where an application was developed using this technology, being source of
information for the detailed definition of a software development process, based on Lean
Startup, to support startups working with projects involving Blockchain.
Keywords: Software Development, Process, Blockchain, Startup.

LISTA DE ILUSTRAÇÕES
Figura 1 – Camadas da engenharia de software ....................................................................... 24
Figura 2 – Princípios do Pensamento Enxuto........................................................................... 27
Figura 3 – Exemplo de mapeamento do fluxo de valor ............................................................ 28
Figura 4 – Ilustração de Fluxo de Contínuo Lean .................................................................... 29
Figura 5 – Circuito de Reação .................................................................................................. 30
Figura 6 – Funcionamento de uma transação na Cadeia de blocos (Blockchain) .................... 35
Figura 7 – Funcionamento de contratos inteligentes ................................................................ 38
Figura 8 – Vantagens de um contrato inteligente ..................................................................... 40
Figura 9 – Ciclo de vida de uma transação bitcoin................................................................... 42
Figura 10 – Macro atividades de um processo de abertura de startup ...................................... 45
Figura 11 – Framework teórico/tecnológico ............................................................................ 50
Figura 12 – Resumo das características das personas identificadas ......................................... 53
Figura 13– Registro de transações ............................................................................................ 54
Figura 14 – Criar Contrato – Permite o registro do contrato de votação na Cadeia de blocos

(Blockchain) ............................................................................................................................. 55

(Blockchain). ............................................................................................................................ 55
Figura 16 – Cadastrar Candidato – Permite o cadastro do candidato relacionado com o

contrato de votação na cadeia de blocos (Blockchain). ............................................................ 55
Figura 17 – Cadastrar Candidato – Confirmação do registro do candidato relacionado com o

contrato de votação na Cadeia de blocos (Blockchain). ........................................................... 56
Figura 18– Registrar voto – Exibição do candidato cadastrado para ser votado. ..................... 56
Figura 19 – Encerrar votação – Exibição do resultado da votação. ......................................... 57
Figura 20 – Representação da arquitetura proposta.................................................................. 58
Figura 21 – Instanciação do objeto Web3 ............................................................................... 61
Figura 22 – Compilação do arquivo.sol.................................................................................... 62
Figura 23 – Instanciação do objeto do contrato ........................................................................ 62

Figura 24 – Chamada à função de implantação do contrato..................................................... 62

Figura 27 – Teste da Criação do Contrato ................................................................................ 64
Figura 28 – Teste do registro de candidatos ............................................................................. 65
Figura 29 – Teste do registro de votos nos candidatos ............................................................. 66
Figura 30 – Teste da consistência de votos nos candidatos ...................................................... 66
Figura 31 – Teste da consistência da quantidade total de votos ............................................... 67
Figura 32 – Resultados dos testes com sucesso ........................................................................ 67
Figura 33 – Resultados dos testes com falha ............................................................................ 68
Figura 34 –Representação gráfica do fluxo do processo .......................................................... 15
Figura 35 – Representação gráfica do perfil técnico dos entrevistados ................................... 30
Figura 36 – Representação gráfica da experiência profissional dos entrevistados................... 31
Figura 37 – Representação gráfica do conhecimento prévio em blockchain dos entrevistados

.................................................................................................................................................. 31
Figura 38 – Representação gráfica do nível de escolaridade dos entrevistados ....................... 32
Figura 39 – Representação gráfica da vivência em startups dos entrevistados ........................ 32

LISTA DE QUADROS
Quadro 1 – Composição da equipe ................................................................................. 48

Quadro 2 – Lista de requisitos funcionais e não funcionais associados ......................... 52
Quadro 3 – Representação da atividade – Caracterizar e analisar o problema ............... 15
Quadro 4 – Representação da atividade – Definir o produto de software ...................... 15
Quadro 5 – Representação da atividade – Identificar personas e cenários ..................... 16
Quadro 6 – Representação da atividade – Identificar requisitos ..................................... 16
Quadro 7 – Representação da atividade – Definir arquitetura da solução ...................... 17
Quadro 8 – Representação da atividade – Configurar ambiente Blockchain.................. 17
Quadro 9 – Representação da atividade – Configurar Ambiente Web ........................... 18
Quadro 10 –Representação da atividade – Priorizar requisitos ...................................... 18
Quadro 11 – Representação da atividade – Planejar Iteração ......................................... 19
Quadro 12 – Representação da atividade – Identificar personas e cenários ................... 19
Quadro 13 – Representação da atividade – Projetar/Desenvolver testes ........................ 20
Quadro 14– Representação da atividade – Codificar funcionalidades............................ 20
Quadro 15 – Representação da atividade – Publicar na Blockchain de Testes ............... 21
Quadro 16 – Representação da atividade – Executar testes ............................................ 22
Quadro 17 – Representação da atividade – Corrigir problemas ..................................... 22
Quadro 18 – Representação da atividade – Publicar na Blockchain real ........................ 23
Quadro 19 – Representação da atividade – Coletar feedbacks ....................................... 23
Quadro 20 – Representação da atividade – Coletar medições ........................................ 24
Quadro 21 – Representação da atividade – Realizar retrospectiva ................................. 24
Quadro 22 – Representação da atividade – Avaliar MVP do produto ............................ 25
SUMÁRIO
1 INTRODUÇÃO ..................................................................................................................... 15
1.2 MOTIVAÇÃO ................................................................................................................ 15
1.3 OBJETIVOS ................................................................................................................... 18
1.4 METODOLOGIA ........................................................................................................... 19
1.5 ESTRUTURA DO TRABALHO ................................................................................... 19
1.6 TRABALHOS RELACIONADOS ................................................................................ 20
1.7 CONCLUSÃO DO CAPÍTULO .................................................................................... 20
2 FUNDAMENTAÇÃO TEÓRICA ........................................................................................ 21
2.1 ENGENHARIA DE SOFTWARE ................................................................................. 21
2.1.1 Conceitos de software ................................................................................. 21
2.1.2 Conceitos de engenharia de software .......................................................... 24
2.1.3 Processo de software ................................................................................... 26
2.1.4 Metodologia Lean ....................................................................................... 26
2.1.4.1 Lean Startup ......................................................................................... 29

2.1.4.2 Lean Development (Desenvolvimento Enxuto) ................................... 32
2.2 INFRAESTRUTURA TECNOLÓGICA BLOCKCHAIN ............................................ 33
2.2.1 Cadeia de Blocos (Blockchain) ...................................................................... 33
2.2.1.1 Características ......................................................................................... 35

2.2.1.2. Principais aplicações .............................................................................. 36
2.2.2 Contratos inteligentes ..................................................................................... 37
2.2.3 Bitcoin ............................................................................................................ 41
2.3 STARTUP ...................................................................................................................... 43

3 EXPERIÊNCIA DE USO NO DESENVOLVIMENTO DE SOFTWARE UTLIZANDO-SE
CADEIA DE BLOCOS (BLOCKCHAIN) ............................................................................ 47
3.1 CARACTERIZAÇÃO da experiência de uso ................................................................ 47
3.1.1 Motivação ....................................................................................................... 47
3.1.2 Domínio de aplicação ..................................................................................... 47
3.2 MATERIAIS E MÉTODOS........................................................................................... 48
3.2.1 Equipe ............................................................................................................ 48
3.2.2 Metodologia utilizada..................................................................................... 48
3.3 RESULTADOS E DISCUSSÕES .................................................................................. 50
3.3.1 Base teórica e tecnológica .............................................................................. 50
3.3.2 Requisitos ....................................................................................................... 51
3.3.2.1 Requisitos funcionais e não funcionais ................................................... 52

3.3.2.2 Personas .................................................................................................. 53
3.3.2.3 Cenários de uso ....................................................................................... 53
3.3.2.4 Interface do sistema................................................................................. 55
3.3.3 Definição da arquitetura utilizada .................................................................. 57
3.3.3.2 Ambiente de desenvolvimento ................................................................ 59

3.3.3.3. Principais ferramentas/bibliotecas utilizadas ......................................... 60
3.3.4 Implementação do protótipo do produto ........................................................ 61
3.3.5 Testes de software para cadeia de blocos (Blockchain) ................................. 63
3.3.6 Resultados obtidos com a revisão bibliográfica e a experiência de uso ........ 68

4 PROCESSO DE DESENVOLVIMENTO DE SOFTWARE para produtos cadeia de blocos
(Blockchain) ........................................................................................................................... 71
4.1 FLUXO DO PROCESSO ............................................................................................... 71
4.2 Atividades do Processo................................................................................................... 15
4.2.1 Atividade 1: Caracterizar e analisar o problema ............................................ 15
4.2.2 Atividade 2: Definir o produto de software ................................................ 15

4.2.3 Atividade 3: Identificar personas e cenários ............................................... 16
4.2.4 Atividade 4: Identificar requisitos ............................................................... 16
4.2.5 Atividade 5: Definir arquitetura da solução ................................................ 17
4.2.6 Atividade 6: Configurar ambiente Blockchain............................................ 17
4.2.7 Atividade 7: Configurar ambiente web ....................................................... 18
4.2.8 Atividade 8: Priorizar requisitos ................................................................. 18
4.2.9 Atividade 9: Planejar iteração ..................................................................... 19
4.2.10 Atividade 10: Documentar Histórias de Usuários ..................................... 19
4.2.11 Atividade 11: Projetar/Desenvolver testes ................................................ 20
4.2.12 Atividade 12: Codificar funcionalidades ................................................... 20
4.2.13 Atividade 13: Publicar na Blockchain de testes ........................................ 21
4.2.14 Atividade 14: Executar testes .................................................................... 22
4.2.15 Atividade 15: Corrigir problemas.............................................................. 22
4.2.16 Atividade 16: Publicar na Blockchain real ................................................ 23
4.2.17 Atividade 17: Coletar feedbacks ............................................................... 23
4.2.18 Atividade 18: Coletar medições ................................................................ 24
4.2.19 Atividade 19: Realizar retrospectiva ......................................................... 24
4.2.20 Atividade 20: Avaliar MVP do produto .................................................... 25
4.2.21 Atividade 21: Lançar produto.................................................................... 26
4.3 ATIVOS DO PROCESSO ............................................................................................. 26

4.4 MEDIÇÕES PROPOSTAS ............................................................................................ 27
4.5 AVALIAÇÃO DO PROCESSO ..................................................................... 28
4.5.1 Metodologia utilizada na avaliação ................................................................ 28
4.5.2 Perfil dos entrevistados ............................................................................... 29
4.5.3 Resultados ................................................................................................... 33
4.5.4 Oportunidades de melhoria, pontos fracos e pontos fortes ......................... 33

5 CONCLUSÃO E TRABALHOS FUTUROS ....................................................................... 38
5.1 CONSIDERAÇÕES FINAIS ......................................................................................... 38
5.2 PRINCIPAIS CONTRIBUIÇÕES ................................................................................. 39
5.3 LIMITAÇÕES ................................................................................................................ 39
5.4 TRABALHOS FUTUROS ............................................................................................. 40
REFERÊNCIAS ....................................................................................................................... 41
ANEXOS .................................................................................................................................. 45
ANEXO A – CENÁRIOS DE USO ................................................................................................. 45
ANEXO B – EXEMPLO COMENTADO DE CANVAS PARA MODELO DE NEGÓCIO ......... 50
ANEXO C – POLÍTICA DE DESENVOLVIMENTO DE SOFTWARE BLOCKCHAIN.......... 51
ANEXO D – CHECKLIST DE VERIFICAÇÃO DE ADEQUAÇÃO BLOCKCHAIN. ................ 52
ANEXO E – ARQUITETURA DE REFERÊNCIA BLOCKCHAIN. ............................................. 53
ANEXO F – EXEMPLO COMENTADO DE KANBAN PARA STARTUPS QUE UTILIZAM
LEAN STARTUP ............................................................................................................................ 55
ANEXO G – MODELO DE HISTÓRIA DE USUÁRIOS .............................................................. 56
ANEXO H – ESPECIFICAÇÃO DAS MEDIÇÕES ....................................................................... 57
ANEXO I – QUESTIONÁRIO DE AVALIAÇÃO DO PRODUTO. .............................................. 58
ANEXO J – QUESTIONÁRIO DE AVALIAÇÃO DO PROCESSO ............................................. 59
15
1 INTRODUÇÃO
Este capítulo apresenta a introdução da pesquisa, contendo a descrição da

problemática que motivou e justificou o desenvolvimento deste trabalho. Em seguida, são
descritos os objetivos e a metodologia aplicada para construção dos resultados. Ao final, é
apresentada a forma de organização desta dissertação.
1.2 MOTIVAÇÃO
Nos últimos anos, muita atenção vem sendo dada aos conceitos emergentes de Cadeia
de Blocos (Blockchain) e Contratos Inteligentes, principalmente após a popularização da
moeda virtual Bitcoin lançada em 2008 por um desconhecido sob o pseudônimo de Satoshi
Nakamoto (NAKAMOTO, 2009).
Com a concretização da moeda virtual Bitcoin e os conceitos inovadores que essa ação
trouxe ao mercado financeiro, organizações como instituições bancárias, financeiras e órgãos
públicos reguladores começaram a discutir explicitamente sobre a importância dessas novas
tecnologias de cadeia de blocos (Blockchain) e contratos inteligentes. Alguns observadores
falam até do amanhecer de uma nova era, declarando que “[...] deve-se pensar sobre a Cadeia
de blocos (Blockchain) como outra classe de coisa como a Internet [...]” (PORRU et al.,
2017).
A cadeia de blocos (Blockchain) é um sistema de livro-razão público que usa um
consenso de rede para gravar e executar transações. De forma mais técnica, é também
conhecida como um protocolo de confiança, onde através de uma rede peer-to-peer (P2P)
funciona como um banco de dados distribuído e descentralizado que armazena cadeias de
blocos de informações interligados e acessíveis via hash, sendo o primeiro bloco de cada
cadeia conhecido como Gênese. Por manter todo o histórico das transações desde o
nascimento da cadeia e não permitir alterações dessas informações de forma desordenada, a
cadeia de blocos (Blockchain) é considerada como a solução para transações seguras e
confiáveis via Internet, gerando pensamento disruptivo em muitos universos de negócio
conhecidos atualmente. (TAPSCOTT; TAPSCOTT,2016).
Esta tecnologia recentemente vem chamando atenção de um
número crescente de líderes empresariais que reconhecem que a tecnologia subjacente
desta arquitetura transformacional pode ser aplicada a quase qualquer indústria.
A característica mais relevante da cadeia de blocos (Blockchain) é que nenhum agente único
16
possui a capacidade de executar o controle sobre a atividade do sistema. A validação da

transação ocorre pela cadeia através da estratégia de consenso. Um protocolo de consenso é
acordado por todos os membros participantes da rede de negócios e assegura que o livro razão
seja atualizado somente com as transações verificadas na rede. A verificação se dá através dos
mineradores, por meio de algoritmos de consenso. O minerador que decodifica a transação
para permitir a validação desta pela cadeia, recebe uma bonificação, geralmente paga em
criptomoeda. (COLLINS,2016)
Segundo Plansky, O’Donnell e Kimberly (2016), a tecnologia poderia se tornar um
fator diferenciador em suas próprias capacidades, permitindo-lhes processar transações com
mais eficiência, segurança, privacidade, confiabilidade e velocidade. É possível que a cadeia
de blocos (Blockchain) possa transformar transações no mesmo grau em que o sistema de
posicionamento global (GPS) transformou o transporte, fazendo dados acessíveis através de
uma plataforma eletrônica comum. Ninguém é necessário para validar as transações. É por
isso que o Bitcoin é, muitas vezes, referido como um sistema "sem confiança". Você não
precisa saber qualquer coisa sobre os outros jogadores, ou confiar neles como indivíduos,
basta ter fé no sistema e investir seu dinheiro lá. Além disso, uma vez inseridas no livro-razão
distribuído, as transações são imutáveis. Os registros não podem ser adulterados, porque
alterá-los exigiria coordenar muitos computadores e muito potencial computacional.
(PLANSKY; O’DONNELL; KIMBERLY,2016).
A tecnologia também pode ser usada para criar e apoiar "contratos inteligentes":
conjuntos de regras definidas e baseados em uma base de dados de blocos que executam
somente quando ocorrem ações específicas. Eris Industries, uma empresa de software que
criou uma das primeiras plataformas baseadas em blocos para este aplicativo, descreve
Contratos inteligentes como componentes modulares, semelhantes aos aplicativos em uma
rede financeira, que podem ser combinados para fornecer verificabilidade a qualquer tipo de
transação. De acordo com os estudiosos da indústria Eris, os usos podem ser “[...] tão simples
como votar uma postagem em um fórum, para o mais complexo, como a garantia de
empréstimos e os contratos de futuros, para o altamente complexo, como a priorização de
reembolso em uma nota estruturada”. (PLANSKY; O’DONNELL; KIMBERLY, 2016).
Grandes empresas do mercado financeiro e tecnológico vêm criando consórcios e
plataformas para implementação de softwares que utilizem cadeia de blocos (Blockchain),
como o Hyperledger(IBM), R2, Bitcoin(Livre) e Ethereum(Livre), que visam ao
desenvolvimento de softwares de códigos abertos ou privados, organização da tecnologia e
geração de padronizações para facilitar o desenvolvimento de produtos nesta área, tendo como
17
foco a validação dos conceitos e estudos de iniciativas de regulamentação do uso dessas

tecnologias. (TAPSCOTT; TAPSCOTT,2016).
A cadeia de blocos (Blockchain) está remodelando finanças, economia e dinheiro na
medida em que seu poder tecnológico cresce. Está sendo comparada com a Internet em seus
primeiros dias. Como resultado, todo o desenvolvimento de software girando em torno da
tecnologia Cadeia de blocos (Blockchain) está crescendo a uma taxa surpreendente. Porru et
al. reconhecem a necessidade de engenheiros de software, papéis, padrões arquiteturais,
diagramas UML e técnicas de teste de softwares específicos para sistemas orientados à cadeia
de blocos (Blockchain). (PORRU et al.,2017).
Do ponto de vista econômico e financeiro, o conjunto de capitalização das moedas
digitais é de cerca de 12 bilhões de dólares, sendo, em outubro de 2016, 80% relativos a
Bitcoins. Investimentos em capital de risco em startups de cadeia de blocos vêm aumentando
constantemente, passando de US$ 93,8 milhões em 2013 para US$ 315 milhões em 2014, até
US$ 490 milhões em 2015. (PORRU, 2016)
As startups normalmente visam criar produtos de alta tecnologia e inovadores, e
geralmente crescem expandindo agressivamente seus negócios em grande escalabilidade de
mercados.
De uma perspectiva de engenharia de software, startups são únicas, uma vez que
desenvolvem softwares em um contexto onde os processos dificilmente seguem uma
metodologia prescritiva e lidam com problemas únicos que geram desafios
inovadores. Startups de software compartilham algumas características com outros contextos,
como pequenas empresas de tecnologia, mas apresentam uma combinação de diferentes
fatores que tornam o ambiente de desenvolvimento particular em relação aos demais
diferentes tipos de empresas estabelecidas. Portanto, é necessária investigação para apoiar
atividades de engenharia de software em startups, orientar praticantes em tomar decisões e
evitar escolhas que poderiam facilmente conduzir a falhas de produção. (GIARDINO, 2016)
Dada a relevância e poder inovador desta tecnologia de cadeia de blocos, este trabalho
tem como principal fator motivador compreender o papel e as contribuições da engenharia de
software neste contexto, buscando identificar características específicas a serem consideradas
durante o processo de construção de produtos de software que utilizem cadeia de blocos
(Blockchain), tendo como base metodológica a aplicação da engenharia de software.
Com o desenvolvimento deste trabalho, buscamos identificar um exemplo de processo
de desenvolvimento de software que auxilie empresas startups no desenvolvimento de
produtos de software orientados à cadeia de blocos (Blockchain), favorecendo assim, a
18
difusão da tecnologia, contribuindo para a validação de hipóteses existentes e, ainda,

auxiliando no esclarecimento de lacunas decorrentes do crescente avanço tecnológico e das
recentes discussões e estudos em massa sobre o assunto.
Como foco principal da pesquisa, buscamos construir uma abordagem de processos de
desenvolvimento de software para produtos que utilizem a tecnologia de cadeia de blocos
(Blockchain) e identificar respostas às seguintes questões:
a) Que particularidades da engenharia de software estão envolvidas no

desenvolvimento de produtos de software que utilizam cadeia de blocos
(Blockchain)?
b) Quais os principais desafios tecnológicos que empresas do tipo startups enfrentam
para inovar na área de cadeia de blocos (Blockchain)?
1.3 OBJETIVOS
O objetivo geral deste trabalho é:
Identificar um processo composto por métodos, técnicas e ferramentas que auxiliem

empresas startups do setor de tecnologia da informação a desenvolverem produtos de software
na área de contratos inteligentes utilizando a tecnologia de cadeia de blocos (Blockchain).
Os principais objetivos específicos deste trabalho são:
a) Identificar modelos de referência e bases metodológicas para processos de

desenvolvimento de software difundidos e executados atualmente em empresas
startups de tecnologia.
b) Identificar particularidades do desenvolvimento de produtos de software na área
de contratos inteligentes que utilizam a plataforma cadeia de blocos (Blockchain).
c) Elaborar um processo de software que auxilie as empresas de tecnologia da
informação a aplicar “melhores práticas” existentes na bibliografia ou decorrentes
de lições aprendidas, com o objetivo de favorecer a difusão da tecnologia e o
desenvolvimento de produtos na área de contratos inteligentes utilizando cadeia
de blocos (Blockchain).
19
1.4 METODOLOGIA
Para cumprir com os anseios e objetivos propostos, a realização deste trabalho foi
dividida em 5 etapas:
a) A etapa 1 foi constituída pela realização de pesquisa bibliográfica na área de

processo de desenvolvimento de software para startups, com objetivo de levantar
modelos a serem adaptados para as especificidades da tecnologia de cadeia de
blocos (Blockchain).
b) A etapa 2 foi composta pela realização de uma pesquisa bibliográfica para
levantamento do estado da arte e aprofundamento do conhecimento na área de
contratos inteligentes e cadeia de blocos (Blockchain), com foco em entender as
particularidades que permeiam a construção deste tipo de produto de software.
c) A etapa 3 envolveu a execução de um caso prático através da construção de uma
ferramenta utilizando-se da tecnologia de contratos inteligentes aliada à cadeia de
blocos (Blockchain), embasados na engenharia de software, e teve como objetivo
de entender as particularidades neste contexto.
d) A etapa 4 permitiu a construção de um processo-guia para desenvolvimento de
produtos de software na área contratos inteligentes utilizando cadeia de blocos
(Blockchain) por empresas startups, baseando-se na experiência vivida nas etapas
anteriores. A validação do processo se deu através da técnica de revisão por pares,
onde foram entrevistados dez (10) profissionais no intuito de perceber a
adequação do processo modelado.
e) A etapa final teve como foco explicitar as principais contribuições deste trabalho,
suas limitações e indicar a gama de trabalhos futuros identificados ao longo deste
processo de construção.
1.5 ESTRUTURA DO TRABALHO
Este trabalho está organizado em 5 (cinco) capítulos, conforme vemos descrição

sucinta a seguir.
No Capítulo 1, INTRODUÇÃO, são apresentados a motivação que justificou esta
pesquisa, o objetivo geral e específicos e a metodologia utilizada para cumprimento dos
objetivos deste trabalho.
20
No Capítulo 2, FUNDAMENTAÇÃO TEÓRICA, é apresentado o estudo já

realizado sobre os conceitos principais utilizados neste trabalho que foram levantados através
de pesquisa bibliográfica.
No Capítulo 3, EXPERIÊNCIA DE USO NO DESENVOLVIMENTO DE
SOFTWARE UTLIZANDO CADEIA DE BLOCOS (BLOCKCHAIN), são apresentadas
as etapas vividas e os produtos de trabalho gerados durante a vivência da experiência. É
destacado também o produto de software que evidencia a utilização dos conceitos e das
tecnologias de contratos inteligentes e cadeia de blocos (Blockchain).
No Capítulo 4, PROCESSO DE DESENVOLVIMENTO DE SOFTWARE
ADAPTADO PARA STARTUPS DE SOLUÇÕES EMCADEIA DE BLOCOS
(BLOCKCHAIN), é apresentado o processo proposto gerado como resultado da pesquisa
bibliográfica e realização da experiência de uso apresentados no capítulo 3.
No Capítulo 5, CONCLUSÃO E TRABALHOS FUTUROS, são apresentadas as
conclusões do presente trabalho e as principais contribuições identificadas. São descritas,
ainda, as sugestões e perspectivas futuras de pesquisa nesta área de estudo.
1.6 TRABALHOS RELACIONADOS
Por se tratar de um conhecimento de natureza inovadora e em estado de ascensão, não

foram identificados trabalhos relacionados durante a realização da pesquisa.
1.7 CONCLUSÃO DO CAPÍTULO
Neste capítulo, apresentamos as motivações que levaram à identificação da

necessidade da pesquisa, os conceitos introdutórios de cadeia de blocos (Blockchain) e
contratos inteligentes, as principais questões que nortearam o trabalho, os objetivos definidos
como escopo da obra, as estratégias metodológicas utilizadas e a estruturação e organização
proposta para organização textual dos resultados do trabalho.
21
2 FUNDAMENTAÇÃO TEÓRICA
2.1 ENGENHARIA DE SOFTWARE
2.1.1 Conceitos de software
Conforme Kazman, como a importância do software em nossa sociedade vem

crescendo nos últimos anos, faz-se necessário também a evolução dos deveres, habilidades e
conhecimentos necessários dos engenheiros de software, assim como adaptações da própria
engenharia de software para se adequar às evoluções de mercado. (KAZMAN; TANG,2017)
Apesar de ser caracterizado como intangível e possuir difícil compreensão de sua
definição, o software é definido por Sommerville como o conjunto de todos os artefatos
gerados no seu processo de produção e não somente o código fonte. (SOMMERVILLE, 2003)
Para Pressman, o conceito de software deve ser composto por três vertentes, sendo:(1)
um conjunto composto por instruções de computador que, quando executadas, fornecem
características, funções e desempenho desejados;(2) estruturas de dados que possibilitam aos
programas manipular informações adequadamente; e (3) documentos ou informação
descritiva, tanto impressa como virtual, que descrevem a operação e utilização dos programas.
(PRESSMAN, 2011).
A categorização do campo de aplicação do software em sete cenários gera desafios
contínuos aos engenheiros de software, sendo eles (PRESSMAN, 2011):
a) Software de sistema: conjunto de programas feito para atender a outros

programas (drivers, compiladores, componentes do sistema operacional, etc.).
Caracterizada pela interação com o hardware.
b) Software de aplicação: programas que solucionam um problema de negócio.
Utilizado para controlar funções do negócio em tempo real (controle de transações
de vendas, gestão de processos, etc.).
c) Software científico de engenharia: Algoritmos para os processamentos
numéricos dispendiosos (meteorologia, vulcanologia, indústria espacial).
d) Software embutido: embarcado em um produto ou sistema e utilizado para
implementar e controlar características e funções (painel do micro-ondas, controle
do nível de combustível do carro), sendo muito utilizado na internet das coisas.
22
e) Software para linha de produtos: Projetado para prover capacidade específica

de utilização por clientes diversos (controle de estoque, gerenciamento de bancos
de dados, planilhas eletrônicas). Conhecidos popularmente como softwares de
prateleira.
f) Aplicações para a Web: Conjunto de arquivos de hipertexto interconectados que
abarcam uma gama de aplicações. Com a evolução da Web 2.0, essas aplicações
estão ligadas a bancos de dados corporativos e aplicações comerciais.
g) Softwares de inteligência artificial: Fazem uso de algoritmos não numéricos
para solucionar problemas complexos que não são passíveis de análise direta.
Aplicados na robótica, redes neurais, reconhecimento de padrões, jogos, etc.
Como fruto desta pesquisa, acrescentamos a estes cenários um novo contexto,

conforme descrito abaixo:
h) Software orientado à Cadeia de blocos (Blockchain) - SOB: “softwares que

utilizam a implementação de uma Cadeia de blocos (Blockchain) em seus
componentes”. (PORRU et al.,2017). Realizando uma análise deste conceito e
acrescentando os conhecimentos adquiridos ao longo deste estudo, podemos
entender que os softwares do tipo SOB, se aplicam a problemas que envolvem
transações entre duas partes que necessitam de validação de autenticidade, que
englobam processamento distribuído em uma rede peer-to-peer (P2P), que
exigem taxa de remuneração para validação das transações que alteram o estado
da cadeia e que gravam o histórico de transações de forma imutável, permitindo
o rastreio de uma cadeia de blocos de informações desde a sua origem.
Ainda conforme Pressman, novos desafios vêm surgindo aos engenheiros de software,
sendo eles: (1) Computação mundial aberta – com o crescimento exponencial das redes sem
fio, brevemente será necessário desenvolver aplicativos de software que possam se comunicar
de forma pervasiva e distribuída através de extensas redes; (2) Netsoursing (recursos via
internet) – a internet está se tornando um provedor de conteúdo e o desafio é desenvolver
aplicações simples e sofisticadas que forneçam benefícios aos usuários finais em massa,
possibilitando a geração e evolução de novos mercados; e (3) Software aberto – tendência de
mercado que consta na distribuição de códigos-fonte para aplicações de sistemas. O desafio é
23
construir códigos simples e autoexplicativos que possibilitem o rápido entendimento e

reaproveitamento para os demais engenheiros interessados. (PRESSMAN, 2011)
Com relação ao surgimento dos novos cenários desafiadores citados anteriormente,
entendemos neste trabalho a relevância da tecnologia de cadeia de blocos (Blockchain) como
base tecnológica para solução ou redução de alguns dos problemas a serem enfrentados nesses
contextos.
Efetuando uma breve relação entre os cenários e as possibilidades de utilização da
tecnologia de Cadeia de blocos (Blockchain), podemos verificar:
a) Com relação ao tópico 1, Computação mundial aberta, a tecnologia já citada

possui base descentralizada, redundância de dados, gestão distribuída na cadeia de
blocos e facilidade de escala através do conceito de carteiras.
b) No caso do tópico 2, Netsoursing (recursos via internet),combinada a contratos
inteligentes (SmartContract) – definidos por Joe Dewey e Shawn Amuial (2015)
como um protocolo de computador feito para facilitar, verificar ou reforçar a
negociação ou desempenho de um contrato, sendo capaz de ser executado ou de se
fazer cumprir por si só – a cadeia de blocos (Blockchain) favorece uma transação
peer-to-peer de forma segura e rastreável de forma transparente, sem a
necessidade de um terceiro envolvido para validar a transação. Deste modo,
serviços como os oferecidos em cartórios e instituições financeiras podem ocorrer
diretamente entre os envolvidos de forma transparente e segura, trazendo
transformação digital e a oferta de serviços online para os mercados que envolvem
registros de transações, como o mercado imobiliário, financeiro, da saúde e
demais contextos que possuam essas características.
c) Ainda em relação ao 3, Software aberto, a descentralização da cadeia de blocos e
a possibilidade de códigos integrados e validação colaborativa de transações
favorecem a cultura do compartilhamento, que é premissa do software aberto,
possibilitando que o valor fique nas informações de negócio e não na codificação
de sistemas que apoiam o negócio. Ressalta-se que foi percebida na pesquisa a
existência de inúmeros projetos de softwares orientados à cadeia de blocos
(Blockchain) disponíveis de forma colaborativa na ferramenta Github.
24
Neste trabalho, tivemos como foco a abordagem do conceito de Software Orientado a

Blocos (SOB) definido por Porru como “[...] softwares que utilizam a implementação de uma
Cadeia de blocos (Blockchain) em seus componentes”. (PORRU et al.,2017).
2.1.2 Conceitos de engenharia de software
Na atualidade, existem diversos conceitos apresentados sobre a definição do termo

Engenharia de Software. Uma das mais antigas nesse contexto, datada de 1969 e divulgada na
conferência NATO Science Committe, foi a de Fritz Bauer, que a definiu como “A criação de
sólidos princípios de engenharia afim de obter software de maneira econômica, que seja
confiável e que trabalhe eficientemente em máquinas reais”. (BAUER, 1969apud
PRESSMAN, 2005)
No intuito de alcançar maior completude, o Instituto de Engenheiros Eletricistas e
Eletrônicos (IEEE) desenvolveu uma definição mais abrangente: “Engenharia de Software é:
(1) A aplicação de uma abordagem sistemática, disciplinada e quantificável no
desenvolvimento, na operação e na manutenção de software; isto é, a aplicação de engenharia
de software [...] (2) O estudo de abordagens como definido em (1) ”. (PRESSMAN, 2011;
SOMMERVILLE, 2006).
De acordo com Pressman (2011), a engenharia de software é uma tecnologia
organizada em camadas cuja abordagem está fundamentada em um comprometimento da
organização com a garantia da qualidade (Figura 1).
Figura 1 – Camadas da engenharia de software
Fonte: (PRESSMAN, 2011).
Na Figura 1, podemos observar que a base da engenharia de software está composta

pelo foco na qualidade. A gestão e garantia da qualidade embasada pelos modelos de
maturidade organizacionais promovem a evolução contínua dos processos e produtos de uma
instituição, ajudam a compreender os pontos de melhorias e valorizam o resultado a ser
25
entregue ao cliente. Por esses fatores, o foco na qualidade é camada inicial e de suporte de
toda a Engenharia de Software, como demonstrado na Figura 1.
É possível observar também que a camada de Processos está diretamente ligada ao
Foco na Qualidade, permitindo que esta seja alcançada através da relação com a camada de
Métodos, que, por sua vez, se apoia na camada de Ferramentas com o mesmo objetivo de
obter recursos que minorem o esforço de execução do processo. A junção dessas três camadas
permite repetitividade, identificação de melhorias continuamente, caracterização de gargalos,
reuso de práticas e artefatos, e, ainda, uma aplicação sistemática para obtenção de um
determinado padrão de qualidade esperado e definido pelo nível de maturidade
organizacional.
Conforme Pressman (2011), entende-se por princípios de Engenharia de Software:
Os princípios da Engenharia de Software constituem a base dos métodos,

tecnologias, metodologias e ferramentas adotadas na prática e que norteiam a prática
de desenvolvimento de soluções de software. Os princípios se aplicam ao processo e
ao produto de software se tornando em prática de desenvolvimento de software
através da adoção de métodos e técnicas. Geralmente, métodos e técnicas constituem
uma metodologia, as quais são apoiadas pela utilização de ferramentas.
(PRESSMAN, 2011, p. 46)
Segundo Purri (2006), a Engenharia de Software representa o estabelecimento de

princípios científicos em conjunto com métodos para a implementação eficaz de processos,
técnicas e ferramentas para a construção do produto de software.
Porru et al. (2017, p. 45) citam que, dentre os principais desafios a serem enfrentados
pela Engenharia de Software no contexto de softwares orientados a cadeia de blocos
(Blockchain), estão:
a) Necessidade de engenheiros de software capacitados para elaborar ferramentas e

técnicas especializadas para orientações de cadeias de blocos.
b) Definição de novos papéis profissionais.
c) Especialização das atividades de testes buscando maior rigorosidade e
segurança. Principalmente no contexto dos requisitos não funcionais.
d) Definição de novas ferramentas para a arquitetura de software orientada a
Blocos e contratos inteligentes.
e) Propor novos caminhos a partir da análise de repositórios de códigos
compartilhados de aplicações orientadas a blocos.
Neste contexto, o foco deste trabalho é contribuir com a minimização desses desafios a
partir da proposição de instrumentos e ativos, estruturados em um processo de
26
desenvolvimento de softwares que possam ser utilizados por empresas preferencialmente do

tipo startups para desenvolvimento de aplicações orientadas a blocos.
2.1.3 Processo de software
Derivado da Engenharia de Software, existem diversas definições sobre o conceito de

processo de software. Sommerville traz inicialmente a definição de processo como " O
processo é um conjunto de atividades e resultados associados que produzem um produto de
software ". (SOMMERVILLE, 2006).
Pressman (2011) expõe o conceito de processo como “[...] um conjunto de atividades,
ações e tarefas realizadas na criação de algum produto de trabalho”.
Jalote (2005, p. 114) determina que um processo de software é:
[...] é um conjunto de atividades, ligadas por padrões de relacionamento entre ela,

pelas quais se as atividades operarem corretamente e de acordo com os padrões
requeridos, o resultado desejado é produzido. O resultado desejado é um software de
alta qualidade e baixo custo. Obviamente, um processo que não aumenta a produção
(não suporta projetos de software grandes) ou não pode produzir software com boa
qualidade não é um processo adequado.
Pinheiro (2008) defende que um processo de software pode ser entendido como um
framework para as tarefas que são necessárias à construção de um software de alta qualidade.
Como objeto deste trabalho, buscamos desenvolver uma abordagem de processos que
minorem os esforços e favoreçam o desenvolvimento de produtos de software que utilizem
Cadeia de blocos (Blockchain). Entendemos que não existe processo ideal, principalmente a
diferentes contextos e necessidades a serem atendidas; sendo assim, as organizações devem
criar e adaptar seus métodos, técnicas e ferramentas à sua realidade produtiva. (CMMI,2013).
Temos como foco, através de uma experiência de uso prático, mapear as dificuldades
de desenvolver softwares utilizando Cadeia de blocos – SOB – e propor um arcabouço de
processo que possa ser adaptado e utilizado como base para desenvolvimento e validação de
ideias de produtos de software até a definição do mínimo produto viável no cenário de
empresas startups.
2.1.4 Metodologia Lean

27
A metodologia Lean, também conhecida como Lean Thinking, traduzida para o

português como “pensamento enxuto”, ganhou destaque na literatura acadêmica ocidental
durante meados dos anos 1980, como resultado do aumento da curiosidade em torno do
“segredo” de técnicas de fabricação japonesas práticas e do Sistema de Produção Toyota em
particular. (PEGELS, 1984 apud EMERALD, 2015).
Os cinco princípios amplamente aceitos no estabelecimento do pensamento enxuto, de
acordo com Kollberg et al. (2007), são listados na Figura 2.
Figura 2 – Princípios do Pensamento Enxuto.
Fonte: Lean IT (2017).
a) Agregar valor ao cliente: essa é a premissa básica para começar a desenvolver

algo: deixar o cliente definir o que é valor em seu produto. Muitas empresas,
principalmente as startups, falham nesse ponto, vão à falência ou não obtêm
sucesso porque o produto desenvolvido não atende às necessidades do cliente-
alvo. Em alguns casos ocorre até a identificação errônea ou prematura de quem é
o seu real cliente.
b) Mapeamento do fluxo de valor: o foco deve ser no que agrega valor, é
necessário identificar quais etapas agregam valor ao produto e o que ficar fora
desse contexto (desperdício) deve ser eliminado, reduzindo automaticamente os
custos (Figura 3).
28
Figura 3 – Exemplo de mapeamento do fluxo de valor
Fonte: Lean TI (2017).
c) Criar fluxo contínuo: após identificadas as tarefas que agregam valor ao

produto, deverá ser criado o fluxo contínuo, ou seja, produzir sem interrupções
ou refluxo. Deve-se buscar atender às necessidades dos clientes com rapidez e
baixo estoque. Esse é o princípio mais desafiador.
29
Figura 4 – Ilustração de Fluxo de Contínuo Lean
Fonte: Sustentare (2014).
d) Produção puxada: nessa etapa, a empresa passa a trabalhar produzindo apenas o

que o cliente solicitou, reduzindo ao máximo o estoque. A produção puxada, que é
um dos pilares do JustinTime (JIT), idealizado por Kiichiro Toyota, tem como
metáfora o sistema puxado do Supermercado: onde o estoque é reposto apenas
para os itens vendidos, evitando acúmulo de estoque. Trazendo para o contexto de
software, com a produção puxada elimina-se o risco de produzir funcionalidades
que não estão em uso no sistema ou que não agregam valor de fato, reduzindo o
custo de manutenção e o risco de problemas por funcionalidades que não
evoluíram em conjunto com o restante do produto por não agregarem valor de
verdade ao cliente.
e) Buscar a perfeição: É a melhoria contínua pregada pelo CMMI (2013), que deve
ser focada em toda a cadeia, ou seja, em processos, pessoas, produtos, etc., com
foco no valor agregado ao cliente.
2.1.4.1 Lean Startup
A concepção de um novo negócio embasado em um produto ou serviço inovador é

geralmente acompanhada de incertezas quanto ao sucesso da ideia e futuro da empresa,
tornando-se desafiador traçar estratégias confiáveis de previsão de desempenho no mercado
para um espaço de anos à frente do momento em que se concebe o plano de negócios,
30
semelhante às características demonstradas previamente no contexto da criação de um

software. (BOUFLEUR; NESTOR; FRANCO, 2016).
A metodologia Lean Startup, criada por Eric Ries e derivada do pensamento enxuto
(Lean Thinking), introduziu a ideia de rejeição ao planejamento de longo prazo e abraça a
experimentação e aprendizagem iterativa. Muitos estudos vêm ocorrendo baseando-se nessa
metodologia para a área de empreendedorismo, principalmente no contexto de
desenvolvimento de produtos de software. (RIES, 2011).
De acordo com o fundador, “[...] Lean startup é um conjunto de processos usados
por empreendedores para desenvolver produtos e mercados, combinando desenvolvimento
ágil de software, desenvolvimento de clientela (Customer Development) e plataformas
existentes de software”(RIES, 2011).Pode ser considerada como o pensamento enxuto voltado
para o empreendedorismo, conforme define o autor. As práticas do modelo Lean Startups e
tornaram amplamente adotadas por Startups no Brasil. (RIBEIRO, 2014)
A iniciativa Lean Startup está baseada no conceito de loop de feedback, onde se prega
que, através da criação e liberação de protótipos rápidos, é possível validar ideias e hipóteses
de mercado através do envolvimento do cliente na construção do produto. O ciclo de
concepção e desenvolvimento do produto podem ser observados na Figura 5, que representa o
laço de aprendizagem definido na metodologia.
Figura 5 – Circuito de Reação
Fonte: Blog do Nei (2012).

31
O autor define um ciclo em três fases diferentes. Na primeira fase, denominada

CONSTRUIR, cabe à empresa/startup a construção da versão inicial do produto, ou seja, uma
versão funcional que possa validar as primeiras hipóteses. Geralmente essa versão é
denominada Produto Minimamente Viável (MVP). Esta etapa encerra com a apresentação do
produto ao cliente. Após o término da etapa anterior, a empresa/startup pode MEDIR se os
esforços desenvolvidos estão conduzindo a empresa para o rumo correto de concepção do
produto, ou se a empresa está caminhando de forma regressiva ou está presa em métricas de
vaidade. A empresa/startup pode, a partir deste momento, APRENDER com as métricas
elaboradas na fase anterior e saber se deve continuar com a implementação do produto ou se
será necessário elaborar um pivô e reiniciar o Circuito de Reação. (RIES, 2012)
Para melhor esclarecimento, detalhamos os conceitos e as técnicas utilizadas no
Circuito de Reação, conforme definido pelo autor:
a) Produto minimamente viável: Um produto minimamente viável (MVP) é a “[...]

versão de um novo produto que permite à equipe coletar a quantidade máxima de
aprendizagem validada por clientes com o mínimo esforço”. Tem como objetivo
testar hipóteses de negócios e apoiar os empreendedores a começarem o processo
de aprendizagem o mais cedo possível. Geralmente a visão desta técnica é: “erre
cedo e aprenda rápido”.
b) Desenvolvimento contínuo: Desenvolvimento contínuo é um processo “[...] onde
todo código que é escrito para uma aplicação é imediatamente implantado em
produção”, o que resulta em uma redução do tempo de ciclo e da probabilidade de
retrabalho.
c) Testes A/B: Com visão experimental, o Teste A/B é um método no qual “[...]
diferentes versões de um produto são oferecidas aos clientes, ao mesmo tempo”.
O objetivo deste teste é observar as mudanças no comportamento entre os dois
grupos e medir o impacto de cada versão. Os resultados podem ser combinados
para geração de uma nova versão do produto.
d) Métricas de vaidade: Métricas de vaidade são medidas do tipo: usuários
cadastrados, downloads e acessos ao website. Essas métricas podem mascarar os
reais problemas relacionados ao negócio. Elas dão “[...] a imagem mais otimista
possível” e não têm necessariamente correlação com os números que realmente
importam para o negócio (chamados de métricas acionáveis), como envolvimento,
custos de aquisição de usuário, usuários ativos, lucro obtido, dentre outras.
32
e) Pivô: Um pivô é uma “[...] correção de curso estruturado para testar uma nova
hipótese fundamental sobre o produto, estratégia ou motor de crescimento”. É
extremamente importante saber mudar de curso quando necessário. (RIES, 2012,
p. 67)
Neste contexto e dado que as iniciativas de produtos em cadeia de blocos (Blockchain)

ainda estão no caminho das ideias e com um amplo mercado a ser explorado, a metodologia
também serviu de base para a construção do processo que foi produto deste trabalho.
2.1.4.2 Lean Development (Desenvolvimento Enxuto)
A Tecnologia da Informação (TI) é um dos maiores propulsores de mudança na forma

como as empresas agregam valor a seus clientes e aumentam sua produtividade, mas é
também uma das maiores fontes de desperdício. Basta um olhar mais detalhado para os
processos e ficam evidentes os inúmeros retrabalhos, custos desnecessários, horas excedentes,
atrasos, usuários e clientes insatisfeitos. (LIB, 2015)
De acordo com Peter Drucker, em algumas de suas citações, o único propósito de um
negócio é servir ao cliente, e a única fonte de lucro real é o cliente. Nesta visão, o
Desenvolvimento Enxuto não é sobre o processo de desenvolvimento em si, mas sobre como
usá-lo para criar valor para os clientes. Assim, não se trata de uma metodologia de engenharia
de software no sentido convencional. É realmente uma síntese de um sistema de práticas,
princípios e filosofia para a construção de sistemas de software para o uso de um cliente.
(MARY; TOM, 2003)
Na busca de obter princípios básicos a serem seguidos pela Engenharia de Software,
durante o processo de desenvolvimento de produtos, Mary e Tom (2003) estruturaram sete
princípios no livro Lean software development, sendo eles:
a) Eliminar o desperdício: "desperdício" é qualquer coisa que não adicione

diretamente valor ao cliente ou adicione conhecimento sobre como entregar esse
valor de forma mais eficaz. Esse desperdício pode ser originado de tarefas
parcialmente completas, defeitos, funcionalidades adicionais, compartilhamento
de recursos, espera ocupada ou até comunicação ineficiente. É importante que
esteja claro para toda a equipe o conceito de “Pronto” e o fluxo de valor, definidos
no início do processo.
33
b) Fortalecer o time: Empoderar as pessoas, encorajar o trabalho em equipe e mover

a tomada de decisões ao nível mais baixo possível são fundamentais para qualquer
implementação enxuta. Deve-se criar um ambiente de trabalho saudável, com uma
equipe auto gerenciada e buscar-se evitar a micro gestão.
c) Entregas rápidas: Em muitos ambientes de desenvolvimento lean, os
lançamentos de produção ocorrem frequentemente, semanalmente e diariamente
de forma contínua, visando entregar valor o mais rápido possível ao cliente.
d) Otimizar o todo: Entender a relação do software como um produto completo e
não apenas como soma das partes e buscar entender seu contexto e alimento aos
objetivos estratégicos da empresa.
e) Construir qualidade: Significa desenvolver o software baseando-se em boas
práticas testadas e validadas no mercado, integração contínua, testes unitários,
testes automatizados e desenvolvimento orientado a testes.
f) Adiar decisões: Deixar para tomar decisões no momento oportuno e com o
máximo de informações coletadas e analisadas a respeito.
g) Amplificar conhecimento: Buscar sempre aprendizado nas novas experiências,
através do incentivo ao feedback entre equipes e cliente. A evolução deve ser
perseguida diariamente.
Esses princípios são usados para enquadrar a discussão sobre quais práticas de
desenvolvimento de produtos de software podem ser apropriadas, dependendo da situação
única de cada organização. Neste trabalho, buscamos observá-los no contexto restrito de
empresas startups do ramo de desenvolvimento de software, analisando como poderiam
contribuir para o sucesso dessas organizações respeitando seus limites, características e
restrições.
2.2 INFRAESTRUTURA TECNOLÓGICA BLOCKCHAIN
2.2.1 Cadeia de Blocos (Blockchain)
Proposta por Satoshi Nakamoto como solução para o problema de gasto duplo ao se
utilizar a criptomoeda Bitcoin, a cadeia de blocos (Blockchain) é um sistema de livro-razão
descentralizado que usa um consenso de rede para gravar e executar transações. É mais
34
conhecida como a plataforma para a web moeda bitcoin, que atualmente está revolucionando
os serviços financeiros.
No entanto, a cadeia de blocos (Blockchain) recentemente chamou a atenção de um
número crescente de líderes empresariais, reconhecendo que a tecnologia subjacente desta
arquitetura transformacional pode ser aplicada a quase qualquer indústria. (CONLLINS,
2017)
Essa arquitetura de sistemas provavelmente revolucionará a maneira como
construímos sistemas de TI e tem o potencial de minimizar algumas atividades de pirataria e
fraude. Essa ideia simples e elegante, através de sua capacidade inovadora, tem a
possibilidade de mudar nossa noção inteira da empresa, da economia e toda a sociedade.
(CONLLINS, 2017; MURRAY, 2015)
A tecnologia Blockchain pode ser entendida das mais variadas formas. Em geral,
podemos dizer que se trata de um sistema distribuído de base de dados em log, mantido e
gerido de forma compartilhada e descentralizada (através de uma rede peer-to-peer: P2P), na
qual todos os participantes são responsáveis por armazenar e manter a base de dados, sendo
eles responsáveis por toda a informação aceita como verdadeira que gera um novo bloco em
cadeia. (CPQD, 2017)
Um banco de dados de blocos consiste em dois tipos de registro: transações e
blocos. Os blocos possuem lotes de transações válidas que são esmagadas e codificadas em
uma árvore Merkle. https://en.wikipedia.org/wiki/Blockchain - cite_note-te20151031-1Cada
bloco inclui o hash do bloco anterior na cadeia de blocos, ligando os dois. Os blocos ligados
formam uma cadeia. Este processo iterativo confirma a integridade do bloco anterior, todo o
caminho de volta ao bloqueio original da gênese. Algumas cadeias de bloqueio criam um
novo bloco a cada cinco segundos.
A Figura 6 ilustra o funcionamento padrão de uma transação ocorrida em uma rede de
cadeia de blocos (Blockchain). (CUCCURU,2017)
35
Figura 6 – Funcionamento de uma transação na Cadeia de blocos (Blockchain)
Fonte: Insider PRO (2017)
2.2.1.1 Características
A tecnologia foi construída tendo por base quatro principais características

arquiteturais: “[...] segurança das operações, descentralização de armazenamento/computação,
integridade de dados e imutabilidade de transações”. (CPQD, 2017, p. 24).
A característica mais distintiva da Cadeia de blocos (Blockchain) é que nenhum agente
único possui capacidade de executar o controle sobre a atividade do sistema. (COLLINS,
2017)
36
Outra característica da cadeia de blocos é que a informação armazenada é tanto

transparente como privada, o que faz uma arquitetura perfeita para o IoT(Internet das Coisas).
Isso é conseguido separando verificação de identidade da validação da transação. Assim,
todos os atributos de uma pessoa particular podem ser conhecidos sem que se conheça sua
identidade. Isso é possível porque a cadeia de blocos (Blockchain) emprega avatares como
uma informação do mecanismo de processamento para preservar a privacidade individual.
(COLLINS, 2017)
Outro ponto relevante é que, como a cadeia de blocos (Blockchain) não usa arquivos
centralizados, se os intrusos rastrearem o caminho de uma cadeia no sistema, os dados
distribuídos são ininteligíveis. Eles são impedidos de causar danos porque não podem realizar
nenhuma ação de mudança na cadeia sem aprovação de um consenso da rede de cadeias de
blocos. (COLLINS, 2017)
Outra característica do blockchain proposto por Nakamoto é que o mesmo deveria ser
robusto a adulterações, e qualquer tentativa de fraude no livro-razão existente seria facilmente
detectada por todos os usuários da criptomoeda Bitcoin. Para obter esta robustez a
modificações, os elementos do livro-razão são ligados entre si, formando uma cadeia.
(LUCENA, 2016)
A tecnologia Cadeia de blocos (Blockchain) usa tecnologia de chave pública-privada
(PKI Criptografia), por isso é razoavelmente seguro de fraude, roubo e corrupção, mas o
anonimato nunca é cem por cento garantido. (MURRAY, 2015)
2.2.1.2. Principais aplicações
Blockchain possui diversos cenários de aplicação, os mais citados na literatura são:
a) Sistemas financeiros: A aplicação de Blockchain no sistema financeiro traz uma

mudança cultural no setor: a não necessidade das câmaras integradoras que
servem para validação de transações financeiras, o que poderia gerar grande
economia aos bancos e instituições financeiras. (COLLINS, 2017)
b) Gestão de identidade pessoal: A cadeia de blocos (Blockchain) também é
extremamente poderosa quando se trata de vítimas de roubo de identidade ou
preservação de dados pessoais. Usando a segurança da blockchain, podemos
realizar transações protegendo a identidade dos envolvidos e permitindo que
37
possamos possuir diferentes avatares e utilizá-los em seus contextos específicos,

isolando a vida profissional da vida pessoal. (MARVIN, 2017)
c) Direitos autorais de arquivos e mídias: A popularização da internet provocou
grandes perdas financeiras à indústria fonográfica. Ouso de blockchain na
distribuição de conteúdo multimídia poderá fazer com que qualquer arquivo de
música ou filme possa ser utilizado apenas pelo dono de determinado nó,
impossibilitando a cópia e distribuição gratuita do arquivo para outras pessoas. A
venda de um arquivo de mídia seria a transferência do mesmo para o domínio de
outra chave pública pertencente a outro usuário dentro da rede blockchain, de
forma similar ao que ocorre com a transferência de uma criptomoeda. (MARVIN,
2017)
d) Votação eletrônica segura: Os principais modelos atuais de votações eletrônicas
são centralizados, e a totalização dos votos é normalmente realizada após a
transferência do conteúdo da memória de cada urna para o órgão controlador da
eleição. Assim, abre-se espaço para a adulteração do resultado dos votos antes de
sua transferência para o órgão controlador, e, caso este órgão não seja imparcial,
ele mesmo poderá participar em uma adulteração. (LUCENA, 2016)
2.2.2 Contratos inteligentes
A propriedade e as características de qualquer bem ou dados podem ser digitalizadas e

representadas por um código de computador. Propriedades intangíveis, direitos, dados
pessoais, certificados, testamentos, saldos comerciais: qualquer informação pode ser incluída,
armazenada e protegida em uma cadeia de blocos. Não só isso, mas relacionamentos
envolvendo esses ativos podem ser programados por computador, e sua execução é aplicada
através dos nós de um bloco sem intermediários. Essas operações são geralmente
denominadas “contratos inteligentes”, ou seja, protocolos de computador que formalizam os
elementos de uma relação contratual, sendo capaz de executar automaticamente os termos
nele codificados, uma vez que as condições pré-definidas são atendidas. (CUCCURU,2017)
Um contrato inteligente pode ser entendido como um protocolo de computador feito
para facilitar, verificar ou reforçar a negociação ou desempenho de um contrato, sendo capaz
de ser executado ou de se fazer cumprir por si só, quando atendida uma condição pré-definida.
A implementação do contrato não deve requerer envolvimento humano direto a partir do
momento em que o contrato foi firmado. (SZABO,1997).
38
A Figura 7 ilustra o funcionamento de um contrato inteligente, ressaltando o acordo

existente entre as partes.
Figura 7 – Funcionamento de contratos inteligentes
Fonte: Insider PRO (2017).
Neste trabalho, focamos em contratos inteligentes desenvolvidos em plataforma

Cadeia de blocos (Blockchain), utilizando-se da segurança e descentralização das transações
fornecida pela cadeia de blocos.
Contratos inteligentes seguem aproximadamente o esquema “se x, então y”. A
formalização das relações digitais em livros contábeis distribuídos ou cadeia de blocos
(Blockchain) seria ideal para reduzir o risco de descumprimento que qualquer regra firmada
em um acordo, promovendo segurança no comércio on-line. Isso ocorre porque a
responsabilidade fica com a própria rede de cumprir os termos da relação: uma vez que o
protocolo (ou seja, o contrato inteligente) é lançado no bloco, torna-se "independente" da
vontade das partes, seguindo nada além de suas instruções de auto execução nas condições
nele codificadas. (MAGAZZENI; MCBURNEY; NASH, 2017).
39
Os contratos tradicionais são basicamente assistidos, na sua execução, por vinculação

legal. Como tal, eles são naturalmente sujeitos a um certo grau de incerteza, como considera
os seus resultados finais: as partes podem voluntariamente ignorar suas promessas – ou seja, a
“lei” pode ser violada – e / ou tribunais e árbitros são convidados a modificar, invalidar ou
fazer cumprir as obrigações assumidas.
Assim como os contratos tradicionais, os contratos inteligentes se aplicam a diversos
setores, vindo a facilitar as transações ocorridas entre partes em diversos segmentos e gerando
a redução ou exclusão da intermediação dessas relações contratuais. A Figura 8 apresenta de
forma breve as principais vantagens da utilização desta aplicação tecnológica em problemas
de mercado.
40
Figura 8 – Vantagens de um contrato inteligente
Fonte: Insider PRO (2017).
Como toda tecnologia, também existem desvantagens na utilização de contratos

inteligentes, como defeitos de código que podem gerar decisão errônea e imutável do
contrato, comprometendo a segurança e a precisão deste. A principal delas está associada ao
aspecto legal: não existe hoje na legislação brasileira aparato legal para a utilização de
contratos inteligentes. Sugere-se então que, juntamente a solução tecnológica que implementa
o contrato inteligente, seja feito um contrato formal e reconhecido nos órgãos competentes
41
entre as partes, onde devem ser documentadas as sanções a serem aplicadas em caso de não
cumprimento das regras do contrato. (MAGAZZENI; MCBURNEY; NASH, 2017).
2.2.3 Bitcoin
Não é interessante falar de cadeia de blocos (Blockchain) sem citar o protocolo

Bitcoin que proporcionou mais evidência a esta tecnologia. Conforme difusão de mercado,
Bitcoin é uma moeda digital que fornece uma plataforma segura e de baixo custo para
pagamentos eletrônicos.
Desenvolvido por Nakamoto (2009) como uma alternativa anônima ao sistema
bancário centralizado, a rede Bitcoin foi lançada em 2009 e tem crescido consideravelmente
nos últimos anos. Desde então, goza de uma ampla adoção; por exemplo, em julho de 2015 o
limite de mercado de Bitcoins circulantes excedeu US$ 4 bilhões. (HENDRICKSON;
HOGAN; LUTHER, 2015).
Bitcoin é mais bementendido como uma rede peer-to-peer descentralizada e
distribuida que acompanha todas as transferências de dinheiro entre seus usuários. Todas as
transferências são agrupadas em blocos e registradas em um público ledger (livro-razão), a
cadeia de blocos (Blockchain), que contém, assim, a história completa das transações Bitcoin
aceitas.O bloco está constantemente sendo validado pelos participantes da Bitcoin. Adicionar
um novo bloco à cadeia de blocos (Blockchain) requer uma prova de trabalho, de modo que
adultarerar a cadeia de blocos em um ponto anterior exigiria refazer todas as provas de
trabalho para os blocos sucessores, o que demandaria grande capacidade computacional. Isso
protege contra adulterações e resolve o problema do gasto duplo, onde o mesmo dinheiro é
gasto mais de uma vez, ou seja, ocorre o crédito do credor, porém não ocorre o débito da
pagador, duplicando-se o poder de pagamento de um Bitcoin. (ZIEGELDORF et al., 2016)
Para acompanhar os saldos e estabelecer confiança na moeda, todas as transações
Bitcoin são armazenadas em um livro público distribuído, a cadeia de blocos, em vez de usar
entidades centralizadas, por exemplo, bancos ou câmaras integradoras. Para receber,
armazenar e gastar Bitcoins, os usuários mantêm na criptografia identidades chamadas
endereços, que correspondem a chaves públicas e privadas geradas através do Algoritmo de
Assinatura Digital de Curvas Elípticas (Elliptic Curve Digital Signature Algorithm –
ECDSA). As transações são anônimas desde que os endereços não possam ser associados aos
seus proprietários, o que geralmente é assegurado pela aleatoriedade das transferências na
Cadeia de blocos (Blockchain). Diferentemente de instituições financeiras, as transações
42
também não são ligadas à identidade dos usuários. Desse modo, desde que um minerador
inclua a transação na cadeia de blocos, qualquer pessoa pode transferir Bitcoins de forma
eficaz a partir de qualquer endereço que controle a chave (privada) para qualquer outro
endereço, sem a necessidade de revelar quaisquer dados pessoais. Semelhante ao dinheiro
físico, nem mesmo o destinatário precisa saber a identidade do remetente. (ZIEGELDORF et
al.,2016)
Como podemos ver na Figura 9, uma transação Bitcoin possui um ciclo de vida,
conforme ilustrado no exemplo abaixo:
Figura 9 – Ciclo de vida de uma transação bitcoin
Fonte: Astarlabs (2017).
O protocolo Bitcoin processa transações sobre uma rede distribuída usando tecnologia
criptográfica de chaves público-privadas. Quando um remetente transfere fundos para um
destinatário usando o cliente Bitcoin em uma transação, o pedido é gerado. O remetente
confirma o acesso para que os fundos sejam enviados com sua chave privada e identifica o
destinatário por sua chave pública. Por sua vez, o pedido de transação é assinado com a chave
privada de um remetente, e qualquer pessoa na rede pode usar a chave pública do remetente
43
para verificar se o legítimo titular da conta aprovou o pedido. O pedido de transação é

incluído em um bloco com outras transações realizadas. Todos os usuários que executam
efetivamente o cliente Bitcoin (mineradores) vão competir para processar o bloco de
transações. Isso envolve resolver um complicado problema de criptografia, que basicamente
equivale a uma busca de força bruta para uma sequência de caracteres essencialmente
aleatórios (Mineração).
A solução para o problema de criptografia certifica que o bloco de transação que está
sendo processado é consistente com o bloco existente com um registro público de todas as
transações passadas. Uma vez identificada a solução, a rede pode bloquear o bloco e outros
seis usuários verificam a solução (Consenso); assim, a cadeia de blocos é modificada para
refletir as transações referenciadas no bloco processado. O destinatário pode agora utilizar sua
chave privada para gerar novas transações, transferindo os fundos recentemente recebidos
para outra pessoa. Processando transações desta maneira, garante-se que um usuário não gaste
o mesmo valor duas vezes sem depender de uma central autoridade da câmara de
compensação. Os usuários que executam o cliente Bitcoin são recompensados sempre que
forem os primeiros a processar com êxito um bloco de transações. A recompensa vem em
forma de Bitcoin recém-criado, conhecido como a moeda. (HENDRICKSON; HOGAN;
LUTHER, 2015).
O protocolo Bitcoin varia a dificuldade em processar o bloco de transações para
garantir que, em média, um bloco seja processado a cada 10 minutos. O número de moedas é
cortado pela metade a cada 210.000 blocos (ou, aproximadamente, 4 anos). Como tal, a oferta
total de Bitcoin em circulação cresce a uma taxa previsível, aproximando-se assintoticamente
de 21 milhões. O último Bitcoin está programado para entrar em circulação em setembro de
2140. (HENDRICKSON; HOGAN; LUTHER, 2015).
As transações Bitcoin são executadas através de blocos encadeados e relacionados de
forma descentralizada e aleatória, sendo interligados por endereços hash que apontam para o
próximo bloco válido da cadeia – a esta tecnologia dá-se o nome de cadeia de blocos
(Blockchain). Esta tecnologia que possui inúmeras aplicações, sendo Bitcoin apenas uma de
suas formas de implementação, é o foco principal de estudo deste trabalho.
2.3 STARTUP
O empreendedorismo moderno, nascido há mais de trinta anos, foi impulsionado pelo

advento dos mercados de consumo da Internet. Hoje, com a onipresença da Internet e dos
44
dispositivos móveis, o mercado possui suporte técnico para uma proliferação contínua de
empreendimentos de software. (GIARDINO, 2016).
De fato, o acesso fácil a mercados potenciais e o baixo custo de distribuição de
serviços são condições atraentes para empresários modernos. Inspiradas em histórias de
sucesso, um grande número de empresas de software é criado todos os dias, sendo
denominadas no contexto empresarial como Startups. Contudo, a grande maioria dessas
empresas falha dentro de dois anos a partir de sua criação. (GIARDINO, 2016).
As startups de software enfrentam intensa pressão do tempo do mercado e estão
expostas a competições (Hacktons) operando em um contexto caótico, em rápida evolução e
incerto. A escolha dos recursos corretos para construir e se adaptar rapidamente a novos
pedidos, ao serem desafiadas pela realidade de limitação de recursos, é crucial para o sucesso
neste ambiente. (RIES, 2012). Startups compartilham características em comum com outros
contextos empresariais, como pequenas empresas, e apresentam uma combinação de
diferentes fatores que tornam o ambiente de desenvolvimento de software diferente das
demais empresas estabelecidas. (GIARDINO, 2016).
Sutton (2017) fornece uma caracterização das Startups de software definidas pelos
desafios que enfrentam:
a) Pouco ou nenhum histórico operacional – Por seu contexto inovador, as startups

têm poucos ou nenhum dado acumulado para apoiar decisões.
b) Experiência em processos e organização de desenvolvimento– Geralmente, as
startups são idealizadas por jovens que buscam resultados rápidos e pouca
burocracia.
c) Recursos limitados – As startups geralmente se concentram em obter o produto,
promovendo-o e elaborando estratégias através de alianças com investidores.
d) Várias influências – Pressão de investidores, clientes, parceiros e concorrentes
influenciam a tomada de decisões em uma Startup. Embora individualmente
importantes, em geral eles podem ser inconsistentes, o que pode gerar decisões
errôneas.
e) Tecnologias e mercados dinâmicos – As empresas geralmente precisam
desenvolver ou operar com visão inovadora, vencendo problemas e limitações
tecnológicas para entrar em um mercado de alto potencial alvo.
45
A implementação de metodologias para estruturar e controlaras atividades de

desenvolvimento em startups são um grande desafio para engenheiros. Em geral, a gestão do
desenvolvimento de software é obtida através da introdução de processos de software, bem
como da definição de um conjunto coerente de políticas, estruturas organizacionais,
tecnologias, procedimentos e artefatos que são necessários para conceber, desenvolver,
implantar e manter um produto de software. (GIARDINO, 2016).
O processo de abertura de uma empresa do tipo startup é basicamente dividido em
cinco etapas, podendo estas serem subdivididas entre as etapas teóricas e as práticas. Nas
etapas teóricas, estão a iniciativa da ideia e a identificação das oportunidades. Na parte prática
estão a descoberta e a validação de clientes. Como suporte a tudo está o plano de negócios
que viabiliza a startup. A Figura 10 demonstra as macro atividades de um processo de
abertura de um startup. (YAGIMA, 2012).
Figura 10 – Macro atividades de um processo de abertura de startup
Fonte: IME-USP apud Yagima (2012).
Nesta pesquisa, atuaremos apenas nas etapas práticas, pressupondo que a startup já
existe e possui modelo de negócio desenhado. Para a etapa de descoberta de clientes,
utilizaremos o suporte da técnica de personas e cenários, e a validação do cliente será apoiada
pelo processo a ser proposto e acompanhado por indicadores.
No contexto de Startups, a engenharia de software enfrenta desafios complexos e
obstáculos multifacetados na compreensão de como gerenciar o desenvolvimento de software
nesse contexto. As Startups são criativas e flexíveis na natureza e relutam em introduzir
medidas processuais ou burocráticas que podem dificultar os seus atributos naturais. Além
disso, startups têm recursos muito limitados e normalmente desejam usá-los para
desenvolvimento de produtos em vez de estabelecer processos. Algumas tentativas de adaptar
processos leves a startups tiveram relatos de falha básica de sua aplicação. Rejeitando a noção
de processos repetitivos e controlados, startups buscam obter vantagem através do contexto de
46
construção rápida e validação breve e contínua; por isso, muitas utilizam o jargão de mercado
“Erre cedo e aprenda rápido”. (GIARDINO, 2016).
As práticas orientadas a produto ajudam as operações iniciais a terem uma equipe,
com fluxos de trabalho que lhes trazem a capacidade de mudar rapidamente a direção de
acordo com o mercado-alvo. Assim sendo, muitas empresas startups se concentram na
produtividade da equipe, buscando mais controle dos funcionários em vez de fornecer-lhes
orientações rígidas. (GIARDINO, 2016).
Outro aspecto peculiar que influencia o desenvolvimento de software no contexto
orientado para o mercado (Startups) está relacionado aos requisitos do produto, que são
relatados como sendo frequentemente inventados pelos desenvolvedores de software, e
validados somente depois que o produto é lançado no mercado. Sob estas circunstâncias, a
falha no lançamento de produtos deve-se principalmente a produtos que não satisfaçam as
necessidades dos clientes. (GIARDINO, 2016).
Neste capítulo, apresentamos as bases metodológicas que serviram como pilar para
abordagem do processo. Citamos, ainda, as iniciativas de difusão da tecnologia Cadeia de
blocos (Blockchain) que possuem objetivo relacionado a este trabalho.
47
3 EXPERIÊNCIA DE USO NO DESENVOLVIMENTO DE SOFTWARE

UTLIZANDO-SE CADEIA DE BLOCOS (BLOCKCHAIN)
3.1 CARACTERIZAÇÃO DA EXPERIÊNCIA DE USO
3.1.1 Motivação
Analisando a literatura e as iniciativas atuais de mercado, é possível compreender a

relevância da tecnologia cadeia de blocos (Blockchain) para o cenário tecnológico atual. A
principal motivação desta experiência de uso foi identificar os principais desafios para
desenvolver aplicações utilizando tecnologia de cadeia de blocos (Blockchain) e propor um
processo que vise facilitar esta tarefa. Com isso, almeja-se, através da aplicação da engenharia
de software, compreender o processo de produção de software neste contexto de cadeias de
blocos e compor um processo de desenvolvimento de software base, orientado ao cenário de
empresas startups. Deste modo, esperamos favorecer a construção de produtos de software em
Cadeia de blocos (Blockchain) e apoiar a difusão da tecnologia no mercado.
3.1.2 Domínio de aplicação
Existe muita polêmica em relação à confiabilidade do voto eletrônico no Brasil.

Segundo os testes públicos realizados pelo TSE no ano de 2002 e 2016, a urna eletrônica
usada no Brasil não é totalmente confiável, estando sujeita a fraudes internas e externas,
comprometendo a segurança das eleições e dificultando a auditoria das alterações por permitir
que rastros sejam apagados. Apesar de os resultados de 2016 serem bem mais motivadores
que os obtidos em 2002, ainda existem muitos desafios de confiabilidade a serem superados
nesse contexto. Este fato pode ser demonstrado com a baixa adesão de países desenvolvidos a
sistemas eletrônicos de votação.
Para este trabalho, selecionamos o contexto que envolve o cadastro do candidato e o
registro do voto pelo eleitor. Com isso, objetivamos demonstrar a proposta de votação segura
e transparente, onde é possível verificar o registro do candidato e do voto de forma pública e
imutável na cadeia de blocos (Blockchain). Um ponto relevante é que isso ocorre sem
exposição da identidade do eleitor.
48
3.2 MATERIAIS E MÉTODOS
3.2.1 Equipe
Para construção do protótipo que serviu como base para esta experiência de uso, a
equipe participante foi composta conforme descrito no Quadro 1.
Quadro 1 – Composição da equipe
Perfil Papel desenvolvido Senioridade
Arquiteto, Codificador, Scrum Master,

Desenvolvedor Web 1 Desenvolvedor Cadeia de blocos (Blockchain), Sênior
Analista de Configuração
Consultor de metodologias ágeis e loop de
Desenvolvedor Web 2 Sênior
feedback de startups
Analista de requisitos, Analista de testes,
Especificadora Sênior
Testadora, Product Owner
Não
Assessor político Cliente
aplicável
Não
Cidadãos Cliente votante
aplicável
Fonte: Elaborado pelo autor.
3.2.2 Metodologia utilizada
Para a construção deste protótipo, foi desenvolvida uma versão inicial do processo
proposto composta das seguintes atividades:
a) Levantar Base teórica: Definição da base metodológica da engenharia de

software a ser utilizada. Obtivemos essa base como fruto da revisão bibliográfica
que envolveu a compreensão dos conceitos de engenharia de software,
metodologia Lean e seus derivados, protocolo Bitcoin e conceitos, estrutura e
aplicações da cadeia de blocos (Blockchain) e conceituação do contexto de
desenvolvimento de software em empresas startups.
49
b) Definir do domínio de aplicação: A escolha se deu com base no cenário atual do

país, onde se discute sobre reforma política e mais segurança no acesso a
informações e a integridade do método eleitoral.
c) Identificar das personas e cenários de uso: A identificação se deu com base nos
cenários identificados para o contexto de um processo de votação simples. Cada
persona foi mapeada com base nas ações e nos objetivos a serem atingidos no
produto gerado. Os cenários de uso foram mapeados com base na visão de valor
de cada persona identificada. O objetivo da utilização da técnica foi
principalmente apoiar a etapa prática de descoberta do cliente, buscando evitar a
falha da startup por identificação errônea do cliente-alvo responsável por validar o
produto.
d) Elaborar os requisitos: Os requisitos funcionais e não funcionais foram
definidos em cartões, consolidados em uma lista e associadas a histórias de
usuários que detalham essas necessidades sob o posto de vista do usuário.
e) Definir a arquitetura do produto: A escolha da arquitetura originou-se das
orientações coletadas na pesquisa bibliográfica e na premissa estabelecida de
utilização de tecnologias livres e que proporcionem segurança e confiabilidade
nas transações, com foco em gerar economia no investimento das empresas
startups.
f) Configurar o ambiente: Para montagem e configuração do ambiente, utilizou-se
apoio de guias coletados na internet e fóruns de discussão.
g) Codificar e testar o protótipo: A codificação foi dividida em dois contextos, a
parte relativa à aplicação web e a parte relativa à cadeia de blocos (Blockchain),
que foi desenvolvida na plataforma Ethereum. Não houve a necessidade de
utilização de banco de dados tradicional. A própria Cadeia de blocos (Blockchain)
serviu de base de dados. Foram utilizadas duas instâncias: uma de teste local e
uma de produção. Os testes foram realizados de forma automatizada.
h) Levantar as dificuldades e especificidades do processo: A técnica utilizada foi
a coleta de métricas, documentação de experiência dos envolvidos através da
técnica de diários de bordo e consolidação em documentos de lições aprendidas.
i) Documentar os resultados obtidos através da construção do processo: A
documentação se deu a partir da definição e documentação do processo definido
com base na experiência de uso e pesquisa bibliográfica.
50
3.3 RESULTADOS E DISCUSSÕES
3.3.1 Base teórica e tecnológica
Após realização de pesquisa bibliográfica, identificamos o arcabouço de teorias e

tecnologias que possibilitaram a construção do processo para desenvolvimento de softwares
orientados à cadeia de blocos (Blockchain). Como resultado, obtivemos o seguinte framework
teórico/tecnológico representado na Figura 11.
Figura 11 – Framework teórico/tecnológico
a) Teóricos:
 Engenharia de software: Especificamente no contexto de tipos de software.

Acrescentando a este trabalho a identificação de um novo tipo, sendo este
definido por softwares orientados à cadeia de blocos (Blockchain).
 Lean Startup: Metodologia utilizada para apoio ao mapeamento do fluxo do
processo (fluxo contínuo, loop de feedback).
 Empresas startups: Tipo de empresa selecionada para o estudo devido ao
conceito de inovação e à necessidade de apoio de pesquisas na área de
processos presente em seu contexto.
51
b) Tecnológicos:
 Cadeia de blocos (Blockchain): Foco principal do trabalho. Tecnologia que

favorece o registro de transações seguras, imutáveis e rastreáveis.
 Ethereum: Plataforma de cadeia de blocos (Blockchain) selecionada para o
estudo, por ser, segundo a literatura, uma das mais indicadas para a
implementação de contratos inteligentes.
 Contratos inteligentes: Servem para automatizar execução de acordo entre
partes sem a necessidade de ação humana. Neste projeto, foram
desenvolvidos na linguagem solidity no contexto deste trabalho por restrição
da plataforma de cadeia de blocos (Blockchain) escolhida, que como já citada
anteriormente foi a Ethereum.
 Bitcoin: Plataforma para implementação de Cadeia de blocos (Blockchain)
bastante conhecida pela moeda virtual que leva o mesmo nome. Utilizado
para comparação e distinção do conceito de Cadeia de blocos (Blockchain) da
moeda virtual.
 Metamask: Plugin do Google Chrome que otimiza o acesso à plataforma
Cadeia de blocos (Blockchain), não necessitando, assim, que o cliente final
possua uma cópia da Cadeia de blocos (Blockchain) instalada em seu
ambiente para interagir com ela.
3.3.2 Requisitos
O processo de levantamento de requisitos se deu de forma evolutiva. Inicialmente,

listou-se de forma breve os requisitos conhecidos para o problema de votação segura no início
da pesquisa, e, em seguida, utilizou-se a técnica de histórias de usuários para documentar os
pontos relevantes para a construção do produto. Para melhor favorecer o cenário de definição
das regras do contrato inteligente, acrescentou-se a técnica de identificação das personas e
cenários envolvidos nos requisitos.
A metodologia SER - Sistema para Elicitação de Requisitos proposta por Holanda
(2010), sugere a execução de atividades específicas para levantamento dos requisitos e
identificação dos usuários, sendo elas: Conhecer o Usuário; Definir Personas; Construir
52
Cenários, Modelar Storyboards, Validar Personas, Comunicar e Acompanhar a equipe.

Utilizamos parcialmente essa metodologia para apoiar o levantamento dos requisitos a serem
desenvolvidos na construção do sistema de votação eletrônica que possibilitou a experiência
de uso da tecnologia Blockchain. As atividades executadas foram: Conhecer o Usuário: No
intuito de apoiar as startups a identificarem mais precisamente o seu cliente para possibilitar
uma validação efetiva do seu produto, realizamos uma pesquisa de mercado com foco em
conhecer as características dos envolvidos em um processo de votação eletrônica; Definir
Personas: Foram mapeadas as personas envolvidas no contexto de uso da aplicação por meio
de entrevistas com a equipe do projeto; Construir Cenários: Mapeamos os principais
cenários de uso do sistema pelas personas envolvidas e documentamos esses cenários através
de histórias de usuários.
3.3.2.1 Requisitos funcionais e não funcionais
Quadro 2 – Lista de requisitos funcionais e não funcionais associados

Código Requisito Tipo
O sistema deverá permitir o registro descentralizado de

RNF01 Não funcional
votos.
O sistema deverá permitir que apenas participantes

autorizados possam registrar votos.
O sistema deverá garantir a transparência e a integridade

da votação.
O sistema deverá permitir o cadastro do contrato da

RF01 Funcional
eleição.
O sistema deverá permitir o cadastro dos candidatos a

RF02 Funcional
serem votados na eleição.
O sistema deverá permitir o registro de votos pelo
RF03 eleitor, sendo apenas um voto e para um único Funcional
candidato por vez.
O sistema deverá permitir o acompanhamento online do

RF04 Funcional
resultado online da votação por todos os envolvidos.
53
3.3.2.2 Personas
A técnica de Personas e Cenários é extremamente importante no contexto de

desenvolvimento de software para startups, pois esta favorece, no contexto de identificação de
personas, um maior esclarecimento dos requisitos a serem atendidos para favorecer a cada
grupo de usuários envolvido.
De acordo com Madeira (2010 apud GUIMARÃES, 2012), as categorias do
framework Persona são: Tipo de usuário; Perfil sociodemográfico; Contexto de uso;
Necessidades; Dificuldades; Atitudes; Características webográficas; Características
tecnológicas; Perfil psicográfico; Características do Uso; e Feedback. Existem grupos de
estudos voltados para a realização de experimentação avançada nesta técnica). Um dos
Grupos de Pesquisa que tem trabalhos desenvolvidos no tema Personas em Engenharia de
Software se encontra na Universidade de Fortaleza (HOLANDA, 2010, NOBREGA, 2011 e
GUIMARÁES, 2012). A Figura 12 representa as personas identificadas no contexto da
realização da experiência de uso.
Figura 12 – Resumo das características das personas identificadas
3.3.2.3 Cenários de uso
O âmbito dos Cenários de Uso antecipa a validação de contextos e comportamentos

sem a necessidade de investimento para construção de um protótipo funcional.
54
 Cenário 1 – Cadastro do contrato eleitoral: neste contexto gestor eleitoral,

realizará o cadastro do contrato na plataforma de votação digital, conforme Anexo
A– Cenários de Uso.
 Cenário 2 – Cadastro dos candidatos: neste contexto gestor eleitoral, realizará o
cadastro dos candidatos na plataforma de votação digital, conforme Anexo A–
Cenários de Uso.
 Cenário 3 – Encerrar cadastro dos candidatos: neste contexto gestor eleitoral,
realizará encerramento do cadastro dos candidatos na plataforma de votação
digital, conforme Anexo A– Cenários de Uso.
 Cenário 4 – Registro de voto: neste contexto, o eleitor realizará o registro do seu
voto na eleição digital, conforme Anexo A– Cenários de Uso.
 Cenário 5 – Encerrar votação: neste contexto, o gestor eleitoral poderá encerrar
o período de votação, não permitindo mais o registro de votos para aquela eleição.
Anexo A– Cenários de Uso.
 Cenário 6– Consultar resultado: neste contexto, o eleitor, assessor político,
gestor eleitoral ou candidato poderá realizar consulta do resultado da eleição em
tempo real na plataforma de votação digital e o registro de cada voto realizado.
Essa consulta poderá ser realizada durante ou depois da votação na plataforma de
registros de transações da Cadeia de blocos (Blockchain) Ethereum através do
código hash gerado para cada alteração efetivada na Cadeia de blocos
(Blockchain).
O registro é apresentado na Figura 13.
Figura 13– Registro de transações

55
3.3.2.4 Interface do sistema

(Blockchain)

(Blockchain).
Figura 16 – Cadastrar Candidato – Permite o cadastro do candidato relacionado com o

contrato de votação na cadeia de blocos (Blockchain).
56
Figura 17 – Cadastrar Candidato – Confirmação do registro do candidato relacionado com o

contrato de votação na Cadeia de blocos (Blockchain).

Figura 18– Registrar voto – Exibição do candidato cadastrado para ser votado.

57
Figura 19 – Encerrar votação – Exibição do resultado da votação.
3.3.3 Definição da arquitetura utilizada
Existem várias redes de Cadeia de blocos (Blockchain) ativas no mercado hoje. Além
da rede do Bitcoin, existem a Ethereum, HyperLedger, Ripple etc., e todas elas funcionam
paralelamente. Para este trabalho selecionamos a rede Ethereum. A escolha se deu como
resultado de pesquisa bibliográfica, onde a rede é citada como uma plataforma bastante
indicada para execução de contratos inteligentes no contexto da cadeia de blocos
(Blockchain). Ela possui uma máquina virtual descentralizada denominada Turing
completude, a Ethereum Virtual Machine (EVM), que pode executar scripts usando uma rede
internacional de nós públicos. Deste modo, é possível desenvolver aplicações que funcionam
exatamente como programadas sem qualquer possibilidade de censura, fraude ou interferência
de terceiros, isso porque o contrato é imutável. (BUTERIN, 2014).
A Figura 20 representa os componentes que foram necessários para a construção desta
experiência de uso.
58
Figura 20 – Representação da arquitetura proposta
Na arquitetura da aplicação descentralizada desenvolvida, pode-se destacar quatro elementos

principais: a aplicação cliente, a aplicação servidor, o plugin Metamask no cliente e a própria
rede de cadeia de blocos (Blockchain).
A aplicação cliente, representada com a letra A na Figura 20, consiste em uma
aplicação web que, assim como qualquer outra, é executada no navegador do usuário. Essa é a
aplicação que o cliente final interage, realizando requisições para a aplicação no servidor e
obtendo respostas dela. A principal requisição da aplicação cliente é a solicitação do contrato
que se deseja interagir, descrita na imagem pela seta de número 1.
A aplicação servidor, representada com a letra B na imagem, além de disponibilizar a
aplicação cliente ao usuário final, é também responsável por compilar o código do contrato
solicitado – descrita na imagem pela seta de número 2 – e enviá-la para a aplicação cliente,
representada na imagem pela seta de número 3.
Recebendo o contrato compilado, a própria aplicação cliente está apta para implantar o
contrato na cadeia de blocos (Blockchain). Após a implantação de um contrato, é possível
realizar chamadas aos métodos públicos deste contrato. A aplicação cliente, nesse caso,
interage com o contrato já disponível na cadeia de blocos (Blockchain) sem a necessidade de
intermédio da aplicação servidor, daí o caráter de aplicação descentralizada.
No entanto, a aplicação cliente depende, no caso dessa arquitetura, do intermédio do
plugin Metamask (disponível apenas para o navegador Google Chrome) para realizar
transações na cadeia de blocos (Blockchain), descritas na imagem através da seta de número
4. Através desse plugin o usuário autoriza ou não transações para a cadeia de blocos
(Blockchain), podendo inclusive gerenciar a conta que deseja utilizar para autorizar
determinada transação, sem a necessidade da instalação de um nó da cadeia de blocos
(Blockchain) localmente. Caso o método chamado do contrato apenas retorne alguma
59
informação, ou seja, não altere o estado da cadeia de blocos (Blockchain), não é necessária a
autorização do usuário, o que torna o processo mais performático.
3.3.3.2 Ambiente de desenvolvimento
Para a interação com a infraestrutura de cadeia de blocos (Blockchain), é necessário se

comunicar com um nó desta. A forma mais direta e segura é utilizar um programa cliente da
plataforma Ethereum, que atua como um nó da cadeia de blocos (Blockchain).
Dentre os vários programas cliente possíveis, foi escolhido para esse experimento a
utilização do programa Parity (https://parity.io/). Ao ser inicializado, o programa sincroniza
todas as transações já realizadas na cadeia de blocos (Blockchain). Essa sincronização pode
demorar bastante tempo, mesmo acessando uma cadeia de blocos (Blockchain) oficial de
teste, pois o nó recém-criado realiza o download de todos os blocos de transação já minerados
e confirmados pela cadeia de blocos (Blockchain).
A criação de uma conta na cadeia de blocos (Blockchain) com a qual deseja-se
interagir é um requisito básico. Neste experimento optou-se por utilizar a cadeia de blocos
(Blockchain) de teste do Ethereum denominada Kovan, por ser a cadeia de blocos
(Blockchain) de teste padrão de nós que utiliza o Parity como cliente. A criação dessa conta
pode ser feita pelo próprio Parity, que fornece um passo a passo para a criação de uma nova
conta logo na primeira utilização. A conta criada consiste na geração de uma chave pública e
uma chave privada. A chave pública consiste em um hash único que identifica o usuário que
realizou determinada transação na cadeia de blocos (Blockchain). Já a chave privada é
utilizada para assinar digitalmente as transações feitas pelo usuário, garantindo a
autenticidade das informações.
Para uma aplicação interagir com a cadeia de blocos (Blockchain), a plataforma
Ethereum desenvolveu uma API em JavaScript denominada Web3
(https://github.com/ethereum/wiki/wiki/JavaScript-API), que internamente se comunica com
um nó da cadeia de blocos (Blockchain) através de chamadas RPC (Remote Procedure Call).
Através da Web3, é possível implantar novos contratos inteligentes (Smart Contracts) e
consumir as funcionalidades expostas por esses contratos. Funcionalidades essas que podem
inclusive chamar outros contratos já existentes na cadeia de blocos (Blockchain).
Para que a aplicação cliente se comunique com a cadeia de blocos (Blockchain) sem a
necessidade de um nó da cadeia de blocos (Blockchain) instalado localmente, como o Parity,
é possível a utilização do plugin Metamask (https://metamask.io/) do navegador Google
60
Chrome. Através do Metamask, o usuário final pode criar uma conta na cadeia de blocos
(Blockchain) e interagir com aplicações descentralizadas “Dapp” que consistem em duas
partes: um frontend, escrito em HTML, e um backend, da mesma maneira como se possuísse
um nó da cadeia de blocos (Blockchain) instalado localmente, o que não é interessante para
um usuário final. Internamente, a aplicação cliente também utiliza a mesma API do Web3
para interagir com a Cadeia de blocos (Blockchain) através do Metamask.
Para agilizar o desenvolvimento e teste de aplicações que interagem com a cadeia de
blocos (Blockchain), a plataforma Ethereum desenvolveu uma aplicação baseada em NodeJS
chamada de “testrpc” (https://github.com/ethereumjs/testrpc). A testrpc simula uma cadeia de
blocos (Blockchain) em memória, possibilitando o desenvolvimento e testes ágeis de
aplicações que interagem com a cadeia de blocos (Blockchain). Ao iniciar essa cadeia de
blocos (Blockchain) de desenvolvimento, são criadas automaticamente dez contas fictícias
para uso nessa cadeia de blocos (Blockchain).
A estruturação deste ambiente de desenvolvimento contou com dois cenários de
plataforma de cadeia de blocos (Blockchain), um de teste e outra real. Essa necessidade se
justifica por conta da indispensabilidade de investimento financeiro para realização de
transações na Blockchain real. Esse custo é necessário para maior controle de transações
ocorridas na cadeia de blocos, devido a toda transação ocorrida necessitar ser validada pelos
mineradores da cadeia. Os mineradores são recompensados pelo esforço com o gas.
De acordo com Pavanatti (2017), o “gas” é uma medida de esforço computacional.
Para cada operação, uma quantidade fixa de gas é atribuída (por exemplo, adicionar dois
números custa 3 gas, o cálculo de um hash custa 30 gas, o envio de uma transação custa
21.000 gas). Uma vez que a computação é dispendiosa (é importante que seja feito por cada
nó completo da rede), o consumo excessivo de gas normalmente é desencorajado. Portanto,
cada unidade de gas deve ser paga pelo remetente da transação que desencadeou a
computação de passos computacionais em uma transação ou mensagem para acionar a
execução de um contrato inteligente. Ou seja, um limite de gas maior implica que possa haver
mais transações.
No contexto deste estudo, o gas é medido em Ether, moeda digital transacionada na
plataforma Ethereum que foi selecionada como plataforma de cadeia de blocos (Blockchain)
para realização da experiência de uso.
3.3.3.3. Principais ferramentas/bibliotecas utilizadas

61
A aplicação cliente foi desenvolvida utilizando o framework de Java Script Angular

(https://angular.io/) para o desenvolvimento mais ágil da interface gráfica. Para permitir as
chamadas ao contrato criado na cadeia de blocos (Blockchain), foi utilizada a API Web3 da
plataforma Ethereum, descrita anteriormente.
A aplicação servidora foi desenvolvida com o framework Express
(http://expressjs.com/) em NodeJS.
Para permitir a criação do contrato na cadeia de blocos (Blockchain), também foi
utilizada a API Web3, juntamente com o nó da cadeia de blocos (Blockchain) instalado no
servidor (exclusivo para a segunda arquitetura testada). Esse nó consiste no programa Parity,
que se conecta à rede cadeia de blocos (Blockchain) ao ser iniciado e permite a interação com
esta.
O editor de código utilizado foi o Visual Studio Code (https://code.visualstudio.com/),
devido ao ótimo suporte que possui para desenvolvimento de aplicações voltadas para Web,
como a linguagem Java Script, utilizada em praticamente toda a experiência de uso.
3.3.4 Implementação do protótipo do produto
A plataforma Ethereum desenvolveu uma linguagem própria para a criação de

contratos inteligentes denominados Solidity, cuja extensão do arquivo é *.sol. O código do
contrato utilizado na experiência de uso segue abaixo:
A criação de um contrato na cadeia de blocos (Blockchain) através da API Web3
implica a execução de algumas etapas importantes:
a) Instanciação do objeto Web3, que encapsula as funcionalidades da Web3 e

permite a interação com a cadeia de blocos (Blockchain), representado pela Figura
21 seguinte:
Figura 21 – Instanciação do objeto Web3
b) Compilação do arquivo.sol, que corresponde à implementação do contrato

inteligente, conforme Figura 22.
62
Figura 22 – Compilação do arquivo.sol
c) Instanciação do objeto que possui a abstração do contrato compilado, contendo a

definição dos métodos do contrato.
Figura 23 – Instanciação do objeto do contrato
d) Chamada à função de implantação do contrato, disponível na API do WEB3,

passando como parâmetro o usuário que solicita a criação do contrato e a
quantidade de “gas” necessária para a criação desse contrato.
Figura 24 – Chamada à função de implantação do contrato
e) Recebimento da instância do contrato criado na cadeia de blocos (Blockchain),

contendo principalmente o endereço desse contrato na cadeia de blocos
(Blockchain) necessário para permitir chamadas aos métodos do contrato e
efetivara utilização deste.
63
f) Após a execução dos passos acima, é possível chamar funções do contrato;já na

Cadeia de blocos (Blockchain), também através da API do Web3. Abaixo, segue
um exemplo do código da experiência de uso utilizado para realizar a votação
em um candidato.
3.3.5 Testes de software para cadeia de blocos (Blockchain)
Para os testes automatizados do contrato inteligente da experiência de uso construída,

foi utilizado o framework de desenvolvimento orientado a comportamento (Behavior Driven
Development – BDD) chamado Jasmine (https://jasmine.github.io/).
A metodologia de BDD serve para criar testes e integrar regras de negócios com a
linguagem de programação, focando no comportamento do software. Além disso, ainda
melhora a comunicação entre as equipes de desenvolvimento e testes, aumentando o
64
compartilhamento de conhecimento entre elas. Esta metodologia é útil em projetos de

software ágeis, os quais são construídos em várias iterações e estão sofrendo alterações ao
longo do seu ciclo de vida. Como os contratos inteligentes geram transações imutáveis na
cadeia de blocos (Blockchain), é essencial que as regras de negócios sejam bem testadas e
reflitam exatamente o que se espera do contrato. (SMART, 2015).
Os principais fluxos que compõem a experiência de uso foram testados, seguem as
representações de códigos que testam cada um deles:
a) Criação do Contrato: geração e registro do contrato na cadeia de blocos

(Blockchain).
Figura 27 – Teste da Criação do Contrato

65
b) Criação de candidatos para a votação: registro de candidatos a serem votados

na eleição.
Figura 28 – Teste do registro de candidatos
c) Votação em candidatos: registro de votos realizados em determinado candidato.

66
Figura 29 – Teste do registro de votos nos candidatos
Fonte:Elaborado pelo autor.
d) Contagem de votos de um candidato específico: verificação da consistência da

quantidade de votos registrada em cada candidato.
Figura 30 – Teste da consistência de votos nos candidatos

67
e) Contagem global de votos: registro da contagem de todos os votos registrados na

eleição.
Figura 31 – Teste da consistência da quantidade total de votos
A saída da execução dos testes automatizados com sucesso pode ser verificada na
figura abaixo:
Figura 32 – Resultados dos testes com sucesso
Caso algum teste falhe, o erro é exibido no log da execução, onde é descrito o caso de
teste com falha e a descrição do erro.
No exemplo de execução abaixo ocorreram dois erros: um no caso de teste de
contagem de votos de um candidato específico, onde era esperado o valor 7 e foi obtido o
valor 3, e outro na contagem de votos gerais, onde era esperado o valor 3 e foi obtido o valor
5.
68
Figura 33 – Resultados dos testes com falha
3.3.6 Resultados obtidos com a revisão bibliográfica e a experiência de uso
Com a execução dessa experiência de uso, pudemos compreender alguns pontos

relevantes no contexto de desenvolvimento de software orientado à cadeia de blocos, sendo
eles:
a) É necessário inicialmente analisar se o problema a ser resolvido se adéqua à

tecnologia de cadeia de blocos (Blockchain).
b) Desenvolver orientado à cadeia de blocos (Blockchain) requer arquitetura
específica e diferenciada das aplicações web tradicionais.
c) A configuração do ambiente necessita da criação de contas de usuários na
plataforma de cadeia de blocos (Blockchain) selecionada para o desenvolvimento
do produto.
d) O especificador do contrato inteligente não necessita possuir alto conhecimento
em tecnologia da informação. Conhecimento legal é relevante neste contexto e
69
pode ser um fator diferenciador à completude e validade do contrato inteligente a

ser definido.
e) Como muitas Startups falham por muitas vezes por não identificarem
corretamente seus clientes, acreditamos que a técnica de identificação de personas
e cenários podem vir a eliminar esse risco.
f) Identificamos que, para cada plataforma de cadeia de blocos (Blockchain),
geralmente existe uma linguagem de programação específica para que seja
codificado o contrato inteligente e seja possível a interação com a cadeia de
blocos. Neste estudo analisamos e utilizamos a Solidity, específica para a
plataforma Ethereum.
g) Percebemos, ainda, que para evitar bloqueio de transações endereçadas ao
contrato em ambiente de testes ou produção, deve existir um indicador que
monitore o consumo do gás ao longo do ciclo de desenvolvimento, o qual deve ser
coletado e controlado pelo gestor do projeto.
h) Os testes de contrato necessitam ser o mais preciso possível para prever falhas nas
regras de negócio que poderão gerar transações incorretas ao logo do ciclo de vida
de execução do contrato inteligente. São necessários mais estudo para
desenvolvimentos específicos de métodos, técnicas e ferramentas para testes em
software orientados a Blockchain.
i) Percebemos a relevância da utilização de uma plataforma de cadeia de blocos
(Blockchain) de testes para evitar desperdício do gas em transações que não sejam
reais. O gas a ser utilizado em plataformas de testes por ser reposto gratuitamente
em um endereço web da plataforma Ethereum.
j) Como definido na literatura, os softwares orientados à cadeia de blocos são 80%
negócio e 20% tecnologia; por isso, entendemos que a metodologia Lean Startup é
adequada para execução de projetos neste contexto, ela favorece entregas curtas,
orientadas a valor e redirecionamento do fluxo de trabalho baseado em feedback
do cliente. Neste cenário, o contrato inteligente pode ir tendo uma evolução
contínua de suas cláusulas alinhadas ao negócio. (TAPSCOTT;
TAPSCOTT,2016).
k) Pelo alto investimento ocorrido em Startups que desenvolvem produtos de
software orientados à cadeia de blocos – SOB –, entendemos ser um mercado
promissor de negócio para essas empresas.
70
Neste capítulo, pudemos vivenciar a experiência de desenvolver o protótipo de um

produto que utiliza a tecnologia cadeia de blocos (Blockchain) e enfrentar os desafios
oriundos dessa jornada. Documentamos a motivação e as questões que envolvem a pesquisa, a
equipe envolvida, a metodologia utilizada e os resultados obtidos com a construção do
produto.
71
4 PROCESSO DE DESENVOLVIMENTO DE SOFTWARE PARA PRODUTOS

CADEIA DE BLOCOS (BLOCKCHAIN)
4.1 FLUXO DO PROCESSO
Como principal resultado, mapeamos uma segunda versão do processo para

desenvolvimento de software orientado à cadeia de blocos definido na etapa que deu origem
ao protótipo desenvolvido, nesta versão evolutiva o foco do processo foi voltado
principalmente para empresas Startups tendo como base a metodologia Lean.
O processo foi baseado principalmente no conceito de desenvolvimento orientado a
produto e na metodologia proposta por Eric Ries, a Lean Startup, voltada exclusivamente para
empresas Startups. Podemos observar a utilização desses conceitos nas atividades de
definição do produto, na atividade de coletar feedback do cliente que gera retorno à definição
do produto, evidenciando o loop de feedback proposto na prática. É relevante destacar ainda a
análise de necessidade de Pivô e de completude do Mínimo Produto Viável – MPV do
projeto.
Com base na literatura e na experiência de uso da tecnologia de contratos inteligentes
e da plataforma de cadeia de blocos (Blockchain), levantamos as necessidades específicas de
desenvolver sistemas web utilizando essas tecnologias. Podemos observar atividades
modeladas específicas para este contexto, como configurar ambiente blockchain, publicar na
blockchain de testes, publicar na blockchain real ou passos de algumas atividades, como no
caso de definir arquitetura da solução, onde é necessário definir a plataforma blockchain e a
forma de comunicação a ser utilizada no projeto. Geramos ainda alguns guias de apoio e um
checklist de verificação que se apoia na análise de aderência do problema com a solução de
cadeia de blocos (Blockchain).
72
15
A Figura 34 mostra a representação gráfica do fluxo proposto para o processo modelado.
Figura 34 –Representação gráfica do fluxo do processo

15
4.2 ATIVIDADES DO PROCESSO
A seguir listamos, do Quadro 03 ao 22, as atividades propostas no processo, contendo

seus objetivos, papéis envolvidos, entradas e saídas necessárias à execução das atividades e os
passos básicos para execução de cada tarefa.
4.2.1 Atividade 1: Caracterizar e analisar o problema
Quadro 3 – Representação da atividade – Caracterizar e analisar o problema

Objetivos: Compreender se a tecnologia de cadeia de blocos (Blockchain) é adequada para a
resolução do problema.
Papéis principais: Papéis adicionais:

Gerente de projeto Equipe do projeto
Entrada:
Saída:
 Política de Desenvolvimento de SW
 Checklist de adequação Blockchain
Blockchain
 Canvas do projeto
 Modelo de negócio
Passos:
1. Analisar necessidades do cliente
O gerente de projeto recebe e analisa as necessidades do cliente. Caso necessário, consulta o
modelo de negócio da Startup.
2. Documentar necessidades do cliente

O gerente elabora o Canvas do projeto contendo as necessidades do cliente.
3. Verificar adequação à tecnologia Blockchain

O gerente preenche o formulário de adequação à tecnologia blockchain e verifica o percentual
obtido.
1.2.2 Atividade 2: Definir o produto de software
Quadro 4 – Representação da atividade – Definir o produto de software
Objetivos: Definir o escopo inicial e os objetivos do produto.

 Equipe do projeto  Cliente
 Gerente de projeto
Entrada: Saída:
 Política de desenvolvimento de SW
Blockchain  Canvas do projeto atualizado
 Canvas do Projeto
16
Passos:
1. Apresentar problema
O gerente de projeto apresenta o problema a ser resolvido com blockchain ao time através do
canvas do projeto na reunião inicial do projeto.
2. Definir o produto
O gerente de projeto e o time discutem o escopo, os objetivos e limites do produto a ser gerado.
3. Atualizar o canvas do projeto

O gerente de projeto atualiza o canvas do projeto com as informações de concepção do produto.
4.2.3 Atividade 3: Identificar personas e cenários
Quadro 5 – Representação da atividade – Identificar personas e cenários

Objetivos: Mapear e documentar as personas identificadas e os cenários de uso para o projeto.
Equipe do projeto Gerente de projeto
Entrada: Saída:
 Kanban do Projeto  Personas documentadas
 Histórias de usuários
Passos:
1. Identificar personas
O time deverá levantar, através da técnica de personas, os potenciais clientes a utilizarem e seus
perfis para melhor prever os cenários de uso.
2. Identificar cenários
O time deverá levantar, através da técnica de cenários, os potenciais cenários de uso do sistema.
3. Documentar personas e cenários

O time deverá documentar o resumo das características das personas e os cenários através do
modelo disponível no processo de histórias do usuário. OBS: a empresa poderá definir a melhor
forma de documentar as informações das personas identificadas.
4.2.4 Atividade 4: Identificar requisitos
Quadro 6 – Representação da atividade – Identificar requisitos
Objetivos: Identificar e documentar os requisitos a serem atendidos com a construção do produto.

Entrada: Saída:
 Canvas do projeto
 Insumos adicionais relacionados ao  Lista de requisitos
17
negócio (quando aplicável)
Passos:
1. Levantar requisitos do produto

O gerente de projeto designa um membro do time para realizar o levantamento com base no
canvas e cliente do projeto. A técnica de levantamento fica a cargo da experiência do analista.
2. Documentar requisitos do produto

O analista designado pelo gerente de projeto registra uma lista com todos os requisitos
identificados até o momento.
4.2.5 Atividade 5: Definir arquitetura da solução
Quadro 7 – Representação da atividade – Definir arquitetura da solução

Objetivos: Definir e documentar a arquitetura a ser utilizada para implementação do produto,
contendo os componentes ligados ao sistema web e cadeia de blocos (Blockchain).

Entrada: Saída:
 Arquitetura de referência
blockchain  Diagrama arquitetural comentado
 Lista de requisitos
 Guia de plataformas Blockchain
Passos:
1. Definir arquitetura da solução

O time realiza reunião para definição da arquitetura da solução do projeto. A arquitetura pode
utilizar-se de padrões conhecidos e a arquitetura do ambiente blockchain deve seguir a
arquitetura de referência definida.
2. Documentar arquitetura da solução

O analista designado deverá documentar a arquitetura de forma clara e entendível pelo restante
do time.
4.2.6 Atividade 6: Configurar ambiente Blockchain
Quadro 8 – Representação da atividade – Configurar ambiente Blockchain

Objetivos: Realizar a configuração do ambiente Blockchain para o projeto.

18
Entrada: Saída:
Diagrama arquitetural comentado Ambiente configurado
Passos:
1. Criar a conta de acesso
Um membro do time realiza criação da conta na plataforma blockchain escolhida para o projeto.
2. Solicitar doação ou realizar aquisição de insumo financeiro para utilização da cadeia

O time realiza a aquisição do estoque de gas a ser consumido no projeto.
3. Configurar a blockchain de testes

O time realiza a configuração do ambiente blockchain definido na arquitetura do projeto e o
integra na plataforma blockchain de testes selecionada para o projeto.
4. Configurar a blockchain real

O time realiza a configuração do ambiente blockchain definido na arquitetura do projeto e o
integra na plataforma blockchain real selecionada para o projeto.
4.2.7 Atividade 7: Configurar ambiente web
Quadro 9 – Representação da atividade – Configurar Ambiente Web

Objetivos: Realizar a configuração do ambiente web para o projeto.
Entrada: Saída:
Arquitetura definida para o projeto Ambiente configurado
Passos:
Os passos para execução desta tarefa não são o escopo deste estudo. Eles irão variar de acordo
com as tecnologias selecionadas pela startup para a aplicação web.
4.2.8 Atividade 8: Priorizar requisitos
Quadro 10 –Representação da atividade – Priorizar requisitos

Objetivos: Priorizar os requisitos identificados por valor agregado de negócio.
Papéis principais:
Papéis adicionais:
Equipe do projeto
Cliente
Gerente de projeto
Entrada: Saída:
Arquitetura definida para o projeto Requisitos priorizados
19
Passos:
1. Priorizar requisitos
Os times, juntamente com o gerente de projetos, realizam reunião com o cliente para priorizar os
requisitos listados por valor agregado ao cliente.
2. Documentar arquitetura da solução

O analista designado deverá documentar a lista de requisitos priorizada.
4.2.9 Atividade 9: Planejar iteração
Quadro 11 – Representação da atividade – Planejar Iteração

Objetivos: Planejar as tarefas a serem executadas na iteração.
Gerente de projeto e equipe do projeto Cliente
Entrada: Saída:
 Requisitos priorizados  Kanban do projeto
Passos:
1. Selecionar atividades
As atividades da iteração devem ser selecionadas com base no escopo a ser atendido. Deve-se
evitar atividades não relacionadas aos objetivos da iteração.
2. Estimar esforço por atividade

O time, juntamente com o gerente de projetos, realiza a estimativa de esforço de cada atividade
selecionada e alimenta o Kanban do projeto.
3. Selecionar atividades candidatas

O time, juntamente com o gerente de projetos, realiza a seleção das atividades candidatas a
entrarem no escopo da iteração caso haja performance superior ao esperado, e alimentam o
Kanban do projeto.
4.2.10 Atividade 10: Documentar Histórias de Usuários
Quadro 12 – Representação da atividade – Identificar personas e cenários

Objetivos: Mapear e documentar as os cenários de uso para o projeto.
Entrada: Saída:
 Kanban do Projeto  Histórias de usuários
20
Passos:
1. Identificar cenários
O time deverá levantar, através da técnica de cenários, os potenciais cenários de uso do sistema.
2. Documentar histórias de usuários

O time deverá documentar os cenários através do modelo disponível no processo de histórias do
usuário.
4.2.11 Atividade 11: Projetar/Desenvolver testes
Quadro 13 – Representação da atividade – Projetar/Desenvolver testes
Objetivos: Projetar e implementar os testes automatizados definidos para a iteração.

Entrada: Saída:
 Personas documentadas
 Histórias de usuários  Classes de testes implementadas.
Passos:
1. Analisar documentação e planejar cenários

O time deverá levantar os cenários de testes através da leitura dos requisitos documentados.
2. Codificar cenários de testes
O time deverá realizar a codificação das classes de testes para os cenários na ferramenta definida
na arquitetura do projeto.
3. Disponibilizar projeto de testes

O time deverá realizar o salvamento dos códigos produzidos no repositório definido para o
projeto.
4.2.12 Atividade 12: Codificar funcionalidades
Quadro 14– Representação da atividade – Codificar funcionalidades

Objetivos: Realizar a codificação das funcionalidades do sistema.

21
Entrada: Saída:
 Personas documentadas  Versão de código das histórias do projeto.
 Histórias de usuários
Passos:
1. Analisar documentação e planejar componentes
O time deverá levantar os componentes a serem desenvolvidos através dos requisitos
documentados.
2. Codificar cenários de testes

O time deverá realizar a codificação dos componentes na ferramenta definida na arquitetura do
projeto.
3. Disponibilizar codificação
O time deverá realizar o salvamento dos códigos produzidos no repositório definido para o
projeto.
4.2.13 Atividade 13: Publicar na Blockchain de testes
Quadro 15 – Representação da atividade – Publicar na Blockchain de Testes

Objetivos: Integrar com a blockchain de testes para interação com o contrato.

Entrada: Saída:
 Versão de código das histórias do  Versão de código das histórias do projeto
projeto. integrada à blockchain de testes.
Passos:
1. Selecionar Blockchain
O membro do time deverá selecionar o usuário e a plataforma de blockchain para testes através
da ferramenta de simulação de plataforma blockchain para envio do contrato sem consumo de
criptomoeda.
O membro deverá utilizar a função disponível no framework selecionado para envio do código
construído para a blockchain.
22
4.2.14 Atividade 14: Executar testes
Quadro 16 – Representação da atividade – Executar testes

Objetivos: Executar testes definidos para o projeto
Entrada: Saída:
 Versão de código das histórias do  Versão de código testada.
projeto integrada à blockchain de  Relatório de corretude do Jasmine. (Q. A.)
testes.
 Classes de testes implementadas.
Passos:
1. Executar testes
Após o término da codificação, um membro do time deve executar os testes implementados
através da ferramenta selecionada.
2. Registrar defeitos
Após o término da execução, devem ser registrados os defeitos apontados pela ferramenta ou
observados por algum membro do time.
3. Disponibilizar resultados dos testes

O membro do time deverá informar os resultados dos testes, além de executar e alertar sobre
casos de falha para início das correções.
4.2.15 Atividade 15: Corrigir problemas
Quadro 17 – Representação da atividade – Corrigir problemas

Objetivos: Correção de problemas identificados na atividade de execução de testes.

Entrada: Saída:
 Versão de código testada.  Versão de código corrigida.
 Relatório de corretude do Jasmine.
(Q. A.)
Passos:
1. Analisar defeitos
Os defeitos registrados para aquela iteração devem ser analisados para correção.
2. Realizar correções
23
A correção dos defeitos deve ser feita por um ou mais membros do time, com foco na corretude
do produto gerado.
4.2.16 Atividade 16: Publicar na Blockchain real
Quadro 18 – Representação da atividade – Publicar na Blockchain real

Objetivos: Integrar com a blockchain real (de produção) para interação com o contrato.

Entrada: Saída:
 Versão de código das histórias do  Versão de código das histórias do projeto
projeto. integrada à blockchain real.
Passos:
1. Selecionar Blockchain
O membro do time deverá selecionar o usuário e a plataforma de blockchain real através da
ferramenta de integração com a blockchain para envio do contrato com consumo de gás.
O membro deverá utilizar a função disponível no framework selecionado para envio de código
construído para a blockchain.
4.2.17 Atividade 17: Coletar feedbacks
Quadro 19 – Representação da atividade – Coletar feedbacks

Objetivos: Coletar o feedback do cliente em relação ao produto entregue para validação.

Gerente de projeto Equipe do projeto
Entrada: Saída:
 Versão de código disponibilizada  Relatório de satisfação do cliente
para avaliação.
Passos:
1. Apresentar produto ao cliente
O gerente do projeto deverá realizar a apresentação das funcionalidades prontas do produto ao
cliente.
2. Coletar feedback do cliente

O gerente do projeto deverá coletar a percepção do cliente em relação ao produto através do
checklist de avaliação do produto.
24
4.2.18 Atividade 18: Coletar medições
Quadro 20 – Representação da atividade – Coletar medições
Objetivos: Coletar as medições definidas para o projeto.

Papéis adicionais:
Papéis principais:
Equipe do projeto
Gerente de projeto
Cliente
Entrada: Saída:
 Relatório de satisfação do cliente  Relatório de medições
 Kanban do projeto
Passos:
1. Coletar medições
As medições devem ser coletadas pelo gerente de projeto conforme procedimento definido na
especificação das medições.
2. Documentar resultados
Os resultados das coletas devem ser documentados pelo gerente de projetos da forma mais
adequada ao cenário da startup.
4.2.19 Atividade 19: Realizar retrospectiva
Quadro 21 – Representação da atividade – Realizar retrospectiva

Objetivos: Realizar reunião de retrospectiva e avaliação dos resultados do projeto.
Papéis principais:
Papéis adicionais:
Gerente de projeto e equipe do projeto
Cliente
Entrada: Saída:
 Relatório de medições  Ata de retrospectiva
 Relatório de satisfação do cliente  Ações (Q.A.)
 Kanban do projeto
25
Passos:
1. Levantar pontos positivos e oportunidades de melhoria

O gerente de projetos deverá conduzir a estratégia de registro positivo e as oportunidades de
melhoria identificados na iteração concluída e no relatório de satisfação do cliente. É importante
a participação e contribuição de toda a equipe do projeto.
2. Levantar lições aprendidas

O gerente de projetos deverá conduzir à estratégia de registro lições aprendidas identificadas na
iteração concluída e no relatório de satisfação do cliente. É importante a participação e
contribuição de toda a equipe do projeto.
3. Analisar indicadores
O gerente de projetos deverá analisar e apresentar o resultado dos indicadores ao time do projeto.
4. Documentar reunião
O gerente de projetos deverá documentar os resultados da reunião na ata de retrospectiva do
projeto.
4.2.20 Atividade 20: Avaliar MVP do produto
Quadro 22 – Representação da atividade – Avaliar MVP do produto

Objetivos: Verificar a completude do MVP definido para o produto.
Papéis adicionais:
Papéis principais:
Equipe do projeto
Gerente de projeto
Cliente
Entrada: Saída:
 Termo de abertura do projeto  Dados do projeto
 Requisitos do projeto  Relação de profissionais que irão trabalhar
 Disponibilidade da equipe no projeto
Passos:
1. Avaliar Completude MVP

O gerente de produto deverá analisar o escopo previsto para a primeira versão do produto e
comparar com o escopo produzido até o momento, validando a completude da versão e
definindo se ela pode ser lançada ao mercado.
26
4.2.21 Atividade 21: Lançar produto
Esta atividade está representada apenas para melhor entendimento da conclusão do

fluxo. Este processo se limita a apoiar a startup até a conclusão do Mínimo Produto Viável –
MPV – definido para o produto desenvolvido no projeto.
4.3 ATIVOS DO PROCESSO
a) Modelo de negócio: O modelo de negócio será entrada para o processo. Para

execução deste processo, faz-se necessário que a Startup já exista e já possua seu
modelo de negócio definido. Sugerimos que o modelo de negócio seja
documentado no próprio Canvas do Projeto, no qual serão documentadas as
informações do produto (Anexo B – Exemplo comentado de Canvas para modelo
de negócio).
b) Política de desenvolvimento de software orientado à Blockchain: A política
sugerida para desenvolvimento de software orientado à cadeia de blocos – SOB –
condensa diretrizes coletadas na literatura que são relevantes a este contexto
(Anexo C – Política de desenvolvimento de software Blockchain).
c) Checklist de verificação de adequação do problema a Blockchain: Essa lista
de verificação agrupa pontos chave para identificar se a tecnologia de cadeia de
blocos (Blockchain) é adequada para resolver o problema em questão (Anexo D –
Checklist de verificação de adequação Blockchain).
d) Canvas do projeto: Modelo já existente no mercado que visa à documentação do
modelo de negócio através da ferramenta Canvas, desenvolvido pelo pesquisador
Alexander Oster Walder (Anexo B – Exemplo comentado de canvas para modelo
de negócio).
e) Lista de requisitos: A lista de requisitos pode ser documentada da forma que a
Startup achar convencional. Com intuito de não termos um processo muito
mandatório, neste trabalho não foi produzido modelo de artefato para esta
atividade.
f) Arquitetura de referência blockchain: O documento de arquitetura de
referência para Softwares Orientados em Cadeia de Blocos – SOB – visa apoiar a
construção de produtos com utilização da arquitetura testada na experiência de uso
27
realizada, focando apenas na plataforma Ethereum (Anexo D – Arquitetura de

referência Blockchain).
g) Documento de arquitetura: O foco deste artefato é documentar as informações
relevantes da arquitetura do projeto. Como ocorre em muitos ambientes de projeto
ágil, geralmente é feito um desenho e registrada uma foto que serve como
documento deste desenho. Por existirem inúmeras formas de documentar já
disponíveis no mercado, neste trabalho deixamos a cargo da startup escolher a que
melhor se adéqua ao seu cenário.
h) Kanban do projeto: O Kanban é uma ferramenta adaptável, e neste projeto não
definimos modelo para este artefato. Existem inúmeros modelos no mercado e
acreditamos que a Startup deve ficar livre para trabalhar com o que seja adequado
ao seu contexto de projeto (Anexo F – Exemplo comentado de kanban para
startups que utilizam Lean Startup).
i) Histórias de usuários: Para mapeamento dos cenários de uso do contrato, foi
utilizada a técnica de construção de histórias de usuários. (Anexo G – Modelo de
história de usuários).
j) Projeto de testes: Mapeamento de cenários a ser realizado dentro do framework
para automação de testes. Neste trabalho optamos pelo framework Jasmine devido
à identificação de testes anteriores de contratos inteligentes para softwares
orientados à cadeia de blocos – SOB – durante a pesquisa bibliográfica.
k) Especificação de medições: Esse artefato contempla as sugestões de medições
iniciais para controle do projeto. (Anexo H – Especificação de medições).
l) Questionário de avaliação do produto: Esse artefato visa apoiar a avaliação do
produto pelo cliente. (Anexo I – Questionário de avaliação do produto).
m) Ata de retrospectiva: A ata de retrospectiva visa documentar os resultados
obtidos, as lições aprendidas e direcionar a necessidade ou não de execução de
uma mudança de estratégia no projeto (PIVÔ). Também existem muitos modelos
no mercado e deixaremos a cargo das Startups escolherem o que melhor se adéqua
ao seu contexto.
4.4 MEDIÇÕES PROPOSTAS
Como foco de controle do processo proposto, sugerimos três indicadores:

28
a) Trabalho em Progresso (Work In Progress – WIP): Objetiva apoiar a

ocorrência do fluxo contínuo de trabalho, indicando a ocorrência de mais
atividades em progresso do que pessoas disponíveis para executá-la, gerando
gargalos de trabalho e dificultando as entregas.
b) Nível de Reserva do Gas: Para registrar qualquer tipo de alteração na
Blockchain, é necessário a existência de gas, que serve como moeda de troca a ser
paga aos mineradores pelo esforço de validação da transação. A ausência de gas
impede integrações com a Blockchain. Com isso, o nível de gas disponível deve
ser monitorado continuamente no projeto.
c) Média de Satisfação do Cliente com o Produto: Este indicador permite
identificar se o valor de negócio está sendo realmente priorizado e atendido pelo
projeto através da medição da média de satisfação do cliente.
As especificações dos indicadores estão definidas no artefato de especificação das

medições (Anexo H – Especificação das medições).
4.5 AVALIAÇÃO DO PROCESSO
4.5.1 Metodologia utilizada na avaliação
A metodologia selecionada para a validação do processo foi a revisão por pares (Peer-
Review), que consiste na inspeção de produtos de trabalho por um par, ou seja, um
colaborador com habilidades semelhantes ao autor dos artefatos. Essa revisão geralmente é
conduzida de forma estruturada, de modo a que se alcance o máximo de proveito desse
processo. O foco principal desta técnica é conseguir uma exposição do produto construído e
obter os benefícios oriundos de pontos de vista divergentes. A análise deve estar voltada para
o produto inspecionado e não para a pessoa que o produziu. (BEIZER; BEIZER, 1984)
Segundo Cuenca, Buchalla e França (2017), as características gerais da revisão por
pares são:
a) Predominantemente anônimo;
b) Revisores protegidos pelo anonimato têm poder absoluto;
c) Sistema imperfeito com validade desconhecida e confiabilidade abaixo do ponto
ótimo.
29
Ainda segundo os autores, os principais pontos de atenção destacados em relação à

utilização da técnica são:
a) Conservadorismo: Os pares julgam com base em critérios definidos pela própria

comunidade sem questionar a validade das regras estabelecidas. Preconceito
contra novas ideias.
b) Ineficiência: Gasto considerável de tempo e esforço.
c) Autoritarismo e tendenciosidade: Preconceitos contra cientistas mulheres,
jovens, oriundos de instituições sem prestígio ou de países não desenvolvidos.
d) Baixa confiabilidade: Baixo grau de concordância entre avaliadores.
e) Conduta antiética: Conduta considerada incorreta por parte de um revisor.
Para amenizar esses pontos de atenção, os autores sugerem alguns mecanismos de

controle, sendo eles (CUENCA; BUCHALLA; FRANÇA,2017):
a) Utilização de roteiros estruturados com critérios claros de julgamento. Neste

trabalho, utilizamos um questionário estruturado específico para validação do
processo construído. (Anexo J– Questionário de avaliação do processo).
b) Maior número possível de revisores dentro de um contexto aceitável.
c) Possibilidade de recurso por parte dos autores.
d) Caráter confidencial do processo.
Neste trabalho, a revisão em pares ocorreu em três etapas: 1 – Apresentação do

processo aos envolvidos; 2 – Preenchimento do questionário do processo pelos entrevistados;
e 3 – Análise dos resultados pela pesquisadora.
4.5.2 Perfil dos entrevistados
Foram entrevistados 10(dez) participantes que possuem formação em tecnologia da

informação. Devido à natureza inovadora do conhecimento abordado na pesquisa e ao foco de
apoiar a difusão da tecnologia, o público alvo entrevista não previu apenas um universo de
pessoas que possuíssem conhecimento prévio em blockchain. Incorporamos como avaliadores
participantes sem conhecimento prévio com objetivo de analisar a clareza das informações do
processo e sua facilidade de utilização em startups que não possuam experiência anterior no
30
uso de blockchain, tornando o processo um guia inicial para apoiar empreendedores que
desejam iniciar sua jornada de construção de produtos de software que utilizem esta
tecnologia e seu conjunto de conceitos independente do seu nível de experiência no contexto.
Deste modo, os dados coletados foram avaliados em único conjunto universo.
Os pontos observados na caracterização dos entrevistados foram: 1 – Perfil
desenvolvido pelos profissionais em suas equipes de trabalho; 2 – Tempo de experiência; 3 –
Conhecimento prévio em blockchain; 4 – Nível de escolaridade; e 5 – Vivência em empresas
startups.
Em relação ao perfil dos profissionais, podemos observar os seguintes resultados: 20%
dos entrevistados desenvolvem o papel de Gerente de Projeto, 40% exercem o papel de
Projetista/Desenvolvedor (Programador), 20% atuam como Analistas de Teste, e os demais 20%
desempenham a função de Analista de Requisitos/Negócios. A Figura 35 exibe o resultado do
levantamento de perfil técnico realizado com os entrevistados.
Figura 35 – Representação gráfica do perfil técnico dos entrevistados
Em relação ao tempo de experiência dos profissionais entrevistados na função que

informaram exercer, pudemos perceber que 10% possuem até 3 anos de experiência; 60%
possuem de 3 a 6 anos, sendo este grupo a maior concentração dos profissionais entrevistados.
Notou-se, ainda, que existem 20% com tempo de experiência de 6 anos a 9 anos, e, por
último, 10% com tempo superior a 9 anos. Podemos destacar que a maioria dos entrevistados
possuem um tempo de experiência relevante, o que favorece as contribuições adicionadas à
pesquisa. A Figura 36 representa graficamente o resultado obtido neste item da pesquisa.
31
Figura 36 – Representação gráfica da experiência profissional dos entrevistados

Em relação ao conhecimento prévio da tecnologia blockchain, podemos destacar que
apenas 10% dos entrevistados já trabalhou com a tecnologia anteriormente e que 30%
desconhecem o significado do conceito. A Figura 37 representa os resultados obtidos.
Figura 37 – Representação gráfica do conhecimento prévio em blockchain dos entrevistados
Analisando o nível de escolaridade dos entrevistados, podemos observar que a maioria

de 60% possui especialização concluída, e os demais (40%) possuem apenas nível superior
completo. Não ocorreu representatividade numérica para as demais opções. A Figura 38
ilustra esse resultado.
32
Figura 38 – Representação gráfica do nível de escolaridade dos entrevistados

Avaliando a vivência dos colaboradores da pesquisa em relação à vivência em
empresas startups, pode-se perceber que a maioria de 70% dos entrevistados nunca atuou em
projetos neste tipo de empresa. A Figura 39 exibe os dados obtidos.
Figura 39 – Representação gráfica da vivência em startups dos entrevistados
Com a análise do perfil dos entrevistados, podemos caracterizar que a maioria do

grupo selecionado são desenvolvedores que possuem cerca de 3 a 6 anos de experiência
profissional, que conhecem o conceito de blockchain, mas nunca trabalharam com a
tecnologia. Percebe-se também que a maioria possui nível de escolaridade com especialização
completa, e que, apesar de conhecerem o modelo de startups, nunca atuaram diretamente
neste tipo de empresa.
33
4.5.3 Resultados
Como resultados dos itens específicos da avaliação do processo, obtivemos as

respostas apresentadas na Tabela 1.
Tabela 1 – Resultados da avaliação do processo

Nem
Discordo concordo Concordo
Questão fortemente Discordo nem Concordo fortemente
discordo
O processo proposto é de
fácil
0% 0% 0% 60% 40%
entendimento/usabilidade
para o leitor.
As atividades citadas no
processo estão adequadas
0% 0% 0% 50% 50%
para desenvolvimento de
um produto de software.
A documentação gerada no
0% 0% 0% 70% 30%
processo é adequada.
O processo possui
características de leveza
0% 0% 0% 50% 50%
que favorecem a aplicação
no âmbito de uma Startup.
O processo possui
características específicas
0% 0% 10% 60% 30%
que abordam a tecnologia
Blockchain.
Analisando os dados coletados, podemos perceber que o processo está adequado para
uso, sendo de fácil compreensão, possuindo atividades que possibilitam a criação de um
produto de software, documentação de suporte ao processo, leveza para ser utilizado em uma
startup e características específicas voltadas à tecnologia blockchain.
4.5.4 Oportunidades de melhoria, pontos fracos e pontos fortes
a) Sugestões de melhoria informadas pelos entrevistados:

34
1. “Acredito que o passo "Identificar Personas e Cenários" deva estar antes

da definição da arquitetura, pois pode ser identificado algum cenário que
necessite mudar a arquitetura do sistema”.
Análise: Acreditamos que esta melhoria é relevante e possa ser incorporada
ao processo em versões futuras.
2. “A sequência do passo "Codificar Funcionalidades" é somente publicar em

Testes. No mundo real de desenvolvimento, alguma funcionalidade pode
precisar de ajustes de requisitos nessa fase. O modelo poderia contemplar o
que fazer neste caso (replanejar iteração, ajustes de testes...).
Análise: Existe a atividade genérica chamada a partir do ponto “Realizar
Correção” que possibilita a correção de defeitos em qualquer disciplina.
Entendemos que esta melhoria deve ser desconsiderada na evolução do
processo.
3. “Definir os papéis dos envolvidos na equipe, para ser possível mensurar o

time”.
Análise: No contexto ágil de lean startup, as equipes são autocontidas e
multidisciplinares, a equipe se comporta como um time, onde todos podem
exercer qualquer papel dentro da engenharia de software com foco no
objetivo a ser atingido e no trabalho pendente. A mensuração de equipes
geralmente não se dá apenas por competências. Em versões futuras, pode ser
feita a estratificação dos perfis de membros do time em um documento de
competências da equipe. A melhoria procede.
4. “A análise da necessidade de pivô não deveria ocorrer durante a avaliação

do MVP? São realmente duas análises tão distantes que justifiquem dois
fluxos diferentes? Não seria ideal que a atividade estivesse melhor colocada
após a análise do MVP? Uma vez que, segundo o livro The Lean startup de
Eric Ries, o pivô acontece durante a validação do MVP?”.
Análise: Existe a necessidade de retornar a pontos diferentes no processo a
partir destas análises. Como o processo se propõe a focar no valor ao
cliente, se for identificada a necessidade de pivô, é porque as necessidades
do cliente não foram atingidas; logo, nem é necessário avaliar a completude
35
do MVP, reduzindo o esforço da análise e otimizando o processo. Neste

contexto, presumimos que a melhoria não procede.
b) Pontos fracos informados pelos entrevistados:
1. “Apesar de o processo estar bem ágil, acredito que a realidade no

desenvolvimento de software em uma startup não seria possível a geração
de tantos artefatos de documentação”.
Análise: Existe uma resistência à documentação oriunda de empresas
Startups. Ser ágil ou lean não significa não possuir documentação. A
documentação está pautada em dois instrumentos muito utilizados em
startups, o Canvas e o Kanban. Imaginamos que esta melhoria precisa ser
mais bem avaliada após um ciclo de execução dos processos em alguns
projetos.
2. “O modelo apresenta o caminho feliz, rotas alternativas ajudariam a

tomada de decisões”.
Análise: Com foco no loop de feedback, as rotas de retorno permitidas pelo
processo são: (1) durante a identificação de falhas nos testes, sejam eles em
qualquer disciplina; e (2) após a validação do produto ou de parte dele pelo
cliente. Deste modo, evitam-se muitas mudanças durante o curso,
impedindo a conclusão de itens para entrega. Levando em consideração a
natureza proposta no processo, esse ponto pode ser desconsiderado.
c) Pontos fortes informados pelos entrevistados:

1. “A ideia é muito escalável e genérica, pode ser aplicada a muitas
atividades do dia a dia”.
Análise: Realmente o processo é genérico para qualquer aplicação,
independentemente do domínio de negócio que utilize blockchain.
2. “Processo devidamente definido, metodologia corretamente aplicada e

excelente escolha do mercado de atuação (startups)”.
Análise: Como já citado anteriormente, pelo conceito inovador da
tecnologia e pelo estágio de experimentação existente atualmente,
36
acreditamos que as startups sejam o melhor tipo de empresa para

empreender neste cenário tecnológico.
3. “O primeiro passo, que é a análise e caracterização do problema, a fim de

identificar sua adequação ao uso de blockchain, é uma atividade primordial
no processo, impelindo ao Gestor de Projetos a análise do problema, de
forma a antecipar e evitar decisões possivelmente equivocadas sobre a
utilização ou não da plataforma”.
Análise: Essa atividade é relevante porque, caso o problema não seja
adequado, o gestor terá claramente e ainda no início do processo a visão de
buscar outras alternativas tecnológicas.
4. “O uso do circuito de reação (Construir, Medir, Aprender) também ficou

bastante claro no decorrer das atividades, denotando a maturidade do
processo e suas raízes no Lean, bem como o uso de feedback quantitativo e
qualitativo, através dos indicadores definidos para coleta de medições,
também fortalece o circuito de reação”.
Análise: O Lean Startup é a base metodológica do processo.
5. “O processo é capaz de atender a todos os problemas de vários pontos

críticos do sistema, como por exemplo o erro de requisitos encontrados
durante o desenvolvimento”.
Análise: O ciclo de correção de defeitos e o loop de feedback após
validação do produto pelo cliente favorecem a identificação de defeitos e
necessidades de mudança.
6. “O modelo desenhado do processo está bastante claro com respeito a todos

os papéis do mesmo”.
Análise: Com a visão de time autocontido e multidisciplinar, o processo foi
dividido em apenas dois papéis para favorecer o entendimento da fronteira
entre atividades técnicas e atividades de gestão.

37
Neste capítulo, pudemos documentar a principal contribuição deste trabalho: o

processo para desenvolvimento de aplicações SOB – Software Orientado à Cadeia de Blocos
(Blockchain) – proposto a partir do resultado da pesquisa bibliográfica e da experiência de
uso vivenciada.
38
5 CONCLUSÃO E TRABALHOS FUTUROS
Neste capítulo, são apresentadas as conclusões finais do trabalho, focando nas

contribuições, limitações e nos trabalhos futuros.
5.1 CONSIDERAÇÕES FINAIS
Com a elaboração da pesquisa bibliográfica e a execução da experiência de uso

vivenciadas nesta pesquisa, buscou-se responder as questões levantadas durante o processo de
construção da ideia de estudo.
Analisando-se a primeira questão discutida no trabalho ‘Que particularidades da
engenharia de software estão envolvidas no desenvolvimento de produtos de software que
utilizam Cadeia de blocos (Blockchain)?’, chegamos aos seguintes pontos que respondem a
indagação:
Porru et al. (2017, p. 45) citam que, dentre os principais desafios a serem enfrentados
pela Engenharia de Software no contexto de softwares orientados a cadeia de blocos
(Blockchain), estão:
1) Necessidade de engenheiros de software capacitados para elaborar ferramentas e
técnicas especializadas para orientações de cadeias de blocos.
2) Definição de novos papéis profissionais.
3) Especialização das atividades de testes buscando maior rigorosidade e segurança.
Principalmente no contexto dos requisitos não funcionais.
4) Definição de novas ferramentas para a arquitetura de software orientada a Blocos
e contratos inteligentes.
5) Propor novos caminhos a partir da análise de repositórios de códigos
compartilhados de aplicações orientadas a blocos.
6) Definição de novo tipo de categoria de softwares, SOB – Softwares Orientados à
Blockchain, a ser acrescida as existentes. Devendo esta ser observada como objeto de
estudo da engenharia de software.
Avaliando-se a segunda questão de pesquisa ‘Quais os principais desafios tecnológicos
que empresas do tipo startups enfrentam para inovar na área de Cadeia de blocos
(Blockchain)?’, aprendeu-se que é desafiador compreender os novos paradigmas que
envolvem o desenvolvimento de produtos que utilizam Cadeia de blocos (Blockchain),
39
principalmente no contexto de empresas startups que precisam lidar muitas vezes com
restrições e incertezas de mercado.
Percebeu-se também que alguns conceitos da Engenharia de Software tradicional
precisam ser evoluídos para atender à demanda oriunda desta nova tecnologia. Profissionais
com visão integradora que façam o elo entre os profissionais da tecnologia e o cliente
necessitam ser agregados ao processo de construção para uma boa elaboração das regras e
nuances do contrato inteligente. Identificou-se, ainda, a necessidade de evolução de propostas
arquiteturais que apoiem melhor a tomada de decisão durante o processo de construção de
softwares. Faz-se necessário também o desenvolvimento de ferramentas que possibilitem uma
maior automação e um melhor aproveitamento da disciplina de testes de software, buscando
avanços na disciplina de testes de software orientados à cadeia de blocos (Blockchain).
5.2 PRINCIPAIS CONTRIBUIÇÕES
Embasados na realização da pesquisa bibliográfica e na execução da experiência de

uso, obtivemos como principais contribuições deste estudo as listadas a seguir:
a) Compilação de conhecimentos relacionados à cadeia de blocos (Blockchain);

b) Definição de uma arquitetura base a ser reutilizada em aplicações simples que
envolvam Cadeia de blocos (Blockchain);
c) Demonstração prática de utilização da tecnologia Cadeia de blocos (Blockchain)
em uma aplicação web;
d) Disponibilização do código fonte para pesquisas futuras no GitHub através do link
https://github.com/samantha-kelly/dapp.git;
e) Construção de um processo de apoio ao desenvolvimento de software orientado à
Cadeia de blocos (Blockchain) para empresas startups;
f) Construção de indicadores de apoio a gestão e a utilização do processo.
5.3 LIMITAÇÕES
O trabalho produziu um processo que não pôde ser validado em ambiente real por
questões de tempo e financeiras. Para este contexto, seria necessário o envolvimento de
empresas startups interessadas em desenvolver produtos na tecnologia e dispostas a investir
para utilizar e validar o processo.
40
Outro ponto relevante foi que devido à natureza inovadora da tecnologia pesquisada, o
universo de pessoas especialistas em blockchain, entrevistadas na validação do processo foi
inferior ao desejado, onde quanto ao conhecimento prévio da tecnologia pelos avaliadores
apenas 10% dos entrevistados já trabalhou com a tecnologia anteriormente, 60% conheciam o
conceito, mas nunca atuaram diretamente com blockchain e 30% se quer conheciam.
5.4 TRABALHOS FUTUROS
A tecnologia possui inúmeras aplicações nos mais variados campos de negócio.

Entende-se que a utilização de Cadeia de blocos (Blockchain) em produtos é composta por
20% tecnologia e 80% negócio (COLLINS,2016). Durante o desenvolvimento da aplicação da
abordagem proposta, algumas possibilidades de trabalhos futuros foram percebidas:
a) Validação do processo em startups com diversos níveis de maturidade. Neste

trabalho, é possível levantar as necessidades de evolução do processo e/ou
subdivisão em outros processos para startups por nível de maturidade.
b) Análise de especialistas Cadeia de blocos (Blockchain) sobre o processo, com
intuito de validar e propor soluções mais otimizadas que melhorem a performance
do processo e agreguem mais valor ao domínio de aplicação.
c) Aplicação da tecnologia em diversos domínios de aplicação para comparação de
resultados e verificação de mais pontos específicos onde a engenharia de software
poderia atuar para agregar valor ao desenvolvimento de softwares que se utilizem
desta tecnologia.
d) Elaborar um guia de adaptação do processo para apoiar a utilização do processo
em diversas plataformas de blockchain e em variados contextos de domínio de
aplicação da tecnologia.
e) Desenvolvimento de ferramentas que possibilitem uma maior automação e um
melhor aproveitamento da disciplina de testes de software, buscando avanços na
disciplina de testes de software orientados à cadeia de blocos (Blockchain).
f) Desenvolvimento de novas abordagens arquiteturais voltadas as diversas
plataformas de blockchain.
41
REFERÊNCIAS
ASTAR LABS. O ciclo de vida de uma transação bitcoin. 2017. Disponível em:
<https://www.astarlabs.com/o-ciclo-de-vida-de-uma-transacao-bitcoin/>. Acesso em: 05 dez.
2017.
BAMFORD, David et al. Partial and iterative lean implementation: two case studies.
International Journal of Operations & Production Management, v. 35, n. 5, p. 702-727,
2015.
BEIZER, B. Software system testing and quality assurance. Van Nostrand Reinhold Co.,
New York, 1984.
BLOG DO NEI. Lean Startup – Para iniciar uma empresa enxuta e ágil. 2012. Disponível
em: <https://neigrando.wordpress.com/2012/05/23/lean-startup-para-iniciar-uma-empresa-
enxuta-e-agil/>. Acesso em: 05 dez. 2017.
BOUFLEUR, Pedro; AYALA, Nestor; FRANK, Alejandro. Uma análise da implementação

da metodologia lean startup em uma empresa do ramo de entretenimento digital.
Disponível em: <http://revistas.ubiobio.cl/index.php/RI/article/download/2952/3014/>.
Acesso em: 15 nov. 2017.
BUTERIN, Vitalik. Ethereum: a next-generation cryptocurrency and decentralized application

platform. Bitcoin Magazine. 2014. Disponível em:
<https://bitcoinmagazine.com/articles/ethereum-next-generation-cryptocurrency-
decentralized-application-platform-1390528211/>. Acesso em: 05 dez. 2017.
CMMI. CMMI for Development – Version 1.3. 2013. Disponível em:

<https://resources.sei.cmu.edu/asset_files/technicalreport/2010_005_001_15287.pdf>. Acesso
em: 02 nov. 2017.
COLLINS, Rod. A new architecture for digital content. 2016. Disponível em:
<http://www.econtentmag.com/Articles/Editorial/Commentary/Blockchain-A-New-
Architecture-for-Digital-Content-114161.htm>. Acesso em 28 out. 2017.
CPQD. Centro de Pesquisa e Desenvolvimento em Telecomunicações. Tecnologia

Blockchain: uma visão geral. 2017. Disponível em: <http://www.cpqd.com.br>. Acesso em:
05 nov. 2017.
CUCCURU, P. Beyond Bitcoin: an early overview on smart contracts. International Journal

of Law and Information Technology, v. 1, n. 17, 2017.
CUENCA, Angela; BUCHALLA, Cassia; FRANÇA, Ivan J. Metodologia para divulgação

do artigo científico. 2017. Disponível em: <http://slideplayer.com.br/slide/10839875/>.
42
GIARDINO, C. et al. Software development in startup companies: A systematic mapping

study. Inf. Softw. Technol. v. 56, n. 10, p. 1200-1218, oct. 2014. Disponível em:
<http://www.sciencedirect.com/science/article/pii/S0950584914000950?via%3Dihub>.
Acesso em: 06 dez. 2017.
GUIMARÃES JÚNIOR, Antônio Oliveira de Andrade. Uma estratégia de avaliação de

modelos de experiência do usuário: utilizando checklists de verificação e validação.
Universidade de Fortaleza – UNIFOR. 2016. Disponível em:
<http://uolp.unifor.br/oul/conteudosite/F10663420170410113558250807/Dissertacao.pdf>.
HENDRICKSON, Joshua R.; HOGAN, Thomas L.; LUTHER, William J. The political
economy of bitcoin. Economic Inquiry, v. 54, n. 2, p. 925-939, 2016.
HOLANDA, Kelma Madeira Furtado. Um Framework de Elaboração de Personas e sua

Aplicação para a Elicitação de Requisitos e para a Análise das Interações em Sistemas
Sociais. Universidade de Fortaleza – UNIFOR. 2010. Disponível em:
< http://uolp.unifor.br/oul/conteudosite/F1066347375/Dissertacao.pdf>.
INSIDER PRO. Contratos inteligentes: guia para principiantes. 2017. Disponível em:
<https://pt.insider.pro/tutorials/2017-08-02/contratos-inteligentes-guia-para-principiantes/>.
JALOTE, P. An integrated approach to software engineering. 2005. 3. ed. New York:

Springer, 2005. 566p.
KAZMAN, Rick; TANG, Antony. On the worthiness of software engineering research.

2017. Disponível em: <http://shidler.hawaii. edu/sites/shidler. hawaii.
edu/files/users/kazman/se_research_worthiness.pdf>. Acesso em: 25 dez. 2017.
KOLLBERG, B.; DAHLGARD, J. J.; BREHMER, P. O. Measuring lean initiatives in health

care services: issues and findings. 2007. International Journal of Productivity and
Performance Management, v. 56, n. 1, p. 07-24. (Emerald Group Publisher Limited).
LEAN IT. Lean TI ou TI enxuta! 2017. Disponível em:

<http://www.ft.unicamp.br/liag/leanit/lean-it/>. Acesso em: 05 dez. 2017.
______. O que é mapeamento do fluxo de valor (MFV)? 2013. Disponível em:

<http://www.leanti.com.br/conceitos/6/Mapeamento-do-fluxo-de-valor.aspx>. Acesso em: 05
dez. 2017.
LIB. Lean Intitute Brasil. Lean em TI. 2017. Disponível em:

<https://www.lean.org.br/consultoria-lean-em-ti.aspx>. Acesso em: 24 out. 2017.
LUCENA, Antonio U. Estudo de arquiteturas dos blockchains de Bitcoin e Ethereum.

Departamento de Engenharia de Computação e Automação Industrial (DCA). In: IX
ENCONTRO DE ALUNOS E DOCENTES DO DCA/FEEC/UNICAMP (EADCA). 2016.
Disponível em:
43
<http://www.fee.unicamp.br/sites/default/files/departamentos/dca/eadca/eadcaix/artigos/lucen
a_henriques.pdf>. Acesso em: 05 nov. 2017.
MAGAZZENI, Daniele; MCBURNEY, Peter; NASH, William. Validation and verification of

smart contracts: a research agenda. Computer, v. 50, n. 9, p. 50-57, 2017.
MARVIN, R. Blockchain in 2017: the year of smart contracts. 2016. PC MAG. Disponível
em: <http://www.pcmag.com/article/350088/blockchain-in-2017-the-year-of-smart-
contracts>. Acesso em: 05 nov. 2017.
MARY, Poppendieck; TOM, Poppendieck. Lean software development: an agile toolkit.

2003.
MURRAY, Art. All aboard the block chain express. KM World Magazine. 2015. Disponível
em: <http://www.kmworld.com/Articles/Column/The-Future-of-the-Future/All-aboard-the-
blockchain-express-102652.aspx>. Acesso em: 06 dez. 2017.
NAKAMOTO, Satoshi. Bitcoin: a peer-to-peer electronic cash system. 2009. Disponível em:
<https://bitcoin.org/bitcoin.pdf>. Acesso em: 5 maio 2017.
NOBREGA, Carlos Lenine de Oliveira. Um Framework de Elaboração de Persona

Empresa para Suporte na Análise de Valor de Negócio na Aplicação em Sistemas de
Redes Sociais. Universidade de Fortaleza – UNIFOR. 2011. Disponível em:
< http://uolp.unifor.br/oul/conteudosite/F106634588/Dissertacao.pdf>.
PINHEIRO, Lívia Figueredo Rodrigues. Modelagem do domínio DAA utilizando a

tecnologia p3tech©. Monografia (graduação) – Curso de bacharelado em Ciências da
Computação, Faculdade Farias Brito, Fortaleza, 2007. 196f.
PLANSKY, Jonh; O’DONNELL, Tim; KIMBERLY, Richards. A strategist’s guide to

blockchain. 2016. Disponível em: <https://www.strategy-business.com/article/A-Strategists-
Guide-to-Blockchain?gko=0d586>. Acesso em: 24 out. 2017.
PORRU, S. et al. Blockchain-oriented software engineering: challenges and new

directions. Departamento de Engenharia Elétrica e Eletrônica. Departamento de Informática e
Matemática – Universidade de Cagliari, Itália, 2017.
______. Engenharia de software: um enfoque prático. New York: Mc Graw Hill, 2005. p.
21-22.
PRESSMAN, Roger S. Engenharia de software: uma abordagem profissional. 2011. 7. ed.

São Paulo: Pearson Makron Books, 2011.
PURRI, M. C. M. e S. Estudo e propostas iniciais para a definição de um processo de

desenvolvimento para software científico. Dissertação apresentada ao Departamento de
Modelagem Matemática e Computacional (MMC) do Centro Federal de Educação
Tecnológica de Minas Gerais, Belo Horizonte, 2006.
44
RIBEIRO, G. Lean startup: análise exploratória sobre sua utilização por novas empresas
brasileiras. 2014. Dissertação de mestrado. FGV. Disponível em:
<http://bibliotecadigital.fgv.br/dspace/handle/10438/13114>. Acesso em: 10 nov. 2017.
RIES, Eric. A startup enxuta: como os empreendedores atuais utilizam a inovação contínua
para criar empresas extremamente bem-sucedidas. In. RIES, Eric. [tradução Texto Editores].
– São Paulo: Lua de Papel, 2012. ISBN 9788581780139
SMART, John Ferguson. BDD in Action: Behavior-driven development for the whole
software lifecycle. Manning, 2015.
SOMMERVILLE, I. Engenharia de software. 2013. 6. ed. São Paulo: Pearson Addison

Wesley, 2003.
______. Engenharia de software. 2007. 8. ed. Boston: Pearson Addison-Wesley, 2007.
SUSTENTARE. Manufatura enxuta: princípios da filosofia lean. 2014. Disponível em:

<https://pt.slideshare.net/Sustentare/manufatura-enxuta-lean-slides-prof-silene-seibel>.
SUTTON, Garrett. The 7 most common legal mistakes startups make. 2017. Disponível
em: <https://www.linkedin.com/pulse/7-most-common-legal-mistakes-startups-make-garrett-
sutton-1/>. Acesso em: 15 set. 2017.
SZABO, N. Formalizing and securing relationships on public networks. First Monday, v. 2,

n. 9, 1997.Disponível em: <http://firstmonday.org/ojs/index.php/fm/article/view/548/469>.
TAPSCOTT, Don; TAPSCOTT, Alex. The blockchain revolution: how the technology
behind bitcoin is changing money, business, and the world. London: Penguin Books,
2016. ISBN 978-0670069972
YAGIMA, Fernanda Yukari. Lean startup: uma aplicação ao projeto neo time touch.
Universidade Estadual de Campinas – UNICAMP, Limeira, 2012. Disponível em:
<http://www.ft.unicamp.br/liag/leanit/wp-
content/uploads/sites/8/2017/05/ST865_Lean_Startup_final_Corre%C3%A7%C3%A3o_v2.p
df>. Acesso em: 05 nov. 2017.
ZIEGELDORF, Jan Henriket al. Secure and anonymous decentralized Bitcoin

mixing. Future Generation Computer Systems, 2016.
45
ANEXOS
ANEXO A – CENÁRIOS DE USO
Cadastro do Contrato Eleitoral

46
Cadastro dos Candidatos na Plataforma de Votação

47
Encerramento do Cadastro dos Candidatos na Plataforma de Votação

48
Registro de Voto

49
Encerrar votação

50
ANEXO B – EXEMPLO COMENTADO DE CANVAS PARA MODELO DE NEGÓCIO
Fonte: http://www.internetparaempreendedores.com.br/modelo-de-negocios-canvas/
51
ANEXO C – POLÍTICA DE DESENVOLVIMENTO DE SOFTWARE BLOCKCHAIN.

52
ANEXO D – CHECKLIST DE VERIFICAÇÃO DE ADEQUAÇÃO BLOCKCHAIN.
Questionário de Adequação Blockchain

O questinoário apóia a decisão de utilizar ou não a tecnologia Blobkchain no contexto do seu projeto.
Responda ao questionamentos abaixo e verifique o percentual de aderência a tecnologia. ()
Questões Respostas
1 O seu problemas necessita de registro de transações entre duas partes? Sim
2 O resultados das suas transações pode ser público? Não
3 É relevante o rastreio de transações ocorridas e suas relações? Sim
4 O Anonimato de uma transação no sistema a ser resolvido para o seu sistema é relevante? Sim
5 As transações ocorridas no seu sistema necessitam de imutabilidade? Sim
6 É obrigatória a validação da veracidade detodas as transações ocorridas no seu sistema? Não
7 Seu sistema pode possuir base de dados descentralizada? Sim
8 A velocidade de retorno de transações é vital para o seu negócio? Sim
9 Na solução do seu problema será envolvido algum terceiro para validar as transações ocorridas? Sim
10 É necessária transparência nas transações ocorridas para resolver o seu problema? Sim
Percentual de Aderência: 80%

53
ANEXO E – ARQUITETURA DE REFERÊNCIA BLOCKCHAIN.

54
55
ANEXO F – EXEMPLO COMENTADO DE KANBAN PARA STARTUPS QUE

UTILIZAM LEAN STARTUP
Fonte: https://br.pinterest.com/pin/388857749058638342/
56
ANEXO G – MODELO DE HISTÓRIA DE USUÁRIOS

57
ANEXO H – ESPECIFICAÇÃO DAS MEDIÇÕES
Especificações das Medições

Identificador WIP GAS GSC
Trabalho em Progresso (Work In Progress Média de Satisfação do Cliente
Nome da Medida Nível de Reserva do Gas
– WIP) Com o Produto
Apoiar a ocorrência do fluxo contínuo de trabalho,
indicando a ocorrência de mais atividades em
Verificar a variação consumo de gas Mede o Grau de Satisfação do Cliente
Objetivos da Medição progresso que pessoas disponíveis para executá-la,
no projeto com o Produto
gerando gargalos de trabalho e dificultando as
entregas
Tipo da Medição Simples Simples Simples
Quantidade de atividades por coluna do Kanban X

Medidas que compõem Valor do Saldo do GAS
Quantidade de pessoas alocadas
Meta <= 0 <= 1000 >= 3
Quantidade de atividades em andamento -

Fórmula de Cálculo Valor apresentado como saldo do GAS Média ((∑ Nota de cada item))
Quantidade de pessoas alocadas
Unidade de Medida Unidade Unidade Média

maior ou igual a
menor ou igual a 0 maior ou igual a 3
Sinalizadores gráficos 1000
maior que 0 menor que 1000 menor que 3
Projetos de desenvolvimento de
Tipos de projetos Todos tipos de projetos software que utilizem Blockchain com Todos tipos de projetos
Pataforma Ethereum.
Informações para a Coleta e Armazenamento dos Dados
Fonte(s) de dados Kanban do Projeto Relatório do Metamask do Projeto Questionário de Avaliação do Produto
Como coletar:
Como coletar: Como coletar:
Observar a quantidade de tarefas em andamento
Valor apresentado como saldo do GAS Observar as notas informadas e
Procedimento de coleta e durante a reunião diária.
no site do plugin metamask realizar a media de todos os valores.
armazenamento Armazenamento:
Armazenamento: Armazenamento:
Para este indicador não é necessário
Relatório do projeto Relatório do projeto
armazenamento.
Periodicidade de coleta Diário Semanal Diário
Responsável pela coleta e
Gerente do Projeto Gerente do Projeto Gerente do Projeto
armazenamento
Informações para Análise de Dados
Não aceita variação. Só podem existir atividades
Não aceita variação. Abaixo de 1000 Não aceita variação. Abaixo de 3 deve
Parâmetros de análise em andamento que correspondam a quantidade de
unidades deve ser tomada ação. ser tomada ação.
pessoas disponíveis para fazer.
Como analisar: Como analisar:
Analisar através do quadro kanban, verificando a Analisar através do relatório Como analisar:
ocorrência de atividades excedentes. metamask do projeto. Analisar através do relatório do
Procedimento de análise Ações corretivas: Ações corretivas: projeto.
Revisar a prioridade das tarefas e mover para Decidir pela compra de mais GAS ou a Ações corretivas:
Pendende as excedentes que tiveram menor redução de atividades de alteração na Revisar a estratégia e definir o Pivô.
prioridade. Blockchain real ou de testes.
Periodicidade da análise Diário Semanal Ao termino da iteração
Responsável pela análise Gerente do Projeto Gerente do Projeto Gerente do Projeto
Relatórios Não se Aplica. Relatório do Projeto Relatório do Projeto
Informações para Divulgação
O Gerente do Projeto deverá
O Gerente do Projeto deverá
O Gerente do Projeto deverá apresentar o resultado apresentar o resultado do indicador a
Procedimento de divulgação apresentar o resultado do indicador a
do indicador a equipe na reunião diária. equipe na reunião diária e encaminhar
equipe na reunião diária.
as ações necessárias aos envolvidos.
Periodicidade de divulgação Ao final da iteração Semanal Ao final da iteração

Responsável pela divulgação Gerente do Projeto Gerente do Projeto Gerente do Projeto
Gerente do Projeto, Time do Projeto e
Partes Interessadas Gerente do Projeto e Time do Projeto Gerente do Projeto e Time do Projeto
Patrocinadores
58
ANEXO I – QUESTIONÁRIO DE AVALIAÇÃO DO PRODUTO.

59
ANEXO J – QUESTIONÁRIO DE AVALIAÇÃO DO PROCESSO
FUNDAÇÃO EDSON QUEIROZ

UNIVERSIDADE DE FORTALEZA
Mestrado em Informática Aplicada
PESQUISA PARA AVALIAÇÃO DE RELEVÂNCIA DO PROCESSO PROPOSTO

PARA APOIAR O DESENVOLVIMENTO DE PRODUTOS DE SOFTWARE
ORIENTADOS À CADEIA DE BLOCOS (BLOCKCHAIN)
Esta pesquisa busca avaliar por pares a clareza e contribuições do processo proposto neste trabalho para apoiar
empresas Startups a desenvolverem produtos de software orientados a cadeia de blocos (Blockchain).
Agradecemos antecipadamente sua colaboração.
PARTE I – CARACTERIZAÇÃO DO ENTREVISTADO

01. Cargo/Função: 02. Tempo de Experiência na Função:
a) Gerente de Projeto a) até 3 anos
b) Projetista/Desenvolvedor (Programador) b) de 3 anos a 6 anos
c) Analista de Testes c) de 6 anos a 9 anos
d) Analista de Requistos/Negócios d) Acima de 9 anos
03. Conhecimento Prévio em Blockchain: 04. Nível de Escolaridade:
a) Desconhece o Conceito a) 2º. Grau ou Nível Médio
b) Conhece o conceito mas nunca trabalhou b) Superior Incompleto
c) Já trabalhou c) Superior Completo
d) Especialização
e) Mestrado
f) Doutorado
05. Vivência em Empresas Startup:
a) Conhece o modelo de empresa mas
b) Já trabalhou em Startup atuou
nuncatrabalhou
c) Possui uma Startup
PARTE II – AVALIAÇÃO DO PROCESSO

Este processo é produto de um estudo teórico e da execução de uma experiência de uso, onde foi desenvolvida uma aplicação
que possibilita realizar uma eleição onde todos os registros dessa eleição são rastreáveis e imutáveis através da plataforma
Blockchain Ethereum. Solicitamos que, se possível, deixe suas contribuições para melhoria deste processo.
06. O processo proposto é de fácil entendimento/usabilidadepara o leitor.
( ) Discordo fortemente ( ) Discordo ( ) Nem concordo nem discordo ( ) Concordo ( ) Concordo fortemente
Sugestões de Melhorias / Comentários:
__________________________________________________________________________________________
__________________________________________________________________________________________
____________________________________________________________________________________
07. As atividades citadas no processo estão adequadaspara desenvolvimento de um produto de software.
__________________________________________________________________________________________
__________________________________________________________________________________________
____________________________________________________________________________________
08. A documentação gerada no processo é adequada.
60
__________________________________________________________________________________________
__________________________________________________________________________________________
____________________________________________________________________________________
09. O processo possui características de leveza que favorecem a aplicação no âmbito de uma Startup.
__________________________________________________________________________________________
__________________________________________________________________________________________
____________________________________________________________________________________
10. O processo possui características específicas que abordam a teconologia Blockchain.
__________________________________________________________________________________________
__________________________________________________________________________________________
____________________________________________________________________________________
Caso possível, realize a análise do processo destacando pontos fortes, pontos fracos e oportunidades de melhoria
que foram identificados para o processo.
Pontos Fortes: ______________________________________________________________________________
__________________________________________________________________________________________
Pontos Fracos: ______________________________________________________________________________
__________________________________________________________________________________________
Oportunidades de Melhoria:___________________________________________________________________
__________________________________________________________________________________________
Agradecemos sua participação.
MIA – Mestrado em Informática Aplicada Unifor – Engenharia de Software
Aluna: Samantha Kelly Soares de Almeida e Professor Orientador: Dr. Adriano Bessa

1.uma Abordagem para o Desenvolvimento de Softwares Que Utilizam Blockchain - Compressed

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

1.uma Abordagem para o Desenvolvimento de Softwares Que Utilizam Blockchain - Compressed

Enviado por

Direitos autorais:

Formatos disponíveis

FUNDAÇÃO EDSON QUEIROZ

SAMANTHA KELLY SOARES DE ALMEIDA

UMA ABORDAGEM PARA O DESENVOLVIMENTO DE SOFTWARES QUE

UMA ABORDAGEM PARA O DESENVOLVIMENTO DE SOFTWARES QUE

Dissertação apresentada ao Curso de Mestrado

Orientador: Prof. Dr. Adriano Bessa

Dissertação (Mestrado Acadêmico) - Universidade de Fortaleza. Programa de Mestrado em

1. Desenvolvimento de Software. 2. Processo. 3. Blockchain. 4. Startup. I. ALBUQUERQUE,

Agradeço a Deus por seu amor, misericórdia e providência em todos os momentos

Não tenha medo da vida, tenha medo de não

Ultimamente a tecnologia de Cadeia de blocos (Blockchain) vem ganhando visibilidade no

Palavras-chave: Desenvolvimento de Software, Processo, Blockchain, Startups.

Keywords: Software Development, Process, Blockchain, Startup.

Figura 1 – Camadas da engenharia de software ....................................................................... 24

Figura 2 – Princípios do Pensamento Enxuto........................................................................... 27

Figura 3 – Exemplo de mapeamento do fluxo de valor ............................................................ 28

Figura 4 – Ilustração de Fluxo de Contínuo Lean .................................................................... 29

Figura 5 – Circuito de Reação .................................................................................................. 30

Figura 6 – Funcionamento de uma transação na Cadeia de blocos (Blockchain) .................... 35

Figura 7 – Funcionamento de contratos inteligentes ................................................................ 38

Figura 8 – Vantagens de um contrato inteligente ..................................................................... 40

Figura 9 – Ciclo de vida de uma transação bitcoin................................................................... 42

Figura 10 – Macro atividades de um processo de abertura de startup ...................................... 45

Figura 11 – Framework teórico/tecnológico ............................................................................ 50

Figura 12 – Resumo das características das personas identificadas ......................................... 53

Figura 13– Registro de transações ............................................................................................ 54

Figura 14 – Criar Contrato – Permite o registro do contrato de votação na Cadeia de blocos

Figura 15 – Criar Contrato – Permite o registro do contrato de votação na Cadeia de blocos

Figura 16 – Cadastrar Candidato – Permite o cadastro do candidato relacionado com o

Figura 17 – Cadastrar Candidato – Confirmação do registro do candidato relacionado com o

Figura 19 – Encerrar votação – Exibição do resultado da votação. ......................................... 57

Figura 20 – Representação da arquitetura proposta.................................................................. 58

Figura 21 – Instanciação do objeto Web3 ............................................................................... 61

Figura 22 – Compilação do arquivo.sol.................................................................................... 62

Figura 23 – Instanciação do objeto do contrato ........................................................................ 62

Figura 25 – Chamada à função de implantação do contrato..................................................... 63

Figura 27 – Teste da Criação do Contrato ................................................................................ 64

Figura 28 – Teste do registro de candidatos ............................................................................. 65

Figura 29 – Teste do registro de votos nos candidatos ............................................................. 66

Figura 30 – Teste da consistência de votos nos candidatos ...................................................... 66

Figura 31 – Teste da consistência da quantidade total de votos ............................................... 67

Figura 32 – Resultados dos testes com sucesso ........................................................................ 67

Figura 33 – Resultados dos testes com falha ............................................................................ 68

Figura 34 –Representação gráfica do fluxo do processo .......................................................... 15

Figura 35 – Representação gráfica do perfil técnico dos entrevistados ................................... 30

Figura 36 – Representação gráfica da experiência profissional dos entrevistados................... 31

Figura 37 – Representação gráfica do conhecimento prévio em blockchain dos entrevistados

Figura 38 – Representação gráfica do nível de escolaridade dos entrevistados ....................... 32

Figura 39 – Representação gráfica da vivência em startups dos entrevistados ........................ 32

Quadro 1 – Composição da equipe ................................................................................. 48

2.1.1 Conceitos de software ................................................................................. 21

2.1.2 Conceitos de engenharia de software .......................................................... 24

2.1.3 Processo de software ................................................................................... 26

2.1.4 Metodologia Lean ....................................................................................... 26

2.1.4.1 Lean Startup ......................................................................................... 29

2.2.1 Cadeia de Blocos (Blockchain) ...................................................................... 33

2.2.1.1 Características ......................................................................................... 35

2.2.2 Contratos inteligentes ..................................................................................... 37

2.2.3 Bitcoin ............................................................................................................ 41

2.3 STARTUP ...................................................................................................................... 43

3.1.2 Domínio de aplicação ..................................................................................... 47

3.2 MATERIAIS E MÉTODOS........................................................................................... 48

3.2.1 Equipe ............................................................................................................ 48