Introdução A Engenharia de Software

IFPR – Instituto Federal do Paraná – Campus Umuarama
Curso Técnico em Informática

Disciplina: Engenharia de Software - 2º módulo - 2010
Professora: Márcia Cristina Dadalto Pascutti (
marcia.pascutti@ifpr.edu.br)
Introdução à Engenharia
de Software
Bibliografia: SOMMERVILLE, Ian. Engenharia de

Software. São Paulo: Pearson Addison-Wesley, 2007.
1
Engenharia de Software (ES)
 É uma disciplina da engenharia cuja meta é o
desenvolvimento de sistemas de software com boa
relação custo-benefício;
 É uma disciplina relativamente nova. Surgiu pela
1a vez em 1968  crise do software (hardware
poderoso, portanto o software resultante era maior
e mais complexo);
 Dessa forma uma abordagem informal para a
construção desses sistemas não era o bastante. Os
projetos atrasavam, apresentavam custos
elevados, não eram confiáveis, eram de difícil
manutenção e tinham desempenho ruim  o
desenvolvimento de software estava em crise.
2
 Novas técnicas e novos métodos eram
necessários para controlar a complexidade
inerente aos sistemas de software;
 Essas técnicas se tornaram parte da ES.
Ainda existem problemas, porém houve
um grande progresso desde 1968 e o
desenvolvimento da ES melhorou de modo
marcante o software produzido.
3
 Quando um software é bem-sucedido – quando satisfaz
as necessidades das pessoas que o usam, tem
desempenho sem falhas por um longo período, é fácil
de modificar e ainda mais fácil de usar – ele pode e
efetivamente modifica as coisas para melhor.
 Mas quando o software falha – quando seus usuários
ficam insatisfeitos, quando tem tendência a erros,
quando é difícil de modificar e ainda mais difícil de usar
– podem e efetivamente acontecem coisas
desagradáveis.
 Para obter sucesso, precisamos de disciplina quando o
software é projetado e construído  precisamos de
uma abordagem de engenharia.
4
1. O que é software?
 São os programas de computador, a documentação
associada e os dados de configuração necessários para que
esses programas operem corretamente.
 Há dois tipos de software 
 Produtos genéricos: produtos desenvolvidos para o
mercado; pacotes de software. A especificação do software
é controlada pela organização que o desenvolve.
 Produtos sob encomenda (personalizados): produtos
desenvolvidos para um cliente específico. A especificação do
software é controlada pela organização que está comprando o
software  os desenvolvedores devem trabalhar de acordo com
essa especificação.
5
2. O que é engenharia de software?
 É uma disciplina da engenharia que se ocupa de
todos os aspectos da produção de software,
desde os estágios iniciais de especificação do
sistema até a manutenção desse sistema;
 Geralmente, os engenheiros de software
adotam uma abordagem sistemática e
organizada em seu trabalho, pois essa, com
certeza, é a maneira mais eficaz de produzir
software de alta qualidade.
6
3. Qual a diferença entre
engenharia de software e ciência
da computação?
 Ciência da computação  ocupa-se da teoria e dos
fundamentos referentes aos computadores e sistemas de
software;
 Engenharia de software  dedica-se aos problemas
práticos da produção de software;
 Teorias mais refinadas da ciência da computação nem
sempre podem ser aplicadas a problemas reais e
complexos, que requerem uma solução de software.
7
4. Qual a diferença entre
engenharia de software e
engenharia de sistemas?
 Engenharia de sistemas  ocupa-se
de todos os aspectos relacionados ao
desenvolvimento de sistemas, incluindo
hardware e software;
 Engenharia de software  é parte
desse processo.
Engenharia de Sistemas
Engenharia de
software
8
5. O que é um processo de software?
 É um conjunto de atividades e resultados que geram um
produto de software;
 Há 4 atividades fundamentais – comuns a todos os processos
de software 
1. Especificação do software: definição das funcionalidades e
restrições;
2. Desenvolvimento do software: o software deve ser
produzido de forma a atender as especificações;
3. Validação do software: garantia de que o software faz o que
o cliente deseja;
4. Evolução do software: o software deve evoluir para atender
as necessidades mutáveis dos clientes.
 Diferentes organizações podem utilizar processos diferentes para
produzir o mesmo tipo de produto.
9
6. O que é um modelo de processo
de software?
 É uma representação simplificada de um processo de
software, apresentada a partir de uma perspectiva
específica;
 Um modelo de processo de software define a seqüência
