O documento apresenta conceitos sobre engenharia de software e modelos de desenvolvimento. Discute o que é software, as diferenças entre software e hardware, as características do software e sua evolução ao longo do tempo. Também aborda a crise do software e como a engenharia de software pode ajudar a resolver problemas na produção de software de forma sistemática, disciplinada e quantificável.

1. Conceitos e modelos de
desenvolvimento
Engenharia de Software
Prof: Sérgio Souza Costa

2. Sobre mim
Sérgio Souza Costa
Professor - UFMA
Doutor em Computação Aplicada (INPE)
prof.sergio.costa@gmail.com
https://sites.google.com/site/profsergiocosta/home
http://www.slideshare.net/skosta/presentations?order=popular
https://twitter.com/profsergiocosta
http://gplus.to/sergiosouzacosta

3. O que iremos aprender hoje ?

4. O que iremos aprender hoje ?
Conceitos sobre Engenharia de Software

5. O que iremos aprender hoje ?
Conceitos sobre Engenharia de Software
Modelos de desenvolvimento

6. O que iremos aprender hoje ?
Conceitos sobre Engenharia
de Software

7. Qual o primeiro conceito ? Por onde
devemos começar ? O que vocês acham ?

8. O que é software ?

9. O que é software?
Resposta não é obvia,
segundo Pressman, em
1970 menos de 1% dos profissionais poderiam ter
definido o que é software.

10. O que é software?
Produto que os engenheiros de software projetam e
constroem.

11. O que é software?
Produto que os engenheiros de software projetam e
constroem. Englobando:

12. O que é software?
Produto que os engenheiros de software projetam e
constroem. Englobando:
1) Instruções (programas de computadores,
código executável) que produzem algum resultado
desejado.

13. O que é software?
Produto que os engenheiros de software projetam e
constroem. Englobando:
2) Estruturas de dados que permitem que os
programas manipulem adequadamente a
informação.

14. O que é software?
Produto que os engenheiros de software projetam e
constroem. Englobando:
3) Documentação que descrevem o uso dos
programas.

15. O que é software?
SIM. Documentação,
aquela projetam
Produto que os engenheiros de softwareparte que ose
programadores não
constroem. Englobando:
morrem de amor.
3) Documentação que descrevem o uso dos
programas.

16. Então, software é um produto do engenheiro de
software, como um hardware é um produto de um
engenheiro eletrônico ? O que diferencia estes
produtos?

17. Então, software é um produto do engenheiro de
software, como um hardware é um produto de um
engenheiro eletrônico ? O que diferencia estes
produtos?
Software é lógico.
Hardware é físico.

18. Então, software é um produto do engenheiro de
software, como um hardware é um produto de um
engenheiro eletrônico ? O que diferencia estes
produtos?
Software é lógico.
Vamos ver melhor
estas diferenças, e
como isto reflete
na sua construção.
Hardware é físico.

19. CARACTERÍSTICAS DO SOFTWARE

20. Qual a diferença entre Hardware e
Software ?

21. 1. Desenvolvido ou projetado por engenharia,
não manufaturado no sentido clássico.

22. 1. Desenvolvido ou projetado por engenharia,
não manufaturado no sentido clássico.
Hardware - manufaturado
Projeto (modelo
conceitual)
Mundo Lógico
Artefatos (esquemas,
plantas, mapas ... )
Fabricação (manufaturado)
Mundo físico

23. 1. Desenvolvido ou projetado por engenharia,
não manufaturado no sentido clássico.
Software
Modelos
Alto nível
Baixo nível
Projeto (modelo
conceitual)
Artefatos (diagramas,
documentos ..)
Programa – modelo de
implementação
Mundo Lógico

24. 1. Desenvolvido ou projetado por engenharia,
Relaxem. Iremos
entender melhor isso
não manufaturado no sentido oclássico.
durante curso, na
Software
Modelos
Alto nível
Baixo nível
carreira, em algum
momento …
Projeto (modelo
conceitual)
Artefatos (diagramas,
documentos ..)
Programa – modelo de
implementação
Mundo Lógico

25. 1. Desenvolvido ou projetado por engenharia,
Relaxem. Iremos
entender melhor isso
A engenharia ainda
não manufaturado no sentido oclássico.
durante curso, na
está entendendo
Software
Modelos
Alto nível
Baixo nível
carreira, em algum
melhor
momento …estas
diferenças.
Projeto (modelo
conceitual)
Artefatos (diagramas,
documentos ..)
Programa – modelo de
implementação
Mundo Lógico

