Universidade Federal do Paraná
Setor de Ciências Exatas
Departamento de Informática
ESPECIALIZAÇÃO EM INFORMÁTICA
Análise e Projeto de Sistemas
Setembrino Soares Ferreira Jr.
01 - Introdução
06/05/2010
01 - Introdução
1
Conteúdos
1. Considerações iniciais
2. Conceitos básicos
3. Engenharia de software
3.1. Princípios
3.2. Paradigmas
3.3. Interação da engenharia de software com
outras áreas
4. Considerações finais
5. Exercícios
Bibliografia
06/05/2010
01 - Introdução
2
1. Considerações iniciais

Sistemas (“sistemas de software”)


Papel cada vez mais importante
Funcionamento correto ou incorreto = vida ou morte
Espaçonaves, aeronaves, trens, carros, reatores nucleares,
equipamentos hospitalares, contas bancárias (segurança de
acesso, movimentação correta), ...


Aplicações TÊM DE SER totalmente confiáveis!

Cumprir requisitos integralmente



Requisitos intransigentes
Restrições de integridade
Vasto conhecimento sobre a aplicação

06/05/2010
Interações software x ambiente adequadas
01 - Introdução
3
1. Considerações iniciais (cont.)

Construir (bons) produtos de software envolve:





Compreender a complexidade dos produtos (cresc.)
Gerenciar equipes multidisciplinares
Obter informações precisas sobre os produtos a
serem desenvolvidos
Comunicação adequada
Sincronizar e controlar atividades



06/05/2010
Paralelas
Diversos profissionais
Diversas equipes
01 - Introdução
4
1. Considerações iniciais (cont.)

Atividades essenciais (do início do desenvolvimento):

Extração de requisitos (características do produto a
ser desenvolvido)



Complexa
Baseada na comunicação entre equipes
Representação adequada de requisitos
Abstrações representativas das diferentes propriedades do
sistema
 Notações formais / semiformais


Planejamento e acompanhamento de atividades do
projeto

06/05/2010
Controle do processo de desenvolvimento
01 - Introdução
5
2. Conceitos básicos

Sistema
- do latim systema, reunião, grupo;
“Conjunto de princípios reunidos de modo a formar
um corpo de doutrina”;
“Conjunto de partes coordenadas que concorrem
para o atingimento de um resultado (conjunto de
objetivos) ou para formar um conjunto”;
“Conjunto de elementos, concretos ou abstratos,
entre os quais se pode encontrar alguma relação”;
“Conjunto, identificável e coerente, de elementos
que interagem coesivamente, onde cada elemento
pode ser um sistema”;
(...)
06/05/2010
01 - Introdução
6
2. Conceitos básicos (cont.)
Existe uma relação estrutural entre as partes
componentes de um sistema


Sistema x universo: fronteira conceitual

Elementos internos



Entidade relativamente autônoma e identificável
Fortes interações entre si
Elementos externos
Fracas interações com elementos internos: devem ser fracas
o suficiente para que possamos desprezá-las

06/05/2010
01 - Introdução
7
2. Conceitos básicos (cont.)
Exemplo 1:
Ecossistema de certa espécie de inseto que
passa toda a sua vida em uma única árvore de
determinada espécie.


Fronteira conceitual
Inseto (fisiologia, anatomia, hábitos reprodutivos, ciclo de
vida, etc.)
 Árvore
 Fauna que habita a árvore
 Caracterização do habitat da árvore (clima, solo, vegetação
na vizinhança, etc.)

06/05/2010
01 - Introdução
8
2. Conceitos básicos (cont.)

Exemplo 2:
Ecossistema floresta amazônica.

Fronteira conceitual ?
06/05/2010
01 - Introdução
9
2. Conceitos básicos (cont.)

Exemplo 2:
Ecossistema floresta amazônica.

Fronteira conceitual ?






06/05/2010
Flora
Fauna
Ocupação humana na floresta e em volta dela
Utilização humana da floresta
Aspectos climáticos, atmosféricos, etc.
Etc.
01 - Introdução
10
2. Conceitos básicos (cont.)
Em sistemas de software, determinar a fronteira
conceitual adequada

É um passo decisivo no processo de concepção do
sistema
 Permite separar componentes pertencentes


Ao sistema


Ao ambiente externo

06/05/2010
Informações devem ser estudadas em detalhes
Interesse: interações com o sistema
01 - Introdução
11
2. Conceitos básicos (cont.)
Exemplo 3:
Sistema de reservas de passagens aéreas de
uma determinada companhia.


