Regolamento dell'industria del software [chiuso]


85

Ogni pochi anni qualcuno propone una regolamentazione più rigorosa per l'industria del software.

Questo articolo IEEE ha attirato recentemente l'attenzione sull'argomento.

Se gli ingegneri del software che scrivono programmi per sistemi che espongono il pubblico a rischi fisici o finanziari sapessero che sarebbero stati testati in base alla loro competenza, il pensiero va avanti, ridurrebbe i difetti e i fallimenti del codice e forse salverebbe alcune vite nell'affare.

Sono scettico sul valore e sul merito di questo. A mio avviso sembra un accaparramento di terre da parte di chi lo ha proposto.

La citazione che conferma questo per me è:

L'esame metterà alla prova le conoscenze di base, non la padronanza della materia

poiché i grandi fallimenti (ad es. THERAC-25 ) sembrano essere questioni complesse e sottili che la "conoscenza di base" non sarebbe mai sufficiente a prevenire.

Ignorando eventuali problemi locali (come le protezioni esistenti del titolo Engineer in alcune giurisdizioni):

Gli obiettivi sono nobili: evitare i ciarlatani / ciarlatani 1 e rendere questa distinzione più evidente a coloro che acquistano il loro software. Una regolamentazione più rigorosa dell'industria del software potrà mai raggiungere il suo obiettivo originale?

1 Esattamente come previsto dalla regolamentazione della professione medica.


3
Spero che Thomas Owens risponda a questo perché so che ha la risposta perfetta.
maple_shaft

3
Per quanto mi piacerebbe sapere cosa hanno da dire le persone su questo argomento, mi sembra una domanda di discussione che si adatta perfettamente al formato di domande e risposte di Stack Exchange.
PersonalNexus

12
Francamente, sono a favore di un emendamento costituzionale che crea una separazione tra tecnologia e stato, dato che il governo sembra incapace quando regola la tecnologia (vedi anche SOPA)
JohnFx,

3
Come può un'industria essere regolata quando cambia ogni giorno?
Jon Raynor,

4
Non sono molte queste situazioni "abbastanza buone" che in seguito causano errori spesso la colpa della direzione / marketing che dice: "SHIP SHIP SHIP!"
Aren

Risposte:


105

L'opinione che gli ingegneri del software possano essere inseriti nella stessa classificazione dei professionisti medici o dei contabili è una visione ignorante del "problema" che stanno cercando di risolvere. Prima di esprimere il mio parere al riguardo, analizziamo alcuni degli argomenti di Thornton, che è vicepresidente dell'organismo di regolamentazione che propone questa legislazione.

"Proprio come professionisti professionisti come dottori, commercialisti e infermieri sono autorizzati, così dovrebbero gli ingegneri del software", afferma Thornton. "Il pubblico deve poter fare affidamento su una sorta di credenziale quando sceglie un appaltatore per scrivere software".

- Mitch Thornton, vicepresidente della licenza e registrazione IEEE

Sembra molto ragionevole in superficie. Dopotutto, ci sono altri settori che potrebbero essere considerati "regolati con successo". Se regolamentato con successo intendo che se si guarda un medico nelle pagine gialle si può essere ragionevolmente certi che abbia avuto un'istruzione approfondita in un'università accreditata e che abbia superato una serie di esami e completato una residenza. Ecco alcune industrie "regolate con successo" (in termini di personale professionale).

  • avvocati
  • medici
  • Accountants
  • Ingegneri nucleari
  • Barbieri ( non scherzando )

Dopotutto, non vuoi che nessuno rimuova quel tumore dal tuo pancreas o lavori sulle centrifughe di quella centrale nucleare appena fuori città. Perché non dovrebbero esistere restrizioni simili per gli ingegneri del software?

Solo coloro i cui programmi potrebbero "mettere in pericolo la salute pubblica o la sicurezza, la sicurezza, la proprietà o l'economia dovranno essere testati",

Questa è una dichiarazione vaga e aperta all'interpretazione e all'applicazione liberali. Potrei sostenere che Apple Inc. o Facebook sono parte integrante dell'economia americana - ho bisogno di una licenza speciale da parte del governo per scrivere il codice per loro adesso, dal momento che se abbasso il sito con la mia incompetenza potrei danneggiare l'americano economia? Nel mio ultimo lavoro ho accidentalmente chiuso un montacarichi con un cron job difettoso, probabilmente mettendo in pericolo la fornitura di cibo.

Mi rendo conto che sto evitando l'intento reale di questa proposta. L'idea alla base è quella di garantire che la persona che scrive il codice per il sistema di frenatura antibloccaggio sul nuovo Jetta sia competente e debitamente autorizzato a scrivere il codice per un sistema di frenatura antibloccaggio. Sulla tua Jetta.

Ecco il problema: l'ingegneria del software al giorno d'oggi comprende tutto e non è possibile testare per ogni disciplina. Le regole aziendali sono troppo specifiche e troppo diverse da disciplina a disciplina. Il nostro ipotetico ingegnere che scrive il codice per il sistema ABS su una Jetta potrebbe scrivere qualcosa di completamente diverso per il sistema ABS su una Elantra. Deve essere ricertificato?

E se testassi tutte queste discipline derivate? Supponiamo per un momento che ogni programmatore che lavora su un sito web di e-commerce venga certificato come programmatore abilitato al commercio elettronico. Così? Questo significa che improvvisamente questi programmatori e le aziende effettivamente fare la convalida necessaria e costruire per la conformità PCI? Anche se lo fanno, continueranno a verificarsi problemi.

