Engenharia de Software Captulo 3 Processos de Software

  • Slides: 49
Download presentation
Engenharia de Software Capítulo 3 – Processos de Software Slides do Livro do Sommerville,

Engenharia de Software Capítulo 3 – Processos de Software Slides do Livro do Sommerville, 2000 Disponíveis em inglês em www. software-engin. com Apresentados por Bernadette Farias Lóscio Slides traduzidos por Jacinta Pereira Graduando do Curso de Letras da UFC e cedidos pela Profa. Rossana Andrade ©Ian Sommerville 2000 Software Engineering, 6 th edição. Cápítulo 3 Slide 1

Processos de Software l Conjuntos de atividades coerentes para especificar, projetar, implementar e testar

Processos de Software l Conjuntos de atividades coerentes para especificar, projetar, implementar e testar sistemas de software ©Ian Sommerville 2000 Software Engineering, 6 th edição. Cápítulo 3 Slide 2

Objetivos l l Introduzir modelos de processo de software Descrever uma variedade de modelos

Objetivos l l Introduzir modelos de processo de software Descrever uma variedade de modelos de processo e quando eles podem ser usados Descrever esboços de modelos de processo para engenharia de requisitos, desenvolvimento de software, teste e evolução Apresentar a tecnologia CASE para dar suporte às atividades de processo de software ©Ian Sommerville 2000 Software Engineering, 6 th edição. Cápítulo 3 Slide 3

Tópicos abordados l l l l Modelos de processo de software Iteração do Processo

Tópicos abordados l l l l Modelos de processo de software Iteração do Processo Especificação de Software Projeto e implementação do Software Validação do Software Evolução do Software Suporte de processo automatizado ©Ian Sommerville 2000 Software Engineering, 6 th edição. Cápítulo 3 Slide 4

O processo de software l Um conjunto estruturado de atividades requeridas para desenvolver um

O processo de software l Um conjunto estruturado de atividades requeridas para desenvolver um sistema de software • • l Especificação Projeto Validação Evolução Um modelo de processo de software é uma representação abstrata de um processo. Apresenta uma descrição de um processo de alguma perspectiva particular ©Ian Sommerville 2000 Software Engineering, 6 th edição. Cápítulo 3 Slide 5

Modelos genéricos de processo de software l O modelo cascata • l Desenvolvimento evolucionário

Modelos genéricos de processo de software l O modelo cascata • l Desenvolvimento evolucionário • l Especificação e desenvolvimento são entrelaçados Desenvolvimento Formal de sistemas • l Separa e distingue fases de especificação e desenvolvimento Um modelo de sistema matemático é formalmente transformado para uma implementação Desenvolvimento baseado na reutilização • O sistema é montado a partir de componentes existentes ©Ian Sommerville 2000 Software Engineering, 6 th edição. Cápítulo 3 Slide 6

Modelo Cascata ©Ian Sommerville 2000 Software Engineering, 6 th edição. Cápítulo 3 Slide 7

Modelo Cascata ©Ian Sommerville 2000 Software Engineering, 6 th edição. Cápítulo 3 Slide 7

Fases do modelo cascata l l l Análise e definição de requisitos Projeto do

Fases do modelo cascata l l l Análise e definição de requisitos Projeto do sistema e do software Implementação e teste da unidade Integração e teste do sistema Operação e manutenção A desvantagem do modelo cascata é a dificuldade de acomodar mudanças depois que o processo está em andamento ©Ian Sommerville 2000 Software Engineering, 6 th edição. Cápítulo 3 Slide 8

Problemas do modelo cascata l l l Partição inflexível do projeto em diferentes estágios

Problemas do modelo cascata l l l Partição inflexível do projeto em diferentes estágios Isto faz com que seja difícil responder aos requisitos mutáveis dos clientes Portanto, este modelo só é apropriado quando os requisitos são bem entendidos ©Ian Sommerville 2000 Software Engineering, 6 th edição. Cápítulo 3 Slide 9

Desenvolvimento evolucionário l Desenvolvimento exploratório • l O objetivo é trabalhar com clientes e

