it-swarm.com.de

Regulierung der Softwareindustrie

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

Dieser IEEE-Artikel hat in letzter Zeit einige Aufmerksamkeit auf dieses Thema gelenkt.

Wenn Softwareentwickler, die Programme für Systeme schreiben, die die Öffentlichkeit physischen oder finanziellen Risiken aussetzen, wissen, 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 gegenüber dem Wert und dem Verdienst davon. Meiner Meinung nach sieht es aus wie ein Landraub durch diejenigen, die es vorgeschlagen haben.

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

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

weil die großen Fehler (z. B. THERAC-25 ) komplexe, subtile Probleme zu sein scheinen, deren "Grundwissen" niemals ausreichen würde, um sie zu verhindern.

Ignorieren lokaler Probleme (z. B. bestehender Schutz des Titelingenieurs in einigen Ländern):

Die Ziele sind edel - vermeiden Sie die Quacksalber/Scharlatane1 und machen Sie diese Unterscheidung für diejenigen, die ihre Software kaufen, offensichtlicher. Kann eine strengere Regulierung der Softwareindustrie jemals ihr ursprüngliches Ziel erreichen?

1 Genau so, wie es die Regulierung der Ärzteschaft vorhatte.

85
Flexo

Die Ansicht, dass die Softwareentwickler in dieselbe Klassifizierung wie Mediziner oder Buchhalter eingeteilt werden können, ist eine ignorante Ansicht des "Problems", das sie zu lösen versuchen. Bevor ich meine Meinung dazu wiedergebe, lassen Sie uns einige der Argumente von Herrn Thornton, dem stellvertretenden Vorsitzenden der Regulierungsbehörde, die diese Gesetzgebung vorschlägt, zusammenfassen.

"So wie praktizierende Fachkräfte wie Ärzte, Buchhalter und Krankenschwestern lizenziert sind, sollten auch Software-Ingenieure lizenziert werden", sagt Thornton. "Die Öffentlichkeit muss sich bei der Auswahl eines Auftragnehmers zum Schreiben von Software auf eine Art Berechtigungsnachweis verlassen können."

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

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

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

Schließlich möchten 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 Sicherheit, das Eigentum oder die Wirtschaft gefährden könnten, müssen getestet werden“.

Dies ist eine vage Aussage und offen für liberale Auslegung und Anwendung. Ich könnte das Argument vorbringen, dass Apple Inc. oder Facebook integrale Bestandteile der amerikanischen Wirtschaft sind - brauche ich eine spezielle Lizenz der Regierung, um jetzt Code für sie zu schreiben, denn wenn ich das herunterbringe Bei meiner Inkompetenz könnte ich der amerikanischen Wirtschaft schaden? Bei meinem letzten Job habe ich versehentlich einen Getreideheber mit einem fehlerhaften Cron-Job abgeschaltet - was möglicherweise die Lebensmittelversorgung gefährdet.

Mir ist klar, dass ich die eigentliche Absicht dieses Vorschlags vermeide. 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, um Code für ein Antiblockiersystem zu schreiben. Auf deinem Jetta.

Hier ist das Problem: Software-Engineering umfasst heutzutage alles und man kann unmöglich 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? Nehmen wir für einen Moment an, dass jeder Programmierer, der an einer E-Commerce-Website arbeitet, als E-Commerce-fähiger Programmierer zertifiziert wird. Damit? Bedeutet dies plötzlich, dass diese Programmierer und Unternehmen tatsächlich do die erforderliche Validierung durchführen und die PCI-Konformität aufbauen? Selbst wenn dies der Fall ist, treten immer noch Störungen auf.

Laut Mitch Thornton, stellvertretender Vorsitzender des IEEE Licensure and Registration Committee, wird die Prüfung auf Grundkenntnisse und nicht auf die Beherrschung des Fachs geprüft.

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

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

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

Folgendes passiert, wenn diese "Zertifizierung" in Kraft tritt: Die Anzahl der Vorfälle bleibt genau gleich. Warum? Weil es nichts unternimmt, um das tatsächliche Problem eines ABS- oder Insulinpumpenausfalls zu beseitigen.

104
Jarrod Nettles

