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
Traduzidos por Jacinta Pereira
Graduando do Curso de Letras da UFC
Apresentados por Rossana Andrade
Ph.D, SITE, University of Ottawa, Canadá
Profa. Departamento de Computação, Centro de Ciências,
Universidade Federal do Ceará
[email protected]
http://great.ufc.br
©Ian Sommerville 2000
Software Engineering, 6th edição . Cápítulo 3
Slide 1
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 2
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 3
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 4
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 5
Modelos genéricos de processo de
software

O modelo cascata
•

Desenvolvimento evolucionário
•

Especificação e desenvolvimento são entrelaçados
Desenvolvimento Formal de sistemas
•

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, 6th edição . Cápítulo 3
Slide 6
Modelo Cascata
Requirements
definition
System and
software design
Implementation
and unit testing
Integr ation and
system testing
Operation and
maintenance
©Ian Sommerville 2000
Software Engineering, 6th edição . Cápítulo 3
Slide 7
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 8
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 9
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 10
Desenvolvimento evolucionário
Concurr ent
activities
Outline
description
©Ian Sommerville 2000
Specification
Initial
version
Development
Intermediate
versions
Validation
Final
version
Software Engineering, 6th edição . Cápítulo 3
Slide 11
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 12
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 13
Desenvolvimento de sistemas
formais
Requirements
definition
©Ian Sommerville 2000
Formal
specification
Formal
transformation
Software Engineering, 6th edição . Cápítulo 3
Integration and
system testing
Slide 14
Transformações Formais
Formal transformations
T1
Formal
specification
T2
R1
P1
T3
R2
P2
T4
Executable
program
R3
P3
P4
Proofs of transformation correctness
©Ian Sommerville 2000
Software Engineering, 6th edição . Cápítulo 3
Slide 15
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 16
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 17
Desenvolvimento orientado ao reuso
Requirements
specification
Component
analysis
Requirements
modification
System design
with reuse
Development
and integration
©Ian Sommerville 2000
Software Engineering, 6th edição . Cápítulo 3
System
validation
Slide 18
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 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, 6th edição . Cápítulo 3
Slide 19
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 20
Desenvolvimento incremental
Define outline
requirements
Develop system
increment
Assign requirements
to increments
Valida te
increment
Design system
architecture
Integrate
increment
Valida te
system
Final
system
System incomplete
©Ian Sommerville 2000
Software Engineering, 6th edição . Cápítulo 3
Slide 21
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 22
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 23
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 24
Modelo espiral do processo de
software
Determine objectives
alternatives and
constraints
Risk
analysis
Evaluate alternatives
identify, resolve risks
Risk
analysis
Risk
analysis
REVIEW
Requirements plan
Life-cycle plan
Development
plan
Plan next phase
©Ian Sommerville 2000
Integration
and test plan
Prototype 3
Prototype 2
Operational
protoype
Risk
a nayl sis Prototype 1
Simulations, models, benchmarks
Concept of
Operation
S/W
requirements
Product
design
Requirement
validation
Detailed
design
Code
Unit test
Design
V&V
Integr ation
test
Acceptance
test
Develop, verify
Service
next-level product
Software Engineering, 6th edição . Cápítulo 3
Slide 25
Setores do modelo espiral

Estabelecimento de objetivos
•

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
•

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, 6th edição . Cápítulo 3
Slide 26
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 27
O processo de engenharia de requisitos
Feasibility
study
Requirements
elicitation and
analysis
Requir ements
specification
Feasibility
report
Requirements
validation
System
models
User and system
requirements
Requirements
document
©Ian Sommerville 2000
Software Engineering, 6th edição . Cápítulo 3
Slide 28
Projeto e implementação de Software


O processo de converter a especificação do
sistema em um sistema executável
Projeto de Software
•

