Upload
internet
View
122
Download
1
Tags:
Embed Size (px)
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á
[email protected]://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