Desenvolvimento evolucionário l Desenvolvimento exploratório • l O objetivo é trabalhar com clientes e evoluir o sistema final de um esboço de especificação inicial. Deve começar com os requisitos que estão bem entendidos Preparação de protótipos descartáveis • Objetivo é entender os requisitos do sistema. Deve começar com requisitos pobrementendidos ©Ian Sommerville 2000 Software Engineering, 6 th edição. Cápítulo 3 Slide 10

Desenvolvimento evolucionário ©Ian Sommerville 2000 Software Engineering, 6 th edição. Cápítulo 3 Slide 11

Desenvolvimento evolucionário ©Ian Sommerville 2000 Software Engineering, 6 th edição. Cápítulo 3 Slide 11

Desenvolvimento evolucionário l Problemas • • • l Falta de visibilidade do processo Sistemas

Desenvolvimento evolucionário l Problemas • • • l Falta de visibilidade do processo Sistemas são, em geral, pobremente estruturados Habilidades especiais (ex. em línguas para rápida preparação de protótipos ) podem ser requeridas Aplicabilidade • • • Para sistemas interativos pequenos ou médios Para partes de sistemas grandes (ex. a interface de usuário) Para sistemas de curto-prazo ©Ian Sommerville 2000 Software Engineering, 6 th edição. Cápítulo 3 Slide 12

Desenvolvimento de sistemas formais l l l Baseado na transformação de uma especificação matemática

Desenvolvimento de sistemas formais l l l Baseado na transformação de uma especificação matemática através de diferentes representações para um programa executável Transformações são ‘preservadoras de exatidão’, portanto, são diretas para mostrar que o programa está de acordo com sua especificação Contido na abordagem ‘Cleanroom’ para desenvolvimento de software ©Ian Sommerville 2000 Software Engineering, 6 th edição. Cápítulo 3 Slide 13

Desenvolvimento de sistemas formais ©Ian Sommerville 2000 Software Engineering, 6 th edição. Cápítulo 3

Desenvolvimento de sistemas formais ©Ian Sommerville 2000 Software Engineering, 6 th edição. Cápítulo 3 Slide 14

Transformações Formais ©Ian Sommerville 2000 Software Engineering, 6 th edição. Cápítulo 3 Slide 15

Transformações Formais ©Ian Sommerville 2000 Software Engineering, 6 th edição. Cápítulo 3 Slide 15

Desenvolvimento de sistemas formais l Problemas • • l Necessidade de habilidades especializadas e

Desenvolvimento de sistemas formais l Problemas • • l Necessidade de habilidades especializadas e treinamento para aplicar a técnica Difícil de especificar formalmente alguns aspectos do sistema como a interface de usuário Aplicabilidade • Sistemas críticos, especialmente aqueles no qual um case de segurança deve ser feito antes do sistema ser posto em operação ©Ian Sommerville 2000 Software Engineering, 6 th edição. Cápítulo 3 Slide 16

Desenvolvimento orientado ao reuso l l Baseado no reuso sistemático, onde os sistemas são

Desenvolvimento orientado ao reuso l l Baseado no reuso sistemático, onde os sistemas são integrados de componentes existentes ou sistemas padronizados Estágios do Processo • • l Análise do componente Modificação dos requisitos Projeto do sistema com reuso Desenvolvimento e integração Esta abordagem está se tornando mais importante, mas a experiência ainda é limitada com ela ©Ian Sommerville 2000 Software Engineering, 6 th edição. Cápítulo 3 Slide 17

Desenvolvimento orientado ao reuso ©Ian Sommerville 2000 Software Engineering, 6 th edição. Cápítulo 3

Desenvolvimento orientado ao reuso ©Ian Sommerville 2000 Software Engineering, 6 th edição. Cápítulo 3 Slide 18

Iteração do Processo l l l Requisitos do sistema SEMPRE evoluem no decorrer de

Iteração do Processo l l l Requisitos do sistema SEMPRE evoluem no decorrer de um projeto, então a iteração do processo, onde estágios anteriores são retrabalhados, é sempre parte de um processo para sistemas maiores Iteração pode ser aplicada para qualquer modelo de processo genérico Duas abordagens (relacionadas) • • Desenvolvimento incremental Desenvolvimento espiral ©Ian Sommerville 2000 Software Engineering, 6 th edição. Cápítulo 3 Slide 19

Desenvolvimento incremental l Ao invés de entregar o sistema de uma única vez, o

