UNIVERSIDADE DO SUL DE SANTA CATARINA DIEGO SALOMÃO …

UNIVERSIDADE DO SUL DE SANTA CATARINA

DIEGO SALOMÃO

MARIA LUIZA DA SILVA

UM ESTUDO DE CASO UTILIZANDO FRAMEWORK SCRUM COM ARTEFATOS

UML PARA APOIO AO DESENVOLVIMENTO DE SOFTWARE

Florianópolis/SC

2016

DIEGO SALOMÃO




Este Trabalho de Conclusão de Curso foi julgado adequado à obtenção do título de Bacharel em Sistemas de Informação e aprovado em sua forma final pelo Curso de Sistemas de Informação da Universidade do Sul de Santa Catarina.

Orientador: Maurício Botelho, MEng.

Florianópolis/SC

2016

DIEGO SALOMÃO




Este Trabalho de Conclusão de Curso foi julgado adequado à obtenção do título de Bacharel em Sistemas de Informação e aprovado em sua forma final pelo Curso de Graduação em Sistemas de informação de Informação da Universidade do Sul de Santa Catarina.

Florianópolis, 15 de junho de 2016.

______________________________________________________ Professor e orientador Maurício Botelho, MEng.

Universidade do Sul de Santa Catarina

______________________________________________________ Prof. Edson Lessa, Esp.


______________________________________________________ Prof. Flávio Ceci, Dr.


Dedicamos esta monografia aos nossos

pais e irmãos que sempre nos apoiaram,

ao nosso orientador Prof. Maurício

Botelho que sempre muito prestativo,

contribuiu muito para que este trabalho

fosse concluído e, ainda, a todos os

professores do nosso curso.

AGRADECIMENTOS

Diego Salomão agradece a:

A Deus por permitir e dar forças para que este sonho pudesse ser

alcançado.

Aos meus pais e irmão que me apoiaram em todos os momentos e, que

mesmo distantes, me deram força, conselhos e incentivos para a realização deste

sonho.

Ao nosso orientador Prof. Maurício Botelho, pela atenção, apoio e

recomendações para a execução do trabalho.

A Prof.ª Maria Inés Castiñeira, que nos conduziu na elaboração deste

trabalho.

As instituições UNIUBE e UNISUL onde pude ter o contato com os

mestres e os colegas de curso que tiveram grande participação nesta jornada.

A Ana Marta, que nos permitiu utilizar a sua empresa como parte

fundamental para a realização deste trabalho e disponibilidade em nos receber.

A minha parceira deste trabalho, Maria Luiza da Silva, pelo último ano em

que passamos juntos para a realização deste trabalho, pela dedicação e paciência.

E a todos que participaram direta ou indiretamente deste momento, muito

obrigado.

Maria Luiza da Silva agradece a:

Meu pai, por sua confiança e investimento em mim, sem os quais não

poderia ter concluído esse curso. Também gostaria de agradecer a minha mãe, por

seu apoio inabalável e confiança em mim.

Ao nosso orientador Prof. Maurício Botelho, por sua orientação sempre

presente, sua disposição em nos ajudar e tirar dúvidas em qualquer momento que

fosse necessário.

A Prof.ª Maria Inés Castiñeira, por seu apoio em momentos de

insegurança e por seus conselhos.

A proprietária da cantina, Ana Marta, que nos permitiu utilizar o seu

negócio como case para realizar a implementação do sistema e que sempre esteve

disponível para marcar encontros e tirar dúvidas.

A todos os meus familiares e amigos que me apoiaram e encorajaram

para a conclusão desse trabalho.

Ao Clayton Boneli, por me ensinar a programação na prática e

compartilhar muitos dos seus conhecimentos comigo que foram muito importantes

para a implementação do sistema realizado neste trabalho.

Por fim, não poderia deixar de agradecer ao meu parceiro desse trabalho,

Diego Salomão, por ter passado esses dois semestres comigo realizando esse

trabalho e por dar o seu melhor em tudo o que faz.

“O sucesso nasce do querer, da determinação e persistência em se chegar a um

objetivo. Mesmo não atingindo o alvo, quem busca e vence obstáculos, no mínimo

fará coisas admiráveis.” (José de Alencar).

RESUMO

A engenharia de software apresenta diferentes modelos de processos de

desenvolvimento de software, dentre estes, estão os modelos tradicionais e os

modelos ágeis. Os modelos tradicionais apresentam uma forma mais incisiva em

documentação de software e abordam a utilização da Unified Modeling Language

(UML) para elaboração de diferentes diagramas para proporcionar diferentes visões

do sistema. Os modelos ágeis defendem que a interação entre as pessoas são mais

importantes que a documentação, mas não restringe que seja documentado. Alguns

dos principais motivos apresentados pelos autores que defendem as metodologias

ágeis, são a dificuldade em manter uma documentação atualizada devido à

mudanças que frequentemente ocorrem durante a fase de desenvolvimento de

sistemas e também que as pessoas são mais importantes que os processos. Este

trabalho apresenta uma pesquisa aplicada que busca documentar e conduzir o

desenvolvimento de um software utilizando o framework Scrum com seus

respectivos artefatos (histórias de usuário e critérios de aceite) apoiado a alguns dos

diagramas da UML, sendo eles o de casos de uso, o de classes e o de sequências.

A junção de alguns diagramas da UML em um processo de desenvolvimento que

utiliza o Scrum pode agregar muito para que mesmo sendo um projeto que utiliza

princípios ágeis, possa conter o mínimo de uma documentação que de fato tenha

sentido para o desenvolvimento e que agregue valor ao processo, porém, sem

perder o foco ágil. Para testar o objetivo deste trabalho, foi realizado o

desenvolvimento de um software de gestão para uma cantina escolar com

funcionalidades simples, seguindo o Scrum. Foram elaborados os respectivos

diagramas da UML e os artefatos previstos do Scrum, ao final, o software foi

desenvolvido dentro do prazo e os critérios de aceitação foram atendidos, o que

demonstra um resultado positivo da metodologia utilizada em relação ao cenário.

Palavras chaves: Metodologias de Desenvolvimento. Metodologias Ágeis. Scrum.

Scrum com UML.

ABSTRACT

Software Engineering applies different methods of software development processes.

We can list among them the classic or waterfall model and the agile model: the

classic model is strict when it comes to software documentation and makes use of

the Unified Modeling Language (UML) for the preparation of different diagrams which

provides different views of the system. The agile model priorizes the interaction with

people even more than documentation, what doesn´t mean that documentation is not

important. Actually, it is really difficult to maintain a up to date documentation in this

method due to the several changes during the system development phase. Besides

that, user’s involvment is imperative. It is over the processes. This paper presents an

applied research that documents and conduces the development of a software which

makes use of the Scrum Framework as its characteristics (computer's users stories

and acceptance criterias). Also it presents some UML diagrams as the use case

diagram, the class diagram and the sequence diagram in a case study. The addition

of some UML diagrams in a development process using Scrum can add up a lot even

though its a project using agile principles. It helps the project in a way it contains the

minimum documentation necessary to develop and it also values the process. All of

that without losing the agile focus . To test the objective of this work was carried out

a development of a management software for a school canteen with its simple

functionalities, following the Scrum. Their UML diagrams and expected

characteristics of Scrum were prepared at the end. The software was developed on

time and the acceptance criterias have been met, which shows a positive result of

the methodology used in the scenary.

Keywords: Development Methodologies. Agile Methodologies. Scrum. Scrum with

UML.

LISTA DE ILUSTRAÇÕES

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

Figura 2 – O modelo em Cascata ....................................................................................... 25 Figura 3 – O processo de desenvolvimento de software na realidade ......................... 26

Figura 4 – O modelo em Espiral .......................................................................................... 27 Figura 5 – Framework e utilização do RUP ....................................................................... 29 Figura 6 – O ciclo de vida de desenvolvimento de um software .................................... 30

Figura 7 – Processo XP ........................................................................................................ 35 Figura 8 – Planejamento da Sprint ..................................................................................... 36

Figura 9 – Três exemplos de formatos de Product Backlog ........................................... 39

Figura 10 – Exemplo de História de Usuário ..................................................................... 40

Figura 11 – Sprint Backlog ................................................................................................... 41 Figura 12 – Ciclo de vida do Scrum .................................................................................... 42

Figura 13 – Representação esquemática de uma Sprint ................................................ 43

Figura 14 – Exemplo simples de definição de preparado ............................................... 44 Figura 15 – Gráfico de Burndown ....................................................................................... 46

Figura 16 – Exemplo simples de um acordo de definição de pronto ............................ 47 Figura 17 – O ciclo de vida de desenvolvimento de um software ................................. 50

Figura 18 – Representação da classe ................................................................................ 54 Figura 19 – Notação de generalização .............................................................................. 55 Figura 20 – Agregação ......................................................................................................... 56

Figura 21 – Composição ....................................................................................................... 56 Figura 22 – Diagrama de Classes ....................................................................................... 56

Figura 23 – Exemplos de atores ......................................................................................... 58

Figura 24 – Documentação do caso de uso de abertura de conta ................................ 58

Figura 25 – Diagrama de caso de uso - include ............................................................... 59

Figura 26 – Diagrama de caso de uso - extend ................................................................ 60 Figura 27 – Diagrama de caso de uso - generalização ................................................... 60

Figura 28 – Diagrama de caso de uso – atores x casos de uso .................................... 61 Figura 29 – Tipos de mensagens ........................................................................................ 63

Figura 30 – Diagrama de sequência ................................................................................... 63

Figura 31 – Etapa metodológica ......................................................................................... 67

Figura 32 – Arquitetura da solução ..................................................................................... 68 Figura 33 – Diagrama de Caso de Uso e Atores .............................................................. 77 Figura 34 – Diagrama de Classes – Cantina Escolar ...................................................... 95

Figura 35 – Diagrama de Sequência – Incluir Venda ...................................................... 96

Figura 36 – Diagrama de Sequência – Alterar Venda ..................................................... 97

Figura 37 – Diagrama de Sequência – Consultar Venda ................................................ 98

Figura 38 – Diagrama de Sequência – Excluir Venda ..................................................... 98

Figura 39 – Tarefas da Sprint 4 ......................................................................................... 102 Figura 40 – Gráfico de Burndown – Sprint 4 ................................................................... 104 Figura 41 – Ferramentas Utilizadas .................................................................................. 108

Figura 42 – Interface da tela que permite inserir créditos ............................................. 116 Figura 43 – Interface da tela que permite a realização de vendas .............................. 117

Figura 44 – Interface da tela que permite a finalização de vendas ............................. 118 Figura 45 – Interface da tela que permite realizar compras ......................................... 119

LISTA DE QUADROS

Quadro 1 – Atributos essenciais de um bom software. ................................................... 22

Quadro 2 – Princípios dos métodos ágeis ......................................................................... 32 Quadro 3 – Divisão de tarefas nos papéis do Scrum. ..................................................... 38

Quadro 4 – Exemplo de Critérios de Aceitação ................................................................ 40 Quadro 5 – Exemplos de multiplicidade ............................................................................. 55 Quadro 6 – Descrição dos Requisitos Funcionais ........................................................... 73

Quadro 7 – Descrição dos Requisitos Não Funcionais ................................................... 74 Quadro 8 – Descrição das Regras de Negócio ................................................................ 74

Quadro 9 – Documentação do caso de uso “Cadastrar Produtos” ............................... 77

Quadro 10 – Documentação do caso de uso “Cadastrar Clientes” ............................... 79

Quadro 11 – Documentação do caso de uso “Cadastrar Fornecedores”..................... 81 Quadro 12 – Documentação do caso de uso “Recarregar Saldo em Cartão” ............. 84

Quadro 13 – Documentação do caso de uso “Registrar compras” ............................... 84

Quadro 14 – Documentação do caso de uso “Realizar Venda de Produtos” .............. 86 Quadro 15 – História de usuário – “Cadastro de Clientes” ............................................. 90

Quadro 16 – História de usuário – “Cadastro de Fornecedores” ................................... 91 Quadro 17 – História de usuário – “Cadastro de Produtos” ........................................... 91

Quadro 18 – História de usuário – “Recarga de Saldo em Cartão” ............................... 92 Quadro 19 – História de usuário – “Compra de Produtos” ............................................. 92 Quadro 20 – História de usuário – “Venda de Produtos” ................................................ 93

Quadro 21 – Time Scrum ..................................................................................................... 99 Quadro 22 – Planejamento das Sprints ........................................................................... 100

Quadro 23 – Estimativa das tarefas da história “Venda de Produtos” ........................ 103

Quadro 24 – Retrospectiva da Sprint ............................................................................... 106

SUMÁRIO

1 INTRODUÇÃO ............................................................................................................................. 14

1.1 PROBLEMA ................................................................................................................................17 1.2 OBJETIVOS ................................................................................................................................18 1.2.1 Objetivo Geral ..........................................................................................................................19 1.2.2 Objetivos Específicos ...............................................................................................................19 1.3 JUSTIFICATIVA .........................................................................................................................19 1.4 ESTRUTURA DA MONOGRAFIA ...........................................................................................20

2 ENGENHARIA DE SOFTWARE ............................................................................................... 22

2.1 MODELOS DE DESENVOLVIMENTO DE SOFTWARE .......................................................24 2.1.1 Modelos Tradicionais...............................................................................................................24 2.1.1.1 Modelo em Cascata ................................................................................................................ 25 2.1.1.2 Modelo em Espiral ................................................................................................................. 26 2.1.2 Rational Unified Process (RUP) ..............................................................................................28 2.1.3 Modelos Ágeis ...........................................................................................................................31 2.1.3.1 Extreme Programming (XP) ................................................................................................... 33 2.1.3.2 Scrum ..................................................................................................................................... 35 2.1.3.2.1 Papéis do Scrum ..................................................................................................................37 2.1.3.2.2 Product Backlog ..................................................................................................................38 2.1.3.2.2.1 HISTÓRIAS DE USUÁRIO (USER STORIES) ....................................................... 39 2.1.3.2.2.2 CRITÉRIOS DE ACEITAÇÃO ................................................................................... 40 2.1.3.2.3 Sprint Backlog ......................................................................................................................41 2.1.3.2.4 Sprint ....................................................................................................................................41 2.1.3.2.5 Reunião de Planejamento da Sprint (Sprint Planning) .......................................................43 2.1.3.2.6 Scrum Diárias (Daily Scrum) ..............................................................................................45 2.1.3.2.6.1 GRÁFICO BURNDOWN ............................................................................................. 45 2.1.3.2.7 Revisão da Sprint (SPRINT REVIEW) .................................................................................46 2.1.3.2.8 Retrospectiva da Sprint (Sprint Retrospective) ....................................................................48 2.2 DESENVOLVIMENTO DE SOFTWARE UTILIZANDO A UNIFIED MODELING LANGUAGE (UML) .............................................................................................................................48 2.2.1 Requisitos ..................................................................................................................................51 2.2.1.1.1 Requisitos Funcionais ..........................................................................................................51 2.2.1.1.2 Requisitos Não funcionais....................................................................................................52 2.2.1.1.3 Regras de Negócio ...............................................................................................................53 2.2.2 Diagrama de Classes ................................................................................................................53 2.2.3 Diagrama de Casos de Uso ......................................................................................................57 2.2.4 Diagrama de Sequência ...........................................................................................................62 2.3 SCRUM COM UML ....................................................................................................................64

3 MÉTODO ....................................................................................................................................... 65

3.1 CARACTERIZAÇÃO DO TIPO DE PESQUISA ....................................................................65 3.2 ETAPAS DE EXECUÇÃO DO PROJETO .............................................................................66 3.3 ARQUITETURA DA SOLUÇÃO...............................................................................................68 3.4 DELIMITAÇÕES .........................................................................................................................69

4 MODELAGEM .............................................................................................................................. 70

4.1 O CASE UTILIZADO PARA APLICAR A PROPOSTA ........................................................70 4.1.1 Etapa de Levantamento de Requisitos ...................................................................................71 4.1.2 Etapa de Desenvolvimento da Proposta .................................................................................72 4.1.2.1 Casos de Uso .......................................................................................................................... 73

4.1.2.2 Product Backlog ..................................................................................................................... 89 4.1.2.2.1 Histórias de Usuário ............................................................................................................89 4.1.2.3 Time do SCRUM .................................................................................................................... 99 4.1.2.4 SPRINT ................................................................................................................................. 100 4.1.2.5 SPRINT Planning ................................................................................................................. 100 4.1.2.6 SPRINT Backlog ................................................................................................................... 101 4.1.2.7 Tarefas .................................................................................................................................. 101 4.1.2.8 Reunião Diária...................................................................................................................... 103 4.1.2.9 Revisão da SPRINT .............................................................................................................. 105 4.1.2.10 Retrospectiva da SPRINT ................................................................................................... 105

5 DESENVOLVIMENTO DA PROPOSTA ................................................................................ 108

5.1 FERRAMENTAS E TECNOLOGIA .......................................................................................108 5.1.1 Java .........................................................................................................................................109 5.1.2 Enterprise Architect (EA) .....................................................................................................109 5.1.3 Trello .......................................................................................................................................109 5.1.4 Maven ......................................................................................................................................110 5.1.5 JSF ...........................................................................................................................................110 5.1.6 Primefaces ...............................................................................................................................110 5.1.7 Eclipse .....................................................................................................................................111 5.1.8 Mysql .......................................................................................................................................111 5.1.9 Tomcat ....................................................................................................................................111 5.1.10 Balsamiq .................................................................................................................................112 5.2 PROCESSOS DE DESENVOLVIMENTO (HISTÓRIA) .....................................................112 5.3 APRESENTAÇÃO DO SISTEMA ..........................................................................................116 5.4 CONSIDERAÇÕES FINAIS ...................................................................................................119

6 CONCLUSÕES E TRABALHOS FUTUROS ........................................................................ 121

6.1 CONCLUSÂO ...........................................................................................................................121 6.2 TRABALHOS FUTUROS ........................................................................................................123

REFERÊNCIAS ................................................................................................................................ 124

APÊNDICES ..................................................................................................................................... 127

APÊNDICE A – CRONOGRAMA .................................................................................................. 128

14

1 INTRODUÇÃO

O processo de desenvolvimento de software sempre foi um assunto

bastante discutido. Tais processos visam dar suporte aos quesitos produtividade e

qualidade que atendam as expectativas do cliente e que sejam viáveis para o

negócio.

Quando se iniciava a década de 1980, uma reportagem de primeira página da revista Business Week trazia a seguinte manchete: “Software: A Nova Força Propulsora”. O software amadurecera – tornara-se um tema de preocupação administrativa. Em meados da década de 1989, uma reportagem de capa de Fortune lamentava “Uma Crescente Defasagem de Software” e, ao final da década, a Business Week avisava os gerentes sobre a “Armadilha do Software – Automatizar ou não”. No começo da década de 1990, uma reportagem especial da Newsweek perguntava: “Podemos Confiar em Nosso Software:” enquanto o Wall Street Journal relacionava as “dores de parto” de uma grande empresa de software com um artigo de primeira página intitulado “Criar Software Novo: Era uma Tarefa Agonizante...”. Essas manchetes, e muitas outras iguais a elas, eram o anúncio de uma nova compreensão da importância do software de computador – as oportunidades que ele oferece e os perigos que apresenta. (PRESSMAN, 1995, p. 3).

Com a exploração do potencial de softwares para melhor posicionamento

de mercado das empresas foi preciso oferecer soluções que de fato atendessem as

necessidades das organizações e que agregassem valor ao negócio.

O objetivo principal de um software é dar suporte aos usuários; logo, para o software ter sucesso, ele deverá atender às expectativas e necessidades dos usuários que o utilizarão. Neste contexto, a palavra usuário não se refere apenas a pessoas, ela pode designar também outros sistemas que tenham que interagir com o software em questão. (MARTINS, 2006, p. 138).

Conforme abordado por Hirama (2011), em busca de atingir os objetivos

do software, com o tempo foram propostos alguns processos para conduzir o

desenvolvimento de software. Um dos processos de desenvolvimento bastante

utilizado nas décadas de 1970 e 1980 foi o modelo Cascata. Como o próprio nome

já sugere, este processo é composto por etapas que são dependentes uma da outra.

Comumente é utilizado quando os requisitos estão bem definidos e possuem uma

boa estabilidade (PRESSMAN, 2011). Uma das desvantagens deste modelo, é que

pode acarretar em problemas caso houver a necessidade de alteração de requisitos,

visto que o respectivo modelo não permite alterações no meio do processo, pois

15

prevê que uma funcionalidade apenas poderá ser alterada após ter sido concluída

(SANTANA, 2013).

O processo Cascata define um desenvolvimento linear e sequencial do software. Da maneira como é proposto, ele não se adapta facilmente às novas exigências de mercado. Enquanto o processo Cascata é focado na entrega de um sistema completo no fim do seu processo, os processos Evolutivos são iterativos: o software é desenvolvido evolutivamente em direção ao produto final cada vez mais completo. (HIRAMA, 2011, p. 31).

De forma geral, Hirama (2011) apresentou que o modelo Cascata possui

algumas limitações que podem comprometer o projeto caso os requisitos não

estejam estáveis. Para solucionar alguns pontos negativos do modelo Cascata,

foram apresentados alguns processos do tipo “Evolutivo”. A diferença básica entre

estes processos é que o processo Evolutivo suporta alterações de requisitos durante

o desenvolvimento do software, o que proporciona melhor controle e gestão de

riscos do projeto.

Um modelo Evolutivo que foi apresentado é o Espiral, Pressman (2011, p.

65), afirma que este “é um modelo de software evolucionário que acopla a natureza

iterativa da prototipação com os aspectos sistemáticos e controlados do modelo

cascata”, o que potencializa o desenvolvimento de versões mais completas do

software.

Dos modelos de desenvolvimento tradicionais apresentados até então,

segundo Medeiros (2004), eles dão uma visão única do processo, e com a

necessidade de se obter uma visão do projeto como um todo, Ivar Jacobson

apresentou uma nova forma de se ver o processo de desenvolvimento, este com

foco na arquitetura. Este processo é o Rational Unified Process (RUP).

De acordo com Mendes (2014), O RUP é um processo de

desenvolvimento de software criado pela Rational Software Corporation e em 2003

foi adquirida pela IBM. O RUP consiste em várias etapas de entregas de forma a

agregar mais valor ao produto e diminuir os riscos de projeto. Ao utilizar o RUP,

ocorrem validações e verificações do que foi produzido, permitindo um melhor

gerenciamento. A linguagem utilizada para apoiar o RUP é a Unified Modeling

Language (UML), que de maneira geral, é destinada a visualizar, especificar,

construir e documentar um projeto de software.

16

Matos et al. (2014), cita que as necessidades de mercado como a rápida

evolução tecnológica, pressão para que o sistema seja entregue rapidamente e

mudanças frequentes no ambiente de negócio do cliente, trouxeram novos desafios

para a engenharia de requisitos. As Metodologias Ágeis (MA) surgiram com o

objetivo de atender a esta demanda, com foco principal em garantir a entrega de um

software em menor tempo, com qualidade e que atenda as necessidades do cliente.

Visando customizar o processo de desenvolvimento de software,

