universidade do sul de santa catarina diego salomÃo …
Post on 27-Apr-2022
2 Views
Preview:
TRANSCRIPT
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
MARIA LUIZA DA SILVA
UM ESTUDO DE CASO UTILIZANDO FRAMEWORK SCRUM COM ARTEFATOS
UML PARA APOIO AO DESENVOLVIMENTO DE SOFTWARE
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
MARIA LUIZA DA SILVA
UM ESTUDO DE CASO UTILIZANDO FRAMEWORK SCRUM COM ARTEFATOS
UML PARA APOIO AO DESENVOLVIMENTO DE SOFTWARE
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.
Universidade do Sul de Santa Catarina
______________________________________________________ Prof. Flávio Ceci, Dr.
Universidade do Sul de Santa Catarina
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
Fonte: MACHADO (2011, p. 216).
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
Fonte: SABBAGH (2013, p. 113).
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
Fonte: SABBAGH (2013, p. 135).
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.
Fonte: SABBAGH (2013, p. 142).
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
Fonte: SABBAGH (2013, p. 149).
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
Fonte: MACHADO (2011, p. 209).
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
Fonte: SABBAGH (2013, p. 190).
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
Fonte: SABBAGH (2013, p. 156).
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
Fonte: BOOCH et al. (2000, p. 33).
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
Fonte: BOOCH et al. (2000, p. 105).
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
Fonte: GUEDES (2011, p. 62).
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
Fonte: GUEDES (2011, p. 65).
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
Fonte: GUEDES (2011, p. 59).
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
Fonte: BOOCH et al. (2000, p. 232).
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
Fonte: BOOCH et al. (2000, p. 245).
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
Fonte: Elaborado pelos autores, 2015.
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.
Fonte: Elaborado pelos autores, 2016.
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.
Fonte: Elaborado pelos autores, 2016.
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.
Fonte: Elaborado pelos autores, 2016.
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
Fonte: Elaborado pelos autores, 2016.
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.
Fluxo Alternativo [FA2]
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.
Fluxo Alternativo [FA3]
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
Fonte: Elaborado pelos autores, 2016.
O quadro 10 apresenta o caso de uso referente ao cadastro de clientes no
sistema, descrevendo as condições e os fluxos principal e alternativos.
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.
Requisitos Funcionais:
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.
4. O sistema valida as informações do cadastro. [RN002.01] [RN002.03]
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
Fonte: Elaborado pelos autores, 2016.
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
Pré-condições: Não se aplica
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
Requisitos Funcionais:
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.
6. O sistema valida as informações do cadastro. [RN003.01] [RN003.03]
7. O sistema inclui o fornecedor no sistema.
Fluxo Alternativo [FA1]
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.
Fluxo Alternativo [FA3]
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
Fonte: Elaborado pelos autores, 2016.
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.
Pré-condições: Não se aplica
Pós-condições: POS001 - Saldo de crédito inserido e disponível para o cliente
Requisitos Funcionais:
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
Fonte: Elaborado pelos autores, 2016.
O quadro 13 apresenta o caso de uso referente ao registro de compras no
sistema, descrevendo as condições e os fluxos principal e alternativos.
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.
Requisitos Funcionais:
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
6. O sistema valida as informações. [RN005.01] [RN005.02] [RN005.03] [RN005.04]
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
Fonte: Elaborado pelos autores, 2016.
O quadro 14, apresenta o caso de uso referente à venda de produtos no
sistema, descrevendo as condições e os fluxos principal e alternativos.
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
Requisitos Funcionais:
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]
6. O sistema valida as informações. [RN006.01] [RN006.07] [RN006.08] [RN006.09]
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]
4. O sistema valida as informações. [RN006.01] [RN006.07] [RN006.08] [RN006.09]
5. O sistema salva os dados da compra.
Fluxo Alternativo [FA2]
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.
Fluxo Alternativo [FA3]
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
Fonte: Elaborado pelos autores, 2016.
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
Fonte: Elaborado pelos autores, 2016.
O quadro 16 apresenta a história de usuário referente ao cadastro de
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.
Critérios de aceite:
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.
Prioridade: 2 – Horas: 60
Fonte: Elaborado pelos autores, 2016.
O quadro 17 apresenta a história de usuário referente ao cadastro de
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.
Critérios de aceite:
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.
Prioridade: 3 – Horas: 80
Fonte: Elaborado pelos autores, 2016.
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.
Critérios de aceite:
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;
Prioridade: 4 – Horas: 20
Fonte: Elaborado pelos autores, 2016.
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.
Critérios de aceite:
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.
Prioridade: 5 – Horas: 140
Fonte: Elaborado pelos autores, 2016.
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.
Critérios de aceite:
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
Fonte: Elaborado pelos autores, 2016.
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
Fonte: Elaborado pelos autores, 2016.
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
Fonte: Elaborado pelos autores, 2016.
97
A figura 36 apresenta o diagrama da funcionalidade que permite realizar a
alteração de vendas.
Figura 36 – Diagrama de Sequência – Alterar Venda
Fonte: Elaborado pelos autores, 2016.
A figura 37 apresenta o diagrama da funcionalidade que permite realizar a
consulta de vendas.
98
Figura 37 – Diagrama de Sequência – Consultar Venda
Fonte: Elaborado pelos autores, 2016.
A figura 38 apresenta o diagrama da funcionalidade que permite realizar a
exclusão de vendas.
Figura 38 – Diagrama de Sequência – Excluir Venda
Fonte: Elaborado pelos autores, 2016.
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
Fonte: Elaborado pelos autores, 2016.
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
Fonte: Elaborado pelos autores, 2015.
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”
Fonte: Elaborado pelos autores, 2016.
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
Fonte: Elaborado pelos autores, 2016.
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
Fonte: Elaborado pelos autores, 2016.
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
Fonte: Elaborado pelos autores, 2016.
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
Fonte: Elaborado pelos autores, 2016.
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
Fonte: Elaborado pelos autores, 2016.
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
Fonte: Elaborado pelos autores, 2016.
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
Fonte: Elaborado pelos autores, 2016.
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
top related