Regulierung der Softwareindustrie [abgeschlossen]

Alle paar Jahre schlägt jemand eine strengere Regulierung für die Softwareindustrie vor.

Dieser IEEE-Artikel hat in letzter Zeit einige Aufmerksamkeit auf sich gezogen.

Wenn Softwareentwickler, die Programme für Systeme schreiben, die die Öffentlichkeit physischen oder finanziellen Risiken aussetzen, wüssten, dass sie auf ihre Kompetenz getestet werden, würde dies die Fehler und Ausfälle im Code verringern und möglicherweise ein paar Leben retten.

Ich bin skeptisch in Bezug auf Wert und Verdienst. Meiner Meinung nach scheint es ein Landraub derjenigen zu sein, die es vorgeschlagen haben.

Das Zitat, das das für mich ausmacht, ist:

Die Prüfung prüft auf Grundkenntnisse, nicht auf Beherrschung des Faches

weil die großen Ausfälle (z. B. THERAC-25 ) komplexe, subtile Probleme zu sein scheinen, die mit "Grundkenntnissen" niemals verhindert werden könnten .

Ignorieren lokaler Probleme (z. B. in einigen Gerichtsbarkeiten vorhandene Schutzmaßnahmen für den Titelingenieur):

Die Ziele sind nobel - meide die Quacksalber / Scharlatane ¹ und mache diese Unterscheidung für diejenigen, die ihre Software kaufen, offensichtlicher. Kann eine strengere Regulierung der Softwareindustrie jemals ihr ursprüngliches Ziel erreichen?

¹ Genau so, wie es die Regulierung der Ärzteschaft vorsah.

Die Ansicht, dass die Softwareingenieure in dieselbe Klassifikation wie Mediziner oder Buchhalter eingestuft werden können, ist eine ignorante Ansicht des "Problems", das sie zu lösen versuchen. Bevor ich zu diesem Thema Stellung nehme, möchte ich einige Argumente von Herrn Thornton, dem stellvertretenden Vorsitzenden der Regulierungsbehörde, der diese Rechtsvorschriften vorschlägt, aufgreifen.

"So wie praktizierende Fachkräfte wie Ärzte, Buchhalter und Krankenschwestern lizenziert sind, sollten auch Softwareingenieure", sagt Thornton. "Die Öffentlichkeit muss sich bei der Auswahl eines Auftragnehmers für das Schreiben von Software auf einen Berechtigungsnachweis verlassen können ."

- Mitch Thornton, stellvertretender Vorsitzender der IEEE-Lizenzierung und -Registrierung

Das hört sich an der Oberfläche sehr vernünftig an. Schließlich gibt es noch andere Branchen, die als "erfolgreich reguliert" gelten könnten. Mit erfolgreich reguliert meine ich, wenn Sie einen Arzt in den Gelben Seiten nachschlagen, können Sie ziemlich sicher sein, dass er oder sie eine gründliche Ausbildung an einer akkreditierten Universität absolviert und eine Reihe von Prüfungen bestanden und eine Residency abgeschlossen hat. Hier sind einige "erfolgreich regulierte" Branchen (in Bezug auf Fachpersonal).

• Anwälte
• Ärzte
• Buchhalter
• Nuklearingenieure
• Barbiere ( kein Scherz )

Schließlich wollen Sie nicht, dass irgendjemand diesen Tumor aus Ihrer Bauchspeicheldrüse entfernt oder an den Zentrifugen dieses Kernkraftwerks außerhalb der Stadt arbeitet. Warum sollten für Softwareentwickler keine ähnlichen Einschränkungen bestehen?

Nur diejenigen, deren Programme "die öffentliche Gesundheit oder die Sicherheit, das Eigentum oder die Wirtschaft gefährden" könnten, müssen getestet werden.

Dies ist eine vage Aussage und offen für eine liberale Auslegung und Anwendung. Ich könnte argumentieren, dass Apple Inc. oder Facebook integraler Bestandteil der amerikanischen Wirtschaft sind - brauche ich eine spezielle Lizenz der Regierung, um Code für sie zu schreiben, da ich den Amerikaner beschädigen könnte, wenn ich die Website mit meiner Inkompetenz herunterlasse Wirtschaft? Bei meinem letzten Job habe ich versehentlich einen Getreidespeicher mit einem fehlerhaften Cron-Job heruntergefahren - was möglicherweise die Lebensmittelversorgung gefährdet.

Mir ist klar, dass ich die eigentliche Absicht dieses Vorschlags meide. Die Idee dahinter ist, sicherzustellen, dass die Person, die den Code für das Antiblockiersystem auf Ihrem neuen Jetta schreibt, kompetent und ordnungsgemäß lizenziert ist, Code für ein Antiblockiersystem zu schreiben. Auf deinem Jetta.

Hier ist das Problem: Software-Engineering in der heutigen Zeit umfasst alles und Sie können möglicherweise nicht für jede Disziplin testen. Die Geschäftsregeln sind zu spezifisch und von Disziplin zu Disziplin zu unterschiedlich. Unser hypothetischer Ingenieur, der Code für das ABS-System auf einem Jetta schreibt, schreibt möglicherweise etwas ganz anderes für das ABS-System auf einem Elantra. Muss er sich erneut zertifizieren lassen?

Und was ist, wenn Sie für all diese abgeleiteten Disziplinen testen? Angenommen, jeder Programmierer, der auf einer E-Commerce-Website arbeitet, wird als E-Commerce-fähiger Programmierer zertifiziert. Damit? Bedeutet dies plötzlich , dass diese Programmierer und Unternehmen tatsächlich tun die notwendige Validierung und PCI - Compliance bauen? Auch wenn sie es tun - Pannen werden immer noch passieren.

Die Prüfung prüft nach Ansicht von Mitch Thornton, stellvertretender Vorsitzender des IEEE-Komitees für Lizenzierung und Registrierung, auf Grundkenntnisse und nicht auf Beherrschung des Fachs.

Hier ist der Kicker. Ein Mangel an Grundkenntnissen ist nie das Problem. Meine Anti-Blockier-Bremsen hörten nicht auf zu funktionieren, weil Chuck mit den Konzepten einer Kontrollstruktur zu kämpfen hatte. Sie versagten, weil es einen Defekt gab, bei dem sich das ABS aufgrund eines elektrischen Kurzschlusses in den Rücklichtern abschaltete und die Stromversorgung nicht richtig umgeleitet wurde. Oder so.

Die Insulinpumpensoftware, die ich geschrieben habe, hat nicht aufgehört zu funktionieren, weil mir grundlegende Fähigkeiten fehlen. es hörte auf, weil es einen Fehler bei der Messung der Insulinabgabe gab, als mein europäischer Teamkollege das metrische System verwendete und ich nicht.

Das können Sie in der Entwicklung berücksichtigen, aber niemals mit einer Zertifizierung testen .

Folgendes passiert, wenn diese "Zertifizierung" in Kraft tritt: Die Anzahl der Vorfälle bleibt exakt gleich. Warum? Weil es nichts unternimmt, um das eigentliche Problem des Ausfalls einer ABS- oder Insulinpumpe zu beseitigen .

Wie glücklich es ist, dass niemand aufgrund medizinischer Bestimmungen stirbt, niemand aufgrund finanzieller Bestimmungen durch Betrug verletzt wird, niemand sein Haus aufgrund der Wohnverordnung für ungültig erklärt bekommt, niemand aufgrund von Friseurbestimmungen einen schlechten Haarschnitt bekommt und kein Flugzeug jemals abstürzt dank Flugzeugregulierung.

Das Vorhandensein von Vorschriften bedeutet natürlich nicht, dass keine Mängel oder Mängel vorliegen. Umgekehrt bedeutet das Vorhandensein von Fehlern oder Ausfällen keine Regulierung, die diese Fehler oder Ausfälle verhindert. Softwareentwickler sind als Mitglieder der jeweiligen sicherheitskritischen Branchen bereits stark reguliert, und außerhalb dieser Branchen besteht nur ein geringer Bedarf.

Die Geschichte hat zu Recht gezeigt, dass der Unterschied zwischen einem hervorragenden und einem mittelmäßigen Handwerker mit keiner objektiven Maßnahme überprüft werden kann. Grundkenntnisse machen keinen großen Programmierer, keine große Weisheit und Erfahrung - die nicht wirklich gelehrt oder objektiv gemessen werden können - darüber, wie man diese Grundkenntnisse anwendet.

Außerdem sind diese Tests in der Regel nur ein paar Schlagworte und konkrete Vorgehensweisen und messen zunächst nichts Wesentliches.

Wenn die Softwareindustrie eine Art Gilde gründen wollte, wäre dies ein viel besserer Weg, um das Problem anzugehen. Die Zentralisierung hat jedoch nur die Macht, Spitzenleistungen zu zerstören, nicht sie zu schaffen.

Darüber hinaus würden die Probleme, die durch diese Maßnahme vermieden werden sollen, wahrscheinlich ohnehin nicht von einem Test erfasst. Wie auch immer, ich würde auch gerne sehen, wie @ThomasOwens diese Frage beantwortet.

Was wäre die Aufgabe der Regierung, zumindest nach amerikanischer Ideologie, Softwareunternehmen für alle Sachschäden verantwortlich zu machen, die durch ihre fehlerhafte oder unsichere Software verursacht werden. Dies würde die Unternehmen ermutigen, ihre eigenen Standards durchzusetzen und persönliche Verantwortung für die Angelegenheit zu übernehmen. Dies ist immer eine bessere Lösung, und es gibt keine zentralisierte Regierung, die ihre Grenzen überschreitet.