26. No
desenvolvimento
de
um
software
conceitualmente não existe um processo manual,
todos os envolvidos exercem um trabalho
intelectual.

27. No desenvolvimento de um software conceitualmente não
existe um processo manual, todos os envolvidos exercem
um trabalho intelectual.
Porém, onde e quem exerce o trabalho mais
similar a um trabalho “manual” em um
software ?

28. 2. Software não se desgasta como nos
hardware.

29. Como é a manutenção em um hardware ? e
em um software?

30. Curva de falha do hardware
Mortalidade infantil
Desgaste
Associada a falhas de
fabricação e ou projeto.
Desgaste
Falha
Mortalidade
infantil
Males ambientais, poeiras,
vibrações.
Todo hardware tem um
tempo de vida.
Temp
o

31. E no software, como vocês acham que é esta
curva ? Lembrem-se de que no software não
existe uma processo manufaturado, não
existem peças que se desgastam.

32. Falha
Curva de falha do software
Mudança
Curva real
Curva idealizada
Temp
o

33. Falha
Curva de falha do software
Mudança
Curva real
Curva idealizada
Temp
o

34. Contraditorio ?
Curva de falha do software
Consegueriam
Falha
explicar ?
Mudança
Curva real
Curva idealizada
Temp
o

35. Curva de falha do software
Falha
Incremento
devido os efeitos
colaterais
Mudança
Curva real
Curva idealizada
Temp
o

36. Efeitos colaterais, o pesadelo de todo
desenvolvedor de software.
Correção de erros, tendem a gerar novos erros.

37. Efeitos colaterais, o pesadelo de todo
desenvolvedor de software.
Correção de erros, tendem a gerar novos erros.
Desenvolvedores temem modificações, tentam a evitá-las.

38. Efeitos colaterais, o pesadelo de todo
desenvolvedor de software.
Correção de erros, tendem a gerar novos erros.
Desenvolvedores temem modificações, tentam a evitá-las.
Porém, mudanças são inevitáveis e temos que lidar com
isso.

39. Efeitos colaterais, o pesadelo de todo
Requisitos de
softwares
desenvolvedor de software. sempre
mudam.
Correção de erros, tendem a gerar novos erros.
Desenvolvedores temem modificações, tentam a evitá-las.
Porém, mudanças são inevitáveis e temos que lidar com
isso.

40. Efeitos colaterais, o pesadelo de todo
Requisitos de
softwares
desenvolvedor de software. sempre
mudam.
Vamos ver durante o
curso, mecanismo quetendem a gerar novos erros.
Correção de erros,
tentam tornar esse
processo menos
dolorosos.
Desenvolvedores temem modificações, tentam a evitá-las.
Porém, mudanças são inevitáveis e temos que lidar com
isso.

41. 3. A maioria é feita sob medida em vez de
ser montada a partir de componentes
existentes.

42. 3. A maioria é feita sob medida em vez de
ser montada a partir de componentes
existentes.
O reuso de “componentes de software” ainda não é
equivalente a outras engenharias, como no hardware.
Padrões ainda estão sendo desenvolvidos.

43. 3. A maioria é feita sob medida em vez de
ser montada a partir de componentes
existentes.
O reuso de “componentes de software” ainda não é
equivalente a outras engenharias, como no hardware.
Padrões ainda estão sendo desenvolvidos.
Existem diversos componentes padronizado para a
montagem de um hardware, parafusos, placas,
transistores, diodos, etc.

44. EVOLUÇÃO DO SOFTWARE

45. Evolução do Software
Os primeiros
anos
- ORIENTAÇÃO
BATCH
- DISTRIBUÍÇÃO
LIMITADA
- SOFTWARE
CUSTOMIZADO
1950
1960
1970
1980
2000

46. Evolução do Software
Os primeiros
anos
- ORIENTAÇÃO
BATCH
- DISTRIBUÍÇÃO
LIMITADA
- SOFTWARE
CUSTOMIZADO
1950
A segunda
era
- MULTIUSUÁRIO
- TEMPO REAL
- BANCO DE
DADOS
- PRODUTOS DE
SOFTWARE
1960
1970
1980
2000

47. Evolução do Software
Crise do software
Os primeiros
anos
- ORIENTAÇÃO
BATCH
- DISTRIBUÍÇÃO
LIMITADA
- SOFTWARE
CUSTOMIZADO
1950
A segunda
era
- MULTIUSUÁRIO
- TEMPO REAL
- BANCO DE
DADOS
- PRODUTOS DE
SOFTWARE
1960
1970
1980
2000

