Resenha Crítica do artigo:

No Silver Bullet: Essence and Accident

Software Engineering
Karina Yukie N. Kataoka
31 de Março de 2008
Sumário do Texto:

Este artigo começa fazendo uma comparação entre o temido lobisomem com o
software, onde de um familiar homem, inesperadamente se transforma em um
monstro horripilante e que só uma bala de prata pode acabar com ele. E
analogamente, o software de inocente e simples pode se “transformar” em um
produto imperfeito e de orçamentos estourados, e quando isso acontece
também se procura uma bala de prata pra acabar com esses problemas. Mas
segundo o autor, não há um avanço tecnológico que melhore a ordem de
magnitude da produtividade, confiabilidade e a simplicidade e com isso não há
nenhuma bala de prata a vista. O artigo vai ter como objetivo defender que
avanços conquistados até hoje e como eles foram promovidos em cima das
questões acidentais do software, e que ganhos no desenvolvimento das
atividades essenciais são muito mais difíceis de serem alcançados.

Brooks afirma que não é o software que avança devagar, mas o progresso do
hardware é que rápido e que não existem paralelos tecnológicos no mundo
com a velocidade da inovação em hardware. Ele acredita que a parte dura da
construção do software é a especificação, design, e os testes dessa construção
conceitual e não o trabalho de representar e testar a fidelidade da
representação.

Ele analisou algumas propriedades inerentes à essência dos problemas de

desenvolvimento de software, que são: a complexidade, conformidade,
adaptabilidade e invisibilidade.

A complexidade exigida para a produção de um software é muito maior que a

de um computador. Uma entidade de software não é apenas uma repetição dos
mesmos elementos, é um aumento no número de elementos diferentes. Na
maioria dos casos, os elementos interagem uns com os outros não-
linearmente, e a complexidade do conjunto aumenta muito mais do que
linearmente. Muitos dos problemas clássicos de desenvolvimento de produtos
de software resultam dessa complexidade. Dela surge a dificuldade de
comunicação entre os membros da equipe, o que leva a falhas nos produtos,
aos custos excedentes e atrasos no calendário. Gera também a dificuldade de
enumerar todos os possíveis estados do programa. A complexidade das
funções gera dificuldades de invocá-las. E a complexidade da estrutura gera
dificuldades na invocação das funções sem que ocorram outros erros
ocasionais.

Já a conformidade é um princípio unificado. Como o software e o seu

desenvolvimento são muito recentes, precisam ser adaptados a todos os tipos
de instituições e sistemas já existentes. E como há uma constante mudança de
softwares e de hardwares a conformidade não pode ser bem vista porque
senão deixará o sistema obsoleto e fora de mercado.

Como não pode haver conformidade a adaptabilidade ou alterabilidade deve

existir, porque como os sistemas avançam muito rapidamente, os softwares
precisam acompanhar e com isso precisa haver mudanças e alterações
constantes. Mas claro que essas mudanças não se equiparam com carros que
a cada ano sai um novo, ou a edifícios que sempre tem um novo em
construção. A evolução é mais lenta mais tem que existir. Mas ele não precisa
ser modificado como um todo, e como é composto por funções, só algumas
delas podem ser alteradas e atualizadas de acordo com o que o mercado
necessita. Na maioria das vezes essas mudanças são feitas a pedidos dos
usuários, que querem novas atualizações que acompanhem os avanços das
novas arquiteturas dos computadores.

Segundo a invisibilidade o software não é espacialmente representável, não

existe um diagrama ou esquema lógico que o descreva, mas sim vários
gráficos ou diagramas sobrepostos uns aos outros. Esses vários gráficos
podem representar o fluxo de controle, o fluxo de dados, padrões de
dependência, a seqüência de tempo e os relacionamentos nome-espaço.
Sendo assim necessárias muitas representações para conseguir um
entendimento visual do sistema.

Analisando as três etapas em tecnologia do software que renderam mais no

passado pode-se concluir que o maior avanço promoveram melhoras de
produtividade na criação do software. Essas etapas são: Linguagem de auto
nível, Time-sharing e Ambientes unificados.

A utilização da linguagem de alto-nível para a linguagem de programação

ajudou muito na produtividade do software, confiabilidade e simplicidade. Mas,
embora ela seja realmente muito importante na melhora de produtividade, este
avanço só vai ter impacto sobre a complexidade acidental, e não no problema
em si.

O time-sharing gera uma significativa melhora na produtividade dos

programadores e na qualidade dos seus produtos, embora não tão grande
como a trazida pelas linguagens de alto-nível, mas o custo da interrupção
gerada pode levar a uma perda da noção geral da complexidade do sistema
em desenvolvimento. Por isso que uma boa organização e divisão de tarefas
ajudam a preservar a linha de raciocínio da principal tarefa a ser desenvolvida.

