Engenharia de Software I

Transcrição

1 Engenharia de Software I CURSO DE S ISTE MAS DE INFORMAÇÃO KAR LA DONATO FOO K DA NIEL LIMA GO MES JÚNIOR DESU / DCO MP 2017 Engenharia de Software Disciplina de engenhara relacionada com todos os aspectos da produção de software, desde os estágios iniciais de especificação do sistema até sua manutenção Sommerville,

2 Princípios Formalidade Abstração Decomposição Maior confiabilidade durante o processo. Efeitos benéficos durante a manutenção, reutilização, portabilidade e entendimento do software. Generalização Flexibilização 3 Princípios Formalidade Abstração Decomposição Processo de identificação dos aspectos importantes de um problema no qual os pontos irrelevantes devem ser ignorados Maior confiabilidade durante o processo. Generalização Flexibilização 4 2

3 Princípios Formalidade Abstração Decomposição Forma de diminuir a complexidade. Subdivisão de processos em atividades específicas. Generalização Flexibilização 5 Princípios Formalidade Abstração Decomposição A generalização da solução do problema tem maior potencial para permitir reutilização. Generalização Flexibilização 6 3

4 Princípios Formalidade Abstração Decomposição Aplica-se tanto ao processo quanto ao produto. O último sofre mudanças e o processo deve ser flexível para assimilá-las. Generalização Flexibilização 7 Paradigmas ou Modelos de Processos Especificam atividades que devem ser executadas, bem como a ordem de execução Alguns modelos são mais adequados que outros para determinados tipos de aplicação A opção por um determinado modelo deve ser feita considerando-se o produto a ser desenvolvido 8 4

5 Processo de Software Conjunto de atividades, métodos, práticas e transformações que guiam pessoas na produção de software. Um processo eficaz deve, claramente, considerar as relações entre as atividades, os artefatos produzidos no desenvolvimento, as ferramentas e os procedimentos necessários e a habilidade, o treinamento e a motivação do pessoal envolvido. Falbo, Processo de Software Atividades genéricas podem ser organizadas de diferentes maneiras descritas em diferentes níveis de detalhamento para diferentes tipos de software O uso de um processo de software inadequado pode Reduzir a qualidade ou a utilidade do produto de software a ser desenvolvido e/ou Aumentar os custos de desenvolvimento 10 5

6 Processo de Software São, geralmente, decompostos em diversas fases, etapas ou atividades: 1. Planejamento 2. Análise e Especificação de Requisitos 3. Projeto 4. Implementação 5. Testes 6. Entrega e Implantação 7. Operação 8. Manutenção Falbo, Processo de Software Atividades de apoio que se encontram no entorno das atividades principais: 1. Acompanhamento e controle do projeto de software 2. Gestão de risco 3. Garantia da qualidade 4. Revisões Técnicas Formais 5. Medição 6. Gestão de configuração de software 7. Gestão de reusabilidade 8. Preparação e produção do produto de trabalho Pressman,

7 Modelos de Processos de Software Descrição simplificada do processo de software Incluem atividades que fazem parte do processo de software, os produtos de software e os papéis das pessoas envolvidas na engenharia de software 13 Modelos de Processos de Software Modelos Prescritivos Modelo Cascata Modelos de Processo Incremental Modelos de Processo Evolucionário Prototipagem Modelo Espiral Modelos de Processo Especializado Engenharia de software baseada em componentes (CBSE Component Based Software Engineering) Modelo de métodos formais Desenvolvimento de Software Orientado a Aspectos 14 7

8 Modelos de Processos de Software Processo Unificado Modelos de Processo Pessoal e de Equipe 15 Modelo Cascata É o paradigma mais antigo e o mais amplamente usado da Engenharia de Software Também conhecido como Ciclo de Vida de Software Desenvolvimento Sequencial, embora se possa retornar para fase anterior Depois que cada estágio é concluído, o desenvolvimento prossegue para o estágio seguinte 16 8

