UNIVERSIDADE TECNOLÓGICA FEDERAL DO PARANÁ DEPARTAMENTO ACADÊMICO DE INFORMÁTICA BACHARELADO EM CIÊNCIA DA COMPUTAÇÃO

Transcrição

1 UNIVERSIDADE TECNOLÓGICA FEDERAL DO PARANÁ DEPARTAMENTO ACADÊMICO DE INFORMÁTICA BACHARELADO EM CIÊNCIA DA COMPUTAÇÃO MARIELLY TAMIRES LOURENÇO FREITAS ADAPTAÇÃO DO PRODUTO BACKLOG PARA GERAÇÃO DE SCENARIOS UTILIZANDO DESENVOLVIMENTO DIRIGIDO A COMPORTAMENTO TRABALHO DE CONCLUSÃO DE CURSO PONTA GROSSA 2017

2 MARIELLY TAMIRES LOURENÇO FREITAS ADAPTAÇÃO DO PRODUTO BACKLOG PARA GERAÇÃO DE SCENARIOS UTILIZANDO DESENVOLVIMENTO DIRIGIDO A COMPORTAMENTO Trabalho de Conclusão de Curso apresentado como requisito parcial à obtenção do grau de Bacharel em Ciência da Computação, do Departamento Acadêmico de Informática, da Universidade Tecnológica Federal do Paraná. Orientador: Prof a Dr a. Simone Nasser Matos PONTA GROSSA 2017

3 Ministério da Educação Universidade Tecnológica Federal do Paraná Câmpus Ponta Grossa Diretoria de Graduação e Educação Profissional Departamento Acadêmico de Informática Bacharelado em Ciência da Computação TERMO DE APROVAÇÃO ADAPTAÇÃO DO PRODUTO BACKLOG PARA GERAÇÃO DE SCENARIOS UTILIZANDO DESENVOLVIMENTO DIRIGIDO A COMPORTAMENTO por MARIELLY TAMIRES LOURENÇO FREITAS Este Trabalho de Conclusão de Curso (TCC) foi apresentado em 09 de Novembro de 2017 como requisito parcial para a obtenção do título de Bacharel em Ciência da Computação. A candidata foi arguida pela Banca Examinadora composta pelos professores abaixo assinados. Após deliberação, a Banca Examinadora considerou o trabalho aprovado. Simone Nasser Matos Prof(a). Orientador(a) Gleifer Vaz Alves Membro titular Vinícius Camargo Andrade Membro titular Prof(a). Helyane Bronoski Borges Responsável pelo Trabalho de Conclusão de Curso Prof. Saulo Jorge Beltrão de Queiroz Coordenador do curso - A Folha de Aprovação assinada encontra-se na Coordenação do Curso -

4 RESUMO FREITAS, Marielly T. Lourenço. Adaptação do Product Backlog para geração de Scenarios utilizando Desenvolvimento Dirigido a Comportamento Trabalho de Conclusão de Curso Bacharelado em Ciência da Computação - Universidade Tecnológica Federal do Paraná. Ponta Grossa, Scrum é um método ágil para coordenar projetos e é utilizado no desenvolvimento de software. Embora seja considerado uma metodologia ágil de desenvolvimento, Scrum é um framework que auxilia na coordenação dos processos de software, definindo fases que determinam as tarefas que devem ser realizadas até que uma parcela do projeto seja completada. Nas primeiras fases do Scrum (Iniciação, Planejamentos e Estimativas) é criado uma lista com as funcionalidades e suas descrições do que o sistema deve fazer. Esta lista é chamada de Product Backlog e seus itens seguem o formato de User Story, que são cenários que contém descrições simples, escritas em linguagem natural e que explicam como as funcionalidades devem ser executadas. O conceito de Scenarios é utilizado no desenvolvimento Dirigido a Comportamento (DDC) (Behavior Driven Development BDD) e permite que escopos menores sejam definidos para que possam ser testados, o que garante a qualidade do sistema. Outro conceito semelhante aos Scenarios, são asuser Story inseridas como itens do Product Backlog, que por sua vez são definições de funcionalidades requisitadas pelo Dono do Produto. A validação da User Story não é realizada de forma automatizada, por esse motivo o uso de Scenarios em BDD pode ser utilizado para resolver este problema, propondo um mecanismo de tradução (uma ferramenta de conversão) em que dado uma entrada, itens do Product Backlog, a ferramenta converte em uma classe de teste que contém os Scenarios que serão testados. Este trabalho criou um formalismo de conversão baseado em uma Gramática Livre de Contexto (GLC) entre Product Backlog e Scenarios, automatizando não somente os testes posteriores que serão feitos utilizando ferramentas BDD, como a parte de análise de requisitos inicial descrita através de itens do Product Backlog. Foi proposto um formato modificado de Product Backlog, denominado MPBacklog (Modified Product Backlog), em que possam ser inseridas informações que venham servir de entrada para a geração dos Scenarios das ferramentas BDD. Por meio do formalismo, usando a Backus-Naur-Form (BNF) nas suas descrições, realiza-se a integração entre o formato de analise de requisitos utilizada no processo de desenvolvimento de software (Scrum - Product Backlog) e Scenarios de teste presentes em ferramentas BDD. Palavras-chaves: Scrum. BDD. Cenários. Testes Automatizados. BNF.

5 ABSTRACT FREITAS, Marielly T. Lourenço. Adaptation of the Product Backlog for the Generation of BDD Scenarios p. Work of Conclusion Course Graduation Bachelor of Computer Science - Federal Technology University - Paraná. Ponta Grossa, Scrum is an agile method used to coordinate projects and it is used in software development. Although it is considered a methodology, Scrum is a framework that assist in software process coordination, defining phases that determine which tasks must be finished until a certain portion of the project is complete. On the first steps of Scrum, a list is created with the system s functionalities and descriptions. This list is called Product Backlog and it s items follow the User Story format, which are scenarios that contain simple descriptions, written in the natural language and explain how the functionalities must be executed. The concept of Scenarios are used in the Behavior Driven Development (BDD) and allow the smaller scopes to be defined so that they can be tested, assuring the quality of the system. A similar concept to Scenarios are User Stories inserted as items of the Product Backlog, which are in turn defined by the functionalities described by the Product Owner. User Story validation is not an automated process, therefore the use of BDD Scenarios can solve this issue. This paper created a conversion formalism between the Product Backlog and Scenarios, automating not only further tests, but the initial requirement analysis as well. This paper also proposes a modified format of the Product Backlog in which new information can serve as input for the Scenarios of BDD tools. By means of the proposed formalism, using Backus-Naur-Form (BNF), it accomplishes the integration between a software development process (Scrum - Product Backlog) and a behavior driven development (BDD) for the automated generation of tested using as a base scenarios created during the requirement analysis. Key-words: Scrum. Behavior Driven Development. Agile Methodology. Test Automation. Scenarios.

6 LISTA DE ILUSTRAÇÕES Figura 1 Vantagens da Utilização de Cenários Figura 2 Exemplo de um Cenário com Fluxo Básico e Alternativo Figura 3 Ferramentas BDD e suas principais caracteristicas Figura 4 Outras caracteristicas das ferramentas apresentadas na Figura Figura 5 Exemplo de um Feature usando Cucumber Figura 6 Camadas de execução de testes com Cucumber Figura 7 Scrum vs. Modelo Tradicional de Desenvolvimento Figura 8 Template de um Epico criado a partir de duas Sprint Figura 9 Representação de um Product Backlog Figura 10 Representação de um item do Product Backlog Figura 11 Template de um Cenário, Backlog Comum e MPBacklog Figura 12 Diagrama de um Cenário, Backlog Comum e MPBacklog Figura 13 Fases do processo de desenvolvimento utilizando Scrum Figura 14 Fases do uma Sprint Figura 15 Etapa do processo de desenvolvimento utilizando o MPBacklog Figura 16 Fase de teste sem a utilização MPBacklog Figura 17 Integrando o MPBacklog com Scrum Figura 18 BNFs Backlog Comum, MPBacklog e Scenario BDD Figura 19 Produção: tipousuario Figura 20 Produção: parametro Figura 21 Produção: acao Figura 22 Produção: lista_op Figura 23 Produção: logico Figura 24 Produção: como Figura 25 Produção: eu Figura 26 Produção: posse Figura 27 Produção: assim Figura 28 Produção: acao_op Figura 29 Produção: resultados Figura 30 Produção: feature Figura 31 Produção: background Figura 32 Produção: given Figura 33 Produção: when Figura 34 Produção: then Figura 35 Produção: scenario Figura 36 Produção: scenario_otl Figura 37 Produção: logico_bdd Figura 38 Produção: eu_bdd Figura 39 Produção: eu_posse_bdd Figura 40 Produção: acao_bdd_op Figura 41 Produção: assim_bdd Figura 42 Produção: parametros_bdd Figura 43 Produção: resultados_bdd Figura 44 Produção: name Figura 45 Fluxo de Conversão Figura 46 steps de um Feature de Teste... 61

7 LISTA DE QUADROS Quadro 1 Template de uma User Story Quadro 2 Exemplo de um Feature para uma operação de soma de uma calculadora. 19 Quadro 3 Nome para o Scenario Quadro 4 Sintaxe de um Scenario Quadro 5 Utilização das palavras reservadas Given, And, When, Then Quadro 6 Exemplo de representação boa e ruim de um objetivo de trabalho Quadro 7 Representação e Comparação de Cenários, User Story, Backlog e Feature BDD Quadro 8 Formato User Story Quadro 9 Itens - Backlog Comum Quadro 10 Fluxo de Aceitação BNF: Backlog Comum Quadro 11 Fluxo de Aceitação BNF:Backlog Comum com mais de uma operação Quadro 12 Itens - MPBacklog Quadro 13 Fluxo de Aceitação BNF: MPBacklog Quadro 14 Fluxo de Aceitação BNF: MPBacklog com resultados Quadro 15 Item - Scenarios BDD Quadro 16 Fluxo de aceitação BNF: Feature Quadro 17 Fluxo de aceitação BNF: Scenario BDD... 59

8 LISTA DE ABREVIATURAS E SIGLAS BDD TDD DDC BNF Behavior Driven Development Test Driven Development Desenvolvimento Dirigido a Comportamento Backus-Naur-Form

