Anda di halaman 1dari 15

UNIVERSIDAD NACIONAL DEL

CALLAO


ASSUNTO: PORTUGUES

NÍVEL: BÁSICO 5

PROFESSOR: JAVIER PARDO INGA

ESTUDANTES:

- ABANTO CORDOVA, ASTRID CELESTE

- AYARQUISPE GOMEZ, GIANCARLO JACK

Julho, 2018
MINHA PROFISSÃO É:

ENGENHARIA DE SISTEMAS
1. História
As referências ao surgimento da Engenharia de Sistemas remotam às mais
antigas civilizações que se têm conhecimento. Desde a construção das
pirâmides egípcias aos jardins suspensos da Babilônia e até mesmo nas
Américas com as civilizações précolombianas.

Mas foi apenas no século I a.C. que Vitruvius deixou um manual que foi
praticamente a única referência no Ocidente sobre Arquitetura e Engenharia até
o período da Renascença. (ALMEIDA, 2011, p 56).

Segundo Schlager (1956, p. 65 apud ALMEIDA, 2011, p. 57):


As máquinas a vapor trouxeram a revolução industrial no século XVII, mostrando
as grandes indústrias, a capacidade de produção e o surgimento das cidades
onde seria possível o desenvolvimento do transporte público, iluminação a gás
entre outras inovações. No transcorrer do século XIX, ocorreu um grande
desenvolvimento das ciências naturais. Nas ciencias físicas, o estudo dos
fenômenos elétricos e magnéticos deu origem à nova disciplina da Engenharia
Elétrica. A virada do século XIX para o século XX viu o surgimento de muitas
novas tecnologias e inventos relacionados com a Engenharia Elétrica, e.g.,
lâmpada incandescente, telégrafo, telefone, rádio, motores elétricos.

A Engenharia de Sistemas passou por enormes aperfeiçoamentos de acordo


mostra a história. Um dos ocorridos na segunda guerra mundial que foram
definitivos para a carreira da Engenharia de Sistemas sucedeu logo após a
ocupação da Alemanha pelos Estados Unidos, onde, em visita às instalações
inimigas, os Americanos perceberam que as aeronaves alemãs estavam mais
desenvolvidas em termos de tecnologia e aerodinâmica. Constataram que os
projetos dos Alemães eram dotados de um líder de projeto provido de
conhecimentos em aerodinâmica, design estrutural, eletrônica,
servomecanismos, etc. Os Americanos produziram então o Toward New
Horizons, composto de 13 volumes e tratando das inúmeras questões
relacionadas com o uso de aviões e foguetes com fins militares.

Durante a Segunda Guerra Mundial o


conhecimento para o desenvolvimento de novas
armas deu origem às disciplinas como Pesquisa
Operacional e Análise de Sistemas, estas
disciplinas aumentaram a capacidade dos
cientistas de otimizarem seus projetos, Kahn
(1957, p. 01 apud Almeida, 2011, p. 63) ainda
destaca que problemas que durante milênios
eram exclusivamente da jurisdição dos militares
passaram a ser também da jurisdição de
cientistas e com isso tecnologias restritas de guerra foram compartilhadas a toda
a comunidade científica.
Durante a Guerra Fria, intenso período de demonstração da capacidade nuclear
entre Estados Unidos e União Soviética, o espaço sideral tornou-se importante
para a esfera da estratégia. O conceito de dissuasão baseava-se na observação
do comissionamento de armas estratégicas por meio de sensores baseados em
satélites de sistemas de comunicação e vigilância. Sendo assim, a obtenção de
armas nucleares mais potentes e o desenvolvimento de meios de empregá-las
contra o inimigo, além de contramedidas de ataques com armas nucleares
alavancou o desenvolvimento de mísseis nucleares, uma vez que o projeto era
de maior complexidade que o desenvolvimento de aviões, por
exemplo, uma vez que eram utilizados complexas tecnologias em
telecomunicações, georreferenciamento, aerodinâmica e também rigorosas
metodologias de gerenciamento que foram formalizadas na série de documentos
AFSCM 375 da United States Air Force – USAF, como no caso do
desenvolvimento de um míssil balístico intercontinental – ICBM, Almeida (2011,
p. 84) ainda lembra que:

