Anche la programmazione Agile è & # 8230; ad hoc per i sistemi critici per la sicurezza? [chiuso]

Question

Ad esempio, sarebbe incredibilmente pericoloso farlo per il software avionico?

Nota, non capisco completamente Agile.

Answer 1

Ho lavorato su sistemi di controllo del traffico aereo utilizzando essenzialmente un processo a cascata e quei progetti avrebbero sicuramente beneficiato di pratiche agili. Non mi piace pensare a quanto di quel codice ha funzionato "per caso", senza alcun tipo di test di regressione automatizzata a livello di unità. E la cosa in anticipo è una specie di aringa rossa. Mentre è vero che i sistemi aerospaziali sono probabilmente il più vicino possibile ad avere requisiti precisi, ancora hai argomenti sul significato di requisiti ambigui che si presentano solo quando il sistema è dovrebbe essere in fase di collaudo. Oppure hai problemi di throughput che nessuno aveva considerato che si presentano alla fine del gioco a causa dell'integrazione big bang. Prima prova, soluzioni spike, integrazione continua, programmazione in coppia - Penso che tutti questi avrebbero migliorato i progetti a cui ho lavorato.

AGGIORNAMENTO: per non parlare della frequenza con cui " documenti di progettazione " erano un branco di bugie entro la fine del progetto, perché il design si è necessariamente evoluto di fronte alla realtà. Agile riconosce il fatto del design emergente, che è altrettanto reale nei progetti Waterfall come in qualsiasi altro, piuttosto che cercare di far finta di poter ottenere il design prima di iniziare a scrivere codice.

Answer 2

Lavoro nel settore aerospaziale (in particolare i satelliti) e utilizziamo un approccio ibrido perché affrontiamo due preoccupazioni diverse: requisiti del mondo reale e requisiti dei processi aziendali.

Usiamo un approccio a cascata per i requisiti dei veicoli spaziali e le sezioni critiche perché le modifiche al satellite sono lente e rare, e rovinare tutto è male.

Ma per i processi aziendali in continua evoluzione utilizziamo un approccio agile perché come volano i veicoli spaziali sono in costante cambiamento a causa delle esigenze dei clienti. Fanculo lì significa che nel peggiore dei casi l'utente ottiene risultati non altrettanto piacevoli.

Answer 3

Non ho abbastanza esperienza in quel campo (diverso da un utente di sistemi di aviazione) per formare la mia opinione veramente indipendente. Tuttavia, tutte le cose che continuo a leggere sui sistemi critici che hanno il miglior track record mi portano a credere che la cascata sia in realtà il modo migliore. È possibile perché le persone sono disposte a consentire lo spreco aggiuntivo dei requisiti di congelamento al fine di promuovere la sicurezza. I compromessi sono un po 'diversi in quel caso, immagino.

Answer 4

Determinazione dell'applicabilità delle pratiche agili ai sistemi Mission e Life-Critical

Filtri di idoneità agile

In breve, non esiste "Agile" programmazione. C'è una serie di pratiche. Alcuni si prestano meglio di altri, ma in generale qualsiasi progetto trarrà beneficio da alcune delle pratiche.

La più grande area di cui le persone si occupano in genere è la modellazione e l'architettura. Ci sono molti team là fuori che usano pratiche agili - per esempio, conosco i membri del Fun3d team con la NASA - usano pratiche agili e affrontano cose come il supporto dello Space Shuttle.

Esistono diversi gruppi dedicati a questo tipo di lavoro, quindi è possibile. Devi solo essere consapevole dei tuoi rischi - come qualsiasi altra metodologia.

Answer 5

Agile dovrebbe essere un processo disciplinato. Qualunque sia il processo, in questo caso i problemi di sicurezza devono essere affrontati in anticipo. Non vedo come l'erogazione nelle iterazioni, l'utilizzo di un sistema di generazione continua, il calcolo della frequenza di masterizzazione del programmatore, l'organizzazione di riunioni in sospeso, il coinvolgimento del cliente attivo, ecc. Influirebbe negativamente sulla sicurezza.

Answer 6

