UNIVERSIDADE PEDAGÓGICA

ESCOLA SUPERIOR TÉCNICA

DEPARTAMENTO DE ENGENHARIAS

LICENCIATURA EM ENGENHARIA ELECTRÓNICA

CADEIRA DE ENGENHARIA DE SOFTWARE

Discente: João Kelvin Horácio Zunguza

Docente: MSc. Sheila Sitoe

Tema: Não há bala de prata - Essência e Acidente na Engenharia de Software.

Resumo

Em 1986, foi publicado um grande artigo da Engenharia de Software, o artigo “No Silver Bullet
– Essence and Accident in Software Engineering” (Não há bala de prata – Essência e Acidente
na Engenharia de Software) por Frederick P. Brooks, onde a reflexão principal reside, ou por
outra, é reflectida na frase acima. “Não há desenvolvimento único, seja na tecnologia ou na
técnica de gerenciamento, o que por si só promete uma melhoria de ordem de magnitude dentro
de uma década em produtividade, em confiabilidade, em simplicidade”. Ou seja, não há
nenhuma bala de prata que sozinha resolva os problemas do Software.

Toda a construção de software envolve tarefas essenciais, a modelagem de estruturas conceituais

complexas que compõem a entidade abstracta de software e tarefas acidentais, a representação
dessas entidades abstractas em linguagens de programação e o mapeamento destas em
linguagens de máquina dentro de restrições de espaço e velocidade.

Introdução

De todos os monstros que preenchem os pesadelos do nosso folclore, nenhum aterroriza mais do
que os Lobisomens, porque eles se transformam inesperadamente do familiar em horrores. Para
estes, procuramos balas de prata do que magicamente podem colocá-las para descansar. O
projecto de software familiar tem algo desse carácter (pelo menos como visto pelo gerente não
técnico), geralmente inocente e directo, mas capaz de se tornar um monstro de horários perdidos,
orçamentos inflados e produtos defeituosos. Então, ouvimos gritos desesperados por uma bala de
prata, algo para fazer os custos de software caírem tão rapidamente quanto os custos de hardware
de computador. Mas, ao olharmos para o horizonte de uma década, não vemos bala de prata. Não
existe um desenvolvimento único, seja na tecnologia ou na técnica de gerenciamento, o que, por
si só, promete uma melhoria na produtividade, na confiabilidade, na simplicidade. Neste
capítulo, tentaremos entender por quê, mas examinando a natureza do problema de software e as
propriedades das balas propostas.

O autor faz uma brilhante e também estranha comparação ou analogia entre o Software e o
Lobisomem, alegando que estes seres se transformam, inesperadamente, de coisas familiares à
seres horripilantes. A diferença é que o Lobisomem, basta uma bala de prata para se resolver o
problema. Com relação ao Software, os horrores seriam os prazos perdidos, orçamentos
estourados e produtos com falhas, só que diferentemente do Lobisomem, não há uma única bala
de prata que resolva esses problemas.

O autor em sua argumentação, divide os problemas envoltos ao desenvolvimento de Software em

dois: acidentais e essenciais. Os problemas acidentais dizem respeito aos problemas relacionados
com a fabricação do Software e estão quase sempre associados à limitações tecnológicas. Já, os
problemas essenciais são aqueles inerentes a sua própria natureza, sendo assim a real causa da
sua complexidade.

Dificuldades Essenciais

Como já dito, os problemas essenciais dizem respeito a características que são inerentes somente
ao Software. Eles referem-se aos desafios da criacao de um modelo conceitual para os sistemas.

Neste sentido, Brooks elenca quatro desafios referentes ao Software que dificilmente são
encontrados em outras ciências.

Complexidade