Aktualisieren

Ich habe letzte Nacht bei einem oder zehn Bier darüber nachgedacht.

Alles, was den medizinischen Bereich regulierte, war, alle Paradigmen außer einem auszulöschen. Wenn ihr Ziel darin bestand, homöopathische und naturheilkundliche Ärzte auszusondern, die von der OP freundlicherweise als "Quacksalber" bezeichnet wurden, dann war eine solche Regulierung erfolgreich. Ich bin jedoch nicht einverstanden, dass so etwas für irgendjemanden profitabel ist, außer für die Leute, die die Gesetze schreiben. Denken Sie darüber nach, was dies getan hat. Es hat die Kosten für die Gesundheitsversorgung auf ein nicht nachhaltiges Niveau getrieben, die Haftungsquote für Ärzte ohne Grenzen erheblich erhöht und die Entscheidungsfreiheit und Selbstbestimmung des Verbrauchers vom Markt genommen. Es gibt keinen Marktplatz mehr für Ideen in der medizinischen Gemeinschaft, und neue Behandlungsmethoden und Denkweisen in Bezug auf die Medizin werden jetzt unterdrückt. Darüber hinaus ist die Markteintrittsbarriere unglaublich hoch, was zu einem Mangel an gutem MD führt s. Darüber hinaus haben die Aufsichtsbehörden die Befugnis, die Versorgung mit Ärzten zu kontrollieren, so dass sie wiederum den Preis kontrollieren können, den die Ärzte zahlen.

Es gibt zwar einige Gewinne, die wir durch die ärztliche Verordnung erhalten haben, aber die Kosten sind völlig zu hoch.

Dasselbe wird Softwareentwicklern passieren, wenn eine solche Regelung verabschiedet wird. Ich kann jetzt sehen, dass die Regulierungsbehörden vorschreiben werden, dass objektorientierte Programmierung der einzige Gestaltungsstandard ist und dass die funktionalen und prozeduralen Programmierer nicht üben dürfen. Dann werden sie uns sagen, dass wir unser eigenes Gedächtnis nicht verwalten dürfen, weil es nicht sicher ist. Dann werden sie uns JAVA und C # in die Kehlen stopfen und uns sagen, dass wir es verwenden müssen, während Oracle und Microsoft fetter und glücklicher werden. Innovation wird unterbunden und Kreativität wird verboten. Microsoft und Google werden die Gesetzgebung schreiben, damit die Regeln des Marktes auf ihre eigene Rentabilität und gegen das soziale Wohlergehen ausgerichtet werden.

Lassen Sie mich auch daran erinnern, dass Computer als Hobby und akademisches Unterfangen begannen. Anders als in den Unix-Kriegen der 80er und frühen 90er hatten wir kostenlose Betriebssysteme, kostenlose Compiler, kostenlose Programme und so weiter ... Dies würde schnell ein Ende haben. Die Welt, die uns Richard Stallman, Linus Torvalds und Dennis Richtie hinterlassen haben, wird allmählich verblassen.

Kurz gesagt, habe ich es satt, mit "Ich entwerfe Ihnen eine WordPress-CMS-Site für 25 US-Dollar pro Stunde" oder mit "Jede iPhone-App für 500 US-Dollar" zu konkurrieren? Nicht wirklich warum? Weil ich verdammt gut in dem bin, was ich tue und die Kunden, die ich möchte, bereit sind, für hervorragende Leistungen zu bezahlen. Wenn ich ein Projekt selbständig oder an meinem Arbeitsplatz übernehme, gehe ich das Risiko ein, dass sich mein Kopf und mein Ruf verschlechtern. Das wird mir folgen, wohin ich gehe. Außerdem wissen die meisten Menschen, dass sie das bekommen, wofür sie bezahlen. Ein Kunde, der nur bereit ist, mir den Preis zu zahlen, den er seinem Rasenkerl zahlt, wird sowieso ein Albtraum. Wenn die Regierung die rechtliche Struktur festlegt, um die Dienstleister zum Ersatz ihrer Schäden zu zwingen, gibt es nur sehr wenige schlechte Programmierer, die noch im Außendienst beschäftigt sind.

Übrigens haben wir immer noch schlechte Ärzte, der einzige Unterschied ist, dass es nur sehr wenige Kräfte gibt, um sie vom Markt zu entfernen. Wenn sie die Verantwortung für ihre eigenen Handlungen übernehmen müssten, wären sie aus dem Geschäft, bevor sie erneut die Möglichkeit hätten, ihren Kunden inkompetenten Schaden zuzufügen.

Silicon Valley News - 31. Juni 2015

Horror: Nicht zertifizierter Programmierer hat Programmabbruch durchgeführt

"Ich werde nie wieder rennen können", gibt das Opfer aus. Die Polizei ermittelt.

