Engenharia de Software - Conceitos e Modelos de Desenvolvimento

19,312 views
18,935 views

Published on

1 Comment
11 Likes
Statistics
Notes
No Downloads
Views
Total views
19,312
On SlideShare
0
From Embeds
0
Number of Embeds
11
Actions
Shares
0
Downloads
848
Comments
1
Likes
11
Embeds 0
No embeds

No notes for slide

Engenharia de Software - Conceitos e Modelos de Desenvolvimento

  1. 1. Conceitos e modelos de desenvolvimento Engenharia de Software Prof: Sérgio Souza Costa
  2. 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. 3. O que iremos aprender hoje ?
  4. 4. O que iremos aprender hoje ? Conceitos sobre Engenharia de Software
  5. 5. O que iremos aprender hoje ? Conceitos sobre Engenharia de Software Modelos de desenvolvimento
  6. 6. O que iremos aprender hoje ? Conceitos sobre Engenharia de Software
  7. 7. Qual o primeiro conceito ? Por onde devemos começar ? O que vocês acham ?
  8. 8. O que é software ?
  9. 9. O que é software? Resposta não é obvia, segundo Pressman, em 1970 menos de 1% dos profissionais poderiam ter definido o que é software.
  10. 10. O que é software? Produto que os engenheiros de software projetam e constroem.
  11. 11. O que é software? Produto que os engenheiros de software projetam e constroem. Englobando:
  12. 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. 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. 14. O que é software? Produto que os engenheiros de software projetam e constroem. Englobando: 3) Documentação que descrevem o uso dos programas.
  15. 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. 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. 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. 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. 19. CARACTERÍSTICAS DO SOFTWARE
  20. 20. Qual a diferença entre Hardware e Software ?
  21. 21. 1. Desenvolvido ou projetado por engenharia, não manufaturado no sentido clássico.
  22. 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. 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. 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. 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. 26. No desenvolvimento de um software conceitualmente não existe um processo manual, todos os envolvidos exercem um trabalho intelectual.
  27. 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. 28. 2. Software não se desgasta como nos hardware.
  29. 29. Como é a manutenção em um hardware ? e em um software?
  30. 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. 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. 32. Falha Curva de falha do software Mudança Curva real Curva idealizada Temp o
  33. 33. Falha Curva de falha do software Mudança Curva real Curva idealizada Temp o
  34. 34. Contraditorio ? Curva de falha do software Consegueriam Falha explicar ? Mudança Curva real Curva idealizada Temp o
  35. 35. Curva de falha do software Falha Incremento devido os efeitos colaterais Mudança Curva real Curva idealizada Temp o
  36. 36. Efeitos colaterais, o pesadelo de todo desenvolvedor de software. Correção de erros, tendem a gerar novos erros.
  37. 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. 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. 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. 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. 41. 3. A maioria é feita sob medida em vez de ser montada a partir de componentes existentes.
  42. 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. 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. 44. EVOLUÇÃO DO SOFTWARE
  45. 45. Evolução do Software Os primeiros anos - ORIENTAÇÃO BATCH - DISTRIBUÍÇÃO LIMITADA - SOFTWARE CUSTOMIZADO 1950 1960 1970 1980 2000
  46. 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. 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. 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. 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. 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. 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. 52. Temos muitos PROBLEMAS, a quem podemos recorrer ?
  53. 53. Temos muitos PROBLEMAS, a quem podemos recorrer ? ENGENHARIA
  54. 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. 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. 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. 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. 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. 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. 60. ES – Uma tecnologia em camadas Ferramentas Métodos Processo Foco na qualidade Adaptado de Roger Pressman
  61. 61. ES – Uma tecnologia em camadas Ferramentas Métodos Processo Foco na qualidade Adaptado de Roger Pressman
  62. 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. 63. ES – Uma tecnologia em camadas Ferramentas Métodos Processo Foco na qualidade Adaptado de Roger Pressman
  64. 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. 65. ES – Uma tecnologia em camadas Ferramentas Métodos Processo Foco na qualidade Adaptado de Roger Pressman
  66. 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. 67. ES – Uma tecnologia em camadas Ferramentas Métodos Processo Foco na qualidade Adaptado de Roger Pressman
  68. 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. 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. 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. 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. 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. 73. Modelos de processos • Existem diversos modelos de processo como: – – – – – – – Cascata Incremental Protótipo Espiral Formal 4º geração ...
  74. 74. Modelos de processo • Independente do modelo de processo, incluise as seguintes atividades: – – – – – Comunicação Planejamento Modelagem Construção Implantação
  75. 75. “Existem muitos modos de ir para frente, mas apenas um modo de ficar parado.” Franklin D. Rosevelt
  76. 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. 77. Modelo em cascata Comunicação Iniciação do projeto, levantamento de requisitos
  78. 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. 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. 80. Comunicação Exemplo de requisitos: Em pequenos sistemas, uma ferramenta de planilhas pode ser suficiente: Ref:
  81. 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. 82. Modelo em cascata Comunicação Iniciação do projeto, levantamento de requisitos Planejamento Estimativas, cronogramas, monitoração
  83. 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. 84. Planejamento Ferramentas que auxilia, MSProject e OpenProject.
  85. 85. Modelo em cascata Comunicação Iniciação do projeto, levantamento de requisitos Planejamento Estimativas, cronogramas, monitoração Modelagem Análise e projeto
  86. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 96. Modelo cascata • Pontos fortes
  97. 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. 98. Modelo cascata • Pontos fracos
  99. 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. 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. 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. 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. 103. Modelo incremental Comunicação Planejamento Funcionalidades Modelagem Construção Implantação Incremento 1 Tempo decorrido
  104. 104. Modelo incremental Comunicação Planejamento Funcionalidades Modelagem Construção Implantação Incremento 2 Incremento 1 Tempo decorrido
  105. 105. Modelo incremental Incremento N Comunicação Planejamento Funcionalidades Modelagem Construção Implantação Incremento 2 Incremento 1 Tempo decorrido
  106. 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. 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. 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. 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. 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. 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. 112. Exercitando o cérebro.... • As atividades deverão ser enviadas por email antes do início da próxima aula.

×