Wie glücklich, dass niemand dank medizinischer Vorschriften stirbt, niemand durch Finanzvorschriften durch Betrug verletzt wird, niemand sein Haus aufgrund von Wohnungsvorschriften abgeschottet hat, niemand dank Friseurvorschriften jemals einen schlechten Haarschnitt bekommt und kein Flugzeug jemals abstürzt dank Flugzeugregulierung.

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

72
Karl Bielefeldt

Die Geschichte hat zutreffend gezeigt, dass der Unterschied zwischen einem hervorragenden und einem mittelmäßigen Handwerker nicht mit objektiven Maßstäben geprüft werden kann. Grundkenntnisse machen einen großen Programmierer, eine Weisheit und Erfahrung - die nicht wirklich objektiv gelehrt oder gemessen werden können - nicht dazu, wie man dieses Grundwissen anwendet.

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

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

Darüber hinaus würden die Probleme, die diese Maßnahme zu verhindern versucht, wahrscheinlich sowieso nicht von einem Test erfasst. Wie auch immer, ich würde auch gerne sehen, wie @ThomasOwens diese Frage beantwortet.

Zumindest aus amerikanischer Sicht würde die Regierung die Aufgabe haben, Softwareunternehmen für 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 enthält keine zentralisierte Regierung, die ihre Grenzen überschreitet.

pdate

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

Alles, was die Regulierung des medizinischen Bereichs tat, war, alle Paradigmen außer einem auszurotten. Wenn ihr Ziel darin bestand, homöopathische und naturheilkundliche Ärzte auszusondern, die der o.p. freundlicherweise als "Quacksalber" bezeichnet, war eine solche Regulierung erfolgreich. Ich bin jedoch nicht der Meinung, dass so etwas für jeden rentabel ist, außer für die Leute, die die Gesetzgebung schreiben. Überlegen Sie, was dies getan hat. Es hat die Kosten für die Gesundheitsversorgung auf ein nicht nachhaltiges Niveau getrieben, das Haftungsniveau für M.D.s erheblich erhöht und die gesamte Entscheidungsbefugnis und Selbstbestimmung des Verbrauchers vom Markt genommen. Es gibt keinen Marktplatz mehr für Ideen in der medizinischen Gemeinschaft, und neue Behandlungen und Denkweisen über Medizin werden jetzt unterdrückt. Darüber hinaus ist die Eintrittsbarriere für das Feld unglaublich hoch, und infolgedessen mangelt es uns an guten M.D.s. Darüber hinaus haben die Regulierungsbehörden die Befugnis, die Versorgung mit Ärzten zu kontrollieren, so dass sie wiederum den Preis kontrollieren können, den Ärzte erhalten.

Es gibt zwar einige Gewinne, die wir aus der medizinischen Verordnung erhalten haben, aber die Kosten sind völlig zu hoch.

Dasselbe wird Softwareentwicklern passieren, wenn eine solche Regelung verabschiedet wird. Ich kann es jetzt sehen, die Regulierungsbehörden werden entscheiden, dass objektorientierte Programmierung der einzige Standard für das Design ist und 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 Java und C # alle unsere Kehlen runterdrücken und uns sagen, dass wir es verwenden müssen, während Oracle und Microsoft dicker und glücklicher werden. Innovation wird unterdrückt und Kreativität wird verboten. Microsoft und Google wird die Gesetzgebung schreiben, damit die Regeln des Marktes auf ihre eigene Rentabilität und auf das soziale Wohlergehen ausgerichtet sind.

Lassen Sie mich auch alle daran erinnern, dass Computer als Hobby- und akademisches Unterfangen angefangen haben. Abgesehen von den Unix-Kriegen der 80er und frühen 90er Jahre hatten wir kostenlose Betriebssysteme, kostenlose Compiler, kostenlose Programme usw. Dies würde schnell zu Ende gehen. Die Welt, die Richard Stallman, Linus Torvalds und Dennis Richtie uns hinterlassen haben, wird allmählich verschwinden.

Zusammenfassend kann ich sagen, dass ich es satt habe, mit "Ich werde Ihnen eine wordpress CMS-Site für 25 US-Dollar pro Stunde" oder der "iPhone-App für 500 US-Dollar") konkurrieren zu müssen? 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 zahlen. Wenn ich ein Projekt unabhängig oder an meinem Arbeitsplatz übernehme, gehe ich das Risiko meiner Probleme ein Mein eigener Kopf und Ruf. Das wird mir folgen, wohin ich auch 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 Rasenmenschen zahlt, wird ein Albtraum Wenn die Regierung die rechtliche Struktur festlegte, um die Dienstleister zu zwingen, ihre Schäden zu kompensieren, würde es nur sehr wenige schlechte Programmierer geben, die noch eine Anstellung vor Ort hatten.

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

