Tópicos Especiais em Engenharia de Software – Agenda – Behaviour-Driven Development

View Github Repository Open presentation in a new window

raphaelrodrigs

See all presentation from raphaelrodrigs

Tópicos Especiais em Engenharia de Software – Agenda – Behaviour-Driven Development

0 0

topengenhariasoft

Apresentação sobre documentação ágil Tópicos Engenharia de Software - PUCRS

On Github raphaelrodrigs / topengenhariasoft

Tópicos Especiais em Engenharia de Software

US, RN, RF, RI e BDD Eduardo MartinencoLetícia HoffmannLuciano AlmeidaRaphael Rodrigues

Agenda

  • User Story
  • Regras de Negócio
  • Requisitos Funcionais
  • Requisitos de Interface
  • BDD

User Story

User story ou “história de usuário” é uma descrição concisa de uma necessidade do usuário do produto, (ou seja, de um requisito) sob o ponto de vista desse usuário.
A User Story busca descrever a necessidade de uma forma curta, simples e clara. Ela é apenas uma promessa de uma conversa, um lembrete de que mais detalhes serão necessários e não deve ser considerados suficientes para a realização do trabalho.

User Stories possui três aspectos críticos, os chamados três Cs:

Cartão As conversas A confirmação

Construindo uma User Story:

Ator Ação Funcionalidades

Construindo User Story:

Fonte: http://blog.myscrumhalf.com

Construindo User Story:

Fonte: http://blog.myscrumhalf.com

Exemplo US

Fonte: http://pt.slideshare.net/manoelp/exemplos-de-user-stories

Regras de Negócio

Fonte: http://www.vecteezy.com
As regras de negócios são tipos de requisitos de como os negócios, incluindo suas ferramentas de negócios, devem operar. Podem ser leis e regulamentos impostos ao negócio, mas também expressam a arquitetura e o estilo de negócio escolhidos.

Regras de Negócio

É uma linguagem "natural", com estruturação semântica precisa, destinada a ser usada, entendida e mantida por pessoas ligadas ao negócio, não por especialistas em TI ou por sistemas e linguagens de programação.

Regras de Negócio

Uma regra de negócio estabelece as condições em que os fatos são válidos, ou as restrições que devem ser observadas no tratamento dos fatos.

Exemplo

Um CLIENTE só pode fazer um PEDIDO se tiver seu CRÉDITO APROVADO Note que a regra acima implica na existência de dois fatos: CLIENTE faz PEDIDO e CLIENTE tem CRÉDITO APROVADO

Formas de capturar as regras de negócio:

Baseadas em modelos Baseadas em documentos

Categorias de regras de negócio:

Regras de limite Regras de derivação

Regras de limite:

Regras de estímulo e resposta Regras de limite de operação Regras de limite de estrutura

Regras de derivação:

Regras de conclusão Regras de cálculo

Regras de estímulo e resposta

Fonte: http://www.funpar.ufpr.br

Regras de limite de operação

Fonte: http://www.funpar.ufpr.br

Regras de limite de estrutura

Fonte: http://www.funpar.ufpr.br

Regras de conclusão

Fonte: http://www.funpar.ufpr.br

Regras de cálculo

Fonte: http://www.funpar.ufpr.br

Requisitos Funcionais

Requisitos funcionais são as necessidades apontadas pelo cliente, ou seja, o que ele quer que o sistema faça. Estes requisitos são obtidos durante a etapa de levantamento de requisitos junto ao cliente e demais usuários. A partir disto defini-se uma função de um sistema de software ou seu componente. Uma função é descrita como um conjunto de entradas, seu comportamento e as saídas (envolve cálculos, lógicas de trabalho, manipulação e processamento de dados, entre outros).
Dentro dos requisitos funcionais também encontram-se a arquitetura do aplicativo, diferentemente da arquitetura técnica, que pertence aos requisitos não funcionais.Exemplos: Gerenciar vendas Emitir relatórios Consultar usuários
Muitos autores ainda dividem os requisitos funcionais em três: evidente, escondida e friso.
  • Evidentes: é quando o usuário final do sistema está ciente do que está sendo executado.
  • Escondida: é quando uma função está sendo feita, mas é invisível ao usuário.
  • Friso: quando a execução da funcionalidade não afeta outras funções do software.
