É ao contrario do nec-otium, que é justamente a falta de tempo para estudar, por conta de umas escolhas. Então é claro que o filosofo não só não é alguém vagabundo, no sentido contemporâneo, mas alguém que passa todo o seu tempo refletindo sobre as questões do seu mundo, do mundo contemporâneo, as questões concretas da vida e procurando para além das certezas que compartilhadas por todos, buscar reflexões que possam problematizar essas certezas e, com isso, alcançar, digamos, melhores certezas, certezas mais contributivas, para a nossa convivência, enfim, pra vida de cada um e assim por diante.
]]>Infelizmente, a demanda atual por questionar uma enxurrada de informação mequetrefe, ainda segue esse sistema antigo — experimentar; acreditar que é verdade; e talvez e raramente questionar mais tarde. Não é preciso muito para qualquer um de nós acreditar em algo. E uma vez que isso acontece, proteger essa crença determina como tratamos as informações adicionais relevantes a ela — empurramos mais areia para o mesmo pote.
Queremos pensar bem de nós próprios, e sentir que a narrativa de nossa história de vida é positiva. Apostamos nelas, apostamos em nossas crenças e, é evidente, a maneira como as formamos tem consequências. Quem acreditamos que será o melhor presidente, quanto de gordura e proteína devemos consumir para nos tornarmos mais “saudáveis” o que é mais justo: depende das apostas que nossas crenças fazem. Temos aí um dilema, recusamo-nos naturalmente a atualizar nossas crenças e não há maneira de fazer com que nossa maquinaria cerebral funcione de maneira diferente, não importa o quão inteligente formos.
A esperança começa aqui.
Partindo da pergunta: “Quer apostar?”. Temos, então, a capacidade de atuar sobre nossas crenças e atingir aquele ponto que raramente chegamos “talvez e raramente questionar mais tarde a crença”. Bem, mas não é nada razoável esperar que todos desafiem uns aos outros a apostar em qualquer opnião — mesmo que de forma retórica. Seria difícil fazer algum tipo de amigo desse jeito. Então, partimos para a mudança de nossa própria maneira de pensar sobre as decisões que tomamos: treinando-nos a ver o mundo sob a ótica do “Quer apostar?”. E a pessoa que, no longo prazo, ganha as apostas é aquela cujas crenças são mais precisas e não eficientes.
O ideal é que isso nos estimule a examinar a crença:
— resumo adaptado de: Pensar em Apostas: Decidindo com inteligência quando não se tem todos os fatos - Annie Duke
Definição
Ao que parece, a estrutura de software se dá pouco a intuição desenvolvida sobre os aspectos de, por exemplo, a estrutura de um prédio; onde a estrutura física é, de certa forma, óbvia: em concreto armado, lajes, vigas e pilares. Essas estruturas estão para os limites impostos pela consequência da geometria do espaço-tempo (a gravidade), proposta por Albert Einstein. O software está pouco para a gravidade. Softwares robustos são compostos por “componentes de software menores, que, por sua vez, são formados por componentes ainda menores de software, e assim por diante. É um código dentro do outro, do início ao fim.” (ROBERT, 2018). Portanto, apesar de poder ser difícil confirmar ou compreender a estrutura bruta de vários softwares, é de extrema importância lembrar que se a arquitetura for negligenciada a medida das outras “preocupações” que se tem para produzir um software de qualidade — como, por exemplo, os recursos e funções do domínio da aplicação — serão justamente esses recursos e funções que se tornarão difíceis de serem desenvolvidos, manuteníveis e ampliados à medida da crescente demanda requerida pelo domínio da aplicação e/ou pelo próprio mercado de software. “A arquitetura é o conjunto de decisões que você queria ter tomado logo no início do projeto, mas, como todo mundo, não teve imaginação necessária.” — Ralph Johnson. Pode-se então delimitar o conceito de arquitetura de software como sendo: “uma disciplina que busca definir a estrutura geral do software, incluindo a divisão em módulos, a comunicação entre eles e os padrões de interação com o usuário.” (ROBERT, 2019). “A arquitetura representa as decisões significativas de design que moldam um sistema, onde a significância é medida pelo custo da mudança.” — Grady Booch.
O propósito da Arquitetura
Como descrito no tópico anterior, a arquitetura de software está pouco para a intuição desenvolvida sobre os aspectos de um prédio, como, por exemplo, a força imposta pela gravidade. Mas há um ponto onde as duas áreas compartilham uma única ideia: o mantenimento da funcionalidade. Não é comum observar hordas de trabalhadores dando manutenção em uma construção civil para manter ela em pé e funcionando, os defeitos surgem, em boa parte, por conta da simples passagem do tempo — com base na Lei da Entropia. Nesse mesmo aspecto, não deveria ser comum observar hordas de programadores trabalhando sobre sistemas para mantê-los “em pé” e funcionando adequadamente. Para que esse mantenimento ocorra sem a “força bruta” e incontáveis programadores, deve ser proposto uma cultura que vá além da “força de vontade” e parta para um grau de raciocínio aprofundado, disciplina e dedicação nas quais a maioria dos desenvolvedores de software não está disposto a construir, dia a dia e repetidamente. Quando esse raciocínio aprofundado sobre o software não é abdicado, o esforço humano é atenuado e a funcionalidade e flexibilidade são estimuladas, ou seja, tempo, dinheiro e esforço dão sentido de escala para parametrizar os fatores que são importantes e/ou urgentes dos que não são.
Ivar Jacobson argumenta que as arquiteturas de softwares são estruturas que suportam os casos de uso do sistema, ou seja, eles devem deixar estritamente explícito o domínio de uma aplicação. Pode-se então avaliar que, por exemplo, o uso limitado a frameworks para construção da arquitetura do software vai de encontro com os casos de uso de cada aplicação. Em paralelo a essa abordagem, a garantia da construção de uma casa com base em tijolos não é tida, em primeira instância, como essencial, mas a preocupação maior inicialmente é garantir que a casa seja ao menos utilizável para seu propósito. Portanto, as boas arquiteturas devem ser centradas em casos de uso para que os arquitetos possam descrever com segurança as estruturas que suportam esses casos de uso, sem se comprometerem com frameworks, ferramentas e ambientes. (ROBERT, 2018). Logo, identificar a melhor arquitetura para determinado sistema de software, dependendo das necessidades e dos requisitos temporais do sistema em questão, pode garantir o sucesso de um projeto.
BRUNO, R. C. Arquiteturas e Padrões de Projeto no Desenvolvimento de Software: Uma Análise Comparativa e Quantiva.
Mas isso só acontece se você for atencioso e compassivo — como alguém que olha de fora com calma e respeito; escorado na grade que ainda os separam, observando os detalhes com um binóculo.
]]>Pode me dizer o que houve com suas esperanças?
Será que você pode ser considerada, de algum modo, pronta, segura, boa, eficientes e suficientes? Existe mesmo algum tipo de ordem nisso tudo que passa na sua cabeça, ou você está blefando consigo? Não me entenda mal, eu quero que você pense melhor sobre sua própria vida, irmã. Talvez essa seja mesmo a única maneira de manter-se funcional: encontrando algumas Galápagos de ordem nesse oceano de desordem.
]]>Isso pode ser visto de forma romântica demais, e apesar de eu conseguir descrever as coisas assim, não me desprendo da vida prática contigo. Nada muda pelo simples fato de haver subjetividade nas interpretações, a vida é como é, e de qualquer ângulo que se olhe e viva, ela é boa contigo aqui, meu bem.
]]>O estudo e a capacidade que nosso cérebro tem de tomar decisões com pouca informação do ambiente externo, parece ser a melhor ferramenta que dispomos. É estudando exaustivamente, de forma constante e ordenada, que chegamos ao ouro. Antes um cérebro exigido por tomar diversas decisões diarias com teor preocupante, e sem muitas ferramentas (memórias) as quais utilizar, agora dispõe (com o estudo), o ouro das conexões sinápticas. O que era antes uma pedra bruta, informações e conexões equivocadas e pouco funcionais, torna-se fino e mais adequado as diversas atribuições.
Agora, como proceder com uma enxurrada de informações de baixa qualidade na qual você nem se dá conta? Talvez você não tenha percebido que todas as informações que passam por suas periferias são usadas para a tomada de decisões e cálculos futuros. De valor ao seu tempo aqui e as coisas as quais quer conquistar. Trabalhe por você e pelo que enxerga no futuro, mas não esqueça: as mais impressionantes façanhas humanas são na realidade o amontoado de pequenas ações que, em certo sentido, nada tem de extraordinário. (Daniel F. Chambliss). Faça, faça o que é certo a se fazer e no momento que precisa ser feito fazer. A maturidade, em resumo, vem disso. Lidar com suas ações e, na maior parte do tempo, fazer o que precisa ser feito, não o que você gostaria de fazer. A qualidade de quem faz de forma não idealizada como perfeita, é muito maior do que quem só cogita.
É aí que sua predição de recompensa deve estar adequada. Somos ignorantes, queremos recompensas imediatas, com alto valor recompensatório e pouco esforço, é inerente a forma a qual evoluímos. Ou seja, associações erradas e/ou inadequadas ao contexto é uma das variáveis que pode lhe fazer parar de executar um comportamento; e também, seu estado fisiológico, a função atribuída ao seu comportamento e a organização da sua vida que corroboram com a decisão de fazer ou não. Quando digo sobre a função atribuída ao seu comportamento, leve em consideração que prazer não é o mesmo que recompensa: sua recompensa, a função do comportamento, pode estar atribuída a algo fútil para outras pessoas, é subjetivo, podendo prover de alegria onde dizem que não há.
Atribuir valor a coisas pequenas e controláveis, vão lhe fazer ficar menos disposto a frustrações. A frugalidade. É então que me parece ser interessante também, ter a capacidade de viver com muito menos: não há nada que te abale, você só quer o seu canto, teu trabalho, ter água e comida disponível e boas pessoas as quais contar. Pelo fato de vivermos em um ambiente muito fácil de conseguir essas propriedades básicas, esquecemos do valor que elas possuem. Não só pela facilidade, mas também pela obesidade dos sentidos que hoje tem-se, estímulos excessivos que inibem a nossa sensibilidade de sentir-se bem com pouco. Nosso sistema fisiológico, em boa parte, trabalha por alças de feedback inibitório, ou seja, quanto maior e mais frequente o estímulo menor será a “absorção” dele mesmo. A capacidade de viver com “muito menos”, pode referir-se também a recompensas subjetivas, como dito anteriormente, é ver alegria onde dizem que não.
]]>Podemos observar brevemente a evolução do software, desde os anos de 1950 a 2000:
Estamos vivendo em uma era de dispositivos interconectados, o que torna crucial examinarmos o que é, de fato, o software e quais são as suas idiossincrasias. Para compreendermos plenamente suas características distintas em relação a outras construções humanas, desde sua concepção lógica até a assimilação de conhecimento em todo seu ecossistema, é necessário ir além de uma definição formal que o descreva apenas como: estruturas de dados utilizadas para manipular informações e produzir funções e desempenho adequado. Ao construirmos um edifício ou mesmo um hardware, o processo criativo humano é claramente visível e se materializa em uma forma física. Engenheiros civis desenvolvem esboços iniciais compreendidos em desenhos de projetos formais, que caracterizam as informações e diretrizes necessárias para uma construção eficiente. Esses esboços são então transformados em componentes físicos como cômodos, peças, casas, edifícios etc. O software é desenvolvido ou projetado por engenharia, não manufaturado no sentido clássico. (PRESSMAN, 1995). Tendo essa consideração em vista, é importante ressaltar que o software, ao contrário do hardware e de outras estruturas físicas, não está sujeito, por exemplo, à degradação dos corpos. Portanto, ao considerar a lógica por trás das falhas e correções, bem como o processo de manutenção de um sistema de computador, é fundamental adotar um modelo diferente para a resolução de problemas relacionados ao software.
No contexto atual, a evolução tecnológica e a interconectividade têm gerado uma dependência cada vez maior de sistemas de software robustos e confiáveis. A complexidade do software requer abordagens especializadas, como o uso de metodologias de desenvolvimento ágil, testes contínuos e práticas para garantia de qualidade. Além disso, a compreensão do contexto de uso do software, as necessidades dos usuários e a análise de riscos são aspectos fundamentais para o desenvolvimento e manutenção eficazes.
Portanto, afirma-se que sua caracterização vai além de meras estruturas de dados e requer uma abordagem especializada para garantir sua confiabilidade e segurança. Partindo do reconhecimento de suas peculiaridades e adotando abordagens apropriadas, fortalece-se a base para a construção de um futuro tecnológico mais sólido e confiável.
Considerações Finais
À medida das primeiras décadas da era computacional, o principal foco era desenvolver um hardware que reduzisse o custo e tempo de processamento e armazenamento de dados. Já durante a década de 1980, avanços na microeletrônica transformaram um poder de computação cada vez maior e componentes cada vez menores a custos cada vez mais baixos. Hoje o problema é diferente. Deve-se principalmente a qualidade e redução do custo de soluções baseadas no software. Visto que atualmente o poder de, por exemplo, um notebook como MacBook com um processador Intel i7 de quatro núcleos, rodando a 2.8 gigahertz cada, com 16 gigabyte de RAM, um terabyte de SSD e um display de retina, com resolução máxima de 2880X1800 pixels, tem uma diferença extraordinária em relação ao poder computacional de antigos computadores de meio século atrás. Uma análise razoável mostrará que esse MacBook, que nem é o mais atual, tem pelo menos 1022 vezes mais capacidade em relação a computadores das primeiras eras computacionais. O software é o meio que torna possível o bom uso desse potencial.
Com base nos últimos tópicos descritos em eras, podemos concluir que de fato o hardware evoluiu, linguagens de programação ficaram melhores, ferramentas nesse ecossistemas de software tiveram uma enorme evolução, bem como o surgimento de frameworks e paradigmas da programação trouxeram uma visão sobre maneiras de se programar. Mas a base que compõem um programa de computador não foi alterada. O que deve ser elucidado é que o código continua sendo feito com os mesmos elementos. Formado por declaração de condição, declarações de atribuição e laços de repetição. Assim como nos anos iniciais de 1950 e 1960, ainda é formado por várias sequências, seleções e iterações.
A Engenharia de Software é a disciplina que visa manter o uso sólido de princípios de engenharia, orientados a produzir-se um software que seja economicamente viável, confiável e que consiga interagir adequadamente com o hardware. Seu objetivo é auxiliar os desenvolvedores de software, gerentes e engenheiros de maneira prática, visando melhorar a qualidade dos produtos desenvolvidos e permitir a expressão adequada de modelos de domínio. Essa área do conhecimento busca utilizar metodologias e práticas eficientes para o desenvolvimento, manutenção e evolução do software ao longo de seu ciclo de vida, garantindo a entrega de produtos de alta qualidade que atendam às necessidades e também as expectativas dos usuários.
O Ciclo de Vida
O software passa por diversas fases em sua vida útil, essas fases são organizadas contendo um conjunto comum de estágios, podendo serem descritas em: exploração do conceito, atividades e tarefas no desenvolvimento, operação e manutenção, e aposentadoria. O trabalho inicia-se com o estabelecimento do modelo de ciclo de vida do processo de desenvolvimento, levando em consideração qual é a necessidade do cliente, a natureza do problema, finalidade, qual a medida de tempo de entrega de versões e como elas serão feitas. As atividades conseguintes poderão ser agrupadas em fases, como: definição e análise de requisitos, projeto, desenvolvimento, teste e implantação. Em cada uma dessas são definidas, além das suas respectivas atribuições, as funções e responsabilidades que cada membro ou grupo de membros da equipe terá, e assim propondo a geração de um produto resultante do trabalho de cada profissional. O contraste que geralmente se dá de um processo de software a outro, são: ordem de ocorrência das fases deste processo, o tempo e a ênfase dada a cada, as atividades propostas, e os produtos que serão entregues.
Portanto, as fases descrevem os principais progressos e pontos de conquistas do sistema de software ao longo de seu ciclo de vida. Elas dão origem à base de decisão primária do ciclo de vida. Essas bases de decisão são usadas pelas empresas para entender e gerenciar as incertezas e riscos associados a custos, organização temporal e funcionalidade ao projetar, manter e ou utilizar um sistema computacional externo, podendo assim ter uma visibilidade de alto nível e controle de projetos e processos técnicos. Portanto, as fases descrevem os principais progressos e pontos de conquistas do sistema de software ao longo de seu ciclo de vida. Elas dão origem à base de decisão primária do ciclo de vida. Essas bases de decisão são usadas pelas empresas para entender e gerenciar as incertezas e riscos associados a custos, organização temporal e funcionalidade ao projetar, manter e ou utilizar um sistema computacional externo, podendo assim ter uma visibilidade de alto nível e controle de projetos e processos técnicos. As organizações definem e empregam estágios e modelos diferentes do ciclo de vida do software para satisfazer estratégias contrastantes de mitigação de riscos e negócios. O perfil e complexidade do negócio do cliente, o tempo disponível, o custo, a equipe, o ambiente operacional são fatores que influenciarão diretamente na escolha do ciclo de vida do software a ser adotado, podendo assim ter a presença de mais de um ciclo de vida. Com isso em mente, percebe-se que utilizar um modelo de ciclo de vida é uma das melhores formas de garantir um bom alinhamento entre o desenvolvimento do software e o modelo do domínio, bem como as necessidades dos usuários que irão utilizá-lo. O modelo “ideal” é, portanto, guiado pela necessidade intrínseca do contexto. Dito isso, abaixo estão pontuados, brevemente, alguns dos estágios mais comuns no ciclo de vida de um software.
Análise
O processo de coleta dos requisitos é intensificado e concentrado especificamente no software. Para entender a natureza dos programas a serem construídos, o profissional analista de software deve compreender o domínio da informação para o software, bem como a função, desempenho e interface exigida. Os requisitos tanto para o sistema como para o software, são documentados e revistos com o cliente.
Projeto
O projeto é a fase responsável por recolher os requisitos de software e transformar em um conjunto de representações do modelo do negócio, podendo ser em gráficos, tabulações ou baseadas em linguagem. É um processo de múltiplos passos que se concentra em quatro atributos distintos do programa: estrutura de dados; a arquitetura; detalhes procedimentais e caracterização de interface. Ou seja, o processo de leitura do projeto traduz as exigências numa representação do software que pode ser avaliada quanto à qualidade antes que a codificação se inicie. Como requisito, o projeto é documentado e torna-se parte da configuração do software.
Codificação
Todo o projeto e a idealização da resolução dos problemas de determinado domínio de projeto devem ser desenvolvidos por uma linguagem de programação, compilada ou interpretada por máquina. A etapa de codificação é responsável por este papel. Dada esta codificação, consegue-se executar mecanicamente os processos eletrônicos do hardware responsável.
Testes
Assim que o código for escrito ou até mesmo antes da codificação propriamente dita de as funcionalidades do projeto serem desenvolvidas – tem-se TDD (Test Driven Development) como exemplo de prática de desenvolvimento de software onde a codificação das funcionalidades começa a partir da escrita de testes unitários. Técnica criada por Kent Beck que é um dos pilares do XP (Extreme Programming) – inicia-se a realização de testes do programa. O processo de realização de testes é orientado pelos aspectos lógicos internos do domínio do software, ou seja, é preparado um determinado cenário, executado e depois verifica se este cenário era realmente o esperado.
Manutenção
A palavra soft (suave), pode referir-se ao conceito do mantenimento do software, onde o seus comportamentos devem ser fáceis de serem modificados e ou acrescentados.
A mudança no software é, na maioria esmagadora das vezes, inerente ao projeto desenvolvido. Podendo ocorrer mudanças por erros encontrados ou adaptações requeridas pelo domínio da aplicação e ou então pelo próprio mercado de software. Tendo assim, potencial de ocorrer em projetos já idealmente desenvolvidos ou em desenvolvimento, replicando-se para cada etapa precedente do ciclo de vida de um software.
BRUNO, R. C. Arquiteturas e Padrões de Projeto no Desenvolvimento de Software: Uma Análise Comparativa e Quantiva. 2023. Disponível em: Meu Drive pessoal.
PRESSMAN, Roger S. Engenharia de Software. 3. Makron Books. Tradução: José C. B. S. 1995. 1027 p.
]]>