9 Modelo Cascata Considera as atividades apresentadas anteriormente e as representa como fases separadas do processo Planejamento Análise Projeto Implementação Cada fase produz como resultado um ou mais documentos 17 Modelo Cascata Copyright 2011 John Wiley & Sons, Inc. 18 9

10 Modelo Cascata Os serviços, restrições e objetivos do sistema são definidos por meio de consultas aos usuários do sistema. Copyright 2011 John Wiley & Sons, Inc. 19 Modelo Cascata Os serviços, restrições e objetivos do sistema são analisados e refinados. Copyright 2011 John Wiley & Sons, Inc

11 Modelo Cascata O processo de projeto de sistema divide os requisitos em sistemas de hardware ou de software. Ele estabelece uma arquitetura geral do sistema. Envolve a identificação e a descrições das abstrações fundamentais do sistema de software e suas relações. Copyright 2011 John Wiley & Sons, Inc. 21 Modelo Cascata Nesta etapa, o projeto é realizado como um conjunto de programas ou unidades de programa. Os programas são integrados e testados como um sistema completo para garantir que os requisitos de software foram atendidos. Após os testes, o sistema de software é liberado para o cliente. Copyright 2011 John Wiley & Sons, Inc

12 Modelo Cascata Doc. com informações iniciais do Sistema Doc. de Especificação de Requisitos Doc. de Especificação de Projeto Coleção de Programas Implementados e Testados Copyright 2011 John Wiley & Sons, Inc. 23 Limitações Modelo Cascata Os projetos reais raramente seguem o fluxo sequencial (e top-down ) que propõe o modelo Sempre ocorrem interações e às vezes existem problemas na aplicação do paradigma É difícil tanto para o cliente como para o analista estabelecer no principio, explicitamente, todos os requisitos Ciclo de vida clássico tem dificuldades em expressar possíveis incertezas do cliente e do analista A versão funcional da aplicação somente estará disponível nas etapas finais do desenvolvimento do projeto 24 12

13 Modelo Cascata Deve ser usado apenas quando os requisitos forem bem compreendidos e houver pouca probabilidade de mudanças radicais durante o desenvolvimento do sistema Reflete o tipo de modelo de processo usado em outros projetos de engenharia 25 Variantes do Modelo Cascata Há duas variantes Desenvolvimento Paralelo Modelo V 26 13

14 Desenvolvimento Paralelo Copyright 2011 John Wiley & Sons, Inc. 27 Desenvolvimento Paralelo Um projeto geral (ou concepção) é criado e dividido em uma série de subprojetos distintos que pode ser concebidos e em paralelo Após a conclusão destes, há a integração final do das partes separadas 28 14

15 Desenvolvimento Paralelo Vantagem Reduz o tempo de distribuição do sistema Diminui as chances de as alterações que ocorrem no ambiente da empresa causarem retrabalho Limitações Problemas ocasionados pelos volumosos produtos resultantes Se os projetos não forem completamente independentes, as decisões de concepção (design) tomadas em um subprojeto pode afetar outro Isto dificulta a integração dos subprojetos 29 Modelos de Processo Incremental Clientes identificam os serviços mais e menos importantes, definindo um número de entrega de incremento Serviços de mais alta prioridade são entregues primeiro O primeiro incremento é um produto essencial, onde os requisitos básicos são atendidos 30 15

16 Modelos de Processo Incremental INCREMENTAL 31 Modelos de Processo Incremental Após a conclusão e entrega de um incremento, este é posto em operação clientes podem experimentar parte da funcionalidade do sistema de software Isto ajuda a conhecer os requisitos dos incrementos posteriores e das versões posteriores da atual 32 16