Ambientes de programação unificada, atacam as dificuldades acidentais de

usar o programa em conjunto através do fornecimento de Bibliotecas
integradas e formatos de arquivos unificados, que fazem, na prática, ser
possível integrar estruturas conceituais cujo projeto já prévia esta integração,
de forma que não resolveram nenhum problema essencial ao trabalho de
construir um sistema de software.

Brooks propôs soluções mágicas para tentar resolver, ou diminuir esses

problemas, entre elas, a Ada e outras linguagens de alto-nível que ajuda o
desenvolvedor de softwares a elaborar e produzir novas técnicas de projetar o
sistema. Tem também a orientação a objetos que não resolvem questões
relacionadas à projetos de softwares ou análise, mas resolvem questões
acidentais provendo tipos abstratos de dados e uma hierarquia de tipos. A
inteligência artificial que ajuda o desenvolvimento otimizando o software, mas
não seria uma bala de prata porque não resolve problemas genéricos e ainda
requer trabalho e criatividade para permitir aplicar uma solução a novas
questões.

A programação automática, que até hoje não se viu algo que passe uma
especificação diretamente para código, mas se existem, tem aplicações muito
específica. Tem também a Verificação de Programas, Ambientes e
Ferramentas e Workstations.
Resenha
No Silver Bullet – Essence and accidents in Software
Engineering
Carlos Roberto
Sumário do Texto:

O texto No Silver Bullet escrito por Frederick P. Brooks, Jr., na década de 80, é
tido como um dos clássicos dentre a engenharia de software. Nele é feita uma
análise do que vem a ser a engenharia de software, destrinchando
minuciosamente o processo de criação de um software, desde sua concepção,
até a implementação, passando por testes e debugging. Todo esse longo
caminho percorrido pelo autor, é para evidenciar e dar suporte à tese por ele
sustentada: não há uma maneira, tanto no quesito manutenção quanto em
relação a tecnologia, que possa fazer com que o processo de produção do
software seja extremamente otimizado, ao ponto do software ser o mais
simples, barato e confiável, possível. Daí a alusão à silver bullet , uma vez que
ele afirma que não há um modo de resolver esses problemas todos, de uma
maneira miraculosa, tal qual uma bala de prata está para o lobisomem.

Dividindo-se os problemas englobados no desenvolvimento do software em

duas categorias, essenciais e acidentais, os que estão intimamente
relacionados com o software, e os que decorrem da produção do software em
si, respectivamente. Complexidade, conformidade, maleabilidade, e
invisibilidade, são postas em xeque. Quanto maior um software maior a é sua
complexidade, uma vez que é constituído de vários elementos que se
interrelacionam. Nos é exposto pelo autor que com o crescimento da
complexidade, outros problemas surgem, como problemas de entendimento, de
reuso, e até mesmo de comunicação, dentro da própria equipe de
desenvolvimento. Como todos os softwares existentes não são criados por uma
mesma pessoa, há também a preocupação de como o software produzido irá
interagir com os outros já existentes. Justamente por ser diferente das outras
construções humanas, o software não pode ser representado de maneira
gráfica como uma plante de um prédio. Trata-se de um entidade abstrata, e
quanto mais complexo os relacionamentos entre suas componentes, mais difícil
de conseguir uma representação para o mesmo. Além disso por englobar suas
funcionalidades e poder ser mais simplesmente modificado, está sempre
suscetível a mudanças impostas pelo meio externo: leis, pessoas, tecnologia.

Linguagens de alto nível, como a Ada, citada no artigo, vêm aumentar a