Criminal: Die Lizenz von Dr. H. Acker Jr. wurde wegen falscher Verwendung des Zeigers und des Versuchs, aus der Systemdatei zu lesen, entzogen

Anwalt sagt, es wird Berufung beim Obersten Gerichtshof geben.

Ankündigungen: Cobol-Programmierer, die 1975 zertifiziert wurden, sollten sich spätestens 2025 erneut zertifizieren lassen

Die nach IEEE bestätigte Zertifizierung hat sich seitdem nicht geändert.

Anzeigen: Zertifizierung mit Magic Knowledge Stuffers, Inc. Garantiert

Bringen Sie sich in 21 Tagen das Programmieren bei.

Es gibt verschiedene Möglichkeiten, Vorschriften auf einen Beruf anzuwenden - eine genau festgelegte Wissensbasis, einen Ethikkodex, die Akkreditierung von Bildungsprogrammen, Zertifizierungen und Lizenzen sowie Fachgesellschaften, die die berufliche Entwicklung und die anderen Aspekte eines Berufs unterstützen Beruf. Das Software-Engineering weist die meisten Merkmale eines Berufs auf.

Ich stelle es mir gerne als Ausgangspunkt für das Software Engineering Body of Knowledge (SWEBOK) und den Software Engineering Code of Ethics und Professional Practice vor . Obwohl die allgemeine Akzeptanz dieser Kriterien noch recht begrenzt ist, sind sie meiner Meinung nach eine gute Grundlage, um die Arten von Dingen zu identifizieren, die jemand, der sich als Softwareentwickler ausweist, kennen sollte und wie eine solche Person in beruflicher Funktion handeln sollte. Das bedeutet nicht, dass dies strenge Regeln sind, sondern dass diese Dokumente professionelle Software-Ingenieure dahingehend anleiten, was normalerweise für die Arbeit relevant ist, zu der sie möglicherweise aufgefordert werden. Das SWEBOK wird von Zeit zu Zeit überarbeitet, um sicherzustellen, dass es relevant bleibt.

Das nächste Merkmal ist die Akkreditierung von Bildungsprogrammen. In den USA wird die Akkreditierung von Software-Engineering-Programmen von ABET durchgeführt . Sie akkreditieren auch Informatik, Informationstechnologie, Computertechnik und andere Berufe in Bezug auf Computer. ABET veröffentlicht die Anforderungen an akkreditierte Programme auf seiner Website - Software Engineering wird als Engineering-Programm betrachtet. Der Zweck der Akkreditierung besteht darin, die Kohärenz zwischen Absolventen verschiedener Ingenieurstudiengänge zu gewährleisten, zumindest in Bezug auf das im Klassenzimmer unterrichtete Fach. Es sagt nichts über die Qualität der Ausbildung aus.

Nach dem Abschluss werden durch Zertifizierung und Lizenzierung die im Unterricht (und in einigen Fällen am Arbeitsplatz) erworbenen Kenntnisse anhand der Standardkenntnisse bewertet. Obwohl die akkreditierten Schulen eine Reihe von Unterrichtsmaterialien haben, gibt es kein Maß dafür, wie gut dieses Material unterrichtet wird und wie viel die Schüler am Ende des Programms lernen. Zertifizierungen und Lizenzen bieten Methoden, um dies zu erreichen. Alle Teilnehmer legen die gleichen Prüfungen ab und weisen Kenntnisse in den verschiedenen Wissensbereichen nach, in denen der Beruf verwurzelt ist. Im Bereich Software Engineering bietet das IEEE Zertifizierungen an, die in der SWEBOK - der zertifizierten Softwareentwicklung - verwurzelt sind Associate für Senioren und Absolventen sowie Certified Software Development Professionalfür diejenigen mit Branchenerfahrung. Damit diese einen Mehrwert schaffen, muss die SWEBOK als eine gute Definition dessen, was Software-Engineering ist, akzeptiert werden.

Schließlich bewahren Fachgesellschaften die Leitdokumente für den Beruf auf, ermöglichen Konferenzen und Veröffentlichungen für den Wissens- und Ideenaustausch, schließen Lücken zwischen Wissenschaft und Industrie und so weiter. Die beiden führenden Gesellschaften sind die IEEE Computer Society und die ACM , aber es gibt auch andere Gesellschaften auf der ganzen Welt. Diese packen alles in ein hübsches kleines Bündel und helfen dabei, die richtigen Personen mit Informationen zu versorgen.

Ab hier gibt es noch andere Fragen zu stellen. Ist die Entwicklung von Software eine technische Disziplin? Bietet die Zertifizierung oder Lizenzierung einen Mehrwert für Softwareentwickler? Ist eine Zertifizierung sinnvoll?