em que as atividades do processo serão realizadas;
 Exemplos de Modelos de Processo de Software 
 Modelo em Cascata (Ciclo de Vida Clássico)
 Desenvolvimento Evolucionário
 Desenvolvimento Formal (Transformação formal)
 Desenvolvimento Orientado a Reuso (Montagem de um
sistema a partir de componentes reutilizáveis)
10
Modelo Cascata
 Considera as atividades de especificação,
desenvolvimento, validação e evolução,
que são fundamentais ao processo, e as
representa como fases separadas do
processo, como a especificação de
requisitos, o projeto de software, os testes
e assim por diante.
 Após cada estágio ter sido definido, ele é
“aprovado” e o desenvolvimento
prossegue para o estágio seguinte.
11
Desenvolvimento Evolucionário
 Tem como base a idéia de desenvolver uma
implementação inicial, expor ao comentário
do usuário/cliente e fazer seu aprimoramento
por meio de muitas versões, até que um
sistema adequado tenha sido desenvolvido.
 Em vez de ter as atividades de especificação,

desenvolvimento e validação em separado,
todo esse trabalho é realizado
concorrentemente.
12
Desenvolvimento Evolucionário
Atividades
concorrentes
Versão
Especificação inicial
Versões
Descrição intermediárias
Desenvolvimen
do esboço
to
Versão
Validação final
13
Engenharia de Software Baseada
em Componentes
 Baseia-se na existência de um número
significativo de componentes reutilizáveis;
 O processo de desenvolvimento de sistemas

se concentra na integração desses
componentes em um sistema, em vez de
partir do zero;
 Desenvolvimento Baseado em Componentes.
14
7. Quais são os custos da
engenharia de software?
 A distribuição dos custos ao longo do processo de
software depende do modelo de processo utilizado e do
tipo de software que está sendo desenvolvido;
 Aproximadamente 60% dos custos são relacionados ao
desenvolvimento e 40% são referentes aos testes;
 Para software personalizado (com um longo ciclo de
duração), os custos de evolução normalmente excedem
os custos de desenvolvimento;
 Software genérico  normalmente tem custo de
especificação baixo, porém devem ser extensivamente
testados.
15
8. O que são métodos de
engenharia de software?
 Baseiam-se na idéia de desenvolver modelos de
um sistema que possam ser representados
graficamente e de utilizar esses modelos como
uma especificação ou projeto de sistema;
 Métodos 
 Análise Estruturada;
 Orientados a Objetos (UML – Unified Modeling
Language – Linguagem de Modelagem
Unificada)
16
9. O que é CASE (computer-aided
software engineering)?
 Uma ferramenta CASE é um software destinado a
proporcionar apoio automatizado às atividades de
processo de software, como a análise de requisitos,
modelagem do sistema, depuração e testes;
 Alguns exemplos de ferramentas CASE 

 RequisitePro
 DrCase
 Rational Rose
 Astah
17
10. Quais são os atributos de um
bom software?
 Facilidade de manutenção  o software deve ser
escrito de modo que possa evoluir para atender as
necessidades mutáveis dos clientes;
 Nível de Confiança  inclui confiabilidade, segurança
e proteção;
 Eficiência  inclui rapidez de resposta, tempo de
processamento, utilização da memória, entre outros;
 Facilidade de Uso (usabilidade)  o software deve
dispor de uma interface apropriada com o usuário e de
documentação adequada. Deve ser utilizável sem
esforços indevidos.
18
11. Quais são os principais desafios
enfrentados pela engenharia de
software?
 Desafio da heterogeneidade  desenvolver
técnicas para construir softwares confiáveis, que
sejam flexíveis para atender diferentes tipos de
computadores e diferentes sistemas de apoio;
 Desafio da entrega  reduzir tempo para
entrega de sistemas grandes e complexos, sem
comprometer a qualidade;
 Desafio da confiança  desenvolver técnicas
que demonstrem que o software pode ter a
confiança dos seus usuários.
19
Processos de
Software
20
Processo de Software
 Conjunto de atividades e resultados associados
que levam à produção de um produto de software;
 Não há um processo ideal e até dentro da mesma
empresa pode haver muitos processos diferentes
utilizados para o desenvolvimento de software;
 Existem muitos processos de software diferentes,
porém há atividades fundamentais comuns a
todos eles, como:
 1. Especificação de software  é preciso
