https://padlet.com/yasminbarreto450/dgfvxx4g3h4osual Yasmin, Lucas, Luane, Bruno en-us 2022-09-03 16:58:00 UTC 2025-10-05 18:46:47 UTC hello@padlet.com yasminbarreto450 https://padlet.com/yasminbarreto450/dgfvxx4g3h4osual/wish/2282190574 2022-09-04 20:47:52 UTC https://padlet.com/yasminbarreto450/dgfvxx4g3h4osual/wish/2282190574 yasminbarreto450 https://padlet.com/yasminbarreto450/dgfvxx4g3h4osual/wish/2282194386 O desenvolvimento incremental é baseado na ideia de desenvolver uma implementação inicial, expô-la aos comentários dos usuários e continuar por meio da criação de várias versões até que um sistema adequado seja desenvolvido. Atividades de especificação, desenvolvimento e validação são intercaladas, e não separadas, com rápido feedback entre todas as atividades. Desenvolvimento incremental de software, que é uma parte fundamental das abordagens ágeis, é melhor do que uma abordagem em cascata para a maioria dos sistemas de negócios, e-commerce e sistemas pessoais. 

Cada incremento ou versão do sistema incorpora alguma funcionalidade necessária para o cliente. Frequentemente, os incrementos iniciais incluem uma funcionalidade mais importante ou mais urgente. Isso significa que o cliente pode avaliar o sistema em um estágio relativamente inicial do desenvolvimento para ver se ele oferece o que foi requisitado. Em caso negativo, só o incremento que estiver em desenvolvimento no momento precisará ser alterado e, possivelmente, nova funcionalidade deverá ser definida para incrementos posteriores. ]]> 2022-09-04 20:56:43 UTC https://padlet.com/yasminbarreto450/dgfvxx4g3h4osual/wish/2282194386 yasminbarreto450 https://padlet.com/yasminbarreto450/dgfvxx4g3h4osual/wish/2282202098 2022-09-04 21:17:56 UTC https://padlet.com/yasminbarreto450/dgfvxx4g3h4osual/wish/2282202098 yasminbarreto450 https://padlet.com/yasminbarreto450/dgfvxx4g3h4osual/wish/2282223937 2022-09-04 22:23:27 UTC https://padlet.com/yasminbarreto450/dgfvxx4g3h4osual/wish/2282223937 yasminbarreto450 https://padlet.com/yasminbarreto450/dgfvxx4g3h4osual/wish/2282226160 No modelo espiral, criado em 1988, as fases são tratadas de modo cíclico. A cada iteração (ou “volta” do ciclo), o usuário tem acesso a versões evolucionárias do software. Nele, há menos flexibilidade para lidar com possíveis falhas e bugs.

Por isso, cada etapa demanda maior planejamento. A empresa deve estar atenta para possíveis problemas, testando funcionalidades e avaliando eventuais incompatibilidades. Além disso, é necessário manter o cliente vinculado a cada etapa aplicando feedbacks e orientando mudanças futuras.

]]> 2022-09-04 22:30:30 UTC https://padlet.com/yasminbarreto450/dgfvxx4g3h4osual/wish/2282226160 yasminbarreto450 https://padlet.com/yasminbarreto450/dgfvxx4g3h4osual/wish/2291304767 Cada volta da espiral é dividida em quatro setores:

1. Definição de objetivos: Onde são definidos os objetivos para essa fase do projeto, identificando as restrições e preparando um plano de gerenciamento detalhado que inclui todos os possíveis riscos do projeto.

2. Avaliação e redução de riscos: Para cada um dos riscos identificados do projeto, é feita uma análise detalhada. Medidas para redução do risco são tomadas. Por exemplo, se houver risco de os requisitos serem inadequados, um protótipo de sistema pode ser desenvolvido.

