Vous êtes sur la page 1sur 7

Isaías Bartolomeu Sambga

Licenciatura em Engenharia Electrónica (3° ano)

Resumo

Universidade Pedagógica De Moçambique

Maputo

2017
Isaías Bartolomeu Sambga

Licenciatura em Engenharia Electrónica (3° ano)

Resumo

Resumo a ser apresentado na ESTEC na cadeira


de Engenharia de Software para efeito de
avaliação dos estudantes, sob orientação do
Docente:

Universidade Pedagógica de Moçambique

Maputo

2017
No Silver Bullet (Sem Bala de Prata): Essência e Acidentes da Engenharia de Software.

O manual de Silver Bullet compara os acidentes da Engenharia o software ao um lobisomem,


que, de todos os monstros que preenchem os pesadelos de nosso folclore, nenhum nos
aterroriza mais que lobisomens, porque eles inesperadamente se transformam do familiar ao
horrível. Assim, procura-se balas de prata que possam magicamente fazê-los descansar. O
projeto de software familiar, pelo menos do ponto de vista do gerente não técnico, tem algo
desta personagem; ele é normalmente inocente e honesto, mas capaz de se tornar um monstro
de prazos deficientes, orçamentos de danificação de produtos falhos. Surgem então súplicas
desesperadas por uma bala de prata algo que faça os custos de software cair tão rapidamente
quanto os custos de hardware de computador.

Tem que ser difícil? Dificuldades Essenciais

Não há apenas balas de prata agora em vista, a própria natureza do software faz com que
improvável que haja alguma - nenhuma invenção que fará para a produtividade do software,
confiabilidade e simplicidade que eletrônicos, transístores e integração em grande escala para
hardware de computador. Não podemos esperar nunca ver dois ganhos a cada dois
anos.Primeiro, deve-se observar que a anomalia não é que o progresso do software seja tão
lento, mas que o progresso do hardware de computador seja tão rápido. Em nenhuma outra
tecnologia alguém pode escolher ganhos tanto em melhoria de desempenho quanto em custos
reduzidos. Segundo, para ver qual taxa de progresso se pode esperar na tecnologia de software,
devemos examinar as dificuldades daquela tecnologia. Seguindo Aristóteles, o autor as divide
em:

 Essência: as dificuldades inerentes na natureza do software.


 Acidentes: dificuldades que afetam a produção do software, mas não são inerentes à sua
natureza.

A essência de uma entidade do software é a construção de conceitos engrenados: conjuntos


de dados, relacionamentos entre itens de dados, algoritmos e chamadas de funções. Esta
essência é tão abstrata que uma construção conceitual é a mesma sob muitas representações
diferentes. Portanto, é altamente precisa e rica em detalhes. O autor acredita que a parte
mais difícil na construção do software seja a especificação, o projeto e o teste desta
construção conceitual, e não o trabalho de representá-lo e testar a fidelidade da
representação. A construção de um software será sempre difícil. Não há nenhuma bala de
prata inerente. Seguem as propriedades inerentes desta essência irredutível dos sistemas de
software modernos:

Complexidade. as entidades do software talvez sejam mais complexas para seu tamanho que
qualquer outra construção humana porque duas partes não são similares (pelo menos acima do
nível de especificação). Se elas forem similares, criamos as duas partes em uma sub-rotina –
aberta ou fechada. Neste aspecto, sistemas de software diferem profundamente de
computadores, Edificios ou automóveis, onde elementos repetidos abundam. O
escalonamento de uma entidade de software não é meramente a repetição dos mesmos
elementos em tamanhos maiores, mas necessariamente um aumento no número de elementos
diferentes. Na maioria dos casos, os elementos interagem entre si de forma não linear, e a
complexidade do todo cresce muito mais que linearmente. A complexidade do software é uma
propriedade essencial, não acidental. Por isso, descrições de uma entidade de software que

abstrae sua complexidade sempre abstraem sua essência. Muitos dos problemas clássicos no
desenvolvimento de produtos de software derivam desta complexidade essencial e seu
aumento não linear de tamanho. Da complexidade surge dificuldade de comunicação entre os
membros da equipe, o que leva a falhas no produto, custos exacerbados e atrasos nos prazos
estabelecidos. Da complexidade surge dificuldade de enumerar, muito menos entender todos
os estados do programa e a origem da deficiência. Da complexidade da função vem
dificuldade de chamar a função, o que torna os programas difíceis de usar. Da complexidade
de estrutura surge dificuldade de estender os programas com novas funções sem criar efeitos
colaterais.

Conformidade. Einstein argumentava que deve haver explicações simplificadas da natureza,


porque Deus não é excêntrico ou arbitrário. Porém, nenhuma fé conforta o engenheiro de
software. Grande parte da complexidade que ele tem que dominar é de caráter arbitrário,

forçada sem uma razão exata por muitas instituições humanas e sistemas para os quais suas
interfaces devem se adaptar. Diferem de interface para interface e de tempo para tempo, não
devido à necessidade, mas somente porque foram projetados por diferentes pessoas, em vez
de Deus. Em muitos casos, o software deve se adaptar porque é novo e entrou em cena
recentemente. Em outros, porque é percebido como o mais adaptável.