Ich denke nicht, dass jede Softwareentwicklung die Genauigkeit einer technischen Disziplin erfordert. Das soll nicht heißen, dass eine empirische, wissenschaftliche Studie über die Wissenschaft und Technik der Erstellung von Software nicht jedem hilft - es tut es. Es gibt jedoch einen großen Unterschied zwischen der Entwicklung des neuesten Videospiels, der Entwicklung der eingebetteten Software für einen Schrittmacher oder dem Bau des nächsten Raumschiffs. Die Betonung ist bei allen unterschiedlich - zwei der drei verdienen die Aufmerksamkeit eines erfahrenen Ingenieurs. Der andere kann aus den Ingenieurspraktiken lernen, muss sich jedoch nicht darauf verlassen, um das Projekt erfolgreich abzuschließen.

Für die Zertifizierung und Lizenzierung sind anerkannte Kenntnisse erforderlich. Das SWEBOK ist ein gutes Dokument, das eine solide Grundlage bietet, aber es ist nicht weit verbreitet. Wenn Sie Ihre akademischen Programme und Zertifizierungs- / Lizenzprüfungen nicht auf etwas Konkretes stützen können, das von den Praktikern akzeptiert wird, hat das wirklich keinen Sinn. Wenn das SWEBOK-Dokument oder ein alternatives Dokument weithin akzeptiert wird (zumindest in den Bereichen, in denen strenge technische Anforderungen gestellt werden), können Zertifizierungs- oder Lizenzprüfungen verwendet werden, um das Verständnis der erforderlichen Kenntnisse zu beurteilen.

Es gibt jedoch ein Problem bei der Zertifizierung: Es ist ein Test für ein Buch. Einige Leute können gut lesen, lernen, sich merken und einen Test machen. Das bedeutet jedoch nicht, dass sie ein guter Ingenieur sind. Die Leute rutschen die ganze Zeit durch die Ritzen. Eine Zertifizierung oder Lizenz ist nur ein Schritt. Die Ausbildung und Betreuung durch andere erfahrene Ingenieure am Arbeitsplatz ist für die Pflege eines guten Praktikers unerlässlich. Darüber hinaus kann die Fähigkeit, Menschen davon abzuhalten, in kritischen Umgebungen zu praktizieren, dazu beitragen, die Risiken für Gesellschaft und Unternehmen zu verringern.

Ein gutes Buch mit einer ziemlich eingehenden Diskussion darüber ist Steve McConnells Professional Software Development: Kürzere Zeitpläne, qualitativ hochwertigere Produkte, erfolgreichere Projekte und verbesserte Karrieren .

Wenn staatliche Vorschriften verabschiedet werden, wird die Softwareindustrie in den USA erheblich schrumpfen, da die mit der Einhaltung dieser Vorschriften verbundenen Kosten höher sind, als es sich Start-ups und kleine Unternehmen leisten können.

Die Knappheit und die Kosten, die mit einem Jurastudium oder einem Doktor der Medizin verbunden sind, werden in unserer Branche mehr oder weniger sichtbar. Nicht gut, wenn die Alternative ist, dass jeder Joe möglicherweise das nächste Facebook bauen könnte.

Die Menschen machen Fehler und keine Regulierung wird das Auftreten von Katastrophen verhindern. Betrachten wir die NASA, die die mit Abstand strengsten Anforderungen an die Softwareentwicklung stellt, die dem Menschen bekannt sind. Haben sie noch Softwarefehler? (Ja, ja und oft, ja!)

Der Markt löst diese Probleme viel besser, als es Vorschriften können. Unternehmen, die Software entwickeln, die Probleme verursacht, werden von den Personen, die sie verletzt haben, zur Verantwortung gezogen. Der Rest von uns muss nicht für ihre Fehler bezahlen.

1999 gab die ACM eine Erklärung zur Lizenzvergabe heraus, als sie die IEEE SWEBOK-Arbeit weitgehend eingestellt hatte. Nach Durchsicht der öffentlich zugänglichen SWEBOK-Dokumente und der Erklärung der ACM unterstütze ich die Stellungnahme der ACM.

Werfen wir einen Blick auf den Artikel, wird jemand mit 4-6 Jahren Erfahrung benötigt, um die Prüfung abzulegen, bei der grundlegende Kenntnisse geprüft werden. Das ist mehr als lächerlich und sollte aus der Tür gelacht werden.

Die Softwarekomponenten eines Geräts sind ein Implementierungsdetail. In der Steuerungssystemindustrie waren beispielsweise alle Sicherheitsvorrichtungen fest verdrahtet, und die Menschen trauten keiner Software. Wir sehen jedoch jetzt softwarebasierte Sicherheitsgeräte wie Sicherheitsrelais und Sicherheits-SPS. Diese sind zulässig, da sie (je nach Sicherheitskategorie) noch den branchenüblichen Vorschriften für Sicherheitseinrichtungen entsprechen müssen. In einigen Fällen benötigen die Geräte daher redundante Prozessoren und redundanten Code, der von zwei verschiedenen Teams usw. geschrieben wurde.