definir a funcionalidade do software e as restrições
em sua operação;
21
Processo de Software
 2. Projeto e implementação de
software  deve ser produzido o
software de modo que cumpra sua
especificação;
 3. Validação de software  o software
precisa ser validado para garantir que ele
faz o que o cliente deseja;
 4. Evolução de software  o software
precisa evoluir para atender às
necessidades mutáveis do cliente.
22
Modelos de Processo de
Software
 São utilizados para explicar diferentes
abordagens do desenvolvimento de
software.
 Um modelo de processo de software
define a seqüência em que as atividades
do processo serão realizadas;
 Exemplos de processo de software 
 1. Modelo Cascata;
 2. Desenvolvimento Evolucionário;
 3. Engenharia de Software Baseada em
Componentes. 23
Modelo Cascata
 Primeiro modelo publicado do processo de
desenvolvimento de software;
 Também conhecido como Ciclo de Vida
Clássico ou Modelo Clássico;
 Esse modelo considera as atividades de
especificação, desenvolvimento, validação e
evolução, que são fundamentais ao processo,
e as representa como fases separadas do
processo, como a especificação de requisitos,
o projeto de software, os testes e assim por
diante.
24
Modelo Cascata
Definição de
requisitos
Projeto de sistemas e
de software
Implementação e
teste de unidades
Integração e teste
de sistemas
Operação e
manutenção
25
Fases do Modelo Cascata
 Análise e definição de requisitos
(especificação de requisitos)  as
funções, as restrições e os objetivos
do sistema são estabelecidos por meio
da consulta aos usuários do sistema;
 Em seguida são definidos em detalhes
e servem como uma especificação do
sistema.
26
 Projeto de sistemas e de software 
agrupa os requisitos em sistemas de
hardware ou de software. Estabelece uma
arquitetura do sistema geral.
 Implementação e teste de unidades 
durante esse estágio, o projeto de software é
compreendido como um conjunto de
programas ou de unidades de programa. O
teste de unidade envolve verificar que cada
unidade atenda a sua especificação.
27
 Integração e teste de sistemas 
as unidades de programa ou
programas individuais são integrados
e testados como um sistema completo
a fim de garantir que os requisitos de
software foram atendidos. Depois dos
testes, o sistema de software é
entregue ao cliente.
28
 Operação e Manutenção 
normalmente esta é a fase mais longa
do ciclo de vida. O sistema é instalado
e colocado em operação. A
manutenção envolve corrigir erros que
não foram descobertos em estágios
anteriores do ciclo de vida ou
aumentar as funções desse sistema à
medida que novos requisitos são
descobertos.
29
Modelo Cascata
 Em princípio, o resultado de cada fase
envolve um ou mais documentos que são
aprovados;
 A fase seguinte não deve se iniciar até que a
fase precedente tenha sido concluída;
 O processo de software não é um modelo
linear simples, mas envolve uma seqüência
de iterações das atividades de
desenvolvimento  problema do modelo
cascata  inflexível divisão do projeto
nesses estágios distintos.
30
Modelo Cascata
 O modelo cascata somente deve ser
utilizado quando os requisitos forem
bem compreendidos;
 Contudo, ele reflete a prática da
engenharia;
 Conseqüentemente, os processos de
software com base nessa abordagem
ainda são muito utilizados no
desenvolvimento de software.
31
Desenvolvimento
Evolucionário
 Tem como base a idéia de desenvolver
uma implementação inicial, expor o
resultado ao comentário do usuário e
fazer seu aprimoramento por meio de
muitas versões, até que um sistema
adequado tenha sido desenvolvido;
 Em vez de ter as atividades de
especificação, desenvolvimento e
validação em separado, todo esse
trabalho é realizado concorrentemente
com um rápido feedback por meio
dessas atividades. 32
Desenvolvimento
Evolucionário
Atividades
concorrentes
Versão
Especificação inicial
Versões
Descrição intermediárias
Desenvolvimen
do esboço
to
Versão
Validação final
33
Desenvolvimento
Evolucionário
 A abordagem evolucionária do
desenvolvimento de software, muitas
vezes, é mais eficaz do que a abordagem
em cascata, no sentido de produzir
sistemas que atendam às necessidades
imediatas dos clientes;
 VANTAGEM  a especificação pode ser
desenvolvida gradativamente. À medida
que os usuários desenvolvem uma
compreensão melhor de seus problemas,
isso pode ser refletido no sistema de
software. 34
Desenvolvimento
Evolucionário
 PROBLEMAS 
 1. Como os sistemas são desenvolvidos