17 Modelos de Processo Incremental Vantagens 1. Clientes não precisam esperar até a entrega do sistema inteiro para se beneficiar dele. O 1º incremento satisfaz os requisitos mais críticos 2. Clientes podem usar os incrementos iniciais como protótipos e ganhar experiência 33 Modelos de Processo Incremental Vantagens (cont.) 3. Existe um risco menor de falha geral do projeto 4. Como os serviços de prioridade mais alta são entregues primeiro, e os incrementos posteriores são integrados a eles, os sistemas mais importantes recebem mais testes os clientes têm menos probabilidade de de encontrar falhas de software nas partes mais importantes do sistema 34 17

18 Modelos de Processo Incremental Desvantagens 1. Os incrementos devem ser relativamente pequenos (ter menos que 20 mil linhas de código) 2. Cada incremento deve entregar alguma funcionalidade do sistema de software Difícil mapeamento 3. Pode ser difícil identificar os recursos comuns a todos os incrementos 35 Modelos de Processo Evolucionário Baseiam-se no desenvolvimento e implementação de um produto inicial, que é submetido aos comentários e críticas do usuário O produto vai sendo refinado através de múltiplas versões, até que o produto de software almejado seja desenvolvido 36 18

19 Modelos de Processo Evolucionário As atividades de desenvolvimento e validação são desempenhadas paralelamente, havendo feedback entre elas O sistema pode ser entregue ou reimplementado utilizando uma abordagem mais estruturada, para produzir um sistema mais robusto e mais fácil de ser mantido Em Geral, é mais efetivo que o Ciclo de Vida Clássico, mas apresenta problemas de gerenciamento 37 Modelos de Processo Evolucionário Especificação Versão inicial Descrição do esboço Desenvolvimento Versões intermediárias Validação Versão final 38 19

20 Modelos de Processo Evolucionário Desenvolvimento Exploratório O objetivo do processo é trabalhar com o cliente para explorar seus requisitos e entregar um sistema final Se inicia com as partes do sistema que são compreendidas O sistema evolui com o acréscimo de novas características, conforme o cliente 39 Modelos de Processo Evolucionário: Prototipagem Executa o processo a fim de desenvolver rápido uma versão simplificada do sistema. O protótipo é uma versão rápida e mal feita que fornece uma quantidade mínima de recursos. Copyright 2011 John Wiley & Sons, Inc

21 Modelos de Processo Evolucionário: Prototipagem Prototipagem throwaway ou Protótipos descartáveis Copyright 2011 John Wiley & Sons, Inc. 41 Modelos de Processo Evolucionário: Prototipagem Prototipagem throwaway ou Protótipos descartáveis O objetivo do processo é compreender os requisitos do cliente O protótipo se concentra em fazer experimentos com partes dos requisitos que estejam mal compreendidos Copyright 2011 John Wiley & Sons, Inc

22 Problemas Modelos de Processo Evolucionário: Prototipagem Cliente enxerga protótipo como produto final Prototipação é eficiente? 43 Modelos de Processo Evolucionário: Considerações O processo não é visível Documentos necessários para medir o progresso no desenvolvimento deixam de ser produzidos em virtude da velocidade de elaboração de versões do produto Em geral, os sistemas são mal estruturados As estruturas são prejudicadas pelas mudanças constantes O desenvolvedor pode assumir como definitivas escolhas feitas como temporárias Um Sistema Operacional inapropriado pode ser usado porque é conhecido, ou algoritmos ineficientes podem ser implementados para demonstrar possibilidades do Sistema 44 22

23 Modelos de Processo Evolucionário: Modelo Espiral Desenvolvimento do sistema evolui em uma espiral para fora a partir de um esboço inicial, em direção ao sistema final desenvolvido Proposto por Boehm (1988) Foi desenvolvido para englobar as melhores características do ciclo de vida clássico e do paradigma evolutivo, adicionando ainda um novo elemento, a análise de risco Não existem fases fixas neste paradigma 45 Modelos de Processo Evolucionário: Modelo Espiral Trabalha com risco Risco circunstância adversa que pode atrapalhar o processo de desenvolvimento e a qualidade do produto a ser desenvolvido 46 23