L'esame metterà alla prova le conoscenze di base, non la padronanza della materia, secondo Mitch Thornton, vicepresidente del Comitato di licenza e registrazione IEEE.

Ecco il calciatore. La mancanza di conoscenze di base non è mai il problema. I miei freni antibloccaggio non hanno smesso di funzionare perché Chuck stava lottando con i concetti di una struttura di controllo. Hanno fallito perché c'è stato un problema tecnico in cui l'ABS si è spento a causa di un cortocircuito elettrico nelle luci posteriori e l'alimentazione non è stata reindirizzata correttamente. O qualcosa.

Il software del microinfusore per insulina che ho scritto non ha smesso di funzionare perché mi mancano le competenze di base; si è fermato perché c'era un bug nel modo in cui ho misurato la dispensazione di insulina quando il mio compagno di squadra europeo ha usato il sistema metrico e non l'ho fatto.

È qualcosa di cui puoi tenere conto nello sviluppo, ma non potresti mai provare con una certificazione .

Ecco cosa accadrà se questa "certificazione" entrerà in vigore: il numero di incidenti rimarrà esattamente lo stesso. Perché? Perché non fa nulla per eliminare l' effettivo problema di un guasto alla pompa dell'ABS o dell'insulina.


33
+1 risposta eccellente. Mi piace soprattutto: "La mancanza di conoscenze di base non è mai il problema".
Jonathan Henson,

4
Ottima risposta, ma tiene conto solo dell'ingegneria del software dal punto di vista dei programmatori. La vera ingegneria del software è in realtà uno sforzo di squadra che coinvolge molteplici competenze e discipline, analisti aziendali, garanzia di qualità, gestione dei progetti, ecc. e test impropri. Il test dell'OP menziona qualcosa del genere? Ovviamente non perché è per i programmatori.
maple_shaft

3
Aggiungerei però che penso che l'intera idea IEEE sia spazzatura per cominciare. Tutto quello che il governo deve fare è risolvere il problema. Ritenere tutti i responsabili di eventuali danni arrecati a chiunque. Solo questo risolverà il problema
Jonathan Henson,

16
Non sono d'accordo con "La mancanza di conoscenze di base non è mai il problema". In realtà spesso è il problema. Con quale frequenza i nuovi programmatori (o quelli più vecchi) trascurano la sanificazione dell'input? Verifica del caso angolare? Per i sistemi fisici, potrei leggere un sensore. Può essere acceso o spento. Che dire di rotto? Come può dirlo il mio software? Allora cosa devo fare al riguardo? Presumi che sia acceso o spento? Questi tipi di cose "di base" sono effettivamente comunemente in discussione.
sabato

3
@JonathanHenson Poi di nuovo, considero la maggior parte dei casi di iniezione SQL esattamente questo - privo di conoscenze di base ... ma nel complesso, un buon post. +1.
Jeff Ferland,

72

Che fortuna che nessuno muoia grazie alla regolamentazione medica, nessuno sia ferito dalla frode grazie alla regolamentazione finanziaria, nessuno ha la sua casa preclusa grazie alla regolamentazione degli alloggi, nessuno ha mai avuto un brutto taglio di capelli grazie alla regolamentazione del barbiere e nessun aereo si è mai schiantato grazie alla regolamentazione dell'aeromobile.

Ovviamente, la presenza della regolamentazione non implica l'assenza di difetti o guasti. Al contrario, la presenza di difetti o guasti non implica una regolamentazione che prevenga tali difetti o guasti. Gli ingegneri del software sono già altamente regolamentati come membri delle rispettive industrie critiche per la sicurezza e al di fuori di quelle industrie c'è poco bisogno.


10
+1 per "Gli ingegneri del software sono già fortemente regolamentati come membri delle rispettive industrie critiche per la sicurezza e al di fuori di quelle industrie c'è poco bisogno"
Trevor Boyd Smith

3
Non mi piace il tono cinico di questa risposta. Stai dicendo che non c'è bisogno di regolamentazione, dal momento che la regolamentazione non risolve mai alcun problema?
Fred Foo,

8
Sto dicendo oltre un certo punto, più regolamentazione raramente risolve più problemi. È logico imporre alcune pratiche di test del software su macchine in grado di uccidere le persone. Affrontare un altro esame di certificazione delle competenze di base alla fine di un corso di laurea non fa che aumentare la burocrazia.
Karl Bielefeldt,

2
@larsmans Concordo con Karl, se il governo ha a che fare con un missile o qualcosa in cui crede che debbano essere imposti standard elevati, lascia che assumano i propri programmatori e ingegneri secondo lo standard che scelgono. Il settore privato non dovrebbe comunque fare soldi con il rischio pubblico - questo è il fascismo. Un settore privato non dovrebbe essere autorizzato a mettere in pericolo il pubblico all'inizio. Le persone che sanno di cosa hanno bisogno di meglio, sono le persone che corrono il rischio. Lascia che gestiscano i loro affari. E sì, so che Lockheed-Martin e simili fanno questo. Non dovrebbero essere autorizzati a farlo però.
Jonathan Henson,

3
Considerando il numero di grandi società che hanno perso i dettagli della carta di credito nell'ultimo anno o giù di lì, direi che non esiste un'autoregolamentazione soddisfacente. Si potrebbe sostenere che questi sistemi non sono critici per la vita, ma l'effetto sulle tasche delle persone può essere altrettanto duro a seguito di questi incidenti.
HorusKol

32

La storia ha dimostrato, a mio avviso, che la differenza tra un eccellente artigiano e uno mediocre non può essere verificata con alcuna forma di misura oggettiva. La conoscenza di base non costituisce un grande programmatore, la saggezza e l'esperienza - che non possono davvero essere insegnate o misurate obiettivamente - su come applicare tale conoscenza di base.