9 SUMÁRIO 1 INTRODUÇÃO OBJETIVOS Objetivo Geral Objetivos Específicos ORGANIZAÇÃO DO TRABALHO CENÁRIOS CONCEITOS E APLICAÇÕES DE CENÁRIOS VANTAGENS DE USAR CENÁRIOS NO DESENVOLVIMENTO DE SOFTWARE ELEMENTOS PARA DESCRIÇÃO DE UM CENÁRIO USER STORY CONSIDERAÇÕES FINAIS DESENVOLVIMENTO DIRIGIDO A COMPORTAMENTO BDD: VISÃO GERAL FUNCIONAMENTO DO BDD DEFINIÇÃO DE OBJETIVOS COM BDD FERRAMENTAS BDD FERRAMENTA: CUCUMBER CONSIDERAÇÕES FINAIS SCRUM CONCEITOS FASES DO SCRUM PRODUCT BACKLOG CONSIDERAÇÕES FINAIS MPBACKLOG: UMA PROPOSTA DE MODIFICAÇÃO DO PRODUCT BACK- LOG PROPOSTA DE CONVERSÃO FASE DE IDENTIFICAÇÃO, DESCRIÇÃO E CONVERSÃO DEFINIÇÕES DE BNF(BACKUS-NAUR FORM) DIAGRAMA DE SINTAXE (BNF) CONSIDERAÇÕES FINAIS CENÁRIO DE TESTE ESTUDO DE CASO FLUXO DE ACEITAÇÃO: BACKLOG COMUM FLUXO DE ACEITAÇÃO: MPBACKLOG FLUXO DE ACEITAÇÃO: SCENARIO BDD CONVERSÃO DE MPBACKLOG PARA SCENARIO BDD RESULTADOS OBTIDOS CONSIDERAÇÕES FINAIS CONCLUSÃO TRABALHOS FUTUROS REFERÊNCIAS APÊNDICE A - Lista de Produções BNF APÊNDICE B - BNFs Backlog Comum, MPBacklog e Scenario BDD ANEXO A - Feature de Teste... 73

10 8 1 INTRODUÇÃO As metodologias ágeis ganharam espaço no processo de desenvolvimento de software, inserindo novos conceitos e ferramentas que possam automatizar e melhorar o processo de desenvolvimento, garantindo não só a qualidade do software como também atendendo as requisições do cliente(cohn, 2009). Considerando o fato de que as metodologias ágeis tem ganhado espaço, e junto delas ferramentas que auxiliam no processo, foi escolhido uma metodologia ágil e uma ferramenta de automação de teste para melhorar o processo de desenvolvimento. A metodologia ágil Scrum foi a escolhida para integrar uma ferramenta de automação de teste chamada BDD (Behavior Driven Development), pela sua versatilidade e flexibilidade de integração com novas tecnologias. Outras ferramentas BDD (RSpec, JBehave, Jasmine) poderiam ter sido utilizadas, pois essas ferramentas utilizam as palavras-chaves que descrevem um Scenario, entretanto não se pode afirmar o mesmo sobre todas as metodologias ágeis, já que a proposta do trabalho é modificar o Product Backlog e ele só existe no Scrum Scrum é uma metodologia ágil usada para criar um novo projeto ou serviço (SCRUM- STUDY, 2016). Para Schwaber e Sutherland (2016), Scrum é definido como um framework para desenvolvimento de produtos e serviços em qualquer tipo de indústria independente da sua complexidade. Existem processos que devem ser executados quando aplicado o Scrum, são esses: Iniciação, Estimativa e Planos, Implementação, Revisão e Retrospectiva e Release (SCRUMSTUDY, 2016). Constatou-se durante os estudos que o Scrum não abrange conceitos de cenários durante a construção das User Story, as descrevendo somente no formato proposto por Beck (2000). Os cenários são descrições estruturadas em linguagem natural de como as funcionalidades devem ser executadas. Considerando que a validação das User Story devem ser feitas a priori, não é possível avaliar os resultados de imediato, pois a validação não é automatizada. Uma das formas de resolver esta dificuldade é aplicar o conceito de Desenvolvimento Dirigido a Comportamento (DDC) (Behavior Driven Development BDD). O BDD foi desenvolvido para sanar a divergência de linguagens entre os desenvolvedores, clientes e usuários (KUDRYASHOV; STEAD; NORTH, 2015). Devido a este fato foi proposto um método de formalização de comunicação que pudesse ser compartilhado pelos envolvidos no projeto. O principio do BDD é fazer uma tradução da linguagem natural descrita pelo cliente, para uma linguagem de programação na qual os desenvolvedores possam codificar as funcionalidades (AMODEO, 2015). Ferramentas foram criadas para realizar traduções de forma automatizada de frases ditas pelo cliente para cenários que serão implementados no sistema (CHELIM- SKY et al., 2012; WYNNE; HELLESOY, 2014).

11 9 De acordo com North (2006), criador do método de teste automatizado BDD, o ideal é que todos os envolvidos no projeto pudessem compartilhar de uma mesma linguagem, assim seria possível minimizar situações em que as funcionalidades do sistema sejam interpretadas de forma incorreta. A Linguagem Ubíqua surge para preencher a lacuna de comunicação, criando uma linguagem padrão que seja concisa e de fácil entendimento, além de poder ser compartilhada entre os times, tanto o de desenvolvimento quanto os clientes e usuários. Quando aplicada essa técnica, é possível escrever cenários que especificam de forma sucinta o que os componentes do software deverão responder quando executados (EVANS, 2003). O BDD realiza testes que são realizados baseado nas informações que o cliente forneceu, utilizando os possíveis resultados que a execução irá utilizar como entrada, e é papel do desenvolvedor implementar as funções que irão agir sobre esses dados. Essa forma de teste é conhecida como de "dentro para fora", pois a preocupação está no conteúdo estruturado do código e se ele atende as especificações do modelo requisitado, e não em como a função é implementada (WYNNE; HELLESOY, 2014). Neste contexto, este trabalho propõe a adaptação do Product Backlog utilizado no Scrum para gerar Scenarios BDD. A geração dos Scenarios deve ser feita utilizando como entrada os itens do MPBacklog (Modified Product Backlog), versão modificada do Product Backlog proposto nesse trabalho, e como saída as classes.features que apresentam os Scenarios nas ferramentas BDD. O enfoque do trabalho foi mostrar as semelhanças e possibilidade de traduzir um item do MPBacklog em Scenarios BDD. A metodologia Scrum não é alterada, somente o formato de escrita de um dos seus artefatos utilizado na análise de requisito. O formalismo de tradução foi proposto através da utilização de uma BNF (Backus-Naur-Form) em que é apresentado três gramáticas livres de contexto que apresentam as semelhanças entre o Product Backlog original, o MPBacklog e os Scenarios BDD. Os Scenarios BDD fazem parte de classes testáveis chamadas de Feature, e esses testes são escritos em linguagem natural, ou seja, a linguagem comum utilizada em diálogos. Os Scenarios podem ser escritos utilizando ferramentas de automatização de testes BDD tais como: JBehave, Cucumber, RSpec, Jasmine, entre outras (CHELIMSKY et al., 2012; WYNNE; HELLESOY, 2014; TOOLS, 2016). Para os testes realizados neste trabalho, foi utilizado a ferramenta BDD Cucumber, considerando sua popularidade e adaptação de várias linguagens de programação, logo é possível alcançar mais domínios de aplicações a ser testadas. O benefício da utilização do MPBacklog traduzido em Scenarios BDD é a diminuição do tempo de escrita de cenários para teste e a menor perda de informações. A implementação da conversão dos itens do MPBacklog em Scenarios não é apresentada neste trabalho, servindo de ideia para trabalhos futuros. A conversão não foi implementada,

12 10 logo, não foi feito o tratamento de aspectos da língua portuguesa como a morfologia das palavras e a tradução de um MPBacklog em Scenario BDD. 1.1 OBJETIVOS A seguir são apresentados os objetivos geral e específicos desse trabalho Objetivo Geral Adaptar o Product Backlog presente na metodologia Scrum de forma a permitir a definição de Scenarios em BDD para geração de testes automatizados Objetivos Específicos Os objetivos específicos desta proposta são: Comparar as principais ferramentas que implementam o BDD. Definir uma BNF (Backus-Naur Form) para a adaptação da alteração do Product Backlog em Scenarios BDD. Aplicar um cenário de teste em uma das fases do Scrum utilizando uma ferramenta BDD (Behavior Driven Development). Analisar os resultados obtidos. 1.2 ORGANIZAÇÃO DO TRABALHO Esse trabalho está dividido em sete capítulos. O capítulo 2 explica o conceito de cenários de forma geral, e qual o papel da sua utilização no processo de desenvolvimento de software. O capítulo 3 apresenta o conceito do BDD, as ferramentas mais utilizadas e suas sintaxes. O capítulo 4 descreve a metodologia ágil Scrum, contendo uma seção que apresenta o Product Backlog que serve de entrada para realização desse trabalho. O capítulo 5 explica o necessário para que seja possível realizar a conversão de um Backlog para o Scenario BDD, denominado neste trabalho de MPBacklog. O estudo de caso escolhido para realizar os testes do trabalho é apresentado no Capítulo 6. O Capítulo 7 apresenta as propostas de trabalhos futuros e as conclusões deste trabalho de pesquisa.

13 11 2 CENÁRIOS Cenário é uma forma de descrever funcionalidades de um sistema sem a necessidade de especificar detalhes da sua implementação, focando somente na sequência de passos que devem ser seguidos para interagir com o sistema e quais são as respostas obtidas. Esse capítulo apresenta os principais conceitos sobre cenários. A Seção 2.1 descreve os conceitos e as aplicações de Cenário. As vantagens de utilizar Cenários no desenvolvimento de software é apresentada na Seção 2.2. Os elementos de descrição de um Cenário são explicados na Seção 2.3. A Seção 2.4 relata sobre o que são User Story (Estória de usuário). As considerações finais do capítulo são apresentadas na Seção CONCEITOS E APLICAÇÕES DE CENÁRIOS GmbH (2016) explica que os Cenários são importantes para permitir que os desenvolvedores consigam entender a forma como a mente dos usuários funcionam em termos de usabilidade das funcionalidades criadas por eles. Os cenários permitem descrever detalhadamente como as funcionalidades do sistema funcionam ou expõe em alto nível as ações que podem ser críticas dentro de um projeto, porém, sem indicar detalhadamente como elas são desenvolvidas ou corrigidas (AMBLER, 2014). Uma boa forma de descrever as funcionalidades do sistema é por meio da utilização das User Story (Estórias de Usuário)(PICHLER, 2013), explicada mais detalhadamente na Seção 2.4 desse capítulo. Ambler (2014) descreve os Cenários como uma técnica adaptiva, pois eles podem ser aplicados em vários processos e fases do desenvolvimento do software. Os Cenários são utilizados comumente na conversão de Casos de Uso para diagramas de Sequência ou em descrições de Caso de Uso. Os cenários são usados no desenvolvimento de softwares e em diversas outras áreas, como na descrição de economia de uma determinada área geográfica ou ambiente operacional, logísticas de empresas, entre outras. O papel dos cenários é descrever uma sequência de passos a serem seguidos e algumas vezes, dependendo de qual área eles foram aplicados, os resultados que se espera ter quando sua execução é solicitada pelo usuário (BERGMANN, 2003). Nesse trabalho é utilizado o modelo de cenário proposto por Larman (2004), em que os cenários são utilizados nas descrições de Casos de Uso durante o desenvolvimento de software. GmbH (2016) explica que os Cenários são importantes para permitir que os desenvolvedores consigam entender a forma como a mente dos usuários funcionam em termos de usabilidade das funcionalidades criadas por eles.

