A complexidade do que parece simples

Agora que muitos jovens se preparam para ingressar em cursos superiores em diversas áreas das chamadas ciências exatas, talvez seja interessante falar um pouco sobre em que consiste e como se desenvolve um projeto de engenharia. Vou, naturalmente, centrar a exposição na minha área – a Engenharia Informática –, embora os conceitos e princípios se possam transpor para outras áreas. Queria, ainda, realçar que a exposição que aqui se apresenta poderá ser útil a um leque variado de leitores, incluindo pessoas de áreas não tecnológicas e, até, a políticos que queiram evitar erros catastróficos de sistemas que deveriam funcionar sem falhas, a nível nacional, afetando centenas de milhares de utilizadores.

Desenvolver um sistema informático pode ser extremamente simples ou atingir elevados níveis de complexidade. Pequenas aplicações para uso individual podem ser elaboradas sem qualquer especificação formal e sem preocupações de fiabilidade e de robustez, com base nalgumas ideias soltas sobre o que se pretende. Podem, até, ser desenvolvidas com recurso a inteligência artificial, sem qualquer necessidade de escrever código, utilizando apenas algumas frases para descrever a funcionalidade pretendida.

Bem, se isto funciona para uma pequena aplicação, por que não usar o mesmo método para sistemas mais complexos? O problema é que, entre um e outro caso, há uma distinção importante: uma coisa é conseguir gerar o código de uma pequena aplicação e outra é conseguir produzir um sistema complexo, realmente robusto e seguro. Quando passamos de uma pequena aplicação pessoal para uma aplicação complexa, com milhares ou milhões de utilizadores, funcionando à escala nacional, já não estamos perante um simples problema de “escrever código”, mas, sim, perante verdadeira engenharia de software e de sistemas.

O desenvolvimento de qualquer sistema complexo exige sempre várias fases, cuidadosamente pensadas, de acordo com metodologias largamente utilizadas em engenharia. Vejamos, no que se segue, as principais.

A primeira fase é a especificação funcional, ou seja, a descrição da funcionalidade do sistema. Antes de escrever qualquer linha de código, é necessário transformar a ideia numa especificação muito precisa. Aqui incluem-se aspetos como o que se pretende com a aplicação, quem são os utilizadores e o que podem fazer, que informação é necessária, que regras se aplicam, que situações excecionais existem, que requisitos legais devem ser observados, e que níveis de serviço são necessários. Esta é, provavelmente, uma das fases mais subestimadas, mas qualquer bom engenheiro sabe que um erro na especificação funcional pode sair muito mais caro do que um erro de programação.

A fase seguinte é designada “especificação interna”, e define a forma como o sistema se organiza, de modo a suportar a funcionalidade especificada na fase anterior. Aqui, estabelece-se a arquitetura do sistema, ou seja, quais os seus componentes ou módulos e como se relacionam entre si. Dessa arquitetura decorrem aspetos cruciais, como, por exemplo, onde ficam os dados, como e por que módulo são processados, como se distribui a carga no sistema, como se fazem cópias de segurança, ou como comunicam entre si os diferentes módulos do sistema.

Um aspeto relacionado com a arquitetura, mas que deve ser alvo de cuidada atenção, é o da escalabilidade, ou seja, a capacidade do sistema para suportar cargas elevadas ou para crescer. O que acontece se cem mil pessoas tentarem utilizar o sistema simultaneamente? Nesse caso, não basta comprar servidores maiores. Muitas vezes, é necessário conceber o sistema para repartir o trabalho por muitos servidores, criar redundância, ou distribuir as bases de dados. Além disso, há que ter em atenção que a escala não é apenas o número de utilizadores. Uma aplicação com dez milhões de utilizadores que fazem uma operação por mês pode ser menos exigente do que uma aplicação com cem mil utilizadores que fazem milhares de operações por minuto. Tudo isto deve ser analisado e acautelado.

Outras características importantíssimas que devem ser consideradas no projeto de qualquer sistema crítico são a segurança e a privacidade. A este respeito, é necessário que a solução desenvolvida proteja a identidade dos utilizadores e os seus dados pessoais. Devem ser cuidadosamente pensados os mecanismos de autenticação dos utilizadores e as respetivas permissões. Quer as comunicações quer as bases de dados devem ser adequadamente protegidas. A par disso, é preciso pensar em ataques deliberados, em monitorização e deteção de intrusões, e em mecanismos de resposta a incidentes. Todos os mecanismos de privacidade devem estar em conformidade com a legislação em vigor.

Num sistema de larga escala – por exemplo, um sistema de âmbito nacional já em funcionamento –, não se pode simplesmente dizer: “Foram detetados alguns problemas; tentaremos resolvê-los até ao final do dia de amanhã.” Pôr em funcionamento um sistema sem haver garantias de fiabilidade e de tolerância a falhas é inconcebível. É durante a conceção do sistema que se deve pensar no que acontece quando um servidor falha, quando uma base de dados fica indisponível, quando uma ligação à Internet cai, quando um componente externo deixa de responder, ou quando ocorre uma falha de software. A existência de mecanismos de redundância, capazes de garantir a operacionalidade do sistema, mesmo quando alguns dos seus componentes falham, é fundamental e tem sempre de ser acautelada.

Por fim, antes de o sistema ser posto em funcionamento em ambiente real, é indispensável fazer testes. Para além de testes em condições normais de funcionamento, é imperioso realizar testes em situações limite, com milhares de utilizadores simultâneos. Devem também fazer-se testes de segurança, de recuperação depois de falhas, de desempenho e de comportamento do sistema face a problemas com componentes externos. Em certos casos, é crucial fazer testes de stress, nos quais se tenta deliberadamente levar o sistema para lá da sua capacidade normal.

Já com o sistema em funcionamento, é importantíssimo monitorizar continuamente a sua operação, de forma a avaliar o normal desempenho, detetar erros e ataques ou identificar quaisquer sinais de degradação. O sistema deve ter sido construído de forma a guardar em registos uma grande variedade de indicadores de funcionamento, e a gerar automaticamente certos tipos de alarmes, caso alguma situação anormal aconteça.

A parte mais complexa no desenvolvimento e na operação de qualquer sistema é, no entanto, a coordenação do grande número de pessoas necessárias para o montar e operar. Um sistema de grande dimensão pode envolver engenheiros de software, programadores, especialistas de bases de dados, engenheiros de infraestruturas, especialistas de segurança, especialistas de redes, desenhadores de interfaces de utilizador e interfaces de gestão, juristas, gestores de projeto, equipas de testes, operadores do sistema, formadores dos utilizadores e, por fim, os próprios utilizadores.

Contudo, no final, por mais sofisticado que seja o sistema, o objetivo é sempre o mesmo: tornar algo que é complexo num sistema de utilização o mais simples possível. Se na complexidade está a garantia de que o sistema funciona, resiste a falhas, suporta cargas elevadas, é útil e dá resposta às necessidades, é na simplicidade de utilização que reside a sua aceitação por todos os que dele devem beneficiar.

.

03/09/2026

Siga-nos: