O documento discute processos de engenharia de software, incluindo: (1) modelos de processos como cascata e evolutivo, (2) atividades de processo como especificação, desenho e validação, (3) RUP como um processo moderno, e (4) CASE para apoiar processos de desenvolvimento de software.

1. Engenharia do Software IManuel Menezes de SequeiraDCTI, ISCTE-IULManuel.Sequeira@iscte.pt, D6.02As apresentações desta série baseiam-se nas apresentações disponibilizadas por IanSommerville, tendo sido alteradas e adaptadas primeiro por Anders Lyhne Christensen e finalmente por Manuel Menezes de Sequeira.

2. SumárioProcessos de softwareModelos de processos de softwareIteração de processosActividades de processoRUP (RationalUnifiedProcess)CASE (Computer-Aided Software Engineering)2009/2010Engenharia do Software I2

3. Processos de Software2009/20103Engenharia do Software I

4. Na aula anteriorProcesso da engenharia de requisitosEstudos de viabilidadeEliciação e análise de requisitosValidação de requisitosGestão de requisitos2009/20104Engenharia do Software I

5. Processo de softwareConjunto estruturado de actividades necessárias para desenvolver sistema de softwareEspecificaçãoDesenhoValidaçãoEvoluçãoModelo de processo de software é representação abstracta de processo, descrevendo-o sob um ponto de vista particular2009/20105Engenharia do Software I

6. Modelos genéricos de processo de softwareHá muitas variantes destes modelos. Por exemplo, o desenvolvimento formal, que usa um processo semelhante ao do modelo em cascata, mas em que a especificação, que é formal, é refinada ao longo de várias etapas até se atingir um desenho implementável.2009/20106Engenharia do Software I

7. Modelo em cascataDefinição de requisitosEtapasDesenho do sistema e do softwareImplementação e testes unitáriosIntegração e testes de sistemaO principal inconveniente deste modelo é que dificulta lidar com mudanças depois do processo estar em andamento. Tem de se completar cada uma das fases antes de avançar para a fase seguinte.Operação e manutenção2009/20107Engenharia do Software I

8. Problemas do modelo em cascataSegmentação inflexível do projecto em etapas distintas dificulta resposta a modificações nos requisitos do clienteApropriado apenas quando requisitos são bem compreendidos e modificações se previrem bastante limitadasSobretudo grandes projectos de engenharia de sistemas com sistema desenvolvido em vários locaisPoucos negócios têm requisitos estáveis.2009/20108Engenharia do Software I

9. Desenvolvimento evolutivo2009/20109Engenharia do Software I

10. Actividades concorrentesDesenvolvimento evolutivoEspecificaçãoVersão inicialDescrição geralDesenvolvimentoVersões intermédiasValidaçãoVersão final2009/201010Engenharia do Software I

11. Desenvolvimento evolutivoProblemasFala de visibilidade do processoSistemas muitas vezes mal estruturadosPodem ser necessárias competências especiais (e.g., em linguagens de prototipagem rápida)AplicabilidadeSistemas interactivos de pequena ou média dimensãoPartes de sistemas de grande dimensão (e.g., interface com utilizador)Sistemas com tempo de vida curto2009/201011Engenharia do Software I

12. Engenharia do software baseada em componentesBaseia-se em reutilização sistemáticaSistemas integrados a partir de componentes existentes ou sistemas comerciais prontos a usarEtapas do processoAnálise de componentesModificação de requisitosDesenho do sistema com reutilizaçãoDesenvolvimento e integraçãoAbordagem mais usada à medida que a normalização de componentes vai progredindo.COTS (Commercial-Off-The-Shelf)2009/201012Engenharia do Software I

13. Desenvolvimento orientado pela reutilizaçãoEspecificação de requisitosAnálise de componentesModificação de requisitosDesenho do sistema com reutilizaçãoDesenvolvimento e integraçãoValidação do sistema2009/201013Engenharia do Software I

14. Iteração de processosRequisitos do sistema evoluem sempre ao longo de um projecto……logo, para sistemas de grande dimensão, iterações do processo são sempre parte desse processoIterações são repetições das etapas iniciais do processo2009/201014Engenharia do Software I

15. Iteração de processosIteração aplica-se a qualquer modelo genérico de processoDuas abordagens (relacionadas)Entrega incrementalDesenvolvimento em espiral2009/201015Engenharia do Software I

16. Entrega incrementalEm vez de entrega única, desenvolvimento e entrega divididos em incrementos, cada um entregando parte da funcionalidadeRequisitos do utilizador prioritizados; requisitos prioritários desenvolvidos primeiroLogo que se inicia desenvolvimento de um incremento, seus requisitos são congelados; requisitos de incrementos posteriores continuam a evoluir2009/201016Engenharia do Software I

17. Desenvolvimento incrementalDefinir visão geral dos requisitosAtribuir requisitos a incrementosDesenhar arquitectura do sistemaDesenvolver incremento do sistemaValidar incrementoIntegrar incrementoValidar sistemaSistema finalSistema incompleto2009/201017Engenharia do Software I

18. Vantagens do desenvolvimento incrementalCada incremento entrega valor ao cliente; funcionalidade do sistema disponível mais cedoIncrementos iniciais como protótipos ajudam eliciação de requisitos para novos incrementosMenor risco de falha global do projectoServiços prioritários do sistema tendem a ser os mais testados2009/201018Engenharia do Software I

19. XP – Extreme ProgrammingAbordagem ao desenvolvimentoBaseada no desenvolvimento e entrega de pequenos incrementos de funcionalidadeAssenta em Melhorias constantes do códigoUtilizador envolvido na equipa de desenvolvimentoProgramação em paresCapítulo 17 do livro. Ver também http://www.extremeprogramming.org/.2009/201019Engenharia do Software I

20. Desenvolvimento em espiralProcesso como espiral e não sequência de actividades com retrocessoEspiras representam fases do processoSem fases fixas como especificação ou desenho – espiras escolhidas segundo necessárioRiscos avaliados e resolvidos explicitamente ao longo do processo2009/201020Engenharia do Software I

21. Modelo em espiral2009/201021Engenharia do Software ICusto cumulativoProgresso ao longo dos passosAvaliação de alternativas, identificação e resolução de riscos.Determinação de objectivos, alternativas e restriçõesAnálise de riscoAnálise de riscoAnálise de riscoProtótipo operacionalPartição de compromissoProtótipo3AnálISE riscoProtótipo2Protótipo1RevisãoSimulaçõesPlan-Req.e ciclovidaModelosConceito de operaçãoBenchmarksRequisitos do softwarePlaneamento de desenvolvimentoDesenho de pormenorDesenho do produto de softwareValidação de requisitosCódigoPlaneamento de integração e testesValidação e verificação do desenhoTESTES UNITÁRIOSPlaneamento das próximas fasesTESTES de integraçãoDesenvolvimento e verificação do produto do próximo nívelTESTES de aceitaçãoImplemen-tação

22. Sectores do modelo espiral2009/201022Engenharia do Software I

23. Actividades do processoEspecificação de softwareDesenho e implementação de softwareValidação de softwareEvolução de software2009/201023Engenharia do Software I

24. Especificação do softwareProcesso de estabelecer serviços requeridos e restrições à operação e desenvolvimento do sistemaProcesso de engenharia de requisitosEstudo de viabilidadeEliciação e análise de requisitosEspecificação de requisitosValidação de requisitos2009/201024Engenharia do Software I

25. Desenho e implementação do softwareProcesso de converter especificação do sistema em sistema executávelDesenho de software – Desenhar estrutura de software realizando especificaçãoImplementação – Traduzir estrutura de software em programa executávelEstas actividades estão intimamente relacionadas e podem ser entrelaçadas2009/201025Engenharia do Software I

26. Actividades do processo de desenhoDesenho arquitecturalEspecificação abstractaDesenho de interfacesDesenho de componentesDesenho de estruturas de dadosDesenho de algoritmos2009/2010Engenharia do Software I26

27. Processo de desenho de software2009/201027Engenharia do Software IEspecificação de requisitosDesenho arquitecturalEspecificação abstractaActividades de desenhoArquitectura do sistemaDesenho de interfacesEspecificação do softwareDesenho de componentesEspecificação da interfaceDesenho de estruturas de dadosEspecificação dos componentesProdutosde desenhoDesenho de algoritmosEspecificação das estruturas de dadosEspecificação dos algoritmos

28. Métodos estruturadosAbordagens sistemáticas ao desenvolvimento de desenhos de softwareDesenho normalmente documentados como conjunto de modelos gráficosModelo de objectosModelo de sequênciaModelo de transição de estadosModelo estruturalModelo de fluxo de dados2009/2010Engenharia do Software I28

29. Programação e depuraçãoTradução de desenho em programa e remoção de erros do programaProgramação é actividade pessoal – não há processo genérico de programaçãoProgramadores efectuam alguns testes para revelar falhas no programa e as remover no processo de depuração2009/2010Engenharia do Software I29No entanto, XP prescreve programação em pares e TDD.

30. Processo de depuração2009/201030Engenharia do Software IDesenhar correcção do erroTestar programa de novoLocalizar erroCorrigir erro

31. Validação de softwareVerificação e validação (V & V) mostra que sistema está conforme especificação e cumpre requisitos do clienteInclui processos de verificação e revisão, bem como testes de sistemaTestes de sistema incluem execução do sistema com casos de teste resultantes da especificação dos dados reais a processar2009/2010Engenharia do Software I31

32. Processo de teste2009/201032Engenharia do Software ITestes de componentesTestes de sistemaTestes de aceitação

33. Etapas de teste2009/2010Engenharia do Software I33

34. Especificação de requisitosServiçoTestes de aceitaçãoFases de teste (modelo em V)2009/201034Engenharia do Software IEspecificação de sistemaDesenho de sistemaTestes de integração de sistemaPlano de testes de integração de subsistemasPlano de testes de integração de sistemasPlano de testes de aceitaçãoDesenho de pormenorTestes de integração de subsistemasCodificação e teste de módulos e unidades

35. Evolução de softwareSoftware inerentemente flexível e mutávelRequisitos mudam devido a alterações nas circunstâncias do negócio, logo software de suporte tem de evoluir e mudar tambémDemarcação entre desenvolvimento e evolução (manutenção) torna-se menos clara à medida que há menos sistemas totalmente novos2009/2010Engenharia do Software I35

36. Evolução de sistema2009/201036Engenharia do Software IAferição dos sistemas existentesDefinição de requisitos do sistemaProposta de modificações ao sistemaModificação dos sistemasSistemas existentesNovo sistema

37. Rational Unified ProcessModelo moderno de processo com origem no trabalho no UML e processo associadoDescrito normalmente segundo três perspectivasDinâmica – Mostra fases ao longo do tempoEstática – Mostra as actividades do processoPrática – Sugere boas práticas2009/2010Engenharia do Software I37

38. Rational Unified ProcessProduto/infra-estrutura que organizações de desenvolvimento de software podem personalizarCombina os três modelos de processo de software genéricosEm cascataEvolutivoBaseado em componentes2009/2010Engenharia do Software I38

39. Modelo de fases do RUP2009/201039Engenharia do Software IIteração de faseComeçoElaboraçãoConstruçãoTransição

40. Fases do RUP2009/2010Engenharia do Software I40

41. O RUP2009/2010Engenharia do Software I41

42. Boas práticas RUPDesenvolver o software iterativamenteGerir os requisitosUsar arquitecturas baseadas em componentesModelar visualmente o softwareVerificar a qualidade do softwareControlar modificações ao software2009/2010Engenharia do Software I42

43. Fluxos de trabalho estáticos2009/2010Engenharia do Software I43

44. Fluxos de trabalho estáticos2009/2010Engenharia do Software I44

45. CASE (Computer-Aided Software Engineering)Software de suporte aos processos de desenvolvimento e evolução de softwareAutomação de actividadesEditores gráficos para desenvolvimento de modelos do sistemaDicionários de dados para gestão das entidades de desenhoConstrutores de interfaces gráficas com o utilizadorDepuradores para suportar a descoberta de falhas nos programasTradutores automatizados para gerar novas versões de um programa2009/2010Engenharia do Software I45

46. Tecnologia CASELevou a melhorias significativas no processo de software, mas não tão grandes se havia previstoEngenharia do software exige pensamento criativo, que não se automatiza facilmenteEngenharia do software é uma actividade de equipa passando-se muito tempo em interacções dentro da equipa quando o projecto é de grande dimensão. A tecnologia CASE não suporta estas interacções.2009/2010Engenharia do Software I46

47. Classificação CASE2009/2010Engenharia do Software I47

48. Classificação funcional2009/2010Engenharia do Software I48

49. Classificação funcional2009/2010Engenharia do Software I49

50. Classificação por actividade2009/2010Engenharia do Software I50

51. Classificação por integração2009/2010Engenharia do Software I51

52. A reterProcessos de software são actividades envolvidas na produção e evolução de sistemas de softwareModelos de processos de software são representações abstractas desses processosActividades gerais são especificação, desenho e implementação, validação e evoluçãoModelos genéricos de processos descrevem organização dos processos de software. Exemplos: em cascata, desenvolvimento evolutivo e engenharia do software baseada em componentes2009/2010Engenharia do Software I52

53. A reterModelos de processos iterativos descrevem processo de software como ciclo de actividadesEngenharia de requisitos é processo de desenvolvimento de especificações de softwareProcessos de desenho e implementação transformam especificação em programa executávelValidação envolve verificar que sistema satisfaz especificação e necessidades dos utilizadores2009/2010Engenharia do Software I53

54. A reterEvolução respeita a modificações no sistema depois de em produçãoRUP é modelo genérico de processo que separa actividades de fasesTecnologia CASE suporta actividades do processo de software2009/2010Engenharia do Software I54

55. A lerIanSommerville, Software Engineering, 8.ª edição, Addison-Wesley, 2006Capítulo 42009/201055Engenharia do Software I