Inoltre, questi test di solito finiscono per essere solo alcune parole d'ordine e procedure concrete e non riescono a misurare nulla di sostanziale per cominciare.

Se l'industria del software volesse sviluppare una corporazione di qualche tipo, sarebbe un modo molto migliore per affrontare il problema. Tuttavia, la centralizzazione ha solo il potere di distruggere l'eccellenza: non di crearla.

Inoltre, i problemi che questa misura sta cercando di prevenire probabilmente non verrebbero comunque colti da un test. Ad ogni modo, mi piacerebbe anche che @ThomasOwens rispondesse a questo.

Quale sarebbe il ruolo del governo, almeno dall'ideologia americana, sarebbe quello di ritenere le società di software responsabili di eventuali danni alla proprietà causati dal loro software difettoso o insicuro. Ciò incoraggerebbe le aziende a far rispettare i propri standard e ad assumersi la responsabilità personale in merito. Questa è sempre una soluzione migliore e non contiene un governo centralizzato che supera i suoi limiti.

Aggiornare

Ci stavo pensando un po 'di più ieri sera davanti a una birra o dieci.

Tutto ciò che ha regolato il campo medico è stato quello di sterminare tutti i paradigmi tranne uno. Se il loro obiettivo era quello di estromettere i medici omeopatici e naturopatici, che gli operatori chiamavano gentilmente "ciarlatani", tale regolamentazione avrebbe avuto successo. Tuttavia, non sono d'accordo sul fatto che una cosa del genere sia vantaggiosa per chiunque, tranne per le persone che scrivono la legislazione. Pensa a ciò che ha fatto. Ha portato i costi dell'assistenza sanitaria a livelli insostenibili, ha aumentato notevolmente i livelli di responsabilità per i medici di famiglia e ha rimosso dal mercato tutta la potenza di scelta e l'autodeterminazione del consumatore. Non esiste più un mercato per le idee nella comunità medica e ora vengono soppressi nuovi trattamenti e modi di pensare alla medicina. Inoltre, la barriera per l'ingresso nel campo è incredibilmente alta e, di conseguenza, abbiamo una carenza di buoni MD S. Inoltre, le agenzie di regolamentazione hanno il potere di controllare l'offerta di medici in modo che possano a loro volta controllare il prezzo pagato dai medici.

Ci sono davvero alcuni guadagni che abbiamo ricevuto dalla regolamentazione medica, ma i costi sono del tutto troppo alti.

La stessa cosa accadrà agli ingegneri del software se tale regolamento verrà approvato. Ora posso vederlo, le agenzie di regolamentazione decideranno che la programmazione orientata agli oggetti è l'unico standard di progettazione e che i programmatori funzionali e procedurali non potranno esercitare. Quindi inizieranno a dirci che non ci è permesso di gestire la nostra memoria perché non è sicura. Quindi riempiranno JAVA e C # di tutte le nostre gole e ci diranno che dobbiamo usarlo mentre Oracle e Microsoft diventano più grassi e più felici. L'innovazione sarà soffocata e la creatività sarà messa fuori legge. Microsoft e Google scriveranno la legislazione, quindi le regole del mercato saranno orientate verso la propria redditività e contro il benessere sociale.

Inoltre, vorrei ricordare a tutti che i computer hanno iniziato come hobby e impegno accademico. Oltre alle guerre Unix degli anni '80 e dei primi anni '90, abbiamo avuto sistemi operativi gratuiti, compilatori gratuiti, programmi gratuiti e così via ... Questo sarebbe finito rapidamente. Il mondo che Richard Stallman, Linus Torvalds e Dennis Richtie hanno lasciato in eredità a noi svaniranno gradualmente dall'esistenza.

In sintesi, mi stanco di dover competere con "Ti designerò un sito CMS wordpress per $ 25 l'ora" o i ragazzi "qualsiasi app per iPhone per $ 500"? Non proprio perché? Perché sono dannatamente bravo in quello che faccio e i clienti che desidero sono disposti a pagare per l'eccellenza. Quando intraprendo un progetto in modo indipendente o presso la mia sede di servizio, corro il rischio che i miei f * & ^ up si verifichino sulla mia testa e reputazione. Questo mi seguirà ovunque io vada. Inoltre, molte persone sanno che ottengono ciò per cui pagano. Un cliente che è disposto a pagarmi solo il prezzo che paga per il suo ragazzo in erba sarà comunque un incubo da affrontare. Se il governo fissasse la struttura legale per costringere i fornitori di servizi a risarcire i loro danni, allora ci sarebbero pochissimi programmatori malvagi che ancora avevano un impiego nel settore.

A proposito, abbiamo ancora dei dottori cattivi, l'unica differenza è che ci sono pochissime forze per rimuoverli dal mercato. Se dovessero assumersi la responsabilità delle proprie azioni, sarebbero fuori dal mercato prima di avere un'altra possibilità di provocare il caos incompetente sui loro clienti.


8
Sebbene sia d'accordo con la spinta generale della tua affermazione, trovo che la parte più interessante di essa sia la prima frase. Tu caratterizzi lo sviluppo del software come un mestiere , che è esattamente il problema . Non si costruisce un ponte sospeso; si progetta un ponte sospeso per garantirne l'efficacia e la sicurezza. Gli ingegneri del software si comportano ancora più come artigiani che ingegneri, indipendentemente dal titolo che gli dai.
Eric Lippert,