14 12 Larman (2004) descreve Casos de Uso como narrativas em texto que podem ser utilizadas para descobrir e registrar requisitos, que representam uma especificação de software, em que são definidos quais são os serviços que o software deve fornecer (SOMMERVILLE, 2006). Durante o processo de aprendizagem de utilização da funcionalidade, o usuário não precisa saber os termos técnicos, tais como métodos, funções, variáveis, entre outros, que foram utilizados para apresentar aquelas informações na tela. Entretanto, é possível perceber detalhadamente qual o papel dessa funcionalidade e quais são as respostas que ela deve fornecer para os atores envolvidos. Os Cenários focam nas necessidades de usabilidade do usuário ao invés dos processos técnicos que compõem a funcionalidade, além de serem escritos em uma linguagem natural e comum para todos os que tiverem acesso às descrições definidas. 2.2 VANTAGENS DE USAR CENÁRIOS NO DESENVOLVIMENTO DE SOFTWARE Bergmann (2003) descreve cenários como uma técnica que é utilizada no processo de elicitação de requisitos e que embora seja aplicado durante essa etapa, alguns autores tem proposto a utilização da descrição de cenários em outras fases do processo de desenvolvimento. Em sua dissertação, Bergmann (2003) apresenta diversos autores que acreditam nas vantagens da utilização de cenários em algumas fases, como por exemplo, Carroll (1995) que acredita na melhoria da comunicação entre clientes e desenvolvedores ao utilizar cenários, pois fica melhor ilustrado os desejos do cliente. Filippidou (1998) também foi citado por sua utilização de cenários durante as fases de elicitação, projeção, análise, avaliação de requisitos e na captura de justificativas e geração de interfaces. Carroll (1995) propõe mais algumas tarefas que os cenários podem e devem cumprir no auxílio de um bom desenvolvimento de software. A Figura 1 descreve as funcionalidades da utilização de cenários, sendo essas: especificações da usabilidade do sistema, os requisitos do sistema, uma visão geral do sistema, desenvolvimento racional que aponta as consequências da escolha de determinadas funcionalidades inseridas no sistema, metáforas sobre as interfaces dos usuários e como devem ser utilizadas, as funções do sistema, os protótipos, os modelos de objetos requisitados pelo sistema e uma documentação orientada a sequência de tarefas.

15 13 Figura 1 Vantagens da Utilização de Cenários Fonte:Rosson e Carroll (2003) A principal vantagem de utilizar cenários durante o processo de desenvolvimento de software é sua informalidade nas descrições, embora ainda existam técnicas e padrões a serem utilizados para garantir que todos os itens essenciais de criação de cenários foram atendidos. 2.3 ELEMENTOS PARA DESCRIÇÃO DE UM CENÁRIO Para a criação de um cenário, Larman (2004) definiu alguns termos que são utilizados. Os principais são: atores; cenários; e casos de uso. Atores podem ser identificados como algo com comportamento, seja uma pessoa que interage com o sistema, um outro sistema de computador que interage diretamente ou indiretamente com o sistema sendo desenvolvido e, por fim, uma organização que possa ser utilizada como requerente ou requerida. As coleções de cenários descritos são chamados de caso de uso, em que é possível determinar se aquelas sequências de ações são sucedidas ou mal sucedidas pelo sistema, analisando a resposta positiva ou negativa que o sistema deve fornecer em cada um dos passos definidos nos cenários. Os Cenários são estórias escrita passo-a-passo que descrevem a utilização de uma funcionalidade quando um ou mais atores interagem com o sistema. Os atores precisam ter uma motivação, conhecimento e capacidade para utilizar a funcionalidade e os cenários listam quais

16 14 as sequências de passos que são necessários para que a interação possa ser bem-sucedida e quais os fluxos e respostas alternativas que a aplicação deve devolver quando o ator ou aplicação tiver alguma falha. Com a criação dos Cenários é possível analisar erros, reações e as principais dificuldades que os usuários podem ter ao usar as aplicações do sistema (ROSSON; CARROLL, 2003). Pré-condições sobre o cenário podem ser adicionadas para informar quais os pré-requisitos básicos para que os atores possam iniciar os passos do Cenário ou as necessidades essenciais que o sistema requer para ser iniciado. A Figura 2 apresenta um exemplo de Cenário para retirar dinheiro de um caixa eletrônico. Figura 2 Exemplo de um Cenário com Fluxo Básico e Alternativo Fonte: Lucidchart (2015) A Figura 2 descreve os passos que o usuário executa para utilizar a funcionalidade com

17 15 sucesso, ou em caso de falha, quais são os possíveis passos alternativos que devem ser seguidos ou entregues como respostas do sistema. 2.4 USER STORY Uma User Story (Estória do Usuário) descreve como alguém utiliza, ou deve utilizar, o produto ou sistema, ou ainda definições de funcionalidades que o sistema deve conter. A User Story deve ter um nome, uma narrativa e um critério de aceitação. A vantagem de utilizar User Story é focar apenas o que deve ser feito e não nos detalhes de como será feito (INSTITUTE, 2016). Rubin (2012) e Patton (2014) mencionam Jeffries, Anderson e Hendrickson (2000) por terem descrito as User Story através do método 3 Cs, que são: Cartões, Conversas e Confirmação. Os cartões são pedaços de papéis, indexados e padronizados, em que é escrito o que o cliente deseja ver ou o que gostaria que tivesse no software. A Conversa, é uma reunião com o cliente para obter detalhes do software que será construido. A Confirmação é uma forma para confirmar que as especificações dadas pelo cliente foram atendidas com sucesso. Os cartões são uma forma do usuário informar as funcionalidades que ele deseja que o sistema possua, cada funcionalidade é escrita em um cartão diferente e conforme a quantidade de cartões aumenta, é possível priorizar os cartões, ou seja, priorizar as funcionalidades informadas neles e então ser organizados em algum tipo de estrutura que os mapeie baseado nas suas prioridades. A Conversa representa as definições detalhadas sobre o papel do usuário e como ele imagina que a funcionalidade deve funcionar. Nessa etapa, o usuário pode fazer perguntas e os requerimentos do sistema podem ser melhor entendido. Patton (2014) coloca ênfase em dizer que a etapa da conversa cliente e desenvolvedores trabalham juntos, a fim de encontrar a melhor solução para um problema que os dois entendam a respeito. A Confirmação é a forma de checar se o que produto desenvolvido é o que foi pedido. Assim como nos Cenários, as User Storys descrevem passos de como uma funcionalidade deve funcionar, porém sem utilizar uma linguagem natural, assim como apresenta o Quadro 1. Quadro 1 Template de uma User Story Como um [ator], Eu [ quero devo] [ação] Para que eu possa [alcançar o objetivo] Fonte: Institute (2016) O Ator é o dono da Story descrita, logo deve ser bem especificado qual o papel dele, por exemplo: Administrador, Cliente, Usuário, entre outros. Ação é o que o ator deseja fazer para

18 16 alcançar outro estado da aplicação. Objetivo é o que o ator pretende ao realizar determinada ação. Algumas outras metodologias de desenvolvimento de software utilizam em seus processos de testes o conceito de User Story. Na metodologia Scrum, User Story são utilizadas como entrada para criar o Product Backlog (COHN, 2009). No Product Backlog são listadas as funcionalidades, funções, requisitos, aprimoramentos, e possíveis formas de consertar ou adicionar mudanças nos lançamentos futuros do produto. Os itens do Product Backlog possuem atributos como descrição, ordem, estimativa de tempo e valor (INSTITUTE, 2016), e será aprofundado na Seção CONSIDERAÇÕES FINAIS Este capítulo apresentou a origem, conceitos e finalidade dos Cenários e User Story. Ambos são focados no que o sistema deve fazer e não em sua implementação. A importância desse capítulo é para exemplificar o formato de User Story utilizado no Product Backlog, que é explicado na Seção 4.3, e de onde os Scenarios BDD (detalhado na Seção 3.2) retiram seus fundamentos. Tanto User Story quanto Scenarios BDD retiram sua fundamentação de Cenários, em que a utilização de elementos de identificação são necessários para melhor descrição de uma funcionalidade do sistema, como por exemplo: Atores, Pré-condições e Fluxos de execução.

19 17 3 DESENVOLVIMENTO DIRIGIDO A COMPORTAMENTO O Desenvolvimento Dirigido a Comportamento (DDC) (Behavior Driven Development, BDD) é um método de implementar e testar funcionalidades baseadas em como o cliente as descreveu utilizando linguagem natural, não se preocupando a princípio com a forma como será implementada determinada funcionalidade e sim seu comportamento. Esse capítulo foi dividido de forma que a Seção 3.1 apresenta de forma geral o conceito do BDD, sua origem e porque começou a ser utilizado. A Seção 3.2 que descreve o funcionamento das ferramentas BDD, o formato de utilização da ferramenta e suas palavras-chaves. A Seção 3.3 explica a melhor forma de organizar os objetivos das funcionalidades ao utilizar ferramentas BDD. A Seção 3.4 apresenta a resposta para um dos objetivos definidos para realização desse trabalho, em que ferramentas são apresentadas e é feito a comparação entre as mais utilizadas, determinando assim um parâmetro de escolha da ferramenta utilizada nesse trabalho, que por sua vez é descrita na Seção 3.5. A Seção 3.6 apresenta as considerações finais deste capítulo. 3.1 BDD: VISÃO GERAL O conceito de Behavior Driven Development (BDD) foi criado devido necessidade de criar uma forma de comunicação entre desenvolvedores e as pessoas que iriam interagir com o sistema, sendo esses cliente ou usuários (KUDRYASHOV; STEAD; NORTH, 2015). Devido a forma como os problemas eram descritos pelos usuários, os desenvolvedores não conseguiam identificar as funcionalidades que o sistema deveria possuir para atender suas necessidades. Os usuários não entendiam as funcionalidades, visto que a linguagem utilizada pelos desenvolvedores possuía termos técnicos desconhecidos que não eram de seu conhecimento (WYNNE; HELLESOY, 2014). Desta forma, foi proposto um método de formalização de comunicação que pudesse ser compartilhado pelos envolvidos no projeto. Esse método faz uma tradução da linguagem natural descrita pelos usuários para uma linguagem de programação na qual os desenvolvedores conseguem codificar as funcionalidades (AMODEO, 2015). Após a proposta dessa formalização, surgiram ferramentas como: JBehave 1, Cucumber 2, RSpec 3, entre outras que são capazes de realizar traduções de forma automatizada. É necessário que aconteça uma tradução da linguagem natural utilizada pelos usuários