32
Jonathan Henson

Silicon Valley News - 31. Juni 2015

Horror: Nicht zertifizierter Programmierer hat Programm abgebrochen

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

Krimineller: Lizenz von Dr. H. Acker Jr. wegen falscher Verwendung des Zeigers und Versuchen, aus der Systemdatei zu lesen, widerrufen

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 von IEEE bestätigte Zertifizierung hat sich seitdem nicht geändert.

Anzeigen: Zertifizierung garantiert mit Magic Knowledge Stuffers, Inc.

Bringen Sie sich das Programmieren in 21 Tagen bei.

23
gnat

Es gibt verschiedene Möglichkeiten, die Regulierung auf jeden Beruf anzuwenden - einen genau definierten Wissensbestand, einen Ethikkodex, die Akkreditierung von Bildungsprogrammen, die Zertifizierung und Lizenzierung sowie Fachgesellschaften, die die berufliche Entwicklung unterstützen, sowie die anderen Aspekte eines Berufs Beruf. Software-Engineering hat die meisten Merkmale eines Berufs.

Ich stelle es mir gerne so vor, als würde es mit dem Software Engineering Body of Knowledge (SWEBOK) und dem Software Engineering Code of Ethics and Professional Practice beginnen. Obwohl die allgemeine Akzeptanz dieser Dinge noch recht begrenzt ist, denke ich, dass sie als gute Grundlage dienen, um die Arten von Dingen zu identifizieren, über die jemand, der sich als Softwareentwickler identifiziert, Bescheid wissen sollte und wie eine solche Person beruflich handeln sollte. Das bedeutet nicht, dass dies harte Regeln sind, sondern dass diese Dokumente professionellen Software-Ingenieuren zeigen, was für die Arbeit, zu der sie möglicherweise aufgefordert werden, normalerweise relevant ist. 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 Computerberufe. ABET veröffentlicht ihre Anforderungen an akkreditierte Programme auf ihrer Website - Software-Engineering wird als Engineering-Programm betrachtet. Der Zweck der Akkreditierung besteht darin, die Kohärenz zwischen Absolventen verschiedener Ingenieurprogramme sicherzustellen, zumindest in Bezug auf die im Klassenzimmer unterrichteten Fächer. Es sagt nichts über die Qualität der Ausbildung aus.

Nach Abschluss des Studiums werden Zertifizierung und Lizenzierung verwendet, um das im Klassenzimmer (und in einigen Fällen am Arbeitsplatz) erlernte Wissen anhand der Standardkenntnisse zu bewerten. Obwohl die akkreditierten Schulen über ein definiertes Material verfügen, das unterrichtet werden soll, gibt es kein Maß dafür, wie gut dieses Material unterrichtet wird und wie viel die Schüler nach Abschluss des Programms lernen. Zertifizierung und Lizenzierung bieten Methoden, um dies zu erreichen - jeder legt die gleichen Prüfungen ab und weist Kenntnisse in den verschiedenen Wissensbeständen nach, in denen der Beruf verwurzelt ist. In der Softwareentwicklung bietet das IEEE Zertifizierungen an, die im SWEBOK verwurzelt sind - das Certified Software Development Associate für Senioren und Absolventen und Certified Software Development Professional für Personen mit Branchenerfahrung. Damit diese einen Mehrwert schaffen, muss das SWEBOK als eine gute Definition dessen, was Software-Engineering ist, akzeptiert werden.

Schließlich pflegen Fachgesellschaften die Leitdokumente für den Beruf, ermöglichen Konferenzen und Veröffentlichungen zum Austausch von Wissen und Ideen, 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 andere Gesellschaften auf der ganzen Welt. Diese packen alles in ein schönes kleines Bündel und helfen dabei, Informationen an die richtigen Personen zu liefern.