Boa parte da qualidade do software está centrada em atender tais requisitos, uma vez que esse é o comportamento esperado pelo cliente.

Exemplo de Requisito Funcional - RF

Fonte: http://ericlemes.com/2009

Exemplo de Requisito Funcional - RF

Fonte: http://ihuru.fe.up.pt

Requisitos de Interface

Requisitos de Interface

Fonte: http://image.uisdc.com/
São as regras que determinam formato/aparência de campos, comportamento dos componentes das janelas e outras informações relevantes à interface gráfica.

Exemplo Requisitos de Interface

Layout Sugerido

Exemplo Requisitos de Interface

Campos

Exemplo Requisitos de Interface

Navegação WebFonte: www.gmaxweb.com.br

Exemplo Requisitos de Interface

Navegação MobileFonte: www.gmaxweb.com.br

Prototipagem

O uso de prototipagem é feito em diversas fases do processo de engenharia de requisitos. Trata-se de uma versão inicial do sistema, baseada em requisitos ainda pouco definidos, mas que pode ajudar a encontrar desde cedo falhas que através da comunicação verbal não são tão facilmente identificáveis.
Fonte: inventbordados.blogspot.com
Fonte: webanduxdesign.tumblr.com
Fonte: materialpatterns.tumblr.com

Behaviour-Driven Development

Fonte: https://plus.google.com/+Qaworks/ Desenvolvimento Orientado por Comportamento Dan North criou o primeiro framework de BDD, em 2006

O que é?

BDD é técnica de desenvolvimento ágil que visa integrar regras de negócios com linguagem de programação, focando o comportamento do software;

Trata-se de uma evolução do TDD;

É uma abordagem de design de software com foco no domínio do software (Domínio nada mais é que do atender completamente um determinado negócio).

Para que serve?

Utilizando BDD em apenas um repositório, você mantém os testes de aceite automatizados de uma forma simples de ler para o cliente, desenvolvedores, QAs e demais membros da equipe. Nessa abordagem, a documentação e o código de desenvolvimento evoluem sempre juntos.

Camadas BDD

Fonte: http://elemarjr.net

Ferramentas

Sintaxe Gherkin

Fonte: http://pt.slideshare.net/dversaci/behavior-driven-development-bdd-and-agile-testing

BDD Cenário

Fonte: try.behave.pro

Cenário em pt

Fonte: http://elemarjr.net

Testes ágeis com BDD

Comparação entre Caso de teste e BDD cenário

As razões para os testes tradicionais serem superados pelos testes ágeis

  • Grandes volume de atividade manuais de teste atrasam a entrega;
  • As equipes só começam a testar quando o sistema tenha sido desenvolvido e integrado;
  • Um grande bloqueio da entrega no prazo é descobrir no final do ciclo de desenvolvimento que sua aplicação possui grandes problemas de qualidade.

Case

Referência

http://blog.myscrumhalf.com/2011/10/user-stories-o-que-sao-como-usar/ http://arquiteturadeinformacao.com/user-experience/como-criar-uma-user-story/ https://extreme-programming-mds.googlecode.com/files/user_stories.pdf http://www.knowledge21.com.br/sobreagilidade/user-stories/o-que-e-user-story/ http://eduardopires.net.br/2012/06/ddd-tdd-bdd/ http://www.bugbang.com.br/entendendo-bdd-com-cucumber-parte-i/ http://dannorth.net/whats-in-a-story/ https://pt.wikipedia.org/wiki/Behavior_Driven_Development http://henriqueluz.com.br/2012/05/05/as-vantagens-do-bdd-em-times-ageis/ http://www.infoq.com/br/news/2014/07/desenvolvimento-agil-testes http://raphaelrodrigs.github.io/learnbdd/#/ http://blog.makesys.com.br/definindo-seu-software-o-que-sao-requisitos-funcionais-e-nao-funcionais http://www.profissionaisti.com.br/2013/02/a-importancia-dos-requisitos-nao-funcionais/ http://www.cin.ufpe.br/~gta/rup-vc/extend.bus_model/guidances/guidelines/business_rules_E6E7173.html http://www.centus.com.br/base-de-conhecimento/artigos/definindoregrasdenegocio
0