4
@Jonathan Henson: Certamente no, in generale. Molti negozi segnano zero sul Joel Test. ( joelonsoftware.com/articles/fog0000000043.html ) Per quanto riguarda se non dovrebbero , questa è una decisione commerciale non una decisione morale. Tutte queste cose costano denaro: tanti soldi. Se stai costruendo un sistema di controllo dell'aeromobile, a lungo termine è vantaggioso sostenere tali costi; se stai costruendo un gioco su Facebook, forse no.
Eric Lippert,

1
No, un timbro da architetto è buono come un timbro PE. Direi certamente che dobbiamo incorporare molte cose che attualmente vengono chiamate discipline ingegneristiche, proprio come fa un architetto. L'architettura è ancora considerata più come un mestiere. Comunque, anche l'ingegneria è probabilmente un mestiere, quindi potrei semplicemente sminuzzare le parole sul nulla.
Jonathan Henson

1
@Andy, suppongo che dovremmo chiedere lo scambio di stack per cambiare il titolo di questo sito in softwareengineers.stackexchange.com :)
Jonathan Henson

1
@JonathanHenson Offend? Assolutamente no, non preoccuparti! :) Avrei dovuto rendere un po 'più chiaro che ho pubblicato il link solo perché era stranamente coincidente con il tuo commento.
yannis,

23

Silicon Valley News - 31 giugno 2015

Horror: il programmatore non certificato ha interrotto il programma

"Non potrò mai più correre", dice la vittima. La polizia sta indagando.

Criminale: la licenza del Dr. H. Acker Jr. è stata revocata per un uso errato del puntatore e tenta di leggere dal file di sistema

L'avvocato afferma che ci sarà appello alla Corte suprema.

Annunci: i programmatori Cobol certificati nel 1975 dovrebbero ricertificare entro il 2025

La certificazione IEEE confermata non è cambiata da allora.

Annunci: certificazione garantita con Magic Knowledge Stuffers, Inc

Insegnati a programmare in 21 giorni.


Sto cercando di decidere se questa è una risposta completa insite o un commento umoristico. (Entrambi forse?)
Lyndon White

@Oxinabox La data del 31 giugno è divertente
moscerino

"Insegnati a programmare tra 10 giorni!" hehe
BЈовић

20

Esistono diversi modi per applicare la regolamentazione a qualsiasi professione: un corpus ben definito di conoscenze, un codice etico, l'accreditamento dei programmi di istruzione, la certificazione e le licenze e le società professionali che supportano lo sviluppo professionale, nonché gli altri aspetti di un professione. L'ingegneria del software ha la maggior parte delle caratteristiche di una professione.

Mi piace pensarlo come a partire dal Software Engineering Body of Knowledge (SWEBOK) e dal Software Engineering Codice Etico e Pratica Professionale . Sebbene l'accettazione comune di questi sia ancora abbastanza limitata, penso che servano da buona base per identificare i tipi di cose che qualcuno che si identifica come ingegnere del software dovrebbe avere una conoscenza e di come tale persona dovrebbe agire a titolo professionale. Ciò non significa che queste siano regole rigide, ma piuttosto questi documenti guidano gli ingegneri software professionisti su ciò che è tipicamente rilevante per il lavoro che potrebbe essere loro chiesto di fare. SWEBOK viene periodicamente rivisto per garantire che rimanga rilevante.

La prossima caratteristica è l'accreditamento dei programmi di istruzione. Negli Stati Uniti, l'accreditamento dei programmi di ingegneria del software è gestito da ABET . Accreditano inoltre l'informatica, l'informatica, l'ingegneria informatica e altre professioni informatiche. ABET pubblica i propri requisiti di programmi accreditati sul proprio sito Web: l'ingegneria del software è considerata un programma di ingegneria. Lo scopo dell'accreditamento è garantire la coerenza tra i laureati di diversi programmi di ingegneria, almeno in termini di materia insegnata in classe. Non dice nulla sulla qualità dell'educazione.

Dopo la laurea, le certificazioni e le licenze vengono utilizzate per valutare le conoscenze apprese in classe (e, in alcuni casi, sul posto di lavoro) rispetto agli organismi di conoscenza standard. Sebbene le scuole accreditate abbiano un corpus definito di materiale da insegnare, non c'è una misura di quanto bene questo materiale sia insegnato e di quanto gli studenti apprendano al completamento del programma. La certificazione e la licenza forniscono metodi per farlo - tutti fanno gli stessi esami e dimostrano una conoscenza nei vari corpi di conoscenza su cui è radicata la professione. Nell'ingegneria del software, l'IEEE offre certificazioni che sono radicate nello SWEBOK - lo sviluppo software certificato Associato per senior e neolaureati e Professionista di sviluppo software certificatoper quelli con esperienza nel settore. Perché questi aggiungano valore, richiede l'accettazione di SWEBOK come una buona definizione di cosa sia l'ingegneria del software.

Infine, le società professionali mantengono i documenti guida per la professione, facilitano conferenze e pubblicazioni per lo scambio di conoscenze e idee, colmano le lacune tra università e industria, e così via. Le due società principali sono l' IEEE Computer Society e l' ACM , ma ci sono altre società in tutto il mondo. Questi racchiudono tutto in un piccolo pacchetto e aiutano a fornire informazioni alle persone giuste.

Da qui, ci sono altre domande da porre. Lo sviluppo del software è una disciplina ingegneristica? La certificazione o la licenza aggiungono valore agli ingegneri del software? La certificazione è utile?

