Introducao

2. Conteúdo Quem cuida da criação de software

3. Engenharia de software (perspectivas)

4. Existem problemas no mundo

5. Elementos de uma solução computacional

6. Atividades e dependências entre elas para uma solução

7. Problema, solução e código

8. Por que análise, projeto e codificação?

9. Linguagens empregadas

10. Problemas de desenvolvimento e “regras de ouro”

11. Estímulo econômico para construir software

12. Revisão

13. Quem cuida da criação de software “ Esplanada dos Ministérios” Qual o percurso para software? Engenharia Civil Engenharia de Software Próxima da idéia (1957) Resultado (2000)

14. Engenharia de software (perspectivas) Algumas perspectivas Atividades

15. Artefatos

16. Pessoas

17. Processo

18. Métodos

19. Projeto

20. Qualidade Ênfase em desenvolvimento Alguns artefatos

21. Algumas atividades Não aborda processo

22. Não aborda gerência de projeto Esta apresentação:

23. Reconheça a existência de problemas Guerras

24. Baixa qualidade de serviços prestados

25. Custos elevados de produção

26. Cura de muitas enfermidades

27. ... Alguns podem ser “resolvidos” por computador Alvo da computação Problemas existentes

28. Computação pode resolver problemas Mas não todos os problemas

29. Elementos de solução computacional Software não é só código! DADOS CÓDIGO DOCUMENTOS

30. Atividades necessárias... Analisando... Problema é definido

31. Projetando... Modelo de solução que emprega computador

32. Implementando... Código obtido a partir do projeto ... de toda solução computacional Solução computacional Implementação Projeto Análise

33. Dependência entre atividades Primeiro caracterize o problema Sem problema não há o que fazer

34. Depois crie o projeto (a solução computacional) Etapa laboriosa, extensa. Deve-se adquirir habilidades para tal.

35. Converta o projeto em código Sem projeto não há o que codificar. Considere a máquina conforme a liberdade possível. Problema  Solução  Código Análise Projeto Implementação

36. Problema O que é preciso? Compreendê-lo Como se faz? Analisando-o Como saber se foi compreendido? Validando com os usuários (clientes) Antes da análise Após a análise “idealmente” Análise Atividade “mais difícil”

37. Projeto O que é preciso? Criá-lo (exige registro) Como se faz? Princípios de projeto

38. Exercitando o raciocínio lógico Como saber se está correto? Verificando a solução

39. Algoritmo (parte de projeto detalhado) Abstração de um programa

40. Seqüência de passos de execução finita

41. Produz um resultado esperado Algoritmo = modelo de solução computacional Qualquer seqüência de passos cuja execução dá origem a um resultado desejado em tempo finito ... é exemplo de algoritmo!

42. Projeto não é só algoritmo Definição de partes da solução

43. Mecanismo de interação entre as partes

44. Influencia várias qualidades ... Facilidade de manutenção

45. Desempenho e outras ... Projetista de software Criação de algoritmos Atividades de projeto de software Sem o projeto, não há o que codificar!

46. Código Está para Energia Gasolina Lâmpada Carro Assim como ... Programa Está para Computador

47. Programa O que é preciso? Linguagem de programação

48. Compreender algoritmo

49. Conhecer o computador Como se faz? Reescreva o projeto na linguagem de programação Como saber se está correto? Verificando e Validando (V&V) Não é razoável escrever programa sem a existência de uma solução correspondente.

50. Algoritmo e programa correspondente Algoritmo Permutacao(p,S) Se S possui um caractere então Imprima p seguido de S Senão para i  0 até (n-1) faça S’  S – c i p’  p + c i Permutacao(p’,S’) fim para fim se #include <stdio.h> void Permutacao(char* p, char* S) { char Slinha[10], pLinha[10]; int c; if (strlen(S) == 1) printf("\n%s%s",p,S); else for (c = 0; c < strlen(S); c++) { memset(Slinha,0,10); memset(pLinha,0,10); strncpy(Slinha,S,c); strcat(Slinha,S+c+1); strcat(pLinha,p); strncat(pLinha,S+c,1); Permutacao(pLinha,Slinha); } } Algoritmo (projeto) Programa em C Acrescenta detalhes da linguagem, computador ...

51. Por que análise, projeto e codificação? Problema Projeto Software Como poderia ser diferente? Análise Codificação Entender o problema Definir uma solução Escrever o software conforme a solução

52. SWEBOK® Requisitos

53. Projeto

54. Construção

55. Testes

56. Manutenção

57. Gerência de Configuração Gerência de Projeto

58. Processos

59. Qualidade

60. Métodos e Ferramentas

61. Uma visão “bem” geral Requisitos (o que fazer?)

62. Projeto (como fazer?)

63. Construção (contruir)

64. Testes (localizar problemas)

65. Manutenção (evoluir)

66. Gerência de Configuração (gerir artefatos)

67. Gerência de Projeto (coordenar ações)

68. Processos (passos e produtos)

69. Qualidade (atender necessidades)

70. Métodos e Ferramentas (instrumentos)