Fronteira conceitual ?
06/05/2010
01 - Introdução
12
2. Conceitos básicos (cont.)
Exemplo 3:
Sistema de reservas de passagens aéreas de
uma determinada companhia.


Fronteira conceitual ?
Companhia
 Dados sobre vôos: disponibilidades, reservas, cancelamentos,
etc.)

Se o sistema de software incluir reservas de
hotéis, locação de carros, ofertas de pacotes
turísticos, etc., a fronteira conceitual terá de ser
ampliada para contemplar informações sobre ?


Hotéis, locadoras de carros, agências de turismo, etc.
06/05/2010
01 - Introdução
13
2. Conceitos básicos (cont.)

Produtos de software
Sistemas de software entregues ao usuário com a
documentação que descreve como instalá-lo e usá-lo


Categorias de produtos de software
Sistemas genéricos: produzidos e vendidos no
mercado
 Sistemas específicos: produzidos sob encomenda
especialmente para um determinado cliente


Composição dos produtos de software



Instruções (programas de computador)
Estruturas de dados (manipuladas pelas instruções)
Documentos (descrevem operações e uso do produto)
06/05/2010
01 - Introdução
14
2. Conceitos básicos (cont.)

Processo de desenvolvimento de software
Conjunto de atividades e resultados associados, com
o objetivo de construir um produto de software
 Desenvolvimento

Especificação de funcionalidades e restrições relativas à
operacionalidade do software
 Produção do software conforme as especificações


Validação
Avaliação da aderência do software às necessidades do
usuário


Manutenção
Correções, adaptações e ampliações para corrigir erros pósentrega
 Atender novos requisitos / mudanças na tecnologia

06/05/2010
01 - Introdução
15
2. Conceitos básicos (cont.)
No processo de desenvolvimento de software,
modelos de processos (paradigmas) especificam:



Quais atividades devem ser executadas
Qual a ordem de execução das atividades
Produtos de software podem ser construídos
utilizando-se diferentes modelos de processos

Alguns modelos são mais adequados que outros =
f(tipo da aplicação)
 A escolha de um determinado modelo deve ser feita =
f(produto a desenvolver)

06/05/2010
01 - Introdução
16
3. Engenharia de software
Décadas de 60 e 70, desafio era desenvolver
hardware que reduzisse custos de:




Década de 80, f(avanços na microeletrônica):



Processamento
Armazenagem de dados
Aumento do poder computacional
Custo cada vez menor
Processo de desenvolvimento e software:




Cronogramas não eram cumpridos
Custos excediam previsões
Requisitos não eram cumpridos
Etc.
06/05/2010
01 - Introdução
17
3. Engenharia de software (cont.)

Desafio atual (há ± 3 décadas):




Melhorar a qualidade
Reduzir o custo do software
Introduzir disciplina no desenvolvimento
Engenharia de software
Uma disciplina que reúne metodologias, métodos e
ferramentas a serem utilizadas, desde a percepção do
problema até o momento em que o sistema
desenvolvido deixa de ser operacional, visando resolver
problemas inerentes ao processo de
desenvolvimento e ao produto de software.
06/05/2010
01 - Introdução
18
3. Engenharia de software (cont.)

Objetivos da engenharia de software




Auxiliar no processo de produção de software
Processo para gerar produtos de alta qualidade
Mais rapidamente
Custo cada vez menor
Problemas a tratar, f(atributos do processo e
do produto de software)

Complexidade, visibilidade, aceitabilidade,
confiabilidade, alterabilidade, segurança, etc.
 Controle de tráfego aéreo / ferroviário: confiabilidade
 Controladores embutidos em eletrodomésticos
(lavadoras de roupas / videocassetes): desempenho

06/05/2010
01 - Introdução
19
3. Engenharia de software (cont.)

Engenharia de software
Herda da engenharia o conceito de disciplina na
produção de software
 Adota metodologias, com métodos que utilizam
ferramentas automatizadas
 Métodos focalizam:




06/05/2010
Funções do sistema
Objetos do sistema
Eventos do funcionamento do sistema
01 - Introdução
20
3.1. E. S. - Princípios

Referem-se:
Ao processo
 Ao produto final
 Descrevem propriedades gerais dos processos e
produtos
 Processo correto => produto correto
 Produto almejado => escolha do processo
