eletrotupi / tcc/ commit / 90a005b

thesis: rewrite development methodologies section

Pedro Lucas Porcellis porcellis@eletrotupi.com · 16 days ago 90a005b2c3a229dac7b2f1b43663d94291cf2bf8 Browse files
Parents f60b377
Changed files
1
Additions
+64
Deletions
-77
monografia/chapters/methodologies.tex modified+64 -77
monografia/chapters/methodologies.tex
1 1 
\chapter{Metodologias}
2 2 
\label{chapter:methodologies}
3 3
4 4 
Como primeiro passo, para conseguir viabilizar construir um \textit{software}
5 5 
com qualidade, é necessário adotar metodologias que fundamentam a ideia e o
6 - 
processo. De tal sorte que, ajudem a levantar requisitos, priorizar
7 - 
funcionalidades, quebrar o escopo em entregáveis que possam ser validados, e
8 - 
desenvolver o aplicativo/sistema de forma sustentável. Esse capítulo se
9 - 
debruça, tanto na abordagem da metodologia de pesquisa do projeto, quanto
10 - 
também detalha o método de desenvolvimento de \textit{software} implementado.
6 + 
embasem o processo. De tal sorte que, ajudem a levantar quais requisitos esse
7 + 
\textit{software} deve atender, priorizar funcionalidades, quebrar o escopo em
8 + 
entregáveis que possam ser validados, e desenvolver os mesmos de forma
9 + 
sustentável. Esse capítulo se debruça, tanto na abordagem da metodologia de
10 + 
pesquisa do projeto, quanto também detalha o método de desenvolvimento de
11 + 
\textit{software} escolhido.
11 12
12 13 
\section{Metodologia de Desenvolvimento de \textit{software}}
13 14
14 - 
Existem diversos métodos de desenvolvimento, cada um com seus respectivos prós
15 - 
e contras. Todos tentam, de sua forma, responder à necessidade de como dar
16 - 
forma ao processo de desenvolvimento, para que ele flua e assegure que os
17 - 
requisitos levantados sejam atendidos, que os membros envolvidos no processo,
18 - 
tanto de desenvolvimento em si, quanto dos atores que o demandam tenham seus
19 - 
anseios respondidos de forma minimamente transparente e satisfatória.
15 + 
Existem diversas abordagens para o desenvolvimento de \textit{software}, cada
16 + 
uma com seus respectivos prós e contras. Todos procuram responder a uma mesma
17 + 
necessidade: dar forma ao processo de desenvolvimento, para que ele flua e
18 + 
assegure que os requisitos levantados sejam atendidos, que os membros
19 + 
envolvidos no processo, sejam eles os desenvolvedores quanto os usuários finais
20 + 
ou atores que o demandam tenham seus anseios respondidos de forma minimamente
21 + 
transparente e satisfatória.
20 22
21 - 
Além disso, a escolha de uma boa metodologia, adequada para as necessidades do
22 - 
sistema, permite que os prazos de entrega sejam melhor controlados e mais
23 - 
precisos \cite{pressman:2021}, minimizando a ocorrência de falhas e gestão do
24 - 
tempo.
23 + 
Além disso, a escolha de uma abordagem adequada para as necessidades do
24 + 
sistema, permite que os prazos de entrega sejam mais bem controlados e mais
25 + 
precisos \cite{pressman:2021}, minimizando a ocorrência de falhas e melhorando
26 + 
a gestão do tempo.
25 27
26 28 
As ideias fundamentais que norteiam esse projeto são baseadas em dois conceitos
27 - 
chaves da engenharia de \textit{software}: desenvolvimento incremental e
28 - 
desenvolvimento de \textit{software} ágil. O IEEE define que a engenharia de
29 - 
\textit{software} é:
29 + 
chaves da engenharia de \textit{software}: o modelo de desenvolvimento
30 + 
incremental e desenvolvimento de \textit{software} ágil. O IEEE define que a
31 + 
engenharia de \textit{software} é:
30 32
31 33 
\begin{quote}
32 34 
  Engenharia de \textit{software}: A aplicação de uma abordagem sistemática,
33 35 
  disciplinada e quantificável no desenvolvimento, na operação e na manutenção de
34 36 
  \textit{software}; isto é, a aplicação de engenharia ao \textit{software}.