rapidamente, não é viável produzir
documentos que reflitam cada versão do
sistema;
 2. Os sistemas freqüentemente são mal-
estruturados. A mudança constante tende
a corromper a estrutura do software.
Incorporar modificações torna-se cada vez
mais difícil e oneroso.
35
em Componentes
 Essa abordagem tem como base a
existência de um número significativo
de componentes reutilizáveis;
 O processo de desenvolvimento de
sistemas se concentra na integração
desses componentes em um sistema,
ao invés de proceder ao
desenvolvimento a partir do zero;
36
em Componentes
Modelo genérico de processo para a
engenharia de software baseada em
componentes
Especificação de Análise de Modificação de
requisitos componentes requisitos
Projeto de sistema Desenvolvimento Validação de

com reuso e integração sistema
37
em Componentes


38
em Componentes
 Especificação de Requisitos 
comparável com outros processos, por
exemplo, modelo cascata;
 As funções, as restrições e os objetivos
do sistema são estabelecidos por meio
da consulta aos usuários do sistema;
 Em seguida são definidos em detalhes
e servem como uma especificação do
sistema.
39
em Componentes


40
em Componentes
 Análise de Componentes  com
base na especificação de requisitos, é
feita uma busca de componentes para
implementar essa especificação;
 Nem sempre é possível encontrar uma
combinação exata e os componentes
que podem ser utilizados fornecem
somente parte da funcionalidade
requerida.
41
em Componentes


42
em Componentes
 Modificação de requisitos  durante
esse estágio, os requisitos são analisados,
utilizando-se as informações sobre os
componentes que foram encontrados;
 Eles são então modificados para refletir os
componentes disponíveis;
 Quando as modificações forem
impossíveis, a atividade de análise de
componentes é refeita, a fim de procurar
soluções alternativas.
43
em Componentes


44
em Componentes
 Projeto de sistema com reuso 
durante essa fase, a infra-estrutura do
sistema é projetada ou uma infra-
estrutura existente é reutilizada;
 Os projetistas levam em conta os
componentes que são reutilizados e
organizam a infra-estrutura para lidar
com esse aspecto.
45
em Componentes


46
em Componentes
 Desenvolvimento e integração  o
software que não puder ser comprado
será desenvolvido, e os componentes
e sistemas COTS (commercial off-the-shelf –
sistemas comerciais de prateleira) serão
integrados, a fim de criar um sistema.
47
em Componentes


48
em Componentes
 Validação de sistema  o software
deve ser validado para garantir que
faz o que o cliente deseja.
49
em Componentes
 VANTAGENS 
 Reduz a quantidade de software a ser
desenvolvida, reduzindo custos e
riscos;
 Geralmente propicia a entrega mais
rápida do software.
50
em Componentes
 PROBLEMAS 
 As adequações nos requisitos são
inevitáveis, e isso pode resultar em um
sistema que não atenda às reais
necessidades dos usuários;
 O controle sobre a evolução do sistema se
perde, uma vez que novas versões dos
componentes reutilizáveis não estão sob o
controle da organização que utiliza esses
componentes.
51
Processos Iterativos
 Os modelos apresentados anteriormente
apresentam vantagens e desvantagens;
 Para o desenvolvimento de grandes
sistemas, pode haver a necessidade de
utilizar diferentes abordagens para diferentes
partes dos sistemas, de maneira que um
modelo híbrido tem de ser utilizado;
 Há também a necessidade de iteração, em
que partes do processo são repetidas, à
medida que os requisitos do sistema
evoluem.
52
Processos Iterativos
 Existem dois modelos híbridos, que
apóiam diferentes abordagens do
desenvolvimento e que foram
explicitamente projetados para
apoiarem a iteração do processo 
 Desenvolvimento Incremental
 Desenvolvimento em Espiral
53
Desenvolvimento Incremental
 É uma abordagem intermediária, que combina as
vantagens do modelo cascata e do
desenvolvimento evolucionário;
 Em um processo de desenvolvimento incremental,
os clientes identificam, em um esboço, as funções
a serem fornecidas pelo sistema, definindo quais
são mais importantes e quais são menos
importantes;
 Em seguida é definida uma série de estágios de
entrega, com cada um fornecendo um subconjunto
das funcionalidades do sistema;
 As funções prioritárias são entregues
primeiramente ao cliente;
54
 Uma vez identificados os incrementos, os
