Problemas no desenvolvimento de Software

Modelo de Maturidade de Software – Problemas no desenvolvimento de Software

Hardware ou software?

Vamos começar a nossa aula com uma pergunta simples: qual é o elemento mais importante no desenvolvimento de um software: o hardware ou o software?

Acredito que muitos tenham respondido o software; entretanto, essa não foi a resposta padrão durante muito tempo, contabilizando desde o início do desenvolvimento de sistemas. Por um longo período, o hardware era o componente principal, era o elemento essencial para o qual todas as atenções estavam voltadas.

Porém, esse cenário mudou e, agora, vamos entender bem como isso ocorreu e por que ocorreu, estudando o contexto do desenvolvimento de um software e os problemas que geraram a crise deste elemento.

O contexto do desenvolvimento de software

No início da computação, o elemento-chave era o hardware. Havia uma preocupação muito grande com o projeto e o uso deste componente. Naquela época, o hardware era muito caro e, por isso, o armazenamento nos dispositivos de memória secundária deveriam ser muito bem pensados e medidos. Foi nessa época que o termo “escovar bits” foi cunhado, devido ao alto valor de armazenamento dos dados. Entretanto, no início dos anos 80, foi divulgado um importante artigo na Business Week Magazine falando sobre a importância do software, cujo título era: “Software: the new driving force”.

A partir desse artigo, os pesquisadores começaram a perceber a importância do software para o desenvolvimento de sistemas. Outros artigos foram lançados como vertentes positivas à utilização do software, como: The Third Wave (Toffler, A., 1980); Information Society (Naisbitt, J., 1982).

Eletronic Community (Stoll, C., 1989).

Assim como as vertentes positivas, tivemos também as negativas ao uso do software: Resisting the Virtual Life (Brook, J.); The Future Does Not Compute (Talbot, S.).

Dessa forma, o software ultrapassou o hardware como a chave do sucesso para muitos sistemas baseados em computador. Hoje, o principal desafio é melhorar a qualidade e reduzir o custo de soluções baseadas em computador, pois a economia de todos os países do mundo depende cada vez mais de software, visto que este componente serve de base para: modernas investigações científicas; resolução de problemas de engenharia; controlar sistemas de transporte, medicina, telecomunicações, etc. As pessoas aplicam software em praticamente tudo no dia a dia, como: no trabalho, no conforto, na segurança, no entretenimento, na comunicação, entre outros.

Problemas persistentes

Ainda existem alguns problemas no uso e desenvolvimento de software, como:

• Avanços de hardware que continuam a se intensificar, mas não existe capacidade de construção de software que possa usufruir desses avanços.
• Pouca habilidade de construção de novos programas e de construção rápida que atenda a todos os requisitos dos usuários.
• A habilidade para construção de software é insuficiente para suprir a demanda por novas aplicações.
• Os engenheiros de software precisam trabalhar bastante para produzir software com alta confiabilidade e qualidade.
• Pouca habilidade de manutenção devido a projetos ruins e ausência de recursos.
• Sociedade dependente da construção de software totalmente confiável, o que pode causar verdadeiras catástrofes.

Um dos grandes problemas ainda é a manutenção de software. As empresas gastam um valor muito alto para prestar assistência em seus sistemas, o que impacta nos custos de acordo com a etapa em que a alteração no software ocorrerá, conforme a figura abaixo:

Percebemos que, depois que o software é entregue ao cliente final, qualquer tipo de alteração demanda um alto custo para sua manutenção. Precisamos analisar bem qualquer tipo de alteração no software para que as mudanças não tenham custos proibitivos. Quanto mais cedo uma alteração for realizada no desenvolvimento de um software, menor será o seu custo.

Também possuímos uma fábrica de desenvolvimento de software em fase de envelhecimento, pois há milhares de aplicações de software críticas que se encontram em dramática necessidade de renovação. Existem muitas aplicações críticas, tais como:

• Sistemas de informação escritos há 20 anos, em que a menor modificação pode fazer com que todo o sistema falhe;
• Aplicações de engenharia em projetos críticos que ninguém tem conhecimento detalhado sobre a estrutura interna de seus programas;
• Sistemas embutidos que exibem comportamento estranho, mas que não podem ser tirados de operação porque não há nada para substituí-los.

Um estudo realizado pelo governo dos Estados Unidos em relação ao software produzido constatou que:

• 2 % funcionavam muito bem;
• 3 % funcionariam com poucas correções;
• 45 % entregues, mas nunca foram usados com sucesso;
• 20 % usados, mas extremamente modificados ou abandonados;
• 30 % pagos, mas nunca foram terminados e/ou entregues.

Essa análise foi o primeiro indício que uma grave crise do software estaria por vir.

Crise do software

A crise do software refere-se aos seguintes problemas:

1. As estimativas de prazo e de custo são frequentemente imprecisas, visto que:
   1. Não se dedica tempo para coletar dados sobre o processo de desenvolvimento de software;
   2. Os projetos de desenvolvimento de software normalmente são efetuados apenas com um vago indício das exigências do cliente.