Variabilidade. a entidade do software está constantemente sujeita às pressões por mudanças.


O software, dentro de um sistema, pode ser modificado mais facilmente é puramente objeto
intelectual, infinitamente maleável. Todo software de sucesso sofre mudança. Um software de
sucesso sobrevive além da vida normal do veículo de máquina para o qual é primeiramente
escrito. Novos computadores, discos, displays, impressoras surgem e o software deve ser
adaptável a estes dispositivos. Em suma, o produto de software é incorporado a uma matriz
cultural de aplicações, usuários, leis e veículos de máquina, que estão em constante mudança
e suas mudanças, inexoravelmente, forçam mudanças no produto de software.

Invisibilidade. o autor defende que o software é invisível e invisualizável. Abstrações


geométricas são ferramentas poderosas, mas a realidade do software não está incorporada
inerentemente ao espaço. Assim que tentamos diagramar a estrutura do software, descobrimos
que ela não possui um, mas muitos gráficos superpostos. Os diversos gráficos podem
representar o relacionamento entre fluxo de controle, fluxo de dados, camadas de
dependência, seqüência de tempo e name-space. Estes gráficos normalmente não são planos,
nem hierárquicos.

Desvios anteriores solucionaram dificuldades acidentais


O autor defende que, ao examinarmos as três etapas no desenvolvimento da tecnologia de
software que foram mais produtivas no passado, descobrimos que cada uma atacou uma
dificuldade diferente na construção do software, mas que aquelas dificuldades foram
acidentais, não essenciais.

Linguagens de alto nível. a linha mais poderosa para a produtividade, confiança,


simplicidade e inteligibilidade do software foi o uso das linguagens de alto nível na
programação. livra um programa de muitas das suas complexidades acidentais. Seu maior
benefício é fornecer todas as construções que o programador imagina no programa abstrato. E
o desenvolvimento da linguagem se aproxima cada vez mais da sofisticação dos usuários.
Tempo de compartilhamento . a divisão do tempo trouxe melhorias principalmente na
produtividade dos programadores e na qualidade de seu produto, mas não tanto quanto as
trazidas pelas linguagens de alto nível. A divisão de tempo preserva imediatismo e, por isso,
permite manter uma visão geral da complexidade.

Ambientes de programação unificado. Unix e Interlisp, os primeiros ambientes de


programação integrada que chegaram a um uso abrangente, melhoraram a produtividade pois
atacaram as dificuldades acidentais que resultam do uso de programas individuais em
conjunto, através do fornecimento de bibliotecas integradas, formatos de arquivo unificados,
filtros, entre outros.

Esperanças para a Prata. O autor chama o leitor para refletir sobre os desenvolvimentos
técnicos que são avançados como potenciais balas de prata. Quais problemas eles visam
problemas de essência, ou as dificuldades acidentais permanentes. Eles oferecem avanços
revolucionários, ou incrementais.

Programação orientada a objeto. o autor mantém mais esperança em programação


orientada a objeto do que em qualquer outra ovidade técnica atual. Mesmo assim, defende que
tais avanços não fazem mais do que remover todas as dificuldades acidentais de expressão do
projeto.

Inteligência artificial. muitas pessoas esperam avanços na inteligência artificial para prover o
progresso revolucionário que proporcionará ganhos na ordem de magnitude em produtividade
e qualidade de software. Mas O autor concorda com esta crítica. Por exemplo, as técnicas
usadas para reconhecimento de fala parecem ter pouco em comum com aquelas usadas para
reconhecimento de imagem e ambas são diferentes daquelas usadas em sistemas
especializadas.

Sistemas especializados.de acordo com o autor, a parte mais avançada da arte da inteligência
artificial, e a mais aplicada, é a tecnologia para construir sistemas especializada. Um sistema
expert é um programa que contém uma máquina de inferência generalizada e uma base de
regra, tem dados de entrada e suposições, explora as inferências deriváveis da base de regra,
fornece conclusões e avisos, além de oferecer explicações sobre os resultados re-traçando o
raciocínio para o usuário.
Programação Automática. o autor cita Parnas Em suma, a programação automática tem
sempre sido mais um eufemismo para a programação com uma linguagem de alto nível do
que os recursos actualmente disponíveis ao programador. E conclui que é difícil ver como esta
técnica generaliza para o mundo mais extenso do Sistema de software ordinário, onde casos
com propriedades nítidas sãoexceções. E também é difícil imaginar como este progresso na
generalização pode ocorrer.

Programação gráfica. o autor diz que, às vezes, o teórico justifica a abordagem por
considerar fluxogramas o meio de projeto de programa ideal por fornecerem facilidades
poderosas para construí-lo. Mas defende que nada convincente ainda surgiu destes esforços e
crê que não surgirá, pois vê o fluxograma como uma abstração muito pobre da estrutura do
software e as telas da época eram muito pequenas, em pixels, para mostrar tanto o escopo
quanto a resolução de qualquer diagrama de software detalhado. E conclui que, mais
fundamentalmente, é muito difícil visualizar o software.