A aplicação de metodologias similares às da AFSCM 375 na NASA tornou


possível o cumprimento das difíceis metas do programa Apollo em 1961. O
sucesso da aplicação da Engenharia de Sistemas no programa espacial civil
levou a muitas tentativas, geralmente frustradas, de sua aplicação na solução de
problemas sociais.

Segundo Takahashi (2009, p. 01): “Um dos marcos da Engenharia de Sistemas,


que ajudou a estabelecer a forma atual de diversos métodos que hoje a integram,
foi o projeto da aeronave Boeing 777, concluído em 1995. Essa foi a primeira
aeronave inteiramente projetada em computador”. O surpreendente projeto
levou menos de cinco anos desde o início da especificação do produto, em 1991,
e o primeiro voo, em 1995, algo inédito até então.

Além do conhecimento específico dos domínios da Engenharia Aeronáutica, da


Engenharia Elétrica, da Ciência da Computação, que tiveram de ser integrados
naquele projeto, há um corpo de conhecimentos que, em parte, estavam sendo
elaborados àquela altura, e que foram cruciais para permitir tanto o prazo recorde
quanto os elevados índices de confiabilidade e de atendimento às especificações
que foram obtidos. Esse corpo constitui a Engenharia de Sistemas como a
conhecemos hoje e em diversos ramos, como o da indústria aeronáutica, o
Engenheiro de Sistemas já é considerado indispensável.

“O mundo de hoje não poderia viver sem o software” Sommerville, 2011

Abstração

Os sistemas computacionais são máquinas de grande complexidade. Esta


complexidade pode ser dominada intelectualmente por uma única ferramenta:
Abstração. Uma linguagem representa um computador abstrato cujos objetos e
construções se encontram mais perto (em mais alto nível) para o problema a ser
representado do que em uma máquina concreta. Por exemplo, em uma
linguagem de alto nível lidamos com os números, matrizes indexadas, tipos de
dados, instruções condicionais e repetitivas, e não com bits e bytes, palavras
endereçadas, desvios e códigos de condição. No entanto, essas abstrações são
benéficas somente se forem consistentemente e completamente definidas em
termos de suas próprias propriedades. Se isto não é assim, se as abstrações
podem ser entendidas só em termos de facilidades de um computador
subjacente, então os benefícios são marginais, quase insignifcantes. Se a
depuração de um programa - sem dúvida a atividade mais comum da engenharia
de software - requer uma "descarga da memória em hexadecimal", a linguagem
vale pouco a pena.

A expansão generalizada do C mina a tentativa de elevar o nível da engenharia


de software, porque C oferece abstrações que não se sustentam de fato:
Matrizes permanecem sem a verificação de índice, os tipos de dados não são
conferidos quanto a consistência, os ponteiros são meramente endereços onde
adição e subtração são aplicáveis . Poderíamos ter classificado C como sendo
algo entre enganoso e até mesmo perigoso. Mas, ao contrário, as pessoas em
geral, particularmente na academia, acharam-no intrigante e "melhor que o
código Assembly”, porque ele apresentava alguma sintaxe.

O problema era que suas regras poderiam ser facilmente quebradas, exatamente
o que muitos programadores estimavam. Era possível acessar todas as
idiossincrasias de um computador, itens que uma linguagem de alto nível deveria
esconder. C proporcionou liberdade, onde as linguagens de alto nível eram
consideradas engessadas impondo uma disciplina indesejada. Era um convite
para usar truques que tinham sido necessários para atingir a eficiência nos
primeiros tempos dos computadores, mas agora eram armadilhas que tornavam
grandes sistemas propensos a erros e dispendiosos para depurar e manter.

Linguagens que apareceram por volta de 1985 (como Ada e C + +), tentaram
remediar estes defeitos e cobrir uma variedade muito maior de aplicações
previsíveis. Como conseqüência, elas se tornaram grandes e suas descrições
volumosas. Compiladores e ferramentas de apoio tornaram-se volumosos e
complexos. Descobriu-se que, em vez de resolver problemas, eles
acrescentaram problemas. Como Dijkstra disse: Eles pertenciam ao conjunto de
problemas ao invés do conjunto de soluções.

