Merge pull request #18 from mdsreq-fga-unb/4-processo-de-desenvolvime…

…nto-do-software

reenvia processo de dev para main

docs/doc-visao/3.processo-dev.md

@@ -10,8 +10,130 @@
 | **Data**  | **Versão** | **Descrição**        | **Autor**                                                     |
 | --------- | ---------- | -------------------- | ------------------------------------------------------------- |
 | 26/9/2023 | 0.1        | Criação do documento | [Luciano de Freitas](https://github.com/luciano-freitas-melo) |
+| 26/9/2023 | 0.2        | Adiciona Abordagem, Ciclo de Vida e Processo | [Luciano de Freitas](https://github.com/luciano-freitas-melo) |
+| 27/9/2023 | 0.3        | Insere as características do processo que serão desenvolvidos pela equipe| [Luciano de Freitas](https://github.com/luciano-freitas-melo) |
 
 
+
+## Abordagem de Desenvolvimento do Software
+
+  *Segundo Sommerville(2018)¹, para decidir sobre uma abordagem para o desenvolvimento de um software é necessário responder a uma série de perguntas, de três tipos diferentes:*
+
+  1. **Questões técnicas** relacionadas ao sistema a ser desenvolvido
+  2. **Questões humanas** relacionadas à equipe de desenvolvimento
+  3. **Questões organizacionais** relacionadas ao contexto no qual o sistema será desenvolvido 
+
+### Questões técnicas
+
+1. **Qual é o tamanho do sistema que está sendo desenvolvido?**
+
+    Um sistema de pequeno porte.
+
+2. **Que tipo de sistema está sendo desenvolvido?**
+
+    Uma aplicação web de complexidade média, com requisitos não muito bem definidos e que podem ser alterados durante o desenvolvimento.
+
+3. **Qual é a vida útil prevista para o sistema?**
+
+    A princípio, vida útil de curto a médio período.
+
+4. **O sistema está sujeito a controle externo?**
+
+    Sim, sujeito ao controle do cliente e do acompanhamento da disciplina.
+
+### Questões humanas
+
+1. **Qual é o nível de competência dos projetistas e programadores do time de desenvolvimento?**
+
+    Os projetistas possuem conhecimento em áreas diversas do desenvolvimento de software.
+
+2. **Como está organizado o time de desenvolvimento?**
+
+    O time é pequeno, e apesar de terem papéis definidos, todos devem participar da maioria das atividades.
+
+3. **Quais são as tecnologias disponíveis para apoiar o desenvolvimento do sistema?**
+
+    Os escopo tecnológico do projeto está melhor descrito [nesta seção](1.visao-produto.md/#tecnologias-a-serem-utilizadas).
+
+
+### Questões organizacionais
+
+1. **É importante ter uma especificação e um projeto (design) bem detalhados antes de passar para a implementação — talvez por motivos contratuais?**
+
+    Não, existem partes da aplicação que podem ser resolvidos sem especificações de design.
+
+2. **É realista uma estratégia de entrega incremental, na qual o software é entregue aos clientes ou outros stakeholders e um rápido feedback é obtido?**
+
+    Sim, pois dessa forma é possível corrigir os problemas por partes, antes de uma implementação completa do projeto, a qual poderia comprometer todo o produto.
+
+3. **Os representantes do cliente estarão disponíveis e dispostos a participar do time de desenvolvimento?**
+
+    Não, os representantes do cliente participarão apenas no envio de feedbacks durante as fases de construção, não participando do desenvolvimento em si.
+
+4. **Existem questões culturais que possam afetar o desenvolvimento do sistema?**
+
+    Não, pois o time é novo e não tem apego a determinado método de desenvolvimento. 
+
+
+### Conclusões
+
+*Levando em consideração as respostas das questões acima e outros fatores elencados pela equipe, foi decidido que a abordagem de desenvolvimento do software será a* **Abordagem Ágil***, pelos seguintes critérios:*
+
+- Complexidade ainda não mensurada e imprevisível das funcionalidades do sistema;
+- Proximidade com o cliente e a possibilidade de feedbacks rápidos, além de não ser necessário uma formalização acentuada dos requisitos e do projeto como um todo;
+- Time de desenvolvimento pequeno para um sistema de pequeno porte para um projeto de ciclo curto/médio;
+
+## Ciclo de Vida e Processo de Desenvolvimento do Software
+
+*Como a abordagem de desenvolvimento escolhida foi a Abordagem Ágil, o ciclo de vida do software será o* **Ciclo de Vida Ágil***, pois o desenvolvimento do software será feito em incrementos, com entregas parciais e contínuas, com o objetivo de atender as necessidades do cliente e se favorecer da disponibilidade de feedbacks constantes.*
+
+*O processo de desenvolvimento do software será o* **Scrum/XP***, que a união de duas metodologias complementares: O Scrum e o eXtreme Programming (XP). A metodologia Scrum servirá para organização e adaptação da equipe de desenvolvimento durante o projeto, o XP servirá para a execução das atividades de desenvolvimento do software.*
+
+*A escolha desse processo de software tem o objetivo de gerar uma melhor adaptação do projeto a mudanças de requisitos e de escopo, além de potencializar a participação do cliente por meio dos feedbacks constantes, todas características identificadas no projeto em questão.*
+
+## Características e Adaptações do Processo Escolhido
+
+### Scrum
+*Todos os rituais e artefatos do Scrum que serão utilizados no projeto estão descritos na tabela 1, logo abaixo, seguindo as definições do The Scrum Guide(2020)².*
+
+<p style="display: flex; justify-content: center; font-size: 0.8em">Tabela 1 - Características do Scrum a serem trabalhadas no projeto</p>
+| **Rituais/Artefatos**    | **Descrição**                                                                                                                                                                                                                |
+|:------------------------:|:----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------:|
+| Sprints                  | As sprints terão duração de 2 semanas, sempre iniciando aos sábados e terminando as quartas-feiras.                                                                                                                           |
+| Sprint Planning          | As plannings ocorrerão sempre aos sábados no início da sprint através de reuniões síncronas.                                                                               |
+| Daily Scrum              | Serão feitas de forma assíncrona todos os dias pela equipe de desenvolvimento no decorrer da sprint.                                                                                                                         |
+| Sprint Retrospective     | As Retrospectives serão realizadas as quartas-feiras, ao final da sprint.  |
+| Sprint Review            | A review da sprint ocorrerá no último dia da Sprint, quarta-feira, juntamente com  Retrospective.                                                                                                                                                          |
+| Product Backlog          | O Backlog será utilizado para elencar e estruturar o conjunto inicial de requisitos do projeto.                                                                                                                              |
+| Sprint Backlog           | Esse artefato será a mesma coisa da Release Planning do XP, em que serão definidos os requisitos que serão desenvolvidos e entregues para a próxima release.                                                                 |
+| Definition Of Done (DoD) | Esse compromisso do Scrum será baseado nas características do XP, que estão descritas mais abaixo.                                                                                                                           |
+<p style="display: flex; justify-content: center; font-size: 0.8em; margin-top: 0">Fonte: Autores (2023)</p>
+
+### eXtreme Programming (XP)
+
+*As características do XP que serão utilizadas no projeto estão descritas na tabela 2, seguindo as informações fornecidas por Don Wells(2013)³ sobre eXtreme Programming.*
+
+<p style="display: flex; justify-content: center; font-size: 0.8em">Tabela 2 - Características do XP a serem trabalhadas no projeto</p>
+
+| Característica | Descrição |
+|:---:|:---:|
+| User Stories (US) | As US serão a principal fonte de requisitos do projeto e auxiliaram para estimar os prazos para as entregas das funcionalidade do produto. |
+| Release Planning | As releases serão planejadas durante a Sprint Planning do Scrum e servirá para definir o Backlog da Sprint de quais US serão implementadas. Devido ao espoco da disciplina de Requisitos as releases serão planejadas por prazos (by date). |
+| Iteration Planning | Devem ocorrer pelo menos 2 iterações durante uma sprint, uma na Sprint Planning e outra no meio da sprint, com a "quebra" das US que serão desenvolvidas em tarefas (tasks).  |
+| Velocity Tracking | Tanto na Release Planning, como na Iteration Planning será utilizado o Velocity Tracking para auxiliar na definição dos prazos e nas estimativas de entrega das funcionalidades. |
+| *Planning Game⁴* | Método que transforma as plannings do XP em uma espécie de jogo, deixando as iterações e a rotina da metodologia mais dinâmica.  |
+| Sustainable, Measurable, Predictable Pace | O ritmo da equipe será avaliado durante todas as etapas de projeto, principalmente através do Velocity Tracking e das Retrospectives do Scrum. |
+| Stand up Meetings | Serão incorporadas as dailys do Scrum, com o propósito de responder as seguintes perguntas: O que foi feito ontem?; O que será tentado hoje?; e Quais problemas estão causando atrasos? |
+| Pair programming e Move people around | O Pair Programming servirá para melhoria na qualidade do produto, além de compartilhamento de experiência pela equipe. Para isso, o Move People Around também será muito útil, pois fará com que toda a equipe esteja capacitada em todas as áreas do produto. |
+| Unit Testing | Base para o XP programming, todo código que será entregue deverá ter testes unitários para assegurar qualidade, facilitar refatoração e proporcionar integração contínua do produto. Os testes unitários fazem parte do DoD do Scrum. |
+| Acceptance Tests | Testes de aceitação derivam das US e serão utilizados para validar as User Story. O Acceptance Tests também fazem parte do DoD do Scrum. |
+
+
+<p style="display: flex; justify-content: center; font-size: 0.8em; margin-top: 0">Fonte: Autores (2023)</p>
+
 ## Referências Bibliográficas
 
-1. Material da disciplina disponivel no aprender
+1. Sommerville, Ian Engenharia de software/ Ian Sommerville; tradução Luiz Cláudio Queiroz; revisão técnica Fábio Levy Siqueira. 10. ed. São Paulo: Pearson Education do Brasil, 2018. Título original: Software engineering ISBN 978-65-5011-048-2 1. Engenharia de software I. Siqueira.
+2. The 2020 Scrum Guide TM. Scrum Guides, 2020. Disponível no [link](https://scrumguides.org/scrum-guide.html#purpose-of-the-scrum-guide). Acesso em: 27 de setembro de 2023.
+3. WELLS, Don. Extreme Programming: A gentle introduction. Extreme Programming, 2013. Disponível no [link](http://www.extremeprogramming.org/). Acesso em: 27 de setembro de 2023.
+4. Wiki C2. Planning Game, 2013. Disponível no [link](https://wiki.c2.com/?PlanningGame). Acesso em: 27 de setembro de 2023.