Ci sono molte considerazioni. La prima è la tua criticità per la sicurezza. Se la tua risposta è " A " o "B" (e davvero " A ") quindi assolutamente NO. Non riuscirai a fare Agile in qualsiasi forma o forma. Esistono standard di codifica molto severi, standard di documentazione e standard di processo richiesti dal software di livello A (il mio background di circa 15 anni). Questo include:

• Tracciabilità completa su / giù.
• Copertura completa delle filiali.
• Copertura multi-condizionale completa.
• I documenti di base indicati da DO-178B includono: SRD, SDD, SCI, SCMP, SDP, TQP, SCI ...

Quindi non solo devi certificare il tuo codice, design e requisiti, ma devi anche certificare set di strumenti, compilatori, apparecchiature di test automatizzate e così via.

In breve, non è un'impresa da poco e non sarà fatto con una piccola squadra. Allo stesso modo, le interfacce sono davvero solide e molto specifiche oltre che statiche. La modifica delle interfacce richiede in genere il coordinamento con più di 3 aziende (produzione Airframe, Vender 1 parla con Vender 2).

In tutta onestà, una modifica del codice di 12 righe può costare fino a $ 170.000. Naturalmente, una modifica del codice di 500 righe sarà di $ 190.000. In breve, c'è un enorme sovraccarico di processo associato al codice di livello A (molto meno con il livello B, ancor meno con C e molto poco con il livello D) che rende le piccole iterazioni molto costose; vale a dire. costa un sacco di soldi per ottenere un 777 completamente alimentato e volante per testare una piccola modifica. Anche i laboratori di test di sistema di grandi aeromobili commerciali avranno un tasso di combustione di $ 10.000 al giorno.

Ad esempio: Livello A: HUD, inversori di spinta, sistemi di alimentazione, FADEC (controllo del motore) Livello B: logica di commutazione secondaria, sistemi di comunicazione vocale. Livello C: collegamenti ai dati di volo. Livello D: nei sistemi di intrattenimento in volo.

Livello D e, forse livello C, potrebbero essere candidati per Agile.

Answer 7

Penso che dipenda da come le esigenze di sicurezza si sono integrate nel processo. Se si tratta di una serie aggiuntiva di test, ciò non è in contraddizione con la programmazione agile. Penso che i metodi agili possano aiutarti a produrre software più sicuro, perché i progetti agili tendono ad essere di qualità superiore rispetto ai progetti a cascata. È importante che la garanzia di qualità aggiuntiva installata sia utilizzata anche per i metodi agili.

Ma se le esigenze di sicurezza vengono applicate al processo di costruzione, ciò potrebbe essere in contraddizione con i metodi agili.

Answer 8

In realtà, c'è una variazione del modello a cascata chiamato modello V, che è favorito da IEC61508 per esempio. È una specie di cascata, ma con disposizioni per la reiterazione del ciclo di base del progetto. Lo scopo principale delle ripetizioni in questo caso è quello di affrontare i problemi rilevati in varie fasi del processo. L'idea di base è che più avanti nella strada incontrerai un problema, più indietro nel tuo processo dovrai andare per occuparti di e rivedere l'impatto delle tue modifiche.

Quindi non è proprio Agile, ma ... :-)

Answer 9

Potresti usare l'approccio agile, ma il primo passaggio dovrebbe includere i tuoi aspetti di sicurezza e protezione, o almeno provvedere a loro, in modo da non spararti ai piedi e finire per riscrivere il tutto. Ma sono d'accordo con Brian, probabilmente starai meglio usando l'approccio Waterfall per tali progetti.

Answer 10

Alla conferenza EuroStar 2009, Gittie Ottosen ha parlato di come agili nella loro azienda. La cosa impressionante è che questa società Systematic sta creando software per aeromobili, militari ecc. Lo fanno in conformità con CMMI 5, ISO 9001 e AQAP 150 e amp. 2110. Quindi immagino che l'agile possa essere applicato a sistemi con regole elevate. Forse prova a cercare quella presentazione e cerca di ottenere maggiori informazioni da lui.