Avanços na engenharia de software pareciam estagnar. As dificuldades


cresceram mais rapidamente do que novos instrumentos que poderiam contê-
las. No entanto, ao menos, pseudo-ferramentas como métricas de software
revelaram-se como sendo de nenhuma ajuda, e os engenheiros de software já
não eram julgados pelo número de linhas de código produzidas por hora.

O advento do micro-computador

A propagação da engenharia de software e Pascal notadamente não ocorreu na


indústria, mas em outras frentes: nas escolas e nas casas. Em 1975, micro-
computadores apareceram no mercado (Commodore, Tandy, da Apple, muito
mais tarde IBM). Eles foram baseados em processadores singlechip (Intel 8080,
Motorola 6800, a Rockwell 6502) com barramentos de 8 bits de dados, 32KB de
memória ou menos, e freqüências de relógio inferior a 1 MHz. Eles fizeram os
computadores acessíveis às pessoas em contraste com as grandes
organizações como empresas e universidades. Mas eram brinquedos e não
máquinas computacionais úteis. O salto veio quando foi demonstrado que as
linguagens poderiam ser usadas também com microcomputadores. O grupo de
Ken Bowles da Universidade da Califórnia em San Diego construiu um editor de
texto, um sistema de arquivos e um depurador de todo o compilador Pascal
portátil (código P), desenvolvido na ETH, e os distribuiram por US$ 50. O mesmo
fez a empresa Borland com a sua versão do compilador. Isso aconteceu numa
época em que outros compiladores eram softwares caros, e foi nada menos do
que uma virada na comercialização de software. De repente, havia um mercado
de massa. A computação veio a público.

Enquanto isso, as exigências em sistemas de software cresciam ainda mais,


assim como a complexidade dos programas. O ofício da programação se tornou
tarefa para invasores (“hackers”). Foram procurados métodos para sistematizar,
se não a construção, pelo menos programas de testes e documentação. Embora
isso fosse útil, os problemas reais de programação “agitada” sob pressão do
tempo permaneceram. Dijkstra trouxe a dificuldade ao ponto de dizer: “Testes
podem mostrar a presença de erros, mas nunca poderão provar a sua ausência”.
Ele também desdenhou: “Engenharia de Software é a programação para quem
não pode”.

A programação como uma disciplina matemática

Já em 1968 R. W. Floyd sugeriu a ideia de asserções de estados, das verdades


sempre válidas em certos pontos do programa [10]. Isso levou ao artigo seminal
de Hoare intitulado "Uma base axiomática da Programação de Computadores",
postulando a chamada lógica de Hoare [11]. Alguns anos mais tarde Dijkstra
deduziu a partir dela, o cálculo de transformadores dos predicados [12]. A
programação foi obtendo uma base matemática. Programas já não eram apenas
o código para controle de computadores, mas textos estáticos, que podem ser
submetidos a um raciocínio matemático.

Embora estes desenvolvimentos fossem reconhecidos em algumas


universidades, eles passaram praticamente despercebidos na indústria. Na
verdade, a lógica de Hoare e os transformadores de predicados de Dijkstra eram
explicados de maneira satisfatória, mas para algoritmos simples, como a
multiplicação de números inteiros, busca binária, e máximo divisor comum.
Entretanto, a indústria foi atingida por sistemas verdadeiramente grandes. Isto
não era óbvio para todos, se as teorias matemáticas iriam resolver problemas
reais, quando a análise de algoritmos simples, por si só, já era bastante exigente.

A solução foi basear-se em uma forma disciplinada de programação, ao invés


