O documento discute os conceitos e aplicações de Processos de Desenvolvimento de Software (PDS), comparando modelos tradicionais como Cascata e RUP com modelos ágeis como SCRUM e XP. Resume que PDS organizam atividades, papéis e artefatos para o desenvolvimento de software, e que não existe um modelo perfeito, sendo importante customizá-los de acordo com cada organização.

1. PDS – Teoria e PráticaRalph J. R. Filho

2. ObjetivosEsclarecer a importância do processo de desenvolvimento de software bem como explicar suas aplicabilidades e a participação das pessoas

3. ConteúdoPrimeiros PassosVisão GeralTipos de PDSTradicionaisRUP, CascataÁgeisSCRUM, XP

4. Primeiros PassosProcessoConjunto de passos e instruçõesparaexecutardeterminadasatividadesDesenvolvimentoCriaçãooumanutenção de um produtoouserviçoSoftwareConjunto de código-fonte e documentação

5. Primeiros PassosUm processo de desenvolvimento de software (PDS) é um conjunto de atividades, disciplinas e papéisqueprescrevepráticaspara se conceber, gerenciar, desenvolver, testar e implantar um softwareAs atividades do PDS possuementradas, saídas, ferramentas e técnicasqueestãoligadas a artefatoscriadosoualteradosdurantesuaexecução

6. Crise do SoftwareOsprimeiros PDS's surgiramnosanos 70 impulsionadospelacrise do software queocorreunosanos60Osprojetos de software dos anosiniciaisapresentavamdiversosproblemasAltos investimentos, semvisibilidadeExcesso de falhas (bugs)Requisitos mal compreendidosQuaseimpossível de manterapós pronto

7. Visão Geral

8. Visão Geral“Anyfoolcanwritecodethat a computercanunderstand. Goodprogramerswritecodethathumanscanunderstand”Martin Fowler

9. Alguns ObjetivosVisão de ProjetoAplicação de boas práticasIndicadores de qualidadeDefinição de papéisligadosaoplano de carreira e àsatividadesexecutadas

10. Alguns ObjetivosVisão de ProjetoSaber sobre o progresso das atividades, impedimentos, atrasos, dependências, relacionamentos, custos, riscosPoderorganizar/planejar com maioreficiência as tarefasqueirãocomporcadaetapa de um desenvolvimento

11. Alguns Objetivos

12. Alguns ObjetivosIndicadores de qualidadeIdentificaracuracidade de estimativasCompararprojetosAlinharobjetivos dos projetos com osobjetivosestratégicos da empresaIdentificaresforço com defeitos e retrabalhosMapeardesempenho de recursoshumanos

13. Alguns Objetivos

14. Alguns Objetivos

15. Alguns ObjetivosAplicação de boas práticasModelos de documentos a seremutilizadosparaagregar valor ao softwareLiçõesaprendidas com projetosanterioresdescritoscomoguiasEstrutura de papéisadequada à política da empresaEstrutura de fases e disciplinasadequada à natureza dos projetos da empresa

16. Primeiros PassosO que é?PapelDisciplinaArtefato

17. Primeiros Passos - PapéisAdministrador de Rede

18. Analista de Qualidade

19. Analista de Requisitos

20. Analista de Negócios

21. Analista de Testes

22. Arquiteto de Software

23. Consultor

24. Desenvolvedor

25. Gerente de Configuração

26. Gerente de Projetos

27. Testador

28. ...Cada papel tem sua importância, disciplina, artefatos associados e atividades pré-definidas

29. Primeiros Passos - DisciplinaAnálise e projeto de software

30. Desenvolvimento de software

31. Gerência de Configuração

32. Gerência de Requisitos

33. Gerência de Projetos

34. Implantação

35. Modelagem de Negócios

36. Teste de SoftwareCategorização de processos que são, teoricamente, independente dos demais

37. Primeiros Passos - ArtefatoAtor

38. Burndownchart

39. Caso de Teste

40. Caso de Uso

41. Código fonte

42. E-mail

43. Glossário

44. Plano de iteração

45. Requisito

46. Exemplo:

47. Coleção de Requisitos

48. Caso de Uso

49. Regra de NegócioDocumento ou elemento pertencente a este, que deve ser criado ou alterado

50. Primeiros Passos - Artefato

51. Visão Geral

52. Visão GeralOrganizaçõesbemestruturadasusam PDS emseuambiente, semprebuscandomelhoriaO PDS possui um conjunto de regras e elementosquesãocriados e refinadosaopassar do tempo