Se refere ao facto de que no desenvolvimento de Software não existem dois elementos repetidos
ou idênticos, quando existem eles são transformados em uma coisa só na forma de funções. Essa
característica é um grande desafio na hora de escalar o Software para desafios maiores, uma vez
que não basta o uso dos mesmos componentes em tamanho maior, como muitas vezes acontece
com o Hardware, construções, automóveis e outras máquinas, onde os elementos repetidos
superabundam. Dessa forma, não crescimento linear para o Software.

Conformidade

Não é só o Software que sofre com os problemas de complexidade, a física por exemplo também
sofre, no entanto, diferentemente desta última o Software não possui leis imutáveis as quais se
possa agarrar. O Software precisa se adaptar a todo tipo de interface, sistema ou instituição
existente, e se não bastasse, estes supostos padrões mudam de tempos em tempos de acordo com
a moda do momento. Como diz o autor, as vezes não é nem por necessidade, mas simplesmente
porque os padrões são desenvolvidos por pessoas e não por Deus, como no caso da física e as
leis da natureza.

Mutabilidade/Alterabilidade

O Software é constantemente sujeito a pressões por mudança. Isso se deve a sua característica
abstracta que lhe confere a impressão de que mudanças são fáceis de se fazer, muito diferente
daquilo que ocorre com os produtos manufacturados do mundo físico. Para tal, basta se comparar
a quantidade de recalls que acontecem no sector automobilístico com a quantidade de
actualizações na indústria de Software. Esta característica é em parte benéfica por permitir uma
‘rápida’ evolução dos sistemas, entretanto, paga-se o preço para tal.

Invisibilidade

Essa é talvez a característica mais intuitiva. O Software é de fato invisível, não é possível
representá-lo à partir de formas geométricas ou outras formas compreendidas pelo senso comum.
Esta característica representa um grande desafio para o projecto de sistemas e a sua
representação para terceiros.

Considerando-se essas características de forte cunho abstracto, não é difícil de se concluir que
dificilmente existirá uma única solução que alavanque a produtividade, a confiabilidade e a
simplicidade do Software, assim como por exemplo foram os transístores para a electrónica.
Dificuldades/Problemas Acidentais

Muitos dos problemas acidentais têm sido resolvidos ao longo dos anos. As restrições de
memória e processamento de hoje nem se comparam àquelas de 30 anos atrás, sem contar que
hoje desenvolvemos num ambiente multitarefa. Outra coisa que têm contribuído bastante para a
eliminação dos problemas acidentais são as linguagens de alto nível, que têm evoluído bastante e
cada vez mais contribuem para a produtividade do desenvolvimento, confiabilidade e
simplicidade do Software. Estas linguagens não possuem a mesma performance de linguagens de
mais baixo nível, como por exemplo C; entretanto, conforme os processadores evoluem, vale a
pena se trocar alguns ciclos por essas melhorias. Mas, mesmo com tantas melhorias, o
desenvolvimento de Software continua tão complexo pelo facto de os principais desafios não
serem os acidentais, mas sim os essenciais.

Segurança

A segurança é também um atributo do Software, assim como usabilidade, performance,

simplicidade, entre outros. Portanto, os desafios acima citados impactam a segurança de igual
forma, uma vez que é igualmente difícil de se implementar segurança à algo que precisa se
adaptar a tudo, que vive sendo alterado e é de difícil representação.

Em vista de tudo isso, o primeiro ponto é que os problemas de segurança no Software decorrem
primeiramente de sua própria complexidade inerente. A evolução da segurança no Software
continuará a ser gradual e fruto de um conjunto de actividades e processos.

Linguagens de alto nível

Linguagens de programação de alto nível tornaram mais fácil para as pessoas aprenderem
programação e escreverem o famoso “Hello World!” sem muita dificuldade. As linguagens de
alto nível estão mais preocupadas com o que um usuário vê no “front-end” de um software e
como cada função realiza uma determinada tarefa, em vez de se concentrar em qual registador
armazena um processo específico em execução em um software como as linguagens de nível
inferior. As linguagens de alto nível estão próximas do inglês simples, esse factor contribuiu para
o rápido crescimento de programadores em todo o mundo, resolvendo, portanto, alguns dos
problemas no campo da engenharia de software.
Compartilhamento de tempo