de em uma rigorosa teoria científica. Uma contribuição importante para a
programação estruturada foi feita por Parnas, em 1972, com a idéia de Ocultação
de Informação [13], e ao mesmo tempo por Liskov com o conceito de Tipos de
Dados Abstratos[14]. Ambos incorporam a idéia de quebrar sistemas de grande
porte em partes, chamados módulos, e definir claramente as suas interfaces. Se
um módulo A usa (importa) um módulo B, então A é chamado de um cliente de
B. O projetista de de A, então não precisa saber os detalhes, o funcionamento
do B, mas apenas as propriedades declaradas em sua interface. Este princípio
constitui, provavelmente, a mais importante contribuição à engenharia de
software, ou seja, a construção de sistemas por grandes grupos de pessoas. O
conceito de modularização é bastante reforçado pela técnica de compilação
separada com verificação automática de compatibilidade nas interfaces.

Assim como a programação estruturada foi o espírito orientador do Pascal, a


modularização foi a principal ideia por detrás da linguagem Modula-2, o sucessor
do Pascal, publicado em 1979 [15]. De fato, sua motivação veio da linguagem
Mesa, um desenvolvimento interno do Laboratório de Pesquisa da Xerox em
Palo Alto, sendo ela mesma uma descendente do Pascal. O conceito de
modularização e compilação em separado também foi adotado pela linguagem
Ada (1984), que também foi amplamente baseada em Pascal. Nela os módulos
foram chamados de pacotes.

A Era da estação de trabalho pessoal

No entanto, um outro desenvolvimento influenciou o campo de computação mais


profundamente do que todas as linguagens de programação. Foi a estação de
trabalho, cuja primeira encarnação, o “Alto”, foi construído, mais uma vez, no
Laboratório de Pesquisa da Xerox em Palo Alto (1975) [16]. Em contraste com
os referidos micro-computadores, a estação era poderosa o suficiente para
permitir o desenvolvimento de software sério, computações complexas, bem
como a utilização de um compilador para uma linguagem de programação
avançada. O mais importante, foi pioneira nas telas de alta resolução –
mapeamento de bits e no dispositivo apontador chamado mouse, que, juntos,
trouxeram uma mudança revolucionária no uso do computador. Junto com o
“Alto”, o conceito de rede de área local (LAN) foi introduzido, bem como
servidores centrais para impressão (a laser), armazenamento de arquivos em
larga escala, e serviço de correio eletrônico. Não há exagero na afirmação que
a era da computação moderna começou em 1975 com o “Alto”. O “Alto” causou
nada mais nada menos do que uma revolução, e como resultado as pessoas de
hoje não tem idéia de como a computação era feita antes de 1975 sem estações
de trabalho pessoais altamente interativas. A influência desses acontecimentos
sobre engenharia de software não pode ser sobrestimada.

Como a demanda de softwares cada vez mais complexos cresceu


persistentemente, como as dificuldades tornaram-se mais ameaçadoras e como
alguns fracassos espetaculares demonstraram que os problemas eram graves,
a procura de panaceias (remédio para todos os males) começou. Muitas curas
foram oferecidas, vendidas, e logo esquecidas. Uma delas, no entanto, mostrou-
se fecunda e sobreviveu: Programação orientada a objeto (POO).

Até 1980, o modelo de computação comumente aceito era transformar os dados


de seu estado dado em resultado, transformando gradualmente a entrada em
saída. Em sua forma abstrata mais simples, esta é a máquina de estado finito.
Este ponto de vista da computação, surgiu a partir da tarefa original dos
computadores: computação de resultados numéricos. No entanto, outro modelo
ganhou terreno na década de 1960: era proveniente da simulação de sistemas
complexos (supermercados, fábricas, ferrovias, logística). Sua abstração
consiste de atores (processos) que vêm e vão, que passam fases em sua vida,
e que trazem um conjunto de dados privados representando o seu estado atual.
Provou-se natural pensar sobre tais atores com seus estados como uma
unidade, como um objeto. Algumas linguagens de programação foram
projetadas com base nesse modelo, sendo seu ancestral Simula, de Dahl e
Nygaard em 1965. Mas elas permaneceram confinadas no campo de simulação
de sistemas de eventos discretos. Somente após o surgimento de poderosos
computadores pessoais que o modelo POO ganhou aceitação mais ampla.
Agora, sistemas de computação possuem janelas, ícones, menus, botões,
barras, etc, tudo facilmente identificável como objetos visíveis e com estado e
comportamentos individuais. Linguagens apareceram apoiando esse modelo,
entre elas Smalltalk (Goldberg e Kay, 1980), Object Pascal (Tesler, 1985), C++
(Stroustrup, 1985), Oberon (Wirth, 1988), Java (Sun, 1995) e C # (Microsoft,
2000). A orientação a objeto tornou-se uma tendência e um chavão. De fato,
escolher o modelo certo para uma aplicação é importante. Mesmo assim, não se
deve desprezar o fato de que existem aplicações para as quais a POO não é o
modelo adequado.

