← Approfondimenti
Uncategorized · 4 min

Sviluppo di add-on Archicad su richiesta: dal problema operativo a uno strumento su misura

Ogni studio sviluppa nel tempo un proprio modo di lavorare. Alcune attività vengono ripetute progetto dopo progetto: controllare dati, rinominare elementi, verificare regole, preparare esportazioni o trasferire informazioni tra procedure diverse. Quando gli strumenti standard non risolvono adeguatamente un’esigenza ricorrente, può essere utile valutare un add-on Archicad sviluppato su richiesta. Non si parte però dal […]

Ogni studio sviluppa nel tempo un proprio modo di lavorare. Alcune attività vengono ripetute progetto dopo progetto: controllare dati, rinominare elementi, verificare regole, preparare esportazioni o trasferire informazioni tra procedure diverse.

Quando gli strumenti standard non risolvono adeguatamente un’esigenza ricorrente, può essere utile valutare un add-on Archicad sviluppato su richiesta. Non si parte però dal codice. Si parte dal problema, dagli utenti e dal risultato che deve essere controllato.

Che cos’è un add-on su misura

Un add-on estende Archicad con funzioni progettate per uno specifico flusso di lavoro. Può affiancare attività di controllo, gestione dei dati, selezione degli elementi, migrazione, documentazione o interazione con altri sistemi.

La funzione deve rimanere coerente con l’ambiente Archicad e con il modo in cui il team lavora. Uno strumento tecnicamente sofisticato ma poco comprensibile rischia di aggiungere complessità invece di ridurla.

Quando vale la pena valutarlo

Lo sviluppo personalizzato può avere senso quando un’attività:

  • viene ripetuta con frequenza;
  • richiede molti passaggi manuali;
  • è soggetta a errori difficili da individuare;
  • applica regole chiare e verificabili;
  • coinvolge dati che devono mantenere una struttura coerente;
  • non è risolta in modo sufficiente dalle funzioni native.

Non ogni esigenza richiede programmazione. A volte una configurazione migliore di proprietà, espressioni, abachi, preferiti o template offre una soluzione più semplice da mantenere. La prima responsabilità dell’analisi è distinguere questi casi.

1. Analisi del processo reale

Il primo incontro serve a comprendere come viene svolta oggi l’attività. Quali persone sono coinvolte? Quali file e dati vengono utilizzati? Dove si verificano perdite di tempo o errori? Quali eccezioni devono essere gestite?

Un esempio concreto è più utile di una descrizione astratta. Per questo chiediamo, quando possibile, un caso rappresentativo, una sequenza di lavoro e il risultato atteso.

2. Verifica di fattibilità

L’analisi tecnica valuta se Archicad rende disponibili le informazioni e le operazioni necessarie, quali versioni devono essere considerate e quali vincoli possono influire sulla soluzione.

In questa fase si definiscono anche i limiti. Alcune funzioni possono essere realizzate direttamente; altre richiedono compromessi o non risultano appropriate. Una risposta negativa motivata è preferibile a una promessa non verificabile.

3. Specifica chiara prima dello sviluppo

Prima di programmare, traduciamo l’esigenza in comportamenti verificabili:

  • quali elementi o dati vengono letti;
  • quali condizioni devono essere controllate;
  • che cosa può essere modificato;
  • quale risultato viene mostrato o prodotto;
  • come vengono gestiti errori ed eccezioni;
  • come l’utente può verificare l’operazione.

Questa specifica riduce incomprensioni e crea una base condivisa per test e accettazione.

4. Prototipo e validazione

Quando opportuno, il progetto inizia con un prototipo circoscritto. L’obiettivo non è consegnare subito tutte le funzioni, ma verificare il passaggio più critico e capire se la soluzione produce valore nel flusso reale.

Il prototipo viene provato su casi concordati. Le osservazioni degli utenti aiutano a migliorare interfaccia, messaggi e gestione delle situazioni impreviste.

5. Sviluppo, test e rilascio

Dopo la validazione si completa lo sviluppo previsto. I test devono comprendere casi normali, dati incompleti e condizioni di errore. È importante che lo strumento comunichi chiaramente che cosa ha eseguito e che non nasconda operazioni rilevanti.

Il rilascio deve specificare versione supportata, modalità d’uso, limiti conosciuti e condizioni di assistenza concordate. Se l’add-on deve evolvere con nuove versioni di Archicad, anche la manutenzione va considerata fin dall’inizio.

Esempi di esigenze da analizzare

Senza trasformarli in prodotti già disponibili, alcuni ambiti tipici di valutazione possono includere:

  • controlli di completezza e coerenza dei dati;
  • procedure ripetitive su gruppi di elementi;
  • supporto alla migrazione di progetti e standard;
  • preparazione o verifica di esportazioni;
  • generazione di report e segnalazioni;
  • collegamenti con procedure interne dello studio.

Ogni caso richiede una verifica specifica. La fattibilità non può essere dedotta soltanto dal titolo della funzione.

Dati, sicurezza e controllo

Un add-on lavora all’interno di un processo professionale. Occorre quindi chiarire quali dati utilizza, dove vengono elaborati e se avvengono collegamenti con servizi esterni.

Privilegiamo soluzioni trasparenti e controllabili. Quando un processo può rimanere locale, questo aspetto viene considerato nell’analisi. Qualsiasi trasmissione o trattamento esterno deve essere esplicitato e valutato con il cliente.

Perché BIMticino

BIMticino nasce dall’esperienza di Tomasoni Architettura Sagl e unisce conoscenza del lavoro di progettazione, Archicad e processi BIM. Questo consente di affrontare lo sviluppo non come esercizio informatico isolato, ma come miglioramento di un flusso operativo reale.

L’obiettivo non è aggiungere funzioni per impressionare. È costruire, quando tecnicamente e commercialmente sensato, uno strumento comprensibile che riduca attrito, migliori il controllo e rimanga verificabile nel tempo.

Che cosa serve per una prima valutazione

Per iniziare sono sufficienti:

  • una descrizione dell’attività attuale;
  • un esempio concreto;
  • la versione di Archicad utilizzata;
  • il risultato desiderato;
  • la frequenza con cui si presenta il problema;
  • eventuali file dimostrativi privi di dati riservati, da condividere solo dopo aver concordato modalità e condizioni.

Da queste informazioni possiamo distinguere tra configurazione, automazione leggera, add-on personalizzato o necessità non realizzabile nelle condizioni richieste.

Hai un’esigenza specifica per Archicad?

Richiedi un’analisi preliminare di fattibilità

Serve applicarlo al tuo progetto?

Trasformiamo il metodo
in un risultato concreto.

Richiedi un confronto