48. Evolução do Software
Crise do software
Os primeiros
anos
- ORIENTAÇÃO
BATCH
- DISTRIBUÍÇÃO
LIMITADA
- SOFTWARE
CUSTOMIZADO
1950
A terceira
era
A segunda
era
- MULTIUSUÁRIO
- TEMPO REAL
- BANCO DE
DADOS
- PRODUTOS DE
SOFTWARE
1960
1970
- SISTEMAS
DISTRIBUÍDOS
-INTELIGÊNCIA
EMBUTIDA
-HARDWARE DE
BAIXO CUSTO
- IMPACTO DE
CONSUMO
1980
2000

49. Evolução do Software
A quarta
era
Crise do software
Os primeiros
anos
- ORIENTAÇÃO
BATCH
- DISTRIBUÍÇÃO
LIMITADA
- SOFTWARE
CUSTOMIZADO
1950
A terceira
era
A segunda
era
- MULTIUSUÁRIO
- TEMPO REAL
- BANCO DE
DADOS
- PRODUTOS DE
SOFTWARE
1960
1970
- SISTEMAS
DISTRIBUÍDOS
-INTELIGÊNCIA
EMBUTIDA
-HARDWARE DE
BAIXO CUSTO
- IMPACTO DE
CONSUMO
- SISTEMAS DE
DESKTOP
PODEROSOS
- TECNOLOGIAS
ORIENTADAS
A OBJETOS
- SISTEMAS
ESPECIALISTAS
- REDES
NEURAIS
ARTIFICIAIS
- COMPUTAÇÃO
PARALELA
1980
2000

50. A crise do software
+ Complexidade
- Confiabilidade
Aumento crescente por
sistemas de Informação
Mais dependência do
software nos
procedimentos
normais do cotidiano
Sistemas mais e mais
sofisticados exigem mais
recursos (humanos e
máquinas)
Sistemas devem ser
mais e mais seguros.

51. A crise do software
Manutenabilidade
•Imprecisão nas especificações iniciais do projeto
•Muitas modificações exigidas pelo cliente
•Rotatividade acentuada da equipe de projeto
•Informações não muito bem documentadas
•Custo elevado nos estágios finais de projeto

52. Temos muitos PROBLEMAS, a quem
podemos recorrer ?

53. Temos muitos PROBLEMAS, a quem
podemos recorrer ?
ENGENHARIA

54. ENGENHARIA DE SOFTWARE de acordo com IEEE é a aplicação de
uma abordagem sistemática, disciplinada e quantificável no
desenvolvimento, operação e manutenção de software.

55. ENGENHARIA DE SOFTWARE de acordo com IEEE é a aplicação de
uma abordagem sistemática, disciplinada e quantificável no
desenvolvimento, operação e manutenção de software.
Sistemática por que parte do princípio de que existe um processo de
desenvolvimento definindo as atividades que deverão ser executadas.

56. ENGENHARIA DE SOFTWARE de acordo com IEEE é a aplicação de
uma abordagem sistemática, disciplinada e quantificável no
desenvolvimento, operação e manutenção de software.
Sistemática por que parte do princípio de que existe um processo de
desenvolvimento definindo as atividades que deverão ser executadas.
Disciplinada por que parte do princípio de que os processos definidos
serão seguidos

57. ENGENHARIA DE SOFTWARE de acordo com IEEE é a aplicação de
uma abordagem sistemática, disciplinada e quantificável no
desenvolvimento, operação e manutenção de software.
Sistemática por que parte do princípio de que existe um processo de
desenvolvimento definindo as atividades que deverão ser executadas.
Disciplinada por que parte do princípio de que os processos definidos
serão seguidos
Quantificável por que se deve definir um conjunto de medidas a serem
extraídas do processo

58. ENGENHARIA DE SOFTWARE de acordo com IEEE é a aplicação de
uma abordagem sistemática, disciplinada e quantificável no
desenvolvimento, operação e manutenção de software.
Sistemática por que parte do princípio de que existe um processo de
desenvolvimento definindo as atividades que deverão ser executadas.
Disciplinada por que parte do princípio de que os processos definidos
serão seguidos
Quantificável por que se deve definir um conjunto de medidas a serem
extraídas do processo
Desenvolvimento, operação e manutenção são fases do processo de
software.