Reflexões Pessoais e Conclusões

O que podemos fazer para liberar essa sobrecarga? Há pouca vantagem em ler
a história, a menos que estejamos dispostos a aprender com ela. Por isso,
atrevo-me a refletir sobre o passado e tentar tirar algumas conclusões. Um
esforço principal deve ser a educação com um sentido de qualidade.
Os programadores devem estar engajados na cruzada contra a complexidade
de fabricação caseira. O crescimento canceroso da complexidade não é uma
coisa para ser admirada, ele deve ser combatido sempre que possível [17].
Programadores devem dispor de tempo e respeito para produzir um trabalho de
alta qualidade. Isso é fundamental e, ultimamente, é mais eficaz do que as
melhores ferramentas e regras. Vamos iniciar um esforço global para impedir
que o software se torne conhecido como softwaste!

Recentemente eu tenho me familiarizado com alguns projetos onde grandes


sistemas operacionais comerciais foram descartados em favor do Sistema
Oberon, cujo principal objetivo foi a clareza e a concentração no essencial [18].
Os líderes do projeto, sendo obrigados a entregar um software confiável e
econômico, reconheceram que eram incapazes de fazê-lo, - mesmo com todo o
cuidado – tendo que construir o seu trabalho em cima do software de base
complexo - uma plataforma - que nem era totalmente descrita, nem segura. Nós
sabemos que qualquer corrente é tão forte quanto seu elo mais fraco. Isso vale
também para as hierarquias de módulos. Os sistemas podem ser projetados com
cuidado e profissionalismo, mas continuarão sujeitos a erros se construídos
sobre uma plataforma complexa e pouco confiável.

A louca corrida por uma maior complexidade - eufemisticamente chamada de


sofisticação - há muito tempo também se apropriava do instrumento mais
importante do engenheiro de software. Linguagens modernas como Java e C #
podem ser melhores do que as antigas como Fortran, PL / I e C, mas estão longe
de serem perfeitas, e elas poderiam ser muito melhores. Seus manuais de várias
centenas de páginas são um sintoma inequívoco da sua inadequação.
Engenheiros na indústria, no entanto, raramente são livres de restrições.
Supostamente, eles devem ser compatíveis com o resto do mundo, e se desviar
dos padrões estabelecidos pode ser fatal.
Mas isso não pode ser dito sobre as universidades. É, portanto, um fato triste
que elas têm permancido inativas e complacentes. Não só tem a pesquisa em
linguagem e metodologia de projeto perdido o seu glamour e atratividade, mas
pior, as ferramentas comuns na indústria tem sido discretamente adotadas sem
debate e crítica. As linguagens atuais podem ser inevitáveis na indústria, mas
para ensinar, para uma introdução fundamentada, ordenada, estrutrada e
sistemática, elas são totalmente erradas e obsoletas.

Isto está notavelmente de acordo com as tendências do século 21: Nós


ensinamos, aprendemos e realizamos apenas o que é imediatamente rentável,
o que é solicitado pelos alunos. Em poucas palavras: Nós focamos no que vende.
Universidades eram tradicionalmente isentas desta corrida comercial. Eram
lugares onde as pessoas deviam refletir sobre o que interessa a longo prazo.
Elas eram líderes espirituais e intelectuais, mostrando o caminho para o futuro.
Em nossa área de computação, estou com medo, elas simplesmente tornam-se
seguidores dóceis. Elas parecem ter sucumbido ao anseio da moda para a
inovação contínua, e ter perdido de vista a necessidade do trabalho cuidadoso.