Von hier aus 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 Strenge einer technischen Disziplin erfordert. Das heißt nicht, dass eine empirische, wissenschaftliche Untersuchung der Wissenschaft und Technik des Bauens 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 Raumfahrzeugs. Die Betonung ist bei allen unterschiedlich - zwei der drei verdienen die Aufmerksamkeit eines erfahrenen Ingenieurs. Der andere kann aus technischen Praktiken lernen, muss sich jedoch nicht auf diese verlassen, um das Projekt erfolgreich abzuschließen.

Die Zertifizierung und Lizenzierung erfordert ein anerkanntes Wissen. Das SWEBOK ist ein gutes Dokument, das eine solide Grundlage bietet, aber nicht allgemein akzeptiert wird. Wenn Sie Ihre akademischen Programme und Zertifizierungs-/Lizenzprüfungen nicht auf etwas Konkretes stützen können, das von den Praktikern akzeptiert wird, hat dies wirklich keinen Sinn. Wenn das SWEBOK oder ein alternatives Dokument allgemein akzeptiert wird (zumindest in den Bereichen, in denen ein hohes Maß an Engineering erforderlich ist), können Zertifizierungs- oder Lizenzprüfungen verwendet werden, um das Verständnis der erforderlichen Kenntnisse zu beurteilen.

Es gibt jedoch ein eklatantes Problem bei der Zertifizierung - es ist ein Test für ein Buch. Einige Leute können gut lesen, lernen, auswendig lernen 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 einziger Schritt. Die Ausbildung und Betreuung durch andere erfahrene Ingenieure am Arbeitsplatz ist obligatorisch, um einen guten Praktiker zu pflegen. Darüber hinaus kann die Fähigkeit, Menschen daran zu hindern, in kritischen Umgebungen zu praktizieren, auch dazu beitragen, die Risiken für Gesellschaft und Unternehmen zu verringern.

Ein gutes Buch mit einer ziemlich ausführlichen Diskussion darüber ist Steve McConnells Professionelle Softwareentwicklung: Kürzere Zeitpläne, qualitativ hochwertigere Produkte, erfolgreichere Projekte und verbesserte Karrieren .

20
Thomas Owens

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 sich Startups 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.

Menschen machen Fehler, und keine Regulierung verhindert das Auftreten von Katastrophen. Betrachten Sie die NASA, die bei weitem die strengsten Anforderungen an die Softwareentwicklung hat, die dem Menschen bekannt sind. Haben sie noch Softwarefehler? (Ja, ja und oft ja!)

Der Marktplatz löst diese Probleme viel besser als es die 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.

12
George Stocker

1999 gab die ACM eine Erklärung zur Lizenzierung heraus, als sie sich weitgehend aus der IEEE SWEBOK-Arbeit zurückzog. Nach Durchsicht der öffentlich zugänglichen SWEBOK-Dokumente und der ACM-Erklärung unterstütze ich die Meinung der ACM.

Bei einem Blick auf den Artikel muss jemand mit 4-6 Jahren Erfahrung die Prüfung ablegen, bei der das Grundwissen geprüft wird. Das ist mehr als lächerlich und sollte aus der Tür gelacht werden.

11
Paul Nathan

Die Softwarekomponenten eines Geräts sind ein Implementierungsdetail. In der Branche der Steuerungssysteme waren beispielsweise alle Sicherheitsvorrichtungen fest verdrahtet, und die Leute vertrauten der Software nicht. Wir sehen jetzt jedoch softwarebasierte Sicherheitsvorrichtungen wie Sicherheitsrelais und Sicherheits-SPS. Diese sind zulässig, da sie noch den Branchenvorschriften für Sicherheitsvorrichtungen entsprechen müssen (abhängig von der Sicherheitskategorie). 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 dieser konsumiert werden soll. Diese Regeln ändern sich nicht, da das Produkt Software enthält. Es ist Aufgabe des Ingenieurs, sicherzustellen, dass das Produkt alle gesetzlichen Kriterien erfüllt. Wenn es Software enthält, muss er die Software überprüfen nd auf diesem Gebiet kompetent sein. Wenn dies nicht der Fall ist, haften sie (oder ihre Firma), wenn sie das Design genehmigt haben und es sich als fehlerhaft herausstellt.

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

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

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

10
Scott Whitlock

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

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

"Software" umfasst heutzutage so viel. Ich denke, es wäre absurd, eine verbindliche allumfassende Regelung zu haben.