Implementação
•

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, 6th edição . Cápítulo 3
Slide 29
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 30
O processo do projeto de software
Re quire me nts
spec if ication
Design a cti
vitie s
Arc hitec tura l
design
Abstra ct
spec if ication
Inte rf ac e
design
Com ponent
design
Data
structure
design
Algor ithm
design
System
a rc hitec ture
Softwa re
spec if ication
Inte rf ac e
spec if ica
tion
Com ponent
spec if ication
Data
structure
spec if ication
Algor ithm
spec if ica
tion
Design pr
oducts
©Ian Sommerville 2000
Software Engineering, 6th edição . Cápítulo 3
Slide 31
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 32
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 33
O processo de depuração
Locate
error
©Ian Sommerville 2000
Design
error repair
Repair
error
Software Engineering, 6th edição . Cápítulo 3
Re-test
program
Slide 34
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 35
O processo de teste
Unit
testing
Module
testing
Sub-system
testing
System
testing
Acceptance
testing
Component
testing
©Ian Sommerville 2000
Integration testing
Software Engineering, 6th edição . Cápítulo 3
User
testing
Slide 36
Etapas de teste

Teste da Unidade
•

Teste do Módulo
•

Os módulos são integrados em sub-sistemas e testados. O foco aqui
deve ser no teste da interface
Teste do Sistema
•

Conjuntos de componentes dependentes relacionados são testados
Teste do Sub-sistema
•

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, 6th edição . Cápítulo 3
Slide 37
Fases de teste
Requir ements
specification
System
specification
System
integration
test plan
Acceptance
test plan
Service
©Ian Sommerville 2000
System
design
Acceptance
test
Detailed
design
Sub-system
integration
test plan
System
integration test
Module and
unit code
and tess
Sub-system
integration test
Software Engineering, 6th edição . Cápítulo 3
Slide 38
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 39
Evolução do sistema
Define system
requirements
Assess existing
systems
Propose system
changes
Existing
systems
©Ian Sommerville 2000
Modify
systems
New
system
Software Engineering, 6th edição . Cápítulo 3
Slide 40
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 41
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 42
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
•

Perspectiva do Processo
•

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, 6th edição . Cápítulo 3
Slide 43
Classificação das Ferramentas
Funcionais
Tool type
Planning tools
Editing tools
Change ma nagement tools
Configuration management tools
Prototyping tools
Method-support tools
Language-processing tools
Program analysis tools
Testing tools
Debugging tools
Documentation tools
Re-engineering tools
©Ian Sommerville 2000
Examples
PERT tools, estimation tools,
spreadsheets
Text editors, diagram editors, word
processors
Requirements traceability tools, change
control systems
Version management systems , system
building tools
Very high-level languages,
user interface generators
Design editors, data dictionaries, code
generators
Compilers, interpreters
Cross reference generators, static
analysers, dynamic analysers
Test data generators, file comp arators
Interactive debugging systems
Page layout programs , ima ge editors
Cross-reference systems , program restructuring systems
Software Engineering, 6th edição . Cápítulo 3
Slide 44
Classificação baseada em atividades (Funcional vs. Processo)
Reengineering tools
Testing tools
Debugging tools
Program analysis tools
Language-processing
tools
Method support tools
Prototyping tools
Configuration
management tools
Change management tools
Documentation tools
Editing tools
Planning tools
Specification
Design
Implementation
Verification
and
Validation
Perspectiva de Integração CASE

Ferramentas
•

Áreas de trabalho (workbenches)
•

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, 6th edição . Cápítulo 3
Slide 46
Ferramentas, áreas de trabalho e
ambientes
CASE
technology
Tools
Editors
Compilers
Workbenches
File
comparators
Analysis and
design
Multi-method
workbenches
©Ian Sommerville 2000
Integrated
environments
Programming
Single-method
workbenches
Environments
Process-centred
environments
Testing
General-purpose
workbenches
Software Engineering, 6th edição . Cápítulo 3
Language-specific
workbenches
Slide 47
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 48
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
©Ian Sommerville 2000
Software Engineering, 6th edição . Cápítulo 3
Slide 49