71. Ordem Requisitos antes de Projeto

72. Projeto antes de Construção

73. Construção antes de Testes (exceto TDD)

74. Manutenção após Construção

75. Qualidade por todo o projeto

76. Gerência de Projeto por todo o projeto

77. Gerência de configuração por todo o projeto

78. Processo por todo o projeto

79. Métodos e ferramentas por todo o projeto

80. Algumas estão “sempre” em execução Processo

81. Gerência de Configuração

82. Métodos e Ferramentas

83. Gerência de Projeto

84. Qualidade

85. Requisitos Não é tópico realizado apenas no início de um projeto (ou seja, exige gerência)

86. Requisitos podem ser funcionais Calcular a nota final como média das notas Requisitos podem ser não funcionais Calcular pelo menos 1000 notas finais em 5s

87. Projeto Compreende: Arquitetura

88. Projeto detalhado Arquitetura Principais componentes

89. Partes da solução e como interagem Projeto detalhado Detalhar o suficiente para permitir a construção

90. Construção Criação do código

91. Testes de unidade

92. Testes de integração

93. Depuração

94. Testes Sempre implica na execução de programa

95. Ou seja, análise estática de código não é teste

96. São finitos

97. Deve ser possível definir resultados aceitáveis para uma dada entrada

98. Manutenção Software deve evoluir Atender novos requisitos

99. Corrigir erros Segundo o padrão IEEE Standard for Software Maintenance, IEEE 1219 “ modificação de um software, após entrega, para corrigir falhas, melhorar desempenho ou outros atributos, ou para se adaptar a um ambiente modificado”.

100. Gerência de Configuração O desenvolvimento de software gera vários artefatos

101. Artefatos evoluem ao longo do tempo

102. Gerência de Configuração Identifica artefatos (itens de configuração)

103. Controla mudanças nos artefatos Baseline Conjunto de itens de configuração “aprovado”

104. Serve para referência posterior

105. Ger ência de Projeto O desenvolvimento de um software pode envolver um ou mais projetos

106. Manutenção pode envolver um ou mais projetos

107. Gerência visa: planejar, dirigir, acompanhar e fechar um projeto Estimar esforço, alocar recursos, gerenciar riscos, contratar profissionais, ...

108. Processos de software “Atividades realizadas por uma organização para produzir ou manter software”

109. A norma 12207 apresenta vários processos

110. MPS.BR visa a “melhoria de processo do software brasileiro”

111. Métodos e ferramentas Ambientes integradas de desenvolvimento, compiladores, ferramentas para builds, …

112. Métodos orientados a objetos, métodos formais, ...

113. Qualidade Satisfazer o uso pretendido do produto

114. Requisitos de software definem as características desejadas de qualidade

115. Ou seja, pode ser interpretada como conformidade aos requisitos

116. Empregadas no desenvolvimento de software Linguagens

117. Linguagens naturais Português

118. Inglês

119. Espanhol

120. Japonês, ...

121. Linguagens para computadores Padrões de bits 01110101000110110111...

122. Assembly Linguagem de montagem

123. Linguagens de “alto nível” Delphi, VB, C++, Java

124. ?? Mais abstração = maior produtividade Abstração crescente

125. Linguagens ao longo do tempo Linguagens naturais Linguagem de máquina Mais abstração Menos abstração Linguagem algorítmica Linguagem de programação Cérebro Cérebro Compilador UML “ Fronteira” homem-máquina

126. Outras questões relevantes do desenvolvimento de programas Processo de desenvolvimento

127. Problemas de desenvolvimento Pressa em codificar Falta de planejamento Conhecimento ingênuo

128. Suposição bem-aceita Processo bom, resultado bom! Processo ruim, resultado ruim! Desenvolver programas exige trabalho em equipe

129. Ausência de disciplina Ausência de disciplina = usuário insatisfeito Não confundir com ausência de formalidade. Formigas são “informais” e “disciplinadas”.

130. Ferramentas “boas” são suficientes? Bons instrumentos fazem boa música? Bom prato é obtido com um bom fogão? Emprego da Última tecnologia Não necessariamente

131. Estímulo ... Microsoft Empresa de maior valor de mercado do mundo

132. 50000 funcionários Wall-Mart Quinta maior

133. Quase 1,5 milhão de funcionários Comparação: Coca-cola está em 16o. Software “bom” = Dinheiro Dados obtidos em www. forbes .com para 2003

134. Você acredita nisso? Não existe solução mágica! Lâmpada mágica para construção de software. COMPRE AGORA! Pague só em 60 dias!

135. Considerações finais Software “bom” é “difícil” de ser construído

136. Desenvolver programas exige raciocínio

137. Envolve atividades e artefatos

138. Envolve várias linguagens

139. Envolve análise, projeto

140. Envolve implementação Desenvolver software “bom” = muito esforço ?

Introducao

Mais conteúdo relacionado

Mais procurados (20)

Destaque (10)

Semelhante a Introducao (20)

Mais de Fábio Nogueira de Lucena (20)

Último (7)

Introducao

Notas do Editor