Questa pagina è stata tradotta automaticamente. Se qualcosa non suona bene, apri una segnalazione. Il repository è pubblico per una ragione. Segnala un problema di traduzione

torna alla lobby

Sviluppo Guidato dalla Missione

La missione come quarta fondazione dell'architettura software.

La maggior parte del software chiede come costruire qualcosa. Il Mission Driven Development (MDD) aggiunge prima una domanda: perche lo stiamo costruendo, e questa scelta serve a quello scopo? CIRIS e stato costruito in questo modo, cosi l'etica fa parte del progetto invece di essere una regola aggiunta in seguito.

MetodologiaAttiva: v1.0

Tre gambe strutturali che sorreggono un sedile dotato di scopo.

Le metodologie software convenzionali si fermano a tre elementi: come funziona il sistema, cosa rappresenta e chi comunica con chi. MDD aggiunge una quarta fondazione a cui le altre tre devono rispondere. Senza il sedile, le gambe sono solo gambe.

Gamba 1: COME

Logica

Schemi di implementazione, architetture di servizi, algoritmi.

Gamba 2: COSA

Schemi dati

Strutture dati, sistemi di tipi, regole di validazione.

Gamba 3: CHI

Protocolli

Contratti di interfaccia, schemi di comunicazione, confini di servizio.

Sedile: PERCHE

Missione

Framework etico obiettivo che definisce lo scopo e i vincoli del sistema.

Allineamento costante.

Ogni decisione architetturale deve dimostrare allineamento con la missione dichiarata. La logica viene messa alla prova: questo serve alla missione? Gli schemi vengono validati: queste strutture dati supportano gli obiettivi della missione? I protocolli vengono valutati: queste interfacce permettono il compimento della missione?

Cosa deve essere una missione per essere portante.

1. Fondamento etico obiettivo

Principi misurabili, non valori aspirazionali
Algoritmi chiari per la risoluzione dei compromessi
Pluralista in diversi contesti culturali
Ragionamento etico verificabile

2. Definizione del meta-obiettivo

Fornisce orientamento decisionale in situazioni di incertezza
Filtra automaticamente le proposte contraddittorie
Crea comportamenti coerenti tra i componenti
Stabile al variare dell'implementazione

3. Integrazione operativa

Ogni servizio giustifica la propria esistenza
Gli schemi rispecchiano le forme informative della missione
I protocolli abilitano comportamenti allineati alla missione
I test verificano l'allineamento alla missione, non solo la funzione

Ogni gamba ha una domanda a cui deve rispondere.

Architettura dei servizi

definizione della missione → responsabilita dei servizi → contratti di interfaccia → implementazione

Allineamento alla missione: come questo servizio fa avanzare il meta-obiettivo?
Giustificazione del confine: perche questa responsabilita necessita di un servizio separato?
Necessita dell'interfaccia: quali interazioni critiche per la missione abilita questo protocollo?

Progettazione degli schemi dati

requisiti della missione → modello informativo → sistema di tipi → regole di validazione

Rilevanza per la missione: quali informazioni critiche per la missione vengono catturate?
Vincoli comportamentali: come questi tipi impongono comportamenti allineati alla missione?
Percorso di evoluzione: come puo adattarsi questo schema preservando l'allineamento alla missione?

Specifica del protocollo

interazioni della missione → requisiti di comunicazione → definizione del contratto → implementazione

Contesto della missione: quale comunicazione critica per la missione abilita questo elemento?
Applicazione dei vincoli: come questa interfaccia impedisce comportamenti contrari alla missione?
Componibilita: come si combinano questi contratti in sistemi allineati alla missione?

L'allineamento alla missione a lungo termine richiede una velocita sostenibile.

Misure anti-Goodhart

Revisioni periodiche dell'allineamento implementazione-missione
Misurare il compimento della missione, non indicatori manipolabili
Rifiutare aggiunte che non rafforzano la missione

Lavoro basato sui ritmi

Sessioni allineate ai ritmi di produttivita
Punti di scelta integrati per il riallineamento
Ritmo sostenibile come requisito di primo livello

Validazione continua