Desenvolvimento incremental l Ao invés de entregar o sistema de uma única vez, o desenvolvimento e a entrega é dividida em incrementos com cada incremento entregando parte da funcionalidade requerida Os requisitos dos usuários são priorizados e os requisitos de maior prioridade são incluídos em incrementos iniciais Uma vez que o desenvolvimento de um incremento é iniciado, os requisitos são congelados embora requisitos para incrementos posteriores possam continuar a evoluir ©Ian Sommerville 2000 Software Engineering, 6 th edição. Cápítulo 3 Slide 20

Desenvolvimento incremental ©Ian Sommerville 2000 Software Engineering, 6 th edição. Cápítulo 3 Slide 21

Desenvolvimento incremental ©Ian Sommerville 2000 Software Engineering, 6 th edição. Cápítulo 3 Slide 21

Vantagens do desenvolvimento incremental l l O valor agregado ao Cliente está na entrega

Vantagens do desenvolvimento incremental l l O valor agregado ao Cliente está na entrega em cada incremento de modo que a funcionalidade do sistema estará disponível mais cedo Incrementos iniciais funcionam como protótipos para ajudar a evocar requisitos para incrementos posteriores Menores riscos de falha no projeto em geral Os serviços do sistema de alta prioridade tendem a receber a maioria dos testes ©Ian Sommerville 2000 Software Engineering, 6 th edição. Cápítulo 3 Slide 22

Programação extrema l l Nova abordagem para o desenvolvimento de software baseado no desenvolvimento

Programação extrema l l Nova abordagem para o desenvolvimento de software baseado no desenvolvimento e entrega de incrementos de funcionalidade bem pequenos Conta com melhoramento constante do código, envolvimento do usuário no time de desenvolvimento e programação em pares ©Ian Sommerville 2000 Software Engineering, 6 th edição. Cápítulo 3 Slide 23

Desenvolvimento espiral l l Processo é representado como uma espiral ao invés de uma

Desenvolvimento espiral l l Processo é representado como uma espiral ao invés de uma seqüência de atividades com retorno Cada volta na espiral representa uma fase no processo. Não existem fases fixas como especificação ou projeto – as voltas na espiral são escolhidas de acordo com o que é requerido Os riscos são explicitamente cotados e resolvidos durante todo o processo ©Ian Sommerville 2000 Software Engineering, 6 th edição. Cápítulo 3 Slide 24

Modelo espiral do processo de software ©Ian Sommerville 2000 Software Engineering, 6 th edição.

Modelo espiral do processo de software ©Ian Sommerville 2000 Software Engineering, 6 th edição. Cápítulo 3 Slide 25

Setores do modelo espiral l Estabelecimento de objetivos • l Avaliação e redução de

Setores do modelo espiral l Estabelecimento de objetivos • l Avaliação e redução de riscos • l Os riscos são avaliados e atividades postas em prática para reduzir os riscos principias Desenvolvimento e validação • l Objetivos específicos para a fase são identificados Um modelo de desenvolvimento para o sistema é escolhido, podendo ser qualquer um dos modelos genéricos Planejamento • O projeto é revisado e a fase seguinte da espiral é planejada ©Ian Sommerville 2000 Software Engineering, 6 th edição. Cápítulo 3 Slide 26

Especificação do Software l l O processo de estabelecer que serviços são requisitados e

Especificação do Software l l O processo de estabelecer que serviços são requisitados e quais as restrições na operação e desenvolvimento do sistema Processo de engenharia de requisitos • • Estudo de viabilidade Elicitação e análise dos requisitos Especificação dos requisitos Validação dos requisitos ©Ian Sommerville 2000 Software Engineering, 6 th edição. Cápítulo 3 Slide 27

O processo de engenharia de requisitos ©Ian Sommerville 2000 Software Engineering, 6 th edição.

O processo de engenharia de requisitos ©Ian Sommerville 2000 Software Engineering, 6 th edição. Cápítulo 3 Slide 28

Projeto e implementação de Software l l O processo de converter a especificação do

Projeto e implementação de Software l l O processo de converter a especificação do sistema em um sistema executável Projeto de Software • l Implementação • l Projeto de uma estrutura de software que perceba a especificação Transformar esta estrutura em um programa executável As atividades de projeto e implementação são intimamente relacionadas e podem ser entrelaçadas ©Ian Sommerville 2000 Software Engineering, 6 th edição. Cápítulo 3 Slide 29