59. ENGENHARIA DE SOFTWARE de acordo com IEEE é a aplicação de
uma abordagem sistemática, disciplinada e quantificável no
desenvolvimento, operação e manutenção de software.
Sistemática por que parte do princípio de que existe um processo de
desenvolvimento definindo as atividades que deverão ser executadas.
Disciplinada por que parte do princípio
serão seguidos
Mas o que é
de que os processos
um processo ?
definidos
Quantificável por que se deve definir um conjunto de medidas a serem
extraídas do processo
Desenvolvimento, operação e manutenção são fases do processo de
software.

60. ES – Uma tecnologia em camadas
Ferramentas
Métodos
Processo
Foco na qualidade
Adaptado de Roger Pressman

61. ES – Uma tecnologia em camadas
Ferramentas
Métodos
Processo
Foco na qualidade
Adaptado de Roger Pressman

62. Foco na qualidade
• A busca pela qualidade é o objetivo de usar
qualquer engenharia (não apenas da ES).
• Ela deve ser buscada em cada fase do processo de
desenvolvimento.
• Permite ao
– gerente um controle e ao
– desenvolvedor uma referência.

63. ES – Uma tecnologia em camadas
Ferramentas
Métodos
Processo
Foco na qualidade
Adaptado de Roger Pressman

64. Métodos
Os detalhes de “como fazer” para construir o software,
existem métodos para as diferentes tarefas.
Planejamento e estimativa de projeto
Análise de requisitos
Projeto da estrutura de dados
Codificação, teste,
manutenção

65. ES – Uma tecnologia em camadas
Ferramentas
Métodos
Processo
Foco na qualidade
Adaptado de Roger Pressman

66. Ferramentas
As ferramentas de engenharia de software proporcionam
apoio automatizado ou semi-automatizado aos métodos.
Cada tarefa, pode ter uma ou mais ferramenta auxiliando.
Se elas são integradas (troca de informação), chamamos de
ferramentas
• CASE (Computer-Aided Software Engineering), em
português Engenharia de Software Auxiliada por
Computador.

67. ES – Uma tecnologia em camadas
Ferramentas
Métodos
Processo
Foco na qualidade
Adaptado de Roger Pressman

68. Processo
O processo é a camada mais importante da ES, esta camada
constitui o elo de ligação entre as ferramentas e os métodos.
Um processo define :

69. Processo
O processo é a camada mais importante da ES, esta camada
constitui o elo de ligação entre as ferramentas e os métodos.
Um processo define :
A seqüência em que os métodos serão aplicados.
Quais os responsáveis por cada tarefa.
Quando e como o software será entregue.
Possibilitam aos gerentes de software avaliar o
progresso do desenvolvimento.

70. Processo
O processo é a camada mais importante da ES, esta camada
constitui o elo de ligação entre as ferramentas e os métodos.
Um processo define :
Uma empresa pode usar métodos
e ferramentas e não seguir
A seqüência em que osnenhum processo estabelecido.
métodos serão aplicados.
Existem até classificações para
empresas quanto ao uso de
Quais os responsáveis por cada tarefa.
processos.
Quando e como o software será entregue.
Possibilitam aos gerentes de software avaliar o
progresso do desenvolvimento.

71. Modelos de processo
Um processo é representado por um MODELO
prescritivo.
Um modelo prescritivo, nos dá uma referência, porem
sempre existe a necessidade de adaptá-lo a cada
projeto:
– O pessoal que vai executar o trabalho e o ambiente no
qual o trabalho vai ser conduzido.

72. Modelos de processo
Um processo é representado por um MODELO
prescritivo.
Modelos prescritivos
são versões
Um modelo prescritivo, nos dá apenas uma referência,
simplificadas, não sao
porem sempreprocessos.necessidade de adaptá-lo a
existe a
cada projeto:
– O pessoal que vai executar o trabalho e o ambiente no
qual o trabalho vai ser conduzido.

73. Modelos de processos
• Existem diversos modelos de processo como:
–
–
–
–
–
–
–
Cascata
Incremental
Protótipo
Espiral
Formal
4º geração
...

74. Modelos de processo
• Independente do modelo de processo, incluise as seguintes atividades:
–
–
–
–
–
Comunicação
Planejamento
Modelagem
Construção
Implantação

75. “Existem muitos modos de ir para frente, mas
apenas um modo de ficar parado.”
Franklin D. Rosevelt

76. Modelo em cascata
Conhecido como “ciclo de vida clássico”. Sugere
uma abordagem sistemática e seqüencial.
Filosofia: O resultado de uma fase se constitui
na entrada da outra e uma fase só começa,
após o termino da anterior.
O modelo mais antigo e ainda muito utilizado,
porém existem diversas variações.