À medida que mais pessoas aprendem a programar, elas começam a compartilhar percepções e
começam a usar uma variedade de meios de comunicação para colocar seu trabalho lá fora, para
que qualquer pessoa tenha acesso e obtenha soluções para os problemas que estiveram
infrentando no passado.

Esperanças para a linguagem

Ada prateada (Brooks, 1995) argumentam que a linguagem de programação Ada e as linguagens
de alto nível são promissoras para lidar com algumas das questões experimentadas na engenharia
de software, Ada foi especificamente projectada para funções do sistema onde a eficiência e
confiabilidade gerais do sistema são vitais.

Programação orientada a objectos (OOP)

A programação orientada a objectos é um dos avanços na programação que tornou mais fácil
para os programadores definir variáveis ou objectos nesse assunto. Cada objecto seria definido
com base em quais estruturas de dados seriam armazenadas para servir a um propósito no
programa ou software. Exemplos de linguagens de programação orientadas a objecto
amplamente utilizadas seriam C ++ e Java. Inteligência Artificial (IA) (Brooks, 1995) argumenta
que Inteligência Artificial não é o que as pessoas esperam que seja, são apenas processos de
hardware e software que escolhem a melhor solução em um determinado problema que pode ser
escolhida pelos humanos.

Sistemas Especializados

Todo sistema de software deve ser projectado e construído de tal maneira que seria capaz de
testar e diagnosticar a si mesmo quando tiver problemas, no entanto, isso não seria uma tarefa
fácil de implementar. Construir um sistema especialista exigiria programadores muito
experientes que poderiam construir um sistema geral para resolver múltiplas tarefas complexas.
Programação automática É essencial ter sistemas de software capazes de se programar, e
escrever soluções de problemas de programas automaticamente a partir de uma declaração de
problema.
Programação gráfica

De acordo com (Brooks, 1995), a apresentação de funções de software de maneira gráfica não
contribui para a simplicidade de ter uma visão geral de um sistema, pois diagramas como
fluxogramas tendem a ser maiores que um tamanho de tela normal de um computador. Além
disso, as funções de software são geralmente mais complexas do que parecem em um
fluxograma. Verificação do programa A verificação do programa é onde a maioria dos
programadores passa o tempo e é uma das etapas mais importantes em um ciclo de vida do
software. A verificação de um programa antes da fase de teste pode eliminar muitas anomalias,
podendo até reduzir o tempo gasto no teste do software real, porque cada requisito seria
verificado antes de ser implementado. Ambientes e ferramentas Dada a quantidade de
ferramentas disponíveis hoje em dia para escrever software, não há desculpa para o motivo pelo
qual os engenheiros de software continuam produzindo software não confiável e não-sustentável.
Cada programador pode programar em qualquer ambiente que se sinta confortável, não há
limitações.

Ataques promissores à essência conceitual

À medida que o grande número de engenheiros de software aumenta diariamente, há mais

concorrência, mais softwares disponíveis para qualquer pessoa utilizar livremente, esse benefício
significa que qualquer software que você esteja tentando construir já pode estar em algum lugar.
As pessoas estão sempre tentando fazer as coisas o mais rápido possível, mesmo que os
engenheiros de software escrevam seu próprio software, mais frequentemente faz sentido
comprar o que está disponível lá fora, em vez de construir algo que já tenha sido construído.
Parte de cada modelo de desenvolvimento de software está definindo os requisitos, essa parte de
um ciclo de vida de software delineia todas as funções ou tarefas necessárias que o software deve
concluir. É nesse ponto que a complexidade de um projecto de software é ponderada. Entre os
engenheiros de software, é um fato conhecido que “os clientes nunca sabem o que querem”.