Non penso che tutto lo sviluppo del software abbia bisogno del rigore di una disciplina ingegneristica. Questo non vuol dire che uno studio empirico e scientifico della scienza e dell'ingegneria della costruzione di software non aiuti tutti, ma lo fa. Tuttavia, c'è una grande differenza tra lo sviluppo dell'ultimo videogioco, lo sviluppo del software incorporato per un pacemaker o la costruzione del prossimo veicolo spaziale. L'enfasi è diversa su tutti loro: due dei tre meritano l'attenzione di un ingegnere esperto. L'altro può imparare dalle pratiche di ingegneria, ma non deve fare affidamento su di esse per completare con successo il progetto.

La certificazione e la licenza richiedono un corpus di conoscenze accettato. SWEBOK è un buon documento che fornisce solide basi, ma non è ampiamente accettato. A meno che tu non possa basare i tuoi programmi accademici e gli esami di certificazione / licenza su qualcosa di concreto che sarebbe accettato dai professionisti, allora non ha davvero senso. Se lo SWEBOK o il documento alternativo vengono ampiamente accettati (almeno in quei campi che richiedono il rigore dell'ingegneria), è possibile utilizzare esami di certificazione o di licenza per valutare la comprensione delle conoscenze richieste.

Tuttavia, c'è un evidente problema con la certificazione: è un test su un libro. Alcune persone sono brave a leggere, imparare, memorizzare e fare un test. Tuttavia, ciò non significa che siano un buon ingegnere. Le persone scivolano continuamente attraverso le fessure. Una certificazione o licenza è solo un singolo passaggio. Sul lavoro, la formazione e il tutoraggio da parte di altri ingegneri esperti sono obbligatori per governare un buon professionista. Inoltre, la capacità di impedire alle persone di praticare in ambienti critici può anche aiutare a mitigare i rischi per la società e le imprese.

Un buon libro con una discussione abbastanza approfondita di questo è lo sviluppo del software professionale di Steve McConnell : programmi più brevi, prodotti di qualità superiore, progetti di maggior successo e carriera migliorata .


Sono un po 'sotto il tempo, quindi se ho perso qualcosa o qualcosa non ha senso, colpiscimi e lo aggiusterò. Grazie ragazzi.
Thomas Owens

"due dei tre meritano l'attenzione di un abile ingegnere" hai ragione, le
astronavi

+1 grazie per aver aggiunto il tuo contributo in merito. Spero che ti sentirai meglio.
Jonathan Henson,

12

Se vengono approvati i regolamenti governativi, l'industria del software negli Stati Uniti si contraerà in modo significativo, poiché i costi associati al rispetto di tali regolamenti saranno superiori a quelli che le startup e le piccole imprese possono permettersi.

La scarsità e i costi associati a una laurea in giurisprudenza o un dottore in medicina diventeranno più o meno visibili nel nostro settore. Non va bene quando l'alternativa è che ogni joe potrebbe potenzialmente costruire il prossimo Facebook.

Le persone commettono errori e nessuna quantità di regolamentazione impedirà il verificarsi di catastrofi. Si consideri la NASA, che ha di gran lunga i requisiti più severi per lo sviluppo di software conosciuti dall'uomo. Hanno ancora bug del software? (Sì, sì, e molte volte, sì!)

Il mercato risolve questi problemi molto meglio dei regolamenti. Le aziende che creano software che causano problemi sono ritenute responsabili dalle persone ferite. Il resto di noi non deve pagare per i propri errori.


8
Un'aggiunta fantastica a questa risposta sarebbe un elenco di società di software esistenti che probabilmente non sarebbero state avviate se queste normative fossero in vigore. Microsoft e Facebook sono un buon inizio, dal momento che una certificazione richiederebbe probabilmente una laurea (quasi ogni professione che inizia con i test aggiunge un requisito di laurea se non iniziano con uno).
psr

1
@maple_shaft, l'IMO che confronta medici / avvocati con l'ingegneria del software non è valido. I campi sono troppo diversi per essere confrontati (vedere la risposta di Jarrod Nettles per capire perché non è possibile confrontare l'ingegneria del software con medici / avvocati).
Trevor Boyd Smith,

1
@maple_shaft - Stai insinuando che la certificazione migliorerebbe la qualità dell'ingegneria. Sono abbastanza scettico che sarebbe il risultato. Penso che il tempo trascorso a studiare per la maggior parte dei test sia tempo non dedicato all'apprendimento di una migliore ingegneria.
psr

4
Credo che tutti stiano ipotizzando in modo inequivocabile che i dottori e gli avvocati in licenza migliorino effettivamente la qualità di dottori e avvocati. Sono molto scettico di questa ipotesi. Tutto ciò che la licenza garantisce è che i dottori e gli avvocati possano addebitare tariffe esorbitanti e non c'è niente di dannato che chiunque possa fare al riguardo. A tal proposito, sono tutto per gli ingegneri del software di licenza. Non migliorerà la qualità del software di un solo punto, ma renderà sicuramente molti di noi sviluppatori di software ricchi. Haha quando il governo arresta il ragazzo delle superiori per aver praticato software senza una licenza.
Dunk

1
@maple_shaft che dipende interamente dalla natura del fallimento - Facebook non risponde non è fondamentale (oltre a influenzare le tasche degli investitori) - Facebook rendere tutti i tuoi dati personali e messaggi privati ​​disponibili per ogni utente di Internet è una questione diversa. Inoltre, le app / i giochi che prendono i dettagli della carta di credito (come su Facebook) rilasciando accidentalmente i dettagli della carta di credito avrebbero gravi ripercussioni.
HorusKol

11

Nel 1999, l'ACM ha rilasciato una dichiarazione sulle licenze quando ha in gran parte ritirato dal lavoro IEEE SWEBOK. Dopo aver esaminato i documenti SWEBOK disponibili pubblicamente e la dichiarazione ACM, sostengo l'opinione dell'ACM.

Guardando l'articolo, qualcuno con 4-6 anni di esperienza è tenuto a sostenere l'esame, che verifica le conoscenze di base. Questo è al di là del ridicolo, e dovrebbe essere riso fuori dalla porta.


10

I componenti software di un dispositivo sono dettagli di implementazione. Ad esempio, nel settore dei sistemi di controllo, tutti i dispositivi di sicurezza erano cablati e le persone non si fidavano del software. Tuttavia, ora vediamo dispositivi di sicurezza basati su software come relè di sicurezza e PLC di sicurezza. Questi sono ammessi perché devono ancora soddisfare le normative del settore per i dispositivi di sicurezza (a seconda della categoria di sicurezza). Pertanto, in alcuni casi i dispositivi richiedono processori ridondanti e codice ridondante scritto da due team diversi, ecc.

È il prodotto che deve soddisfare le linee guida di sicurezza se deve essere venduto e consumato dal pubblico. Tali regole non cambiano perché il prodotto contiene software. È compito dell'ingegnere assicurarsi che il prodotto soddisfi tutti i criteri normativi e, se contiene software, devono rivedere il software ed essere competenti in quel campo . In caso contrario, essi (o la loro società) sono responsabili se hanno approvato il progetto e risulta essere difettoso.

Non è necessario regolare tutti i programmatori solo perché alcuni prodotti devono soddisfare requisiti più severi. Nei casi in cui tali prodotti coinvolgono software, è necessaria una disciplina ingegneristica ben sviluppata in grado di determinare in modo affidabile che il componente software soddisfi i requisiti. Semmai, questo è ciò che significa IEEE: il campo relativamente giovane dell'ingegneria del software deve essere sviluppato al livello di affidabilità e fiducia di altre discipline ingegneristiche.

Non ha davvero nulla a che fare con la "programmazione" e tutto con la "ingegneria".

Questo, ovviamente, ci riporta alla controversa questione della differenza tra uno sviluppatore e un ingegnere. Questi sono generalmente due ruoli diversi che si sovrappongono regolarmente. La parte sviluppatore significa che devi creare un software. La parte ingegneristica del ruolo significa che se stampi il progetto ti stai assumendo la responsabilità della sicurezza pubblica. Si può essere uno senza l'altro.


5
+1 IMHO, ciò a cui stai davvero accennando è che la regolamentazione deve essere sul prodotto, non sugli ingegneri. Ad esempio, le normative (approvazioni) necessarie per i sistemi di allarme antincendio e antintrusione assicurano il funzionamento del software, non la capacità degli ingegneri che lo hanno scritto. (Molte delle normative sembrano molto simili a quelle dei sistemi interamente realizzati con circuiti elettronici.)
jwernerny,

8

Il software è già strettamente regolato nel settore aeronautico. Vedi DO-178B .

Sono sicuro che altri sottogruppi del settore hanno le loro norme.

Il "software" comprende così tanto in questi giorni. Penso che sarebbe assurdo avere una regolamentazione onnicomprensiva obbligatoria.


4

La regolamentazione dell'industria del software viene effettuata al meglio attraverso la regolamentazione dei processi di garanzia della qualità.

Questo è già stato fatto: le grandi aziende di software hanno una moltitudine di tester, responsabili del controllo qualità, suite di test automatizzate, processi di revisione del codice, processi di test, e così via. Ci sono aziende il cui intero scopo è eseguire audit di qualità del software su altre società. Le organizzazioni standard hanno linee guida per il controllo qualità e per gli audit di controllo qualità.

All'interno di un'azienda, un ingegnere del software è responsabile della qualità del proprio lavoro. I loro controlli ed equilibri, tuttavia, sono nei processi di qualità dell'azienda.


2
Questa è esattamente la mia opinione. L'industria aeronautica ha regole severe per la programmazione del controllo e dei test di qualità. Le aziende devono controllare le proprie risorse informative e implementare ulteriori test e revisioni. Penso che questi siano i giorni bui del software, perché così tanti continuano a tagliare gli angoli non facendo ciò che sanno essere la cosa giusta da fare, e gli sviluppatori stessi non sono abbastanza per cambiare il settore.
Tjaart

Un grande punto: il software che esegue il dispositivo è tanto la responsabilità dell'azienda per un'ingegneria buona e sicura quanto lo è con l'ingegneria industriale.
Jarrod Nettles,

3

È lo stesso dei tentativi più moderni di risolvere "problemi relativi al software". Coloro che cercano di legiferare hanno scarsa conoscenza del corso principale del problema. Se si segue il processo prescritto (e ovviamente l'intenzione) durante lo sviluppo di software critici per la sicurezza, sia per gli aeromobili che per gli impianti nucleari di apparecchiature mediche un singolo bug non sarà mai sufficiente per causare un guasto. Un intero algoritmo può essere implementato in modo errato senza che nessuno venga danneggiato.

FDA e FTA richiedono entrambe un'analisi del rischio e sulla base di una strategia di mitigazione. La seconda è di solito una strategia di formaggio svizzero in cui si accetta che qualsiasi mitigazione sia difettosa, quindi vengono applicate più mitigazioni per lo stesso rischio (una mitigazione potrebbe anche essere applicata a diversi rischi) ogni mitigazione è come una fetta di formaggio svizzero che è possibile esaminare uno, forse due fette messe insieme ma unite abbastanza fette e questo non è più possibile. Anche quando le mitigazioni sono implementate perfettamente, ciò non si traduce in un equipaggiamento sicuro al 100%. Se l'analisi del rischio non è corretta, ci saranno rischi a cui nessuno ha pensato (Y2K).

Puoi testare gli ingegneri tutto ciò che desideri, puoi anche testare sull'argomento e richiedere un livello estremamente alto, ma sarebbe molto importante. La maggior parte degli errori critici per la sicurezza sono errori di integrazione. Non sono errori nel codice di un uomo, ma sorgono a causa di disallineamenti tra software e hardware di due sistemi software o perché una particella alfa ha eliminato il contatore del programma dalla sua posizione corretta.

Sono stato su diversi sistemi critici per la sicurezza con sviluppatori altamente esperti e capaci, che avrebbero superato qualsiasi test ragionevole nel loro campo. Non ho mai partecipato a un progetto in cui non abbiamo riscontrato un errore critico per la sicurezza. (Per fortuna non sono mai stato su uno in cui il sistema non ha mai fatto del male a nessuno)


1
+1 - Per: "La maggior parte degli errori critici per la sicurezza sono errori di integrazione". In effetti, con tutto il processo che attraversiamo non c'è quasi mai un errore di codifica. Il 99,98% delle volte è un problema di comprensione tra diversi moduli e dispositivi su come dovrebbero funzionare.
Dunk

@Dunk grazie in realtà è un qoute di Levison. Un fatto che intendevo includere nel testo, ma sembra che mi sia dimenticato :)
Rune FS

2

Non si possono mai eliminare completamente ciarlatani e ciarlatani perché esistono in quasi tutte le professioni, anche le professioni mediche nonostante le pratiche e le tradizioni consolidate.

Dato che questa affermazione è una conquista del territorio, non sono sicuro di quale oscuro e spaventoso signore di tutte le cose che l'IT stia pianificando diabolicamente il suo controllo e la regolamentazione senza limiti dello sviluppo del software. Se in effetti stai parlando dell'IEEE hanno sicuramente un aspetto normativo ma la conformità con gli standard IEEE è più o meno a piacimento, e non sotto minaccia. Stanno cercando di sviluppare standard di settore universali in modo che tutti parliamo la stessa lingua e aumentino l'efficienza su tutta la linea.

Inoltre, gli standard da essi stabiliti aiutano a legittimare le pratiche comuni e gettare le basi per lo sviluppo del software per diventare infine un campo più disciplinato di ingegneria, non diversamente dall'ingegneria meccanica o dall'ingegneria chimica. Mentre il software si sta avvicinando a tale obiettivo, probabilmente non sarà mai completamente accettato come disciplina ingegneristica.

Il problema principale è che uno sviluppatore di software potrebbe fare qualsiasi cosa, dalla scrittura di un grazioso widget desktop all'implementazione di sistemi di guida missle. In uno la gravità e la conseguenza dell'errore sono molto più elevate dell'altra e quindi richiedono una disciplina ingegneristica rigorosamente regolata per un approccio ragionevole, sicuro ed efficiente. Questo è molto simile alla gravità dell'errore in un bridge che è stato progettato in modo errato e di conseguenza ha il collasso. I progettisti del ponte devono rispettare i miei standard tecnici per garantire la qualità.


4
Di solito tali regolamenti finiscono per essere anche requisiti legali. Ad esempio, ingegneria civile che richiede un PE
Paul Nathan,

@PaulNathan Un buon punto, motivo per cui la naturale progressione verso una disciplina universalmente accettata inizia dall'autoregolamentazione (es. MPAA) e alla fine porta alla regolamentazione per legge (consigli di stato, FCC, ecc ...)
maple_shaft

7
Non credo che lo sviluppo del software sia pronto per l'autoregolamentazione, o addirittura vicino ad esso. Francamente, l'idea che i "veri ingegneri" abbiano una "vera qualità" è una specie di scherzo per me. Le navette spaziali sono esplose, i razzi si sono accesi, i ponti sono caduti, gli edifici sono crollati ... ecc. Sarebbe bello provare a imporre la qualità dall'alto, ma ahah.
Paul Nathan,

1
Il confronto tra ingegneria meccanica e ingegneria del software mi fa chiedere quale sarebbe l'analogo ingegneristico del mondo reale a qualcosa come i moderni sistemi operativi.
FrustratedWithFormsDesigner

1
@maple_shaft - il problema principale sarà che non puoi usare Linux / BSD / grep / vi / Firefox ecc. perché non sono scritti da un SE ufficiale. Mentre qualcuno con un certificato MSCE in VB starà bene.
Martin Beckett,

1

Non lo definirei un regolamento più rigoroso, ma invece barriere all'ingresso. A tal proposito, penso che ci sia merito. Per una maggiore qualità, è molto discutibile.

Attualmente qualsiasi John / Jane Doe può scrivere un programma. Non c'è barriera per l'ingresso. Raccogli alcuni libri su scripting e tecnologia web e inizia a hackerare, o peggio inizia a cercare su Google come "farlo".

Quando, nel complesso, decidiamo forse che è il momento di aumentare le barriere all'ingresso, di mantenere il settore a uno standard più elevato, di evolvere da hacker / artigiano a ingegnere, quel tipo di regolamentazione in cui sono completamente d'accordo.

Oggi ci sono troppi individui non qualificati che programmano. Che funzionino o meno su sistemi critici, stanno ancora producendo codice, producendo ancora Big Balls of Mud .

A tale proposito, l'autoregolamentazione o la creazione più appropriata di barriere all'ingresso è una buona cosa. Perché stiamo dicendo, ehi, non puoi semplicemente venire fuori dalla strada e chiamarti Ingegnere del Software. In realtà devi dimostrare un livello di abilità.

Dimostrare abilità non è solo fare un test o ottenere un "distintivo d'onore". Un test è solo una validazione. La vera convalida è la scuola, il tirocinio, l'apprendistato, il tutoraggio per gli anziani, la pratica, ne fanno parte.

Vedo cosa sta cercando di ottenere l'IEEE, ma a questo punto è un esercizio infruttuoso. L'industria cambia rapidamente, troppa domanda per spingere il prodotto fuori dalla porta, mentalità da "hacker", ecc. Il regolamento deve venire dall'interno se non del tutto.


Dò +1 perché dovrebbe esserci un modo per tenere fuori il riff-raff da alcuni tipi di sistemi. Tuttavia, do -1 perché la maggior parte dei software oggi può essere adeguatamente sviluppata dagli hacker e impedire loro di essere in grado di fornire quel servizio al fine di contenere i costi è contro l'interesse pubblico. Allo stesso modo, lo stesso vale per avvocati e medici. Il 90% di ciò che fanno può essere gestito in modo abbastanza conveniente e altrettanto competente da persone con qualifiche minori. Tuttavia, con le leggi di oggi sono liberi di ingannare il pubblico a volontà.
Dunk

Le competenze non dovrebbero essere valutate durante il processo di assunzione. Oh aspetta, le risorse umane assumono persone basate su credenziali cartacee (che non dimostrano le conoscenze applicabili nello sviluppo del software) e le persone delle risorse umane non sanno assolutamente nulla delle esigenze / requisiti per sviluppare software. Doppio fallimento ...
Evan Plaice,

0

Non ho letto l'articolo, ma se la domanda è se la regolamentazione del settore del software possa giovare all'umanità, penso che dipenda dalle circostanze:

  1. L'industria nel suo insieme comprende una vasta gamma di domini, alcuni dei quali critici per la vita (ad es. Controllo del dosaggio delle radiazioni in un dispositivo medico) e altri che non lo sono (l'app di Facebook "Quale Muppet sei?"). Non riesco a vedere alcun argomento per la regolamentazione per le applicazioni in cui la posta in gioco è bassa.

  2. Non si dovrebbe iniziare con la regolamentazione legale. Piuttosto, si dovrebbe iniziare con un programma di certificazione per gli sviluppatori. Solo se il programma di certificazione produce alcuni benefici misurabili dovrebbe esserci una questione di regolamentazione legale.

  3. Anche se un programma di certificazione produce risultati misurabili, è probabile che l'industria standardizzerebbe la richiesta di questa certificazione per ragioni strettamente commerciali e non avremmo bisogno di una regolamentazione legale. (Ecco perché esistono delegazioni come MCSE : le aziende preferiscono assumere MCSE per i domini in cui sono formati MCSE.)

  4. Detto questo, restano ancora domini in cui è logico causare danni agli affari (spesso si tratta di esternalità negative , a volte sono il risultato del potere di mercato di alcune istituzioni). Ad esempio, un'area può avere un singolo ospedale locale; in questo caso, la qualità del software di back-end può fare un'enorme differenza rispetto al livello di assistenza che un paziente riceve, ma non fa molta differenza in quale ospedale il paziente sceglie. L'ospedale quindi non ha necessariamente molto business case per investire in sviluppatori di qualità superiore. In questo caso, potrebbe esserci un caso di sanità pubblica per regolamentare gli sviluppatori che l'ospedale può assumere.

A PARER MIO.


0

Devo rispondere a questo ...

A partire da quello che ha detto @JonathanHenson e dall'entrata di @gnat, quello che dico è ok, le persone che hanno soldi possono pagare per roba certificata, le persone o i paesi che non hanno soldi non possono pagare per le licenze (così tanto per roba certificata ), quindi ci saranno comunque dei rinnegati se questo si metterà in pratica. Anche se i metodi di consegna tradizionali (e non così tradizionali) sono chiusi, le persone troveranno comunque modi per fornire software agli utenti interessati. Anche se significa sviluppare un altro protocollo HTTP o anche uno stack di rete intero alternativo, focalizzato solo a rendere le connessioni non rilevabili (vedi l'ultimo paragrafo, per qualcuno che potrebbe essere in grado di farlo).