20 18 para os termos específicos das linguagens, porém ao realizar a tradução algumas informações são perdidas ou mal interpretadas. A Linguagem Ubíqua surge para suprir a necessidade de uma linguagem padrão, concisa e de fácil entendimento que seja compartilhada entre os dois times, tanto o de desenvolvimento quanto os clientes e usuários. Com a utilização dessa linguagem, é possível escrever cenários que especificam de forma sucinta o que os componentes do software deverão responder ao serem executados (EVANS, 2003). O propósito da utilização do BDD é fazer testes no código desenvolvido para a criação do software e encontrar falhas ou especificações não atendidas durante a fase de desenvolvimento. Diferentemente do Test Driven Development (TDD), versão do conceito de testes que utiliza as linguagens de desenvolvedor e usuários de forma separada, o BDD trabalha com a comunicação entre os times envolvidos com a criação do software utilizando uma mesma linguagem (AMODEO, 2015). Os testes são realizados descrevendo como uma funcionalidade deve ser executada, não as técnicas utilizadas. Essa forma de teste é conhecida como de dentro para fora, pois a preocupação está no conteúdo estruturado do código e se ele atende as especificações do modelo (WYNNE; HELLESOY, 2014). Uma das preocupações na qual o BDD tem foco é se os envolvidos no projeto conseguirão entender os resultados que os testes irão resultar, por isso a linguagem padronizada entre eles é tão importante, logo os testes não serão mais chamados de Testes, e sim, Especificações (Specifications) ou Funcionalidades (Features). 3.2 FUNCIONAMENTO DO BDD Como mencionado na seção anterior, o BDD utiliza uma linguagem especial para descrever as funcionalidades. Essa linguagem consiste de palavras-chaves que indicam alguma descrição, ação ou tempo. Os termos mais importantes são: Feature (Funcionalidade), Scenario (Cenário), Given (Dado), When (Quando), Then (Então), And (E) (ou But(Mas)). A base principal do BDD segue a tríade: Given, When, Then, que são as três palavras principais para a criação de uma boa classe de teste. Essas palavras são utilizadas tanto para avaliar o comportamento das aplicações ou dos objetos (CHELIMSKY et al., 2012). O Feature é o título para o teste, contendo uma breve narração do como a funcionalidade deve funcionar e um conjunto de cenários que irá servir de critério de aceitação do teste. O Quadro 2 ilustra um exemplo de um Feature para somar dois números. Com apenas o título e uma breve descrição é possível interpretar e encontrar soluções para o problema, sem ter a necessidade de conhecer detalhadamente a funcionalidade.

21 19 Quadro 2 Exemplo de um Feature para uma operação de soma de uma calculadora Feature: Soma de dois números In order to somar dois números As calculadora I want to somar um valor com outro valor A escrita dos Features é feita utilizando o próprio idioma do testador responsável pela implementação dos testes, considerando a necessidade de se moldar para cada ambiente geográfico, algumas ferramentas utilizam um método de tradução chamado Gherkin, que faz a tradução do inglês para outros idiomas. O método Gherkin compila o feature criado e que será executado pelas ferramentas, fazendo a tradução das palavras escritas no idioma escrito para o inglês e assim criado os steps (passos) dos scenarios daquele feature escrita (WYNNE; HELLE- SOY, 2014). Logo após a descrição do Feature, é necessário especificar os Scenarios que descrevem os steps (passos) do Feature, por isso elas devem ter precisão sobre o que fazer, para que o sistema encontre o que o Feature descreve. Um Scenario possível para o Feature: Soma de dois números é ilustrado no Quadro 3. Quadro 3 Nome para o Scenario Scenario: Soma números Os Scenarios são colocados após a cláusula I want to, formando uma lista de passos a serem seguidos. O nome do Scenarios não contém palavras reservadas, porém seu corpo irá especificar exatamente o que deve acontecer em determinadas circunstâncias e eles precisam seguir um modelo com palavras reservadas, assim como o Feature. O corpo de um Scenario contém três palavras reservadas principais, conforme apresenta o Quadro 4 (CHELIMSKY et al., 2012; AMODEO, 2015; WYNNE; HELLESOY, 2014; KUDRYASHOV; STEAD; NORTH, 2015). Quadro 4 Sintaxe de um Scenario Given descreve o contexto inicial do Scenario, indicando quais os parâmetros necessários para execução; When descreve as ações necessárias e requisitadas para a resolução do problema; Then descreve o resultado esperado das ações executadas; Fonte:Kudryashov, Stead e North (2015)

22 20 Existe outra palavra reservada utilizada para quando o contéudo do Scenario é complexo e então é necessário mais de uma condição para descrever as especificações do problema e mais passos a serem seguidos. A palavra And (ou But) é adicionada após a primeira condição Given ou após a condição final Then (KUDRYASHOV; STEAD; NORTH, 2015). O Quadro 5 ilustra um exemplo do uso do Given e Then. Quadro 5 Utilização das palavras reservadas Given, And, When, Then Scenario: Somar números Given: numero_1 e numero_2 And sejam eles inteiros When usuário somar Then o resultado será numero_1 + numero_2 A adição do termo And é para criar outra condição além da condição apresentada com o termo Given, logo, quando as ferramentas BDD interpretarem o Scenario escrito, mais uma condição será considerada para garantir que o teste cobriu todas as condições especificadas. O uso de pronomes não é uma descrição imprópria, pois a ferramenta ignora esses e outros termos, focando nos parâmetros que o Scenario possui e no seu comportamento, não na estrutura. 3.3 DEFINIÇÃO DE OBJETIVOS COM BDD Com o BDD os projetos são desenvolvidos analisando as funcionalidades do sistema e não o sistema de modo geral. As funcionalidades são entendidas individualmente, por exemplo, na criação de uma tela de login os testes devem ser feitos para validações dos campos de senha e usuário, porém o cliente apenas visualiza se o login deu acesso ao sistema ou não. O papel do BDD é analisar as funcionalidades de forma separada, caso a caso e só após os testes, pois o processo se preocupa em entender o sistema do ponto de vista do usuário, visualizando as funcionalidades de forma independente. Esse método de análise se assemelha aos Diagramas de Caso de Uso ou Componentes, que analisam o que o sistema faz ou qual é seu comportamento, não a estrutura interna de como é implementado. Para obter sucesso analisando os requisitos necessários para implementar o BDD, é preciso ter um objetivo de trabalho, denominado de Specific, Measurable, Attainable, Relevant and Time-bound (SMART), em que é necessário ser específico, mensurável, atingível, relevante e com resultados alcançáveis em tempo significativo (KUDRYASHOV; STEAD; NORTH, 2015). O Quadro 6 exemplifica duas formas de representação de um objetivo, uma boa e outra ruim, para descrever o problema. O objetivo do exemplo apresentado no Quadro 6 é mostrar que para um objetivo ser bom

23 21 Quadro 6 Exemplo de representação boa e ruim de um objetivo de trabalho Exemplo ruim: Nós iremos ter mais rendimento fazendo mais vendas. Exemplo bom:nós planejamos conseguir 15% de rendimento através dos nossos canais de vendas em 6 meses. Fonte: Kudryashov, Stead e North (2015) é necessário inserir informações lógicas e concisas como: porcentagens, quantidades, condições lógicas, entre outras coisas que podem ajudar a filtrar as informações que serão impostas nos testes. Esse método de desenvolver os planos de trabalho permite especificar claramente quais são os focos do sistema. Dessa forma, o cliente diz na sua própria linguagem o que ele deseja no sistema geral e os desenvolvedores trabalham com funcionalidades específicas no sistema. 3.4 FERRAMENTAS BDD Ferramentas como Cucumber, RSpec e JBehave, foram criadas para implementar o conceito de BDD e realizar testes nas funcionalidades dos sistemas. Os sistemas são desenvolvidos em linguagens diversas, logo existem ferramentas que dão suporte para testes automatizados em cada uma dessas linguagens, assim as funcionalidades podem ser testadas independentes da linguagem escolhida para o desenvolvimento (CHELIMSKY et al., 2012). Algumas ferramentas se destacam por serem as mais utilizadas, porém eu uso depende da linguagem de programação a ser adotada. A Figura 3 apresenta informações sobre as principais ferramentas, se são gratuitas ou pagas, quais as linguagens que elas suportam, se possui código aberto e se a sintaxe e semântica são iguais as demais ferramentas apresentadas (TOOLS, 2016). A sintaxe e semântica estão relacionadas a existência de um padrão de linguagem do BDD, suas palavras-chaves, ou possui algum outro tipo de padrão que deve ser utilizado quando implementado os Scenarios dentro da ferramenta. A Figura 3, apresenta as principais ferramentas utilizadas no desenvolvimento de software de acordo com o site Tools (2016). Figura 3 Ferramentas BDD e suas principais caracteristicas

24 22 Na Figura 4 são apresentadas outras informações sobre as ferramentas apresentadas na Figura 3, informando se a ferramenta cuida de ambiguidade no código das classes, o idioma que ela implementa e se aceita integração com o Gherkin, além da extensão que cada ferramenta usa para ler as criações dos Feature e as saídas que eles retornam. Figura 4 Outras caracteristicas das ferramentas apresentadas na Figura 3 Algumas ferramentas, como Jasmine, RSpec, JWebUnit, tem sintaxe diferente de outras, pois fazem uma integração direta entre os Scenarios das funcionalidades e as possíveis saídas (TOOLS, 2016). A ferramenta Rspec é uma criação que partiu do Jbehave, ferramenta BDD em Java, e foi nomeada de RBehave e assim como o Jbehave que deve ser utilizada usando Java, a ferramenta examina as funcionalidades escritas somente em Ruby, preocupando-se com os objetos e não com o comportamento da funcionalidade (CHELIMSKY et al., 2012). A ferramenta Cucumber, em comparação ao RSpec, se preocupa com o comportamento da funcionalidade. O Cucumber utiliza a sintaxe com palavras-chaves proposta pelo BDD, como é apresentado nos exemplos da Figura 5. Figura 5 Exemplo de um Feature usando Cucumber Fonte: Chelimsky et al. (2012) As três ferramentas:cucumber, Rspec e Jbehave, são as ferramentas mais utilizadas e populares, além de serem pioneiras em termos de BDD (CHELIMSKY et al., 2012; WYNNE; HELLESOY, 2014; TOOLS, 2016).