2. A quantidade e a produtividade de pessoas da área de software não têm acompanhado a demanda por seus serviços.
   1. Sem nenhuma indicação sólida de produtividade, não se pode avaliar com precisão a eficácia de novas ferramentas, métodos ou padrões e, até mesmo, formações de pessoas.
3. A qualidade de software, às vezes, é menor que a adequada.
   1. Apenas recentemente começaram a surgir conceitos quantitativos e qualitativos sólidos de garantia de qualidade do processo e do produto de software.
4. O software existente é muito difícil de manter.
   1. A tarefa de manutenção devora o orçamento destinado ao software;
   2. A facilidade de manutenção normalmente não é enfatizada como um critério importante nos projetos.

LEIA MAIS EM: http://euclezio.blogspot.com.br/2014/06/a-crise-do-software.html

Características do software

Nesta parte do curso, discutiremos as características e os mitos relacionados ao desenvolvimento do software, que possui algumas características que devem ser muito bem analisadas. São estas:

1. O software é desenvolvido ou projetado por engenharia, não manufaturado no sentido clássico, como o hardware.

• Em ambas atividades, a alta qualidade pode ser conseguida mediante um bom projeto e alta capacitação de pessoas; porém, com contextos diferenciados;
• Os custos de software são concentrados na engenharia;
• No início de 1985, o conceito de software factory foi introduzido na literatura; porém, isto não implica que a manufatura de hardware e o desenvolvimento de software sejam equivalentes;
• Fábricas de software recomendam o uso de ferramentas automatizadas e recursos humanos capacitados.

2. Software não se “desgasta” com o uso, mas se deteriora.

• Com o passar do tempo, o hardware se desgasta com os males ambientais, como poeira, vibração, temperatura, entre outros;
• O software não é sensível a esses males ambientais; porém, durante sua vida, o software sofre manutenção, onde, frequentemente, são introduzidos novos defeitos, o que acaba deteriorando o produto.

3. Curva de falha para o hardware

• O gráfico mostra que muitas peças podem ser criadas com defeito (mortalidade infantil); porém, a maioria sofre desgastes com o passar do tempo e serão substituídas.

4. Curva de falha para o software

• A curva de falhas do software não deveria sofrer nenhum erro, pois ela não se desgasta com os males ambientais. Porém, ela sofre manutenção, o que pode introduzir falhas em seu código.

5. A maioria dos produtos de software é feita sob encomenda ao invés de ser montada a partir de componentes existentes, que podem ser executáveis e não executáveis, como código e documentação, respectivamente.

• Hardware é projetado e desenvolvido com a reutilização de componentes;
• Infelizmente, muitos desenvolvedores de software, na maioria das vezes, não desenvolvem dessa forma;
• Devemos reparar um software da mesma forma que consertarmos um equipamento de hardware, trocando suas peças ou seus componentes.

Mitos do software

Muitas causas da atual aflição podem remeter-se à mitologia, que surgiu durante os primórdios do desenvolvimento de software. Esses mitos, que propagaram desinformação e confusão, são divididos em: administrativos ou de gerência e dos profissionais. Conheça-os:

1. Mito administrativo I

Já temos um livro repleto de padrões e procedimentos para a construção de softwares. Isso não oferecerá ao meu pessoal tudo o que eles precisam saber?

Realidade:

• Será que o manual é usado?
• Os profissionais sabem que ele existe?
• Ele reflete a prática moderna de desenvolvimento de software?
• Ele é completo?
• Está voltado para melhorar o prazo de entrega, mantendo o foco na qualidade?

2. Mito administrativo II

Meu pessoal tem ferramentas de desenvolvimento de software de última geração; afinal, compramos os mais novos computadores.

Realidade:

• É preciso muito mais do que os mais recentes computadores para se fazer um desenvolvimento de software de alta qualidade.

3. Mito do profissional I

A única coisa a ser entregue em um projeto bem-sucedido é o programa funcionando.

Realidade:

• O programa funcionando é só uma parte. Uma boa documentação incluindo requisitos, projeto das estruturas de dados, especificação de testes, análise de riscos, etc. é o alicerce para um projeto bem sucedido e serve como guia de manutenção.

4. Mito do profissional II

A engenharia de software nos fará criar documentação volumosa e desnecessária, que, certamente, nos atrasará.

Realidade:

• A Engenharia de Software não se relaciona à criação de documentos, refere-se à criação de qualidade.
• Melhor qualidade leva à redução de retrabalho e menor retrabalho resulta em tempos de entrega mais rápidos.

LEIA MAIS: https://www.profissionaisti.com.br/2011/08/os-principais-mitos-do-desenvolvimento-de-software/

Referências

Base: Pós em Engenharia de Software – Estácio (EAD), com várias adaptações e melhorias.

PFLEEGER, Shari Lawrence. Engenharia de Software: Teoria e Prática. 2ª Edição. São Paulo: Pearson (Livros Universitários), 2003.

PRESSMAN, Roger S. Engenharia de Software: uma abordagem profissional. 7ª Edição. São Paulo: MCGRAW-HILL BRASIL, 2011.

SOMMERVILLE, Ian. Engenharia de Software. 9ª Edição. São Paulo: PEARSON (LIVROS UNIVERSITÁRIOS), 2011.