3. Desenvolvimento e validação: Após a avaliação dos riscos, é selecionado um modelo de desenvolvimento para o sistema. Por exemplo, o “Modelo em Cascata”, “Modelo Incremental”, etc. Pode-se utilizar modelos diferentes em cada volta de implementação, conforme a necessidade.

4. Planejamento: O projeto é revisado, e uma decisão é tomada a respeito da continuidade do modelo com mais uma volta da espiral. Caso se decida pela continuidade, planos são elaborados para a próxima fase do projeto. ]]> 2022-09-11 17:46:48 UTC https://padlet.com/yasminbarreto450/dgfvxx4g3h4osual/wish/2291304767 yasminbarreto450 https://padlet.com/yasminbarreto450/dgfvxx4g3h4osual/wish/2291312147

Como o modelo exige a consideração dos riscos técnicos em todos os estágios de evolução, se for aplicado adequadamente, reduzirá os riscos antes que se tornem problemáticos;

As estimativas se tornam mais realistas e o tempo de implementação é reduzido;

Mais versátil para testar e lidar com mudanças;

Não faz distinção entre desenvolvimento e manutenção.

]]> 2022-09-11 17:57:54 UTC https://padlet.com/yasminbarreto450/dgfvxx4g3h4osual/wish/2291312147 yasminbarreto450 https://padlet.com/yasminbarreto450/dgfvxx4g3h4osual/wish/2291313566

Segundo PRESSMAN (2006), pode ser difícil convencer os clientes que o processo de evolução é controlável, pois ele exige competência considerável na avaliação dos riscos e depende dessa competência para ser bem sucedido;

Se um risco importante não for descoberto e gerenciado corretamente, fatalmente ocorrerão problemas;

A avaliação dos riscos exige um analista com experiência;

Aplica-se melhor a sistemas de grande porte;

Erros na avaliação de riscos podem impactar o projeto.

]]> 2022-09-11 18:00:08 UTC https://padlet.com/yasminbarreto450/dgfvxx4g3h4osual/wish/2291313566 yasminbarreto450 https://padlet.com/yasminbarreto450/dgfvxx4g3h4osual/wish/2291360813

 O custo de acomodar as mudanças nos requisitos do cliente é reduzido. A quantidade de análise e documentação a ser refeita é muito menor do que o necessário no modelo em cascata.

 É mais fácil obter feedback dos clientes sobre o desenvolvimento que foi feito. Os clientes podem fazer comentários sobre as demonstrações do software e ver o quanto foi implementado. Os clientes têm dificuldade em avaliar a evolução por meio de documentos de projeto de software.

É possível obter entrega e implementação rápida de um software útil ao cliente, mesmo se toda a funcionalidade não for incluída. Os clientes podem usar e obter ganhos a partir do software inicial antes do que é possível com um processo em cascata. 

]]> 2022-09-11 19:21:00 UTC https://padlet.com/yasminbarreto450/dgfvxx4g3h4osual/wish/2291360813 yasminbarreto450 https://padlet.com/yasminbarreto450/dgfvxx4g3h4osual/wish/2291361242

O processo não é visível. Os gerentes precisam de entregas regulares para mensurar o progresso. Se os sistemas são desenvolvidos com rapidez, não é economicamente viável produzir documentos que reflitam cada uma das versões do sistema.

A estrutura do sistema tende a se degradar com a adição dos novos incrementos. A menos que tempo e dinheiro sejam dispendidos em refatoração para melhoria do software, as constantes mudanças tendem a corromper sua estrutura. Incorporar futuras mudanças do software torna-se cada vez mais difícil e oneroso. 

]]> 2022-09-11 19:21:45 UTC https://padlet.com/yasminbarreto450/dgfvxx4g3h4osual/wish/2291361242 yasminbarreto450 https://padlet.com/yasminbarreto450/dgfvxx4g3h4osual/wish/2291482828 2022-09-11 23:23:43 UTC https://padlet.com/yasminbarreto450/dgfvxx4g3h4osual/wish/2291482828