requisitos para as funções a serem entregues no
primeiro incremento são definidos em detalhes;
 Esse incremento é desenvolvido, utilizando-se o
processo de desenvolvimento mais apropriado;
 Uma vez que um incremento é concluído e
entregue, os clientes podem colocá-lo em
operação;
 Isso significa que eles recebem com antecedência
parte da funcionalidade do sistema, podendo
experimentar o sistema, facilitando assim o
esclarecimento dos requisitos para os incrementos
seguintes;
55
 À medida que novos incrementos são
concluídos, eles são integrados aos
estágios existentes, melhorando a
funcionalidade do sistema a cada novo
estágio de entrega;
56
Definir esboço Atribuir requisitos Projetar arquite-

dos requisitos aos incrementos tura do sistema
Desenvolver incre- Validar incre- Integrar incre-

mento do sistema mento mento
Validar sistema
Sistema incompleto Sistema
Final
57
 Não existe a necessidade de utilizar o mesmo
processo para o desenvolvimento de cada
incremento;
 Quando as funções têm uma especificação
bem-definida, o modelo de desenvolvimento
em cascata pode ser utilizado;
 Quando a especificação for mal definida,
poderá ser utilizado um modelo de
desenvolvimento evolucionário.
58
 VANTAGENS 
 1. Os clientes não precisam esperar até que
todo o sistema seja entregue, para então
tirar proveito dele;
 2. Existe um risco menor de fracasso
completo do sistema. Embora possam ser
encontrados problemas em alguns
incrementos, é provável que alguns
incrementos sejam entregues com sucesso
ao cliente;
 3. Como as funções prioritárias são
entregues primeiro, é inevitável que elas
passem pela maior parte dos testes.
59
 PROBLEMAS 
 Os incrementos devem ser
relativamente pequenos, e cada
incremento deve produzir alguma
funcionalidade para o sistema;
 Pode, portanto, ser difícil mapear os
requisitos dos clientes dentro de
incrementos de tamanho correto.
60
 Extreme Programming
(programação extrema)  recente
evolução da abordagem incremental;
 Tem como base o desenvolvimento e
a entrega de incrementos de
funcionalidade muito pequenos, o
envolvimento do cliente no processo,
a constante melhoria de código e a
programação impessoal.
61
Desenvolvimento em Espiral
 Em vez de representar o processo de software
como uma seqüência de atividades com algum
retorno de uma atividade para outra, o
processo é representado como uma espiral;
 Cada loop na espiral representa uma fase do
processo de software;
 Assim, o loop mais interno pode estar
relacionado à vialibidade do sistema;
 O loop seguinte, à definição de requisitos para
o sistema;
 O próximo loop, ao projeto do sistema, e assim
por diante.
62
63
 Cada loop da espiral é dividido em
quatro setores:
 1. Definição de objetivos 
 São definidos os objetivos específicos
para essa fase do projeto;
 São identificados os riscos do projeto
e, dependendo dos riscos poderão ser
planejadas estratégias alternativas.
64
Definição dos objetivos
65
 2. Avaliação e redução de riscos 
 Para cada um dos riscos de projeto
identificados, é realizada uma análise
detalhada e são tomadas providências
para reduzir esses riscos;
 Por exemplo, se houver um risco de os
requisitos serem inadequados, poderá
ser desenvolvido um protótipo.
66
Avaliação e redução
de riscos
67
 3. Desenvolvimento e validação 
 Depois da avaliação dos riscos, é
escolhido um modelo de
desenvolvimento para o sistema;
 Por exemplo, se forem dominantes os
riscos relacionados à interface com o
usuário, pode ser utilizado o modelo
de desenvolvimento evolucionário
(prototipação).
68
Desenvolvimento
E
validação
69
 4. Planejamento 
 O projeto é revisto e é tomada uma
decisão sobre continuar com o
próximo loop da espiral;
 Se a decisão for continuar, serão
traçados os planos para a próxima
fase do projeto.
70
Planejamento
71
 Não há fases fixas, como especificação
ou projeto, no modelo em espiral;
 O modelo em espiral abrange outros
modelos de processo, como por
exemplo, prototipação;
 Diferença do modelo em espiral em
relação a outros modelos de processo
de software  explícita
consideração dos riscos no modelo
em espiral;
 Risco  algo que pode acontecer de
errado. 72
Especificação de Software
 Estabelece quais funções são requeridas pelo