Se podemos aprender alguma coisa com o passado, é que a ciência da


computação é na essência uma questão metodológica. É suposto desenvolver
técnicas (ensináveis) e conhecimento que são geralmente benéficos em uma
ampla variedade de aplicações. Isso não significa que a ciência da computação
deva derivar para todas estas aplicações diversas e acabe perdendo a sua
identidade. A engenharia de software seria a principal beneficiária de uma
educação profissional em programação disciplinada. Entre suas feramentas, as
linguagens figuram na vanguarda. Uma linguagem com construções adequadas
e estrutura, suportada por abstrações limpas, contribui para a construção de
artefatos e é essencial na educação. A complexidade caseira e artificial não tem
lugar entre essas linguagens. E finalmente: Deve ser um prazer trabalhar com
elas, porque elas nos permitem criar artefatos que podemos mostrar e nos
orgulhar.
2. Doutrina
Conceito

A engenharia de sistemas é uma cadeira universitária que se encarrega do


design (concepção), da programação, da implementação e da manutenção de
sistemas. Ao contrário de outros ramos da engenharia, esta área não trata de
produtos tangíveis (os engenheiros civis, por exemplo, constroem edifícios), mas
sim de produtos lógicos.

Como tal, a engenharia de sistemas implica o uso de noções matemáticas que


permitam concretizar a aplicação tecnológica das teorias dos sistemas. Trata-se
de uma ciência interdisciplinar, que requer diversos conhecimentos para expor
(ou retratar) os seus desenhos/projectos na vida prática.

A engenharia de sistemas permite transformar uma necessidade operativa numa


descrição dos parâmetros do desempenho de um sistema, com a sua
configuração correspondente. Por outro lado, possibilita a integração dos
parâmetros técnicos relacionados de tal modo que as interfaces de programa e
funcionais sejam compatíveis e seja garantido o funcionamento do sistema total.

Ao realizar o seu trabalho, o especialista desta área deve garantir que o sistema
obedeça aos princípios de fiabilidade, manutenção, segurança e eficiência, entre
outros.

O engenheiro de sistemas encarrega-se das diferentes etapas de um projecto


relacionado com os sistemas. Nesse sentido, analisa o rendimento económico,
a efectividade dos recursos humanos e o uso tecnológico vinculado às suas
criações.

Em termos concretos, o engenheiro de sistemas pode dedicar-se ao


desenvolvimento e à implementação de redes complexas, à programação de
aplicações informáticas e à manipulação de base de dados, por exemplo.

Os profissionais em engenharia de sistemas são muito requisitados actualmente


face ao avanço da tecnologia e à necessidade de informatização que têm as
empresas.

7 Princípios da Engenharia de Software

Primeiro princípio: a razão de existir

Um sistema de software existe por um motivo: agregar valor para seus usuários.
Todas as decisões devem ser tomadas com esse princípio em mente. Antes de
especificar um requisito de um sistema, antes de indicar alguma parte da
funcionalidade de um sistema, antes de determinar as plataformas de hardware
ou os processos de desenvolvimento, pergunte a si mesmo: "Isso realmente
agrega valor ao sistema?". Se a resposta for "não", não o faça. Todos os demais
princípios se apoiam neste primeiro.
Segundo princípio: KISS (Keep It Simple, Stupid!, ou seja: não complique!)

O projeto de software não é um processo casual. Existem muitos fatores a


considerar em qualquer trabalho de projeto. Todo projeto deve ser o mais
simples possível, mas não simplista. Esse princípio contribui para um sistema
mais fácil de compreender e manter. Isso não significa que características, até
mesmo as internas, devam ser descartadas em nome da simplicidade. De fato,
os projetos mais elegantes normalmente são os mais simples. Simples também
não significa "gambiarra". Na verdade, muitas vezes são necessárias muitas
reflexões e trabalho em várias iterações para simplificar. A contrapartida é um
software mais fácil de manter e menos propenso a erros.

Terceiro princípio: mantenha a visão