77. Modelo em cascata
Comunicação
Iniciação do projeto,
levantamento de
requisitos

78. Comunicação
Os serviços, restrições e objetivos do sistema são
definidos por meio de consulta aos usuários do
sistema.
A especificação do sistema:
Quais informações os sistemas deverá prover
Quais informações os sistemas não deverá prover

79. Comunicação
Isto é
documentado e
“assinado”. Faz
Os serviços, restrições e objetivos do sistema são
parte do contrato.
definidos por meio de consulta aos usuários do
sistema.
A especificação do sistema:
Quais informações os sistemas deverá prover
Quais informações os sistemas não deverá prover

80. Comunicação
Exemplo de requisitos:
Em pequenos sistemas, uma ferramenta de planilhas
pode ser suficiente:
Ref:

81. Comunicação
Exemplo de requisitos:
Veremos sobre
engenharia de
requisitos, capitulo
7.
Em pequenos sistemas, uma ferramenta que planilhas
pode ser suficiente:
Ref:

82. Modelo em cascata
Comunicação
Iniciação do projeto,
levantamento de
requisitos
Planejamento
Estimativas,
cronogramas,
monitoração

83. Planejamento
O planejamento define o tempo estimado de
entrega.
Nele, deve ser definido o cronograma de
execução de cada atividade.
Além disso, deve se ter mecanismo que permita
a monitoração do projeto.
– Será que o projeto irá atender as estimativas,
sobre custo e tempo.

84. Planejamento
Ferramentas que auxilia, MSProject e OpenProject.

85. Modelo em cascata
Comunicação
Iniciação do projeto,
levantamento de
requisitos
Planejamento
Estimativas,
cronogramas,
monitoração
Modelagem
Análise e projeto

86. Modelagem
A análise e o projeto estabelecerá a arquitetura
geral do sistema e envolve:
Identificar e descrever as abstrações
fundamentais do sistema de software e suas
relações.

87. Modelagem
Nessa fase, se estivermos fazendo uso da UML,
precisaremos de ferramentas que construam os seus
diagramas.
Gato
Raça
Tamanho
Cor
caçar
brincar

88. Modelagem
Veremos estes
diagramas em
outra disciplina.
Nessa fase, se estivermos fazendo uso da UML,
precisaremos de ferramentas que construam os seus
diagramas.
Gato
Raça
Tamanho
Cor
caçar
brincar

89. Modelo em cascata
Comunicação
Iniciação do projeto,
levantamento de
requisitos
Planejamento
Estimativas,
cronogramas,
monitoração
Modelagem
Análise e projeto
Construção
Codificação,
teste

90. Codificação e teses
O projeto de software é traduzido para um
conjunto de programas ou unidades (funções,
objetos, componentes, etc).
Nesta fase, são feitos testes unitários, que
envolve a verificação de que cada unidade
atende sua especificação.

91. Codificação e teses
Nesta fase, é usual utilizar uma IDE (Integrated Development
Environment), ou ambiente integrado de desenvolvimento, por
exemplo o Eclipse.
No Java existe a JUnit para testes de unidade

92. Modelo em cascata
Comunicação
Iniciação do projeto,
levantamento de
requisitos
Planejamento
Estimativas,
cronogramas,
monitoração
Modelagem
Análise e projeto
Construção
Implantação
Entrega,
manutenção,
feedback
Codificação,
teste

93. Implantação
As unidades individuais de programa e ou programas, são
integrados e testados buscando garantir os requisitos de
software foram atendidos.
Após os testes o sistema é entregue e implantado para o
cliente.
Manutenção, envolve a correção de erros não detectados.
Além da ampliação dos serviços do sistema á medida que
novos requisitos são identificados

94. Implantação
Como é a
implantação em
sistemas desktop e
As unidades individuais de programa e ou programas, são
em sistemas Web?
integrados e testados buscando garantir os requisitos de
software foram atendidos.
Após os testes o sistema é entregue e implantado para o
cliente.
Manutenção, envolve a correção de erros não detectados.
Além da ampliação dos serviços do sistema á medida que
novos requisitos são identificados

95. Implantação
Como é a
implantação em
sistemas desktop e
As unidades individuais de programa e ou programas, são
em sistemas Web?
integrados e testados buscando garantir os requisitos de
software foram atendidos.
Após os testes o sistema é entregue e implantado para o
cliente.
Manutenção, envolve a correção de erros não detectados.
Além da ampliação dos serviços do sistema á medida que
novos requisitos são identificados
Requisitos sempre
mudam