sistema e as restrições sobre a operação e o
desenvolvimento do sistema;
 Essa atividade é chamada de Engenharia de
Requisitos  muito importante;
 O processo de engenharia de requisitos leva à
produção de um documento de requisitos, que é a
especificação para o sistema;
 Existem quatro fases principais no processo de
engenharia de requisitos 
73
Especificação de Software
 1. Estudo de Viabilidade  existe
tecnologia atual para o desenvolvimento do
sistema? Existem restrições orçamentárias?;
 2. Levantamento e análise de requisitos
 obtenção dos requisitos do sistema.
Entrevista, observação, sistemas
existentes, ...;
 3. Especificação de requisitos 
documento que especifica os requisitos;
 4. Validação de requisitos  verificação
dos requisitos quanto a pertinência,
consistência e integralidade. 74
Projeto e Implementação de
Software
 Um projeto de software é uma descrição
estruturada de software a ser
implementada, dos dados que são parte
do sistema, das interfaces entre os
elementos do sistema e dos algoritmos
utilizados;
 Métodos de Projeto 
 Projeto estruturado;
 Projeto orientado a objetos;
75
Projeto e Implementação de
Software
 Programação  atividade pessoal, sem
regras;
 Teste x Depuração
 Teste  estabelece a existência de
defeitos;
 Depuração  localiza e corrige esses
defeitos.
76
Validação de Software
 Destina-se a mostrar que um sistema está de
acordo com suas especificações e que atende às
expectativas do cliente;
 Processo de teste 
 1. Teste de unidade  componentes
individuais;
 2. Teste de módulo  coleção de componentes;
 3. Teste de subsistema  conjunto de módulos
integrados;
 4. Teste de sistema  integração dos
subsistemas;
 5. Teste de aceitação  o sistema é testado
com os dados fornecidos pelo cliente, no lugar
dos testes simulados.
77
Evolução de Software
 Manutenção de software  é o
processo de modificar o sistema
desenvolvido depois que o mesmo é
colocado em operação;
 O software é continuamente modificado
ao longo de seu tempo de duração, em
resposta a requisitos em constante
modificação e às necessidades do
cliente.
78
Ferramentas CASE
 É o nome dado ao software utilizado para
apoiar as atividades de processo de
software, como a engenharia de
requisitos, o projeto, o desenvolvimento
de programa e os testes;
 As ferramentas CASE, portanto, incluem
editores de projeto, dicionários de dados,
compiladores, depuradores, ferramentas
de construção de sistemas, entre outros.
79
Ferramentas CASE
 Exemplos de atividades que podem ser
automatizadas utilizando-se CASE 
 O desenvolvimento de modelos gráficos de
sistemas, como parte das especificações de
requisitos ou do projeto de software;
 A compreensão de um projeto utilizando-se
um dicionário de dados que contém
informações sobre as entidades e sua relação
em um projeto;
 A geração de interfaces com usuários;
80
Ferramentas CASE
 Exemplos de atividades que
podem ser automatizadas
utilizando-se CASE 
 A depuração de programas, pelo
fornecimento de informações sobre
um programa em execução;
 Tradução automatizada de programas,
a partir de uma antiga versão de uma
linguagem de programação, como
Cobol, para uma versão mais recente.
81

Introdução A Engenharia de Software

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Introdução A Engenharia de Software

Uploaded by

Copyright:

Available Formats

IFPR – Instituto Federal do Paraná – Campus Umuarama

Curso Técnico em Informática

Bibliografia: SOMMERVILLE, Ian. Engenharia de

 Em vez de ter as atividades de especificação,

 O processo de desenvolvimento de sistemas

 Desenvolvimento Baseado em Componentes.

 Alguns exemplos de ferramentas CASE 

Projeto de sistema Desenvolvimento Validação de

Especificação de Análise de Modificação de

Projeto de sistema Desenvolvimento Validação de

Especificação de Análise de Modificação de

Projeto de sistema Desenvolvimento Validação de

Especificação de Análise de Modificação de

Projeto de sistema Desenvolvimento Validação de

Especificação de Análise de Modificação de

Projeto de sistema Desenvolvimento Validação de

Especificação de Análise de Modificação de

Projeto de sistema Desenvolvimento Validação de

Especificação de Análise de Modificação de

Projeto de sistema Desenvolvimento Validação de

Definir esboço Atribuir requisitos Projetar arquite-

Desenvolver incre- Validar incre- Integrar incre-

Definição dos objetivos

You might also like