24 Modelos de Processo Evolucionário: Modelo Espiral 47 Modelos de Processo Evolucionário: Modelo Espiral Determinação dos objetivos, alternativas e restrições e de Riscos 48 24

25 Modelos de Processo Evolucionário: Modelo Espiral Análise de alternativas e identificação/resolução dos riscos 49 Modelos de Processo Evolucionário: Modelo Espiral Escolha de um modelo de desenvolvimento para o sistema 50 25

26 Modelos de Processo Evolucionário: Modelo Espiral Traça os planos para a próxima fase do projeto 51 Modelos de Processo Evolucionário: Modelo Espiral A decisão de como estruturar o processo de desenvolvimento de Software em fases é tomada durante o Planejamento A principal diferença entre este modelo e os demais é o reconhecimento explícito do risco Exemplo Se a intenção for usar uma nova Linguagem de Programação, um risco é que os compiladores disponíveis não sejam confiáveis ou não produzam código-objeto suficientemente eficaz 52 26

27 Modelos de Processo Evolucionário: Modelo Espiral Problemas Difícil de convencer o cliente da abordagem evolutiva ser controlável Exige experiência na avaliação dos riscos Vantagens Abordagem realística Abordagem evolucionária Prototipação Interativa Redução de riscos 53 CBSE Component Based Software Engineering Engenharia de software baseada em componentes Baseia-se na existência de um número significativo de componentes reusáveis O processo de desenvolvimento concentra-se na integração desses componentes, em vez de desenvolvêlos a partir do zero 54 27

28 CBSE Component Based Software Engineering Especificação de requisitos Análise de componentes Modificação de requisitos Projeto de sistema com reuso Desenvolvimento e integração Evolução de sistema 55 CBSE Component Based Software Engineering Especificação de requisitos Análise de componentes Modificação de requisitos Projeto Dada de uma sistema especificação de requisitos, uma busca pelos Desenvolvimento Evolução componentes reuso para implementar e integração essas especificações é de feita. sistema Não existe correspondência exata e os componentes que podem ser usados fornecem apenas uma parte da funcionalidade necessária

29 CBSE Component Based Software Engineering Especificação de requisitos Análise de componentes Modificação de requisitos Os requisitos são analisados usando as informações Projeto de sistema sobre os componentes encontrados. Desenvolvimento Eles são modificados Evolução com reuso e integração de sistema para refletir os componentes disponíveis. Quando as modificações são impossíveis, a atividade de análise de componentes pode ser novamente realizada para buscar soluções alternativas. 57 CBSE Component Based Software Engineering O framework do sistema é projetado ou um framework existente é reusado. Os projetistas levam em consideração os componentes reusados, organizando o framework para eles. Especificação Análise de Modificação de requisitos Pode ser necessário projetar algum software novo caso os componentes de requisitos componentes reusáveis não estejam disponíveis. Projeto de sistema com reuso Desenvolvimento e integração Evolução de sistema 58 29

30 CBSE Component Based Software Engineering O software que não pode ser adquirido externamente é desenvolvido e os componentes e os sistemas COTS (Commercial Off-The-Shelf Systems) são integrados para criar o Especificação Análise de Modificação de novo requisitos sistema. A integração de sistema, neste modelo, pode ser componentes de requisitos parte do processo de desenvolvimento, em vez de ser uma atividade separada. Projeto de sistema com reuso Desenvolvimento e integração Evolução de sistema 59 CBSE Component Based Software Engineering Vantagens Reutilização de código Reduz a quantidade de software a ser desenvolvido e, consequentemente, reduz custos e riscos Leva a entrega mais rápida do software Desvantagens Indisponibilidade de código fonte Algum controle sobre a evolução do sistema será perdido se novas versões dos componentes reusáveis não estiverem sob controle da organização que as utiliza 60 30