Sutherland (2014) começou a pesquisar novas formas de melhorar o modo de

trabalho, o que mais tarde ficou conhecido como Scrum. O Scrum é um framework

de MA que vem sendo adotado por várias empresas, pois busca realizar uma

melhoria contínua no processo, onde ao final do processo de desenvolvimento, é

realizada uma retrospectiva de alinhamento que permite verificar o que pode ser

melhorado. O Scrum busca uma nova forma de trabalho, que propõe maior foco na

produtividade por meio da interação dos próprios desenvolvedores e clientes.

Scrum é um framework para gerenciamento de projetos ágeis muito utilizado na área de desenvolvimento de software. Uma das principais características do Scrum é permitir o desenvolvimento de produtos complexos de uma forma incremental e iterativa, contribuindo para decompor um grande produto complexo, em pequenos subprodutos mais simples, mais rápidos e mais fáceis de serem desenvolvidos e entregues. No Scrum estas iterações são chamadas de Sprints, e uma característica marcante de sua estrutura e aplicação é o controle sobre os trabalhos realizados, e a possibilidade de correção e adaptação rápida, permitindo que a equipe altere sua forma de agir ou de pensar o mais breve possível, evitando que problemas ou erros causem danos maiores ao projeto. (MARIOTTI, 2012, p. 7).

Santana (2014) apresenta um comparativo entre os processos de

desenvolvimento RUP e Scrum, onde de um lado o RUP apresenta uma proposta de

metodologia bem estruturada e que é aceita com sucesso no mercado de

desenvolvimento de software, porém requer grande número de documentos em seu

modelo, o que leva a ser considerado como uma abordagem pesada e muito

burocrática. Por outro lado, o Scrum apresenta uma abordagem que valoriza mais a

interação com o cliente para diminuir a necessidade de documentação, o que propõe

que seja apresentado resultados mais rápidos, uma vez que há o acompanhamento

mais próximo do cliente junto ao desenvolvimento.

Com base nos cenários expostos do RUP e MA, este trabalho propõe o

uso do framework Scrum apoiado a alguns diagramas da UML para auxiliar na

elicitação das funcionalidades de sistema, tendo como estudo de caso um cenário

17

que possibilite testar a utilização dos artefatos a serem levantados. Ao final, espera-

se obter um sistema com qualidade, consumindo menor recurso de tempo e que

principalmente, atenda as necessidades de negócio.

1.1 PROBLEMA

Os processos de desenvolvimento de software estão sempre evoluindo

para satisfazer as necessidades de mercado. Para Machado (2011, p. 19), “a

evolução das técnicas para processos de desenvolvimento de software é uma

constante na busca da construção de sistemas mais confiáveis, dentro de prazos

razoáveis, e com qualidade que satisfaça as necessidades do cliente final”.

De um lado o Scrum propõe uma forma interativa do time de

desenvolvimento e cliente (SUTHERLAND, 2014), e de outro, diversos autores da

literatura de engenharia de software apresentam a importância de se documentar

software (PRESSMAN, 2011; BOOCH et al., 2000).

Aproveitando a necessidade de uma cantina escolar, localizada no

município de São José – SC, de controlar o movimento de vendas, este trabalho

utiliza este cenário como um case para testar a utilização de uma forma de

desenvolvimento que possa resultar em um software para a cantina. Busca-se uma

forma que o cliente possa participar do projeto de forma efetiva, que o software seja

entregue em menor tempo, que seja previsto a possibilidade de alteração de

requisitos durante o desenvolvimento e que satisfaça as necessidades da

proprietária da cantina.

Conforme uma prévia apresentada na introdução deste trabalho, os

modelos em cascata e espiral, não seriam uma boa escolha para atingir o objetivo

do trabalho visto que o modelo cascata apresenta restrições à mudança de

requisitos durante o processo de desenvolvimento (HIRAMA, 2011), e o modelo

espiral apesar de possibilitar a alteração de requisitos, segundo Sommerville (2007)

exige uma série de avaliações para gerenciamento de riscos que podem

comprometer o tempo de entrega para o cliente.

18

O RUP seria uma opção para este trabalho, porém, dentre algumas

desvantagens que ele apresenta, uma bastante relevante que o levou não ser

escolhido neste projeto, foi o fato de que exige um grande número de documentos

(SANTANA, 2014), o que pode ser muito burocrático para o cenário exposto da

cantina.

Por último, o método ágil Scrum parece ser uma boa alternativa para se

utilizar neste cenário, visto que conforme apresentado por Santana (2014),

apresenta uma abordagem que valoriza muito a interação com o cliente para

diminuir a documentação. Havendo a necessidade de se utilizar uma documentação

mais técnica para apoiar o desenvolvimento, a utilização da UML é uma boa

alternativa, pois conforme um experimento que Silva (2012, p. 16), realizou

utilizando a UML em um projeto Scrum, ele compartilha a conclusão de que

“qualquer projeto pode seguir práticas ágeis e utilizar artefatos UML que se

encaixem no seu processo de desenvolvimento”, e finaliza enfatizando que o Scrum

não limita utilizar a UML em seu ciclo de vida.

O desenvolvimento de software utilizando apenas o Scrum pode deixar a

desejar de uma documentação básica que auxilia tanto a elicitação das

necessidades do cliente quanto os desenvolvedores a construir algo que de fato o

cliente espera.

1.2 OBJETIVOS

Apresentam-se os objetivos a serem alcançados através de um estudo de

caso.

19

1.2.1 OBJETIVO GERAL

Utilizar o framework Scrum em conjunto com diagramas da UML para

analisar a eficácia destas abordagens no decorrer das etapas de análise e

desenvolvimento de software.

1.2.2 OBJETIVOS ESPECÍFICOS

Os objetivos específicos deste trabalho são:

Realizar pesquisa bibliográfica para levantar informações que embasam

a produção deste trabalho;

Elaborar modelagem e documentação utilizando Scrum e diagramas da

UML para o desenvolvimento de software utilizando um cenário para

estudo de caso;

Desenvolver um software testando os artefatos de análise produzidos;

Apresentar os resultados obtidos do teste de desenvolvimento com os

artefatos produzidos.

1.3 JUSTIFICATIVA

Considerando que o principal produto de um time de desenvolvimento

seja um software que atenda as expectativas e necessidades dos usuários e seus

respectivos negócios (BOOCH et al., 2000), é importante que o processo de

desenvolvimento seja ajustado para que possa atender a estes princípios.

Em determinados projetos de desenvolvimento de software, pode ser que

uma proposta de documentar o projeto inteiro seguindo modelagens tradicionais

20

torne-se exaustivo e não traga um custo/benefício que o justifique como sendo um

pré-requisito indispensável a ser adotado para documentar as necessidades a serem

atendidas do cliente.

Há a hipótese de se utilizar o Scrum apoiado a alguns diagramas da UML

para conduzir um processo de desenvolvimento de software orientado às

metodologias ágeis. Para Silva (2012 p. 16), “qualquer projeto pode seguir práticas

ágeis e utilizar artefatos UML que se encaixem no seu processo de

desenvolvimento”.

Considerando então que não há restrições nas metodologias ágeis para

se utilizar a UML como ferramenta de apoio para documentação, este trabalho

busca desenvolver um software utilizando o Scrum de forma a minimizar custos com

mudanças e propor maior flexibilidade para caso houver alterações de requisitos.

Procura-se verificar se é possível elaborar uma documentação para

desenvolvimento de software que possua qualidade, que atenda as necessidades do

cliente, porém prezando a documentar apenas o essencial e, aproveitar ao máximo

os princípios das metodologias ágeis (interação entre as pessoas).

1.4 ESTRUTURA DA MONOGRAFIA

O trabalho está organizado em 6 capítulos. O Capítulo 1 apresenta a

introdução, o problema, os objetivos gerais e específicos e a justificativa que motivou

a realização do trabalho.

O Capítulo 2 apresenta os conceitos básicos sobre engenharia de

software, modelos de desenvolvimento tradicionais e ágeis. Ao final, apresenta-se

um fechamento abordando de forma conjunta como a UML pode ser introduzida no

desenvolvimento de software que utiliza o framework Scrum.

O Capítulo 3 apresenta o método científico e a proposta de solução para

a obtenção de um documento para o desenvolvimento de software utilizando o

Scrum com apoio de diagramas da UML, além das delimitações a que este trabalho

se propõe.

21

O Capítulo 4 apresenta a modelagem do trabalho, desde o levantamento

de requisitos, passando pelo planejamento previsto pelo Scrum, como a UML foi

utilizada para apoiar o desenvolvimento, até o fechamento do ciclo da sprint.

O Capítulo 5 apresenta as ferramentas utilizadas para o desenvolvimento

deste trabalho, bem como o sistema que foi produzido como case para testar a

aplicabilidade deste trabalho.

O Capítulo 6 apresenta as conclusões, considerações finais e trabalho

futuros.

22

2 ENGENHARIA DE SOFTWARE

Para dar início ao tema principal deste trabalho, bem como abordar os

assuntos que embasam todo o contexto, é importante apresentar o tema de

engenharia de software, pois assim será possível obter informações para uma

melhor compreensão das abordagens que serão utilizadas neste trabalho.

O software se tornou essencial para o mundo moderno, uma espécie de

combustível, pois propicia diversos mecanismos de controle baseados em

infraestrutura que dispõem de sistemas de computador, por exemplo, a maioria dos

produtos elétricos possuem um computador e um software para controlá-lo.

(KRUCHTEN, 2003; SOMMERVILLE, 2007).

Para Sommerville (2007), não existem limitações físicas no potencial de

software e isso simplifica a engenharia de software. Porém essa falta de restrições

pode ser perigosa, pois este software pode se tornar difícil de ser compreendido se

ficar muito complexo. Diante disso, Sommerville destaca os atributos indispensáveis

para um software, conforme demonstra o quadro 1.

Quadro 1 – Atributos essenciais de um bom software.

Características do produto Descrição

Facilidade de manutenção

O software deve ser escrito de modo que possa evoluir para atender às necessidades de mudança dos clientes. É um atributo fundamental, pois a mudança de software é uma consequência inevitável de um ambiente de negócios em constante mutação.

Confiança

O nível de confiança do software tem uma série de características, incluindo confiabilidade, proteção e segurança. Um software confiável não deve causar danos físicos ou econômicos no caso de falha no sistema.

Eficiência

O software não deve desperdiçar os recursos do sistema, como memória e ciclos do processador. Portanto, a eficiência inclui tempo de resposta, tempo de processamento, utilização de memória etc.

Usabilidade

O software deve ser usável, sem esforço excessivo, pelo tipo de usuário para o qual ele foi projetado. Isso significa que ele deve apresentar uma interface com o usuário e documentação adequadas

Fonte: SOMMERVILLE (2007, p. 9).

Diante dos atributos essenciais de um bom software apresentado por

Sommerville (2007) representados no quadro 1, Martins (2006) e Kruchten (2003)

23

por outro lado, apresentam causas que podem levar projetos de desenvolvimento de

software ao fracasso. Alguns dos itens mencionados por estes autores são: o

gerenciamento informal dos requisitos, a não compreensão das necessidades do

cliente, falta de flexibilidade para gerenciar a mudança de requisitos, falta de

experiência para prever possíveis falhas de projeto, falta de organização e

comunicação com a equipe envolvida no projeto, testes insuficientes, dentre outros.

Com o conceito de software bem definido, fica mais fácil o entendimento

do que é Engenharia de Software, para Pressman (2011, p. 39) “a engenharia de

software é um ramo da engenharia cujo foco é o desenvolvimento dentro de custos

adequados de sistemas de software de alta qualidade [...]”.

Qualquer abordagem de engenharia precisa estar fundamentada e

comprometida com a qualidade, desta forma, os engenheiros e demais pessoas

envolvidas precisam estar aptas a aplicarem métodos e ferramentas que atendam as

necessidades apoiados por processos, conforme esboço demonstrado na figura 1

(PRESSMAN, 2011; SOMMERVILLE, 2007).

Figura 1 – Camadas da engenharia de software

Fonte: PRESMAN (2011, p. 39).

De acordo com a figura 1, observa-se que as camadas da engenharia de

software têm como base o foco na qualidade.

Nos últimos 50 anos diferentes grupos, especialistas e pesquisadores da área de TI, vêm disponibilizando diversas metodologias para apoiar essa difícil tarefa de desenvolvimento de software, tais como: modelo cascata, espiral, RAD, RUP, Crystal, Scrum, XP, PFF, Lean, DSDM entre outros (MARIOTTI, 2012, pág. 6).

Existem diversas abordagens para desenvolver um software. Para

Sommerville (2007, p. 4) “[...] noções fundamentais de processo e de organização de

24

sistemas constituem a base de todas essas técnicas que constituem a essência da

engenharia de software”.

2.1 MODELOS DE DESENVOLVIMENTO DE SOFTWARE

Na engenharia de software existem diversos modelos de processo de

desenvolvimento, e muitos foram propostos ao logo dos anos (PFLEEGER, 2004).

Segundo Pfleenger (2004, p. 38) “todo processo de desenvolvimento de

software tem como entrada os requisitos do sistema e como saída um produto

fornecido”.

Os modelos tradicionais geralmente são desenvolvidos em sequencia em

que as etapas de planejamento, análise, design, codificação, testes e documentação

são feitas uma única vez e em sequência. Já os modelos ágeis, geralmente são

utilizados ciclos curtos com duração de poucas semanas, o que facilita mudanças,

pois proporciona um feedback constante (GOMES, 2013). A seguir são abordados

os modelos tradicionais e ágeis.

2.1.1 MODELOS TRADICIONAIS

Os modelos de tradicionais de desenvolvimento de software permitem

maior controle do andamento do projeto, visto que as atividades precisam ser

executadas em ordem para que o processo funcione como um todo (MATOS et al.,

2014).

“Em contra partida, os processos tradicionais ou em cascata, que eram amplamente utilizados do mercado antes dos métodos ágeis, assumem que o desenvolvimento de software pode ser realizado através de uma sequência de atividades facilmente identificadas, previsíveis e repetíveis, mas diferente de outras engenharias, desenvolvimento de software requer criatividade, e geralmente envolve um ato.” (GOMES, 2013, pág. 9).

25

Dos modelos tradicionais de desenvolvimento de software, serão

apresentados alguns dos mais populares, sendo eles: Modelo Cascata e Modelo em

Espiral. Em seguida, será apresentado o RUP, uma unificação dos processos

tradicionais. Apesar de não ser o foco principal deste trabalho, os respectivos

modelos tradicionais serão apresentados de forma sucinta para criar um

embasamento de forma a levar a um melhor entendimento do porque da utilização

do Scrum com apoio da UML que será abordado posteriormente.

2.1.1.1 MODELO EM CASCATA

No modelo em Cascata existe um encadeamento de uma fase com a

outra, no qual o desenvolvimento deve terminar antes do próximo começar. Inicia-se

quando todos os requisitos estiverem enunciados pelo cliente de forma completa,

analisadas as consistências destes requisitos e tiverem sido documentadas em uma

especificação de requisitos. A partir de então, o time de desenvolvimento pode

realizar as atividades de projeto do sistema. É possível entender bem este modelo

observando a figura 2 (PFLEEGER, 2004; SOMMERVILLE, 2007).

Figura 2 – O modelo em Cascata

Fonte: PFLEEGER (2004, p. 39).

26

Sommerville (2007) destaca que as vantagens deste modelo são que em

cada fase existe uma documentação e sua aderência a outros modelos de processo

de engenharia. E a grande desvantagem é a dificuldade de alterações de requisitos

do usuário, por isso é sugerido que este modelo seja usado quando os requisitos

forem bem definidos e a probabilidade de mudança for muito pouca.

A figura 3 mostra o quanto pode ser difícil seguir o modelo em Cascata,

considerando um cenário que necessite de alterações de requisitos ou que algo faça

com que seja necessário realizar uma tarefa anterior.

Figura 3 – O processo de desenvolvimento de software na realidade

Fonte: PFLEEGER (2004, p. 40).

O modelo Cascata passou a ser questionado na década de 1990 devido

às exigências de produtividade e qualidade, quando da chegada dos métodos ágeis

que traziam esta proposta (HIRAMA, 2011).

2.1.1.2 MODELO EM ESPIRAL

Tanto Pfleenger (2004) como Sommerville (2007), apontam que o modelo

em Espiral foi proposto por Boehm, pois ele buscava encontrar uma forma de

27

controlar os riscos, sendo assim, sugeriu que este modelo poderia combinar

atividades de desenvolvimento com o gerenciamento de riscos.

Segundo Pfleenger (2004, p. 46), “em cada iteração, análise de riscos

poderá diferentes alternativas em face dos requisitos e das restrições. A

prototipação verifica a viabilidade e a adequação, antes que haja a decisão por

alguma alternativa”.

Um ciclo da espiral começa com a elaboração de objetivos, como desempenho e funcionalidade. Os caminhos alternativos para alcançar esses objetivos e as fontes de riscos de projetos são identificados. O próximo passo é resolver esses riscos por meio de atividades de coleta de informações, tais como análise mais detalhada, prototipação e simulação. Após a avaliação dos riscos, é realizada uma parte do desenvolvimento, seguida pela atividade de planejamento para a próxima fase do processo (SOMMERVILLE, 2007, pág. 49).

Com a figura 4, pode-se entender melhor o funcionamento do modelo

Espiral.

Figura 4 – O modelo em Espiral

28

Fonte: PFLEEGER (2004 p. 49).

Observe que o modelo Espiral inicia-se na atividade de planejamento e

segue a partir de seu centro no sentido horário. Este modelo permite que tanto o

cliente quanto o desenvolvedor compreendam os riscos em cada nível da evolução

do projeto. Note que diferente do modelo cascata, há diversas etapas de validação

da fase anterior (HIRAMA, 2011).

2.1.2 RATIONAL UNIFIED PROCESS (RUP)

Sommerville (2007, p. 54), menciona que “o Rational Unified Process

(RUP) é um exemplo de processo moderno que foi derivado do trabalho sobre a

UML e do Processo Unificado de Desenvolvimento de Software associado”.

O Processo Unificado é uma tentativa de aproveitar os melhores recursos e características dos modelos tradicionais de processo de software, mas caracterizando-os de modo a implementar muitos dos melhores princípios do desenvolvimento ágil de software. O Processo Unificado reconhece a importância da comunicação com o cliente e de métodos racionalizados (sequencializados) para descrever a visão do cliente sobre um sistema (os

29

casos de uso). Ele enfatiza o importante papel da arquitetura de software e “ajuda o arquiteto a manter o foco nas metas corretas, tais como compreensibilidade, confiança em mudanças futuras e reutilização”. Ele sugere um fluxo de processo iterativo e incremental, proporcionando a sensação evolucionária que é essencial no desenvolvimento de software moderno (PRESSMAN, 2011, p. 71).

De acordo com Martins (2006, p. 175), o RUP “é uma metodologia para

gerenciar projetos de desenvolvimento de software que usa o UML como ferramenta

para especificação de sistemas”.

O RUP define as etapas do projeto, os papéis de quem deve executar

cada uma destas etapas, quando deverá ser executada, o que deve ser gerado

durante o processo de desenvolvimento e como deverá ser feito, de forma que o

projeto possa atingir os objetivos finais que é a concepção de um novo software ou a

evolução de um já existente (MARTINS, 2006; MACHADO, 2011).

A figura 5 mostra de forma esquemática como o RUP é aplicado no

processo de desenvolvimento de software. Há um conjunto de responsabilidades e

definições que norteiam a utilização do RUP.

Figura 5 – Framework e utilização do RUP

Fonte: MACHADO (2011, p. 62).

30

O RUP é composto basicamente de quatro fases nas quais ocorrem as

iterações com as disciplinas envolvidas no projeto, sendo elas: iniciação,

elaboração, construção e transição (KRUCHTEN, 2003).

Kruchten (2003, pág. 19) apresenta a arquitetura geral do RUP da

seguinte maneira:

O eixo horizontal representa o tempo e mostra os aspectos do ciclo

de vida do processo à medida que se desenvolve.

O eixo vertical representa, por natureza, disciplinas que agrupam

logicamente as atividades.

A figura 6 demonstra as iterações das disciplinas nas fases do RUP.

Observa-se que cada fase é executada em uma ou mais iterações.

Figura 6 – O ciclo de vida de desenvolvimento de um software

Fonte: BOOCH et al. (2000, p. 444).

A figura 6 apresenta as iterações, que representam marcos durante o

desenvolvimento utilizando RUP. Cada iteração tem como resultado um incremento,

ou uma entrega de executável (release) (HIRAMA, 2011).

31

A perspectiva prática do RUP descreve boas práticas de engenharia de software recomendadas para uso em desenvolvimento de sistemas. São recomendadas seis melhores práticas fundamentais: 1. Desenvolver o software iterativamente. Planejar os incrementos de software com base nas prioridades do cliente e desenvolver e entregar antes as características de sistema de maior prioridade no processo de desenvolvimento. 2. Gerenciar requisitos. Documentar explicitamente os requisitos do cliente e manter acompanhamento das mudanças desses requisitos. Analisar o impacto das mudanças sobre o sistema antes de aceitá-las. 3. Usar arquiteturas baseadas em componentes. Estruturar a arquitetura de sistemas com componentes [...]. 4. Modelar o software visualmente. Usar modelos gráficos de UML para apresentar as visões estática e dinâmica do software. 5. Verificar a qualidade do software. Garantir que o software atenda aos padrões de qualidade da organização. 6. Controlar as mudanças do software. Gerenciar as mudanças do software, usando um sistema de gerenciamento de mudanças e procedimentos e ferramentas de gerenciamento de mudanças e procedimentos e ferramentas de gerenciamento de configuração [...] (SUMMERVILLE, 2007, p. 56)

Um grande diferencial dos processos até então existentes que o RUP

incorporou em sua ideologia, foi adotar outros fluxos de trabalho, como por exemplo,

modelagem de negócios, implantação e gerenciamento de projetos.

2.1.3 MODELOS ÁGEIS

Com o crescimento constante da tecnologia, novidades nesse meio estão

sempre surgindo, e isso faz com que tudo fique mais rápido no nosso dia-a-dia e

principalmente nos negócios. Segundo Sommerville (2007), o software é parte de

quase todas as operações de negócio, e por isso seria adequado que um novo

software seja desenvolvido rapidamente. Por isso a maioria das empresas de

software quer acompanhar esse ritmo acelerado e oferecerem uma entrega rápida e

com qualidade no desenvolvimento.

Sommerville (2007, p. 260), ainda destaca características fundamentais

de desenvolvimento rápido:

1. Os processos de especificação, projeto e implantação são concorrentes. Não há especificação detalhada de sistema e documentação de projeto é

32

minimizada ou gerada automaticamente por um ambiente de programação usado para implementar o sistema. O documento de requisitos do usuário define somente as características mais importantes do sistema. 2. O sistema é desenvolvido em uma série de incrementos. Os usuários finais e outros stakeholders com o sistema participam da especificação e da avaliação de cada incremento. Eles podem propor alterações e novos requisitos que devem ser implementados em um incremento posterior do sistema. 3. As interfaces com o usuário do sistema são geralmente desenvolvidas usando-se um sistema de desenvolvimento interativo que permite que o projeto de interface seja criado rapidamente por desenho e inserção de ícones na interface. O sistema poderá, então gerar uma interface baseada na Web para um navegador ou uma interface para uma plataforma especifica, como a Microsoft Windows.