Atividades de processo de projeto l l l Projeto arquitetural Especificação abstrata Projeto de

Atividades de processo de projeto l l l Projeto arquitetural Especificação abstrata Projeto de interface Projeto de componente Projeto de estrutura de dados Projeto de algoritmo ©Ian Sommerville 2000 Software Engineering, 6 th edição. Cápítulo 3 Slide 30

O processo do projeto de software ©Ian Sommerville 2000 Software Engineering, 6 th edição.

O processo do projeto de software ©Ian Sommerville 2000 Software Engineering, 6 th edição. Cápítulo 3 Slide 31

Métodos do Projeto l l l Abordagens sistemáticas para desenvolver um projeto de software

Métodos do Projeto l l l Abordagens sistemáticas para desenvolver um projeto de software O projeto é geralmente documentado como uma série de modelos gráficos Modelos possíveis • • Modelo de fluxo de dados Modelo de atributos relacionados à entidade Modelo Estrutural Modelos de objetos ©Ian Sommerville 2000 Software Engineering, 6 th edição. Cápítulo 3 Slide 32

Programando e Depurando l l l Transformar um projeto em um programa e remover

Programando e Depurando l l l Transformar um projeto em um programa e remover erros do programa Programação é uma atividade pessoal – não existe processo de programação genérico Programadores realizam alguns testes de programa para detectar falhas no programa e remover tais falhas no processo de depuração ©Ian Sommerville 2000 Software Engineering, 6 th edição. Cápítulo 3 Slide 33

O processo de depuração ©Ian Sommerville 2000 Software Engineering, 6 th edição. Cápítulo 3

O processo de depuração ©Ian Sommerville 2000 Software Engineering, 6 th edição. Cápítulo 3 Slide 34

Validação do Software l l l Verificação e validação pretendem mostrar que um sistema

Validação do Software l l l Verificação e validação pretendem mostrar que um sistema está de acordo com sua especificação e cumpre os requisitos do cliente do sistema Envolve a verificação e a revisão de processos e teste do sistema Teste de sistema envolve a execução do sistema com cases de teste que são derivados da especificação dos dados reais a serem processados pelo sistema ©Ian Sommerville 2000 Software Engineering, 6 th edição. Cápítulo 3 Slide 35

O processo de teste ©Ian Sommerville 2000 Software Engineering, 6 th edição. Cápítulo 3

O processo de teste ©Ian Sommerville 2000 Software Engineering, 6 th edição. Cápítulo 3 Slide 36

Etapas de teste l Teste da Unidade • l Teste do Módulo • l

Etapas de teste l Teste da Unidade • l Teste do Módulo • l Os módulos são integrados em sub-sistemas e testados. O foco aqui deve ser no teste da interface Teste do Sistema • l Conjuntos de componentes dependentes relacionados são testados Teste do Sub-sistema • l Os componentes individuais são testados Teste do sistema como um todo. Teste das propriedades emergentes Teste de Aceitação • Teste com dados do consumidor para verificar que é aceitável ©Ian Sommerville 2000 Software Engineering, 6 th edição. Cápítulo 3 Slide 37

Fases de teste ©Ian Sommerville 2000 Software Engineering, 6 th edição. Cápítulo 3 Slide

Fases de teste ©Ian Sommerville 2000 Software Engineering, 6 th edição. Cápítulo 3 Slide 38

Evolução do Software l l l Software é hereditariamente flexível e pode ser mudado.

Evolução do Software l l l Software é hereditariamente flexível e pode ser mudado. Como os requisitos mudam ao se alterar as circunstâncias de negócios, o software que suporta o negócio também deve evoluir e mudar Embora tenha havido uma demarcação entre desenvolvimento e evolução (manutenção), este é cada vez mais irrelevante na medida que menos sistemas são totalmente novos ©Ian Sommerville 2000 Software Engineering, 6 th edição. Cápítulo 3 Slide 39

Evolução do sistema ©Ian Sommerville 2000 Software Engineering, 6 th edição. Cápítulo 3 Slide

Evolução do sistema ©Ian Sommerville 2000 Software Engineering, 6 th edição. Cápítulo 3 Slide 40