(~ estratégia <=> estrutura organizacional)
 Princípios são insuficientes. Há a necessidade de:




06/05/2010
Metodologias
Métodos
Ferramentas
01 - Introdução
21
3.1. E. S. - Princípios (cont.)





Formalidade
Abstração
Decomposição
Generalização
Flexibilização
06/05/2010
01 - Introdução
22
3.1. E. S. - Princípios (cont.)

Formalidade
Desenvolvimento de software = atividade criativa
 Tende a ser imprecisa (não estruturada)
 Enfoque formal: produtos mais confiáveis, com custo
controlado e melhor desempenho
 Não deve restringir a criatividade
 Projeto como seqüência de passos precisos
 Passos segundo metodologia e algum método formal,
informal ou semiformal
 Adequar formalidade à necessidade (ex.: barco p/ rio
x oceano)
 Efeitos: manutenção, reutilização, portabilidade e
entendimento do software

06/05/2010
01 - Introdução
23
3.1. E. S. - Princípios (cont.)

Abstração
Processo de identificação de aspectos importantes de
um determinado fenômeno, ignorando-se os detalhes
 Podem existir diferentes abstrações, f(visões e
objetivos diferentes)
 Ex.: telefone sem fio

P/ o usuário: manual c/ efeitos do acionamento dos diversos
botões
 P/ o técnico de manutenção: manual c/ informações de
componentes


Ex.: programas


Abstrações das funcionalidades do sistema
Ex.: linguagens de programação

06/05/2010
Foco do programador no problema, não na máquina
01 - Introdução
24
3.1. E. S. - Princípios (cont.)

Decomposição

Para lidar com a complexidade:
Subdividir atividades do processo
 Atribuí-las a especialistas de diferentes áreas
 Várias formas (ex.: tempo)
 Ex.: controle de qualidade do processo, controle de
qualidade do produto, especificação do projeto,
implementação e manutenção



Decomposição = separação de preocupações
Pode-se decompor o produto
Permite o trabalho em paralelo
 Permite a reutilização de componentes por outros
componentes ou sistemas

06/05/2010
01 - Introdução
25
3.1. E. S. - Princípios (cont.)

Generalização
Solução de um problema potencialmente pode ser
reutilizada
 Determinado componente pode ser utilizado em
diversos pontos do mesmo sistema, ao invés de várias
soluções especializadas
 Solução pode demorar mais (mais custosa)
 Avaliar custo e eficiência para decidir
 Conseqüência principal: portabilidade

06/05/2010
01 - Introdução
26
3.1. E. S. - Princípios (cont.)

Flexibilização

Envolve processo e produto


Produto se altera = f(entendimento de requisitos)
Processo ocorre passo a passo, de forma incremental
Princípio necessário ao processo para que o produto
possa ser modificado com facilidade
 Processo deve ter flexibilidade para permitir

A reutilização de componentes
 A portabilidade do produto para diferentes plataformas
computacionais

06/05/2010
01 - Introdução
27
3.2. E. S. - Paradigmas
Modelos de processo de desenvolvimento que
proporcionam:


Ao gerente:
Controle do processo de desenvolvimento de sistemas de
software.


Ao desenvolvedor:
Obtenção de base para produzir, de maneira eficiente e
eficaz, software que satisfaça os requisitos preestabelecidos.


Objetivo:
Diminuir os problemas inerentes ao processo de
desenvolvimento de software

06/05/2010
01 - Introdução
28
3.2. E. S. - Paradigmas (cont.)


Existem vários.
Escolha de acordo com:




Natureza do projeto e do produto
Métodos e ferramentas
Controles e produtos intermediários desejados
Três mais utilizados:



Ciclo de vida clássico
Evolutivo
Espiral
06/05/2010
01 - Introdução
29
3.2. E. S. - Paradigmas (cont.)
3.2.1. Ciclo de vida clássico
 Método sistemático e seqüencial
 O resultado de uma fase é entrada de outra
 Fases se sucedem linearmente (=> “cascata”)
 Fases estruturadas como um conjunto de
atividades que podem ser executadas


por pessoas diferentes
simultaneamente
06/05/2010
01 - Introdução
30
3.2. E. S. - Paradigmas (cont.)
3.2.1. Ciclo de vida clássico (cont.)
Análise e Especificação
de Requisitos
Projeto
Implementação e
teste unitário
Integração e teste
do sistema
Operação e
manutenção
Os cinco passos
06/05/2010
01 - Introdução
31
3.2. E. S. - Paradigmas (cont.)
3.2.1. Ciclo de vida clássico (cont.)
 Decomposição = f(complexidade da aplicação)