8

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 Standardorganisationen haben Richtlinien für die Qualitätssicherung und für Qualitätssicherungsprüfungen.

In einem Unternehmen ist ein Softwareentwickler für die Qualität seiner Arbeit verantwortlich. Ihre Checks and Balances befinden sich jedoch in den Qualitätsprozessen des Unternehmens.

4
Bringer128

Es ist dasselbe wie bei den meisten modernen Versuchen, "softwarebezogene Probleme" zu lösen. Diejenigen, die versuchen, Gesetze zu erlassen, haben wenig Kenntnis über den Grundverlauf des Problems. Wenn Sie bei der Entwicklung sicherheitskritischer Software den vorgeschriebenen Prozess (und natürlich die Absicht) befolgen, sei es, dass bei Flugzeugen, Kernkraftwerken medizinischer Geräte ein einziger Fehler niemals ausreicht, um einen Fehler zu verursachen. Ein ganzer Algorithmus kann falsch implementiert werden, ohne dass einer beschädigt wird.

FDA und FTA erfordern beide eine Risikoanalyse und darauf basierend eine Minderungsstrategie. Letzteres ist normalerweise eine Schweizer Käsestrategie, bei der man akzeptiert, dass eine Schadensminderung fehlerhaft ist, sodass mehrere Schadensminderungen für dasselbe Risiko angewendet werden (eine Schadensminderung kann auch auf mehrere Risiken angewendet werden). Jede Schadensminderung ist wie eine Scheibe Schweizer Käse, durch die man schauen kann 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 (Y2K).

Sie können die Ingenieure testen, was Sie wollen. Sie können sogar Themen testen und benötigen ein extrem hohes Niveau, aber es wäre sehr wichtig. Die meisten sicherheitskritischen Fehler sind Integrationsfehler. Sie sind keine Fehler im Code eines Mannes, sondern entstehen aufgrund von Fehlausrichtungen zwischen Software und Hardware von zwei Softwaresystemen oder weil ein Alpha-Partikel den Programmzähler aus seiner richtigen Position geworfen hat.

Ich war auf mehreren sicherheitskritischen Systemen mit sehr erfahrenen und fähigen Entwicklern, die jeden vernünftigen Test auf ihrem Gebiet bestehen würden. Ich war noch nie in einem Projekt, in dem wir keinen sicherheitskritischen Fehler hatten. (Ich war zum Glück noch nie auf einem, bei dem das System jemals jemandem Schaden zugefügt hat.)

3
Rune FS

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

Da diese Aussage jedoch ein Landraub ist, bin ich mir nicht sicher, welcher dunkle, beängstigende Oberherr aller Dinge die IT teuflisch seine uneingeschränkte Kontrolle und Regulierung der Softwareentwicklung plant. Wenn Sie tatsächlich über das 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 können.

Darüber hinaus tragen die von ihnen festgelegten Standards dazu bei, gängige Praktiken zu legitimieren und die Grundlage für die Softwareentwicklung zu schaffen, um schließlich zu einem disziplinierteren Bereich des Ingenieurwesens zu werden, ähnlich wie im Maschinenbau oder im Chemieingenieurwesen. Während sich Software diesem Ziel nähert, wird sie wahrscheinlich nie als Ingenieurdisziplin allgemein anerkannt sein.

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

2
maple_shaft

Ich würde es nicht als strengere Regulierung bezeichnen, sondern als Eintrittsbarrieren. In dieser Hinsicht denke ich, dass es Verdienst gibt. Für eine höhere 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 Skripte und Web-Technologie und fangen Sie an, sich zu hacken, oder schlimmer noch, beginnen Sie einfach zu googeln, um zu erfahren, wie man es "macht".

Wenn wir als kollektives Ganzes vielleicht entscheiden, ob es an der Zeit ist, die Eintrittsbarrieren zu erhöhen, die Branche auf einem höheren Niveau zu halten, uns vom Hacker/Handwerker zum Ingenieur zu entwickeln, ist diese Art von Regulierung alles, worauf ich mich einlasse.

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

In dieser Hinsicht ist es gut, sich selbst zu regulieren oder Eintrittsbarrieren zu schaffen. Weil wir sagen, hey, Sie können nicht einfach von der Straße kommen und sich selbst als Software Engineer bezeichnen. Sie müssen tatsächlich eine Fähigkeitsstufe demostrieren.