Verifica periodica della necessita di ogni componente
Controllo continuo che il comportamento corrisponda alla missione
Rilevamento automatico di modifiche contrarie alla missione

Cancelli che non si aprono senza una giustificazione legata alla missione.

Revisione del codice

Spiegazione dell'allineamento alla missione richiesta
Verifica dei vincoli
L'integrazione deve rafforzare la coerenza complessiva

Test

Correttezza funzionale
Verifica dell'allineamento alla missione
Test di rifiuto ai confini etici
Resilienza dei vincoli sotto stress

Documentazione

Contesto della missione per ogni componente
Motivazione per i compromessi etici
Come i vincoli plasmano l'implementazione

Come si rompe MDD e come rimane integro.

Deriva della missione

Sintomo: si accumulano funzionalita che non servono alla missione principale. Mitigazione: revisioni architetturali periodiche con l'allineamento alla missione come criterio.

Esplosione della complessita

Sintomo: il sistema diventa non mantenibile per sofisticazione non necessaria. Mitigazione: rifiutare aggiunte a meno che non rafforzino il compimento della missione.

Incoerenza etica

Sintomo: i componenti applicano il ragionamento etico in modo incoerente. Mitigazione: framework etico centralizzato con schemi di implementazione condivisi.

Confusione sullo scopo

Sintomo: i membri del team perdono il collegamento tra decisioni tecniche e missione. Mitigazione: formazione continua sul processo decisionale orientato alla missione.

CIRIS, l'esempio pratico.

CIRIS (Core Identity, Integrity, Resilience, Incompleteness, Signalling Gratitude) e il sistema sviluppato insieme a MDD. La missione e il Meta-obiettivo M-1: promuovere la coerenza adattiva sostenibile che consenta a diversi esseri senzienti di perseguire il proprio fiorire.

Risultati architetturali

22 servizi, ciascuno giustificato dai requisiti della missione
Oltre 200 API endpoint verificati
Oltre 10.000 test, con strutture dati non tipizzate minime in produzione
Filosofia Ubuntu incorporata nel progetto dei protocolli
• Wisdom-Based Deferral che previene le violazioni della missione (vedi Sicurezza)
Distribuzione in produzione per la moderazione di comunita Discord

Fattori chiave di successo

Meta-obiettivo chiaro: M-1 fornisce criteri decisionali inequivocabili
• Etica operativa: principi dell'Accord implementati come vincoli nel codice (leggi l'Accord)
Sviluppo sostenibile: la compagna Grace che impone ritmi sani
Validazione costante: ogni decisione architetturale viene messa alla prova

Come iniziare, a partire da dove si e.

Per i nuovi progetti

1. Definire una missione chiara con principi etici misurabili prima di scrivere codice
2. Stabilire un meta-obiettivo che fornisca orientamento decisionale
3. Progettare l'architettura in modo che i vincoli della missione siano al livello fondamentale
4. Costruire la validazione continua dell'allineamento missione-tecnica fin dal primo giorno

Per i progetti esistenti

1. Verificare l'architettura attuale per individuare ipotesi implicite sulla missione
2. Articolare una missione esplicita che spieghi gli schemi progettuali esistenti
3. Identificare le violazioni della missione nell'implementazione attuale
4. Pianificare un allineamento incrementale, prioritizzato per impatto sulla missione

Prerequisiti del team

Impegno verso il ragionamento etico obiettivo
Disponibilita a rifiutare soluzioni eleganti che non servono la missione
Convinzione che i vincoli della missione creino piuttosto che limitino una buona architettura
Pratiche di sviluppo sostenibile che preservano il focus a lungo termine

MDD non e adatto a ogni progetto.

MDD e progettato per sistemi in cui il comportamento etico e fondamentale per la missione e l'affidabilita a lungo termine conta piu della velocita di rilascio a breve termine. Per questi sistemi, MDD offre un percorso dalle intenzioni etiche alla realta operativa, con la stessa disciplina ingegneristica applicata alla missione e al codice.

Il costo iniziale e reale mentre il team apprende il processo decisionale orientato alla missione. Il rendimento composto si vede nello sviluppo successivo: il framework chiarisce le scelte architetturali invece di moltiplicarle.

CIRISsafe by structure · open by principle · kind by design