IES-01-A Crise do SW

Prévia do material em texto

2013-2sem Material IES - Prof. Dr. José OSCAR F. de Carvalho 1
A Crise do Software
Introdução à Engenharia de Software 
(IES)
AULA 01
2013-2sem Material IES - Prof. Dr. José OSCAR F. de Carvalho 2
Principais problemas da 
área de Informática
Questionário aplicado à alta direção de 200 empresas de porte 
médio/grande, sobre as principais falhas/dificuldades com a 
Informática:
� Cumprimento dos prazos 26,3%
� Custos elevados 25,4%
� Prioridade desenvolvimento x manutenção 25,4%
� Manutenção dos sistemas em uso 21,1%
� Recrutar profissionais qualificados(*) 18,4%
(*) Boa formação e atualizados
Gartner Group – fev/2000 (admitidas múltiplas Respostas)
2013-2sem Material IES - Prof. Dr. José OSCAR F. de Carvalho 3
Frustração dos Usuários sobre a
grande “promessa” da Informática
� Esperança que pelo menos parte da promessa se cumpra;
� Frustração pela pequena parte da promessa já cumprida, 
em razão de:
� Erros, falhas e inadequação dos produtos de software
� Insegurança na utilização
� Prazos excessivamente longos
� Custos altos e constantes
� Constante necessidade de manutenções
Principais problemas da 
área de Informática
2013-2sem Material IES - Prof. Dr. José OSCAR F. de Carvalho 4
Principais problemas da 
área de Informática
Sensação dos Desenvolvedores
� Baixa produtividade no desenvolvimento;
� Baixa qualidade do produto gerado (erros e adequação 
às necessidades do usuário);
� Impossibilidade de cumprir prazos e custos;
� Dificuldade em treinar os profissionais nas novas 
tecnologias;
� Mudanças constantes em TI/SI (insegurança e 
necessidade constante de atualização)
2013-2sem Material IES - Prof. Dr. José OSCAR F. de Carvalho 5
Principais problemas da 
área de Informática
Sensação dos Desenvolvedores
Constatação:
� Backlog médio é de mais de 3 anos
� Backlog invisível geralmente é 2 a 3 vezes maior
2013-2sem Material IES - Prof. Dr. José OSCAR F. de Carvalho 6
Principais problemas da 
área de Informática
Alves (2004) define backlog como uma fila de espera
existente na área de sistemas de uma empresa, 
decorrente do fato de que a demanda por novos 
sistemas cresce mais depressa que a capacidade da 
empresa de produzi-los.
De acordo com Yourdon (1990), o backlog se divide 
em três tipos:
� visível
� invisível
� desconhecido.
2013-2sem Material IES - Prof. Dr. José OSCAR F. de Carvalho 7
O backlog visível corresponde a novos sistemas solicitados por 
usuários e que não foram iniciados por falta de recursos das 
empresas de desenvolvimento, como por exemplo, analistas de 
sistemas, programadores, equipamentos, etc. Eles estão na fila, 
esperando que algum outro projeto seja concluído ou que novos 
recursos sejam adquiridos para que possa ser iniciado o seu 
desenvolvimento propriamente dito.
O backlog invisível diz respeito à necessidade de novos sistemas, 
mas que não são solicitados, pois aguardam a conclusão de algum 
projeto anterior, ou seja, o usuário sabe que precisa do novo 
sistema, mas ele não irá solicitá-lo oficialmente enquanto o outro 
não estiver pronto.
O backlog desconhecido corresponde aos novos sistemas que 
surgirão, tão logo terminem os projetos de backlog visível e 
invisível e que os usuários nem sabem que precisam.
Principais problemas da 
área de Informática
2013-2sem Material IES - Prof. Dr. José OSCAR F. de Carvalho 8
Principais Tipos de Erros
1) Sistemas desenvolvidos corretamente a partir de 
especificações erradas ou incompletas;
2) Corte deliberado do escopo do projeto, em razão do 
estouro do prazo ou da verba do projeto; e
3) Sistemas desenvolvidos incorretamente a partir de 
especificações corretas.
Nakajo e Kume (1991)
2013-2sem Material IES - Prof. Dr. José OSCAR F. de Carvalho 9
Principais Causas de Erros
� Estudo promovido por Computerworld-USA em 
março/96. Pesquisados 160 profissionais dentre as 
maiores empresas privadas que detinham 
estruturas próprias para o desenvolvimento de 
software, admitidas múltiplas respostas.
Veja a seguir os resultados deste estudo...
2013-2sem Material IES - Prof. Dr. José OSCAR F. de Carvalho 10
Principais Causas de Erros
� 80% dos projetos superam orçamentos e prazos porque 
as mudanças ocorreram depois que os requisitos foram 
definidos. A freqüência do impacto dos requisitos no 
orçamento e prazo ocorre:
� Sempre 31%
� Freqüentemente 49%
� Raramente 20%
Raramente
Sempre
Freqüentemente
80%
2013-2sem Material IES - Prof. Dr. José OSCAR F. de Carvalho 11
Principais Causas de Erros
Falhas em requisitos representam geralmente um aumento 
de 11% a 50% nos custos e/ou atraso no projeto. O 
impacto causado nos custos e prazos no projeto é:
� Grande�+50% de aumento em custos/prazos
� Moderado ���� 11 a 50% de aumento em custos/prazos
� Pequeno ���� 0 a 10% de aumento em custos/prazos
Pequeno – 23%
Grande – 9%
Moderado – 68%
Em 68% dos projetos, falhas
em requisitos causam um 
impacto de 11% a 50% em
custos/prazos. 
2013-2sem Material IES - Prof. Dr. José OSCAR F. de Carvalho 12
Principais Causas de Erros
Desenvolvedores consultados 
definiram a causa dos 
freqüentes erros na 
especificação de requisitos:
A- 44% Definição inicial falha
B- 36% Novas aplicações desconhecidas dos usuário
C-23% Projeto tão longo que os requisitos mudaram durante o 
desenvolvimento
D- 22% Gerenc. falho ou dificuldades em administrar a expectativa dos 
usuários
E- 19% Dificuldade em envolver os usuários nos estágios iniciais do projeto
F- 19% Dificuldade em empregar técnicas de prototipação ou 
desenv.conjunto
A - 44%B - 36%
C - 23%
D - 22% E - 19% 
F - 19%
2013-2sem Material IES - Prof. Dr. José OSCAR F. de Carvalho 13
Principais Causas de Erros
Desenvolvedores informaram 
sobre as técnicas que 
pretendem usar para superar 
os problemas com definição 
de requisitos:
A- 63% Projetar aplicações conjuntamente usuários e desenvolvedores
B- 25% Usar prototipação para obter definição de requisitos
C- 23% Buscar a completeza da definição de requisitos
D- 23% Usar ferramentas de controle e gerência de projetos
E- 16% Dizer “NÃO” às solicitações de alteração dos requisitos, depois de 
iniciado o projeto
A - 63%
B - 25%
C - 23%
D - 23%
E - 16%
2013-2sem Material IES - Prof. Dr. José OSCAR F. de Carvalho 14
Mitos do Software
Surgiram nos primórdios do desenvolvimento de 
software. Ao contrário da mitologia, que oferece lições 
que valem a pena serem consideradas, os mitos do 
desenvolvimento de software só propagam 
desinformação e confusão.
São declarações aparentemente razoáveis (às vezes 
contendo elementos de verdade), mas que são falsas e 
eram propagadas sem que fossem comprovadas de 
maneira rigorosa.
2013-2sem Material IES - Prof. Dr. José OSCAR F. de Carvalho 15
Mitos do Software
Mitos Administrativos
Adotados pela gerência de desenvolvimento de 
software, como forma de atenuar as pressões.
� Já temos todos os manuais e procedimentos para 
construção de software; isso é suficiente.
� Meu pessoal tem ferramentas de desenvolvimento de 
software de última geração e computadores novos.
� Se sofrermos atraso no prazo, basta adicionar mais 
programadores ao projeto (horda de mongóis).
2013-2sem Material IES - Prof. Dr. José OSCAR F. de Carvalho 16
Mitos do Software
Mitos do Cliente
Clientes acreditam em mitos sobre software, porque a 
área de Informática nada faz para esclarecê-los; como 
resultado temos falsa expectativa e insatisfação. 
� Uma declaração geral dos objetivos é suficiente para se 
começar a escrever programas; os detalhes serão 
informados/descobertos ao longo do processo.
� Requisitos de projeto mudam continuamente, mas isso 
não é problema porque o software é flexível.
2013-2sem Material IES -Prof. Dr. José OSCAR F. de Carvalho 17
Mitos do Software
Mitos do Profissional
Velhas atitudes dificilmente morrem (quatro décadas de 
cultura de programação), onde a programação era vista 
como uma forma de arte.
� Assim que escrevermos o programa e o colocarmos em 
funcionamento, nosso trabalho estará completo.
� Enquanto o programa não estiver pronto, não temos 
nenhuma maneira de avaliar sua qualidade.
� O único produto a ser entregue em um projeto bem 
sucedido é o programa funcionando.
2013-2sem Material IES - Prof. Dr. José OSCAR F. de Carvalho 18
Conclusão !!!
ÉÉ preciso adotar mpreciso adotar méétodos, todos, 
ttéécnicas e ferramentas cnicas e ferramentas 
que permitam a aplicaque permitam a aplicaçção ão 
de princde princíípios pios ““cientcientííficosficos””
ou, no mou, no míínimo, adequados nimo, adequados 
àà produproduçção ão eficienteeficiente de de 
software.software.
Não vamos atender a demanda de software com qualidade, Não vamos atender a demanda de software com qualidade, 
a prea preçço compato compatíível e num contexto de globalizavel e num contexto de globalizaçção e da ão e da 
busca de resultados, desenvolvendobusca de resultados, desenvolvendo--os de maneira os de maneira 
artesanal e empartesanal e empííricarica..