35 37 
  \cite[p.~67, tradução nossa]{ieee:1990}
36 38 
\end{quote}
37 39
38 40 
Portanto, a engenharia de \textit{software} propõe estruturar a criação de
39 - 
\textit{software} de forma mais organizada e eficiente. Pressman vai dar um
40 - 
destaque para os modelos de desenvolvimento de \textit{software} sequenciais e
41 - 
incrementais que moldam boa parte das práticas de engenharia de
42 - 
\textit{software} nas últimas décadas.
41 + 
\textit{software} de forma mais organizada e eficiente. \citet{pressman:2021}
42 + 
aborda, entre os diversos modelos de processo, \citet{pressman:2021} aborda o
43 + 
de desenvolvimento em cascata e desenvolvimento incremental que moldaram boa
44 + 
parte das práticas da área nas últimas décadas.
43 45
44 - 
O modelo em cascata (\textit{waterfall}) é um modelo sequencial, dos mais
45 - 
tradicionais e antigos a existirem, cujo qual necessita que cada etapa ---
46 - 
levantamento de requisitos, projeto, implementação, testes --- estejam
47 - 
concluídas antes da próxima etapa começar. Embora forneça uma estrutura rígida
48 - 
e lógica, é frequentemente criticado pela baixa adaptabilidade em relação às
49 - 
mudanças durante o processo de desenvolvimento.
46 + 
O modelo em cascata (\textit{waterfall}) é linear e um dos mais tradicionais.
47 + 
Levantamento de requisitos, projeto, implementação e testes formam uma única
48 + 
linha reta e única, na qual cada etapa precisa estar concluída antes da entrega
49 + 
final. Como não há entrega intermediária, o retorno sobre o produto só é
50 + 
coletado depois que ele está pronto. Embora forneça uma estrutura lógica e
51 + 
rígida, o modelo é frequentemente criticado pela baixa adaptabilidade em
52 + 
relação às mudanças durante o processo de desenvolvimento.
50 53
51 - 
Em outro âmbito, o modelo incremental, trabalha com a premissa de que um
52 - 
desenvolvimento, feito em pequenas porções, agrupam-se para totalizar o projeto
53 - 
em si. Trabalho a concepção de incrementos funcionais, permitindo uma maior
54 - 
flexibilidade com as mudanças no processo ao todo. Também ajuda a iterar
55 - 
rápidamente em cima do desenvolvimento do sistemas, 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 - 
mínimo, 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.
54 + 
Em outro oposto, o modelo incremental, trabalha com a premissa de construir em
55 + 
pequenas porções. Cada incremento percorre seu próprio mini-ciclo de
56 + 
levantamento de requisitos, projeto, implementação e testes, e ao fim de cada
57 + 
ciclo curto, entrega-se um sistema funcional, ainda que parcial. Isso permite
58 + 
colher retorno precocemente, lidar melhor com requisitos incertos ou mutáveis e
59 + 
ajustar o rumo a cada entrega \cite{pressman:2021}.
72 60
73 61 
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,
62 + 
renomados publicou o ``Manifesto Ágil'', um documento desenhando um conjunto de
63 + 
valores/princípios de forma a explicitar elementos chaves do ciclo de
64 + 
desenvolvimento, destacando a satisfação dos \textit{stakeholders} do sistema,
76 65 
entregas mais rápidas, flexibilidade durante o desenvolvimento do
77 66 
\textit{software} de forma a evitar que os desenvolvedores ficassem empacados e
78 - 
reduzissem rigidez. Os principais destaques da abordagem ágil é a proposta de
79 - 
que a mesma não é escrita em pedra, ou seja, permite flexibilidade no como
80 - 
aplicá-la. Nesse cenário, existem algumas abordagens sobre ela, como o
81 - 
\textit{Kanban} e o \textit{Scrum}, que dão um pouco mais de forma a ideia
82 - 
apresentada com o desenvolvimento ágil o que casa relativamente bem com o
83 - 
modelo de desenvolvimento incremental.
67 + 
ajudasse a remover a rigidez de modelos prescritivos.
84 68
85 - 
Com base nesse panorama, o presente trabalho adota uma abordagem baseada na
86 - 
filosofia ágil, estruturada por meio da utilização de um quadro de Kanban,
87 - 
adaptado à realidade de um desenvolvimento individual. Diferentemente de
88 - 
modelos tradicionais que envolvem um maior formalismo, o \textit{Kanban}
89 - 
permite visualizar e gerenciar o fluxo de trabalho de forma contínua, com foco
90 - 
na entrega incremental de funcionalidades. Por ser um método não prescritivo, o
91 - 
\textit{Kanban} oferece liberdade para que as tarefas possam ser priorizadas,
92 - 
ajustadas ou redefinidas conforme a evolução do desenvolvimento, característica
93 - 
especialmente útil quando há apenas um desenvolvedor responsável por todas as
94 - 
etapas do processo. Vale ressaltar também, que a metodologia adotada acaba por
95 - 
ajudar a manter o fluxo de desenvolvimento contínuo sem sobrecarga, já que
96 - 
limita a quantidade de tarefas em progresso, gerando um movimento de maior
97 - 
produtividade e entregas.
69 + 
Por serem princípios, e não procedimentos, os valores ágeis não são aplicados
70 + 
diretamente: precisam ser instanciados em métodos concretos, como o
71 + 
\textit{Kanban} e o \textit{Scrum}. O \textit{Scrum} organiza o trabalho em
72 + 
papéis e cerimônias (\textit{Product Owner}, \textit{Scrum Master},
73 + 
\textit{dailies}, \textit{sprint reviews}) pensados para coordenar uma equipe.
74 + 
O \textit{Kanban}, por sua vez, baseia-se na visualização do fluxo de trabalho
75 + 
e na limitação de tarefas em progresso, sem pressupor uma estrutura de equipe.
76 +
77 + 
Por ser um método não prescritivo, o \textit{Kanban} não define um ciclo de
78 + 
vida de desenvolvimento; ele organiza a execução do trabalho definido por outro
79 + 
modelo. Isso permite que as tarefas sejam priorizadas, ajustadas ou
80 + 
redefinidas, conforme a evolução do projeto, característica especialmente útil
81 + 
quando há apenas um desenvolvedor responsável por todas as etapas do processo.
98 82
99 - 
A escolha pelo \textit{Kanban}, portanto, oferece um equilíbrio sustentável
100 - 
entre estrutura e flexibilidade, permitindo que o desenvolvimento avance de
101 - 
maneira organizada, e sem os entraves burocráticos dos modelos mais rígidos.
102 - 
Essa abordagem permite que o projeto se beneficie dos princípios ágeis, tais
103 - 
como a entrega contínua de valor, adaptação a mudanças e foco na simplicidade,
104 - 
ao mesmo tempo que mantém o controle sobre o progresso e a qualidade do produto
105 - 
final.
83 + 
Com base nesse panorama, o presente trabalho adotou um misto: utiliza o modelo
84 + 
incremental estrutura o ciclo de desenvolvimento em entregas funcionais
85 + 
sucessivas; os princípios ágeis orientam as decisões, priorizando em entregas
86 + 
funcionais sucessivas; os princípios ágeis orientam as decisões, priorizando a
87 + 
entrega contínua de valor e a adaptação a mudanças; e o \textit{Kanban}
88 + 
organiza a execução por meio de um quadro que separa o que precisa ser feito, o
89 + 
que está em andamento e o que já foi concluído, limitando a quantidade de
90 + 
tarefas em progresso. Essa combinação mantém o controle sobre o andamento e a
91 + 
qualidade do produto sem os entraves de cerimônias e papéis pensados para
92 + 
equipes, o que a torna adequada a um desenvolvimento individual.
106 93
107 94 
\section{Metodologia de Pesquisa}
108 95
109 96 
Entende-se por pesquisa científica, a investigação de um fenômeno, de forma a
110 97 
encontrar a solução para algum problema \cite{Coelho:2020}. Portanto, a
418 405 
atenda a essas demandas, mas também adote princípios de transparência, abertura
419 406 
e controle por parte do usuário. A seguir, serão discutidas as decisões de
420 407 
projeto que nortearam a construção da ferramenta proposta, baseadas tanto nas
421 408 
limitações identificadas nos sistemas existentes quanto nas necessidades e
422 409 
expectativas manifestadas pelo público-alvo da pesquisa.