Uma metodologia muito conhecida utilizada pelas empresas de

desenvolvimento rápido de software são os métodos ágeis. Machado (2011) acredita

que essa metodologia é a realidade dos negócios do século 21, pelos mesmos

motivos citados por Sommerville (2007). Nos métodos ágeis, o escopo dos projetos

são mais flexíveis e não são utilizados uma documentação completa e restrita de

requisitos na etapa inicial do projeto.

Em fevereiro de 2001, surgiu o Manifesto Ágil por um grupo de

desenvolvedores de software. O Manifesto Ágil é uma declaração com os princípios

que regem o desenvolvimento ágil (GOMES, 2013).

Métodos ágeis assumem imprevisibilidade natural do desenvolvimento de software, por isso, considera-se que o cliente também esta aprendendo sobre o que precisa e, que a cada feedback pode mudar de ideia e alterar o escopo do projeto. Assume-se também que estimativas de esforço e tempo de desenvolvimento são, de fato, estimativas, e não devem ser tratadas como algo certo e sem margem de erro (GOMES, 2013, pág. 6).

O quadro 2 mostra os princípios dos métodos ágeis, conforme comentado

por Sommerville (2007).

Quadro 2 – Princípios dos métodos ágeis

Princípio Descrição

Envolvimento do cliente Clientes devem ser profundamente envolvidos no processo de desenvolvimento. Seu papel é fornecedor e priorizar novos requisitos do sistema e avaliar as iterações do sistema.

Entrega incremental O software é desenvolvido em incrementos e o cliente especifica os requisitos a serem incluídos em cada incremento.

Pessoas, não processo

As habilidades da equipe de desenvolvimento devem ser reconhecidas e exploradas. Os membros da equipe devem desenvolver suas próprias maneiras de trabalhar sem processos prescritivos.

33

Aceite as mudanças Tenha em mente que os requisitos do sistema vão mudar, por isso projete o sistema para acomodar essas mudanças.

Mantenha a simplicidade

Concentre-se na simplicidade do software que está sendo desenvolvido e do processo de desenvolvimento. Sempre que possível, trabalhe ativamente para eliminar a complexidade do sistema.

Fonte: SOMMERVILLE (2007, p. 263).

Para Foggetti (2014), a simplificação deste método é útil para as

empresas, pois além de ter uma documentação mais simples, economiza tempo e

custos. Porém Foggetti acredita que este método também tem desvantagens já que

nem sempre o cliente estará disponível para acompanhar o desenvolvimento do

sistema, é necessário maior envolvimento dos colaboradores no projeto, podem

ocorrer conflitos de prioridades quando se trata de mais de um cliente e também

existe a questão da pressa que, quando os prazos vão acabando, pode

comprometer soluções simples.

O Scrum é um framework que aplica os conceitos dos métodos ágeis que

é utilizado neste trabalho como foco principal para o desenvolvimento de software,

porém antes de abordar esta ferramenta, serão apresentados os conceitos do

Extreme Programming (XP), apenas a título de conhecimento sobre este modelo.

Essas duas abordagens são muito conhecidas nos métodos ágeis.

2.1.3.1 EXTREME PROGRAMMING (XP)

Segundo Mariotti (2012, p.7), “o Extreme Programming ou XP [...] possui

muitas diferenças em relação a outros modelos, podendo ser aplicado a projetos de

alto risco e com requisitos dinâmicos [...] conduzidos por equipes de tamanho médio

e pequeno”.

Muitas pessoas tem uma ideia equivocada desta metodologia por conta

de seu nome “Programação Extreme”. Uma pessoa sem subsídios suficientes sobre

esta abordagem pode concluir que não é necessário fazer planejamento e nem ter

preocupações com o projeto (design) de software, porém isto é uma ideia bastante

inadequada, já que na verdade o XP refere-se à utilização dos princípios e práticas

34

de XP em níveis extremos e não à atividade específica de programação

(MACHADO, 2011).

Como todo método ágil, o XP procura responder com velocidade às mudanças nas especificações do projeto, com base em princípios, valores e práticas bem definidos. Este método enfatiza o desenvolvimento rápido garantindo a satisfação do cliente e cumprindo as estimativas do projeto (MARIOTTI, 2012, p.7).

O XP não define papéis, artefatos, pontos de sincronização, entradas e

saídas. Somente quatro atividades são definidas: codificar, testar, ouvir e projetar.

Para Gomes (2013, p. 15):

É preciso ouvir porque desenvolvedores nem sempre possuem o conhecimento de negócio necessário para se construir o software. O Planning Game é uma reunião que acontece uma vez a cada iteração, em que o principal objetivo é decidir quais funcionalidades serão desenvolvidas na iteração e aprender mais sobre elas. O cliente escreve histórias de usuário em cartões que representam a necessidade de funcionalidade a ser desenvolvida, e explica para os desenvolvedores tudo o que for preciso para que eles possam implementá-la. Um bom design é uma excelente ferramenta para que todos possam compreender melhor os sistemas complexos, suas estruturas, dependências e regras de negócio. O principal objetivo é manter o design sempre simples, evitando aumentar a complexidade com a criação de funcionalidades que não sejam realmente necessárias.(...) Codificar é uma atividade essencial para o desenvolvimento de software, afinal de contas, sem código não existe software algum. Nessa etapa, é extremante importante que o cliente continue acessível para que possa oferecer feedback e responder às diversas dúvidas que surgem durante o desenvolvimento. Com XP, os testes de unidade são escritos antes do código de produção todo o código fonte que será executado em produção é desenvolvido em pares; a integração do código fonte é realizada frequentemente através da prática de integração contínua; e o código fonte é coletivo, ou seja, pertence a todos os membros da equipe, e deve ser escrito de acordo com os padrões definidos pelo próprio time.

A seguir na figura 7 é apresentado o processo XP, onde é possível

verificar as etapas até a entrega de pequenas versões, os releases.

35

Figura 7 – Processo XP

Fonte: HIRAMA (2011, p. 46).

De forma detalhada da apresentação do XP através da figura 7, observa-

se que os requisitos partem das estórias do usuário. Com base nas estórias, é

realizado o planejamento de versão e a divisão de tarefas. Na iteração, há a etapa

de testes por parte do cliente que apenas é liberado após esta aprovação. Caso

houver novas estórias, novos planejamentos poderão ser realizados em um novo

ciclo do XP.

2.1.3.2 SCRUM

O Scrum será amplamente utilizado neste trabalho, por isso este

framework é abordado de forma mais detalhada.

Conforme Machado (2011, p. 206):

Scrum é um processo empírico para o desenvolvimento de software de alto valor agregado através de ciclos sucessivos de incrementos ao produto. O trabalho é realizado com prazo fixo, de forma colaborativa e autônoma e baseado em uma lista dinâmica de requisitos.

O Scrum é um framework que é usado de forma iterativa e incremental,

ou seja, existem períodos definidos que se repetem até que o produto final fique

pronto, e no fim de cada período, existe um bloco funcional do produto final

entregue. Este framework tem como estratégia iterações curtas para avaliar os

requisitos periodicamente (MACHADO, 2011).

36

Em projetos que utilizam métodos tradicionais, apenas uma ou poucas entregas são realizadas ao final do projeto ou ao final de uma grande etapa. Com Scrum, partes prontas do produto são geradas em ciclos curtos de desenvolvimento, que ocorrem um atrás do outro. As partes entregues são as mais necessárias para seus clientes e usuários no momento da entrega e, por essa razão, serão utilizadas imediatamente. Uma vez que são utilizadas, representam retorno ao investimento realizado (SABBAGH, 2013, p. 5).

No Scrum, caso seja necessário fazer algumas mudanças, as prioridades

poderão ser mudadas. É bastante previsível que um desenvolvimento de software

poderá mudar durante um processo, por isso é necessário que se tenha uma

flexibilidade para acompanhar essas mudanças e o Scrum se adapta à realidade das

mudanças (PRIKLADNICKI et al., 2014).

Na figura 8 a seguir, é possível ver detalhadamente como funciona o todo

o processo do Scrum, os artefatos e reuniões que fazem parte deste framework e

que serão abordadas adiante.

Figura 8 – Planejamento da Sprint


Segundo Audy (2015), o Scrum é baseado em três pilares, o primeiro é a

“Transparência” que requer que os envolvidos no projeto se posicionem, com

sentimento de pertencimento. Outro pilar é a “Inspeção” em que todos devem dar o

seu melhor e buscar o melhor do time a cada relato. O último pilar é a “Adaptação”

para quando for indicada a necessidade de um plano de ação, todos se empenhem

pelo sucesso.

37

2.1.3.2.1 PAPÉIS DO SCRUM

Cada pessoa da equipe de Scrum é igualmente responsável pelos

resultados do trabalho. Existem três papéis diferentes, porém todos trabalham de

forma colaborativa (SABBAGH, 2013).

Machado (2011) define os seguintes papéis existentes no Scrum:

Scrum Master: Deve ter iniciativas para melhorar o projeto, garantir que

o processo seja entendido por todos da equipe, verificar se a equipe

está engajada com o projeto, ou seja, seu papel é manipular a equipe

para que estes consigam se auto gerenciar e os objetivos sejam

alcançados;

Product Owner (PO): É o responsável pelo produto, ou seja, é ele quem

deve ficar ao lado do cliente e ter uma participação constante no

projeto e não somente ser um “patrocinador” que cuida da verba do

desenvolvimento;

Time de desenvolvimento: São os analistas, desenvolvedores e

testadores que entregaram alguma parte do software pronto a cada

Sprint.

O quadro 3 a seguir, mostra como é feita a divisão de tarefas nos

diferentes seus papéis:

38

Quadro 3 – Divisão de tarefas nos papéis do Scrum.

Fonte: SABBAGH (2013, p. 108).

Resumidamente o papel do Product Owner é o analista de negócio, ou

melhor, o representante do cliente. O Scrum Master oferece suporte na execução

das etapas do Scrum e o Time de Desenvolvimento executa a construção do

incremento de software (AUDY, 2015).

2.1.3.2.2 PRODUCT BACKLOG

Segundo Foggetti (2014), o Product Backlog é um documento definido pelo

cliente em que são descritas as funcionalidades esperadas e a ordem das

prioridades. A figura 9 mostra alguns exemplos de como pode ser feito o Product

Backlog.

39

Figura 9 – Três exemplos de formatos de Product Backlog


O Product Backlog pode ter como base a técnica de levantamento de histórias

de usuário, previstas no Scrum, de forma a gerar uma lista funcionalidades a serem

desenvolvidas de acordo com a prioridade, valor, complexidade e expectativa dos

principais envolvidos (AUDY, 2015).

2.1.3.2.2.1 HISTÓRIAS DE USUÁRIO (USER STORIES)

Segundo Sabbagh (2013), é importante utilizar formas simples para

descrever a necessidade do usuário do ponto de vista dele mesmo, para tanto,

existem as histórias de usuário. Para Matos et al. (2014, p. 7), “histórias de usuário é

um dos modelos de especificação de requisitos indicados para MA’s e descreve uma

funcionalidade que é valiosa para o cliente do sistema.”

Sabbagh (2013, p. 135) menciona que “é importante destacar que as

histórias de usuário não fazem parte do framework Scrum e, assim seu uso é

opcional”. A seguir, a figura 10 apresenta um exemplo de história de usuário.

Observe que é escrita considerando o ponto de vista do usuário.

40

Figura 10 – Exemplo de História de Usuário


As histórias devem ser simples e claras para que possam ser bem

entendidas e estimadas pelo time no planejamento, por isso, é interessante detalhar

cada interação do usuário fracionando em situação objetivas para determinado fim

(AUDY, 2015).

2.1.3.2.2.2 CRITÉRIOS DE ACEITAÇÃO

Segundo Sabbagh (2013, p. 141), “critérios de aceitação são expressos

por enunciados pequenos e de fácil entendimento. São utilizados para determinar

quando a funcionalidade produzida pelo Time de Desenvolvimento está completa e,

assim, nada mais deve ser adicionado a ela”. O quadro 4 apresenta um exemplo de

critério de aceitação.

Quadro 4 – Exemplo de Critérios de Aceitação

Critério 1

Somente podemos aceitar cartões de crédito com bandeiras com que temos convênio.

Critério 2

Somente podemos aceitar cartões de crédito com data de expiração no futuro.


Para Audy (2015), os critérios de aceitação é uma parte importante das

histórias de usuário que deverão ser validadas para que o PO aceite a entrega como

pronta ao final de cada Sprint, além de ser uma forma simples para transmitir ao

time de desenvolvimento o que precisa ser feito a fim de agregar valor ao produto.

41

2.1.3.2.3 SPRINT BACKLOG

Segundo Foggetti (2014), o Sprint Backlog é um planejamento que

representa a estratégia dos itens dispostos no backlog para que seja dividido o

Product Backlog em pedaços menores para sua implementação. A figura 11 mostra

um exemplo de representação de um Sprint Backlog.

Figura 11 – Sprint Backlog


Para Audy (2015) o Product Backlog contém todos os requisitos (histórias

já levantadas para incrementar o produto). Este Product Backlog será refinado no

planejamento da sprint de forma a selecionar as histórias que serão desenvolvidas

na próxima sprint.

2.1.3.2.4 SPRINT

As sprints são ciclos que ocorrem no Scrum e apresentam um conjunto de

atividades que devem ser executados (MACHADO, 2011).

42

Segundo Sabbagh (2013), a duração de cada sprint é decidida pela a

equipe, normalmente é de duas a quatro semanas, no fim deste período espera-se

ter um incremento do produto finalizado. Cada incremento é realizado de acordo

com o Sprint Backlog, que apresenta os itens que a equipe decidiu á serem

realizados. A figura 12 mostra o ciclo da sprint.

Figura 12 – Ciclo de vida do Scrum


Inicialmente é realizada a reunião de planejamento em que são definidos

os itens que farão parte do Sprint Backlog e como serão desenvolvidos. Após isso, o

desenvolvimento do produto começa a ser realizado e, em paralelo, também é feito

a Scrum Diária. A Scrum Diária é uma reunião de apenas 15 minutos em que o Time

de Desenvolvimento se reúne todos os dias e discutem o que foi realizado e o que

será feito a seguir. Com o desenvolvimento finalizado, é feito a Revisão da Sprint

para que o produto seja apresentado para a equipe e para o cliente, se todos

estiverem satisfeitos com o produto então a próxima etapa é a reunião de

Retrospectiva da Sprint que são discutidos os aprendizados obtidos pela a equipe

com a sprint corrente e novas melhorias que podem ser feitas nas próximas sprints.

A figura 13 é representação esquemática de uma sprint, evidenciando as

quatro cerimônias supracitadas.

43

Figura 13 – Representação esquemática de uma Sprint

Fonte: PRIKLADNICKI et al. (2014, p. 31).

Segundo Gomes (2013), “ao longo da sprint a equipe mantém sempre em

mente a sua meta e quando o andamento das coisas foge do que foi previsto, é

possível negociar o escopo com o PO, de forma que não comprometa a meta”.

2.1.3.2.5 REUNIÃO DE PLANEJAMENTO DA SPRINT (SPRINT PLANNING)

Nesta reunião será conhecida e planejada a meta da sprint. Para isso, a

reunião é dividida em duas partes. Na primeira parte é definido o que será entregue

no incremento resultante nesta sprint e na segunda parte o que será feito para

entregar este incremento, essas duas partes originam o Sprint Backlog

(PRIKLADNICKI et al., 2014).

Na reunião de Planejamento da sprint é preciso estabelecer métricas para

que se possa planejar o tempo de entrega de uma determinada funcionalidade.

Sabbagh (2013, p. 121) elenca os as seguintes unidades para estimativas no Scrum:

tempo real: dias ou horas reais de trabalho, ou seja, uma estimativa de quanto tempo em dias ou horas a realização da atividade irá durar. É a unidade mais tradicional de estimativa;

tempo ideal: dias ou horas ideias de trabalho, ou seja, quanto tempo se levaria para realizar uma atividade caso todo o foco de trabalho

44

estivesse nessa atividade e não existissem quaisquer interrupções, como conversas, leitura de e-mails, idas ao banheiro, reuniões, cafezinho etc. A estimativa com tempo ideal também pode ser expressa em homens-dias ou homens-horas, ou seja, quantas pessoas são necessárias para completar o item de trabalho em um dia ou uma hora, sem interrupções;

Story Points: unidade relativa de tempo criada pelo Time de Desenvolvimento. É a unidade mais utilizada por equipes Ágeis.

Para que a reunião de planejamento da sprint seja eficaz, um item

importante é que o Product Backlog esteja com detalhes suficientes para que possa

ser discutido. Para tanto, é necessário estabelecer um acordo definido como

“definição de preparado”. Esta definição deve ser através de um acordo formal entre

o PO e o time de desenvolvimento. A figura 14 apresenta um exemplo de definição

de preparado (SABBAGH, 2013).

Figura 14 – Exemplo simples de definição de preparado


Para Sabbagh (2013), a definição de “preparado” é muito importante para

diminuir riscos de uma sprint mal planejada, quando demais detalhes podem ser

deixados para serem discutidos na Sprint Planning.

45

2.1.3.2.6 SCRUM DIÁRIAS (DAILY SCRUM)

Elevam o nível de auto-organização do time de desenvolvimento que se

reúnem rapidamente diariamente para todos se atualizarem do que está sendo

desenvolvido e talvez serem definidos alguns novos pontos. Esta reunião tem

duração de apenas 15 minutos (PRIKLADNICKI et al., 2014).

Segundo Sabbagh (2013) em cada reunião é realizado os seguintes

questionamentos para cada membro do time:

O que foi feito desde a última reunião diária?

O que será feito depois da reunião diária?

Quais problemas estiveram ou estão tendo que impedem o trabalho de ser

executado?

2.1.3.2.6.1 GRÁFICO BURNDOWN

O gráfico Burndown é utilizado para acompanhar o progresso da sprint e

também utilizado como um indicador para predizer quando o trabalho será

concluído. É possível usar a linha de tendência para verificar se está propenso a

terminar as tarefas na meta pretendida pela a equipe (RUBIN, 2013).

Conforme a figura 15, o eixo vertical representa a estimativa de esforço-

horas restante e o eixo horizontal são os dias de uma sprint. Cada dia o gráfico é

atualizado para mostrar o total estimado, esforço restante nas tarefas incompletas

(RUBIN, 2013).

46

Figura 15 – Gráfico de Burndown

Fonte: RUBIN (2013, p. 358).

O gráfico de burndown é um artefato indispensável no Scrum para o

entendimento do quadro de tarefas e é um indicador de tendência “previsão e

trabalho” para atingir os objetivos pretendidos (AUDY, 2015).

2.1.3.2.7 REVISÃO DA SPRINT (SPRINT REVIEW)

Na revisão da sprint é apresentado os itens finalizados na sprint para o

cliente e toda a equipe, com o objetivo de receber um feedback. Nesta reunião é

discutido e inspecionado se o incremento do produto é satisfatório ou se será

necessário modificá-lo ou adaptá-lo, neste caso retornará ao Produtct Backlog para

ser realizada em sprints futuras. É primordial nesta fase esclarecer ao cliente qual é

a meta da sprint para melhor entendimento do incremento final. Também é muito

importante que toda a equipe participe para que haja compreensão de tudo o que foi

realizado na sprint, evitando futuros problemas nas próximas sprints, e também para

ter novas sugestões de futuros Product Backlog que podem melhorar o produto

(PRIKLADNICKI et al., 2014. SABBAGH, 2013).

Na apresentação do produto é demonstrado cada item realizado na sprint

e possibilita o cliente experimentar o produto para que haja um bom esclarecimento

47

do que foi realizado estimulando ainda mais perguntas e feedbacks de melhorias

futuras (SABBAGH, 2013).

Seguindo uma premissa importante de qualquer timebox, a condução deve ter em vista a natureza de sua pauta, deve ficar na apresentação do previsto e do realizado. Não é hora para fazer testes e homologação, nem para revisar ou discutir estratégia ou filosofar sobre o Product backlog (AUDY, 2015, p. 84).

Sabbagh (2013) também cita que outro acordo importante no Scrum é a

“definição de pronto”. Este por sua vez é um acordo realizado também entre o PO e

o time de desenvolvimento para indicar que um item da sprint está pronto, ou seja,

que determinada funcionalidade possa ser entregue ao cliente. A figura 16 a

presenta um exemplo que pode seguido para uma definição de pronto.

Figura 16 – Exemplo simples de um acordo de definição de pronto


A definição de pronto oferece um alto nível de confiança que o incremento

desenvolvido tem qualidade e pode ser realmente entregue ao cliente (RUBIN,

2013).

48

2.1.3.2.8 RETROSPECTIVA DA SPRINT (SPRINT RETROSPECTIVE)

A retrospectiva da sprint ocorre logo após a revisão da sprint e tem como

foco o aprimoramento do processo e prover melhorias nas próximas sprints,

relembrando os processos de trabalho que foram utilizados na sprint anterior, os

problemas que foram enfrentados, e verifica se a equipe conseguiu finalizar suas

tarefas na meta pretendida e assim traçar um plano de ação para realizar estas

melhorias de forma efetiva (PRIKLADNICKI et al., 2014. SABBAGH, 2013).

A reunião de retrospectiva da sprint é uma grande oportunidade para

parar e pensar com a equipe, examinar o que está acontecendo, analisar como

funcionam e assim identificar melhorias. Porém, infelizmente esta reunião é a menos

apreciada pelas equipes e muitas vezes é deixada de lado, isso porque as pessoas

pensam que precisa de muito tempo para colocar todos os planos em prática,

esquecendo-se que esta reunião contribui muito para uma melhoria continua do

Scrum (RUBIN, 2013).

2.2 DESENVOLVIMENTO DE SOFTWARE UTILIZANDO A UNIFIED MODELING

LANGUAGE (UML)

São muitos os desenvolvedores que acreditam que documentação pode

prejudicar o andamento do projeto. O motivo para isso é porque os modelos da

UML, podem se tornar obsoletos a cada sprint, pois a cada interação, novas tarefas

são priorizadas e alterações são propostas. Porém existe outra corrente que é muito

pertinente utilizar artefatos UML junto com o Scrum, pois alguns diagramas da UML

são muito difundidos na comunidade da TI e torna-se uma ferramenta de

comunicação entre os desenvolvedores (SILVA, 2012).

Segundo Silva (2012, p. 16), “seguindo esse pensamento, a metodologia

Scrum não impõe restrições para utilização de UML em seu ciclo de vida, mesmo

porque se trata de um framework para suporte à gerência de projetos”.

49

Pressman (2011, p. 727) define a UML como “uma linguagem padrão

para descrever/documentar projeto de software. A UML pode ser usada para

visualizar, especificar, construir e documentar os artefatos de um sistema de

software-intensivo [...]”.

