Nos artigos anteriores, narrei a evolução do desenvolvimento de produtos na AltoQi entre 1995 e 2010, com destaque para o Eberick, nosso software para projetos estruturais. Ao longo desses anos, o Eberick se consolidou como uma solução robusta e inovadora, refletindo a maturidade dos nossos processos e o compromisso contínuo com a inovação, mesmo após quase três décadas de existência.
Atualmente, na nossa divisão de produtos de engenharia, o Eberick compartilha o protagonismo com o AltoQi Builder, uma solução abrangente que integra projetos complementares, como hidráulico, sanitário e elétrico. Mais que isso, o Builder tem desempenhado um papel fundamental na popularização da metodologia BIM no Brasil, consolidando-se como uma peça-chave na transformação digital do setor.
Embora a história do AltoQi Builder (inicialmente, “QiBuilder”) possa parecer recente, ela começou há mais de duas décadas. Desde então, tivemos que superar diversos desafios para alcançar o estágio de maturidade e relevância que vemos hoje.
De volta ao início dos anos 2000, podemos lembrar que Hydros e Lumine foram criados sobre a base de CAD do Eberick, mas como softwares separados. Em um momento inicial, a decisão de apenas copiar a base e continuar cada produto no seu caminho foi necessária para colocá-los rapidamente no mercado. Mas, a ideia de unificar os dois produtos em uma única “plataforma” apareceu já nesse primeiro momento, mas não era viável para aquele momento da empresa.
Como não era possível interromper o desenvolvimento desses produtos (que tiveram versões novas até 2005), optamos por “recomeçar” o projeto em paralelo, desenvolvendo uma nova e melhorada base de CAD, com novos componentes visuais e uma nova ferramenta de desenvolvimento. Sobre essa nova base, iríamos reconstruir os produtos de uma forma integrada. Como sabemos muito bem hoje, algo que não era nada trivial.
Para evitar que o projeto se estendesse por muito tempo sem obter feedback direto dos clientes, optamos por aplicar essa nova base de CAD em um produto mais simples, mas com algum valor para o mercado. Assim nasceu a versão original do QiCAD, lançada em 2001:
“O QiCAD é um programa genérico para desenho em 2-D, podendo ser utilizado para a elaboração de qualquer tipo de trabalho em CAD. Em sua aplicação inicial, destina-se a fazer o acabamento de plantas de forma e cortes gerados pelo AltoQi Eberick ou pelo AltoQi Formas. Para tal, apresenta uma série de recursos adicionais de CAD que não estão presentes em nenhum destes programas”.
Era apenas uma versão muito simplificada do AutoCAD, mas trazia a nossa abordagem de usabilidade, especialmente no gerenciamento de escalas de desenho.
Embora o lançamento do QiCAD tivesse sido importante como demonstração técnica da nova base de desenvolvimento, não entregava um valor relevante para o mercado. Para alcançarmos um estágio real de MVP (Minimum Viable Product) e termos um produto que fazia sentido no nosso portfólio, optamos por “vocacioná-lo” para ser uma ferramenta de apoio à finalização dos projetos estruturais.
Em 2003, foi lançado o QiCAD V3, que trazia dois grandes diferenciais em relação ao AutoCAD:
Como diferenciais, apresentávamos ainda a tecnologia 100% nacional, bibliotecas de símbolos e o gerenciamento das escalas de desenho.
Esse produto continuou sendo desenvolvido até 2007, com o lançamento do QiCAD V4, produto que representava a maturidade do CAD para Engenharia da AltoQi. Foi feita uma revisão geral, priorizando a estabilidade e performance do programa, além da implementação de uma nova interface.
Nessa versão, foi incluído o gerenciamento das configurações (padrões de desenho e níveis, por exemplo) dos arquivos presentes em um projeto, facilitando a padronização dos desenhos. No Módulo Editor de Ferros, foi incluído o desenho de ferros com trechos curvos, estendendo o escopo do programa ao detalhamento de peças circulares, e a possibilidade de gerenciar a Relação do Aço de vários desenhos simultaneamente, facilitando, por exemplo, a manipulação de pranchas de detalhamento formato A3 com RA no final.
Durante todo esse período, entre 2000 e 2007, permanecemos com o desejo de migrar os nossos produtos de projeto para a base do QiCAD. Foram desenvolvidas algumas provas de conceito, criando os primeiros elementos que representavam de forma genérica o projeto de instalações. Contudo, não tínhamos a capacidade de investimento necessária para materializar esse projeto.
Esse cenário só mudou com a Chamada Pública MCT/FINEP de Subvenção Econômica à Inovação 01/2006. Nosso projeto “QiBuilder – Sistema Integrado para Projeto de Edificações em Alvenaria Estrutural” foi aprovado em outubro de 2008, com a proposta abaixo:
“O presente projeto de subvenção permitirá o desenvolvimento do sistema no qual se pretende unificar a elaboração de todos os projetos (estrutural, hidráulico, elétrico, cabeamento etc.) em um software completo. Além de uma interface de CAD mais moderna, esse produto terá características únicas de integração entre os projetos, permitindo, por exemplo, o trabalho colaborativo e a detecção de interferências. A AltoQi é a única empresa nacional que atua simultaneamente em todas essas áreas, o que lhe permitirá alcançar esse objetivo. Nesta primeira etapa, o foco será o desenvolvimento da aplicação voltada às edificações em alvenaria estrutural, mas a base tecnológica criada poderá ser usada, futuramente, pela empresa, para estender o escopo ao projeto de edificações convencionais em concreto armado”.
Além do nosso objetivo original de unificar as funcionalidades que existiam no Hydros e no Lumine, incluímos no escopo o desenvolvimento de um outro módulo inovador, voltado ao detalhamento de alvenaria estrutural, visto ser esse um dos objetos de interesse do edital.
É interessante destacar também a visão que já tínhamos nessa época:
“Neste projeto será implantada a tecnologia BIM (Building Information Modeling), um método inovador para a integração entre Arquitetura, Engenharia e Construção, pelo qual uma edificação pode ser projetada e construída, permitido ao projetista trabalhar sobre um único modelo tridimensional, no qual os elementos geométricos tradicionais são substituídos por objetos com informações atribuídas”.
A Subvenção FINEP foi um marco decisivo na trajetória da AltoQi. Além de um grande desafio pessoal como gestor de projetos, esse apoio financeiro abriu novas possibilidades para o desenvolvimento tecnológico da empresa. O projeto previa uma nova equipe (dobrando a nossa estrutura) e um prazo total de 36 meses, muito maior do que qualquer coisa que já tínhamos feito até então. Hoje, temos na AltoQi uma estrutura madura e escalável, mas não era a nossa realidade naquele momento.
Felizmente, já estávamos na nossa curva de crescimento de maturidade, com o investimento nas melhores práticas de Engenharia de Software, motivado pelo nosso desafio em concluir o Eberick V5 Gold.
O Projeto QiBuilder nascia no mesmo ambiente em que estávamos concebendo o nosso modelo de desenvolvimento incremental e iterativo, que seria formalizado em 2009.
A figura abaixo contém a EAP (Estrutura Analítica de Projeto) que foi usada para representar o escopo e acompanhar a evolução do projeto até a sua conclusão.
Pela natureza do projeto de subvenção, tivemos que equilibrar duas visões bem distintas. No aspecto mais geral, todos esses pacotes de entrega foram definidos no plano do projeto, gerando um grande gráfico de Gantt que representava nosso compromisso com o FINEP e balizava os relatórios de acompanhamento que eram entregues. No aspecto das equipes, os detalhes de cada entrega deveriam ser tratados de forma incremental e iterativa.
A combinação entre esses dois aspectos gerou o desafio de estabelecer um processo de desenvolvimento ágil em escala, um dos pontos fortes na AltoQi até os dias de hoje.
Tivemos múltiplas equipes trabalhando em diferentes subprojetos ao longo desse período, mas todas coordenadas em conjunto. O meu artigo sobre a Integração Contínua aborda um dos aspectos técnicos que foram mais importantes para viabilizar isso.
Nesse primeiro plano mais geral do projeto, busquei a inspiração no RUP (Rational Unified Process), que fornecia um modelo mais amplo para o desenvolvimento iterativo, que ia além do conceito simples difundido pelo Scrum na época. Os artefatos em si do RUP não eram relevantes, mas sim a ideia das “macro-fases” que definiam grandes etapas a serem alcançadas pelo projeto:
Essa não é mais a metodologia que utilizamos hoje, mas a necessidade de coordenar diferentes equipes em paralelo para uma única entrega se manteve. Ao mesmo tempo em que cada equipe conduz o seu projeto aplicando metodologias ágeis, existe uma coordenação geral que estabelece os mesmos critérios de estimativa em cada projeto e a mesma cadência de entregas, fazendo com que o todo seja igualmente ágil e previsível.
O AltoQi Hydros e o AltoQi Lumine tiveram seu desenvolvimento descontinuado em 2004, mas os seus clientes eram todos potenciais usuários da nova solução.
Nosso primeiro grande objetivo foi o lançamento de uma versão parcial, com a qual seria possível executar projetos de instalações hidráulicas, sanitárias, de gás e de combate e prevenção a incêndio. O público-alvo era os 5600 clientes do produto AltoQi Hydros V4. Queríamos completar essa etapa em 2011, antes da metade do projeto.
Desenvolver um software capaz de integrar todos os projetos de uma edificação simultaneamente foi uma tarefa árdua e complexa. A arquitetura do sistema, baseada em arquivos, apresentou performance insuficiente para as operações de verificação e dimensionamento da edificação integrada. Por isso, tivemos que inserir um subprojeto não previsto inicialmente, migrando desse modelo de arquivos para um modelo baseado em bancos de dados.
A primeira versão do programa foi lançada comercialmente em 2013, contendo uma abordagem renovada para todos os módulos que existiam no AltoQi Hydros e o novo QiAlvenaria.
Os módulos correspondentes ao AltoQi Lumine estavam em fase final de desenvolvimento e seriam lançados gradualmente nos anos seguintes. A partir desse ponto, a AltoQi continuou o projeto com investimento próprio, mas o impulso inicial fornecido pela subvenção foi determinante para o projeto sair do papel.
Com isso, a AltoQi estendeu sua atuação às edificações em alvenaria estrutural. Tratava-se de um software inédito, sobre um sistema construtivo que ganhava força no Brasil, colocando a AltoQi em uma posição de vanguarda no mercado interno.
Diferente das ferramentas de apoio ao projeto de alvenaria que existiam na época, a nossa solução se baseava no lançamento de objetos inteligentes (paredes e aberturas), combinado com um cadastro de peças unificado, que conseguia gerar de forma automatizada a modulação de todas as paredes, gerando detalhamentos finais completos e quantitativos precisos de todos os materiais.
Nos anos de 2014 a 2017, a AltoQi manteve o ritmo de investimento no QiBuilder, mas agora com recursos próprios. Tivemos o lançamento do QiElétrico e QiCabeamento, completando o escopo anteriormente presente no AltoQi Lumine, mais o QiSPDA, primeiro software para projeto de sistemas de proteção contra descargas atmosféricas capaz de fazer a verificação da edificação completa.
O QiSPDA foi o primeiro software a implementar a verificação da edificação pelo método eletrogeométrico em 3D (também chamado “método da esfera rolante”), direto sobre o lançamento dos componentes do projeto.
Todavia, a abordagem do projeto como um todo no mesmo ambiente, contendo as disciplinas integradas e um Cadastro de Peças unificado, se mostrou muito custosa computacionalmente. O software conseguia lidar apenas com edificações de menor porte. Então, tínhamos uma ferramenta com enorme potencial e que entregava nossos diferenciais de usabilidade e produtividade, mas em um escopo de atuação limitado.
Essa limitação era causada pela ferramenta de desenvolvimento que utilizávamos na época, o Borland C++ Builder 2006, que permitia a criação de aplicações apenas em 32 bits. Essa arquitetura, que era comum na época, limitava o uso de memória RAM por cada aplicação em 2 GB.
Na prática, quando o projeto chegava perto desse limite já ocasionava “crashes” na aplicação, para grande insatisfação dos nossos usuários. Esse limite de memória não existia para as novas aplicações em 64 bits, sendo esse o único caminho possível para a continuidade do nosso produto.
Para que fosse possível migrar para uma nova ferramenta, como o Microsoft Visual C++, seria necessário substituir todo o framework gráfico Borland VCL utilizado pelo programa, ou seja, reconstruir cada parte da interface do software em uma outra biblioteca compatível com a compilação em 64 bits. Foi escolhido o Qt, um framework multiplataforma de código aberto que é líder de mercado.
Lidar com esse problema da obsolescência das ferramentas de desenvolvimento utilizadas e com os problemas causados pelo “lock-in” em um fornecedor específico foi um grande aprendizado para a nossa equipe. Mesmo escolhendo uma solução consolidada como a do Qt, optamos por não apenas trocar a interface, mas também isolar a camada das regras de negócio da aplicação, tornando-o independente de qualquer biblioteca ou framework gráfico específico.
Para atender aos requisitos arquiteturais, a solução de implementação da interface gráfica do QiBuilder utilizou a combinação de três conceitos:
O padrão MVP prevê a separação do código de interface gráfica em três partes:
Finalmente, a injeção de dependência tinha o objetivo de permitir a instanciação e associação da interface gráfica Qt ao QiBuilder, mantendo a independência estática (em tempo de compilação) do código de negócio do QiBuilder com a interface gráfica Qt.
A ideia básica é ter uma classe separada, o "assembler", que instancia e preenche a classe concreta e suas dependências com as implementações concretas apropriadas, resultando em um diagrama de dependência similar à figura abaixo.
Utilizando ferramentas de verificação da arquitetura da aplicação, tínhamos um critério bem objetivo para acompanhar a evolução desse projeto, que era o número de dependências existente na nossa base de código com os componentes proprietários da Borland:
Esse projeto consumiu a maior parte do investimento da AltoQi sobre o QiBuilder nos anos de 2015 e 2016. Ao final de 2016, a versão oficial do produto era o QiBuilder 2017, ainda em 32 bits, enquanto entrava no mercado o novo QiBuilder 2018 em 64 bits, inicialmente como uma “Versão Beta”.
As duas versões foram mantidas em paralelo até 2018, com o lançamento oficial do QiBuilder 2018 deixando finalmente para trás o limite das aplicações em 32 bits.
Em paralelo ao investimento para que o QiBuilder pudesse finalmente ultrapassar o limite das edificações de pequeno porte, a AltoQi investiu para se integrar às demais ferramentas do mercado com a adoção do padrão OpenBIM.
O QiBuilder 2018 permitia importar modelos externos em formato IFC (Industry Foundation Classes) para visualização integrada no 3D e também exportar o modelo da tubulação no mesmo formato.
Ainda assim, esse foi apenas um primeiro passo. Quando conseguimos terminar a nossa “versão definitiva” do QiBuilder em 64 bits, tratando os problemas de performance que tinham nos limitado até então, já estávamos em um novo momento de mercado, em que o padrão de detalhamento unifilar que tínhamos mantido desde o AltoQi Hydros não era mais o suficiente para competir com ferramentas específicas de modelagem 3D, como o Autodesk Revit.
Tivemos que repensar novamente o nosso produto e focar agora em aspectos de modelagem tridimensional. Essa é a história que irei concluir no meu próximo artigo.