96. Modelo cascata
• Pontos fortes

97. Modelo cascata
• Pontos fortes
–
–
–
–
Mais antigo e testado modelo de processo
Enfoque sistemático e sequencial das tarefas
Muitas melhorias e variações,
É o arcabouço de referência a diversos outros
modelos de processos.

98. Modelo cascata
• Pontos fracos

99. Modelo cascata
• Pontos fracos
– Projetos reais raramente seguem um fluxo seqüencial.
– Os Clientes e Usuários não conseguem estabelecer de forma clara e
completa os requisitos de sistema no início do desenvolvimento.
– Grande demora até a entrega do produto ao cliente (primeira
apreciação).
– Alto custo da correção das especificações quando na fase da
integração e teste.

100. Modelo incremental
Combina elementos do modelo em cascata, aplicado de
maneira iterativa.
Aplica seqüência lineares, de modo cada sequencia
produz incrementos do software.

101. Modelo incremental
Combina elementos do modelo em cascata, aplicado de
maneira iterativa.
Aplica seqüência lineares, de modo cada sequencia
produz incrementos do software.
Um incremento, é um produto operacional.

102. Modelo incremental
Combina elementos do modelo em cascata, aplicado de
maneira iterativa.
Aplica seqüência lineares, de modo cada sequencia
produz incrementos do software.
Um incremento, é um produto operacional.
Os primeiros incrementos são versões
simplificadas.

103. Modelo incremental
Comunicação
Planejamento
Funcionalidades
Modelagem
Construção
Implantação
Incremento 1
Tempo decorrido

104. Modelo incremental
Comunicação
Planejamento
Funcionalidades
Modelagem
Construção
Implantação
Incremento 2
Incremento 1
Tempo decorrido

105. Modelo incremental
Incremento N
Comunicação
Planejamento
Funcionalidades
Modelagem
Construção
Implantação
Incremento 2
Incremento 1
Tempo decorrido

106. Modelo incremental
• Enfoque para sistemas modulares ou baseado
em subsistemas.
• Utilizado como estratégia para projetos muito
grandes.
• Evita problemas de perda de controle: custo e
prazos.
• É um modelo evolucionário.

107. Modelo incrementalexemplo, os modelos
Por
unificados que vocês
verão em orientação
objeto tem como
referência o modelo
incremental.
• Enfoque para sistemas modulares ou baseado
em subsistemas.
• Utilizado como estratégia para projetos muito
grandes.
• Evita problemas de perda de controle: custo e
prazos.
• É um modelo evolucionário.

108. Modelo incrementalexemplo, os modelos
Por
unificados que vocês
verão em orientação
Já objeto tem como em
ouviram falar
referência o modelo
métodos ágeis ?
incremental.
• Enfoque para sistemas modulares ou baseado
em subsistemas.
Eles tambem são
incrementais.
• Utilizado como estratégia para projetos muito
grandes.
• Evita problemas de perda de controle: custo e
prazos.
• É um modelo evolucionário.

109. Pontos chaves: Conceitos ES
• Software, são os 1) programas, 2) estruturas de dados e 3)
documentação.
• A ES nasce pra resolver diversos problemas que foram
agravados com o incremento na quantidade e complexidade
dos softwares.
• ES é a aplicação de uma abordagem sistemática, disciplinada
e quantificável no desenvolvimento, operação e manutenção
de software.
• Um processo define que métodos e quais ferramentas usar
para atingir um nível de qualidade.

110. Pontos chaves: Modelos
• Um modelo descreve uma visão simplificada do
processo.
• Um modelo deve ser ajustado as necessidades do
projeto específico.
• Um modelo de processo genérico inclui: comunicação,
planejamento, modelagem, construção e implantação.
• Existem diversos modelos, vimos hoje o modelo em
cascata, conhecido como ciclo de vida clássico.
• E o modelo incremental, que é baseado no modelo em
cascata, porém divide o sistemas em incrementos, que
possui uma funcionalidade e seu próprio cronograma

111. Como o projeto foi
documentado.
Como o lider do
projeto entendeu.
Como o projeto foi
instalado.
Como o analista
projetou.
Como o cliente
pagou
Como o
programador
escreveu.
O que o cliente
realmente precisava.
http://www.projectcartoon.com/cartoon/58
Como o cliente
definiu.

112. Exercitando o cérebro....
• As atividades deverão ser enviadas por email
antes do início da próxima aula.