Es ist das Produkt, das die Sicherheitsrichtlinien erfüllen muss, wenn es an die Öffentlichkeit verkauft und von ihr konsumiert werden soll. Diese Regeln ändern sich nicht, da das Produkt Software enthält. Es ist die Aufgabe des Ingenieurs, sicherzustellen, dass das Produkt alle gesetzlichen Kriterien erfüllt. Wenn es Software enthält, muss es die Software überprüfen und auf diesem Gebiet kompetent sein . Andernfalls haften sie (oder ihre Firma), wenn sie das Design genehmigt haben und sich herausstellt, dass es fehlerhaft ist.

Sie müssen nicht wirklich alle Programmierer regulieren, nur weil einige Produkte strengeren Anforderungen gerecht werden müssen. In Fällen, in denen solche Produkte Software beinhalten, benötigen Sie eine gut entwickelte technische Disziplin, mit der zuverlässig festgestellt werden kann, ob die Softwarekomponente die Anforderungen erfüllt. Wenn überhaupt, bedeutet dies das IEEE: Das relativ junge Gebiet des Software-Engineerings muss auf das Maß an Zuverlässigkeit und Vertrauen anderer Ingenieurdisziplinen ausgebaut werden.

Es hat wirklich nichts mit "Programmieren" und alles mit "Engineering" zu tun.

Dies bringt uns natürlich zurück zu der strittigen Frage des Unterschieds zwischen einem Entwickler und einem Ingenieur. Dies sind in der Regel zwei verschiedene Rollen, die sich regelmäßig überschneiden. Der Entwicklerteil bedeutet, dass Sie Software erstellen. Der technische Teil der Rolle bedeutet, dass Sie, wenn Sie das Design stempeln, die Verantwortung für die öffentliche Sicherheit übernehmen. Du kannst eins ohne das andere sein.

Software ist in der Flugzeugindustrie bereits stark reguliert. Siehe DO-178B .

Ich bin sicher, dass andere Untergruppen der Branche ihre Normen haben.

"Software" umfasst heutzutage so viel. Ich halte es für absurd, eine verbindliche umfassende Regelung zu haben.

Die Regulierung der Softwareindustrie erfolgt am besten durch Regulierung der Qualitätssicherungsprozesse.

Dies ist bereits geschehen - große Softwareunternehmen verfügen über eine Vielzahl von Testern, QS-Managern, automatisierten Testsuiten, Codeüberprüfungsprozessen, Testprozessen usw. Es gibt Unternehmen, deren gesamter Zweck darin besteht, Softwarequalitätsprüfungen bei anderen Unternehmen durchzuführen. Die Normungsorganisationen haben Richtlinien für die Qualitätssicherung und für QA-Audits.

Ein Softwareentwickler ist unternehmensintern für die Qualität seiner Arbeit verantwortlich. Ihre Kontrollen und Abwägungen finden jedoch in den Qualitätsprozessen des Unternehmens statt.

Es ist dasselbe wie die meisten modernen Versuche, "Software-bezogene Probleme" zu lösen. Diejenigen, die versuchen, Gesetze zu erlassen, wissen nur wenig über den eigentlichen Verlauf des Problems. Wenn bei der Entwicklung sicherheitskritischer Software der vorgeschriebene Prozess (und natürlich die Absicht) befolgt wird, reicht für Flugzeuge und Kernkraftwerke von medizinischen Geräten ein einziger Fehler niemals aus, um einen Ausfall zu verursachen. Ein ganzer Algorithmus kann falsch implementiert werden, ohne dass jemand Schaden nimmt.

Sowohl die FDA als auch die FTA erfordern eine Risikoanalyse und darauf aufbauend eine Minderungsstrategie. Bei der letztgenannten Strategie handelt es sich in der Regel um eine Schweizer Käse-Strategie, bei der man akzeptiert, dass eine Schadensminderung fehlerhaft ist, sodass mehrere Schadensminderungen für dasselbe Risiko angewendet werden (eine Schadensminderung kann auch für mehrere Risiken angewendet werden) eine, vielleicht zwei Scheiben zusammen, aber genug Scheiben zusammen und das ist nicht mehr möglich. Selbst wenn die Abschwächungen perfekt umgesetzt werden, führt dies nicht zu einem 100% sicheren Gerät. Wenn die Risikoanalyse falsch ist, gibt es Risiken, an die niemand gedacht hat (Jahr 2000).

Sie können alle Ingenieure testen, die Sie möchten, und Sie können sie sogar an einem bestimmten Thema testen. Dabei ist ein extrem hohes Niveau erforderlich, das jedoch von großer Bedeutung ist. Die meisten sicherheitskritischen Fehler sind Integrationsfehler. Sie sind keine Fehler im Code eines Mannes, sondern entstehen aufgrund von Fehlausrichtungen zwischen Software und Hardware zweier Softwaresysteme oder weil ein Alpha-Partikel den Programmzähler aus seiner richtigen Position geschleudert hat.