Verificação do programa. o autor não acredita em grandes mágicas em produtividade com


este recurso. A verificação do programa é um conceito poderoso, mas não promete poupar
tanto trabalho. Embora verificação possa reduzir a carga de teste de programa, não pode

eliminá-la. Indo além, mesmo uma verificação perfeita do programa pode somente confirmar
que o programa atende às suas especificações.

Ambientes e ferramentas.o autor diz que editores inteligentes específicos de linguagem são
desenvolvimentos ainda não utilizados amplamente na prática, mas prometem principalmente
resolver problemas de sintaxe e erros simples de semântica. Talvez o maior ganho dos
ambientes de programação ainda seja o uso de sistemas de banco de dados integrados para
acompanhamento dos inúmeros detalhes que devem ser recuperados apropriadamente pelo
programador individual e mantidos atualizados para um grupo de colaboradores em um
sistema único.

Estações de Trabalho. o autor diz que as estações de trabalho cada vez mais poderosas são
bem vindas, mas não podemos esperar progressos mágicos a partir delas. Ataques
Promissores na Essência Conceitual De acordo com o autor, embora nenhum progresso
tecnológico prometa trazer resultados mágicos com os quais somos tão familiars na área de
hardware, há a abundância de bons trabalhos e a promessa de um progresso, se não
espetacular, estável. Todos os ataques tecnológicos sobre os acidentes do processo de
software são fundamentalmente limitados pela equação de produtividade. Por isso o autor
defende que devemos considerar aqueles ataques que indicam a essência do problema de
software, a formulação destas estruturas conceituais complexas.

Qualquer um destes produtos é mais barato que construir um novo. Mesmo a um custo de cem
mil dólares, o preço de compra do software é equivalente ao salário anual de somente um
programador mais poderosa para muitas organizações seja equipar os trabalhadores
intelectuais sem conhecimentos de computador com computadores pessoais e programas de
escrita, desenho, arquivo e planilha.
Nenhuma outra parte do trabalho conceitual é tão difícil quanto estabelecer requisitos técnicos
detalhados, incluindo todas as interfaces para pessoas, máquinas e outros sistemas de
software. Nenhuma outra parte do trabalho prejudica o sistema resultante caso seja feita
incorretamente. Nenhuma outra parte é tão difícil de corrigir mais tarde. Portanto, as funções
mais importantes que o construtor de software desenvolve para o cliente são a extração e o
refinamento iterativos dos requisitos do produto. O autor ainda afirma que é realmente
impossível para um cliente, mesmo trabalhando com um engenheiro de software, especificar
completa, precisa e corretamente os requisitos exatos de um produto de software moderno
antes de testar algumas versões do produto.

O autor diz que muito do procedimento atual de aquisição de software repousa sobre a
suposição de que se pode especificar um sistema satisfatório antecipadamente, receber
propostas para sua construção, construí-lo e instalá-lo. E defende que esta suposição é
essencialmente incorreta, e que muitos problemas na aquisição de software surgem desta
ilusão. Diz que o cérebro sozinho é intrincado além de mapeamento, poderoso além da
imitação, rico em diversidade, auto-protetor e autorenovador. O segredo é que o cérebro é
evoluído, não construído, e da mesma forma deve ocorrer com sistemas de software.

Grandes projetistas. o autor defende que a questão central de como melhorar os centros de
software está nas pessoas. Podemos ter bons projetos seguindo boas práticas, que podem ser
pensadas. Ressalta que os programadores fazem parte da camada mais inteligente da
população, desta forma podem aprender boas práticas. Por isso, o grande impulso é propagar
boas práticas modernas. Novos currículos, nova literatura, novas organizações a fim de elevar
o nível de nossa prática de ruim para bom. Excelentes projetos vêm de excelentes projetistas.
A construção do software é um processo criativo. Uma metodologia sólida pode capacitar e
libertar a mente criativa. Muitos estudos mostram que projetistas muito melhores produzem
estruturas que são mais velozes, menores, simples, limpas e com menos esforço.

A proposta do autor é que cada organização de software deve determinar e proclamar que
grandes projetistas são tão importantes para o seu sucesso quanto grandes gerentes e,
similarmente, nutri-los e recompensá-los. Não somente salário, mas gratificações de
reconhecimento – tamanho do escritório, mobiliários, equipamento técnico pessoal, fundos
para viagens e pessoal de apoio. E sugere alguns passos para que as organizações
desenvolvam grandes projetistas

 Identificar os melhores projetistas o mais cedo possível. Os melhores nem sempre são
os mais experientes.
 Atribuir um mentor de carreira para ser responsável pelo desenvolvimento de cada
profissional identificado e montar cuidadosamente um plano de carreira.
 Criar e manter um plano de desenvolvimento de carreira para o profissional, incluindo
cuidadosamente aprendizagens selecionadas com os melhores projetistas do mercado,
educação formal avançada e pequenos cursos, todos intercalados com projetos
individuais e exercícios de liderança técnica.
 Dar oportunidades para os projetistas em crescimento interagirem e criarem
estímulos.