From 16cec5e7235a561b2a646887163f677f34e23d07 Mon Sep 17 00:00:00 2001 From: Breno Soares Fernandes Date: Mon, 18 Nov 2024 23:25:01 -0300 Subject: [PATCH 1/2] Adicionando quadro comparativo --- docs/estrategias_de_engenharia/estrategias.md | 44 ++++++++++++++----- 1 file changed, 34 insertions(+), 10 deletions(-) diff --git a/docs/estrategias_de_engenharia/estrategias.md b/docs/estrategias_de_engenharia/estrategias.md index cff69cd..cd0799c 100644 --- a/docs/estrategias_de_engenharia/estrategias.md +++ b/docs/estrategias_de_engenharia/estrategias.md @@ -1,20 +1,44 @@ # Estratégias de Engenharia -## Histórico de Versão +## Estratégia Priorizada + +**Abordagem de Desenvolvimento de Software:** Ágil + +**Ciclo de vida:** Iterativo e Incremental + +**Processo de Engenharia de Software:** RAD + +## Quadro Comparativo + +O quadro a seguir compara os processos de desenvolvimento **RAD** e **Scrum** em diversas características, com o objetivo de auxiliar na justificativa para a escolha do processo mais adequado a este projeto. + +| Características | RAD | Scrum | +|-------------------------------|---------------------------------------------------------------------|--------------------------------------------------------------------------------| +| **Abordagem Geral** | Metodologia de desenvolvimento rápido e iterativo, com foco na criação, validação de protótipos e entregas rápidas. | Framework ágil baseado em sprints curtos e entregas incrementais | +| **Foco em Arquitetura** | Menor foco inicial em arquitetura; ênfase em protótipos | Maior atenção à arquitetura para manter flexibilidade | +| **Estrutura de Processos** | Estrutura flexível, com iterações rápidas e prototipagem | Estrutura bem definida com sprints, backlog e eventos específicos | +| **Flexibilidade de Requisitos** | Alta; requisitos podem ser alterados durante o desenvolvimento | Moderada; alterações podem ser aceitas, mas devem passar pelo backlog e priorização | +| **Colaboração com Clientes** | Intensa; cliente envolvido em feedback frequente e revisão de protótipos | Essencial; cliente revisa e prioriza o backlog e participa de revisões de sprint | +| **Complexidade do Processo** | Baixa a moderada, com processos adaptáveis e qualidade aprimorada por feedback contínuo durante revisões e iterações. | Moderada a alta; requer disciplina para seguir eventos e artefatos do Scrum | +| **Qualidade Técnica** | Foco em funcionalidade, com qualidade técnica aprimorada por feedback contínuo durante revisões e iterações, embora possa ser sacrificada pela velocidade. | Alta; qualidade técnica é essencial, com revisões e melhorias contínuas | +| **Práticas de Desenvolvimento** | Prototipagem rápida, foco em entrega de funcionalidades principais | Desenvolvimento incremental, com práticas ágeis como revisão de código e testes | +| **Adaptação ao Projeto** | Ideal para projetos com escopo indefinido ou requisitos em constante mudança, beneficiando-se de protótipos ágeis e flexíveis. | Adequado para projetos complexos e de longo prazo com escopo claro, mas adaptável | +| **Documentação** | Documentação mínima e enxuta, focada apenas nos registros essenciais para guiar o desenvolvimento, priorizando protótipos e entregas rápidas. | Documentação moderada, geralmente vinculada ao backlog e requisitos do sprint | +| **Controle de Qualidade** | Controle mais básico, com ênfase em entregas rápidas e testes do usuário final | Controle rigoroso; envolve revisões contínuas e testes integrados nos sprints | +| **Escalabilidade** | Limitada, mais indicada para projetos pequenos e médios | Alta, adequado para grandes equipes e projetos complexos | +| **Suporte a Equipes de Desenvolvimento** | Ideal para equipes menores e colaborativas, com papéis flexíveis e forte dependência de feedback do cliente e protótipos rápidos. | Alto; suporta equipes organizadas com papéis claros como Product Owner e Scrum Master | -| **Data** | **Versão** | **Descrição** | **Autor** | -| :--------: | :--------: | :--------: | :--------: | -| 11/11/2024 | 1.0 | Criação do documento | Guilherme Storch | -## Estratégia Priorizada -| Tópico | Decisão | -| :----: | :----: | -|Aborgagem| Ágil | -| Ciclo de Vida| Ágil | ## Justificativa - **Abordagem Ágil**: Pelo levantamento inicial de informações, a abordagem ágil se coloca como uma das abordagens com melhor aplicabilidade para o contexto estudado, levando em consideração a possibilidade de permitir feedbacks antecipados e a liberação do projeto mais cedo para o cliente. Somado a isso, a instabilidade de alguns dos requisitos iniciais levam a crer que esta abordagem possa ser a mais adequada para este cenário de estudos. -- **Ciclo de Vida Ágil**: Reflete a escolha da abordagem de gerenciamento para o projeto. Permite mais feedbacks antecipados e se adapta melhor a mudanças pontuais devido a instabilidade de alguns dos requisitos. \ No newline at end of file +- **Ciclo de Vida Ágil**: Reflete a escolha da abordagem de gerenciamento para o projeto. Permite mais feedbacks antecipados e se adapta melhor a mudanças pontuais devido a instabilidade de alguns dos requisitos. + +## Histórico de Versão + +| **Data** | **Versão** | **Descrição** | **Autor** | +| :--------: | :--------: | :--------: | :--------: | +| 11/11/2024 | 1.0 | Criação do documento | Guilherme Storch | \ No newline at end of file From ac2dd7470246420ef0944e3f579c4fd3844a1a9d Mon Sep 17 00:00:00 2001 From: Breno Soares Fernandes Date: Mon, 18 Nov 2024 23:29:39 -0300 Subject: [PATCH 2/2] Adicionando justificativa --- docs/estrategias_de_engenharia/estrategias.md | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/docs/estrategias_de_engenharia/estrategias.md b/docs/estrategias_de_engenharia/estrategias.md index cd0799c..0daad8f 100644 --- a/docs/estrategias_de_engenharia/estrategias.md +++ b/docs/estrategias_de_engenharia/estrategias.md @@ -33,12 +33,16 @@ O quadro a seguir compara os processos de desenvolvimento **RAD** e **Scrum** em ## Justificativa -- **Abordagem Ágil**: Pelo levantamento inicial de informações, a abordagem ágil se coloca como uma das abordagens com melhor aplicabilidade para o contexto estudado, levando em consideração a possibilidade de permitir feedbacks antecipados e a liberação do projeto mais cedo para o cliente. Somado a isso, a instabilidade de alguns dos requisitos iniciais levam a crer que esta abordagem possa ser a mais adequada para este cenário de estudos. +Escolhemos o RAD (Rapid Application Development) como metodologia devido à sua forte ênfase na coleta contínua de feedbacks com o cliente, um fator essencial para o sucesso do nosso projeto. Essa abordagem nos ajuda a lidar com diversos desafios, como a flexibilidade nos requisitos, permitindo ajustes rápidos e adaptativos conforme surgem novas demandas ou mudanças durante o desenvolvimento. -- **Ciclo de Vida Ágil**: Reflete a escolha da abordagem de gerenciamento para o projeto. Permite mais feedbacks antecipados e se adapta melhor a mudanças pontuais devido a instabilidade de alguns dos requisitos. +O envolvimento ativo do cliente é outro ponto central, já que o RAD promove interações frequentes por meio de protótipos iterativos. Isso nos permite validar funcionalidades em tempo real, garantindo que o projeto esteja sempre alinhado às expectativas do cliente e reduzindo o risco de mal-entendidos ou entregas desalinhadas. +Além disso, a coleta constante de feedback reduz riscos ao identificar possíveis problemas ou lacunas ainda nas fases iniciais, facilitando correções rápidas e prevenindo retrabalho mais complexo. Essa característica é particularmente útil para projetos com escopo indefinido, onde os requisitos podem evoluir ao longo do tempo. Com o RAD, conseguimos transformar a incerteza em oportunidade, iterando de forma ágil e colaborativa. + +Assim, o RAD foi escolhido por sua capacidade de alinhar o processo de desenvolvimento às necessidades do cliente, promovendo entregas eficientes, adaptabilidade às mudanças e maior qualidade nos resultados. ## Histórico de Versão | **Data** | **Versão** | **Descrição** | **Autor** | | :--------: | :--------: | :--------: | :--------: | -| 11/11/2024 | 1.0 | Criação do documento | Guilherme Storch | \ No newline at end of file +| 11/11/2024 | 1.0 | Criação do documento | Guilherme Storch | +| 18/11/2024 | 1.1 | realizando ajustes | Breno Fernandes | \ No newline at end of file