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

Preview:

Citation preview

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

Engenharia de Software

Capítulo 3 – Processos de Software

Slides do Livro do Sommerville, 2000Disponíveis em inglês em www.software-engin.com

Traduzidos por Jacinta PereiraGraduando do Curso de Letras da UFC

Apresentados por Rossana AndradePh.D, SITE, University of Ottawa, Canadá

Profa. Departamento de Computação, Centro de Ciências,Universidade Federal do Ceará

rossana@lia.ufc.brhttp://great.ufc.br

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

Processos de Software

Conjuntos de atividades coerentes para especificar, projetar, implementar e testar sistemas de software

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

Objetivos 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, 6th edição . Cápítulo 3 Slide 4

Tópicos abordados 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, 6th edição . Cápítulo 3 Slide 5

O processo de software Um conjunto estruturado de atividades requeridas

para desenvolver um sistema de software• 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, 6th edição . Cápítulo 3 Slide 6

Modelos genéricos de processo de software

O modelo cascata• Separa e distingue fases de especificação e desenvolvimento

Desenvolvimento evolucionário• Especificação e desenvolvimento são entrelaçados

Desenvolvimento Formal de sistemas • 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, 6th edição . Cápítulo 3 Slide 7

Modelo CascataRequirements

definition

System andsoftware design

Implementationand unit testing

Integration andsystem testing

Operation andmaintenance

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

Fases do modelo cascata 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, 6th edição . Cápítulo 3 Slide 9

Problemas do modelo cascata 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, 6th edição . Cápítulo 3 Slide 10

Desenvolvimento evolucionário Desenvolvimento exploratório

• 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 pobremente entendidos

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

Desenvolvimento evolucionário

ValidationFinal

version

DevelopmentIntermediate

versions

SpecificationInitial

version

Outlinedescription

Concurrentactivities

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

Desenvolvimento evolucionário Problemas

• 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, 6th edição . Cápítulo 3 Slide 13

Desenvolvimento de sistemas formais

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, 6th edição . Cápítulo 3 Slide 14

Desenvolvimento de sistemas formais

Requirementsdefinition

Formalspecification

Formaltransformation

Integration andsystem testing

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

Transformações Formais

R2Formal

specificationR3

Executableprogram

P2 P3 P4

T1 T2 T3 T4

Proofs of transformation correctness

Formal transformations

R1

P1

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

Desenvolvimento de sistemas formais

Problemas• 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, 6th edição . Cápítulo 3 Slide 17

Desenvolvimento orientado ao reuso

Baseado no reuso sistemático, onde os sistemas são integrados de componentes existentes ou sistemas padronizados

Estágios do Processo• 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, 6th edição . Cápítulo 3 Slide 18

Desenvolvimento orientado ao reuso

Requirementsspecification

Componentanalysis

Developmentand integration

System designwith reuse

Requirementsmodification

Systemvalidation

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

Iteração do Processo Requisitos do sistema SEMPRE evoluem no

decorrer de um projeto, então a iteração do processo, onde estágios anteriores são re-trabalhados, é 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, 6th edição . Cápítulo 3 Slide 20

Desenvolvimento incremental 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, 6th edição . Cápítulo 3 Slide 21

Desenvolvimento incremental

Valida teincrement

Develop systemincrement

Design systemarchitecture

Integrateincrement

Valida tesystem

Define outline requirements

Assign requirements to increments

System incomplete

Finalsystem

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

Vantagens do desenvolvimento incremental

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, 6th edição . Cápítulo 3 Slide 23

Programação extrema 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, 6th edição . Cápítulo 3 Slide 24

Desenvolvimento espiral 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, 6th edição . Cápítulo 3 Slide 25

Modelo espiral do processo de software

Riskanalysis

Riskanalysis

Riskanalysis

Riskanalysis Proto-

type 1

Prototype 2Prototype 3

Opera-tionalprotoype

Concept ofOperation

Simulations, models, benchmarks

S/Wrequirements

Requirementvalidation

DesignV&V

Productdesign Detailed

design

CodeUnit test

IntegrationtestAcceptance

testService Develop, verifynext-level product

Evaluate alternativesidentify, resolve risks

Determine objectivesalternatives and

constraints

Plan next phase

Integrationand test plan