53. Visão GeralPessoasquedesempenham o papel de Analista de Qualidadefocamseutrabalhoemdefinir, manter, ensinar e auditar o PDSAlgumasempresaspossuem um setor de qualidadeO conhecimento das pessoasqueusam o PDS naprática é fundamental para o refinamento dos processos

54. Visão Geral

55. Visão Geral

56. Visão Geral

57. Visão GeralUma página web é um bomcaminhoparacentralizar o PDS. Eledeveser de acesso a todosnaempresaCadapessoa, de acordo com seuspapéis, executa as atividadesconforme o PDS e podedarsugestões de melhoriasbemcomoindagarsobreelementosquenãoconcordaouque tem dúvidas

58. Visão GeralÉ importanteconhecer o PDS como um todo!Conhecer o seupapelnaempresaDescobrir e trilharcaminhos de carreiraEstudar e aplicar as melhorespráticas

59. Visão GeralFerramentassãoutilizadaspelaspessoasquefazem o PDS acontecer. Através do usodelas as tarefassãoexecutadas, osdocumentosarquivados e as informaçõesmantidasExemplos: MS Project, CVS, Eclipse, IBM Rational Suite, Thunderbird

60. Visão GeralO PDS deveevitarreferir-se a ferramentasdiretamente, oufazerisso de forma independente, porquê as ferramentasdevemoferecersuporteao PDS, e não o contrárioO PDS deveenglobar as diferentesnaturezas dos projetosque a organizaçãoexecuta

61. Visão Geral - RUP

62. Visão GeralAtualmenteexistemdiversosmodelos de PDS no mercadoO PDS ideal é aquelequeatendeaostipos de projetosque a organizaçãoexecutaCustomização de modelos é normal

63. Modelos de PDSTradicionaisPossuemumagrandequantidade de papéis, disciplinas e fases. Chamadosdesta forma porseremprecursoresouserembaseadosnestes. Lembrametapas de um processofabril (Fábrica de Software)ÁgeisConceitocriadonosanos 90 com o pretexto de queostradicionaisnãoatendiamdeterminadasnaturezas de projetos (web) e queeramexcessivamenteburocráticos

64. Modelos de PDSTradicionaisCascataRUPÁgeisSCRUMXP

65. CascataModeloCascataPrimeiro PDS formalizado, anos 70Processosequencial e estático, é simples de seraplicado e controladoVáriasempresasutilizamatualmenteOriginou-se emempresas da área industrial, de manufatura e construção

66. Cascata

67. CascataO modelo Cascata “puro” prescreve que só é possível avançar para uma próxima fase depois que a fase anterior estiver 100% concluídaExistem variações deste modelo

68. Cascata

69. Cascata

70. CascataQuais as vantagens?Quais as desvantagens?

71. RUPIBM RationalUnifiedProcessUsa a abordagem O.O. e UML na sua documentaçãoOrganizado em fases e disciplinas inclui guias de boas práticas e templatesPossui um vasto conjunto de papéis e documentos, abrange a elaboração de softwares de alta complexidade

72. RUP

73. RUP

74. RUP

75. RUP

76. RUP

77. RUP

78. RUPPrincipais documentos

79. RUP

80. RUP

81. RUP

82. RUPQuais as vantagens?Quais as desvantagens?

83. RUPVisitehttp://www.wthreex.com

84. ÁgeisSCRUM, XPPorquê está em evidência?Toyota, Honda, HPInovaçãoWebA abordagem humanitária em detrimento dos processos bem elaborados

85. ÁgeisPrincípiosIndivíduos e iterações melhor que: processos e ferramentasSoftware funcionando melhor que:documentação compreensivaCooperação do cliente melhor que: negociar contratoResposta à mudanças melhor que:seguir planosCuidado com a interpretação dos itens acima

86. O case ToyotaMais de 300 mil colaboradoresA maior empresa automotiva em produção e vendas

87. O case ToyotaToyota-wayPensamento longo prazo como base para decisões gerenciaisProcesso para soluções de problemasAdicionar valor à organização através do desenvolvimento das pessoasSolução de problemas na raiz direciona ao aprendizado organizacional

88. O case ToyotaRespeito aos seres humanos e melhoria contínuaDesafioKaizenTrabalho em equipeOs ágeis basearam-se neste modelo

89. Ágeis

90. Ciclo de vida ágil

91. XPExtreme programmingPráticas ágeis voltadas para o desenvolvimento de software