capacidade de abstração do programador, uma vez que ele não mais tende a
se prender aos detalhes, em baixo nível, que somente dizem respeito ao
computador, fazendo a compreensibilidade maior não só pelo programador,
como outras pessoas. O Time-Sharing também é levado em consideração,
uma vez que ele possibilitou o aumento da velocidade, e consequentemente a
diminuição do tempo de resposta, do programa. Um tempo de resposta tão
rápido ao usuário , que chega a ser desprezível, já que é uma fração de tempo
que não pode ser sentido por humanos. Por fim os ambientes de programação
unificados, que com a padronização de formatos de arquivos e bibliotecas,
tornaram mais simples a integração de futuras ferramentas, na produção.
O autor afirma, como o dito sobre a linguagem Ada, que as linguagens de alto
nível não virão a ser silver bullets, porque a sua função é abstrair o
programador de problemas inerentes à máquina, e que a resposta aos
problemas remanescentes, com certeza será ínfima. A utilização de orientação
à objeto, também é tida como uma redutora de problemas acidentais,
referentes ao design uma vez que que classes podem ser designadas para
cumprir um propósito mais específico, facilitando o design. Porém, uma vez
mais, o ganho se dá sobre problemas acidentais. Ao abordar inteligência
artificial, primeiro nos é colocado a questão do que seria inteligência artificial, e
depois, que o ganho em cima de técnicas como reconhecimento de voz e/ou
imagem, trariam ganhos marginais. Os sistemas experts englobam a parte de
testes de software , uma vez que eles podem realizar testes com base num
conjunto de dados, modelado conhecimento prévio, e como Brooks mesmo diz,
para fazer um sistema expert, é necessário um expert. E que a contribuição
desse tipo de sistema seria passar o conhecimento acumulado por
programadores mais experientes à frente. Programação automática, diz
respeito a geração de código, dada a especificação do problema a ser
solucionado, através de bibliotecas e tais, pelo sistema. Nesse ponto é feita
uma crítica sobre a generalização desse método em relação a todos os
problemas de computação, já que são poucos os problemas que possuem tal
característica. A programação gráfica no sentido de ajudar no desenvolvimento
de software, no campo da visualização, também é abatida com críticas, em
parte pelo maquinário da época, e também pelo fato do software não ser algo
tão factível a visualização como um prédio [novamente a questão da
invisibilidade]. Verificação de programa também não traz grandes avanços em
termos de confiabilidade e produtividade, uma vez que o trabalho empregado é
grande e no máximo nos assegurará uma reprodução fiel da especificação, e
não um programa à prova de falhas. Ambiente e ferramentas também não
trazem grandes ganhos, uma vez que e eles trazem apenas a unificação do
elaborado pelas pessoas de uma equipe, e um histórico das ações tomadas em
cima do projeto. Por fim, as estações de trabalho, como todos os outros, não
trazem um ganho incrível, já que mesmo com um grande aumento da
velocidade, ainda fica o tempo gasto pelo programador para pensar.

Finalmente, os ataques tidos como promissores, pelo autor, como comprar o

software em vez de construir um, do zero. Umas vez que para um produto já
existente a entrega é imediata, e a documentação sobre, é muito mais vasta.
Bastando-se apenas expandí-lo [ou não] de acordo com a necessidade de
cada um. Partindo da premissa “o cliente não sabe o que quer”, que
prototipagem rápida é a chave para que o cliente teste o software e decida se
realmente atende as suas expectativas. Nesse ponto a interação cliente-
programador é essencial. Para um desenvolvimento, e não construção de
software, vem o desenvolvimento incremental, onde começa-se com o software
funcionando, mesmo sem fazer nada além de chamar procedimentos, e aos
poucos ir acrescentando-se as suas funcionalidades. Onde é lançado um olhar,
tal qual sobre os seres vivos, no que toca ao desenvolvimento contínuo. E
finalmente a grande aposta de Brooks, que reside nas pessoas. Criar ótimos
designers, uma vez que ótimos designs vêm de grandes designers, uma vez
que o processo de construção de software é um processo criativo. Para fechar
o artigo, ele nos diz que para tanto, é necessário dar o devido reconhecimento,
uma vez tendo os identificado, mantê-los sob tutela para acompanhar o seu
crescimento, e promover interação entre eles, para que possam crescer em
conjunto.
Terça-feira, Dezembro 09, 2008
Não há "bala de prata"
postado por Helio Bentzen às 14:44 Label: Computação,
Engenharia de Software
Autor/fonte: Tradução: Christian Reis; Adaptação: Helio
Bentzen http://olio.blogspot.com/
Este texto foi baseado no artigo Brooks, 1986, “No Silver Bullet: essence and
accidents of software engineering” que afirma não haver um avanço
tecnológico que gere uma melhora na produtividade, simplicidade e
confiabilidade da construção de software. Apontam-se, ainda, alguns caminhos
promissores em desenvolvimento.

Introdução

Há, ainda, hoje, grande discussão em torno de como melhorar a produtividade

na construção de sistemas complexos. Há duas partes bastante distintas que
constituem as atividades relacionadas ao desenvolvimento do software:
atividades essenciais, que envolvem a criação de um modelo conceitual para o
sistema, e atividades acidentais, que envolvem a própria implementação do
sistema em um programa. O objeto deste artigo é defender que avanços
significativos conquistados até hoje foram promovidos em cima das questões
acidentais do software, e que ganhos da mesma proporção no
desenvolvimento das atividades essenciais são muito mais difíceis de serem
alcançados.

Desenvolver softwares é uma difícil tarefa?

A própria natureza do software torna improvável que haja uma solução mágica
para os problemas no desenvolvimento de sistemas, como ocorrido na
integração eletrônica para a construção de hardwares complexos. Não é que o
software evolui muito lentamente; na realidade, o hardware é que evolui muito
rapidamente; não há paralelos tecnológicos no mundo com a velocidade da
inovação em hardware.

Analisando os pontos inerentes à essência dos problemas no desenvolvimento

de software, há os seguintes pontos particulares:

Complexidade: Há poucos elementos repetitivos e idênticos, e fazer

crescer o software envolve muito trabalho além de agregar ou repetir
componentes menores. Não há crescimento linear para o software;

Conformidade: Não há conforto em um princípio unificado. O software,

por ser uma criação muito recente, precisa ser adaptado a todo tipo de
instituição e sistema já existente;

Adaptabilidade: Por poder ser alterado muito facilmente, o software sofre

pressão por mudança e alteração constante;

Invisibilidade: O software não é espacialmente representável: não existe
um diagrama ou esquema lógico que o descreva. São necessárias
muitas representações para conseguir um entendimento visual do
sistema.

Conquistas passadas resolvem problemas acidentais

Passando pelas conquistas do passado que promoveram melhoras de

produtividade na criação do software, temos:

Linguagem de alto nível: Embora realmente muito importante na melhora

de produtividade, este avanço só tem impacto sobre a complexidade
acidental, e não no problema em si;

Time-sharing: Sistemas modernos resolveram o problema de turnaround

que realmente existia com os sistemas de processamento Batch. No
entanto, este problema não faz parte do problema essencial ao
desenvolvimento de software;

Ambientes unificados: Bibliotecas integradas e formatos de arquivos

unificados fazem, na prática, ser possível integrar estruturas conceituais
cujo projeto já previa esta integração, de forma que não resolveram
nenhum problema essencial ao trabalho de construir um sistema de
software.

Proposições de soluções mágicas:

Linguagens de alto nível: Não atacam a essência do problema, embora

realmente ajudem o desenvolvedor a desenvolver técnicas novas de
projetar o sistema;

Orientação a objetos: Resolvem questões acidentais provendo tipos

abstratos de dados e uma hierarquia de tipos. No entanto, não resolvem
questões relacionadas à análise ou projeto de software;

Inteligência artificial: segundo Parnas, O uso de IA não é uma bala de

prata, pelo simples fato de resolver problemas muito específicos, e
requerer trabalho e criatividade para permitir aplicar uma solução a
novas questões;

Programação automática: Até hoje não se viu algo que passe uma
especificação diretamente para código; em geral, se existem, tem
aplicação muito específica;

Programação gráfica: Embora muito de faça analogia com

procedimentos gráficos para desenvolver hardware, resta a dificuldade
sempre de se visualizar a estrutura conceitual que representa o
software. O uso de muitos diagramas é necessário, e isto reduz a
eficiência e compreensão da visualização;

Verificação de programas: Embora realmente tenha impacto sobre teste
e validação do software criado, tem alto custo de aplicação, e não
resolve o problema da especificação incorreta ou imprecisa;

Ambientes e ferramentas: O retorno destes avanços será sempre

marginal, porque apóia o acidental através de mecanismos de validação
de sintaxe e semântica, e apoio a memória do desenvolvedor;

Workstations: Edição e composição já são adequadamente suportadas

pelas velocidades atuais de computadores. A compilação já não é um
gargalo significativo ao processo de desenvolvimento.

Ataques promissores à essência do problema

A tarefa é objetiva, melhorar o desenvolvimento de software deve-se atacar os

aspectos essenciais do software.

Utilizar componentes prontos

Uma solução boa para a construção é justamente não construí-lo; há já

disponíveis grandes quantidades de componentes prontos, tornando muito
mais rápido e barato desenvolver. Custos baixos de hardware e a aplicação
geral da computação têm levado os usuários a requererem menos soluções
customizadas para seus problemas, de forma que software padronizado passa
a ser uma alternativa.

Refinar requisitos e prototipação rápida

A tarefa mais difícil é sempre decidir o que construir. Uma técnica excelente
para resolver o problema é extrair e refinar iterativamente a funcionalidade do
sistema; permitem que os requisitos evoluam, o que é muito mais natural do
que forçar os clientes a especificarem sozinhos.

Desenvolvimento incremental

A forma mais natural de se desenvolver é justamente criar um esqueleto

inicialmente desprovido de funcionalidade, e adicionar esta funcionalidade
incrementalmente. Esta técnica se aplica bem tanto a projetos pequenos
quanto a projetos grandes.

Ter bons projetistas

A grande questão de melhorar o processo de desenvolvimento envolve

melhorar a qualidade do pessoal atribuído as atividades de desenvolvimento.
Bons desenvolvedores e gerentes são raros, mas são o ponto único de maior
impacto na produtividade de uma equipe de desenvolvimento.

Bibliografia
Brooks, F. P. (1986), No silver bullet: essence and accidents of software
engineering, in H. Kugler, ed., “`Information Processing 86”', Elsevier Science
(North Holland), pp. 1069-1076.

Parnas, D. (1985), “Software aspects of strategic defense systems”,

Communications of the ACM 28(12), 1326-1335.