aplicações simples e bem entendidas


aplicações maiores e mais complexas




menos formalidade
maior decomposição do processo
melhor controle
garantia dos resultados
Exemplos - aplicações p/usuários


não especialistas: fase p/projetar material especial de
treinamento + treinamento p/entrada em operação
especialistas: manuais técnicos / telefonemas / S.A.U.
06/05/2010
01 - Introdução
32
3.2. E. S. - Paradigmas (cont.)
3.2.1. Ciclo de vida clássico (cont.)
 Análise e especificação de requisitos





Via consultas aos usuários
Identificar serviços, metas, restrições <=> qualidade
= f(funcionalidade, desempenho, facilidade de uso,
portabilidade, ...)
Especificar quais os requisitos, não como alcançá-los
Os requisitos especificados não devem restringir o
desenvolvedor no projeto e implementação
Resultado da fase: documento de especificação de
requisitos, que deve ser


06/05/2010
analisado e confirmado pelos usuários
usado pelos desenvolvedores p/obtenção do produto
01 - Introdução
33
3.2. E. S. - Paradigmas (cont.)
3.2.1. Ciclo de vida clássico (cont.)
 Análise e especificação de requisitos (cont.)

Documento de especificação de requisitos




instrumento de comunicação entre muitos indivíduos
inteligível, preciso, completo, consistente e s/ambigüidades
facilmente modificável = f(natureza evolutiva do software)
conciliar interesses dos usuários e do desenvolvedor


06/05/2010
texto em linguagem natural
versão preliminar do manual do usuário
01 - Introdução
34
3.2. E. S. - Paradigmas (cont.)
3.2.1. Ciclo de vida clássico (cont.)
 Análise e especificação de requisitos (cont.)

Outro resultado da fase: plano de projeto


usar princípios: abstração, decomposição e generalização
Documento de especificação de requisitos


funcionais: o que o produto deve fazer
não funcionais:







06/05/2010
confiabilidade - disponibilidade, integridade, segurança
acurácia dos resultados
desempenho
problemas de ihc
restrições físicas e operacionais
questões de portabilidade
...
01 - Introdução
35
3.2. E. S. - Paradigmas (cont.)
3.2.1. Ciclo de vida clássico (cont.)
 Análise e especificação de requisitos (cont.)

Documento de especificação de requisitos

de desenvolvimento e manutenção





06/05/2010
procedimentos de controle de qualidade
procedimentos de teste
prioridades de funções
mudanças prováveis
etc.
01 - Introdução
36
3.2. E. S. - Paradigmas (cont.)
3.2.1. Ciclo de vida clássico (cont.)
 Projeto


Representação das funções do sistema em forma que
possa ser transformada em um ou mais programas
executáveis
Produto é decomposto em partes tratáveis:
documento de especificação de projeto

descrição da arquitetura do software


06/05/2010
o que cada parte deve fazer
relação entre as partes
01 - Introdução
37
3.2. E. S. - Paradigmas (cont.)
3.2.1. Ciclo de vida clássico (cont.)
 Projeto (cont.)

Projeto preliminar x detalhado



06/05/2010
Preliminar: estrutura de relações: usa, é_composto_de,
herda_de, ...
Detalhado: especificação das interfaces
Preliminar: decomposição lógica (alto nível)
Detalhado: decomposição física do programa em unidades
de programação
Preliminar: principais estruturas de dados
Detalhado: algoritmos para cada módulo
01 - Introdução
38
3.2. E. S. - Paradigmas (cont.)
3.2.1. Ciclo de vida clássico (cont.)
 Implementação e teste unitário


Transformação do projeto em programas (ou
unidades de programas)
Resultado:

Coleção de programas implementados e testados, conforme
os padrões da organização, se houverem




comentários
nomenclatura
número máximo de linhas por componente, ...
Teste unitário: verifica se cada unidade satisfaz suas
especificações, normalmente conforme padrões

06/05/2010
planos e critérios de testes, critério de completude,
gerenciamento de casos de teste, respeito a padrões, ...
01 - Introdução
39
3.2. E. S. - Paradigmas (cont.)
3.2.1. Ciclo de vida clássico (cont.)
 Integração e teste do sistema