A UML é uma linguagem e, como tal, provê um vocabulário e um conjunto de regras para combinar os elementos da linguagem, focando nos elementos conceituais e físicos que representam um sistema. Esta linguagem define uma gramática padrão que auxilia as pessoas a criar e ler documentos UML (MARTINS, 2006, p. 140).

A modelagem de sistemas é importante para que as informações do

sistema não fiquem apenas na mente dos programadores e venha a gerar

problemas de comunicação do modelo conceitual do sistema com os demais

envolvidos do projeto. Determinadas informações sobre o sistema são difíceis de

serem expressas através de linguagem de programação, e há também o risco do

conhecimento do projeto se perder com a saída do funcionário da empresa

(MARTINS, 2006).

Booch et al. (2000), abordam que para visualizar, especificar, construir e

documentar sistemas complexos é necessário atender os diversos pontos de vista. É

necessário dar visibilidade sobre o sistema para os usuários finais, analistas,

implementadores, testers e demais envolvidos no projeto. Desta forma, acreditam

que a arquitetura seja o artefato mais importante a ser utilizado para gerenciar os

diferentes pontos de vista. Martins (2006) complementa que os diferentes pontos de

vista visam dar visibilidade ao que é importante para cada uma das respectivas

visões, omitindo entidades que são irrelevantes para determinado ponto de vista,

conforme pode ser observado na figura 17.

50

Figura 17 – O ciclo de vida de desenvolvimento de um software


De acordo com a arquitetura apresentada por Booch et al. (2000) na

figura 17, observa-se cada visão apresentando o que é relevante para cada uma

delas e a visão de caso de uso que apresenta o comportamento do sistema

conforme é visto pelos usuários finais, analistas, e pessoal de teste.

A UML utiliza diagramas para apresentar de forma gráfica o conjunto de

elementos relacionados entre si e possibilita a construção das diferentes visões

(MARTINS, 2006).

Dentre os 13 diagramas existentes na UML (PRESSMAN, 2011), este

trabalho aborda a apresentação de três deles para apoiar o Scrum, sendo: diagrama

de caso de uso, diagrama de classes e diagrama de sequência.

O diagrama de classes abrange o projeto desde a fase de análise até a

arquitetura do sistema, uma vez que pode ser utilizado para construir o modelo de

banco de dados, além de possuir interface visual de fácil compreensão por analistas

e desenvolvedores. O diagrama de sequências facilita o entendimento da

funcionalidade de alguns métodos de classes e é muito útil para as funcionalidades

de negócio mais complexas, já que possibilita visualizar a iteração entre os objetos

com base em uma linha de tempo (SILVA, 2012).

O diagrama de caso de uso é importante neste trabalho para dar uma

visão das funcionalidades e atores do sistema, junto com o Scrum ele poderá servir

de insumo para geração de Stories para a formação do Product Backlog.

Para dar início à construção dos diagramas que compõem a

documentação de um software, Hirama (2011) comenta que é necessário “entender

51

as necessidades de negócio do cliente e estabelecer requisitos [...]”. Esta atividade

busca detalhar os requisitos do software. A seguir, é apresentado o que é requisito

de software e o que é composto neste cenário.

2.2.1 REQUISITOS

Uma das primeiras fases do desenvolvimento de software é o

levantamento de requisitos, pois com base nos requisitos será possível verificar o

que o software deve fazer e se realmente é possível desenvolver este software.

Nesta etapa é realizada a compreensão do que o cliente deseja de funcionalidades

no software para atender as necessidades dele (GUEDES, 2011).

Segundo Machado (2011, p. 32), “os requisitos são o ponto de partida

para toda a definição do sistema e, consequentemente, são fatores decisivos no

desenvolvimento do produto final [...]”.

Na fase de levantamento de requisitos devem ser identificados os

requisitos funcionais, os não funcionais e avaliar as regras de negócio do cliente. Os

requisitos funcionais correspondem às funcionalidades do software, já os não

funcionais às restrições, condições, consistências e validações (GUEDES, 2011).

2.2.1.1.1 REQUISITOS FUNCIONAIS

Requisitos funcionais descrevem a função do sistema, suas entradas e

saídas, exceções, etc. Dependem do software que está sendo desenvolvido e dos

conhecimentos passados pelo usuário. É a partir desses requisitos que o sistema

será construído (KERR, 2015; SOMMERVILLE, 2007; MACHADO, 2011).

Sommervile (2007, p.81) cita um exemplo de requisito funcional de um

sistema de biblioteca:

52

1. O usuário deve ser capaz de fazer uma busca em todo o conjunto inicial do banco de dados ou selecionar um subconjunto com base nele. 2. O sistema deve fornecer telas apropriadas para o usuário ler os documentos no repositório de documentos. 3. Para cada pedido, deve ser alocado um único identificador (ORDER_ID), o qual o usuário deve ser capaz de copiar a área de armazenamento permanente da conta.

Segundo Machado (2011, p.34), “a especificação de um requisito

funcional deve determinar o que se espera que o software faça, sem a preocupação

de como ele faz”.

2.2.1.1.2 REQUISITOS NÃO FUNCIONAIS

Segundo Machado (2011, p. 35) os requisitos não funcionais “são muito

importantes, pois definem se o sistema será eficiente para a tarefa que se propõe a

fazer. Um sistema ineficiente certamente não será usado”.

Os requisitos não funcionais, não estão diretamente relacionados às

funções do sistema e sim a funções mais amplas. Especificam a parte técnica, como

confiabilidade, tempo de resposta e espaço de armazenamento (KERR, 2015;

SOMMERVILLE, 2007).

Machado(2011, p.35) cita exemplos de requisitos não funcionais:

1. A base de dados deve ser protegida para acesso apenas de usuários a autorizados. 2 .O tempo de resposta do sistema não deve ultrapassar 30 segundos. 3.O software deve ser operacionalizado no sistema Linux. 4.O tempo de desenvolvimento não deve ultrapassar seis meses.

É muito indicado de que se descreva o requisito quantitativamente, pois isso

diminuirá as chances de erro, já que os desenvolvedores não precisam interpretar o

que foi dito (KERR, 2015).

53

2.2.1.1.3 REGRAS DE NEGÓCIO

De acordo com Neto (2016), as regras de negócio definem diretrizes do

negócio de uma organização. Elas orientam como uma determinada situação deve

seguir. Um exemplo de regra de negócio em um cenário bancário, é que apenas

clientes maiores de 18 anos podem abrir contas.

As regras empresariais complementam os processos empresariais e as máquinas automáticas. Por exemplo, se existir uma condição com uma variável, poderá utilizar uma regra de negócio para alterar o valor nessa variável no tempo de execução. Por exemplo, se existir uma condição com uma variável, uma regra empresarial poderá alterar o valor nessa variável no tempo de execução. Criada por uma linguagem de programação visual, uma regra de negócio toma uma decisão com base no contexto. A decisão pode ser simples ou complexa. As regras empresariais são não procedimentais e podem ser alteradas independentemente de uma aplicação. As regras empresariais determinam o resultado de um processo com base num contexto (IBM, 2016)

Neto (2016) comenta que regras de negócio são diferentes de requisitos,

apesar de muitas pessoas confundirem interpretando que ambos tratam-se da

mesma coisa. As regras direcionam o negócio e não necessariamente precisam ter

relação com os requisitos.

2.2.2 DIAGRAMA DE CLASSES

O diagrama de classes fornece uma visão estrutural do sistema, mas não

evidencia a natureza dinâmica das interações entre os objetos das classes no

diagrama (PRESSMAN, 2011). É composto pelas classes de negócio, classes de

interface com o usuário e com outros sistemas e as classes de controle (MARTINS,

2006).

Este diagrama é um dos mais utilizados, pois é uma descrição formal da

estruturada de objetos em um sistema. Descreve a identidade, os relacionamentos

com outros objetos e os atributos e suas operações (NUNES; O’NEILL, 2002).

54

Os elementos principais são caixas, ou seja, ícones usados para representar classes e interfaces. Cada caixa é dividida em partes horizontais. A parte superior contém o nome da classe. A seção do meio lista os atributos da classe. Um atributo refere-se a alguma coisa que um objeto daquela classe sabe ou pode fornecedor o tempo todo. Atributos são usualmente implementados como campos da classe, mas eles não precisam ser. Poderiam ser valores que a classe calcula a partir de suas variáveis de instância ou valores que a classe pode obter de outros objetos dos quais é composta [...]. A terceira seção do diagrama de classes contém as operações ou comportamentos da classe. Uma operação refere-se ao que os objetos da classe podem fazer. Usualmente é implementada como um método da classe (PRESSMAN, 2011, p. 728).

O termo “classe” representa uma abstração sobre um conjunto de objetos

que partilham a mesma estrutura e comportamento. Classes costumam ter atributos

e operações. Atributos são características que os objetos possuem e operações

representam o comportamento de um objeto (NUNES; O’NEILL, 2002). A seguir, a

figura 18 apresenta a representação de uma classe.

Figura 18 – Representação da classe

Fonte: NUNES; O’NEILL (2002, p. 39).

Segundo (BOND et al., 2003; NUNES; O’NEILL, 2002), os atributos e

operações tem 4 níveis de visibilidade:

Público – Qualquer classe tem acesso ao elemento. Precede o nome com “+”.

Protegido - Qualquer descendente da classe pode utilizar o elemento. Precede o nome com “#”.

Privado - Apenas a própria classe tem acesso ao elemento. Precede o

nome com “-“.

Package – elementos do mesmo pacote.

55

O diagrama de classe possui associações em que se têm as relações

entre as classes unidas por uma linha. As associações podem ter multiplicidade, em

que indica quantos objetos podem participar de um relacionamento. (BOND et al.,

2003). O quadro 5 apresenta alguns valores de multiplicidade.

Quadro 5 – Exemplos de multiplicidade

Fonte: GUEDES (2011, p. 53)

A generalização também mostra um relacionamento entre duas classes,

porém a diferença é que uma classe é filha da outra (BOND et al., 2003). Observe

na figura 19, que as classes B e C herdam métodos e campos da classe A.

Figura 19 – Notação de generalização

Fonte: BOND et al., 2003 (2003, p. 887).

Outros artefatos muito importantes em um diagrama de classe são a

agregação e a composição. A agregação apresenta que um todo é composto por

partes, já a composição existe uma dependência direta entre as classes (NUNES;

56

O’NEILL, 2002). As figuras 20 e 21 a seguir, apresentam exemplos de agregação e

composição.

Figura 20 – Agregação

Fonte: GUEDES (2011, p. 111-113)

Fowler (2004) comenta que há uma confusão muito grande na utilização

de agregação e composição e que a UML inclui a agregação com quase nenhuma

semântica justamente pela dificuldade de compreensão.

Figura 21 – Composição

Fonte: GUEDES (2011, p. 111-113)

A figura 22 apresenta um exemplo de diagrama de classes com alguns de seus artefatos.

Figura 22 – Diagrama de Classes

57


2.2.3 DIAGRAMA DE CASOS DE USO

Os diagramas de caso de uso definem o que o sistema faz quando eles

são executados. As funcionalidades de um sistema são definidas por um conjunto de

casos de uso, sendo que cada um representa um fluxo específico de eventos. São

importantes para a organização e modelagem dos comportamentos do sistema

(KRUCHTEN, 2003; BOOCH et al., 2000).

A primeira tarefa é a identificação de atores. Os atores são entidades

externas que poderão utilizar o sistema. Um ator não tem necessariamente uma

representação humanizada, pode representar um hardware ou outro software

(NUNES; O’NEILL, 2002; GUEDES, 2011). A figura 23 apresenta alguns exemplos

de atores

58

Figura 23 – Exemplos de atores

Fonte: GUEDES (2011, p. 53)

Assim que definido os atores, a próxima tarefa é fazer a documentação de

Casos de Uso.

A documentação de um caso de uso costuma descrever, por meio de uma linguagem bastante simples, informações como a função em linhas gerais do caso de uso, quais atores interagem com ele, quais etapas devem ser executadas pelo ator e pelo sistema para que o caso de uso execute sua função, quais parâmetros devem ser fornecidos e quais restrições e validações o caso de uso deve ter (GUEDES, 2011, p. 55).

Não existe um formato específico para casos de uso, permitindo-se que

se documente o caso de uso de forma que considerar melhor (GUEDES, 2011). A

figura 24 apresenta um exemplo que pode ser feito para documentar um caso de

uso.

Figura 24 – Documentação do caso de uso de abertura de conta

59

Fonte: GUEDES (2011, p. 55).

Segundo Nunes, O’Neill (2002, p. 24), “Os use cases podem estar

relacionados entre si. As relações mais frequentes são «include», «extend» e

generalização relação «include» significa que um determinado use case utiliza ou

inclui a funcionalidade disponibilizada num outro use case”. A figura 25 mostra um

exemplo de include.

Figura 25 – Diagrama de caso de uso - include

60


A relação «extend» ocorre quando existe um comportamento opcional que deve ser incluído num use case. Este comportamento é definido num segundo use case e invocado pelo use case base através de um mecanismo de pontos de extensão (NUNES, O’Neill, 2002, p. 25).

A figura 26 mostra um exemplo de <<extend>>.

Figura 26 – Diagrama de caso de uso - extend


Para Nunes, O’Neill (2002, p. 27), “a relação de generalização é utilizada

quando existe um use case que é um caso particular de um outro use case“. A figura

27 mostra um exemplo de generalização.

Figura 27 – Diagrama de caso de uso - generalização

61


A figura 28 apresenta um exemplo de diagrama de caso, que demonstra a

relação dos atores na execução dos casos de uso e as funcionalidades estendidas,

possíveis a partir da funcionalidade desejada.

Figura 28 – Diagrama de caso de uso – atores x casos de uso


62

2.2.4 DIAGRAMA DE SEQUÊNCIA

Os diagramas de sequência são utilizados para representar a visão de

interação de um sistema, de forma que exibe o conjunto de objetos e as mensagens

enviadas e recebidas por esses objetos. Mostra como um cenário específico de caso

será implementado (MARTINS, 2006; BOOCH et al., 2000).

O diagrama de sequência tem os participantes representados por caixas retangulares. Partindo dessas caixas retangulares, há uma linha estendida tracejada e vertical. As trocas de mensagens entre participantes são ilustradas como setas dirigidas e são identificadas pela mensagem que está sendo comunicada. A sequência de mensagens é lida de cima para baixo. Assim, o tempo transcorre de cima para baixo. Quando a linha tracejada é substituída por um retângulo, isso significa que o objeto está ativo e utilizando recursos durante aquele período de tempo (LEE, TEPFENHART, 2001, p. 20).

O diagrama de sequência é utilizado neste trabalho devido a possibilitar a

validação e complementação do diagrama de classes, além também de se basear

em diagramas de casos de uso (GUEDES, 2011).

[...] Nós construímos o diagrama de classes, baseando-nos no Caso de Uso. Isso nos norteou a abstração do negócio modelado. O diagrama de sequência se o mesmo approach, pode mostrar erros não detectados no diagrama de classe. Ele melhora o diagrama de classes permitindo que acrescentemos ou retiremos métodos e/ou atributos desnecessários de um conjunto de classes. (MEDEIROS, 2004, p. 147).

As mensagens neste diagrama demonstram a ocorrência de eventos

(GUEDES, 2011).

Para Nunes, O’Neill (2002, p. 77-78), existem quatro tipos de mensagens:

Mensagem síncrona: o objeto emissor ficar suspenso esperando

uma resposta.

Mensagem assíncrona: permite a operação emissora prosseguir e

ilustra processos concorrentes.

Mensagem simples: utilizado quando não tem um tipo de mensagem

definido.

Mensagem de retorno: ilustra o retorno da mensagem envida.

63

A figura 29 apresenta a notação do diagrama de sequência para os

diferentes tipos de mensagens:

Figura 29 – Tipos de mensagens

Fonte: NUNES; O’NEILL (2002, p. 39).

No diagrama de sequência existe a linha de vida que mostra a duração

em que um objeto existe, esta linha é representada por uma linha pontilhada. Existe

também o foco de controle que é representado por uma linha mais grossa e ficam

dentro da linha de vida que indica o envio de mensagens (NUNES; O’NEILL, 2002;

GUEDES, 2011).

A seguir, a figura 30 apresenta um exemplo da utilização do diagrama de

sequência, pelo qual é possível observar como os objetos interagem entre si.

Figura 30 – Diagrama de sequência


64

2.3 SCRUM COM UML

O Scrum foca na interação entre as pessoas envolvidas no projeto,

inclusive o cliente, para diminuir a necessidade de documentação (SANTANA,

2014). Por outro lado, Booch et al. (2000) defende a documentação para o

desenvolvimento de software.

Silva (2012) comenta que adeptos às MA defendem que o tempo

investido em documentação pode comprometer o andamento dos projetos, isto

porque a cada iteração do Scrum, novas tarefas são priorizadas e são propostas

alterações no projeto, o que pode implicar em dificuldade em manter os modelos

UML atualizados.

Em métodos ágeis não há prescrição de documentação (e o manifesto ágil fala também sobre “software funcionando mais do que documentação”), mas isso não significa que é proibido documentar qualquer coisa. Muita gente confunde isso e diz que nunca se deve documentar em projetos “ágeis”, o que é um grande erro. Em projetos ágeis você pode documentar sem problemas dede que a documentação seja necessária de fato. A idéia é que não devemos perder tempo com nada que não seja requerido de verdade para o projeto (MACHADO, 2011, p. 219)

De forma a complementar um projeto conduzido pelo Scrum, a UML pode

oferecer recursos que facilitam a compreensão de funcionalidades que um

determinado software precisa ter, porém, atentando-se a documentar apenas o

essencial para não perder as características das MA, onde o foco é na interação

entre as pessoas.

Em experimentos, Silva (2012) sugere a utilização de diagramas de casos

de uso para gerar histórias de usuário para a formação do Product Backlog. Outro

diagrama sugerido por Silva é o de classes, pois serve de embasamento para

originar a modelagem do banco e dados.

65

3 MÉTODO

Esta seção apresenta o método científico e a caracterização do tipo de

pesquisa. Em seguida, as etapas metodológicas que demonstram a sequencia das

tarefas a serem realizadas para atingir os objetivos deste trabalho. Posteriormente

será apresentada a proposta e as delimitações. O cronograma de desenvolvimento

deste trabalho encontra-se nos apêndices deste trabalho.

3.1 CARACTERIZAÇÃO DO TIPO DE PESQUISA

Segundo Gil (2002), para realizar toda e qualquer classificação é

necessário que existam critérios. No caso de pesquisas, existem três grandes

grupos sob o ponto do objetivo das pesquisas, sendo elas:

Pesquisas Exploratórias: objetivam explorar de forma detalhada o

problema, de forma a deixá-lo explícito ou construir hipóteses. Estas

pesquisas aprimoram as ideias sobre o problema e o planejamento

possibilita considerar diferentes aspectos ao fato estudado.

Pesquisas Descritivas: tem como objetivo descrever as características e

estabelecer relações entre variáveis. Quanto à sua realização, possui

características padronizadas como a aplicação de questionário, coleta

de dados e observação sistemática.

Pesquisas Explicativas: o ponto focal está em identificar os fatores que

determinam ou contribuem para a ocorrência dos fenômenos. Como o

nome sugere, é um tipo de pesquisa que busca explicar o porquê das

coisas, portanto, existem um risco grande, visto a complexidade.

Quanto à classificação da pesquisa sob o ponto de vista da natureza,

Silva e Menezes (2005) aborda duas maneiras, sendo elas:

Pesquisa Básica: busca gerar conhecimentos novos para contribuir com

o avanço da ciência, de interesses universais.

66

Pesquisa Aplicada: busca gerar conhecimento para solucionar

problemas específicos, de interesses locais.

Em relação ao ponto de vista da forma de abordagem do problema, Silva

e Menezes (2005) classificam de duas formas:

Pesquisa Quantitativa: considera que tudo pode quantificável, de forma

que tudo pode ser convertido em números. Neste tipo de pesquisa,

utilizam-se técnicas estatísticas para realizar estas conversões dos

dados em números.

Pesquisa Qualitativa: trata-se de uma pesquisa descritiva, algo que não

pode ser convertido em números. O processo e seu significado são os

focos principais de abordagem.

Diante dos critérios de classificação expostos, este trabalho é classificado

do ponto de vista da natureza, como uma pesquisa aplicada, pois busca explorar a

mescla do Scrum com alguns diagramas da UML para a produção de artefatos a fim

de se desenvolver um software. Do ponto de vista de seus objetivos, trata-se de uma

pesquisa exploratória, pois busca estudar uma forma de documentar software

utilizando uma metodologia com apoio de uma linguagem para especificação técnica

de software. Por fim, do ponto de vista da abordagem do problema, é uma pesquisa

qualitativa, pois visa analisar e descrever a experiência a ser elaborada/estudada.

3.2 ETAPAS DE EXECUÇÃO DO PROJETO

Para o desenvolvimento deste trabalho, foi elaborado um fluxo de

atividades que permite acompanhar o andamento do projeto. Este trabalho está

dividido em etapas, sendo: fundamentação teórica, que apresenta as ideias dos

autores consagrados sobre os assuntos que trata o trabalho; planejamento e

levantamento de informações que servirão como base para a elaboração da

proposta do trabalho; elaboração das modelagens e documentação para o

desenvolvimento de um sistema; realizar experimento utilizando os artefatos

67

produzidos; coletar e analisar informações para documentar o experimento e

apresentar as conclusões.

A seguir, a figura 31 ilustra em uma visão macro da etapa metodológica a

ser adotada para a elaboração deste trabalho.

Figura 31 – Etapa metodológica

Fonte: Elaborado pelos autores, 2015.

O levantamento bibliográfico é imprescindível para que se possa

fundamentar a ideia inicial deste trabalho e suportar a proposta da utilização da UML

em um processo de desenvolvimento utilizando o Scrum.

Com o planejamento da metodologia de execução busca-se verificar qual

a forma que o trabalho será abordado.

A escolha dos diagramas da UML é embasada em experimentos

realizados por alguns autores como Silva (2012), onde a utilização de cada um dos

diagramas é justificada com a sua aplicabilidade. Em seguir, é iniciada a construção

da proposta utilizando diagramas da UML no processo de desenvolvimento Scrum, o

desenvolvimento do software para testar os artefatos produzidos na construção da

proposta, em seguida a apresentação dos resultados obtidos e, por fim, a

apresentação da conclusão de se utilizar diagramas UML com Scrum.

68

3.3 ARQUITETURA DA SOLUÇÃO

A proposta deste trabalho consiste em desenvolver um software utilizando

a metodologia ágil Scrum apoiada em diagramas da UML para apoiar a elaboração

de documentos, de forma a identificar vantagens e desvantagens de se utilizar esta

mescla. Procura-se observar se foi importante a utilização de diagramas da UML

para a documentação técnica. A figura 32 ilustra a arquitetura da proposta deste

trabalho.

Figura 32 – Arquitetura da solução


69

Para o desenvolvimento do software, será elaborada uma documentação

seguindo a metodologia Scrum apoiada a alguns diagramas da UML para auxiliar na

documentação técnica, conforme exposto nos objetivos deste trabalho.

Ao final do trabalho, será possível concluir se a utilização da mescla da