31 Modelos de Processos Embora não exista um processo de software ideal, existe espaço para aprimoramento do processo de software em várias organizações Os processos de software podem ser aprimorados por meio da padronização de processo, na qual a diversidade é reduzida 61 Modelos de Processos Os modelos apresentados não são mutuamente exclusivos e podem ser utilizados em conjunto, especialmente se o sistema é de grande porte Outras variações desses modelos genéricos foram propostos O desenvolvimento formal de sistemas, no qual é criado um modelo matemático formal de um sistema 62 31

32 Qual Modelo de Processo? Critérios para Seleção Relacionados aos usuários e à equipe Experiência dos usuários no Domínio da Aplicação Facilidade de expressão dos usuários Experiência da equipe no Domínio da Aplicação Experiência da equipe em Engenharia de Software Disponibilidade de recursos humanos para a equipe Relacionados ao produto Tamanho e complexidade da Aplicação Grau de importância dos requisitos de interface 63 Qual Modelo de Processo? Critérios para Seleção Relacionados ao problema Grau de maturidade no Domínio da Aplicação Complexidade do problema Frequência e complexidade das mudanças nos requisitos Modularidade do problema Relacionados ao desenvolvimento Necessidade de entrega de produtos intermediários Grau de riscos técnicos Paradigma de desenvolvimento adotado 64 32

33 Qual Modelo de Processo? 65 Processo de desenvolvimento na realidade Engenharia de Software: Teoria e Prática Shari Lawrence Pfleeger 66 33

34 Atividades em comum em processos de software 67 Atividades em comum em processos de software Especificação Desenvolvimento Validação Evolução 68 34

35 Atividades em comum em processos de software Especificação Desenvolvimento Validação Evolução 69 Fase de Especificação A funcionalidade do software e as restrições sobre sua operação devem ser definidas O quê? Que dados tem que ser processados? Que função e desempenho são desejados? Que interfaces devem ser estabelecidas? Que restrições? Etapas Análise do sistema Análise de requisitos 70 35

36 Atividades em comum em processos de software Especificação Desenvolvimento Validação Evolução 71 Fase de Desenvolvimento Projeto e Implementação É o processo de conversão de uma especificação de sistema em um sistema executável Como? Como a estrutura de dados e arquitetura de software são projetadas? Como os detalhes procedimentais serão implementados? 72 36

37 Projeto Engloba a descrição da estrutura de software a ser implementada dos dados que são parte do sistema das interfaces entre os componentes dos algoritmos usados (às vezes) Envolve a inclusão de formalidades e detalhes Pode envolver o desenvolvimento de vários modelos do sistema em diferentes níveis de abstração 73 Implementação Desenvolvimento dos programas do sistema Atividade pessoal e, em geral, não segue processo Uso de ferramentas CASE para geração de esqueleto do programa com base no projeto 74 37

38 Atividades da fase de Desenvolvimento Projeto de arquitetura Especificação abstrata Projeto de interface Arquitetura de sistema Especificação de software Especificação de interface Projeto de componente Projeto de Estrutura de dados Projeto de algoritmo Especificação de componente Especificação de estrutura de dados Especificação de algoritmo 75 Atividades da fase de Desenvolvimento Codificação... Codificação Programas Programas 76 38

39 Atividades em comum em processos de software Especificação Desenvolvimento Validação Evolução 77 Fase de Validação O software deve ser validado para garantir que ele faça o que o cliente deseja Como os testes serão realizados? Etapas Codificação Realização de testes unitários Realização de testes de software 78 39

40 Fase de Validação Teste de componente Teste de sistema Teste de aceitação 79 Fase de Validação Teste de componente Teste de sistema Teste de aceitação Usa dados reais 80 40

41 Fase de Validação Geralmente, o desenvolvimento e teste de componentes são intercalados No caso da abordagem incremental, cada incremento deve ser testado à medida que é incrementado 81 Atividades em comum em processos de software Especificação Desenvolvimento Validação Evolução 82 41