Ich habe an mehreren sicherheitskritischen Systemen mit erfahrenen und fähigen Entwicklern gearbeitet, die jeden vernünftigen Test auf ihrem Gebiet bestehen würden. Ich war noch nie an einem Projekt beteiligt, bei dem kein sicherheitskritischer Fehler aufgetreten ist. (Ich war zum Glück noch nie bei einem, bei dem das System jemals jemandem geschadet hat.)

Man kann die Scharlatane und Quacksalber niemals vollständig beseitigen, weil sie in fast allen Berufen existieren, auch in medizinischen Berufen, trotz der seit langem etablierten Praktiken und Traditionen.

Da es sich bei dieser Aussage jedoch um einen Landraub handelt, bin ich mir nicht sicher, welcher dunkle, beängstigende Oberherr aller Dinge die IT-Abteilung auf teuflische Weise seine uneingeschränkte Kontrolle und Regulierung der Softwareentwicklung plant. Wenn Sie tatsächlich über die IEEE sprechen, haben sie sicherlich einen regulatorischen Aspekt, aber die Einhaltung der IEEE-Standards erfolgt mehr oder weniger nach Belieben und nicht mit vorgehaltener Waffe. Sie versuchen, universelle Industriestandards zu entwickeln, damit wir alle dieselbe Sprache sprechen und die Effizienz auf ganzer Linie steigern.

Darüber hinaus tragen die Standards, die sie festlegen, dazu bei, gängige Praktiken zu legitimieren und die Grundlage für die Softwareentwicklung zu legen, die schließlich zu einem disziplinierteren Gebiet des Ingenieurwesens werden soll, ähnlich wie Maschinenbau oder Chemieingenieurwesen. Software kommt diesem Ziel zwar immer näher, wird jedoch als Ingenieurdisziplin wahrscheinlich nie vollständig akzeptiert.

Das Hauptproblem besteht darin, dass ein Softwareentwickler alles Mögliche tun kann, vom Schreiben eines hübschen Desktop-Widgets bis zur Implementierung von Raketenleitsystemen. In der einen ist die Schwere und die Konsequenz von Fehlern viel höher als in der anderen und erfordert daher eine streng regulierte technische Disziplin, um vernünftig, sicher und effizient vorzugehen. Dies ähnelt in etwa der Schwere eines Fehlers in einer Brücke, die falsch entworfen wurde und als Ergebnis zusammenbricht. Die Konstrukteure der Brücke müssen meine technischen Standards einhalten, um die Qualität sicherzustellen.

Ich würde es nicht als strengere Regulierung bezeichnen, sondern als Eintrittsbarriere. In dieser Hinsicht denke ich, dass es Verdienst gibt. Für mehr Qualität ist das sehr umstritten.

Derzeit kann jeder John / Jane Doe ein Programm schreiben. Es gibt keine Eintrittsbarriere. Holen Sie sich ein paar Bücher über Scripting und Web-Technologie und fangen Sie an zu hacken, oder, schlimmer noch, fangen Sie einfach an zu googeln, um herauszufinden, wie man es "macht".

Wenn wir als Ganzes entscheiden, dass es an der Zeit ist, die Marktzutrittsschranken zu erhöhen, die Branche auf einem höheren Niveau zu halten, vom Hacker / Handwerker zum Ingenieur zu werden, dann ist diese Art von Regulierung, an der ich bin, alles in allem.

Es gibt heutzutage zu viele unqualifizierte Programmierer. Unabhängig davon, ob sie auf kritischen Systemen arbeiten oder nicht, sie produzieren immer noch Code und Big Balls of Mud .

In dieser Hinsicht ist eine Selbstregulierung oder eine treffendere Schaffung von Eintrittsbarrieren eine gute Sache. Weil wir sagen, hey, Sie können nicht einfach von der Straße kommen und sich selbst als Software-Ingenieur bezeichnen. Sie müssen tatsächlich ein Niveau von Geschicklichkeit demostrieren.

Demostrating Fähigkeit ist mehr als nur einen Test oder ein "Abzeichen der Ehre". Ein Test ist nur eine Bestätigung. Wirkliche Bestätigung ist Schule, Praktikum, Lehrlingsausbildung, Mentoring unter Senioren, Üben, all dies ist ein Teil davon.

Ich kann sehen, was die IEEE zu erreichen versucht, aber zu diesem Zeitpunkt ist es eine erfolglose Übung. Die Branche verändert sich rapide, zu viel Nachfrage, um das Produkt aus der Tür zu schieben, die "Hacker" -Mentalität usw. Die Regulierung muss, wenn überhaupt, von innen kommen.

