Lo sviluppo di sistemi segreti è davvero possibile?

Sarà lento, costoso e inaffidabile se funziona a tutti. Mentre in teoria i computer potrebbero nascondere alcuni dei problemi, ricorda che i computer sono costruiti, gestiti e installati dalle persone. Quindi è un software. Se non permetti alle persone di parlare tra loro, il sistema non funzionerà molto bene.

Il problema chiave è che nessuno deve essere in grado di indovinare la natura del sistema dalla conoscenza di ogni dettaglio di una sua parte. Ciò significa che le parti devono essere frammentate in alto grado (anche le parti che fanno l'integrazione). Quindi ci saranno molti problemi di comunicazione, aggravati dalla necessità di filtrare attentamente la comunicazione per evitare che qualcuno sappia troppo. Non si può avere la gente della "spia sulla webcam" che dice ai "file di archivio" le persone "questo è il video della webcam", anche accidentalmente. Ciò significa che ogni comunicazione tra sviluppatori deve essere filtrata da un essere umano. Il che rende la comunicazione lenta e poco informativa.

Il debug sarà anche un incubo poiché nessuno sviluppatore può essere autorizzato a vedere il sistema in esecuzione e ciascuna parte dovrà disporre di una propria infrastruttura di debug. Quindi tu, sviluppatore del componente "pipe un flusso audio dalla rete verso l'interfaccia utente", dovrai eseguire il debug del bug "a volte viene bloccato" senza sapere quale sia l'interfaccia utente o da dove proviene l'audio (ovvero, quale dispositivo è su ogni estremità). Sarà molto allettante per te dire "il mio diario è pulito, deve essere qualcun altro in colpa". Tutti gli altri diranno la stessa cosa.

Un altro problema è che il team "interno" diventa molto grande, e più grande è la maggiore gestione di cui ha bisogno, il che lo rende più grande. Potrebbe finire per essere più grande della squadra che avrebbe potuto sviluppare l'intero sistema inhouse.

Ho lavorato in una banca di grandi dimensioni che ha avuto problemi simili. Non tanto perché erano un'organizzazione segreta, ma solo perché erano grandi e alcune persone avevano a che fare con un sacco di sistemi. Quindi, se un trasferimento di valuta estera non è andato a buon fine, un utente povero stava guardando un programma di monitoraggio interno della banca che diceva "ERRORE: trasferimento fallito", quando il programma di trasferimento valutario internazionale dice "errore: successo" e la banca ricevente sta dicendo "abbiamo ottenuto il tuo richiesta, dove sono i soldi "... e così via. La loro soluzione era quella di avere una squadra di "addetti ai lavori", come me, che erano appaltatori ingaggiati per fornire il supporto di tre livelli all'helpdesk, ma dall'interno. Quindi avevamo i diritti di amministratore su praticamente tutto (proprio come hanno fatto Snowden e Manning), e il nostro lavoro consisteva nel sistemare le cose che gli appaltatori esterni non potevano risolvere.

Sospetto inevitabilmente che un sistema come questo fallirà perché ci sono enormi incentivi per tutti a "farlo funzionare", e pochissimi per "non dire alle persone le informazioni critiche di cui hanno bisogno per farlo funzionare". I romanzi spia lo risolvono usando le minacce per uccidere e si appella al patriottismo come incentivo a non parlare. Ma nel mondo reale le persone che pagano le bollette (governo) vogliono risultati ora, e "ma potrebbe esserci una perdita più tardi" è molto meno importante di qualunque evento sciocco abbia eccitato tutti in questo momento. Anche quando l'evento era Manning, la risposta era di dare a Snowden più accesso piuttosto che meno. Ops.

Tali cose vengono abitualmente fatte nel mondo dello sviluppo di sistemi classificati. La parola chiave è "compartimentalizzazione". Pochissime persone sanno come tutto si adatta insieme, e quindi i vari team hanno le specifiche per pezzi del sistema totale, che non l'hanno mai messo insieme.

Alcuni pezzi potrebbero essere completamente non classificati, ma la loro applicazione prevista è altamente classificata, il che significa che non ti verrà detto a cosa serve, solo che deve soddisfare queste specifiche.

Sì, è possibile. Ci dovrebbe essere un architetto (o una squadra) per l'intera faccenda che comprenderebbe tutti i pezzi e le loro interazioni a un livello molto dettagliato.

I requisiti per ogni pezzo dovrebbero essere così specifici che sarebbe quasi più semplice scrivere l'applicazione. Tutti i pezzi dovrebbero seguire lo stesso stile di sviluppo dell'applicazione ( SOLID , DRY , DI , architettura orientata ai servizi , ecc.). Tutti i pezzi dovrebbero aver concordato i protocolli di comunicazione.

Una build di questo tipo richiederebbe molto tempo, probabilmente anni a causa della separazione delle preoccupazioni e più tardi, test di integrazione .

C'è un tale esempio che posso pensare che il pubblico sia a conoscenza di: ARPAnet (ora noto come Internet). All'epoca in cui fu costruito, permise agli appaltatori governativi e alle università di comunicare facilmente con l'ARPA. (Mi sembra di ricordare di aver sentito che era un progetto segreto una volta, ma che poteva essere un po 'brutto nella mia memoria ...)

Supponiamo che il sistema fosse per la raccolta, l'archiviazione e la visualizzazione di foto spia.

• Il team di archiviazione non ha bisogno di sapere quali obiettivi zoom vengono utilizzati o come vengono elaborate le immagini.
• Il team di raccolta non ha bisogno di sapere per quanto tempo le immagini sono archiviate o come vengono elaborate. (Potrebbero esserci più di un gruppo di raccolta che non si conoscono l'un l'altro)
• Ogni team di elaborazione non ha bisogno di sapere per quanto tempo sono archiviate le immagini o dove sono state scattate le immagini. Ogni team di elaborazione non ha bisogno di sapere cosa possono fare gli altri sistemi di elaborazione.

Tuttavia, avranno tutti qualche idea di ciò che fa il sistema ma non sanno come bene lo fa, o tutti i dettagli .