CE-278 - Yano - Aula 4

Resumo do artigo Software Chronic Crisis, da Scientific American ( http://www.cis.gsu.edu/~mmoore/CIS3300/handouts/SciAmSept1994.html )

O artigo inicia-se através da citação de um grande sistema de software para o aeroporto de Denver, o qual necessitaria de um excelente planejamento para atender a grandes demandas. Tal sistema foi muito atrasado, chegando a cogitar-se que não poderia ser entregue. Em 1994, ano em que o artigo foi feito, 2 a cada 8 projetos de grande escala eram cancelados.
O que se previa era uma grande crise de software, pois até 1994 não tinha-se o conceito de Engenharia de Software muito desenvolvido e o desenvolvimento de software tinha problemas muito parecidos com os do início da revolução industrial.

Comenta-se sobre o fato de mesmo que o Departamento de Defesa fizesse testes sobre seus softwares, os mesmos ainda apresentavam erros durante o uso. Parecia que os métodos utilizados para a produção de sistemas de tempo real não eram suficientes para usos de segurança crítica.
Outro grande problema enfrentado era o de conectar peças independentes de software. Como os sistemas não eram projetados pensando-se nisso, quando havia a necessidade, muitas vezes os projetos falhavam.
São citados vários casos de insucesso de integrar sistemas. Um deles foi no Departamento de Veículos Motores, na California. O projeto, após custar 6.5 vezes mais que o esperado falhou. Outro deles foi o de integrar os sistemas de passagens aéreas com o de reservas de carros e hotéis. Este falhou após serem gastos US$165.000.000.
Alguns dados de uma consultoria da IBM mostravam o seguinte sobre os projetos de larga escala:
55% custavam mais que o esperado
68% demoraram mais que o esperado e
88% tiveram que ser substancialmente reprojetados

Outro exemplo de projeto que teve seu custo em muito aumentado foi o da Federal Aviation Administration (FAA). Esta agência teve seu projeto acrescido de um bilhão de dólares e alguns subprojetos cancelados. Isto reforça a necessidade da aplicação de técnicas de Engenharia de Software às necessidades atuais.

Um dos primeiros passos em direção à Engenharia de Software foi o desenvolvimento do CMM - Capability Maturity Model. Ele teve início no Software Engineering Institute e dava aos programadores alguma forma de medir a qualidade do seu desenvolvimento através de questionários e entrevistas.
A maioria das empresas na época (75%) tinha CMM 1, ou seja, não tinham nenhum processo de medição de qualidade, enquanto outros 24 % tinham CMM 2 ou 3.
O uso de CMM por algumas empresas demonstrou um retorno de investimento de US$7,80 para cada dólar investido no treinamento dos programadores para atingir níveis maiores de qualidade de software.

Uma das formas de se testar softwares para uso em massa é lançar a sua versão inicial como Beta e deixar que várias pessoas o testem, achando vários erros, para posteriormente lançar a versão final.
A maioria dos bugs encontrados em um projeto são erros de omissão.
Uma tentativa de se encontrar erros em estágios iniciais de desenvolvimento é modelar os programas através de métodos formais, os quais seriam a tradução do programa para uma forma matemática de resolvê-lo. Apesar das vantagens, métodos formais podem ter problemas durante a revisão, pois ler uma página de fórmulas é muito mais oneroso do que rever algumas linhas de código. No entanto, alguma empresas mostram resultados satisfatórios para práticas com técnicas do tipo "clean room", na qual uma probabilidade é associada a cada função de acordo com o número de vezes que virá a ser utilizada.


Há uma grande reclamação sobre o incentivo governamental sobre o apoio a iniciativas de desenvolvimento da Engenharia de Software.
Um dos pontos fracos da computação da época (e também atualmente) é a dificuldade de manter os códigos prontos para as mudanças tecnológicas. Embora tenha-se um código em pleno funcionamento em uma arquitetura, a sua implementação pode variar bastante, havendo dificuldade em componentizar os softwares. Houve uma tentativa de criação de linguagem para que isso não fosse problema. Há um grande indício de que UML foi derivada de tais preocupações.

Um grande desenvolvimento de Software ocorreu em torno da Índia, onde o governo apoiou o crescimento de iniciativas de Software. No entanto, em 97, havia apenas em torno de um bilhão de dólares no mercado de software indiano, enquanto o mercado mundial tinha 92 bilhões.
Os desenvolvedores indianos eram tão vantajosos que acabava sendo mais econômico enviar um grupo de americanos para a Índia do que desenvolver nos próprios EUA. Outra vantagem era o preço de unidade de componente, que custava em torno de US$925 feito por um americano e US$125 por um indiano.

Um dos principais problemas na indústria de venda de componentes é o fato de que as pessoas querem comprar os componentes uma única vez e fazer várias cópias dos mesmos.

Uma espécie de continuação deste artigo pode ser encontrada em (http://www.sciam.com/article.cfm?chanID=sa006&articleID=00020D04-CFD8-146C-8D8D83414B7F0000)