Engenharia de Software I

Engenharia de Software I Curso de Sistemas de Informação Karla Donato Fook karladf@ifma.edu.br DESU / DAI 2016 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, 2007 2 1

Princípios Formalidade Abstração Decomposição Generalização Flexibilização 3 Princípios Formalidade Abstração Decomposição Generalização Maior confiabilidade durante o processo. Efeitos benéficos durante a manutenção, reutilização, portabilidade e entendimento do software. Flexibilização 4 2

Princípios Formalidade Abstração Decomposição Generalização Processo de identificação dos aspectos importantes de um problema no qual os pontos irrelevantes devem ser ignorados Maior confiabilidade durante o processo. Flexibilização 5 Princípios Formalidade Abstração Decomposição Generalização Forma de diminuir a complexidade. Subdivisão de processos em atividades específicas. Flexibilização 6 3

Princípios Formalidade Abstração Decomposição Generalização Flexibilização A generalização da solução do problema tem maior potencial para permitir reutilização. 7 Princípios Formalidade Abstração Decomposição Generalização Flexibilização Aplica-se tanto ao processo quanto ao produto. O último sofre mudanças e o processo deve ser flexível para assimilá-las. 8 4

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 considerandose o produto a ser desenvolvido 9 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, 2005 10 5

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 11 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, 2005 12 6

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, 2006 13 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 14 7

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 15 Modelos de Processos de Software Processo Unificado Modelos de Processo Pessoal e de Equipe 16 8

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 17 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 18 9

Modelo Cascata Copyright 2011 John Wiley & Sons, Inc. 19 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. 20 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. 21 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. 22 11

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. 23 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. 24 12

Limitações Modelo Cascata Os projetos reais raramente seguem o fluxo sequencial (e topdown ) 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 25 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 26 13

Variantes do Modelo Cascata Há duas variantes Desenvolvimento Paralelo Modelo V 27 Desenvolvimento Paralelo Copyright 2011 John Wiley & Sons, Inc. 28 14

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 29 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 30 15

Modelo V Copyright 2011 John Wiley & Sons, Inc. 31 Modelo V Prossegue para baixo na linha inclinada, definindo requisitos e determinando componentes do sistema. Copyright 2011 John Wiley & Sons, Inc. 32 16

Modelo V Na base do V, o código é escrito. Copyright 2011 John Wiley & Sons, Inc. 33 Modelo V Na linha inclinada para cima, São realizados os testes dos Componentes, testes de integração e os testes de aceitação do sistema. Copyright 2011 John Wiley & Sons, Inc. 34 17

Modelo V Um conceito fundamental neste modelo é que, quando os requisitos forem especificados e os componentes determinados, os testes destes elementos também ficarão definidos. Cada nível de teste é relacionado com uma fase da Análise ou Projeto. Isso maximiza a efetividade dos testes. Copyright 2011 John Wiley & Sons, Inc. 35 Modelo V Vantagens É direto e melhora a qualidade dos sistemas por intermédio da ênfase no planejamento precoce dos testes O foco e a prática dos testes estão presentes na fase inicial do projeto Desvantagem Ainda sofre com a rigidez do desenvolvimento em cascata Não se mostra apropriado para a natureza dinâmica do ambiente empresarial 36 18

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 37 Modelos de Processo Incremental INCREMENTAL 38 19

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 39 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 40 20

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 41 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 42 21

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 43 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 44 22

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 45 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 46 23

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. 47 Modelos de Processo Evolucionário: Prototipagem Prototipagem throwaway ou Protótipos descartáveis Copyright 2011 John Wiley & Sons, Inc. 48 24

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. 49 Modelos de Processo Evolucionário: Prototipagem Problemas Cliente enxerga protótipo como produto final Prototipação é eficiente? 50 25

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 51 para demonstrar possibilidades do Sistema 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 52 26

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 53 Modelos de Processo Evolucionário: Modelo Espiral 54 27

Modelos de Processo Evolucionário: Modelo Espiral Determinação dos objetivos, alternativas e restrições e de Riscos 55 Modelos de Processo Evolucionário: Modelo Espiral Análise de alternativas e identificação/resolução dos riscos 56 28

Modelos de Processo Evolucionário: Modelo Espiral Escolha de um modelo de desenvolvimento para o sistema 57 Modelos de Processo Evolucionário: Modelo Espiral Traça os planos para a próxima fase do projeto 58 29

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 59 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 Modelo novo Vantagens Abordagem realística Abordagem evolucionária Prototipação Interativa Redução de riscos 60 30

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 61 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 Validação de sistema 62 31

CBSE Component Based Software Engineering Especificação de requisitos Análise de componentes Modificação de requisitos Dada Projeto uma de sistema especificação de requisitos, uma busca pelos Desenvolvimento Validação componentes reusopara implementar e integração essas especificações de sistema é feita. Não existe correspondência exata e os componentes que podem ser usados fornecem apenas uma parte da funcionalidade necessária. 63 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 Validaçã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. 64 32

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 Pode requisitos 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 Validação de sistema 65 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 novo Análise de Modificação de 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 Validação de sistema 66 33

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 67 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 68 34

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 69 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 70 35

Modelos de Processos de Software Processo Unificado Modelos de Processo Pessoal e de Equipe 71 Pesquisa: Modelos de Processos Temas Modelo de métodos formais Desenvolvimento de Software Orientado a Aspectos Processo Unificado Modelos de Processo Pessoal e de Equipe Vide Página da disciplina 72 36

Resumindo... 73 Qual Modelo de Processo? 74 37

Processo de desenvolvimento na realidade Engenharia de Software: Teoria e Prática Shari Lawrence Pfleeger 75 Atividades em comum em processos de software Especificação Desenvolvimento Validação Evolução 76 38

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

Atividades em comum em processos de software Especificação Desenvolvimento Validação Evolução 79 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? 80 40

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 81 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 82 41

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 83 Atividades da fase de Desenvolvimento Codificação... Codificação Programas Programas 84 42

Atividades em comum em processos de software Especificação Desenvolvimento Validação Evolução 85 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 86 43

Fase de Validação Teste de componente Teste de sistema Teste de aceitação 87 Fase de Validação Teste de componente Teste de sistema Teste de aceitação Usa dados reais 88 44

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 89 Atividades em comum em processos de software Especificação Desenvolvimento Validação Evolução 90 45

Fase de Evolução Mudanças geram manutenções Correção de erros Adaptação Ampliação 91 Fase de Evolução Tipos de manutenção Corretiva Adaptativa Perfectiva Preventiva 92 46

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, 2009 93 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, 2009 94 47

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, 2009 95 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, 2009 96 48

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

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 99 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 100 50

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 101 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 102 51

Modelagem do Processo Fonte: UFPA 103 Modelos --- > Ferramentas... 52

Ferramenta utilizada para descrever processos de software Spearmint Software Process Elicitation, Analysis, Review and Modeling in an Integrated Environment 105 Ferramentas utilizadas para descrever processos de software Spearmint Software Process Elicitation, Analysis, Review and Modeling in an Integrated Environment 106 53

Ferramenta utilizada para descrever processos de software Promodeller (Ebert, 2009) UFPE 107 Ferramenta utilizada para descrever processos de software 108 54

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) 55