Uma visão clara é essencial para o sucesso. Sem ela um projeto se torna
ambíguo. Sem uma integridade conceitual, corre-se o risco de transformar o
projeto em uma colcha de retalhos de projetos incompatíveis, unidos por
parafusos inadequados...Comprometer a visão arquitetural de um sistema de
software debilita e até poderá destruir sistemas bem projetados. Ter um arquiteto
responsável e capaz de manter a visão clara e de reforçar a adequação ajuda a
assegurar o êxito de um projeto.

Quarto princípio: o que um produz outros consomem

Raramente um sistema de qualidade industrial é construído e utilizado de forma


isolada. De uma maneira ou de outra, alguém mais vai usar, manter, documentar
ou de alguma forma, depender da capacidade de entender seu sistema.
Portanto, sempre especifique, projete e implemente ciente de que mais alguém
terá de entender o que você está fazendo. O público para qualquer produto de
desenvolvimento de software é potencialmente grande. Especifique tendo como
objetivo os usuários. Projete tendo em mente os implementadores. Codifique se
preocupando com aqueles que deverão manter e ampliar o sistema. Alguém terá
que depurar o código que você escreveu, e isso o torna um usuário de seu
código. Facilitando o trabalho de todas essas pessoas, você agrega mais valor
ao sistema.

Quinto princípio: esteja aberto para o futuro

Um sistema com tempo de vida mais longo tem mais valor. Nos ambientes
computacionais de hoje, em que as especificações mudam, de um instante para
outro, e as plataformas de hardware se tornam rapidamente obsoletas, a vida de
um software, em geral, é medida em meses. Contudo, os verdadeiros, sistemas
com "qualidade industrial" devem durar muito mais. Para serem bem sucedidos
nisso, esses sistemas precisam estar prontos para se adaptar a essas e outras
mudanças. Sistemas que obtêm sucesso são aqueles que foram projetados
dessa forma desde seu princípio. Jamais faça projetos limitados. Sempre
pergunte "e se" e prepare-se para todas as respostas possíveis, criando
sistemas que resolvam o problema geral, não apenas o específico (1). Isso muito
provavelmente conduziria à reutilização de um sistema inteiro.
Sexto princípio: planeje com antecedência, visando a reutilização

A reutilização economiza tempo e esforço (2). Alcançar um alto grau de


reutilização é indiscutivelmente a meta mais difícil de ser atingida ao se
desenvolver um sistema. A reutilização de código em projetos de software tem
sido proclamada como uma grande vantagem do uso de tecnologia orientadas a
objetos. Contudo, o retorno desse investimento não é automático. Aproveitar as
possibilidades de reutilização oferecidas pela programação orientada a objetos
ou convencional exige planejamento e capacidade de fazer previsões. Existem
várias técnicas para levar a cabo a reutilização em cada um dos níveis do
processo de desenvolvimento do sistema...Planejar com antecedência para a
reutilização, reduz o custo e aumenta o valor tanto dos componentes reutilizáveis
quanto dos sistemas aos quais os sistemas serão incorporados.

Sétimo princípio: pense!

Este último princípio é provavelmente, o mais menosprezado. Pensar bem e de


forma clara antes de agir quase sempre produz melhores resultados. Quando se
analisa alguma coisa, provavelmente ela sairá correta. Ganha-se também
conhecimento de como fazer correto novamente. Se você realmente analisar
algo e mesmo assim o fizer da forma errada, isso se tornará uma valiosa
experiência. Um efeito colateral da análise é aprender a reconhecer quando não
se sabe algo, e até que ponto poderá buscar o conhecimento. Quando a análise
clara faz parte de um sistema, seu valor aflora.
3. Notícias de atualidade sobre a minha profissão
Melhoria dramática da função de navegação na união inteligente
graças a um relógio molecular

Os relógios atômicos são atualmente os mais precisos. Esses relógios


dependem da ressonância estável dos átomos, quando expostos a uma
frequência específica, para medir exatamente um segundo. Os satélites de GPS
têm vários desses relógios instalados. Ao triangular os sinais desses satélites,
que fornecem dados tridimensionais para posicionamento, nossos smartphones
e outros receptores terrestres podem determinar sua própria localização.