Developmentplan

Requirements planLife-cycle plan

REVIEW

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

Setores do modelo espiral Estabelecimento de objetivos

• Objetivos específicos para a fase são identificados

Avaliação e redução de riscos• Os riscos são avaliados e atividades postas em prática para

reduzir os riscos principias

Desenvolvimento e validação• 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, 6th edição . Cápítulo 3 Slide 27

Especificação do Software 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, 6th edição . Cápítulo 3 Slide 28

O processo de engenharia de requisitos

Feasibilitystudy

Requirementselicitation and

analysisRequirementsspecification

Requirementsvalidation

Feasibilityreport

Systemmodels

User and systemrequirements

Requirementsdocument

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

Projeto e implementação de Software

O processo de converter a especificação do sistema em um sistema executável

Projeto de Software• Projeto de uma estrutura de software que perceba a

especificação

Implementaçã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, 6th edição . Cápítulo 3 Slide 30

Atividades de processo de projeto Projeto arquitetural Especificação abstrata Projeto de interface Projeto de componente Projeto de estrutura de dados Projeto de algoritmo

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

O processo do projeto de software

Architecturaldesign

Abstractspecification

Interfacedesign

Componentdesign

Datastructuredesign

Algorithmdesign

Systemarchitecture

Softwarespecification

Interfacespecification

Componentspecification

Datastructure

specification

Algorithmspecification

Requirementsspecification

Design activities

Design products

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

Métodos do Projeto 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, 6th edição . Cápítulo 3 Slide 33

Programando e Depurando 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, 6th edição . Cápítulo 3 Slide 34

O processo de depuração

Locateerror

Designerror repair

Repairerror

Re-testprogram

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

Validação do Software 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, 6th edição . Cápítulo 3 Slide 36

O processo de teste

Sub-systemtesting

Moduletesting

Unittesting

Systemtesting

Acceptancetesting

Componenttesting

Integration testing Usertesting

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

Etapas de teste Teste da Unidade

• Os componentes individuais são testados

Teste do Módulo• Conjuntos de componentes dependentes relacionados são testados

Teste do Sub-sistema• Os módulos são integrados em sub-sistemas e testados. O foco aqui

deve ser no teste da interface

Teste do Sistema• 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, 6th edição . Cápítulo 3 Slide 38

Fases de teste

Requirementsspecification

Systemspecification

Systemdesign

Detaileddesign

Module andunit codeand tess

Sub-systemintegrationtest plan

Systemintegrationtest plan

Acceptancetest plan

ServiceAcceptance

testSystem

integration testSub-system

integration test

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

Evolução do Software 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 e menos sistemas são totalmente novos

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

Evolução do sistema

Assess existingsystems

Define systemrequirements

Propose systemchanges

Modifysystems

Newsystem

Existingsystems

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

Suporte ao processo automatizado (CASE)

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, 6th edição . Cápítulo 3 Slide 42

Tecnologia Case 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, 6th edição . Cápítulo 3 Slide 43

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

de ferramentas de CASE e seu suporte para atividades do processo

Perspectiva Funcional • As ferramentas são classificadas de acordo com suas funções específicas

Perspectiva do Processo• 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, 6th edição . Cápítulo 3 Slide 44

Classificação das Ferramentas Funcionais

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

Reengineering tools

Testing tools

Debugging tools

Program analysis tools

Language-processingtools

Method support tools

Prototyping tools

Configurationmanagement tools

Change management tools

Documentation tools

Editing tools

Planning tools

Specification Design Implementation Verificationand

Validation

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

Perspectiva de Integração CASE

Ferramentas• Suporta tarefas individuais do processo como verificação da

consistência de um projeto, edição de texto, etc.

Áreas de trabalho (workbenches)• 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, 6th edição . Cápítulo 3 Slide 47

Ferramentas, áreas de trabalho e ambientes

Single-methodworkbenches

General-purposeworkbenches

Multi-methodworkbenches

Language-specificworkbenches

Programming TestingAnalysis and

design

Integratedenvironments

Process-centredenvironments

Filecomparators

CompilersEditors

EnvironmentsWorkbenchesTools

CASEtechnology

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

Pontos chave 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, 6th edição . Cápítulo 3 Slide 49

Pontos chave 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