Demostrierende Fähigkeiten sind mehr als nur ein Test oder ein "Ehrenabzeichen". Ein Test ist nur eine Validierung. Eine echte Bestätigung ist Schule, Praktikum, Lehre, Mentoring unter Senioren, Üben - all dies gehört dazu.

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

1
Jon Raynor

Ich habe den Artikel nicht gelesen, aber wenn die Frage lautet, ob die Regulierung der Softwareindustrie der Menschheit zugute kommen kann, hängt dies meiner Meinung nach von den Umständen ab:

  1. Die Branche als Ganzes umfasst eine Vielzahl von Bereichen, von denen einige lebenskritisch sind (z. B. die Kontrolle der Strahlendosis in einem medizinischen Gerät) und andere nicht (die Facebook-App "Welche Muppets sind Sie?"). Ich sehe kein Argument für eine Regulierung für Anwendungen, bei denen der Einsatz gering ist.

  2. Man sollte nicht mit der gesetzlichen Regelung beginnen . Vielmehr sollte man mit einem Zertifizierungsprogramm für Entwickler beginnen. Nur wenn das Zertifizierungsprogramm einen messbaren Nutzen bringt, sollte es eine Frage der gesetzlichen Regelung geben.

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

  4. Trotzdem gibt es immer noch Bereiche, in denen es wirtschaftlich sinnvoll ist, Schaden zu verursachen (oft sind dies negative externe Effekte , manchmal sind sie das Ergebnis von Marktmacht für einige Institute ). Beispielsweise kann ein Bereich ein einzelnes örtliches Krankenhaus haben; In diesem Fall kann die Qualität der Back-End-Software einen großen Unterschied in der Versorgung eines Patienten bewirken, macht jedoch keinen großen Unterschied in dem Krankenhaus, das der Patient wählt. Das Krankenhaus hat dann nicht unbedingt viel Business Case für Investitionen in höherwertige Entwickler. In diesem Fall kann es einen Fall im Bereich der öffentlichen Gesundheit geben, in dem die Entwickler reguliert werden, die das Krankenhaus einstellen darf.

MEINER BESCHEIDENEN MEINUNG NACH.

0
Aidan Cully

Ich muss diese Frage beantworten ...

Beginnend mit dem, was @JonathanHenson gesagt hat und dem Eintrag von @gnat, ist das, was ich sage, 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 ), also wird es immer noch Abtrünnige geben, wenn das in die Praxis umgesetzt wird. Selbst wenn traditionelle (und nicht so traditionelle) Bereitstellungsmethoden geschlossen sind, werden die Benutzer dennoch Möglichkeiten finden, interessierten Benutzern Software bereitzustellen. Selbst wenn es bedeutet, ein anderes HTTP-Protokoll oder sogar einen alternativen gesamten Netzwerkstapel zu entwickeln, der sich nur darauf konzentriert, Verbindungen nicht erkennbar zu machen (siehe den letzten Absatz für jemanden, der dies möglicherweise kann).

Auch die Idee, für etwas zu bezahlen, ist gefährdet, 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 ohne verwenden Zertifizierung (Brasilien und Indien kommen in den Sinn, aber es gibt sicher andere), und einige dieser Länder werden groß, wirklich groß. Und sie verwenden nicht zertifizierte Software von unbekannten Programmierern, deren Fähigkeiten unbekannt sind.

Selbst wenn es irgendeine Art von Zertifizierung gibt, wird die Zertifizierung nur das Wissen zertifizieren, nicht die Ethik. Denken Sie nur, dass einige Ärzte Organe verwenden, die auf nicht autorisierte Weise von Menschen entfernt wurden, also würde es auch zertifizierte Programmierer geben, die dies tun würden Habe keine Ethik und schreibe absichtlich oder unbeabsichtigt schlampigen Code. 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 Kleinem macht.

Was sagen Sie schließlich zu Hacking-Gruppen (nicht Black-Hat-Hacker-Gruppen, sondern White- oder Grey-Hat-Gruppen), die viel mehr über Sicherheit wissen und Sicherheitssoftware so entwickeln, dass sie nur den spezialisiertesten Programmierern bestimmter Regierungsabteilungen entspricht?.

0
Coyote21