Ich habe den Artikel nicht gelesen, aber wenn es um die Frage geht, ob die Regulierung der Softwareindustrie der Menschheit zugute kommen kann, dann hängt das von den Umständen ab:

1. Die gesamte Branche umfasst eine Vielzahl von Bereichen, von denen einige lebenswichtig sind (z. B. die Kontrolle der Strahlendosis in einem medizinischen Gerät) und andere nicht (die Facebook-App "Which Muppet Are You?"). Ich kann kein Argument für eine Regulierung für Anwendungen sehen, bei denen der Einsatz niedrig ist.

2. Man sollte nicht beginnen mit gesetzlicher Regelung. Vielmehr sollte man mit einem Zertifizierungsprogramm für Entwickler beginnen. Nur wenn das Zertifizierungsprogramm einen messbaren Nutzen bringt, sollte es sich um eine gesetzliche Regelung handeln.

3. Selbst wenn ein Zertifizierungsprogramm messbare Ergebnisse liefert, ist es wahrscheinlich, dass die Industrie diese Zertifizierung aus rein geschäftlichen Gründen verlangt und wir keine gesetzlichen Vorschriften benötigen. (Aus diesem Grund gibt es Delegationen wie MCSE - Unternehmen bevorzugen es, MCSEs für die Domänen zu mieten, in denen MCSEs geschult werden.)

4. Trotzdem gibt es immer noch Bereiche, in denen es wirtschaftlich sinnvoll ist, Schaden zu verursachen (häufig handelt es sich um negative externe Effekte , manchmal sind sie das Ergebnis der Marktmacht einiger Institute). Zum Beispiel kann ein Gebiet ein einziges lokales Krankenhaus haben; In diesem Fall kann die Qualität der Back-End-Software einen großen Unterschied zum Versorgungsniveau eines Patienten ausmachen, es spielt jedoch keine Rolle, welches Krankenhaus der Patient auswählt. Das Krankenhaus hat dann nicht unbedingt viel Geschäftssinn, um in qualitativ hochwertigere Entwickler zu investieren. In diesem Fall kann es einen Fall der öffentlichen Gesundheit geben, in dem geregelt wird, welche Entwickler das Krankenhaus einstellen darf.

MEINER BESCHEIDENEN MEINUNG NACH.

Ich muss das beantworten ...

Angefangen mit dem, was Jonathan Henson sagte, und dem Eintrag von Gnat, was ich sage, ist in Ordnung. Leute, die Geld haben, können für zertifizierte Sachen bezahlen, Leute oder Länder, die kein Geld haben, können nicht für Lizenzen bezahlen (so viel für zertifizierte Sachen) ), es wird also immer noch Abtrünnige geben, wenn das in die Praxis umgesetzt wird. Auch wenn traditionelle (und nicht so traditionelle) Bereitstellungsmethoden geschlossen sind, werden die Benutzer dennoch Möglichkeiten finden, interessierten Benutzern Software bereitzustellen. Selbst wenn es darum geht, ein anderes HTTP-Protokoll oder sogar einen alternativen gesamten Netzwerkstapel zu entwickeln, besteht das Hauptaugenmerk darauf, dass Verbindungen nicht mehr erkannt werden (siehe den letzten Abschnitt für jemanden, der dies möglicherweise kann).

Auch die Idee, für etwas zu bezahlen, ist in Gefahr, da die Welt immer ärmer wird und immer mehr Menschen immer weniger Geld haben, um für Dinge zu bezahlen. Es gibt sogar Länder, die nur FOSS-Software verwenden, und zwar ohne Zertifizierung (Brasilien und Indien, aber es gibt sicher auch andere), und einige dieser Länder werden groß, wirklich groß. Und sie verwenden nicht zertifizierte Software von unbekannten Programmierern, deren Fähigkeiten unbekannt sind.

Auch wenn es irgendeine Art von Zertifizierung gibt, wird durch die Zertifizierung nur das Wissen und nicht die Ethik bestätigt. Denken Sie nur, dass einige Ärzte Organe verwenden, die auf unautorisierte Weise von Menschen entfernt wurden, sodass es auch zertifizierte Programmierer gibt, die dies tun würden keine Ethik haben und absichtlich oder unbeabsichtigt schlampigen Code schreiben. Während in den meisten FOSS-Projekten die meisten potenziell ungelernten Programmierer auch Code von anderen überprüfen und versuchen, Fehler auf eine Weise zu finden, die die Paarprogrammierung zu etwas Wenigem macht.

Was halten Sie von Hacking-Gruppen (nicht Black-Hat-Hacker-Gruppen, sondern White- oder Grey-Hat-Gruppen), die viel mehr über Sicherheit wissen und Sicherheitssoftware auf eine Weise entwickeln, die nur den spezialisiertesten Programmierern bestimmter Regierungsstellen entspricht?