25 23 No exemplo da Figura 5 o Feature é para um leitor que deseja aprender sobre Rspec e Cucumber. Na cláusula Given é informado quem irá interagir diretamente com a funcionalidade, a interação entre quem foi informado no Given e o sistema é apresentada na cláusula When e o objetivo final é apresentado na cláusula Then. Enquanto no Feature as informações são apresentadas em formato de User Story, usando os termos In order (Em ordem de), As (Como) e I Want (Eu quero), nos Scenarios informa-se os passos que a ferramenta deve seguir para testar a funcionalidade corretamente, utilizando a sintaxe padrão do BDD (WYNNE; HELLESOY, 2014). 3.5 FERRAMENTA: CUCUMBER A escolha dessa ferramenta se deu, pelo fato dela ser uma das mais utilizadas quando o assunto é automação de testes, sendo utilizada por empresas como IBM (BOWERS; BELL, 2013). A escolha também levou em consideração a tradução dos parâmetros de entrada e saída, que passam a ser expressões regulares, o que auxilia na conversão de Backlog para Scenarios, proposto nesse trabalho. A ferramenta The Cucumber tem suporte para diversas linguagens de programação, além de ser utilizadas em organizações e empresas. Cucumber é uma ferramenta que utiliza linhas de comando para executar suas funções. Quando as instruções são executadas, a ferramenta lê as especificações dos Features escritos em linguagem simples e natural, examinando os Scenarios para testes e então os executa em cima do sistema ou aplicação (WYNNE; HELLESOY, 2014). Cada Scenario contém uma lista de passos que a ferramenta deve passar para testar o Feature, essa lista de passos deve seguir uma sintaxe especial e é escrita através das regras do Gherkin, que foi mencionado anteriormente, pois ele faz a varredura do conteúdo escritos nos Scenarios para que a ferramenta consiga testá-los. Os Scenarios escritos para teste com o Cucumber possuem passos que serão interpretados e executados, indicando para a ferramenta o que deve ser feito e onde ela deve procurar pelas informações da aplicação (WYNNE; HELLESOY, 2014). A ferramenta busca pelos Features escritos dentro da pasta que contém os Scenarios. Dentro da pasta Feature deve conter um arquivo de texto simples possuindo o que deve ser os Scenario de uma funcionalidade, esse arquivo de texto será salvo com o nome da funcionalidade ponto Feature (isto é, exemplo.feature). Após a criação dos Scenarios, nenhum passo é adicionado, apenas para garantir que a ferramenta consiga ler o Feature sem problemas, em seguida é adicionado os passos que dão condições para ser realizado os testes. Os passos apresentados na Figura 6 são escritos usando a linguagem Ruby, porém independe da linguagem de programação do sistema a ser testado, basta

26 24 que seja informado no início do Feature onde procurar pelas informações contidas nos passos. A Figura 6 mostra como o Cucumber trabalha em uma aplicação que será testada ou criada. Os Features é a camada mais externa, a qual as informações em linguagem natural é colocada e interligada com a próxima camada, contendo os passos que a ferramenta deve seguir para executar os testes e a camada mais interna é o sistema ou funcionalidade que será testada. Figura 6 Camadas de execução de testes com Cucumber Fonte:Wynne e Hellesoy (2014) A camada dos Features representa a escrita das funcionalidades e Scenarios de teste do sistema, sendo esses escritos em linguagem natural e apresentado através da sintaxe BDD os lugares nas frases onde serão utilizados parâmetros de testes. A camada de Definições de Passos apresenta o passo a passo de execução dos testes. A aplicação do sistema é a parte onde foi desenvolvido o sistema (aplicação a ser testado) e pode ser implementado em qualquer linguagem de programação, considerando apenas se a ferramenta BDD a ser utilizada possuí suporte para os testes naquela linguagem. 3.6 CONSIDERAÇÕES FINAIS Este capítulo apresentou as visões gerais do que é o BDD (Behavior Driven Development), porquê começou a ser utilizado e como funciona suas ferramentas. As ferramentas mais utilizadas foram comparadas considerando a forma de compilação, execução, formato de saída, entre outros. Essa comparação foi feita para informar que existem algumas diferenças entre elas, porém todas utilizam o mesmo embasamento e propósito. Após a apresentação das principais ferramentas, foi apresentada a Cucumber que é a ferramenta utilizada para implementação do Cenário de Teste utilizado neste trabalho.

27 25 4 SCRUM O Scrum é uma metodogia ágil, que vem sendo utilizada por pequenas e médias empresas para melhorar o processo de desenvolvimento de software, já que seu modelo de processo é dinâmico e flexivel (SCRUMSTUDY, 2016; SCHWABER; SUTHERLAND, 2016). A Seção 4.1 descreve o conceito de Scrum e como é seu processo de utilização, a Seção 4.2 apresenta as fases do processo de desenvolvimento de software utilizando o Scrum. O Product Backlog, um dos conceitos principais desse trabalho, é apresentado na Seção 4.3. As considerações finais sobre o capítulo é apresentada na Seção CONCEITOS A primeira referência do processo de desenvolvimento Scrum, foi apresentada através de um guia (The Scrum Guide) escrito por Jeff Sutherland and Ken Schwaber em 2011, e que é anualmente atualizado, sendo assim, foi utilizado nesse trabalho a última versão lançada no ano de 2016 (SCHWABER; SUTHERLAND, 2016). Em 2012, Kenny Rubin publicou o livro Essential Scrum, utilizando o guia do Scrum (RUBIN, 2012). Nesse capítulo serão utilizados referências de ambas publicações, o Essential Scrum e The Scrum Guide. Scrum é considerado uma das mais populares metodologias ágeis, por ter como principais características habilidades de ser adaptativo, iterativo, rápido, flexível e efetivo. A chave principal do Scrum é a utilização de equipes capacitadas, multifuncionais e auto-organizadas que dividem o projeto em pequenas tarefas, que compõem ciclos de trabalhos chamados de Sprints. Uma Sprint é uma lista das funcionalidades que o cliente deseja que seja feito dentro do projeto, ela possui uma duração. Em um projeto pode haver diversas Sprints, pois quando uma é concluída não significa que o projeto inteiro esteja completo e sim uma fração dele. Alguns dos benefícios de utilizar o Scrum, é sua capacidade de adaptação, em que o controle dos processos empíricos e iterativos são adaptáveis e abertos para posteriores mudanças. Scrum possui um processo de desenvolvimento eficiente, em que as tarefas são categorizadas por tempo de realização e prioridades. Os lançamentos das atividades completas são melhorados a cada Sprint, por meio da utilização de lista de prioridades listadas no início do projeto. As atividades lançadas servem para que o cliente possa verificar se seus requerimentos foram ou estão sendo atendidos. Todos os envolvidos no projeto possuem domínio sobre o desenvolvimento e o andamento de cada uma das tarefas, dando a impressão de que eles fazem parte de frações do projeto que não lhe foram designadas. Por exemplo: o analista não realiza o desenvolvimento, porém ele

28 26 sabe o progresso da tarefa que está sendo desenvolvida. Os valores que o Scrum possui, é o comprometimento, coragem, foco, franqueza e respeito, e eles devem ser seguidos pelo time Scrum, além de ter como pilares a construção de um relacionamento com confiança entre os envolvidos no projeto, a transparência, inspeção e adaptação. O time Scrum deve ter auto organização e uma equipe multidisciplinar. A habilidade se auto organizar faz com que os times escolham a melhor forma de trabalhar entre eles, ao invés de esperar que os trabalhos sejam designados por membros de fora do projeto. O fato de as equipes serem multidisciplinar garante que todos tenham competências suficientes para realizar seus trabalhos sem depender da ajuda externa de outros que não fazem parte do projeto. Um dos principais papeis dentro do Scrum, é chamado de Product Owner (Dono do Produto), que realiza a gestão do Product Backlog e suas responsabilidades incluem: Expressar de forma clara os itens que devem estar no Product Backlog; Ordenar os itens do Product Backlog de forma que eles atinjam seus objetivos e missões da melhor forma; Otimizar o valor do trabalho que o time de desenvolvimento realiza; Garantir que o Product Backlog é visível, transparente e claro para todos, além de mostrar qual será a próxima atividade que deve ser realizada; Garantir que o time de desenvolvimento consiga entender os itens do Product Backlog para que possam avançar para os próximos níveis do desenvolvimento. Todos os envolvidos no projeto devem respeitar as decisões tomadas pelo Dono do Produto, pois as decisões representa os desejos estabelecidos na criação ou atualização do Product Backlog, se algum membro do projeto desejar modificar o Product Backlog, a decisão de adicionar ou não alguma informação cabe ao Dono do Produto. O Scrum possui artefatos que representam o trabalho ou valores capazes de mostrar com transparência o que será inspecionado e adaptado. O papel dos artefatos do Scrum é permitir que todos os envolvidos no projeto consigam acompanhar e entender a que passo o projeto se encontra. O artefato que mais se destaca, é o Product Backlog, que é uma lista ordenada de tudo que deve ser feito no produto que foi pedido pelo cliente. Essa lista é a fonte de quais são os requisitos e somente nela é possível realizar posteriores modificações. O Dono do Produto é o responsável pela criação e manutenção do Product Backlog. O Product Backlog não está completo até finalizar o projeto, pois ele está sempre evoluindo e sendo modificado para melhor atender as especificações do cliente. A Figura 7 apresenta as principais diferenças ao utilizar o Scrum e um modelo tradicional de desenvolvimento de software.

29 27 Figura 7 Scrum vs. Modelo Tradicional de Desenvolvimento Fonte: SCRUMstudy (2016) A Figura 7 apresenta uma comparação sobre as principais caracteristicas dos modelos de desenvolvimento de software sejam eles tradicionais ou ágeis. A enfâse do Scrum é nas pessoas trabalhando no projeto, para que possa haver uma melhor comunicação entre os times e com o cliente. A documentação do Scrum é mínima, pois seu foco é em documentar somente o que foi realizado e aprendido durante o desenvolvimento do projeto, enquanto que nos outros modelos tradicionais a documentação é um dos artefatos mais importantes. O planejamento no Scrum é feito com calma e vai evoluindo conforme os resultados dos planejamentos iniciais são apresentados, nos modelos tradicionais o planejamento é inicial e deve ser seguido até o final do projeto. Os requisitos são atualizados conforme os times percebem a necessidade deles, passando por aprovação de toda a equipe e critérios de aprovações, pois o Product Backlog pode ser atualizado frequentemente, assim como as mudanças podem ser feitas durante o desenvolvimento do projeto.