Programas são integrados e testados como sistema
Freqüentemente não é feito de uma só vez, mas
progressivamente, em conjuntos cada vez maiores, a
partir de pequenos subsistemas, até que o sistema
inteiro seja construído
06/05/2010
01 - Introdução
40
3.2. E. S. - Paradigmas (cont.)
3.2.1. Ciclo de vida clássico (cont.)
 Operação e manutenção


Fase mais longa do ciclo de vida
Entrega em dois estágios



grupo selecionado de usuários (feedback / alterações, caso
necessário)
oficial
Manutenção




06/05/2010
Atividade posterior à entrega do sistema aos usuários
Corretiva: correção de erros remanescentes
Adaptativa: adaptação a mudanças do ambiente
Evolutiva: mudanças nos requisitos, adição de características
e qualidades ao software
01 - Introdução
41
3.2. E. S. - Paradigmas (cont.)
3.2.1. Ciclo de vida clássico (cont.)
 Outras atividades


Paradigma clássico dividido em fases
Algumas atividades devem ser feitas



antes do início do ciclo de vida
durante todo o ciclo de vida
Estudo de viabilidade






06/05/2010
Estágio crítico para o sucesso do projeto
Envolve custos e benefícios
Limitado por tempo (sob pressão)
Poucos recursos investidos
Identificar soluções alternativas, c/custos e datas de entrega
Conteúdo: problema, soluções (c/benef. esp., recursos nec. e
datas de entrega
01 - Introdução
42
3.2. E. S. - Paradigmas (cont.)
3.2.1. Ciclo de vida clássico (cont.)
 Outras atividades (cont.)

Documentação




Produtos ou resultados da maioria das fases são documentos
Mudança de fases depende destes documentos
Seguir padrões da organização p/sua elaboração
Verificação




06/05/2010
Ocorre no teste unitário e do sistema
Também em outras fases
Processo de controle de qualidade via revisões e inspeções
Descoberta e remoção de erros deve ocorrer o quanto antes
(antes da entrega do produto)
01 - Introdução
43
3.2. E. S. - Paradigmas (cont.)
3.2.1. Ciclo de vida clássico (cont.)
 Outras atividades (cont.)

Gerenciamento



06/05/2010
Meta: controlar o processo de desenvolvimento
Adaptação do ciclo de vida ao processo: rigidez /
profundidade variáveis
Políticas: armazenagem, acesso e modificação de produtos /
resultados intermediários; critérios de construção de versões
diferentes e autorizações para acesso aos componentes de
entrada e saída do banco de dados
01 - Introdução
44
3.2. E. S. - Paradigmas (cont.)
3.2.1. Ciclo de vida clássico (cont.)
 Contribuições geradas



Processo sujeito a disciplina, planejamento e
gerenciamento
Implementações postergadas até o entendimento
completo dos objetivos
Problemas


Rigidez (o desenvolvimento não é linear, é iterativo!)
Objetivo continua sendo a linearidade =>



Previsibilidade
Facilidade de monitoramento
Planejamento orientado para data de entrega única,
que pode ser bastante longa (“congelamento?”)
06/05/2010
01 - Introdução
45
3.2. E. S. - Paradigmas (cont.)
3.2.2. O paradigma evolutivo
 Base





Desenvolvimento e implementação de produto inicial
Comentários e críticas dos usuários
Refinamento através de múltiplas versões
Desenvolvimento e validação paralelas (rápido
feedback)
Dois tipos


Desenvolvimento exploratório
Protótipo descartável
06/05/2010
01 - Introdução
46
3.2. E. S. - Paradigmas (cont.)
3.2.2. O paradigma evolutivo (cont.)
 Desenvolvimento exploratório




Início


Objetivo: trabalhar junto do usuário para descobrir os
requisitos
Incremental, até o produto final ser obtido
Adoção: dificuldade (ou impossibilidade) de obter
especificação detalhada de requisitos a priori
Partes mais bem entendidas
Evolução

Novas características adicionadas (sugeridas pelo
usuário)
06/05/2010
01 - Introdução
47
3.2. E. S. - Paradigmas (cont.)
3.2.2. O paradigma evolutivo (cont.)
Atividades Paralelas
Desenvolvimento
Versão inicial
Versão
intermediária
Descrição
Validação
Versão final
Desenvolvimento exploratório
06/05/2010
01 - Introdução
48
3.2. E. S. - Paradigmas (cont.)
3.2.2. O paradigma evolutivo (cont.)
 Protótipo descartável




Objetivo: melhor definir requisitos do usuário/sistema
Fazer experimentos c/requisitos não bem entendidos
Envolve projeto, implementação e teste (não formais
/ completos)
Adoção


Usuário define objetivos / não define E-P-S
Desenvolvedor incerto sobre



06/05/2010
Eficiência de algoritmo
Adaptação da aplicação a sistema operacional
Forma de IHC
01 - Introdução
49
3.2. E. S. - Paradigmas (cont.)
3.2.2. O paradigma evolutivo (cont.)
 Protótipo descartável (cont.)

Possibilita criar modelo do software a construir



Desenvolvedor pode perceber reações do usuário e obter
sugestões para mudança / inovação
Usuário pode relacionar protótipo com requisitos
Operacionalização







06/05/2010
Versão preliminar da especificação de requisitos
Construção do protótipo descartável
Uso pelos usuários => ok’s, alterações, sobras, faltas, etc.
Modificação do protótipo / uso pelos usuários
Repetir ciclo enquanto novas informações valerem $ e tempo
Especificação de requisitos definitiva = f(modificações)
Desenvolvimento
01 - Introdução
50
3.2. E. S. - Paradigmas (cont.)
3.2.2. O paradigma evolutivo (cont.)
 Protótipo descartável (cont.)
Análise de
requisitos
Análise de
requisitos
Projeto
Implementação
Projeto
Implementação
Teste
Teste
Protótipo descartável
06/05/2010
01 - Introdução
51
3.2. E. S. - Paradigmas (cont.)
3.2.2. O paradigma evolutivo (cont.)
 Mais efetivo do que o ciclo de vida clássico
 Problemas (perspectivas de engenharia e gerenciamento)




Processo não visível, rápido, documentação de cada
versão não compensatória, mas necessária para
medição de progresso
Estruturação de produto pobre (corrompida pelas
mudanças) => evolução difícil e custosa
Protótipo a descartar construído artificialmente =>
qualidade e alterabilidade? / Pressão dos usuários p/
transformar protótipo em produto final s/reconstrução
Escolhas inapropriadas (dos desenvolvedores) podem
tornar-se parte integrante do sistema
06/05/2010
01 - Introdução
52
3.2. E. S. - Paradigmas (cont.)
3.2.2. O paradigma evolutivo (cont.)
 Vantagem

Abordagem leva a testes mais efetivos
“Testar cada versão é mais fácil que o sistema todo ao
final do desenvolvimento”

Aplicabilidade prática

Sistemas pequenos

06/05/2010
Mudanças = redesenvolvimento total
01 - Introdução
53
3.2. E. S. - Paradigmas (cont.)
3.2.3. O paradigma espiral (ou de BOEHM, 1991)
 Engloba as melhores características do ciclo de
vida clássico e do paradigma evolutivo
 Inclui análise de risco
“Riscos são circunstâncias adversas que podem
atrapalhar o processo de desenvolvimento e a
qualidade do produto a ser desenvolvido”

Prevê a eliminação de problemas de alto risco


Planejamento e projeto cuidadosos
Tratamento de problemas triviais e não triviais de
formas diferentes
06/05/2010
01 - Introdução
54
3.2. E. S. - Paradigmas (cont.)
3.2.3. O paradigma espiral (cont.)
 Atividades organizadas como uma espiral de
muitos ciclos (ciclo = fase de desenvolvimento)






1o.: estudo de viabilidade + operacionalidade
(funcionalidades e características do sistema e do
ambiente em que será desenvolvido)
2o.: definição dos requisitos
3o.: projeto
...
Não existem fases fixas
Durante o planejamento decide-se como estruturar o
processo de desenvolvimento em fases
06/05/2010
01 - Introdução
55
3.2. E. S. - Paradigmas (cont.)
3.2.3. O paradigma espiral (cont.)
 Atividades principais

Definição dos objetivos, alternativas e restrições

Objetivos para a fase de desenvolvimento






Alternativas para atingir os objetivos
Restrições do processo e do produto
Esboço de plano inicial
Identificação de riscos de projeto
Planejamento de estratégias alternativas = f(riscos)


Ex.: desempenho e funcionalidade
Ex.: desenvolvimento x compra de produto
Análise de risco


06/05/2010
Análise cuidadosa + atitudes p/ cada risco, visando redução
Ex.: requisitos c/problemas => desenvolvimento de protótipo
01 - Introdução
56
3.2. E. S. - Paradigmas (cont.)
3.2.3. O paradigma espiral (cont.)
 Atividades principais (cont.)

Desenvolvimento e validação



Avaliados os riscos, escolher um paradigma de
desenvolvimento
Ex.: Predominância de riscos de interface com o usuário =>
escolha do paradigma de prototipagem evolutiva
Planejamento



Revisar o projeto
Decidir por percorrer ou não mais um ciclo na espiral
Para o caso de decisão positiva


Para o caso de decisão negativa (grandes riscos, p. ex.)

06/05/2010
Planejar a próxima fase do desenvolvimento do projeto
Descontinuar o projeto
01 - Introdução
57
3.2. E. S. - Paradigmas (cont.)
3.2.3. O paradigma espiral (cont.)
 Diferença mais importante dos outros dois





Análise de risco
Entendimento e reação do desenvolvedor aos
riscos a cada ciclo
Mecanismo de redução de risco / manutenção
do desenvolvimento sistemático = prototipagem
Incorporação de componente iterativo =>
refletir o mundo mais realisticamente
Exige especialização em análise de risco

Riscos podem ser diminuídos / sanados através de
informações que diminuam a incerteza do desenvto.
06/05/2010
01 - Introdução
58
3.2. E. S. - Paradigmas (cont.)
3.2.3. O paradigma espiral (cont.)
Análise
de
risco
Definição dos
objetivos,
alternativas e
restrições
Análise
de
risco
Análise
de
Protótipo
risco
operacional
Protótipo
3
Protótipo
2
Análise
de
risco
Análise
de
risco
Revisão
Simulações, modelos
Plano de requisitos
Plano do ciclo de
vida
Plano de
desenvolvimento
Planejamento
Protótipo
1
Integração e
plano de teste
Operacionalidade
do software
Requisitos de
software
Projeto do
Validação dos
software
requisitos
Validação do
projeto e
verificação
Implantação
06/05/2010
01 - Introdução
Projeto
detalhado
Código
Teste
unitário
Teste de
integração
Teste de
aceitação
Desenvolvimento
e validação
59
3.3. E. S. - Interações da E. S.
com outras áreas

Teoria da computação

Desenvolvimento de modelos úteis para a E. S.


Autômatos de estados finitos: especificação de sistemas
operacionais, I. H. C. e processadores p/tais especificações
Semântica formal


Permite raciocinar sobre as propriedades dos sistemas
Importância cresce com o tamanho e a complexidade
dos sistemas

06/05/2010
Ex.: Sistema de controle de linhas de trens determina que
deve existir, em qualquer parte dos trilhos de uma linha, no
máximo, um trem => semântica formal permite a produção
de prova de que o software sempre terá este comportamento
01 - Introdução
60
3.3. E. S. - Interações da E. S.
com outras áreas (cont.)

Linguagens de programação


Grande influência no alcance dos objetivos da E. S.
Objetivos da E. S. influenciam o desenvolvimento das
L. P.





06/05/2010
Inclusão de características modulares
Compilação independente
Separação entre especificação e implementação
Desenvolvimento de “pacotes”: separação entre a interface e
a implementação
Bibliotecas de componentes para o desenvolvimento de
sistemas independentes
01 - Introdução
61
3.3. E. S. - Interações da E. S.
com outras áreas (cont.)

Compiladores


Desenvolvimento modular
Dois componentes



Decomposição permite a reutilização do segundo
componente no desenvolvimento de outros
compiladores



Análise da linguagem
Geração do código
Técnica usada na construção de compiladores da família GNU
Atende a diferentes arquiteturas e L. P. de alto nível
Escrita do menor número de linhas de código viável =
f(reutilização), conceito da E. S.
06/05/2010
01 - Introdução
62
3.3. E. S. - Interações da E. S.
com outras áreas (cont.)

Sistemas operacionais

Ferramentas p/o gerenciamento da configuração


Manutenção / controle das relações entre componentes e
versões do sistema de software
Ex.: UNIX




06/05/2010
Vantagem sobre antecessores
Organização como um conjunto de programas simples
Podem ser combinados com grande flexibilidade
Interface comum: arquivos texto
01 - Introdução
63
3.3. E. S. - Interações da E. S.
com outras áreas (cont.)

Bancos de dados



Linguagens de consulta permitem o uso dos dados
sem se preocupar com sua representação interna
B. D. pode ser alterado para melhorar o desempenho
do sistema sem mudanças na aplicação
Podem ser usados como componentes de sistemas:
resolvem muitos problemas de acesso concorrente,
por múltiplos usuários, a grandes volumes de dados
06/05/2010
01 - Introdução
64
3.3. E. S. - Interações da E. S.
com outras áreas (cont.)

Sistemas multiagentes



Sistemas complexos
Desenvolvimento envolve a decomposição do produto
/ separação de preocupações
Ex.: Sistema para o processamento de textos pode
ser decomposto em




06/05/2010
Análise sintática
Análise semântica
Análise pragmática
Etc.
01 - Introdução
65
3.3. E. S. - Interações da E. S.
com outras áreas (cont.)

Sistemas especialistas


Sistemas modulares
Dois componentes distintos





Fatos conhecidos pelo sistema
Regras para processar os fatos
Ex.: Regra p/decidir determinada ação
Conhecimento é dado pelo usuário
Princípios gerais de como aplicar o conhecimento a
qualquer problema são fornecidos pelo próprio
sistema
06/05/2010
01 - Introdução
66
3.3. E. S. - Interações da E. S.
com outras áreas (cont.)

Ciência do gerenciamento






Estimativas de projeto
Cronograma
Planejamento de recursos humanos
Decomposição e atribuição de tarefas
Acompanhamento de projetos
Contratação e atribuição da tarefa certa à pessoa
certa
06/05/2010
01 - Introdução
67
3.3. E. S. - Interações da E. S.
com outras áreas (cont.)

Engenharia de sistemas



Estuda sistemas complexos
Hipótese: certas leis governam qualquer sistema
complexo / composto de componentes com relações
complexas
Software é componente de um sistema maior =>
sujeito às técnicas da engenharia de sistemas
06/05/2010
01 - Introdução
68
4. Considerações finais

Paradigmas podem ser combinados


Pontos fortes de cada um utilizados em um único
projeto
Paradigma espiral faz isso diretamente, combinando





Prototipagem + elementos do ciclo de vida clássico
Em paradigma evolutivo
Qualquer paradigma pode servir como alicerce
no qual outros se integram
Processo sempre começa com determinação dos
objetivos, alternativas e restrições (obtenção de
requisitos preliminar)
Depois disso, adotar qualquer caminho
06/05/2010
01 - Introdução
69
4. Considerações finais (cont.)

Ex.:

Para sistema completamente especificado no início


Ciclo de vida clássico
Para sistema com requisitos não muito claros
Protótipo para definir requisitos
 Usado como guia, desenvolvedor pode adotar passos do ciclo
de vida clássico (projeto, implementação e teste)
ou
 Alternativamente, protótipo pode evoluir para um sistema,
retornando ao paradigma do ciclo de vida clássico para teste

A natureza da aplicação é que vai determinar o paradigma a ser
utilizado, e a combinação de paradigmas só tende a beneficiar o
processo como um todo.
06/05/2010
01 - Introdução
70
5. Exercícios
1) O gerente geral de uma cadeia de lojas de presentes acredita que o
único objetivo da construção de um protótipo é entender os
requisitos do usuário e que depois esse protótipo será descartado.
Portanto, ele acha bobagem gastar tempo e recursos em algo que
será desprezado mais tarde. Considerando essa relutância, resolva
as seguintes questões:
(a) Compare brevemente o protótipo descartável com o
desenvolvimento evolutivo, de forma que o gerente compreenda o
que um protótipo pode significar.
(b) O gerente pensa em implementar o sistema, implantá-lo em
uma loja e, depois, se obtiver sucesso, instalá-lo nas outras cinco
lojas da cadeia. Diga qual método de prototipagem deve ser usado
e justifique sua escolha.
06/05/2010
01 - Introdução
71
5. Exercícios
2) Qual a importância do software?
3) O que é software legado?
4) Cite 3 (três) tipos de software. Pesquise e descreva cada um deles.
5) Quais as diferenças dos modelos cascata e espiral?
6) Quais as atividades do modelo tradicional?
7) Descreva o modelo de prototipação.
06/05/2010
01 - Introdução
72
Bibliografia
CARVALHO, A. M. B. R.; CHIOSSI, T. C. S. Introdução à
Engenharia de Software. Campinas: Editora da
Unicamp, 2001.
06/05/2010
01 - Introdução
73