Mas os relógios atômicos são grandes e caros. Nosso smartphone, portanto, tem
um relógio interno muito menos preciso que depende de três sinais de satélite
para a função de limpeza e que não está livre do risco de erro ao indicar locais.
Os erros podem ser reduzidos com correções de conteúdo de satélite extra, mas
o desempenho e a velocidade de navegação são degradados.

Quando os sinais enfraquecem ou desaparecem, como acontece em áreas


cercadas por edifícios altos nos quais são refletidos, ou em túneis, nosso telefone
basicamente tem seu relógio e um acelerômetro para estimar nossa localização
e para onde estamos indo.

A equipe de Ruonan Han, do Instituto de Tecnologia de Massachusetts (MIT),


em Cambridge, Estados Unidos, construiu um relógio em um chip que expõe
moléculas específicas (não átomos) em uma freqüência exata e ultra-alta que
faz com que elas girem.
Quando as rotações moleculares causam a máxima absorção de energia, obtém-
se um valor específico e periódico. Tal como acontece com a ressonância dos
átomos, esta rotação é suficientemente constante e confiável para poder servir
como uma referência precisa do tempo.
4. Vocabulário da minha profissão

Base de datos : banco de dados


Ingeniería : engenharia
Sistemas : sistemas
Ingeniera de Sistemas : engenharia de sistemas
Proyecto : projeto
Ciencias : ciencias
Matemática : matemática
Lenguaje : idioma
Programación : programação
Lenguaje de Programación : linguagem de programação
Arquitectura : arquitectónico
Formulario : formulario
Teclado : teclado
Monitor : monitorear
Conferencias : palestras
Gestion : gestão
Analista : analista
Análisis : análise
Servicio : serviço
Tabla : placa
Campo : campo
Doctrina : Doutrina
Diseñador : desenhista
Ética : ético
Colegio de ingenieros : faculdade de engenheiros
Escuela : escola
Universidad : universidade
Colegiatura : aula particular
Arquitectura de sistemas : arquitetura de sistemas
oficina : escritorio
laboratorio : laboratório
tecnología : tecnologia
red : rede
protocolo : protocolo
digital : digital
aplicaciones : aplicativos
soporte : apoiar
trabajo : trabalho
algoritmo : algoritmo
binario : binário
auditoría : auditoria
archivos : arquivos
circuitos integrados : circuitos integrados
datos : dados
diagrama de flujo : diagrama de fluxo
disco duro : disco rígido
dispositivos : aparelhos eletronicos
enlaces : ligações
estructura de datos : estrutura de dados
hardware : hardware
inteligencia artificial : inteligência artificial
lenguaje ensamblador : linguagem artificial
memoria : memoria
minería de datos : mineração de dados
navegador : browser
página : página
periféricos : periféricos
redes de computadoras : redes de computadores
robótica : robótica
simulación : simulação
usuario : utilizador
variables : variáveis
almacenamiento primario : armazenamento primário
ancho de banda : largura de banda
respaldo de archivos : backup de arquivos
copia de archivos : cópia de arquivos
buscador : buscador
cableado : cabeamento
certificado digital : certificado digital
firma electrónica : assinatura eletrônica
correo electrónico : Correio eletrônico
cibernética : cibernética
código fuente : Código fonte
código abierto : código aberto
comercio electronico : comércio eletrônico
conexión remota : conexão remota
congestión : congestionamento
conmutación de paquetes : troca de serviço
contraseña : password
desarrollador web : desenvolvedor web
descomprimir : descompacte
directorio : diretório
descargas : descargas
instalador : instalador
extensión : extensão
fibra óptica : fibra ótica
filtro : filtrar
paquete : embalagem
carpeta : pasta
punto de red : ponto de rede
guardar : salvar
virus de gusano : virus de gusano
hipervínculo : hipervinculo
impresoras : impressoras
camara digital : Câmera digital
protocolo de internet : protocolo de internet
teléfono inteligente : telefone inteligente
reproductor de música : leitor de música
demo : demo
modo de texto : modo de texto