30 28 A liderança e o gerenciamento são colaborativos e descentrazidado no Scrum, pois como já mencionado, o foco está nas pessoas e não nos processos. A medida do desempenho das tarefas realizadas e o retorno do investimento do Scrum são medidos através do quão próximo o resultado final chegou do esperado, além de poder ser medido durante todo ciclo de vida do projeto, assim como o envolvimento do cliente nas decisões tomadas, pois ele quem garante o que é aceitável ou não durante os lançamentos das funcionalidades concluídas, algo que não acontece na maioria das vezes nos modelos tradicionais, que o cliente só se envolve no final do projeto. 4.2 FASES DO SCRUM O Scrum é dividido em 5 fases. A primeira, chamada de Iniciação, possui 6 processos: A criação da visão do projeto, que serve para dar inspiração e apresentar os objetivos de todo o projeto (SCRUMSTUDY, 2016). O Dono do Produto é identificado nesse processo. O segundo processo, é a identificação do Scrum Master, que é o responsável por coordenar as atividades relacionadas às fases e processos do Scrum de forma geral, considerando que algumas atividades são realizadas em paralelos, e os Stakeholder(s) que incluem de forma coletiva o cliente, usuários, patrocinadores ou qualquer outro indivíduo externo que tenha ligação direta com o projeto, pois cada um dos membros que fazem parte desse grupo possui objetivos e benefícios em comum. Algumas vezes o tempo de desenvolvimento de uma determinada funcionalidade requisitada pelo cliente em uma User Story, é maior do que o tempo total de uma Sprint, logo o Dono do Produto pode dividir a User Story maior em pequenos pedaços que podem ser realizados dentro do período estipulado para finalizar aquela Sprint, quando isso acontece o conjunto final é denominado Epico (YODIZ, 2016). A criação dos Epicos serve para que aconteça as divisões de User Story com a finalidade de terminá-las dentro do tempo determinado para as Sprints. A Figura 8 referência um Epico, contendo duas Sprints e as User Storys definidades no Backlog. O processo a seguir da criação dos Epicos, é a criação do Product Backlog baseado em prioridades. Nesse processo, os Epicos são refinados, elaborados e então priorizados para criar o Product Backlog para o projeto. Os epicos precisam ser refinados para garantir que as User Stories criadas sejam sub-dividas caso necessário, pois assim que criadas não é sabido o tempo total necessário para desenvolvê-las. A segunda fase do Scrum é o Planos e Estimativas, essa fase possui 5 processos, sendo seu primeiro processo a criação das User Story e seus critérios de aceitação. As User Stories são escritas pelo Dono do Produto e tem como objetivo garantir que as requisições sejam descritas

31 29 Figura 8 Template de um Epico criado a partir de duas Sprint Fonte:Yodiz (2016) e claras o bastante para que todos os stakeholders consigam entender qual sua finalidade. O próximo processo é a confirmação das User Story, e em seguida a criação das tarefas que devem ser realizadas em busca de desenvolver o que foi requisitado pelo Dono do Produto. Durante a fase de criação das tarefas, também é estimado o tempo de realização, em seguida as User Story são incorporadas no Product Backlog, e a partir de então são consideradas itens do mesmo. O processo seguinte é a aprovação, estimativas e certificação de User Story. Nesse processo o Dono do Produto valida as Story para a Sprint e então é feito uma estimativa de tempo necessário para desenvolver as funcionalidades definidas. A criação de tarefas é o próximo processo, em que as User Story, que foram aprovadas, estimadas e certificadas no processo anterior, são subdivididas e agrupadas em uma Lista de Tarefas. A estimativa de desenvolvimento de cada tarefa é feita e uma nova lista é criada, chamada Lista de estimativas de Tarefas. Após esses dois processos de criação de tarefas, o Product Backlog é finalmente criado, considerando todas as tarefas que devem ser completadas durante as Sprints. Na Fase de Implementação, os processos são realizados com o intuíto de aplicar as decisões que foram estabelecidas nas fases anteriores. O primeiro processo dessa fase é a criação de aplicações, em que o time Scrum trabalha nas tarefas determinadas no Backlog. Um quadro de informações, chamado de Scrum board, é utilizado para informar o progresso das atividades ou possíveis problemas que possam estar impedindo o Scrum Time de atualizar ou entregar as tarefas requisitadas. É durante a fase de Implementação, que a codificação do sistema é feita e os testes realizados. Este trabalho irá atuar na segunda fase do Scrum de Planos e Estimativas, em que é criado o Product Backlog e na fase de Implementação, o que foi desenvolvido será testado. A fase de Revisão e Retrospectiva possui 5 processos, em que o primeiro processo se encaixa em projetos grandes o qual é necessário fazer reuniões com os times responsáveis por

32 30 tarefas independentes e que devem apresentar seus progressos, impedimentos e dependências das tarefas dos outros times. O próximo processo é a demonstração e validação da Sprint, em que o Scrum Time apresenta seus produtos de entrega para o Dono do Produto e os stakeholders, com o intuíto de garantir aprovação e aceitação do que já foi feito e se está de acordo com o que foi pedido. A retrospectiva da Sprint, é um processo em que são discutidas as lições aprendidas durante aquela Sprint atual. As informações aprendidas são documentadas e podem ser usadas em Sprints futuras, além de ser possível discutir o que pode melhorar e ser atualizado. Na fase de Lançamento, o que foi aceito como entrega é lançado e transmitido para os stakeholders, além de ser documentado a conclusão daquela Sprint. A retrospectiva do projeto é feita em seguida e os envolvidos devem documentar o que foi aprendido e realizado. Para a realização deste trabalho, nenhuma alteração na metodologia foi feita, foi proposto uma melhoria na especificação do Product Backlog apresentado na seção 4.3. Essa melhoria utiliza uma das formas de especificação de requisitos do Scrum e propõe uma mudança para que atenda os objetivos do trabalho. 4.3 PRODUCT BACKLOG O Product Backlog (Product Backlog) é uma lista de todos os requisitos que devem ser feitos dentro do projeto, substituindo os artefatos gerados da elicitação de requisitos das metodologias tradicionais, embora isso não signifique que o Time Scrum não tenha permissão para usar e criar outros tipos de artefatos (INSTITUTE, 2016). No Product Backlog são listadas as funcionalidades, funções, requisitos, aprimoramentos, e possíveis formas de consertar ou adicionar mudanças nos lançamentos futuros do produto. Os itens do Product Backlog possuem atributos como descrição, ordem, estimativa de tempo e valor. O Dono do Produto usa o Product Backlog durante as reuniões de planejamentos para descrever o que irá deseja que seja desenvolvido. As informações contidas no Product Backlog aparecem no formato de User Story com mais detalhes. Cada item do Product Backlog tem certas prioridades e que se diferenciam de uma lista comum de tarefas que devem serem feitas. As principais diferenças são que as entradas, ou seja, cada item do Product Backlog, sempre adicionam valores para o cliente, são ordenadas de acordo com as suas prioridades, o nível de detalhes informados depende da posição em que a tarefa está na lista do Product Backlog, além de todas as entradas serem consideradas. O Product Backlog é um documento dinâmico e não possui uma linguagem de baixo nível, apenas informações em linguagem natural. A atualização constante do Product Backlog é realizada dentro da Fase de Implementação. São feitas reuniões para revisar o que já foi feito e o que ainda falta fazer dos itens estabe-

33 31 lecidos a prioridade no Backlog e então novos itens são discutidos e incorporados no Backlog caso necessário. A Figura 9 apresenta a estrutura de um Product Backlog. Figura 9 Representação de um Product Backlog Fonte: Rubin (2012) Após os Features serem determinados, eles são inseridos dentro da lista do Product Backlog, que é organizada através das prioridades de entrega. Os Features dentro do Product Backlog descrevem Funcionalidades do sistema, e podem ser detalhados através de User Story. O que difere o Product Backlog de outras formas de elicitação de requisitos, é a forma de expressar o desejo do Dono do Produto descrito de tal forma que é possível identificar quem está interagindo com a funcionalidade, o objetivo (critério de aceitação) que a funcionalidade tenha ou precise ter para funcionar corretamente, e a prioridade de desenvolvimento dentro do processo, já que os itens do Product Backlog possuem prioridades para ser inseridos. Os autores que apresentaram o Scrum, e que foram citados no ínicio do capítulo, descrevem os itens do Product Backlog no formato de User Story, existem outras formas de descrevê-lo porém não serão considerados, neste trabalho será utilizado User Story para descrever os itens do Product Backlog. Existem ferramentas que auxiliam na integração dos times dentro do processo de desenvolvimento, e que fornecem um template de User Story para geração do Product Backlog, um dos exemplos é a ferramenta online EasyBacklog (2017), que permite a geração de Sprints com Products Backlogs para cada uma delas.

34 32 A Figura 10 apresenta o formato de um item do Backlog. Figura 10 Representação de um item do Product Backlog Fonte: EasyBacklog (2017) Na Figura 10 é possível perceber os campos os quais a User Story seria escrita, o critério de aceitação, os comentários opcionais sobre aquela Story, os pontos e o custo do item, e os dias necessários para que a User Story descrita seja finalizada. 4.4 CONSIDERAÇÕES FINAIS Neste Capítulo foram descritos os conceitos principais do Scrum, as fases que o compõe, de forma a apresentar a fase de atuação em que a proposta deste trabalho pretente atuar. Na Seção 4.3 foi dado ênfase em como o Product Backlog se comporta, mostrando assim suas similaridades com o que será proposto na Seção 6.3 e como ele é integrado dentro da metodologia Scrum, de forma que o processo de desenvolvimento dessa metodologia não é alterado, apenas o formato de escrita de um dos seus artefatos.