Inoltre, l'idea di pagare per qualcosa è a rischio, poiché il mondo sta diventando sempre più povero, quindi sempre più persone avranno sempre meno soldi per pagare le cose, ci sono persino paesi che usano solo il software FOSS, senza alcun certificazione (vengono in mente Brasile e India, ma ce ne sono sicuramente altri), e alcuni di questi paesi stanno diventando grandi, davvero grandi. E usano software non certificato realizzato da programmatori sconosciuti, la cui abilità è sconosciuta.

Inoltre, anche se esiste un qualche tipo di certificazione, la certificazione certificherà solo la conoscenza, non l'etica, basti pensare che alcuni medici usano organi che vengono rimossi in modo non autorizzato dalle persone, quindi ci sarebbero anche programmatori certificati che non avere etica e scrivere codice sciatto intenzionalmente o non intenzionalmente. Mentre nella maggior parte dei progetti FOSS, i programmatori potenzialmente non qualificati riesaminano anche il codice di altri e cercano di trovare errori, in un modo che rende la programmazione di coppia, qualcosa di poco.

Alla fine, cosa ne pensi dei gruppi di hacker (non gruppi di hacker black hat, ma gruppi di cappello bianco o grigio), che sanno molto di più sulla sicurezza e sviluppano software di sicurezza in un modo che corrisponde solo ai programmatori più specializzati di determinati dipartimenti governativi.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.