UML em projetos Scrum pode agregar resultados satisfatórios ao ponto de ser

produtivo e não perder o foco dos princípios ágeis.

3.4 DELIMITAÇÕES

Como o foco do trabalho é aplicar o Scrum para o desenvolvimento de

software e utilizar alguns diagramas da UML para apoiar o desenvolvimento, este

trabalho limita-se a apresentar apenas três diagramas da UML, sendo eles o

diagrama de caso de uso, o diagrama de classes e o diagrama de sequências.

Em relação ao desenvolvimento utilizando o Scrum, este trabalho

evidencia o planejamento macro de todas as sprints, bem como todas as etapas do

Scrum, porém demonstra o ciclo utilizando apenas o desenvolvimento da sprint que

contém as tarefas necessárias para a entrega da principal funcionalidade para o

negócio do case escolhido.

70

4 MODELAGEM

A partir deste tópico, é apresentado o desenvolvimento da proposta deste

trabalho, demonstrando então o cenário arquitetado e as atividades realizadas que

tornaram possíveis a realização do experimento de desenvolvimento de software

conduzido pela metodologia ágil Scrum juntamente com alguns diagramas da UML

como apoio para a elicitação de requisitos.

4.1 O CASE UTILIZADO PARA APLICAR A PROPOSTA

Com a proposta inicial de explorar a utilização de alguns diagramas da

UML para apoiar no processo de desenvolvimento de software utilizando o Scrum,

os autores encontraram um case para aplicar a presente proposta. O case utilizado

para a aplicação da proposta deste trabalho foi uma cantina escolar localizada no

município de São José/SC.

Ao verificar o cenário da cantina para que fosse realizado o

desenvolvimento de um software, foi identificado que poderiam existir necessidades

de diversas funcionalidades, as quais poderiam ser facilmente utilizadas como

insumo para que a proposta deste trabalho pudesse ser colocada em prática.

Para dar início ao projeto, foi marcada uma reunião com a proprietária da

cantina para que fosse possível conhecer a forma de trabalho, os recursos

disponíveis e as necessidades que ela tinha para que pudesse melhorar a

produtividade e ter um controle eficiente da gestão da cantina.

De forma resumida, o cenário baseia-se em uma lanchonete com dois

funcionários vendedores e a proprietária da cantina. Na cantina realizam-se vendas

de salgados, doces, almoço, sucos e refrigerantes. A venda pode ser feita para

qualquer pessoa, porém, para alunos e funcionários da escola, há a necessidade de

se controlar crédito através da identificação do cartão de cada aluno. Este cartão é

de numeração única e possui a matrícula de cada aluno/funcionário da escola.

71

4.1.1 ETAPA DE LEVANTAMENTO DE REQUISITOS

Para o levantamento das necessidades que precisariam ser atendidas, a

conversa foi iniciada em forma de entrevista com o objetivo de identificar os atores

existentes no contexto da cantina, os requisitos funcionais, os não funcionais e as

regras de negócio. A proprietária da cantina expôs quais atividades são realizadas

na cantina, quem as realiza, as dificuldades que ela enfrenta e os objetivos de cada

atividade.

Com base nesta entrevista inicial, foram identificados os requisitos que o

sistema precisaria ter para que a proprietária da cantina pudesse realizar a gestão

da cantina de forma mais eficaz. Em conjunto com os requisitos, também foram

levantadas as necessidades de negócio, estas expressas através de regras de

negócio, as quais ditam como o sistema deve se comportar.

Tendo os requisitos e regras de negócio levantadas, foram elaborados os

casos de uso das funcionalidades que o sistema precisaria ter. De acordo com Silva

(2012), a elaboração de casos de uso requer um maior esforço do que escrever as

histórias de usuário, porém, Matos et al. (2013) conclui através de experimentos que

os casos de uso atendem melhor as expectativas dos programadores.

Segundo Matos et al. (2013, p. 13), o diagrama de caso de uso “é um

documento de linguagem comum entre usuário e desenvolvedor, deste modo é

possível garantir que certas funcionalidades foram verificadas e validadas pelo

cliente”. De acordo com Silva (2012, p. 15), “diagramas de casos de uso podem

servir de a geração de Stories para a formação do Product Backlog”.

Com base nas citações de Matos et al. (2013) e Silva (2012), foi verificado

a importância de se modelar os casos de uso, uma vez que este é mais rico em

detalhes para o time de desenvolvimento, além de ser um documento visual de fácil

validação com usuário.

Tendo elaborado os casos de uso para dar melhor visibilidade para o time

de desenvolvimento, foram geradas as histórias de usuário. A geração das histórias

de usuário, bem como dos critérios de aceite das histórias, puderam ser elaboradas

com exatidão, uma vez que foram baseadas nos casos de uso que continham

72

informações suficientes para elicitar o objetivo do usuário e as condições que

precisariam ser atendidas.

Após realizar a elaboração dos casos de uso, requisitos, regras de

negócio e histórias de usuário, este levantamento foi validado junto com a

proprietária da cantina, a qual verificou que os pontos que foram tratados na

entrevista foram corretamente descritos e estavam claros a forma que seriam

atendidos.

Após a validação das histórias e casos de uso, foram elaborados os

diagramas de sequência e de classes. De acordo com experimentos de Silva (2012),

o diagrama de classes oferece apoio para a elaboração da modelagem conceitual

das entidades do sistema, além de possuir informações que servem de subsídio

para novas pessoas que possam ser incluídas no projeto. O diagrama de

sequências dá uma visão breve do caso de uso para os desenvolvedores, de forma

a mostrar a ordem cronológica em que cada atividade ocorre dentro de um

determinado caso de uso.

A seguir, são apresentados os artefatos gerados durante a etapa de

desenvolvimento da proposta.

4.1.2 ETAPA DE DESENVOLVIMENTO DA PROPOSTA

O desenvolvimento deste trabalho inicia-se então através da reunião para

a elicitação de requisitos, elaboração de documentação que seja essencial para que

todos os envolvidos no projeto tenham conhecimento do que precisa ser feito e

posteriormente, a execução do desenvolvimento seguindo as diretrizes do Scrum.

73

4.1.2.1 CASOS DE USO

Antes de iniciar a apresentação dos casos de uso, serão apresentados os

requisitos e regras levantados na primeira reunião realizada junto com a proprietária

da cantina. Esta reunião inicial tem como objetivo extrair o máximo de informações

sobre o negócio e possibilitar realizar o levantamento de requisitos.

A seguir, no quadro 6, são apresentados os requisitos funcionais, ou seja,

o que a proprietária da cantina espera que o sistema a possibilite realizar.

Quadro 6 – Descrição dos Requisitos Funcionais

Produtos

RF001.01 – O sistema deve permitir cadastrar, alterar, excluir e consultar produtos que serão comercializados na cantina.

RF001.02 – O sistema deve permitir inativar produtos que não são mais comercializados na cantina.

RF001.03 - O sistema deve permitir consultar produtos inativos que não são mais comercializados na cantina.

RF001.04 - O sistema deve permitir controlar o estoque mínimo de produtos que são comercializados na cantina.

Clientes

RF002.01 - O sistema deve permitir cadastrar, alterar, excluir e consultar clientes que consomem produtos na cantina.

RF002.02 - O sistema deve permitir inativar clientes que não consomem mais produtos da cantina.

RF002.03 - O sistema deve permitir consultar clientes inativos que não consomem mais produtos da cantina.

Fornecedores

RF003.01 - O sistema deve permitir cadastrar, alterar, excluir e consultar fornecedores de produtos para a cantina.

RF003.02 - O sistema deve permitir inativar fornecedores que não fornecem mais produtos para a cantina.

RF003.03 - O sistema deve permitir consultar fornecedores inativos que não fornecem mais produtos para a cantina.

Recarga de Saldo

RF004.01 - O sistema deve permitir inserir e consultar saldo no cartão escolar de clientes.

Compras

RF005.01 - O sistema deve permitir cadastrar, alterar, excluir e consultar compra de produtos comercializados na cantina.

RF005.02 - O sistema deve atualizar o estoque dos produtos quando houver compra de produtos para a cantina.

RF005.03 - O sistema deve permitir utilizar leitor de código de barras para identificar produtos ao realizar a venda de produtos.

Vendas

RF006.01 - O sistema deve permitir incluir, alterar, excluir e consultar venda de produtos.

RF006.02 - O sistema deve atualizar o estoque dos produtos quando houver venda de produtos.

RF006.03 - O sistema deve permitir utilizar leitor de código de barras para identificar clientes e produtos

RF006.04 - O sistema deve exibir o saldo do cartão escolar no momento da venda.

RF006.05 - O sistema deve debitar o saldo do cartão do cliente.


74

No quadro 7, são apresentados os requisitos não funcionais, ou seja,

aqueles englobam em geral, critérios de qualidade e não estão necessariamente

relacionados às funcionalidades que o usuário precisa executar no sistema. Os

requisitos não funcionais são uma base que suportam as funcionalidades que o

sistema precisa ter e, estão sendo elencados devido às histórias de usuário que

precisam ser escritas de forma simples e objetiva que o usuário entenda com

facilidade.

Quadro 7 – Descrição dos Requisitos Não Funcionais

RNF01 - Todos os campos de pesquisa devem ignorar acentuação e não diferenciar letras maiúsculas e minúsculas.

RNF02 - O sistema deverá ser acessado completamente via navegador Chrome em versões 47.0 até 49.0.2623.

RNF03 - O sistema deve utilizar banco de dados MySQL.

RNF04 - A base de dados deve ser acessível apenas por usuários autorizados.

RNF05 - O sistema deve suportar até 5 acessos simultâneos.

RNF06 - Realizar rollback caso ocorra algum em qualquer transação realizada no sistema.

RNF006.01 - Deve ser possível realizar vendas utilizando apenas o teclado.

RNF006.02 - Ao incluir um produto na venda, a descrição e o preço devem aparecer em, no máximo, 2 segundos.


No quadro 8, são apresentadas as regras de negócio que definem como

as operações realizadas na cantina devem ser feitas. Tais regras são

imprescindíveis para a contextualização de como deve ser o comportamento de

cada funcionalidade do sistema.

Quadro 8 – Descrição das Regras de Negócio

Produtos

RN001.01 - Informações obrigatórias de produtos Todos os produtos devem possuir descrição, tipo (salgados doces, balas) e valor de venda.

RN001.02 - Código de barras de produtos Um produto deve possuir apenas 1 código de barras e este código de barras não pode estar sendo utilizado por outro(s) produto(s).

RN001.03 - Excluir produtos Caso um produto possuir vínculo em alguma movimentação de entrada ou saída (compra ou venda), não deve ser possível excluir o respectivo produto, apenas inativar o cadastro do mesmo.

RN001.04 - Nome de produtos Um produto não pode ter o mesmo nome de outro produto já cadastrado.

75

Clientes

RN002.01 - Informações obrigatórias de clientes. Para cadastrar clientes, é necessário informar além do nome, o tipo (aluno, funcionário ou cliente externo). Caso o cliente for aluno ou funcionário, é necessário que seja informada a matrícula dele.

RN002.02 - Excluir clientes. Caso um cliente possuir vínculo em alguma movimentação de venda, não deve ser possível excluir o respectivo cliente, apenas inativar o cadastro do mesmo.

RN002.03 - Matrícula de alunos e professores Uma matrícula deve estar associada para apenas 1 aluno ou professor.

Fornecedores

RN003.01 - Informações obrigatórias de fornecedores. Para cadastrar um fornecedor, apenas o nome/razão social deve ser obrigatoriamente informado.

RN003.02 - Excluir fornecedores. Caso um fornecedor possuir vínculo em alguma movimentação de compra, não deve ser possível excluir o respectivo fornecedor, apenas inativar o cadastro do mesmo.

RN003.03 - Validação de CPF/CNPJ. Ao informar um CPF ou CNPJ, deve ser informado um valor válido e, o número informado, deve estar associado para apenas 1 fornecedor.

Recarga de Saldo

RN004.01 - Verificar situação do cadastro do cliente para inserir crédito. Não deve ser possível inserir crédito para clientes que estejam com o cadastro inativo.

RN004.02 - Inserir crédito na conta do cliente. Ao inserir crédito para um cliente, o sistema deve atualizar o saldo do cliente, de forma a acrescentar o valor inserido ao saldo existente anteriormente.

RN004.03 - Permitir inserir crédito apenas para determinados tipos de clientes. Permitir inserir crédito apenas para clientes do tipo "Aluno" e "Funcionário".

RN004.04 - Informações obrigatórias para inserção de crédito. Para inserir crédito, é necessário que seja informado cliente, forma de pagamento e valor.

Compras

RN005.01 - Informações obrigatórias de compras. Para cadastrar uma compra, é necessário que seja informado pelo menos o fornecedor, a data da compra, a forma de pagamento da compra realizada e no mínimo 1 produto.

RN005.02 - Validar situação do cadastro de produtos e fornecedores. Não deve ser possível adicionar um produto ou fornecedor em que os seus respectivos cadastros estejam inativos.

RN005.03 - Validar data de compra. Não permitir que seja informada uma data maior que a data atual.

RN005.04 - Atualizar preço de compra e estoque do produto. Ao salvar a compra de produtos, o sistema deve atualizar o preço de compra do produto e somar a quantidade de produtos que foi comprada no saldo atual do produto antes do registro de compra atual.

Vendas

RN006.01 - Permitir realizar venda sem informar cliente. Deve ser possível realizar uma venda sem informar o cliente.

RN006.02 - Validar situação do cadastro de clientes e produtos. Não deve ser possível informar produtos e clientes que estejam com o cadastro inativo.

RN006.03 - Seleção de produtos sem estoque para venda. Os produtos que estão com o cadastro ativo mas não possuem saldo em estoque, devem aparecer na consulta de produtos, porém não podem ser adicionados na venda.

RN006.04 - Informações obrigatórias para realização de vendas. Para inserir uma venda, é necessário que seja informado pelo menos 1 produto com quantidade maior que 0 e a forma de pagamento.

76

RN006.05 - Permitir utilizar crédito do saldo do cliente como forma de pagamento. Para clientes do tipo “aluno” e “funcionário”, deve ser possível vender utilizando uma forma de pagamento referente ao cartão escolar.

RN006.06 - Permitir selecionar cartão escolar apenas para alunos e funcionários. A forma de pagamento referente ao cartão escolar deve estar disponível apenas para clientes do tipo "aluno" e "funcionário".

RN006.07 - Atualizar estoque de produtos ao realizar vendas. Ao finalizar uma venda, o sistema deve debitar a quantidade de cada produto que foi vendido no saldo atual dos produtos antes do registro de venda atual.

RN006.08 - Atualizar saldo do crédito do cliente. Ao finalizar uma venda em que tenha sido selecionada a forma de pagamento referente ao cartão escolar, o sistema deve debitar o valor total vendido do saldo do cliente selecionado na venda.

RN006.09 - Possibilitar realizar venda no cartão escolar para clientes sem saldo. Deve ser possível vender para alunos e funcionários que não possuem crédito, desta forma, o saldo do respectivo cliente ficará negativo.


Na entrevista foram encontrados identificados os seguintes atores:

Administrador: este é a proprietária da cantina, que será a

responsável pela manutenção de cadastros e configurações do

sistema.

Vendedor: são os funcionários da cantina que são responsáveis pela

parte operacional como realizar as vendas de produtos, dar

entrada nas notas fiscais e realizar a recarga de saldo de cartões.

A seguir, são apresentados os casos de uso das funcionalidades da

cantina e quais os atores estão envolvidos.

A figura 33 exibe uma visualização macro da interação dos atores com os

casos de uso, note que o caso de uso para cadastrar clientes é compartilhado entre

o administrador e vendedor, portanto, este comportamento deve ser previsto,

inclusive se houver algum tipo de permissão de acesso, para os quais podem ter

privilégios diferentes.

77

Figura 33 – Diagrama de Caso de Uso e Atores


A seguir, é apresentada a documentação de todos os casos de uso, bem

como aos requisitos aos quais os mesmos atendem e as regras que devem ser

aplicadas.

O quadro 9 apresenta o caso de uso referente ao cadastro de produtos no

sistema, descrevendo as condições e os fluxos principal e alternativos.

Quadro 9 – Documentação do caso de uso “Cadastrar Produtos”

Caso de Uso: UC001 - Cadastrar Produtos

Objetivo: O objetivo deste caso de uso é permitir manter o cadastro de produtos, sendo cadastrar, alterar, excluir e consultar produtos.

Pré-condições: Não se aplica

Pós-condições:

POS001 - Produto cadastrado no sistema da cantina O produto é cadastrado e passa a fazer parte da lista de produtos ativos da cantina

POS002 - Produto inativado O produto é inativado. Este produto não estará disponível para a realização de movimentações de entradas e saídas (compras e vendas).

POS003 - Produto alterado O sistema salva as alterações do cadastro do produto.

POS004 - Produto excluído O sistema exclui o cadastro do produto. Não é possível recuperar os dados do produto excluído.

POS005 - Produto não excluído O sistema não exclui o produto.

Requisitos Funcionais:

RF001.01 – O sistema deve permitir cadastrar, alterar, excluir e consultar produtos que serão comercializados na cantina.

RF001.02 – O sistema deve permitir inativar produtos que não são mais comercializados na cantina.

78

RF001.03 - O sistema deve permitir consultar produtos inativos que não são mais comercializados na cantina.

RF001.04 - O sistema deve permitir controlar o estoque mínimo de produtos que são comercializados na cantina.

Regras de Negócio:

RN001.01 - Informações obrigatórias de produtos Todos os produtos devem possuir descrição, tipo (salgados doces, balas) e valor de venda.

RN001.02 - Código de barras de produtos Um produto deve possuir apenas 1 código de barras e este código de barras não pode estar sendo utilizado por outro(s) produto(s).

RN001.03 - Excluir produtos Caso um produto possuir vínculo em alguma movimentação de entrada ou saída (compra ou venda), não deve ser possível excluir o respectivo produto, apenas inativar o cadastro do mesmo.

RN001.04 - Nome de produtos Um produto não pode ter o mesmo nome de outro produto já cadastrado.

Fluxo Básico

FB - Cadastrar Produto

1. O Administrador acessa a funcionalidade de manter produtos.

2. O sistema apresenta a tela de consulta de produtos.

3. O Administrador acessa a funcionalidade para incluir um novo produto. [FA1] [FA2] [FA3]

4. O sistema apresenta a tela de cadastro de produtos.

5. O Administrador entra com as informações do produto e submete a opção para salvar o cadastro.

6. O sistema valida as informações do cadastro. [RN001.01] [RN001.02] RN001.04]

7. O sistema inclui o produto no sistema.

Fluxo Alternativo [FA1]

FA1 - Alterar Produto

1. O Administrador seleciona um produto e acessa a funcionalidade para alterar o cadastro de um produto.

2. O sistema exibe a tela de cadastro de produtos com os dados do produto selecionado.

3. O Administrador altera as informações do produto e submete a opção para salvar o cadastro.

4. O sistema valida o cadastro do produto. [RN001.01] [RN001.02] RN001.04]

5. O sistema salva os dados do produto.


FA2 - Excluir Produto

1. O Administrador seleciona um produto e acessa a funcionalidade para excluir o produto.

2. O sistema valida o cadastro do produto para realizar a exclusão. [RN001.03]

3. O sistema exclui o produto.


FA3 - Consultar Produto

1. O Administrador seleciona um produto e acessa a funcionalidade para consultar o produto.

2. O sistema exibe a tela de cadastro de produto com os dados do produto selecionado.

79

Protótipo – Consulta de Produtos

Protótipo – Cadastro de Produtos


O quadro 10 apresenta o caso de uso referente ao cadastro de clientes no


Quadro 10 – Documentação do caso de uso “Cadastrar Clientes”

Caso de Uso: UC002 - Cadastrar Clientes

Objetivo:

O objetivo deste caso de uso é permitir manter o cadastro de clientes, sendo cadastrar, alterar, excluir e consultar produtos. Cliente é qualquer pessoa que possua cadastro na cantina e que podem comprar, de forma geral, são os alunos, funcionários da escola, funcionários da própria cantina e clientes externos (sem vínculo com a escola). Nem todos os clientes que compram na cantina, precisaram estar cadastrados no sistema para consumir produtos da cantina, desta forma, podem existir clientes não identificados.

Pré-condições:

Não se aplica

80

Pós-condições:

POS001 - Cliente cadastrado na cantina O cliente é cadastrado e passa a fazer parte da lista de clientes ativos da cantina

POS002 - Cliente inativado O cliente é inativado. Este cliente não estará disponível para a realização de movimentações de saídas (vendas).

POS003 - Cliente alterado O sistema salva as alterações do cadastro do cliente.

POS004 - Cliente excluído O sistema exclui o cadastro do cliente. Não é possível recuperar os dados do cliente excluído.

POS005 - Cliente não excluído O sistema não exclui o cliente.


RF002.01 - O sistema deve permitir cadastrar, alterar, excluir e consultar clientes que consomem produtos na cantina.

RF002.02 - O sistema deve permitir inativar clientes que não consomem mais produtos da cantina.

RF002.03 - O sistema deve permitir consultar clientes inativos que não consomem mais produtos da cantina.

Regras de Negócio:

RN002.01 - Informações obrigatórias de clientes. Para cadastrar clientes, é necessário informar além do nome, o tipo (aluno, funcionário ou cliente externo). Caso o cliente for aluno ou funcionário, é necessário que seja informada a matrícula dele.

RN002.02 - Excluir clientes. Caso um cliente possuir vínculo em alguma movimentação de venda, não deve ser possível excluir o respectivo cliente, apenas inativar o cadastro do mesmo.

RN002.03 - Matrícula de alunos e professores Uma matrícula deve estar associada para apenas 1 aluno ou professor.

Fluxo Básico

FB - Cadastrar Cliente

1. O Administrador ou Vendedor acessa a funcionalidade de manter clientes.

2. O sistema apresenta a tela de consulta de clientes.

3. O Administrador ou Vendedor acessa a funcionalidade para incluir um novo cliente. [FA1] [FA2] [FA3]

4. O sistema apresenta a tela de cadastro de clientes.

5. O Administrador ou Vendedor entra com as informações do cliente e submete a opção para salvar o cadastro.

6. O sistema valida as informações do cadastro. [RN002.01] [RN002.03]

7. O sistema inclui o cliente no sistema.

Fluxo Alternativo

[FA1]

FA1 - Alterar Cliente

O Administrador ou Vendedor seleciona um cliente e acessa a funcionalidade para alterar o cadastro de um cliente.

O sistema exibe a tela de cadastro de cliente com os dados do cliente selecionado.

O Administrador ou Vendedor altera as informações do cliente e submete a opção para salvar o cadastro.


5. O sistema altera o cadastro do cliente.

Fluxo Alternativo

[FA2]

FA2 - Excluir Cliente

1. O Administrador ou Vendedor seleciona um cliente e acessa a funcionalidade para excluir o cliente.

2. O sistema valida o cadastro do cliente para realizar a exclusão. [RN001.02]

81

3. O sistema exclui o cliente.

Fluxo Alternativo

[FA3]

FA3 - Consultar Cliente