35 33 5 MPBACKLOG: UMA PROPOSTA DE MODIFICAÇÃO DO PRODUCT BACKLOG Este Capítulo apresenta a proposta de conversão do Product Backlog para o MPBacklog (Modified Product Backlog) que é apresentado na Seção 5.1. A Seção 5.2 descreve as fases de atuação do MPBacklog dentro do Scrum. A Seção 5.3 descreve as BNF(Backus-Naur Form) propostas para realização da conversão do Product Backlog para o MPBacklog. São apresentados diagramas de sintaxe que descrevem as BNF propostas, esses diagramas estão presentes na Seção 5.4. Por fim, as considerações finais do capítulo são apresentados na Seção PROPOSTA DE CONVERSÃO Como relatado no capítulo 2, na descrição de Cenários existem elementos essenciais que fazem com que uma sequência de eventos descritos de uma determinada forma sejam caracterizadas como Cenário. Para a conversão de um Backlog, artefato vindo de uma das fases do Scrum e que foi explicado detalhadamente na Seção 4.3, para um MPBacklog, será utilizado o esquema de cenário proposto por (LARMAN, 2004). Através da BNF proposta, foram criados Diagramas de Sintaxe para melhor identificar o fluxo de aceitação das regras de produção da BNF e são apresentados na Seção 5.4. Os atores descritos por Larman (2004) podem ser uma pessoa, um sistema, ou qualquer forma de interação direta com o sistema. Na descrição do MPBacklog essa interação é representada pela cláusula Como. Por exemplo, um ator denominado de Administrador de Sistema utilizado em um Cenário, no MPBacklog é descrito como Como: Administrador de Sistema. A cláusula Como recebe como parâmetro os tipos de Usuários que interagem com o Cenário a ser desenvolvida para aquele Feature. As pré-condições são convertidas nas cláusulas "Eu tenho" e as sequências de passos do Fluxo Básico são convertidas nas cláusulas Eu quero e Assim. Quando houver póscondições são adicionadas na cláusula "Assim". Por exemplo, Eu tenho uma uma lista de informações, Eu quero visualizar essa lista, Assim eu posso conferir os dados. Quando houver um fluxo alternativo ou mais de um tipo de ator dentro no Backlog, esses fluxos são convertidos utilizando o operador lógico "E". A Figura 11 apresenta as alterações que foram feitas desde o Cenário, até o MPBacklog. São apresentados os elementos referentes a cada tipo de descrição de cenário, sejam esses um escopo menor do Cenário proposto por Larman (2004), o Backlog comumente utilizado nos processos de desenvolvimento ágil e que é baseado nas User Story proposto por Beck (2000) e o consolidado por Cohn (2004). O MPBacklog é a proposta deste trabalho. Embora o MPBacklog apresente mais elementos de descrição, essa adição irá proporcionar mais conhecimento do que se deseja que seja executado, além de estruturas lógicas que

36 34 Figura 11 Template de um Cenário, Backlog Comum e MPBacklog garantem que o que foi pedido de forma geral seja executado fracionado, sendo assim, todos os atributos são considerados. Como foi mencionado no capítulo 3, o BDD (Behavior Driven Development) utiliza o esquema de Scenarios, que são fluxos de passos que ao serem executados garantem que a funcionalidade proposta pelo cliente seja desenvolvida com sucesso. Dessa forma, o esquema de Cenários utilizados para descrever Casos de Uso e itens Backlog utilizados no processo de desenvolvimento Scrum, podem ser traduzido em Scenarios do BDD. A Figura 12 apresenta de forma gráfica o que é apresentado na Figura 11. A ideia inicial de seguir um fluxo de eventos é retirada dos Cenários utilizados em Caso de Uso, em seguida declarado de forma direta e simples no Product Backlog Comum, e utilizando o MPBacklog proposto nesse trabalho. Com isto, é possível fazer a tradução direta de itens MPBacklog para os Scenarios do BDD. Figura 12 Diagrama de um Cenário, Backlog Comum e MPBacklog O Backlog Comum e MPBacklog apresentado na Figura 12 foi utilizado para mostrar o fluxo de conceitos e como cada um se interliga com o próximo. O Cenário simboliza o conceito original, com a existência de atores, pré-condições, fluxos básicos e alternativos, o Backlog

37 35 Comum simboliza a forma originalmente utilizada para Backlog dentro do Scrum, e o Scenario BDD representa a etapa de geração dos Scenarios utilizados nas ferramentas BDD. 5.2 FASE DE IDENTIFICAÇÃO, DESCRIÇÃO E CONVERSÃO A Figura 13 apresenta a fase na qual este trabalho é atribuído, e é complementada com a Figura 14, que apresenta o fluxo detalhado de uma Sprint. Durante uma Sprint, assim como foi visto na Figura 13 uma etapa complementa a outra, logo não existe uma ordem exata em que as tarefas devem ser desenvolvidas. Figura 13 Fases do processo de desenvolvimento utilizando Scrum Fonte: Rubin (2012) Durante a fase de Planos e Estimativas, que é apresentado na Figura 14, é criado o Product Backlog, que a partir de agora será chamado de MPBacklog, e que é a entrada para a criação dos Scenarios do BDD, que posteriormente serão implementados durante a Fase de Implementação, Revisão e Retrospectiva, e Release, mencionadas na seção 4.2. As cores dos retângulos vermelho, azul e verde representam as fases do Scrum, separando os processos que contém cada uma das fases, dessa forma é possível identificar exatamente qual a área de atuação do MPBacklog, deixando claro que o processo de desenvolvimento utilizado pela metodologia Scrum não é alterado em nenhum momento, apenas há a incorporação de uma forma de melhoria do Backlog. Após a criação do MPBacklog, a conversão para o Scenario BDD é feita, e então sua implementação do código em uma linguagem de programação. Pode existir uma recursão entre a implementação e os Scenarios BDD, já que eles podem ser incrementados e refatorados. Os critérios de aceitação são determinados no MPBacklog e consequentemente após a conversão para os Scenarios BDD eles devem ser aceitos. Caso os testes resultem em falhas, novos itens do Backlog devem ser adicionados e uma nova conversão é feita para assim englobar os novos atributos que foram coletados e considerados.

38 36 Figura 14 Fases do uma Sprint Fonte: SCRUMstudy (2016) A Figura 15 representa um escopo detalhado da fase de Implementação do Scrum utilizando o MPBacklog. Figura 15 Etapa do processo de desenvolvimento utilizando o MPBacklog Um Feature só é liberada para Release da Sprint se todos os testes foram realizados e a maior área possível de Scenarios for coberta, garantindo assim a qualidade daquele Feature, assim como é ilustrado na Figura 15. Conversão: A conversão do MPBacklog é a contribuição realizada nesse trabalho. Por meio da utilização obrigatória de algumas cláusulas (palavras-chaves) retiradas dos Backlogs Comuns geralmente usados, é possível converter as User Story (Itens do Backlog) em pequenos fluxos de eventos denominados Scenarios nas ferramentas BDD.

39 37 Todos os testes realizados com sucesso: Um Feature na metodologia Scrum só é finalizada após todos os testes terem sido executados e uma grande gama de possíveis cenários terem sido englobados e testados. Refatoração: Os Scenarios BDD podem ser reutilizados, já que eles são como códigos de linguagem de programação, que possuem palavras-chaves e uma sintaxe específica. Portanto, é possível que após a execução de um Scenario, seja modificado o código e assim como em linguagem de programação existe a refatoração, o mesmo acontece com os Scenarios BDD. Feature com falhas: Feature com falhas devem ser analisadas novamente, e provavelmente novos itens sejam adicionados ao Backlog, sendo assim, uma nova conversão deve ser feita para que os novos itens descritos sejam convertidos em Scenarios. Sem a utilização do MPBacklog, o processo de desenvolvimento de forma simplificada, seria como representado na Figura 16, com o MPBacklog, dentro do processo é ignorado alguma dessas etapas, pois a ferramenta de conversão faria o interligamento entre a fase de análise, teste e desenvolvimento. Figura 16 Fase de teste sem a utilização MPBacklog Fonte: Cohn (2009) As fases do critério de aceitação apresentado na Figura 16, ilustra o processo de ida e volta de uma implementação da funcionalidade desenvolvida e qual a próxima etapa quando a funcionalidade falha ou passa nos testes, indicando quando há necessidade de refatoração de código e quando uma funcionalidade é considerada aceita e finalizada. A Figura 16 apresenta o processo de teste utilizando o TDD (Test Driven Development), um método de teste geralmente utilizado em metologias ágeis. Enquanto que a Figura 17 apresenta o processo de teste utilizando BDD (Behavior Driven Development) já utilizando o MPBacklog, na qual algumas etapas serão dispensadas, considerando que as informações irão ser retiradas diretamente da User Story determinada no Product Backlog.

40 38 Figura 17 Integrando o MPBacklog com Scrum A Conversão é um trabalho futuro, em que é desenvolvido uma ferramenta capaz de receber itens do MPBacklog e convertê-las diretamente para os Scenarios BDD. Considerando que existem mais situações e domínios a serem considerados e modificações nas BNF (Backus- Naur Form) apresentadas teria que serem feitas. 5.3 DEFINIÇÕES DE BNF(BACKUS-NAUR FORM) BNF (Backus-Naur Form), que é uma forma de representar gramáticas livres de contexto, ou seja, uma linguagem formal (MIGHT, 2017). As linguagens livres de contexto utilizando o formalismo BNF são representadas da seguinte forma: A ::=< α > < β > Onde, A é uma produção, ::= referência a uma expansão da produção A, que pode ter terminais α e produções β. Os terminais são palavras-reservadas, como por exemplo "Scenario", "Given", "When", "Then", ou qualquer palavra que esteja entre aspas simples. Uma lista de palavras-reservadas é apresentada no Apêndice A, a fim de diminuir o comprimento das BNF e deixar o entendimento mais claro. Exemplo:

41 39 rua numero digito ::= [0-9] letra ::= [a-za-z] rua ::= (letra)* numero ::= (digito)* logradouro ::= No exemplo apresentado, a produção digito aceita um digito de 0 até 9. A produção letra aceita uma letra do alfabeto de a até z minúsculo e maiúsculo, a produção rua aceita zero ou mais letras do alfabeto para compor o nome da rua e o numero aceita zero ou mais digitos para formar o número, que será usado na produção logradouro que obrigatoriamente só é aceita se for composto pelo nome da rua e o número. As palavras sem aspas duplas ou simples são produções da BNF, e elas expandem para uma nova produção ou para um tipo de parâmetro terminal, que é aceito pela variável anterior ao símbolo ::=, como acontece na terceira coluna da Figura 18, onde a produção name expande para a expressão regular [a-za-z0-9]* e que indica que aquela produção aceita qualquer caracter do alfabeto de a até z, minuscúla e maiúscula, e digitos de 0 até 9, e o símbolo * (asterísco) indica que esses caracteres podem ser repetidas 0 ou mais vezes. Existem três possibilidades de expansão das BNF apresentadas: Quando o valor após ::= estiver vazio, significa que a produção pode não ser obrigatória; Quando o valor após ::= possuir um valor entre (barra), significa que a produção possui opções de expansão; Quando o valor após ::= não está vazio e uma produção é imediatamente apresentada, significa que ela é obrigatória para que a produção antes do ::= seja aceita. O Quadro 7 apresenta as semelhanças e diferenças entre Cenário, User Story, item do Backlog e um Feature (BDD). Foi utilizado toda o Feature do BDD, não só o Scenario na representação, podendo assim identificar melhor que também existe semelhanças entre o Feature como um todo, com o resto das colunas apresentadas no quadro. Quadro 7 Representação e Comparação de Cenários, User Story, Backlog e Feature BDD Cenário User Story Backlog (Item) Feature (BDD) Cenário:<nome> Atores:<tipo de usuário> Pré Condições: <condição necessária para que os fluxos possam ser executados> Fluxo de eventos: 1. Passo 1 2. Passo 2 3. Passo 3 As <tipo de Usuário> I want to <objetivo> So that I can <razão> Como um <tipo de Usuário> Eu quero <objetivo> Para que eu possa <razão> Feature: <nome> Background: <contexto> In order to <objetivo> I want <operações> Scenario*: <nome> Given <um contexto, tipo de usuário, classe, objeto> When <condição> And <condição opcional> Then <objetivo>

