Introdução à Engenharia de
Software – Aula 1
Roteiro
●
Software
Importância de Software na Sociedade Atual
Definições de Software
Tipos de Software
Uso de Software
●
Engenharia de Software
Motivação para Engenharia de Software
Crise de Software
Razões para Falhas em Projetos de Software
Dificuldades Inerentes a Software
Importância de Software na
Sociedade Atual
●
A economia das nações é altamente dependente
de software
●
Vários sistemas são controlados por software
Um celular típico contém cerca de 2 milhões de linhas de código de software (este número deve ser 10 vezes maior em 2010) [1]
A General Motors estima que em 2010 seus carros terão, cada, 100 milhões de linhas de código de software [1]
Um Boeing 787 Dreamliner, que deve ficar pronto em 2010, terá cerca de 6,5 milhões de linhas de código de software [1]
Importância de Software na
Sociedade Atual
●
Exemplos de componentes de carros em que há
software embutido:
Importância de Software na
Sociedade Atual
●
Custos de software são significativos
Custos de software em um PC são freqüentemente maiores do que os custos de hardware
No caso de carros, por exemplo, os custos de software e eletrônicos foram de 5% em 1970 para 15% em 2005. Em alguns carros atualmente estes custos chegam a 45%. Estima-se que em 10 anos estes custos subam para 80% [1]
Definições de Software
●
Programas de computador e documentação
associada [2]
●
Novo software pode ser criado
Pelo desenvolvimento de novos programas
Pela configuração de sistemas de software genéricos Pelo reuso de software existente
Definições de Software
●
De acordo com Brooks [3]:
Um programa é um software
Um programa-produto é um programa que
● Tem documentação e pode ser executado, testado, modificado e estendido por qualquer pessoa
Um sistema de programas é um software que
● Envolve vários programas, projetados para funcionarem integrada e cooperativamente
Sistemas de programa-produto são o objeto da Engenharia de Software
Tipos de Software
●
Software de sistema
Programas escritos para servir outros programas
●
Software aplicativo
Programas standalone que satisfazem uma necessidade de negócio específica
●
Software científico e de engenharia
Programas que apóiam atividades científicas e de engenharia (design, simulação, cálculos)
Tipos de Software
●
Software embarcado
Programas embutidos em produtos e sistemas, que implementam e controlam características e funções para o usuário final ou para o próprio sistema
●
Software não-determinístico ou de IA
Programas que resolvem problemas complicados e que não são resolvidos diretamente por análise e computação
●
Software para Web (WebApps)
Programas desenvolvidos para a Web (exemplo: software para e-commerce)
Uso de Software
●
Para quê as organizações desenvolvem e
utilizam software?
Reduzir custos, substituindo processos manuais e sujeitos a erros
Aumentar a produtividade das pessoas
Obter capacidades anteriormente não possíveis Aumentar a capacidade de tomar decisões
Motivação para Engenharia de
Software
Roteiro
●Tópico 1
Subtópico 1
Subtópico 2
●Tópico 2
Subtópico 1
Subtópico 2
●Tópico 3
Subtópico 1
Subtópico 2
Crise de Software
●
Conferências NATO de 1968 e 1969
Uso “oficial” do termo engenharia de software
O propósito era a busca de uma solução para a
crise de software
●
“The computer industry has a great deal of trouble in
producing large and complex software systems” [4]
●
Problemas: estouro de orçamento, entrega atrasada,
sistemas não confiáveis e não satisfatórios, sistemas
nunca
entregues,
sistemas
nunca
usados,
dificuldade de manutenção...
Crise de Software
●
Segundo Dijkstra, em artigo publicado em 1972: “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 computer, programming has become an equally
gigantic problem” [5]
Crise de Software
●
Em 1994, Gibbs publica na Scientific American:
Para cada 6 grandes projetos de software que são operacionalizados, 2 são cancelados
Em média, os projetos de desenvolvimento de software estouram seus cronogramas em 50%
¾ dos sistemas de grande porte não fornecem a funcionalidade requerida [6]
Crise de Software
● Os relatórios do Standish Group também mostram dados
Crise de Software
●
E atualmente?
●
2005: O Inferno de Software!
“Software debacles are routine. And the more ambitious the project, the higher the odds of disappointment.”[7]
●
Apenas 34% dos projetos são entregues dentro
Caso real: Aeroporto de Denver
●
Centro de conexões nos EUA
Com área de aterrissagem para três jatos ao mesmo tempo
●
Software para sistema de controle de bagagem
29 km de esteira para transportar bagagens de 20 cias aéreas
Controle feito por 100 computadores ligados em rede, 5000 sensores, 400 receptores de rádio, 56 leitoras de código de barra
Tudo orquestrado para enviar as bagagens aos seus destinos de forma correta, segura e rápida, por meio de
●
Planejamento
Data de inauguração: Outubro/1993
Valor do contrato do sistema: US$ 234 milhões Custo do atraso? US$ 1 milhão/dia
●
Realização
Inauguração: Fevereiro/1995 (com um sistema provisório) Custo do sistema provisório: US$ 63 milhões
●
FBI
Início em 2001: Base de dados com suspeitos de terrorismo
Em Janeiro de 2005: Gastos de US$ 170 milhões: “not
even close to having a working system” ●
Ford Motors
Início em 2000: Projeto Everest, para substituição de sistema legado
Em Agosto de 2004: US$ 200 milhões acima do orçamento; cancelado (versão beta mais lenta do que o legado)
●
McDonald's
Início em 1999: Projeto Innovate, com orçamento previsto
●
Vôo 965 da American Airlines, de Miami para
Cali
Projeto do sistema feito para melhorar a interação homem-computador → causou um erro e a tripulação não percebeu
Este erro implicou em uma mudança de rota Atingiram uma montanha
159 pessoas de 163 morreram
Razões de Falhas em Projetos de
Software
●
Por quê projetos falham?
Prazos não realistas
Mudanças de requisitos
Esforço honestamente subestimado
Riscos não contingenciados (previsíveis ou não) Dificuldades técnicas
Falhas na comunicação da equipe Falta de gerência no projeto
Razões de Falhas em Projetos de
Software
●
Software é considerado, por muitos executivos, uma
das áreas com maiores problemas em organizações de
grande porte
●
Questões críticas para os executivos sêniores
Projetos de software não são estimados nem planejados com precisão aceitável
O relato de status geralmente é errado e pode induzir a erros
A qualidade e confiabilidade de software são geralmente inaceitavelmente baixas
Razões de Falhas em Projetos de
Software
●
Reclamações contra os executivos sêniores
Executivos geralmente rejeitam estimativas precisas e cautelosas
Executivos aplicam uma pressão nociva em relação aos cronogramas, que geralmente prejudica a qualidade
Executivos adicionam novos requisitos significativos durante o desenvolvimento
Dificuldades Inerentes a Software
●
Projetos de software são como lobisomens
●
Mas será que há uma “bala de prata” para
software?
“Not only are there no silver bullets now in view, the very nature of software makes it unlikely that there will be any” [3]
●
Há dificuldades
Inerentes → fazem parte da própria natureza do software Acidentais → presentes atualmente na produção de software, mas que não são parte da essência
Dificuldades Inerentes a Software
●Dificuldades inerentes:
Complexidade (complexity) Conformidade (conformity) Modificabilidade (changeability) Invisibilidade (invisibility)Definições de Engenharia de
Software
●
Sommerville:
“Engineering discipline that is concerned with all aspects of software production from the early stages of system specification to maintaining tthe system after it has gone into into use” [2]
●
Glossário Padrão de Engenharia de Software da
IEEE:
(1) “The application of a systematic, disciplined and quantifiable approach to the development, operation and maintenance of software; that is, the application of engineering to software”
●
Desenvolver software de forma efetiva
Objetivo da Engenharia de Software
Custo Tempo
Referências
[1] Charette, R. N. (2009) This Car Runs on Code. Disponível em http://www.spectrum.ieee.org/feb09/7649
[2] Sommerville, I. (2007) Software Engineering. Oitava Edição. Addison-Wesley
[3] Brooks Jr, F. P. (1995) The Mythical Man-Month: Essays on Software Engineering. Edição de Aniversário. Addison-Wesley
[4] Naur, P. e Randell, B. (1969) Software Engineering: Report of a Conference Sponsored by the NATO Science Committee. Germany. Scientific Affairs Division, NATO
[5] Djikstra, E. W. (1972) The Humble Programmer. Communications of the ACM. 15(10), págs 859-866
[6] Gibbs W. W. (1994) Software's Chronic Crisis. Scientific American