1. O Administrador ou Vendedor seleciona um cliente e acessa a funcionalidade para consultar o cliente.

2. O sistema exibe a tela de cadastro de cliente com os dados do cliente selecionado.

Protótipo – Consulta de Clientes

Protótipo – Cadastro de Clientes


O quadro 11 apresenta o caso de uso referente ao cadastro de produtos

no sistema, descrevendo as condições e os fluxos principal e alternativos.

Quadro 11 – Documentação do caso de uso “Cadastrar Fornecedores”

Caso de Uso: UC003 - Cadastrar Fornecedores

Objetivo: O objetivo deste caso de uso é permitir manter o cadastro de fornecedores, sendo cadastrar, alterar, excluir e consultar produtos. Um fornecedor pode ser uma pessoa física ou uma pessoa jurídica.

82


Pós-condições:

POS001 - Os dados do fornecedor são exibidos O cliente é cadastrado e passa a fazer parte da lista de clientes ativos da cantina

POS002 - Fornecedor inativado O cadastro do fornecedor é inativado, de forma que ele não é exibido na consulta de fornecedores para associação em uma entrada de notas (compra).

POS003 - Fornecedor alterado O cadastro do fornecedor é alterado e as informações salvas no sistema.

POS004 - Fornecedor excluído O fornecedor não possui nenhum vínculo com nenhum produto ou movimentação de entrada (compra) e ele é excluído do sistema, não sendo possível recuperar esta informação.

POS005 - Fornecedor cadastrado Fornecedor cadastrado


RF003.01 - O sistema deve permitir cadastrar, alterar, excluir e consultar fornecedores de produtos para a cantina.

RF003.02 - O sistema deve permitir inativar fornecedores que não entregam mais produtos para a cantina.

RF003.03 - O sistema deve permitir consultar fornecedores inativos que não fornecem mais produtos para a cantina.

Regras de Negócio:

RN003.01 - Informações obrigatórias de fornecedores. Para cadastrar um fornecedor, apenas o nome/razão social deve ser obrigatoriamente informado.

RN003.02 - Excluir fornecedores. Caso um fornecedor possuir vínculo em alguma movimentação de compra, não deve ser possível excluir o respectivo fornecedor, apenas inativar o cadastro do mesmo.

RN003.03 - Validação de CPF/CNPJ. Ao informar um CPF ou CNPJ, deve ser informado um valor válido e, o número informado, deve estar associado para apenas 1 fornecedor.

Fluxo Básico

FB - Cadastrar Fornecedor

1. O Administrador acessa a funcionalidade de manter fornecedores.

2. O sistema apresenta a tela de consulta de fornecedores.

3. O Administrador acessa a funcionalidade para incluir um novo fornecedor. [FA1] [FA2] [FA3]

4. O sistema apresenta a tela de cadastro de fornecedor.,

5. O Administrador entra com as informações do fornecedor e submete a opção para salvar o fornecedor.


7. O sistema inclui o fornecedor no sistema.


FA1 - Alterar Fornecedor

1. O Administrador seleciona um fornecedor e acessa a funcionalidade para alterar o cadastro de um fornecedor.

O sistema exibe a tela de cadastro de cliente com os dados do cliente selecionado.

2. O sistema exibe a tela de cadastro de fornecedores com os dados do fornecedor selecionado.

3. O Administrador altera as informações do fornecedor e submete a opção para salvar o cadastro. [RN003.01] [RN003.03]

4. O sistema altera os dados do fornecedor.

Fluxo Alternativo FA2 - Excluir Fornecedor

83

[FA2] 1. O Administrador seleciona um fornecedor e acessa a funcionalidade para excluir o fornecedor.

2. O sistema valida o cadastro do fornecedor para realizar a exclusão. [RN003.02]

3. O sistema exclui o fornecedor.


FA3 - Consultar Fornecedor

1. O Administrador seleciona um fornecedor e acessa a funcionalidade para consultar o fornecedor.

2. O sistema exibe a tela de cadastro de fornecedor com os dados do fornecedor selecionado.

Protótipo – Consulta de Fornecedores

Protótipo – Cadastro de Fornecedores


O quadro 12 apresenta o caso de uso referente à recarga de saldo em

cartão no sistema, descrevendo as condições e os fluxos principal e alternativos.

84

Quadro 12 – Documentação do caso de uso “Recarregar Saldo em Cartão” Caso de Uso: UC004 - Recarregar Saldo em Cartão

Objetivo:

O objetivo deste caso de uso é permitir inserir crédito no cartão de clientes, sendo eles alunos ou funcionários (da escola ou da própria cantina). Através deste saldo, será possível realizar vendas utilizando este crédito como forma de pagamento.


Pós-condições: POS001 - Saldo de crédito inserido e disponível para o cliente


RF004.01 - O sistema deve permitir inserir e consultar saldo no cartão escolar de clientes.

Regras de Negócio:

RN004.01 - Verificar situação do cadastro do cliente para inserir crédito. Não deve ser possível inserir crédito para clientes que estejam com o cadastro inativo.

RN004.02 - Inserir crédito na conta do cliente. Ao inserir crédito para um cliente, o sistema deve atualizar o saldo do aluno, de forma a acrescentar o valor inserido ao saldo existente anteriormente.

RN004.03 - Permitir inserir crédito apenas para determinados tipos de clientes. Permitir inserir crédito apenas para clientes do tipo "Aluno" e "Funcionário".

RN004.04 - Informações obrigatórias para inserção de crédito. Para inserir crédito, é necessário que seja informado cliente, forma de pagamento e valor.

Fluxo Básico

FB - Recarregar saldo

1. O Vendedor acessa a funcionalidade para realizar a recarga de saldo no cartão do cliente.

2. O sistema apresenta a tela para a inclusão de saldo.

3. O Vendedor entra com as informações da recarga e submete a operação.

4. O sistema valida as informações. [RN004.01] [RN004.02] [RN004.03] [RN004.04]

5. O sistema inclui o saldo no cartão do cliente

Protótipo – Inserir crédito


O quadro 13 apresenta o caso de uso referente ao registro de compras no


Quadro 13 – Documentação do caso de uso “Registrar compras”

Caso de Uso: UC005 - Registrar Compras

Objetivo: O objetivo deste caso de uso é permitir que possa ser registrado a entrada de produtos na cantina, desta forma, os produtos que possuem controle de estoque passam a ter saldo e podem ser vendidos pela cantina.

Pré-condições:

PRE001 - Deve existir pelo menos 1 fornecedor cadastrado.

85

Pós-condições:

POS001 - Compra cadastrada A compra é cadastrada e o saldo dos produtos da compra são atualizados em estoque.

POS002 - Compra alterada O sistema salva as alterações do registro de compras.

POS003 - Compra excluída O sistema exclui o registro de compras.

POS004 - Estoque de produto atualizado.


RF005.01 - O sistema deve permitir cadastrar, alterar, excluir e consultar compra de produtos comercializados na cantina.

RF005.02 - O sistema deve atualizar o estoque dos produtos quando houver compra de produtos para a cantina.

RF005.03 - O sistema deve permitir utilizar leitor de código de barras para identificar produtos ao realizar a venda de produtos.

Regras de Negócio:

RN005.01 - Informações obrigatórias de compras. Para cadastrar uma compra, é necessário que seja informado pelo menos o fornecedor, a data da compra, a forma de pagamento da compra realizada e no mínimo 1 produto.

RN005.02 - Validar situação do cadastro de produtos e fornecedores. Não deve ser possível adicionar um produto ou fornecedor em que os seus respectivos cadastros estejam inativos.

RN005.03 - Validar data de compra. Não permitir que seja informada uma data maior que a data atual.

RN005.04 - Atualizar preço de compra e estoque do produto. Ao salvar a compra de produtos, o sistema deve atualizar o preço de compra do produto e somar a quantidade de produtos que foi comprada no saldo atual do produto antes do registro de compra atual.

Fluxo Básico

FB - Cadastrar Compra

1. O Vendedor acessa a funcionalidade de manter compras.

2. O sistema apresenta a tela de consulta de compras.

3. O Vendedor acessa a funcionalidade para incluir uma nova compra. [FA1] [FA2] [FA3]

4. O sistema apresenta a tela de cadastro de compras.

5. O Vendedor entra com as informações da compra e submete a opção para salvar a compra


7. O sistema registra a compra.

Fluxo Alternativo

[FA1]

FA1 - Alterar Compra

1. O Vendedor seleciona uma compra e acessa a funcionalidade para alterar os dados da compra.

2. O sistema exibe a tela de compras com os dados da compra selecionada.

3. O Vendedor altera as informações da compra e submete a opção para salvar.

4. O sistema valia as informações. [RN005.01] [RN005.02] [RN005.03] [RN005.04]

5. O sistema salva os dados da compra.

Fluxo Alternativo

[FA2]

FA2 - Excluir Compra

1. O Vendedor seleciona um registro de compra e acessa a funcionalidade para excluir o respectivo registro.

2. O sistema exclui o registro de compra.

86

Fluxo Alternativo

[FA3]

FA3 - Consultar Compra

1. O Vendedor seleciona um registro de compra e acessa a funcionalidade para consultar o registro.

2. O sistema exibe a tela de cadastro de compra com os dados da compra selecionada.

Protótipo – Consulta Compras

Protótipo – Cadastro Compras


O quadro 14, apresenta o caso de uso referente à venda de produtos no


Quadro 14 – Documentação do caso de uso “Realizar Venda de Produtos”

Caso de Uso: UC006 - Realizar Venda de Produtos

Objetivo: O objetivo deste caso de uso é permitir que possa ser registrado a venda de produtos na cantina.

Pré-condições: PRE001 - Deve existir pelo menos 1 produto cadastrado.

PRE002 - É necessário que existam formas de pagamento cadastradas.

Pós-condições:

POS001 - Venda realizada

POS002 - Venda alterada.

POS003 - Venda excluída.

POS004 - Estoque de produto atualizado.

87


RF006.01 - Permitir incluir, alterar, excluir e consultar venda de produtos.

RF006.02 - O sistema deve atualizar o estoque dos produtos quando houver venda de produtos.

RF006.03 - Permitir utilizar leitor de código de barras para identificar clientes e produtos

RF006.04 - O sistema deve exibir o saldo do cartão escolar no momento da venda.

RF006.05 - O sistema deve debitar o saldo do cartão do cliente.

Regras de Negócio:

RN006.01 - Permitir realizar venda sem informar cliente. Deve ser possível realizar uma venda sem informar o cliente.

RN006.02 - Validar situação do cadastro de clientes e produtos. Não deve ser possível informar produtos e clientes que estejam com o cadastro inativo.

RN006.03 - Seleção de produtos sem estoque para venda. Os produtos que estão com o cadastro ativo mas não possuem saldo em estoque, devem aparecer na consulta de produtos, porém não podem ser adicionados na venda.

RN006.04 - Informações obrigatórias para realização de vendas. Para inserir uma venda, é necessário que seja informado pelo menos 1 produto com quantidade maior que 0 e a forma de pagamento.

RN006.05 - Permitir utilizar crédito do saldo do cliente como forma de pagamento. Para clientes do tipo “aluno” e “funcionário”, deve ser possível vender utilizando uma forma de pagamento referente ao cartão escolar.

RN006.06 - Permitir selecionar cartão escolar apenas para alunos e funcionários. A forma de pagamento referente ao cartão escolar deve estar disponível apenas para clientes do tipo "aluno" e "funcionário".

RN006.07 - Atualizar estoque de produtos ao realizar vendas. Ao finalizar uma venda, o sistema deve debitar a quantidade de cada produto que foi vendido no saldo atual dos produtos antes do registro de venda atual.

RN006.08 - Atualizar saldo do crédito do cliente. Ao finalizar uma venda em que tenha sido selecionada a forma de pagamento referente ao cartão escolar, o sistema deve debitar o valor total vendido do saldo do cliente selecionado na venda.

RN006.09 - Possibilitar realizar venda no cartão escolar para clientes sem saldo. Deve ser possível vender para alunos e funcionários que não possuem crédito, desta forma, o saldo do respectivo cliente ficará negativo.

Fluxo Básico

FB - Inserir Venda

1. O Vendedor acessa a funcionalidade de vendas.

2. O sistema apresenta a tela de vendas.

3. O Vendedor acessa a funcionalidade para incluir uma nova venda. [FA1] [FA2] [FA3]

4. O sistema apresenta a tela de inclusão de vendas.

5. O Vendedor entra com as informações da venda e submete a operação para incluir a venda. [RN006.02] [RN006.03] [RN006.04] [RN006.05]


7. O sistema salva o registro de venda.

Fluxo Alternativo FA1 - Alterar Venda

88

[FA1] 1. O Vendedor seleciona um registro de venda e acessa a funcionalidade para alterar os dados da venda.

2. O sistema exibe a tela de vendas com os dados da venda selecionada.

3. O Vendedor altera as informações da venda e submete a opção para salvar. [RN006.02] [RN006.03] [RN006.04] [RN006.05]


5. O sistema salva os dados da compra.


FA2 - Excluir Venda

1. O Vendedor aciona a funcionalidade para excluir a venda.

2. O sistema valida as informações

3. O sistema exclui o registro de venda.


FA3 - Consultar Venda

1. O Vendedor seleciona um registro de venda e acessa a funcionalidade para consultar o registro.

2. O sistema exibe a tela de vendas com os dados da venda selecionada.

Protótipo – Consulta Vendas

Protótipo – Cadastro Vendas


89

Com a elaboração dos casos de uso para melhor compreensão das

funcionalidades a serem desenvolvidas e uma visão clara do comportamento

esperado do sistema, em seguida foram elaboradas as histórias de usuário para

uma apresentação dinâmica em linguagem natural para a proprietária da cantina.

A elaboração de histórias foi realizada dentro de uma das etapas do

Scrum, que é o product backlog.

4.1.2.2 PRODUCT BACKLOG

O product backlog, é a primeira fase do Scrum, pois trata-se basicamente

do itens que irão compor o processo de desenvolvimento.

Inicialmente são adicionados ao product backlog uma lista dos itens que

serão desenvolvidos baseados nos requisitos levantados. Posteriormente, com o

surgimento de necessidade de correções que não impactam as entregas ou ainda

melhoria nas funcionalidades desenvolvidas, estes novos itens também podem ser

adicionados ao product backlog. Os itens que compõem o product backlog são as

histórias de usuário.

4.1.2.2.1 HISTÓRIAS DE USUÁRIO

As histórias de usuário não são requisitos, segundo Silva (2011, p. 12),

“são sentenças que indicam a funcionalidade que um determinado ator pode

executar através de uma ação”. Desta forma, precisam ser descritas pelo usuário

(no caso a proprietária da cantina), de acordo com o que for necessário existir no

sistema para atender as expectativas dele.

As histórias de usuário foram elaboradas a partir dos casos de uso,

descritos com informações levantadas através da entrevista com a proprietária da

cantina. A elaboração de histórias a partir dos casos de uso ajudou a compreender

90

os pontos que deveriam ser atendidos e facilitou na definição dos critérios de aceite,

uma linguagem em comum entre a proprietária da cantina e o time de

desenvolvimento.

O quadro 15 apresenta a história de usuário referente ao cadastro de

clientes no sistema, descrevendo os objetivos da proprietária da cantina, bem como

os critérios de aceite da funcionalidade.

Quadro 15 – História de usuário – “Cadastro de Clientes”

US - 01 - Cadastro de Clientes

Eu como proprietária e administradora da lanchonete, desejo cadastrar clientes, de forma que eu possa registrar as vendas que realizo na cantina, permitindo identificar os clientes para os quais estou vendendo, além de controlar o crédito que os pais dos alunos fazem para que os mesmos possam ir consumindo durante o mês.

Critérios de aceite:

1. Deve ser possível cadastrar um cliente externo (cliente que não possui vínculo com a escola);

2. Deve ser possível cadastrar um cliente do tipo "aluno";

3. Deve ser possível cadastrar um cliente do tipo "Funcionário";

4. Deve ser possível excluir clientes que nunca compraram na cantina;

5. Deve ser possível inativar um cliente;

6. Os clientes inativos não devem aparecer na tela de consulta, a não ser que seja definida a opção para exibi-los;

7. Todos os clientes precisam ter um “tipo de cliente”;

8. Para clientes do tipo “aluno”, deve ser possível informar matrícula e o nome dos pais;

9. Para clientes dos tipos “aluno” e “funcionário”, não deve ser possível cadastrar caso a matrícula não tenha sido informada;

10. Para clientes do tipo “funcionário”, deve ser possível informar matrícula e cargo;

11. Não deve ser possível informar uma mesma matrícula para clientes diferentes;

12. Deve ser possível consultar a lista de clientes;

13. Deve ser possível consultar os dados de um cliente de forma detalhada.

Prioridade: 1 – Horas: 80



fornecedores no sistema, descrevendo os objetivos da proprietária da cantina, bem

como os critérios de aceite da funcionalidade.

91

Quadro 16 – História de usuário – “Cadastro de Fornecedores”

US – 02 - Cadastro de Fornecedores

Eu como proprietária e administradora da lanchonete, desejo cadastrar fornecedores, de forma que eu possa ter controle dos meus fornecedores.


1. Deve ser possível cadastrar um fornecedor informando apenas o nome dele;

2. Deve ser possível informar o documento (CPF ou CNPJ) do fornecedor;

3. Não deve ser possível informar um mesmo documento (CPF ou CNPJ) para fornecedores diferentes;

4. Deve ser possível excluir fornecedores que nunca venderam para cantina;

5. Deve ser possível inativar um fornecedor;

6. Os fornecedores inativos não devem aparecer na tela de consulta, a não ser que seja definida a opção para exibi-los;

7. Deve ser possível consultar a lista de fornecedores;

8. Deve ser possível consultar os dados de um fornecedor de forma detalhada.




produtos no sistema, descrevendo os objetivos da proprietária da cantina, bem como

os critérios de aceite da funcionalidade.

Quadro 17 – História de usuário – “Cadastro de Produtos”

US - 03 - Cadastro de Produtos

Eu como proprietária e administradora da lanchonete, desejo cadastrar os produtos que são comercializados na cantina, de forma que eles poderão ser utilizados nos registros de compras e vendas.


1. Deve ser possível cadastrar um produto sem “código de barras”;

2. Todos os produtos precisam ter um “tipo de produto”;

3. Deve ser possível excluir produtos que nunca foram comprados ou vendidos na cantina;

4. Deve ser possível inativar um produto;

5. Os produtos inativos não devem aparecer na tela de consulta, a não ser que seja definida a opção para exibi-los;

6. Deve ser possível indicar os produtos que eu desejo “controlar o saldo” em estoque;

7. Não deve ser possível informar um mesmo “código de barras” para produtos diferentes;

8. Não deve ser possível cadastrar um produto sem “descrição”, “tipo de produto” e “valor de venda”;

9. Deve ser possível consultar a lista de produtos;

92

10. Deve ser possível consultar os dados de um produto de forma detalhada.



O quadro 18 apresenta a história de usuário referente à recarga de saldo

em cartão, descrevendo os objetivos da proprietária da cantina, bem como os

critérios de aceite da funcionalidade.

Quadro 18 – História de usuário – “Recarga de Saldo em Cartão”

US - 04 – Recarga de Saldo em Cartão

Eu como vendedor da lanchonete, preciso inserir créditos no cartão de clientes (alunos e funcionários) para que eles possam utilizar este saldo para comprar na cantina.


1. Não deve ser possível inserir crédito para clientes que não sejam dos tipos “aluno” ou “funcionário”;

2. Não deve ser possível inserir créditos se não forem informados o cliente, a forma de pagamento que ele utilizou para inserir crédito e o valor do crédito;

3. Ao inserir créditos, o valor inserido deve ser somado ao saldo que o cliente possuía antes de inserir o crédito atual;

4. Não deve ser possível inserir crédito para clientes que estão com o cadastro inativo.

5. Deve ser possível consultar o saldo de crédito atualizado através do cadastro de clientes;



O quadro 19 apresenta a história de usuário referente à compra de

produtos, descrevendo os objetivos da proprietária da cantina, bem como os critérios

de aceite da funcionalidade.

Quadro 19 – História de usuário – “Compra de Produtos”

US - 05 – Compra de Produtos

Eu como vendedor da lanchonete, preciso registrar as compras de produtos que são realizadas para a cantina, afim de que possa obter saldo de produtos para serem vendidos na cantina.


93

1. Não deve ser possível inserir uma compra sem informar o “fornecedor”, a “data da compra”, a “forma de pagamento” e pelo menos 1 produto;

2. Não deve ser possível informar um fornecedor ou um produto que estejam com o cadastro inativo;

3. Não deve ser possível informar uma “data de compra” maior que a data atual do cadastro;

4. Ao salvar a compra de produtos, o sistema deve atualizar o preço de compra do produto e somar a quantidade de produtos que foi comprada no saldo atual do produto antes do registro de compra atual.

5. Deve ser possível consultar a lista de compras realizadas;

6. Deve ser possível consultar os dados da compra realizada de forma detalhada.



O quadro 20 apresenta a história de usuário referente à compra de

produtos, descrevendo os objetivos da proprietária da cantina, bem como os critérios

de aceite da funcionalidade.

Quadro 20 – História de usuário – “Venda de Produtos”

US - 06 – Venda de Produtos

Eu como vendedor da lanchonete, preciso registrar as vendas de produtos que são realizadas na cantina, de forma rápida e identificando os clientes, exceto nas situações em que trata-se de um cliente não cadastrado na cantina.


1. Deve ser possível realizar uma venda sem informar o cliente;

2. Deve ser possível realizar venda de almoço apenas inserindo o valor do almoço.

3. Não deve ser possível informar produtos e clientes que estejam com o cadastro inativo;

4. Não deve ser possível realizar venda de produtos sem saldo em estoque, exceto para os produtos que não possuem controle de estoque;

5. Deve ser possível excluir um produto que tenha sido adicionado na venda enquanto ela não for finalizada;

6. Não deve ser possível finalizar uma venda sem informar a forma de pagamento;

7. Para clientes do tipo “aluno” e “funcionário”, deve ser possível vender utilizando uma forma de pagamento referente ao cartão escolar;

8. Não deve ser possível informar a opção de pagamento referente ao cartão escolar para clientes do tipo “externo” ou ainda para vendas em que o cliente não tenha sido informado;

9. Ao finalizar uma venda, o sistema deve debitar a quantidade de cada produto que foi vendido no saldo atual dos produtos antes do registro de venda atual.

94

10. Ao finalizar uma venda em que tenha sido selecionada a forma de pagamento referente ao cartão escolar, o sistema deve debitar o valor total vendido do saldo do cliente selecionado na venda.

11. Deve ser possível vender para alunos e funcionários que não possuem crédito, desta forma, o saldo do respectivo cliente ficará negativo;

12. Deve ser possível consultar a lista de vendas realizadas;

13. Deve ser possível consultar os dados da venda realizada de forma detalhada.

Prioridade: 6 – Pontos: 100


Após a elaboração das histórias, estas foram validadas junto à

proprietária da cantina para que pudessem dar seguimento ao projeto de

desenvolvimento. Para auxiliar a compreensão do time de desenvolvimento e

