| 1 | \chapter{Metodologias}
|
| 2 |
|
| 3 | % TODO: Rewrite this thing, Jesus
|
| 4 | De forma a prosseguir e conseguir viabilizar construir um software com
|
| 5 | qualidade, é necessário adotar algumas metodologias para fundamentar a ideia do
|
| 6 | projeto em si, como primeiro passo. Isso ajuda tanto em como priorizar
|
| 7 | funcionalidades quanto no aspecto de conseguir gerar dados para construir o
|
| 8 | mesmo de forma que entregue o que de fato é necessário para utilização do
|
| 9 | mesmo. Com esses elementos em mente, esse capítulo se debruça tanto na
|
| 10 | abordagem da metodologia de pesquisa do projeto quanto detalhar o método de
|
| 11 | desenvolvimento de software utilizado no projeto.
|
| 12 |
|
| 13 | \section{Metodologia de Desenvolvimento de Software}
|
| 14 |
|
| 15 | Existem diversos métodos de desenvolvimento, cada um com seus respectivos prós
|
| 16 | e contras. Todos tentam, de sua forma, responder à necessidade de dar forma ao
|
| 17 | processo de desenvolvimento, de forma que ele tente fluir e assegurar que os
|
| 18 | requisitos daquele software sejam atendidos, que os membros envolvidos no
|
| 19 | processo, tanto de desenvolvimento em si, quanto dos atores envolvidos e
|
| 20 | interessados no sistema tenham seus anseios respondidos de forma minimamente
|
| 21 | transparente e satisfatória.
|
| 22 |
|
| 23 | Além disso, a escolha de uma boa metodologia, adequada para as necessidades do
|
| 24 | sistema, permite que os prazos de entrega sejam melhor controlados e mais
|
| 25 | precisos \cite{pressman:2021}, minimizando a ocorrência de falhas e gestão do
|
| 26 | tempo.
|
| 27 |
|
| 28 | As ideias fundamentais que norteiam esse projeto são baseadas em dois conceitos
|
| 29 | chaves da engenharia de software: desenvolvimento incremental e desenvolvimento
|
| 30 | de software ágil. O IEEE define que a engenharia de software é:
|
| 31 |
|
| 32 | \begin{quote}
|
| 33 | Engenharia de software: A aplicação de uma abordagem sistemática, disciplinada
|
| 34 | e quantificável no desenvolvimento, na operação e na manutenção de software;
|
| 35 | isto é, a aplicação de engenharia ao software. (INSTITUTE OF ELECTRICAL AND
|
| 36 | ELECTRONICS ENGINEERS, 1990, p. 421, tradução do autor)
|
| 37 | \end{quote}
|
| 38 |
|
| 39 | Portanto, a engenharia de software propõe estruturar a criação de software de
|
| 40 | forma mais organizada e eficiente. Pressman vai destacar os modelos de
|
| 41 | desenvolvimento de software sequenciais e incrementais que moldam boa parte das
|
| 42 | práticas de engenharia de software nas últimas décadas.
|
| 43 |
|
| 44 | O modelo em cascata (waterfall) é um modelo sequencial, dos mais tradicionais e
|
| 45 | antigos a existirem, cujo qual necessita que cada etapa – levantamento de
|
| 46 | requisitos, projeto, implementação, testes – estejam concluídos antes da
|
| 47 | próxima etapa começar. Embora forneça uma estrutura rígida e lógica, é
|
| 48 | frequentemente criticado pela baixa adaptabilidade em relação às mudanças
|
| 49 | durante o processo de desenvolvimento.
|
| 50 |
|
| 51 | Em outro âmbito, o modelo incremental, trabalha com a premissa de um
|
| 52 | desenvolvimento feito em pequenas partes, que se agrupam para totalizar o
|
| 53 | projeto em si, trabalhando com a concepção de incrementos funcionais, cujo qual
|
| 54 | permite maior flexibilidade com as mudanças no processo. Também ajuda a iterar
|
| 55 | rapidamente em cima do desenvolvimento do sistema, criando um produto mínimo
|
| 56 | viável que possa preencher a proposta usando o mínimo de tempo, reduzindo as
|
| 57 | funcionalidades ao seu estado basal. Essa metodologia também ajuda a reduzir
|
| 58 | custos e riscos, já que necessita que as funcionalidades estejam em seu estado
|
| 59 | mais reduzido, porém funcionais.
|
| 60 |
|
| 61 | Outros modelos tradicionais citados por Pressman incluem o modelo de
|
| 62 | prototipação e o modelo em espiral, o primeiro trabalhando na ideia de
|
| 63 | elaboração de protótipos pequenos que validem a hipótese, e depois passe para a
|
| 64 | implementação final; e o modelo em espiral une a natureza iterativa da
|
| 65 | prototipação com os aspectos sistemáticos do modelo em cascata, sendo que acaba
|
| 66 | por ser um modelo geralmente usado para desenvolvimento de aplicações em larga
|
| 67 | escala, visto que oferece mais segurança ao processo de desenvolvimento. Apesar
|
| 68 | da influência histórica, tais modelos acabam por serem um tanto quanto
|
| 69 | burocráticos e em um projeto com um escopo de equipe reduzida e onde necessita
|
| 70 | um nível de flexibilidade maior, como este, portanto, uma adoção de uma
|
| 71 | metodologia mais flexível se faz necessária.
|
| 72 |
|
| 73 | Pressman, comenta que, por meados de 2001, um grupo de desenvolvedores
|
| 74 | deflagrou o “Manifesto Ágil”, um documento desenhando uma nova metodologia de
|
| 75 | desenvolvimento, destacando a satisfação dos patrocinadores do sistema,
|
| 76 | entregas mais rápidas, flexibilidade durante o desenvolvimento do software de
|
| 77 | forma a evitar que os desenvolvedores ficaram empacados e reduzisse rigidez. Os
|
| 78 | principais destaques da abordagem ágil é a proposta de que a mesma não é
|
| 79 | escrita em pedra, ou seja, permite flexibilidade no como aplicá-la. Nesse
|
| 80 | cenário, existem algumas abordagens sobre ela, como o Kanban e o Scrum, que dão
|
| 81 | um pouco mais de forma a ideia apresentada com o desenvolvimento ágil o que
|
| 82 | casa relativamente bem com o modelo de desenvolvimento incremental.
|
| 83 |
|
| 84 | Com base nesse panorama, o presente trabalho adota uma abordagem baseada na
|
| 85 | filosofia ágil, estruturada por meio da utilização de um quadro de Kanban,
|
| 86 | adaptado à realidade de um desenvolvimento individual. Diferentemente de
|
| 87 | modelos tradicionais que envolvem um maior formalismo, o Kanban permite
|
| 88 | visualizar e gerenciar o fluxo de trabalho de forma contínua, com foco na
|
| 89 | entrega incremental de funcionalidades. Por ser um método não prescritivo, o
|
| 90 | Kanban oferece liberdade para que as tarefas possam ser priorizadas, ajustadas
|
| 91 | ou redefinidas conforme a evolução do desenvolvimento, característica
|
| 92 | especialmente útil quando há apenas um desenvolvedor responsável por todas as
|
| 93 | etapas do processo. Vale ressaltar também, que a metodologia adotada acaba por
|
| 94 | ajudar a manter o fluxo de desenvolvimento contínuo sem sobrecarga, já que
|
| 95 | limita a quantidade de tarefas em progresso, gerando um movimento de maior
|
| 96 | produtividade e entregas.
|
| 97 |
|
| 98 |
|
| 99 | \section{Metodologia de Pesquisa}
|
| 100 |
|
| 101 | \lipsum[1-2]
|
| 102 |
|
| 103 | \subsection{Tipo de Pesquisa}
|
| 104 |
|
| 105 | \lipsum[1]
|
| 106 |
|
| 107 | \subsection{Instrumento de coleta de dados}
|
| 108 |
|
| 109 | \lipsum[1]
|
| 110 |
|
| 111 | \subsection{Análise de Similares}
|
| 112 |
|
| 113 | \lipsum[1]
|
| 114 |
|
| 115 | \subsection{Relação entre os dados coletados e o desenvolvimento}
|
| 116 |
|
| 117 | \lipsum[1]
|