Suporte ao processo automatizado (CASE) l l Engenharia de software auxiliada por computador (CASE)

Suporte ao processo automatizado (CASE) l l Engenharia de software auxiliada por computador (CASE) é um software para dar suporte aos processos de desenvolvimento e evolução do software Automação da atividade • • • Editores gráficos para o desenvolvimento de modelos de sistema Dicionário de dados para gerenciar entidades de projeto Construtor Gráfico UI para a construção de interface para usuário Depuradores para suportar detecção de falhas no sistema Tradutores automáticos para gerar novas versões de um programa ©Ian Sommerville 2000 Software Engineering, 6 th edição. Cápítulo 3 Slide 41

Tecnologia Case l Tecnologia Case tem levado a melhorias significantes no processo de software

Tecnologia Case l Tecnologia Case tem levado a melhorias significantes no processo de software embora não na ordem de magnitude de melhorias que foram antes previstos • • A engenharia de software requer pensamento criativo – isto não é prontamente automatizável A engenharia de software é uma atividade de grupo e, para grandes projetos, muito tempo é utilizado em interações do grupo. A tecnologia CASE não os suporta de fato ©Ian Sommerville 2000 Software Engineering, 6 th edição. Cápítulo 3 Slide 42

CASE classificação l l A classificação nos ajuda a entender os diferentes tipos de

CASE classificação l l A classificação nos ajuda a entender os diferentes tipos de ferramentas de CASE e seu suporte para atividades do processo Perspectiva Funcional • l Perspectiva do Processo • l As ferramentas são classificadas de acordo com suas funções específicas As ferramentas são classificadas de acordo com as atividades do processo que suportam Perspectiva da Integração • As ferramentas são classificadas de acordo com sua organização em unidades integradas ©Ian Sommerville 2000 Software Engineering, 6 th edição. Cápítulo 3 Slide 43

Classificação das Ferramentas Funcionais ©Ian Sommerville 2000 Software Engineering, 6 th edição. Cápítulo 3

Classificação das Ferramentas Funcionais ©Ian Sommerville 2000 Software Engineering, 6 th edição. Cápítulo 3 Slide 44

Classificação baseada em atividades (Funcional vs. Processo)

Classificação baseada em atividades (Funcional vs. Processo)

Perspectiva de Integração CASE l Ferramentas • l Áreas de trabalho (workbenches) • l

Perspectiva de Integração CASE l Ferramentas • l Áreas de trabalho (workbenches) • l Suporta tarefas individuais do processo como verificação da consistência de um projeto, edição de texto, etc. Suporte a fases do processo como especificação ou projeto. Normalmente inclui uma variedade de ferramentas integradas Ambientes • Suporta tudo ou uma parte substancial de todo um processo de software. Normalmente inclui várias áreas de trabalho integradas ©Ian Sommerville 2000 Software Engineering, 6 th edição. Cápítulo 3 Slide 46

Ferramentas, áreas de trabalho e ambientes ©Ian Sommerville 2000 Software Engineering, 6 th edição.

Ferramentas, áreas de trabalho e ambientes ©Ian Sommerville 2000 Software Engineering, 6 th edição. Cápítulo 3 Slide 47

Pontos chave l l Processos de software são as atividades envolvidas na produção e

Pontos chave l l Processos de software são as atividades envolvidas na produção e evolução de um sistema de software. Eles são representados em um modelo de processo de software As atividades gerais são especificação, projeto e implementação, validação e evolução Modelos genéricos de processo descrevem a organização processos de software Modelos iterativos de processo descrevem o processo de software como um de atividades ©Ian Sommerville 2000 Software Engineering, 6 th edição. Cápítulo 3 Slide 48

Pontos chave l l l Engenharia de requisitos é o processo de desenvolver uma

Pontos chave l l l Engenharia de requisitos é o processo de desenvolver uma especificação de software Os processos de projeto e implementação transformam a especificação em um programa executável A Validação envolve verificar que o sistema cumpre com as especificações e as necessidades do usuário Evolução se preocupa em modificar o sistema depois que ele está em uso Tecnologia CASE suporta atividades de processo de software ©Ian Sommerville 2000 Software Engineering, 6 th edição. Cápítulo 3 Slide 49