possuir uma documentação básica que seja relevante para o projeto, foram

elaborados os diagramas de classe e de atividades.

O diagrama de classes pode ser verificado a seguir na figura 34.

95

Figura 34 – Diagrama de Classes – Cantina Escolar


96

O diagrama de classes foi importante para dar uma visibilidade da

interação entre as classes do sistema, bem como subsídio para a geração do

modelo conceitual do banco de dados.

A seguir, foram elaborados os diagramas de sequência. Neste trabalho, é

apresentado o diagrama de sequência correspondente à história de venda de

produtos. Adiante nas diretrizes da sprint são apresentados os motivos pelos quais

esta funcionalidade foi selecionada para ser apresentada em detalhes neste

trabalho.

A figura 35 apresenta o diagrama da funcionalidade que permite realizar a

inclusão de vendas.

Figura 35 – Diagrama de Sequência – Incluir Venda


97


alteração de vendas.

Figura 36 – Diagrama de Sequência – Alterar Venda



consulta de vendas.

98

Figura 37 – Diagrama de Sequência – Consultar Venda



exclusão de vendas.

Figura 38 – Diagrama de Sequência – Excluir Venda


Apresentados os diagramas da UML que apoiaram a elaboração das

histórias que agora compõem o product backlog, foi verificado a priorização com o

PO para que as respectivas funcionalidades fossem desenvolvidas.

Como inicialmente será necessário realizar os cadastros básicos para que

se possam realizar as movimentações. As funcionalidades referentes aos cadastros

foram priorizadas para as primeiros sprints, de forma que ao liberá-las para a

99

proprietária da cantina, ela poderá iniciar os cadastros enquanto as demais

funcionalidades do sistema são desenvolvidas.

Antes de iniciar as sprints para desenvolvimento do sistema, o time Scrum

foi definido para que as responsabilidades fossem atribuídas.

4.1.2.3 TIME DO SCRUM

Para a definição do time Scrum, foi necessário atribuir responsabilidades

entre os autores deste trabalho. Segundo Martins (2006), a matriz de

responsabilidades é importante para evidenciar o papel de cada participante no

projeto. Como os papéis no time Scrum estão divididos entre o PO, o Scrum master

e o time de desenvolvimento, as responsabilidades foram divididas da seguinte

forma:

Aluno 1: Diego Salomão – PO

Aluno 2: Maria Luiza da Silva – Scrum máster

Aluno 1 e Aluno 2: Time de desenvolvimento A seguir, o quadro 21 apresenta a divisão de responsabilidades para o

time Scrum.

Quadro 21 – Time Scrum

Papéis

Product Owner

Scrum Master Time de

Desenvolvimento

Levantar necessidades e objetivos de negócio F,E

Gerar backlog E

Priorizar itens do backlog F,E,A

Estimar desenvolvimento P E

Executar tarefas de desenvolvimento do sistema P P E

Buscar solução de impedimentos no trabalho P E P

Manter a comunicação do time Scrum E E E

Legenda: F = fornece informações ou dados

E = Executa

R = Revisa

P = Participa ou apóia

A = Aprova


100

4.1.2.4 SPRINT

Para o desenvolvimento das funcionalidades elencadas no backlog, foram

dividas as sprints para possibilitar a entrega das funcionalidades considerando a

prioridade incremental do sistema. A funcionalidade de maior relevância para o

negócio da cantina é a de realizar vendas, porém, por ser o início do

desenvolvimento do sistema, seriam necessárias as funcionalidades que antecedem

realização de vendas, como os cadastros básicos e a entrada de produtos.

Para o desenvolvimento completo das funcionalidades levantadas, foram

necessárias 4 sprints. O quadro 22 apresenta como ficou o planejamento das

sprints, evidenciando quais funcionalidades foram desenvolvidas em cada sprint.

Quadro 22 – Planejamento das Sprints

SPRINT 1 SPRINT 2

US - 01 - Cadastro de Clientes US - 03 - Cadastro de Produtos

US - 02 - Cadastro de Fornecedores US - 04 - Recarga de Saldo em Cartão

SPRINT 3 SPRINT 4

US - 05 - Compra de Produtos US - 06 - Venda de Produtos Fonte: Elaborado pelos autores, 2016.

Neste trabalho, é apresentado o ciclo completo do Scrum para o

desenvolvimento da funcionalidade de vendas. Esta funcionalidade foi selecionada

devido a ser a de maior valor para o negócio da cantina. Para esta funcionalidade,

são apresentadas todas as tarefas, estimativas por tarefas e o avanço de cada etapa

dentro do ciclo da sprint. A duração da sprint 4 foi de 3 semanas, dividido entre os

integrantes do time de desenvolvimento.

4.1.2.5 SPRINT PLANNING

Na sprint planning o PO apresenta as funcionalidades que precisam ser

desenvolvidas para o time de desenvolvimento. O objetivo desta apresentação é que

101

todo o time de desenvolvimento tenha o mesmo entendimento do que precisa ser

feito para que a necessidade da funcionalidade seja atendida.

Para o desenvolvimento da funcionalidade de vendas, o PO apresentou a

necessidade do da propriedade da cantina por meio da história de usuário e os

critérios de aceite, juntamente com os diagramas da UML que foram produzidos,

sendo eles o de caso de uso, o de sequência e o de classes.

No início quando havia sido apresentado apenas as histórias de usuário

juntamente com os critérios de aceite, surgiram dúvidas em relação sobre o que a

funcionalidade precisaria ter e como seria a interface com o usuário, detalhes estes

que faltam nas histórias de usuário. Por meio da apresentação do diagrama de caso

de uso e os protótipos, as dúvidas foram sanadas, desta forma, o time de

desenvolvimento em comum acordo afirmaram que tinham entendido o que

precisava ser feito e que teriam subsídios suficientes para iniciar o planejamento das

tarefas que precisam ser executadas para a entrega da funcionalidade.

4.1.2.6 SPRINT BACKLOG

Com os itens do product backlog apresentados para o time de

desenvolvimento e o conhecimento sobre o que precisa ser desenvolvido, inicia-se

nesta fase a discussão do time de desenvolvimento para quebrar as histórias que

precisam ser desenvolvidas para que a história seja entregue. A seguir, são

apresentadas as histórias, bem como os esforços necessários para a entrega da

história.

4.1.2.7 TAREFAS

Para iniciar a divisão das tarefas para o desenvolvimento da

funcionalidade de vendas, expressa através da história de usuário “US – 06 – Venda

102

de Produtos”, foi verificado a estrutura já existente do projeto. Em primeiro instante

foi verificado que não será necessário realizar alterações na modelagem do banco

de dados devido a ser possível utilizar a mesma estrutura do modelo criado para

atender a funcionalidade de “Compras”. A mesma situação foi identificada com a tela

de inclusão de vendas, por ser semelhante à tela de inclusão de compras.

Partindo do princípio que as tarefas a serem realizadas na sprint se

baseiam apenas em codificação e testes, a figura 39 apresenta as tarefas que foram

elencadas. As tarefas estão apresentadas de acordo com o esforço, o que visa a

facilitar no momento de se realizar as estimativas de esforços para executar as

respectivas tarefas.

Figura 39 – Tarefas da Sprint 4


Após elencar as tarefas expostas através da figura 39, o time de

desenvolvimento realizou a classificação das tarefas de acordo com os seus

103

respectivos tamanhos, conforme apresentado na legenda. Com base nas

experiências das sprints anteriores, para a sprint 4, o time de desenvolvimento

adquiriu experiência para estimar tarefas com mais precisão do que no início do

projeto. Sendo assim, a técnica para estimativa das tarefas utilizada na sprint 4 foi a

de “tempo real”. O quadro 23 apresenta as estimativas realizadas para cada uma

das tarefas da história.

Quadro 23 – Estimativa das tarefas da história “Venda de Produtos”


A estimativa das tarefas apresentadas no quadro 23 para a história

“Venda de Produtos” vão de encontro com a estimativa da história, apresentada no

quadro 20. Estas horas vão compor as informações para a geração do gráfico de

burndown que servirão para acompanhamento da evolução da sprint.

4.1.2.8 REUNIÃO DIÁRIA

Durante o ciclo de desenvolvimento da sprint 4, as reuniões foram

imprescindíveis para o acompanhamento das atividades. Nesta fase os membros do

104

time de desenvolvimento apresentaram o andamento das atividades que estavam

executando e discutiram sobre as dificuldades que surgiram. As reuniões ocorriam

no máximo a cada dois dias, não sendo possível ser realizadas diariamente devido à

indisponibilidade dos membros do time de desenvolvimento.

Durante o desenvolvimento da sprint, a consulta à documentação da UML

foi muito importante para que pudesse atingir o objetivo da funcionalidade de forma

a entregar um produto conforme a proprietária da cantina esperava, como havia sido

demonstrado através de protótipos validações de regras.

O diagrama de sequência facilitou bastante o desenvolvimento uma vez

que o comportamento dos objetos estavam claramente evidenciados na

documentação. Poucas vezes foi necessário acionar o PO para tirar dúvidas quanto

ao comportamento que se esperava do sistema, uma vez que o diagrama de caso

de uso complementou com a visão do usuário, ou seja, exibindo como a

funcionalidade deveria se comportar na visão da proprietária da cantina.

Para o acompanhamento da sprint, foi gerado o gráfico de burndown que

possibilitou ter uma visão macro do andamento das tarefas, ou seja, se o

desenvolvimento da sprint estava no caminho certo de forma que a execução das

tarefas estavam sendo realizadas conforme o planejamento ou se haviam

dispersões que poderiam impactar no prazo de entrega da sprint. A figura 40

apresenta o andamento dia a dia das tarefas através do gráfico de burndown.

Figura 40 – Gráfico de Burndown – Sprint 4


105

4.1.2.9 REVISÃO DA SPRINT

Para o acompanhamento da sprint, foram gerados alguns gráficos de

burndown que possibilitaram ter uma visão macro do andamento das tarefas, ou

seja, se o desenvolvimento da sprint estava no caminho certo de forma que a

execução das tarefas estavam sendo realizadas conforme o planejamento ou se

haviam dispersões que poderiam impactar no prazo de entrega da sprint.

Antes da revisão da sprint, foram elencados quais eram os objetivos da

sprint para que tanto o PO quanto a proprietária da cantina pudessem validar se os

respectivos objetivos foram alcançados. Os objetivos elencados para dar a

funcionalidade como pronta foram os critérios de aceite validados incialmente com a

proprietária da cantina, conforme demonstrado no quadro 19.

A revisão da sprint iniciou-se com o time desenvolvimento apresentando

os objetivos da sprint, os itens que estavam previstos para a respectiva sprint e a

funcionalidade de vendas para o PO e a proprietária da cantina. Com base nos

critérios de aceite a funcionalidade de vendas foi validada tanto pelo PO quanto pela

proprietária da cantina.

Durante a apresentação, ambos aprovaram a funcionalidade

desenvolvida, no entanto, a proprietária da cantina sugeriu algumas melhorias para

incrementar o produto. Estas melhorias estão listadas no capítulo correspondente

aos trabalhos futuros e foram adicionados ao backlog do produto para que fossem

analisados pelo PO e priorizados de acordo com a necessidade de negócio.

4.1.2.10 RETROSPECTIVA DA SPRINT

Na reunião de retrospectiva da sprint o PO, o Scrum master e o time de

desenvolvimento discutiram os pontos positivos que devem ser mantidos para as

próximas sprints, o que pode ser melhorado e o que não deu certo.

O quadro 24 apresenta os tópicos discutidos e um consenso geral de

todos os envolvidos.

106

Quadro 24 – Retrospectiva da Sprint

Tópicos

Gestão Visual

O quadro kanban do Trello foi bom para visualização do andamento da sprint.

Burndown foi bom para visualização do andamento

A atualização do quadro kanban no Trello não era realizada em tempo real, sendo assim, o time de desenvolvimento em comum acordo decidiram atualizar durante a reunião diária.

Requisitos

Devido ao tamanho do time de desenvolvimento, todos participaram de todas as etapas desde o levantamento de requisitos, desta forma, quando surgiram dúvidas, a própria equipe solucionou as dúvidas em uma rápida conversa.

Os requisitos, regras e critérios de aceite continham informações que impactavam em atualizar outras rotinas, como estoque e saldo em cartão do cliente, portanto, ajudaram a prever os impactos durante o desenvolvimento.

Os critérios de aceite ajudaram a validar as funcionalidades necessárias para a realização de vendas.

O diagrama de classes foi bom pois possibilitou realizar uma análise da estrutura existente antes do desenvolvimento, com isso, verificou-se que não seria necessário alterar o modelo do banco e nem criar classes, uma vez que a classe que possibilita a movimentação já havia sido criada na funcionalidade de compras e poderia ser reutilizada.

O diagrama de sequência foi bom para dar uma visão do comportamento existente na funcionalidade de compras, desta forma, verificou-se que poderia ser ajustada para realizar vendas.

Os critérios de aceite também deram a visão do que a proprietária da cantina esperava receber

Planning

O planejamento para execução do sprint possibitou o mesmo entendimento da time de desenvolvimento do que deveria ser feito.

A definição de pronto ajudou a manter o foco da entrega até atingir o respectivo estado.

Durante a apresentação da funcionalidade de venda, foi identificado que a proprietária da cantina ainda tinha algumas necessidades que não haviam sido previstas no levantamento inicial. Um acompanhamento mais próximo do PO poderia ter identificado estes pontos para prever as próximas sprints e alterar escopo se necessário.

Testes

Os testes baseados nos critérios de aceite foram bons para garantir que a história pudesse ser considerada pronta para ser entregue.

107

Scrum

A utilização do Scrum foi bom devido à adoção da iteração entre os envolvidos no projeto, o que possibilitou ações rápidas e impediu interrupções no desenvolvimento.

Legenda:

Feito

Fazendo

A fazer


Nota-se através do quadro 24 que diversos pontos da sprint deram certo,

o que é fruto de amadurecimento do ciclo Scrum durante o desenvolvimento das

sprints anteriores.

108

5 DESENVOLVIMENTO DA PROPOSTA

Neste capítulo, são apresentados os módulos do sistema desenvolvido,

conforme especificado no capítulo 4. Também são apresentadas as ferramentas

utilizadas para a implementação e apoio para que o trabalho pudesse ser realizado.

5.1 FERRAMENTAS E TECNOLOGIA

Neste tópico são apresentadas as ferramentas que foram utilizadas para

a composição do trabalho incluindo as ferramentas utilizadas para implementação

do sistema, porém com menos detalhes já que não é o foco principal deste trabalho.

As ferramentas são apresentadas de forma geral através da figura 41.

Figura 41 – Ferramentas Utilizadas


A figura 41 apresenta apenas a logo ou ícone de fácil identificação por

pessoas que conhecem da área de desenvolvimento. A seguir, as respectivas

ferramentas são apresentadas com mais detalhes.

109

5.1.1 JAVA

Java é uma linguagem de programação e foi escolhida para implementar

o sistema case deste trabalho. Com esta ferramenta é possível executar e

desenvolver programas Java com dois tipos de componentes, o JDK (Java

Development Kit) que é utilizado para desenvolver e o JRE (Java Runtime

Environment) para executar. No usuário é necessário instalar somente o JRE já que

pra ele será necessário apenas executar o sistema.

5.1.2 ENTERPRISE ARCHITECT (EA)

O EA é um ambiente de modelagem que permite o desenvolvimento do

ciclo de vida de sistemas. É uma ferramenta muito utilizada no mercado de

desenvolvimento. O EA foi utilizado neste trabalho para realizar a modelagem de

diagramas da UML por possuir os recursos necessários para modelagem de

diversos diagramas e também por permitir um melhor gerenciamento dos modelos

de diagramas em um único projeto, não sendo necessário criar vários projetos para

gerenciar um mesmo produto.

5.1.3 TRELLO

Segundo Turini (2015), o Trello é baseado no sistema de kanban (em

Japonês, Kan = “visual” e ban = “cartão”). Este sistema é muito utilizado por equipes

que desenvolvem com Scrum.

O Trello possui recursos de quadros, onde é possível dividir as tarefas

dos sprints em cada um das etapas em que elas se encontram, dando uma visão

110

dinâmica e rápida quando se pretende verificar o que deve ser feito, o que está

sendo feito e o que já foi feito. Para uma utilização mais simples dos quadros com as

respectivas tarefas, o Trello oferece estes recursos de forma gratuita.

Para a organização e execução deste trabalho utilizando o Scrum, o

Trello foi escolhido por ter uma boa aceitação por equipes que desenvolvem com

Scrum e também por ser gratuita.

5.1.4 MAVEN

O Maven é uma ferramenta para gerenciamento de projetos que possui

diversas funcionalidades. Neste trabalho foi utilizada para gerenciar as

dependências do projeto Java, ou seja, quando é necessário ter uma nova

dependência no projeto é solicitado para o Maven que irá baixar automaticamente.

5.1.5 JSF

O JSF é uma forma eficiente de construir telas, implementar um controle

que é a parte relacionada às ações e a parte do modelo que armazena os dados da

tela. É um framework disponibilizado pela Oracle para desenvolvimento web em

Java e tem diversas especificações. Neste trabalho foi utilizado o Mojarra que é uma

implementação oficial da Oracle para o JSF.

5.1.6 PRIMEFACES

O JSF tem componentes padrões limitados e o Primefaces tem uma

biblioteca de componentes para aplicações JSF. Por isso o Primefaces

111

disponibilizara diversos componentes para melhorar e facilitar a aplicação deste

trabalho.

5.1.7 ECLIPSE

O Eclipse é um ambiente para desenvolver programas Java, porém é

possível utilizar para desenvolvimento em outras linguagens a partir de instalação de

plug-ins. No Eclipse é possível criar um projeto, realizar as codificações e também

verificar logs de execução.

5.1.8 MYSQL

O MySql é um sistema gerenciador de banco de dados relacional que

utiliza a linguagem SQL mantido pela Oracle e de código aberto. O MySql permite

armazenar e gerenciar conteúdo de dados em um banco de dados e é um software

de código aberto, de fácil instalação e requer pouco recurso de hardware para que

seja utilizado em aplicações de pequeno e médio porte.

5.1.9 TOMCAT

O Tomcat é um projeto da entidade Apache. É um container web que é

responsável por converter o código Java em páginas HTML para exibir todas as

telas criadas no projeto Java em um navegador e ser exibido pelo cliente.

112

5.1.10 BALSAMIQ

A ferramenta Balsamiq foi utilizada neste trabalho para o desenvolvimento

dos protótipos de tela. O principal objetivo desta ferramenta é mostrar um “rascunho”

da interface do sistema para o usuário e assim facilitar a validação com apoio de

protótipos de tela, que torna-se uma maneira mais amigável de fácil compreensão

para o usuário.

5.2 PROCESSOS DE DESENVOLVIMENTO (HISTÓRIA)

O desenvolvimento deste trabalho inicia-se tendo como foco o Scrum,

porém de acordo com pesquisas realizadas e documentadas no referencial teórico,

identificamos que existe uma espécie de “janela” entre os modelos de

desenvolvimento tradicional e ágil. Diversos autores defendem a importância de se

documentar software, por outro lado, os defensores das MA defendem maior

interação entre as pessoas para evitar “perda de tempo” em documentar.

Buscando a ponderação de ambos os lados, foi pesquisada uma forma

que pudesse ser realizado o desenvolvimento ágil, mas que documentasse o que

fosse necessário para garantir a entrega de um sistema que atendesse as

necessidades do cliente. Diante disso, ao aprofundar um pouco mais no framework

Scrum, foi verificado que por mais que defende-se que a interação entre as pessoas

seja mais importante do que documentação, o Scrum não restringe documentar.

Alguns autores mencionam o fato de se utilizar alguns diagramas da UML para

apoiar o entendimento tanto do cliente quando da equipe que utilizará o Scrum para

o desenvolvimento, desde que seja documentado apenas o que faz sentido para o

projeto, para não perder a ideia de ágil.

Buscando uma forma de verificar se seria produtivo a utilização de

diagramas da UML para apoiar um desenvolvimento Scrum, foi elaborado um projeto

utilizando ambas as abordagens, justificando o uso de cada um dos três diagramas

eleitos da UML, sendo eles o de caso de uso (para facilitar o entendimento do cliente

113

na validação, para servir de base para geração de histórias de usuário e para

garantir que todos os pontos desejados do sistema tenham sido checados), o de

classes (para apoiar a criação do modelo conceitual do banco de dados e facilitar o

entendimento em nível técnico da organização das classes do sistema) e por fim, o

diagrama de sequências (que permitiu melhor visualização do comportamento dos

objetos do início ao fim do processo, ou seja, a ordem cronológica em que cada

atividade deve ocorrer para atender a necessidade da funcionalidade).

O início do levantamento das necessidades foi realizado através de

entrevista com a proprietária da cantina (cenário case utilizado para aplicar este

trabalho). Esta entrevista inicial possibilitou explorar como eram os processos da

cantina, quem os executava e quais eram as dificuldades que eles tinham. Além

disso, notou-se que a própria proprietária da cantina que era a pessoa que tinha o

conhecimento de todos os processos da cantina, teve dificuldades para expressar o

que ela de fato precisava para solucionar algumas dificuldades, mas durante a

conversa, foi possível mapear estas necessidades para compor uma documentação

inicial que posteriormente seria compilada e serviria de subsídio para a geração da

documentação.

Com as informações obtidas nesta entrevista, foram identificados os

requisitos, regras, atores e casos de uso. Em seguida, foram elaborados os casos

de uso e posteriormente, as histórias de usuário. Nesta etapa, notou-se a facilidade

em escrever as histórias após ter escrito os casos de uso, visto que os casos de uso

utilizam uma linguagem de fácil compreensão a nível de usuário e demonstram os

diferentes cenários de uma funcionalidade, permitindo realizar uma análise

minuciosa se todos requeridos foram levados em consideração. A partir de então, os

critérios de aceitação foram facilmente descritos visto que os requisitos funcionais e

regras de negócio expressaram bem as necessidades que deveriam ser cobertas

para que a funcionalidade pudesse atender as necessidades da proprietária da

cantina.

Com a documentação inicial levantada, foi marcada uma nova entrevista

com a proprietária da cantina para que ela pudesse verificar e validar. Caso

necessitasse de algum ajuste ou tivesse faltando algo que não foi informado na

primeira entrevista, este poderia ser realizado antes de iniciar o desenvolvimento. A

documentação (requisitos, regras, casos de uso, histórias e critérios de aceitação)

foi apresentada e, como havia uma documentação mais palpável, ela pôde visualizar

114

os protótipos e ter uma melhor noção de como seria o sistema. Essa visualização

permitiu que ela validasse a documentação com mais segurança de que de fato a

necessidade dela havia sido compreendida, o que permitiu então seguir para

próxima etapa do projeto.

Com apenas a documentação inicial que foi levantada, faltava ainda

detalhes técnicos para que o time de desenvolvimento melhor compreendesse como

o sistema deveria se comportar. A partir de então, foram elaborados os diagramas

de classes e de sequência, os quais permitiram uma melhor visibilidade técnica da

arquitetura e comportamento do sistema.