42 40 O item do Backlog e o Scenario do BDD Behavior Driven Development são subdividos em diversos outros itens menores, denominados steps (passos) e que alcançam um número maior de cenários de situações que podem ser testadas. Os Cenários são referências ao que foi proposto por Larman (2004), e os Scenarios estão no formato das ferramentas BDD. O MPBacklog é o nome utilizado para referenciar o modelo Backlog nesse trabalho, em que foram feitas pequenas modificações, como a adição de novas palavras chaves no formato original do Backlog para atender ao que foi proposto. Durante a fase inicial do Scrum alguns atributos são criados, tais como: uma lista de itens com valores, objetivos e critérios de aceitação. Essa lista é chamada de Product Backlog e esses itens são descritos no formato de User Stories. User Stories foi um modelo proposto para que funcionalidades tivessem um valor, ou seja, um objetivo e podem ser facilmente inseridas dentro de um projeto em andamento. O valor de uma User Story está relacionado a quais critérios de aceitação devem ser seguidos para que a funcionalidade requisitada pelo cliente seja atendida. As User Stories são utilizadas como elicitações de requisitos, servindo assim de entrada inicial para calcular os recursos necessários para que o projeto seja desenvolvido. Na metodologia Scrum as User Stories são utilizadas no ínicio do processo, pois são itens inseridos no Product Backlog. Nesse trabalho são utilizados conceitos semelhantes, por isso foram padronizado os nomes para que não exista incoerência ou não entendimento do contexto. User Stories serão utilizadas para descrever itens do Product Backlog Comum, que por sua vez, será descrito da forma usual de User Story. As User Story possuem o formato apresentado no Quadro 8: Quadro 8 Formato User Story "Como"<tipo de usuário>, "Eu quero" <um objetivo>, "para então"<uma razão> As User Story são pequenas descrições escritas em um formato especial para identificar o tipo de usuário que irá interagir com o sistema, seu objetivo e uma razão para qual aquela funcionalidade deve ser desenvolvida. O Apêndice B apresenta as BNF propostas e apresentadas na Figura 18, para realização da conversão de um MPBacklog para um Scenario BDD, descrevendo as semelhanças entre eles, sendo possível identificar quais produções passam a ser produção da BNF convertida. Algumas produções foram expandidas com terminais, e para que a lista não poluisse a BNF, elas foram listadas no Apêndice A desse trabalho. Em algumas expressões regulares foi necessário identificar símbolos que são característicos da linguagem BNF, como os meta símbolos (barra), (aspas simples), < (menor), e > (maior). Como esses símbolos são identificados como parte da linguagem BNF, eles devem

43 41 Figura 18 BNFs Backlog Comum, MPBacklog e Scenario BDD

44 42 ser identificados como terminais, logo, eles são representados entre aspas simples. Quando os símbolos citados não estiverem entre aspas simples, significa que eles são parte da representação BNF. A tradução seria feita utilizando alguma das ferramentas já existente para implementações de reconhecimentos de gramáticas livres de contexto. Algumas ferramentas que poderiam auxiliar no reconhecimento da BNF são: Flex, Bison, ANTLR, ou alguma das ferramentas geradores de parser (semântica) e lexers (sintaxe) como as apresentadas no catálogo do site (TOOLS, 2005). A BNF proposta possui limitações e que devem ser consideradas para trabalhos futuros, ela deve ser fatorada para retirar as ambiguidades, considerar os metacaracteres e metasímbolos. Outra limitação das BNF propostas é o tratamento de neologismos possíveis na escrita do MPBacklog, a fim de garantir que as operações estão sendo aceitas corretamente, pois embora tenha sido apresentado uma lista de palavras terminais que apresentam as principais operações, é possível que ainda falte palavras que são neologismo ou sinônimos das mesmas. 5.4 DIAGRAMA DE SINTAXE (BNF) Essa seção tem como objetivo, descrever as principais produções de cada BNF, a fim de mostrar a identificação e posterior conversão dos Backlog descritos. O objetivo desse trabalho é apresentar a possibilidade de realizar a conversão de um item do Product Backlog em um Scenario BDD, como não entra no escopo da proposta tratar a linguagem natural e sim utilizá-la como descrição de Features de um sistema de computador, não foram analisados as regras gramáticais e morfológicas das frases apresentadas, ficando assim como proposta para trabalhos futuros. As Figuras a seguir, foram criadas utilizando a ferramenta online Railroad (2017), e apresentam alguns dos diagramas que são comuns para as três BNF apresentadas, a fim de evitar repetição, elas serão inseridas uma única vez e referenciadas quando necessário. O tipousuário apresentado na Figura 19 é considerado um parâmetro de entrada para algumas produções. Essa produção deve aceitar descrições de possíveis usuários que irão interagir com o sistema.

45 43 Figura 19 Produção: tipousuario A produção parametro apresentada na Figura 20 é outra produção que irá servir de entrada para outras produções. Essa é uma das produções mais importantes da BNF MPBacklog, pois é ela quem garante que a regra será aceita quando os termos definidos como pârametros do modelo de Backlog foram utilizados corretamente. Figura 20 Produção: parametro A produção acao apresentada na Figura 21 e 22, são possíveis ações de utilização e operações que um item descrito no Backlog pode vir a ter. Essas ações e operações foram definidas conforme foi percebido um padrão nas definições do Backlog e Scenarios.

46 44 Figura 21 Produção: acao Por meio dessa repetição de palavras-chaves foi criado uma lista das palavras mais utilizadas e disponibilizadas no Apêndice A. Figura 22 Produção: lista_op MPBacklog. A produção 23 descreve os valores lógicos possíveis ao descrever o Product Backlog e

47 45 Figura 23 Produção: logico A produção como apresentada na Figura 24 dá inicio ao formato do Backlog, como já foi mencionado na seção 4.3. Figura 24 Produção: como A Figura 25 ilustra o fluxo inicial de aceitação que realiza a conversão do MPBacklog em Scenarios. Em que a produção eu inicia a aceitação do MPBacklog. Figura 25 Produção: eu

48 46 A Figura 26 apresenta as opções de posse que o o usuário, concatenando com as opções de Eu possuo e Eu tenho. Figura 26 Produção: posse A Fígura 27 apresenta o contexto de objetivo do MPBacklog. Figura 27 Produção: assim A produção acaoop apresentada na Figura 28 faz o desvio de fluxo quando os resultados possuêm Eu: nos resultados. Figura 28 Produção: acao_op Fonte:Autoria Própria As produções como e assim apresentadas nas Figuras 24 e 27 fornecem o corpo para o formato MPBacklog.

49 47 A produção resultados apresentada na Figura 29 é um complemento para a produção parametros, considerando que existe um formato de aceitação necessário. Figura 29 Produção: resultados Fonte:Autoria Própria As produções apresentadas a seguir, são referentes a BNF de um Feature do BDD. Figura 30 Produção: feature As produções background e feature apresentada nas Figuras 31 e 30, dão ínicio ao fluxo de aceitação da BNF sugerida no Apêndice B. Figura 31 Produção: background As produções Given, When, Then são parte do corpo da produção scenario, todas referenciadas pelas Figuras 32, 33, 34 e 35 respectivamente.

50 48 Figura 32 Produção: given Figura 33 Produção: when Figura 34 Produção: then A Figuras 35 e 36 apresentadas, fornecem de forma diagramada os estados de aceitação de um Scenario BDD. Figura 35 Produção: scenario A produção scenario_otl apresentada na Figura 36, faz a conexão lógica entre as palavraschaves dos Scenarios. Figura 36 Produção: scenario_otl A produção logico_bdd referenciada na Figura 37 possui um formato diferente da produção logico, apresentada na Figura 23, pois os Scenarios BDD identificam "But" como uma condição lógica, interligando duas cláusulas do Scenario.

51 49 Figura 37 Produção: logico_bdd A Figura 38 apresenta o formato de aceitação das opções que a produção eu_bdd aceita. Figura 38 Produção: eu_bdd Semelhante a produção eu_bdd a produção eu_posse_bdd apresentada na Figura 39 descreve a opção de expandir para uma nova produção, que por sua vez, gera os parâmetros possíveis da produção eu_bdd. Figura 39 Produção: eu_posse_bdd A produção acao_bdd_op apresentada na Figura 40 mostra o desvio de opções da produção eu. Figura 40 Produção: acao_bdd_op A produção assim_bdd apresentada na Figura 41, representa o fluxo da aceitação dos parâmetros do Scenario.

52 50 Figura 41 Produção: assim_bdd A Figura 42 apresenta como os parâmetros são aceitos dentro da descrição dos Scenarios. Figura 42 Produção: parametros_bdd Fonte:Autoria Própria Os resultados_bdd são opcionais quando o tipo de Scenario permitir que opções prédefinidas sejam utilizadas para teste.

53 51 Figura 43 Produção: resultados_bdd Fonte:Autoria Própria A produção name aceita letras do alfabeto de a até z, de forma a aceitar as descrições escritas nas produções que podem aceitar palavras diversas que não sejam reservadas dos Scenarios e do MPBacklog. Figura 44 Produção: name Fonte:Autoria Própria 5.5 CONSIDERAÇÕES FINAIS As fases de atuação do MPBacklog no Scrum foi apresentado nesse capítulo, mostrando que o Product Backlog é criado na fase de Planos e Estimativas e então colocado em prática na fase de Implementação. Foi apresentado as BNFs propostas do Backlog Comum, MPBacklog e Scenarios BDD, e os diagramas de sintaxe que descrevem os fluxos de aceitação de cada produção dessas BNFs. Este capítulo fornece um formato de visualização para os fluxos de aceitação apresentados nos Quadros das Seções 6.2, 6.3 e 6.4.