O documento introduz o conceito de Engenharia de Software, discutindo sua origem e objetivos de transformar o desenvolvimento de software de uma atividade artística para um processo controlado e previsível. Apresenta também exemplos históricos de projetos de software problemáticos e seus impactos, e discute modelos de processos e boas práticas para o desenvolvimento de software, como CMMI e PMBok.

1. Introdução a Engenharia de Software Matheus Souto Maior [email_address] @msouto

2. Engenharia de Software Engenharia = “é a atividade em que os conhecimentos científicos são empregados para resolver problemas práticos” Engenharia de Software = “é a atividade em que os [conhecimentos científicos] são empregados para resolver problemas práticos relacionados à construção de software ”

3. Objetivo “ Um dos objetivos básicos da Engenharia de Software é transformar a criação de sistemas software realizada de maneira artística , indisciplinada e pouco entendível para uma forma devidamente controlada , quantificada e previsível .”

4. Origem... em 1968, especialistas se reúnem em Garmisch, para discutir problemas de desenvolvimento de software http://homepages.cs.ncl.ac.uk/brian.randell/NATO/index.html

5. problemas “da época” Produtos de Software de baixa qualidade e sem atender requisitos e Projetos realizados acima do orçamento e do tempo previsto e vez por outra ingerenciáveis

6. A Crise de Software

7. "[The major cause of the software crisis is] that the machines have become several orders of magnitude more powerful! To put it quite bluntly: as long as there were no machines, programming was no problem at all; when we had a few weak computers, programming became a mild problem, and now we have gigantic computers, programming has become an equally gigantic problem." Edsger Dijkstra: The Humble Programmer

8. A crise de Software

9. O Caso do DABHS (Denver Airport Baggage Handling System) Características: 4000 Telecars 21 milhas de trilhos 5000 Olhos Eletrônicos, 400 Receptores de Rádio, 56 Scanners, 100 computadores em rede Estava planejado que o Aeroporto de Denver abriria em 31 de Outubro de 1993 Problemas no desenvolvimento do DABHS fizeram que o aeroporto abrisse em 28 de Fevereiro de 1995 Prejuízos devido ao atraso: Capacidade do sistema foi drasticamente diminuída Aproximadamente $ 500.000.000 ($1.1M por dia)

10. O Caso da Integração SABRE SABRE ( Semi-Automated Business Research Environment ) Sistema de Reserva da American Airlines Terminado no fim da década de 50 Construído pela IBM $2 bilhões Tentativa de Integração com sistemas de reserva de carros e hotel Em 1992 o projeto foi cancelado $165.000.000 jogados fora

11. Therac-25 Equipamento de Radioterapia, controlado por computador criada pela empresa AECL (Atomic Energy of Canada Limited) Muito moderna para sua época Entre 1985 e 1987 se envolveu 6 em acidentes 5 mortes por overdoses de radiação

12. Therac-25 Causas: O código do software não havia sido revisado/testado independentemente; O projeto do software não havia sido documentado com detalhes suficientes para permitir o entendimento dos erros A documentação do sistema fornecida aos usuários não explicava o significado dos códigos de erro que a máquina retornava http://pt.wikipedia.org/wiki/Therac-25

13. Ariane 5 Projeto da Agência Espacial Européia 10 anos de desenvolvimento US$ 8 Bilhões Carga avaliada em US$500 Milhões Em 4 de junho de 1996, menos de um minuto após o lançamento o foguete se autodestruiu

14. Ariane 5 Causa: Ocorreu um run time error (erro de execução) e ambos computadores se desligaram. Um programa que convertia um valor de ponto flutuante para um inteiro de 16 bits recebeu como entrada um valor que estava fora da faixa permitida. Inclusive o resultado da conversão não era mais necessário após a decolagem.

15. Processos para construção de Software

17. Processo de Desenvolvimento de Software Modelo Cascata

18. Análise de Requisitos Entendimento das necessidades do cliente Especificação das necessidades Linguagem mais técnica Análise da viabilidade do escopo Estimativas de Custo e Prazo

19. Para que “Análise de Requisitos”?

20. Processo de Engenharia de Requisitos

21. Gerenciamento de Requisitos Evolução dos requisitos

22. Gerenciamento de mudanças de requisitos

23. Análise e Projeto Desenho lógico da solução Tomada de decisão sobre coisas como Linguagem de Programação Plataforma de Desenvolvimento Integração com outros sistemas Detalhes técnicos

24. Arquitetura Lógica de Software

25. Exemplo de Arquitetura Física

26. Implementação Codificação do sistema Integração dos módulos Testes isolados Otimização de módulos já construídos

27. Tecnologias de desenvolvimento de Software J2ME J2SE J2EE

28. Testes Tem como objetivo identificar erros inseridos durante a construção Testes Funcionais Testes de Performance Testes de Carga Testes de Certificação ...

29. Implantação Tem como objetivo a instalação do software no ambiente final de execução Instalação Treinamento Configuração Adaptação

30. Processo de Desenvolvimento

31. Outros modelos de ciclo de vida do software

32. Modelo de prototipação

33. Modelo orientado a reuso

34. Desenvolvimento incremental

35. Modelo Espiral (evolucionário)

36. Exercício I Identificar todos os modelos de processos apresentados e construir um quadro comparativo. Postar no grupo

37. Por que organizar o desenvolvimento de software??

38. Windows Vista 5000 desenvolvedores (sem incluir pessoal não-técnico); 40 milhões de linhas de código; 16 milhões de linhas de código somente nos últimos 3 anos; Versões compiláveis todos os dias; Testes de regressão; Intervalo de 3 dias para um mudança submetida aparecer no executável; ~1.7 pessoas testando para cada programador; Precisa ter compatibilidade com versões anteriores; Precisa ser instalado em milhares de configurações diferentes;

39. intuitive surgical da vinci

40. intuitive surgical da vinci

41. Telecomunicação e Mobilidade

42. Indústria automotiva Electronic Stability Program

43. Transações Financeiras

44. Alguns números atuais...

45. Quanto melhoramos?

46. chaos report

47. Team Size {dev vs. test} o século de software...ou o século dos problemas de software? – Silvio Meira Product Dev Team Size Test Team Size NT 3.1 (6->) 200 140 NT 3.5 300 230 NT 3.51 450 325 NT 4.0 800 700 Win2k 1400 1700

48. Defect Rates Data With serialized development: Good, small teams operate efficiently Even the absolute best large teams are always broken, and always serialized o século de software...ou o século dos problemas de software? – Silvio Meira Product and Team Size Defects: Per year Per Dev Time to Fix: Per Defect Defects: Per Day Total Defect Fix Time NT 3.1, 200 2 20 minutes 1 20 minutes NT 3.5, 300 2 25 minutes 1.6 41 minutes NT 3.51, 450 2 30 minutes 2.5 1.2 hours NT 4.0, 800 3 35 minutes 6.6 3.8 hours Win2k, 1400 4 40 minutes 15.3 10.2 hours

49. Mas Engenharia de Software não é só técnica... “ The book demonstrates that the major issues of software development are human, not technical.”

50. Mas nem tudo está perdido....

51. Corpo da Engenharia de Software (SWEBOK)

52. Corpo da Engenharia de Software (SWEBOK)

53. CMMi – Capability Maturity Model Integration

54. Em Otimização Gerenciado Quantitativamente Definido Largamente Definido Parcialmente Definido Gerenciado Parcialmente Gerenciado A B C D E F G Relacionamento com o CMMI MR-MPS 2 3 4 5

55. PMBok Corpo de conhecimento da Gestão de Projetos Tem como objetivo divulgar e padronizar as melhores práticas de gestão de projetos

56. Obrigado! Matheus Souto Maior [email_address] @msouto