Com uma documentação mais enxuta, buscando demonstrar apenas o

que fosse essencial, foi realizado a seguir a lista do Product Backlog para então

iniciar as sprints do Scrum.

Na primeira reunião do ciclo Scrum, a Sprint Planning, o PO apresentou

as histórias, contextualizou o time de desenvolvimento e apresentou os documentos

elaborados anteriormente com os diagramas da UML. Os desenvolvedores tiveram

mais facilidade para entender cada funcionalidade a ser realizada já que o

documento é bastante detalhado tanto a nível de usuário, quanto a nível técnico.

Assim ficou mais claro quais funcionalidades caberiam em uma determinada sprint e

facilitou a estimativa de o tempo de execução de cada tarefa.

O próximo passo foi desenvolver as tarefas escolhidas para a sprint. O

desenvolvimento seguiu sem grandes problemas, visto que trata-se de um sistema

simples, com regras não tão complexas e que a documentação produzida supriu as

eventuais dúvidas que poderiam vir a surgir. Todas as sprints foram finalizadas no

prazo determinado na Sprint Planning e acredita-se que isso se deve ao bom

planejamento das sprints e aos documentos da UML que auxiliaram os

desenvolvedores em diversos momentos. Ao longo do desenvolvimento foram feitas

as reuniões diárias que foram muito importantes, pois ajudaram os desenvolvedores

a prosseguir e se manterem atualizados na implementação do sistema e até apoiar

um ao outro para a entrega das tarefas dentro do prazo.

Todas as reuniões da Revisão da Sprint foram bastante produtivas, pois o

sistema era apresentado para a proprietária da cantina e a equipe, com isso surgiam

debates em relação ao funcionamento do sistema e consequentemente novas

sugestões de melhorias futuras. Além disso, este tipo de reunião foi importante para

115

o time de desenvolvimento verificar o resultado do planejamento da sprint e receber

feedbacks.

Por fim, a última fase do ciclo da sprint, foi a reunião de retrospectiva da

sprint em que a equipe discutiu os pontos fortes e fracos que aconteceram ao longo

da sprint corrente. Foi uma reunião muito importante, pois contribuiu com as sprints

sucessoras de tópicos que deveriam ser melhorados ou simplesmente

descontinuados, pois não estavam funcionando.

O Scrum é umas das metodologias ágeis mais usadas atualmente pelas

empresas como já foi relatado nos tópicos anteriores, e ao longo deste trabalho foi

possível perceber o porquê disso. Porque é simples, eficaz e principalmente, é ágil.

O Scrum permite entregas frequentes ao usuário e por isso aumenta satisfação do

mesmo, já que é possível utilizar o sistema enquanto ainda está em

desenvolvimento e isso também leva a receber feedbacks frequentes do cliente para

saber se o projeto está no caminho certo ou se precisa ser interrompido e ajustado.

É possível também ter uma transparência durante todo o desenvolvimento em que a

equipe consegue acompanhar cada passo do ciclo da sprint e verificar seu

progresso. Cada etapa da sprint orienta a equipe no que deve ser feito naquele

momento e é importante segui-lo, pois trará uma grande produtividade no projeto,

resultando em uma equipe mais motivada, melhoria contínua no processo e

correção de problemas.

Durante todo esse processo de desenvolvimento foi possível perceber o

quanto os documentos da UML ajudou a equipe no desenvolvimento do sistema. Foi

muito útil no início, pois permitiu uma visão ampla e um melhor entendimento do

produto por parte do usuário e do time de desenvolvimento. A documentação da

UML permitiu economizar tempo para verificar regras e comportamentos que o

sistema deveria ter, uma vez que a indisponibilidade do PO no momento do

desenvolvimento poderia causar atrasos. A documentação da UML continuará sendo

útil também após a finalização do sistema, pois será mais fácil realizar manutenções

e realizar repasses para novos integrantes da equipe por possuir detalhes técnicos e

de negócio.

116

5.3 APRESENTAÇÃO DO SISTEMA

Neste tópico é apresentado as principais funcionalidades do sistema

implementado neste trabalho.

Na entrevista com o usuário, foi relatado que a maior necessidade era ter

um mecanismo pudesse inserir créditos em uma conta do cliente da cantina de

forma que ele fosse consumindo este crédito ao ir realizando compras de produtos

na cantina.

A figura 42 apresenta a interface da tela de inserir créditos na conta de

um cliente da cantina. Como cada aluno do colégio possui sua matrícula, ela foi

aproveitada neste sistema para identificar cada aluno. Caso seja necessário

cadastrar um colaborador da escola ou até mesmo um cliente externo, o usuário

poderá criar uma “matrícula” para estes clientes. Para inserir os créditos, é

necessário que o usuário insira o cliente digitando a matrícula ou o nome, em

seguida, basta informar o tipo de pagamento e por fim o valor dos créditos que são

inseridos.

Figura 42 – Interface da tela que permite inserir créditos


A segunda prioridade relatada pelo o usuário foi o controle de vendas que

permita registrar as compras de cada cliente, além de controlar a saída de produtos

do estoque. O usuário deixou claro que a funcionalidade precisaria ser rápida, pois o

117

maior movimento de vendas ocorre no intervalo de recreio dos alunos, o qual é um

curto espaço de tempo para atender muitos clientes. Diante desta necessidade, foi

pensado em uma forma que a venda pudesse ser realizada rapidamente utilizando

apenas o teclado para agilizar a venda. Desta forma, a navegação de confirmação

de uma informação ficou definida através da tecla “enter”, que ao ser pressionada, o

sistema passa para foco para o próximo campo requerido, além de uma tecla de

atalho “F2” para finalizar as vendas, ambas as funcionalidades descartam a

necessidade de se utilizar o mouse, tornando o trabalho do usuário mais prático e

ágil para atender os seus clientes.

A figura 43 apresenta a interface da tela de vendas. O usuário poderá

inserir um cliente por meio da matrícula ou nome, porém se o usuário não utilizar os

créditos ou até mesmo se não possuir créditos, não será necessário o seu

respectivo preenchimento. Logo abaixo do campo do preenchimento do cliente é

exibido o saldo disponível para o mesmo e, a medida que é incluído produtos no

pedido, este saldo é descontado, com isso o usuário poderá monitorar o saldo do

cliente e avisá-lo quando estiver acabando ou não possuir mais saldo disponível

para a compra de produtos.

Para o preenchimento dos produtos o usuário poderá utilizar o código de

barras ou a descrição, e poderão ser adicionados quantos produtos forem

necessários. À medida que os produtos são adicionados no pedido, o subtotal e o

total do pedido são atualizados.

Figura 43 – Interface da tela que permite a realização de vendas


118

Quando terminar a inserção de produtos no pedido e desejar finalizar a

venda, o usuário irá clicar no botão de “Finalizar” ou acioná-lo através da tecla de

atalho “F2”, em seguida, o sistema exibirá uma janela de diálogo que mostrará o

valor total do pedido e solicitará a forma de pagamento que será realizada utilizada o

cliente, conforme a figura 44 a seguir.

Figura 44 – Interface da tela que permite a finalização de vendas


O usuário relatou que gostaria de ter um controle de estoque. Para isso,

seria necessário uma funcionalidade que o permitisse realizar a entrada de produtos.

Foi criada a tela de compras que possibilita ao usuário registrar os produtos que

estão entrando no estoque da cantina.

A figura 45 apresenta a tela de compras. É necessário que o usuário

preencha o fornecedor, a data da compra, a forma de pagamento e os produtos. O

número de nota fiscal e as observações não são campos obrigatórios. A inclusão de

produtos nesta tela é semelhante com a inserção de produtos da tela de vendas, em

que o usuário poderá inserir quantos produtos forem necessários e à medida que

são adicionados, o subtotal e o total são atualizados.

119

Figura 45 – Interface da tela que permite realizar compras


Quando a compra for finalizada, as quantidades dos produtos em estoque

são atualizadas, assim como também é feito nas vendas, permitindo um controle

efetivo dos produtos em estoque.

5.4 CONSIDERAÇÕES FINAIS

Durante o desenvolvimento deste trabalho, ao verificar os artefatos de

forma separada (histórias, critérios de aceite, casos de uso, diagrama de

sequências, diagrama de classes), os autores notaram que faltariam informações

para dar visibilidade do que seria necessário para realizar o desenvolvimento de um

software para a cantina escolar. Ao verificar os artefatos juntos, nota-se que há uma

maior transparência que melhor elucida o que precisa ser feito tanto do ponto de

vista do usuário quanto do ponto de vista técnico.

Ao utilizar o experimento proposto como objetivo deste trabalho, que é a

utilização do Scrum com diagramas da UML como apoio para a elaboração de

documentação para produção de software, os autores puderam verificar que cada

120

um dos artefatos produzidos contribuíram muito nivelar o entendimento de todos os

envolvidos no projeto.

Os requisitos e regras de negócio forneceram insumos para a criação dos

casos de uso, que por sua vez possibilitaram verificar que todos os pontos

necessários para atender as necessidades da proprietária da cantina haviam sido

elencados. Em seguida, as histórias de usuário melhor descreveram o que a

proprietária da cantina de fato gostaria de realizar com o sistema e, os critérios de

aceite complementaram o contexto de cada uma das histórias.

Os diagramas de sequência deram uma visibilidade para o time de

desenvolvimento de como deveria ser o comportamento do sistema em cada

funcionalidade, garantindo uma boa visibilidade e planejamento de arquitetura do

sistema.

O diagrama de classes permitiu uma visão ampla de como todas as

classes do sistema interagiam entre si, além de auxiliar na criação do modelo

relacional de dados.

Os autores acreditam que toda a documentação produzida, auxiliará no

planejamento de desenvolvimento de novas funcionalidades para o sistema, além de

oferecer subsídios para novas pessoas que possam vir a dar manutenção no

sistema. Os diagramas da UML utilizados para apoiar o desenvolvimento conduzido

pelo framework Scrum foram bem aceitos devido a não possuírem grande carga de

documentação e que permitiram dar uma boa visibilidade do que precisaria ser

desenvolvido e atendido.

Ao final de cada sprint prevista no Scrum, as histórias desenvolvidas eram

apresentadas à proprietária da cantina, permitindo validar se a documentação

produzida tinha obtido resultado satisfatório, considerando se as funcionalidades

esperadas por ela haviam sido entregues conforme era a necessidade.

121

6 CONCLUSÕES E TRABALHOS FUTUROS

Este capítulo apresenta as conclusões finais deste trabalho, baseado no

objetivo proposto. Serão apresentados os resultados obtidos na criação do trabalho

e os trabalhos futuros.

6.1 CONCLUSÂO

Este trabalho apresentou conceitos sobre a engenharia de software,

modelos tradicionais e ágeis de desenvolvimento de software e a utilização de

documentação da UML para apoiar o desenvolvimento de software conduzido pelo

framework Scrum.

A pesquisa realizada sobre os modelos de desenvolvimento ágeis levou

os autores deste trabalho a aprofundarem os estudos sobre o Scrum por ser um

modelo muito utilizado no mercado e que diversos autores da literatura de

engenharia de software defendem a utilização de uma documentação para o

desenvolvimento de software. Na literatura utilizada como referência para a

produção deste trabalho, diversos autores mencionam que o Scrum não impõe

restrições quanto a documentações, porém recomendam que se optar por

documentar, que seja documentado apenas o que de fato é necessário. Alguns

experimentos realizados por autores da literatura sugerem diagramas certos da UML

a serem utilizados para apoiar o desenvolvimento conduzido pelo Scrum, sendo eles

o diagrama de casos de uso, o diagrama de classes e o diagrama de sequências.

A partir do embasamento teórico levantado para dar início ao

desenvolvimento deste trabalho, os autores elaboraram um planejamento para o

desenvolvimento de um software utilizando como case o cenário de uma cantina

escolar. Foram elaborados os diagramas da UML (diagrama de casos de uso,

diagrama de classes, diagrama de sequências), bem como as histórias de usuário e

critérios de aceite, previstas pelo Scrum.

122

Os diagramas de casos de uso juntamente com os requisitos, regras de

negócio, protótipos de tela, histórias de usuário e critérios de aceite, deram melhor

visibilidade para a proprietária da cantina do que cada funcionalidade iria conter e,

de que forma estas funcionalidades iriam se comportar, dando maior segurança de

que os autores deste trabalho tiveram o entendimento do que ela necessitaria. Além

disso, ao final do desenvolvimento das histórias, os autores puderam validar os

critérios de aceite antes de apresentar o incremento do sistema para a proprietária

da cantina.

O diagrama de classes permitiu realizar um melhor planejamento da

arquitetura do sistema e do modelo de dados, sendo que a alteração da arquitetura

poderia ter um alto custo caso não houvesse um bom planejamento. Futuramente, o

diagrama de classes poderá ser um ótimo insumo para que outras pessoas possam

dar manutenção no sistema, uma vez que expande a visão das classes que

compõem o sistema. Outro diagrama tão importante quanto o de classes foi o

diagrama de sequências, pois permitiu definir o ciclo de vida dos objetos, ou seja, a

ordem cronológica que o objeto deveria percorrer para que o objetivo da

funcionalidade pudesse ser concluído.

Com esta documentação, foi realizado o planejamento de versões a

serem entregues e o que iria conter em cada entrega. A partir de então, deu-se início

ao desenvolvimento do software.

Durante a fase de desenvolvimento, os autores deste trabalho não

tiveram problemas de entendimento do que precisaria ser desenvolvido, uma vez

que os diagramas da UML, juntamente com as histórias de usuário e critérios de

aceite permitiram dar uma ótima visibilidade em linguagem natural e técnica tanto

para os autores quanto para a proprietária da cantina.

O Scrum facilitou muito a comunicação e alinhamento durante o

desenvolvimento do software, uma vez que as reuniões diárias e o gráfico de

burndown mantiveram os autores atualizados da situação das tarefas o que permitiu

um auxílio mútuo para que o prazo da sprint fosse cumprido. Além disso, as

reuniões de retrospectiva foram fundamentais para dar visibilidade do que estava

dando certo, o que poderia ser melhorado e o que poderia ser feito para melhorar na

próxima sprint.

Em linhas gerais, este trabalho atingiu os objetivos propostos, uma vez

que demonstrou a eficácia da utilização de diagramas da UML para apoiar o

123

desenvolvimento de software conduzido pelo framework Scrum no cenário utilizado.

A documentação proposta foi bem aceita pela proprietária da cantina e também

pelos autores do trabalho, que apesar de terem participado desde o início do

levantamento de informações da proprietária da cantina, buscaram manter o foco na

documentação que foi produzida.

6.2 TRABALHOS FUTUROS

Para os possíveis trabalhos futuros em relação ao objetivo deste trabalho,

pode ser analisada a criação de novas funcionalidades e o aperfeiçoamento das

funcionalidades já existentes, verificando se a documentação produzida inicialmente

auxiliará na manutenção do sistema de forma ágil. O quanto uma documentação

mais enxuta pode auxiliar no entendimento da funcionalidade e propor uma evolução

de forma ágil.

Dentre as funcionalidades desenvolvidas, os relatórios não foram

contemplados inicialmente, visto que estes ficaram para um segundo momento.

Pode ser que para o desenvolvimento de relatórios, a produção dos artefatos

mencionados e utilizados neste trabalho não sejam tão eficazes, dando um sentido

de não ser ágil pelo fato de documentar algo que não necessariamente precisaria

ser. Neste sentido, deve-se pensar em uma forma de documentar relatórios para

que não torne a documentação uma atividade que requer grande esforço para pouco

resultado.

As funcionalidades desenvolvidas neste trabalho são de baixa

complexidade, visto que não possuem grande quantidade de regras e nem

processam grande quantidade de informações, resumindo, não trata-se de uma

aplicação robusta. É interessante avaliar se a documentação produzida neste

trabalho seria suficiente para atender demandas de funcionalidades que executam

altos níveis de processamento. Pode ser que seja necessário utilizar outros

diagramas que possibilitam realizar uma melhor análise de arquitetura.

124

REFERÊNCIAS AUDY, Jorge. Scrum 360: Um guia completo e prático de agilidade. São Paulo : Casa do Código, 2015. BOND, Martin. HAYWOOD, Dan. LAW, Debbie. LONGSHAW, Andy. ROXBURGH, Peter. Aprenda J2EE: Com EJB, JSP, Servlets, JNDI, JDBC e XML. São Paulo : Pearson Prentice Hall, 2003. BOOCH, Grady. RUMBAUGH, James. JACOBSON, Ivar. UML – Guia do Usuário: O mais avançado tutorial sobre Unified Modeling Language (UML), elaborado pelos próprios criadores da linguagem. 1ª ed. Rio de Janeiro : Editora Campus LTDA, 2000. FOGGETTI, Cristiano. Gestão Ágil de Projetos. São Paulo : Pearson, 2014. FOWLER, Martin. UML Essencial: Um breve guia para modelagem-padrão de modelagem de objetos. 3ª ed. Porto Alegre : Bookman, 2004. GIL, Antonio Carlos. Como Elaborar um Projeto de Pesquisa. 4ª ed. São Paulo : Editora Atlas S.A, 2002. GOMES, André Faria. Agile: Desenvolvimento de software com entregas frequentes e foco no valor de negócio. São Paulo : Casa do Código, 2013. GUEDES, Gilleanes T.a.. UML 2: Uma abordagem prática. 2ª. ed. São Paulo : Novatec, 2011. HIRAMA, Kechi. Engenharia de Software: qualidade e produtividade com tecnologia. Rio de Janeiro: Elsevier, 2011. IBM. Regras de Negócio. Disponível em < http://www.ibm.com/support/knowledgecenter/SSFPJS_8.5.6/com.ibm.wbpm.wid.main.doc/prodoverview/topics/cbusrules.html?lang=pt>. Acesso em 05 mai. 2016. KERR, Eduardo Santos. Gerenciamento de Requisitos. São Paulo : Pearson, 2015 KRUCHTEN, Fhilippe. Introdução ao RUP – Rational Unified Process. 1ª ed. Rio de Janeiro : Ciência Moderna LTDA, 2003. LEE, Richard C. TEPFENHART, William M. UML e C++: Guia Prático de Desenvolvimento Orientado a Objeto. 1ª ed. São Paulo : MAKRON Books, 2001. MACHADO, Felipe Nery. Análise e Gestão de Requisitos de Software: onde nascem os sistemas. São Paulo : Érica, 2011. MARIOTTI, Flavio S. Requisitos para agilidade no desenvolvimento de software. Engenharia de Software Magazine. Rio de Janeiro, a. 4, n. 44, p. 6 – 12, 2012.

125

MARTINS, José Carlos Cordeiro. Gerenciando Projetos de Desenvolvimento de Software com PMI, RUP e UML. 3. ed. ver. e amp. - Rio de Janeiro : BRASPORT, 2006. MATOS, Maurício M. O., ALVES, Nicolli Souza Rios, SPÍNOLA, Rodrigo Oliveira. Requisito Ágil vs Tradicional. Engenharia de Software Magazine. Rio de Janeiro, n. 66, p. 6 – 13, 2014. MEDEIROS, Ernani. Desenvolvendo software com UML 2.0: Definitivo. São Paulo : Pearson Prentice Hall, 2004. MENDES, Antônio. Custo de Software: planejamento e gestão. 1ª ed. Rio de Janeiro : Elsevier, 2014. NETO, Roberto Capra. Linha de Código: Regras de Negócio – Por que você deveria se importar com isso? Disponível em: <

http://www.linhadecodigo.com.br/artigo/3205/regras-de-negocio-por-que-voce-deveria-se-importar-com-isso.aspx>. Acesso em: 05 mai. 2016. NUNES, Mauro; O'NEILL, Henrique. Fundamental de UML: Abordagem simples e prática, tudo o que precisa para compreender e construir os principais diagramas. 2ª. ed. São Paulo : Fca, 2002. PAULA FILHO, Wilson de Pádua. Engenharia de Software: fundamentos, métodos e padrões. São Paulo: Ltc, 2000. 260 p. PFLEEGER, Shari Lawrence. Engenharia de Software: Teoria e Prática. 2ª ed. São Paulo : Pearson Prentice Hall, 2004. PRESSMAN, Roger S. Engenharia de Software. 1ª ed. São Paulo : MAKRON Books, 1995. PRESSMAN, Roger S. Engenharia de Software. 7ª ed. São Paulo : AMGH Editora LTDA, 2011. PRIKLADNICKI, Rafael. WILLI, Renato. MILANI, Fabiano. Colaboradores. Métodos Ágeis Para Desenvolvimento De Software. Porto Alegre : Bookman, 2014. RUBIN, Kenneth S. Essencial Scrum: A Practical Guide To The Most Popular Agile Process. Arbor : Pearson , 2013. SABBAGH, Rafael. Scrum: Gestão ágil para projetos de sucesso. São Paulo : Casa do Código, 2013. SANTANA, Fábio Pereira. Comparando métodos de desenvolvimento Cascata, RUP e SCRUM. Engenharia de Softwares Magazine. Rio de Janeiro, a. 5, n. 60, p.16 - 20. 2013. SILVA, Edna Lúcia da. MENEZES, Estera Muszkat. Metodologia da Pesquisa e Elaboração de Dissertação. 4 ed. rev. atual. Florianópolis : UFSC, 2005.

126

SILVA, Bruno Carreira Coutinho. Trabalhando com Scrum e UML. Engenharia de Softwares Magazine. Rio de Janeiro, a. 5, n. 56, p.11 – 16, 2012. SOMMERVILLE, Ian. Engenharia de Software. 8ª ed. São Paulo : Pearson Addison-Wesley, 2007. SUTHERLAND, Jeff. Scrum: a arte de fazer o dobro do trabalho na metade do tempo. São Paulo : Leya, 2014. TURINI, Rodrigo. Caelum: Encontrando melhores formas de trabalhar com o Trello. 2015. Disponível em <http://blog.caelum.com.br/encontrando-melhores-formas-trabalhar-com-o-trello/>. Acesso em: 09 mai. 2016.

127

APÊNDICES

128

APÊNDICE A – Cronograma

ATIVIDADES DEZ - FEV. MAR. ABR. MAI. JUN.

Elaborar questionário de levantamento de requisitos X

Agendar visita na empresa que será utilizada em aplicação prática

X

Visitar empresa, conhecer as necessidades, estrutura atual e levantar requisitos

X

Realizar análise de viabilidade X

Especificar requisitos e prototipar X X X X

Agendar nova visita para validar requisitos X

Ajustar especificação de requisitos X X

Validar ajustes com a proprietária da cantina X

Interação com orientador

Implementar funcionalidades X X X X X

Testar o sistema X X X

Agendar treinamento e homologação com a proprietária da cantina

X

Realizar treinamento e homologação do sistema X

Entregar sistema para a proprietária da cantina X

Coleta de dados X X X X X X X X

Análise dos dados X

Fechamento X X

Revisão da redação final X

Digitação do trabalho

X X X X

Revisão e correção da redação final X X

Entrega do Trabalho de Conclusão X

Defesa perante a banca X

Correções levantadas pela banca X X

Entrega da versão final X

129

Documents

UNIVERSIDADE DO SUL DE SANTA CATARINA DIEGO SALOMÃO …