O documento apresenta e descreve vários modelos de processos de desenvolvimento de software, incluindo o modelo em cascata, evolucionário, de desenvolvimento incremental, espiral e prototipação. Cada modelo é explicado com seus principais estágios, vantagens e desvantagens. O documento fornece uma visão geral dos paradigmas e abordagens de processos de software.

1. Engenharia de Software Unidade II – Processos de Software [Parte I] Objetivo : Apresentar os principais paradigmas e modelos de processos de software, demonstrando o ciclo de vida do desenvolvimento de software e enfatizando os processos de especificação de requisitos, projeto, implementação, testes e mudanças Prof. Nécio de Lima Veras

4. Desenvolvimento;

5. Validação; e

9. Evolucionário;

10. Desenvolvimento incremental;

11. Espiral; e

12. Prototipação.

15. Originou-se de outros processos de engenharia;

16. Retrata um desenvolvimento gradual e possui seqüência de passos em ordem que devem ser seguidos.

23. Isso torna difícil responder a requisitos do usuário que mudam;

24. Portanto, esse modelo é apropriado somente quando os requisitos são bem compreendidos;

26. A especificação, desenvolvimento e validação são executados concorrentemente para gerar um retorno rápido;

28. Protótipos descartáveis : tenta compreender os melhor os requisitos a partir de protótipos e então desenvolver uma especificação de requisitos completa.

30. Os sistemas são mal-estruturados: mudanças constantes podem corromper a estrutura do software;

31. Requer ferramentas e técnicas especiais: que nem sempre são disponíveis ou são aplicáveis ao caso.

33. Para partes de sistemas grandes (p.ex., a interface com o usuário)

34. Para sistemas de vida curta.

37. Analogia à construção de uma mansão;

39. Redução do risco de lançar o projeto no mercado fora da data planejada. Identificando os riscos numa fase inicial o esforço despendido para gerenciá-los ocorre cedo, quando as pessoas estão sob menos pressão do que numa fase final de projeto.

40. Aceleração do tempo de desenvolvimento do projeto como um todo, porque os desenvolvedores trabalham de maneira mais eficiente quando buscam resultados de escopo pequeno e claro.

41. Reconhecimento de uma realidade freqüentemente ignorada: as necessidades dos usuários e os requisitos correspondentes não podem ser totalmente definidos no início do processo.

42. Este modelo de operação facilita a adaptação a mudanças de requisitos.

44. O usuário pode se entusiasmar excessivamente com a primeira versão do sistema e pensar que tal versão já corresponde ao sistema como um todo.

46. A verba do projeto pode acabar.

47. O sistema de software pode não ser adaptável, manutenível ou extensível.

48. O sistema de software pode ser entregue ao usuário tarde demais.

50. Cada volta na espiral representa uma fase no processo

52. O modelo Espiral

55. O cliente “enxerga” telas e relatórios resultantes do software, com os quais ele terá alguma pequena interação.

56. O usuário deve ser envolvido para opinar sobre as telas e relatórios do software, de maneira que se consiga torná-lo quase que co-autor do desenvolvimento responsabilizando-o também, desta forma, pelo sucesso final do software, uma vez que terá tido participação ativa na montagem do mesmo.

59. Pressão a fim de que concessões de implementações ocorram para a urgência da implantação, sugerindo-se que o protótipo seja evoluído e entre rapidamente em funcionamento.

60. Exercícios