42 Fase de Evolução Mudanças geram manutenções Correção de erros Adaptação Ampliação 83 Fase de Evolução Tipos de manutenção Corretiva Adaptativa Perfectiva Preventiva 84 42

43 Fase de Evolução Tipos de manutenção Corretiva Adaptativa Perfectiva Preventiva Trata de problemas decorrentes de defeitos. À medida que falhas ocorrem, elas são relatadas à equipe de manutenção, que se encarrega de encontrar o defeito que causou a falha e faz as correções (nos requisitos, análise, projeto ou implementação), conforme o necessário. Esse reparo inicial pode ser temporário, visando manter o sistema funcionando. Quando esse for o caso, mudanças mais complexas podem ser implementadas posteriormente. Falbo, Fase de Evolução Tipos de manutenção Corretiva Adaptativa Perfectiva Preventiva Às vezes, uma mudança no ambiente do sistema, incluindo hardware e software de apoio, pode implicar em uma necessidade de adaptação. Falbo,

44 Fase de Evolução Tipos de manutenção Corretiva Adaptativa Perfectiva Preventiva Consiste em realizar mudanças para melhorar algum aspecto do sistema, mesmo quando nenhuma das mudanças for consequência de defeitos. Isso inclui a adição de novas capacidades bem como ampliações gerais. Falbo, Fase de Evolução Tipos de manutenção Corretiva Adaptativa Perfectiva Preventiva Consiste em realizar mudanças a fim de prevenir falhas. Geralmente ocorre quando um mantenedor descobre um defeito que ainda não causou falha e decide corrigi-lo antes que ele gere uma falha. Falbo,

45 Fase de Evolução A distinção entre o desenvolvimento e manutenção tem se tornado cada vez mais irrelevante (Sommerville, 2007) 89 Modelagem do Processo de Software 45

46 Porque modelar o Processo de Software? A importância em descrever o processo de software tem sido discutida na literatura de engenharia de software como uma das formas de suporte À qualidade do produto de software À sistematização das práticas empregadas durante o desenvolvimento, Para aumentar a maturidade do processo de software estabelecer uma baseline para avaliação e melhoria Modelagem do Processo A descrição de processo de software permite detalhar o processo de software real executado em organizações de desenvolvimento possibilitar que falhas no processo sejam detectadas e corrigidas 92 46

47 Modelagem do Processo A descrição de processos contribui sob vários aspectos no processo de desenvolvimento A padronização do processo é necessária para permitir o treinamento, elaboração de guias, gerenciamento, revisão e automação Com a padronização de métodos, cada experiência de projeto pode contribuir para uma melhoria global em uma organização 93 Modelagem do Processo Processos padronizados provêem uma infra-estrutura básica para melhoria, avaliação e mensuração Porque tarefas básicas são comuns em muitos projetos de software, apenas algumas customizações seriam necessárias para um processo padrão atender à maioria das necessidades de projetos 94 47

48 Modelagem do Processo Fonte: UFPA 95 Modelos --- > Ferramentas... 48

49 Ferramenta utilizada para descrever processos de software Spearmint Software Process Elicitation, Analysis, Review and Modeling in an Integrated Environment 97 Ferramentas utilizadas para descrever processos de software Spearmint Software Process Elicitation, Analysis, Review and Modeling in an Integrated Environment 98 49

50 Ferramenta utilizada para descrever processos de software Promodeller (Ebert, 2009) UFPE 99 Ferramenta utilizada para descrever processos de software

51 Propriedades desejáveis das ferramentas e técnicas para modelagem de processos Facilitar o entendimento humano e a comunicação Apoiar a melhoria do processo Apoiar o gerenciamento do processo Fornecer orientação automatizada para a utilização do processo Apoiar a execução automatizada do processo (Pfleeger, 2004) 51