Ist Softwareentwicklung eine technische Disziplin?

Kann Softwareentwicklung als Engineering betrachtet werden? Wenn nein, was fehlt, um sich als Ingenieurdisziplin zu qualifizieren? Im Zusammenhang damit steht diese Frage zum Stapelüberlauf über den Unterschied zwischen einem Programmierer und einem Softwareentwickler .

Es gibt das Software Engineering Institute der Carnigie Mellon University, das die CMMI-Standards vorschreibt und aufrechterhält. Ist dies etwas, das die Entwicklung in Engineering verwandelt?

Ist Softwareentwicklung Engineering? Wenn nein, was fehlt ihm, um sich so zu qualifizieren?

Ja, Software Engineering ist eine technische Disziplin.

Wikipedia definiert Ingenieurwesen als "die Anwendung von mathematischem sowie wissenschaftlichem, wirtschaftlichem, sozialem und praktischem Wissen, um Strukturen, Maschinen, Werkzeuge, Systeme, Komponenten, Materialien zu erfinden, zu innovieren, zu konstruieren, zu bauen, zu warten, zu erforschen und zu verbessern , Prozesse, Lösungen und Organisationen. " Das Ergebnis des Software-Engineerings ist ein Softwaresystem, das das Leben der Menschen verbessern und eine Kombination aus wissenschaftlichen, mathematischen, wirtschaftlichen, sozialen oder praktischen Kenntnissen beinhalten kann.

In akademischer und beruflicher Hinsicht ist es unterschiedlich. Software-Engineering-Programme können von ABET als Engineering-Programme anerkannt werden. Softwareentwickler können Mitglieder des IEEE sein. Einige Unternehmen betrachten das Software-Engineering als eine technische Disziplin, andere nicht - es ist wirklich eine Zwickmühle.

Das beste Buch zu diesem Thema ist Steve McConnells Professional Software Development: Kürzere Zeitpläne, qualitativ hochwertigere Produkte, erfolgreichere Projekte, verbesserte Karrieren . Es befasst sich mit Software - Engineering als Beruf, Entwicklung von einem Handwerk zu einem Beruf, die Wissenschaft von der Software - Entwicklung, der Unterschied zwischen Software - Engineering und Software Engineering (Ingenieurpraxis Software im Vergleich zu Ingenieuren Anwendung, die Build - Software geschehen, mit einer Fallstudie , dass beinhaltet meine Alma Mater ), Zertifizierung und Lizenzierung sowie Ethik.

Glenn Vanderburg hat eine Reihe von Vorträgen mit dem Titel "Real Software Engineering", die zwischen 2010 und 2015 auf einer Reihe von Konferenzen gehalten wurden, zusammen mit zwei verwandten Vorträgen, "Craft, Engineering und die Essenz der Programmierung" (2011 als "Real Software Engineering") Keynote auf der RailsConf) und "Craft and Software Engineering" (2011 auf der QCon London). Ich denke, diese Gespräche sind ein ziemlich umfassendes Argument dafür, warum Software-Engineering eine technische Disziplin ist.

Ein Argument, das Vanderburg in seinen Gesprächen kurz vorbringt, ist das von Jack W. Reeves im Jahr 1992 (und erneut im Jahr 2005) vorgebrachte, was Software-Design ist und wie Code die Ausgabe von Software-Engineering-Design-Aktivitäten ist ( dies ist auch der Fall) im C2-Wiki diskutiert). Sobald Sie sich von älteren Denkansätzen verabschieden, in denen Spezifikation und Modellierung Software-Design und Code-Software-Design sind, werden einige der Beziehungen zwischen Software-Engineering und anderen technischen Disziplinen deutlicher. Einige Unterschiede und die Gründe für diese Unterschiede werden noch deutlicher, wenn Sie feststellen, dass sich die Wirtschaftlichkeit der Softwareentwicklung erheblich von vielen anderen Disziplinen unterscheidet - Konstruktion ist billig (in vielen Fällen fast kostenlos), während Design den teuren Teil darstellt.

Ist das [CMMI] etwas, das Entwicklung in Engineering verwandelt?

Nein. CMMI ist ein Framework zur Prozessverbesserung, das Organisationen Anleitungen dazu gibt, welche Aktivitäten beim Erstellen von Software hilfreich sind. Technische Disziplinen haben typischerweise einen technischen Prozess. Ein solcher Prozess ist wichtig für den erfolgreichen Abschluss hochwertiger Projekte. Das CMMI (oder ein anderes Prozess-Framework oder eine andere Methodik) ist jedoch nur ein einziges Tool. Wenn Sie es verwenden, werden Sie nicht auf magische Weise von einem Entwickler zu einem Ingenieur. Die Nichteinhaltung eines Prozesses ist meiner Meinung nach ein Zeichen für ein Projekt, das kein Ingenieurprojekt ist.

Wie ist Ihre Meinung zu den Software Engineering Kursen / Zertifikaten?

Es ist nur so viel Wert, wie andere Leute hineinlegen. Es gibt nützliche Kurse und es gibt nutzlose Kurse. Es gibt wertvolle Zertifikate und Zertifikate, die das Papier, auf dem sie gedruckt wurden, nicht wert sind. Es gibt viele Faktoren, von wem der Kurs gebilligt oder akkreditiert wird oder von wem das Zertifikat für Ihre aktuelle Beschäftigungsbranche für Ihre aktuelle Stelle ausgestellt wird und wohin Sie möchten.

Ich komme aus einem typischen technischen Hintergrund, mache aber eine Karriere in der Softwareentwicklung und sehe große Ähnlichkeiten zwischen beiden Welten. Abgesehen von der genauen Definition von Engineering sehe ich in der Praxis, dass sich die Entwicklung von Software nicht wesentlich von der Entwicklung eines physischen Produkts unterscheidet. Zumindest denke ich, dass es nicht sehr anders sein sollte.

Egal, ob Sie ein Flugzeug oder eine Softwareanwendung entwerfen, für beide müssen Sie Folgendes tun:

• Entwürfe machen
• Subsysteme und Komponenten definieren
• Prototypen machen
• Tests spezifizieren und ausführen
• etc.

Irgendwo in einer anderen Antwort habe ich gelesen, dass das Entwerfen von Software anders ist, weil Sie nicht alles entwerfen, bevor Sie mit dem Programmieren beginnen. In geringerem Maße ist dies auch der Fall, wenn Sie ein physisches Produkt entwerfen. Das Entwerfen und Testen von Prototypen ist ein iterativer Prozess.

Auch wenn Softwareprojekte an Größe zunehmen, wird es immer wichtiger, eindeutige Subsysteme, Komponenten und Schnittstellen zu definieren, die auch dem Entwurf komplexer Produkte wie z. B. eines Flugzeugs ähneln.

Deshalb betrachte ich die Entwicklung von Software als Engineering.

Ich würde behaupten, dass es in der Tat so etwas wie Software-Engineering gibt.

Engineering beinhaltet die systematische Anwendung wissenschaftlicher Erkenntnisse zur Lösung von Problemen. Die Komplexität der Probleme, die heute angegangen werden, unterscheidet sich nicht wesentlich von denen, die ein Elektrotechniker beim Erstellen eines Schaltkreises oder ein Chemieingenieur beim Entwerfen eines Herstellungsprozesses oder ein Maschinenbauingenieur beim Erstellen eines Geräts anpackt.

Die Tatsache, dass es auch einen praktischen Ansatz gibt, vorhandene Pläne anzuwenden (Entwicklung in diesem Fall), ähnelt einfach der Tatsache, dass in anderen Bereichen jemand anderes diese Pläne ausführt (z. B. der Bauarbeiter).

Es ist richtig, dass die meisten Entwickler auch Software-Engineering-Aufgaben übernehmen und dass unsere Ausbildung oft nicht im Programmieren, sondern im Software-Engineering stattfindet. Also machen wir uns die Hände schmutzig, wohingegen ein Bauingenieur das nicht tun würde.

Die Fähigkeit, eine Programmiersprache und ein Programm anzuwenden, macht jedoch nicht aus einem Ingenieur einen Ingenieur: Ich habe meinen Teil der Entwickler getroffen, denen es an einem echten Verständnis der Komplexität und der Probleme außerhalb ihres aktuellen Codeteils mangelt.

Zu Ihrer Frage zu CMU: Die Anwendung einer Norm oder eines Verfahrens (z. B. CMMI) macht die Arbeit einer Person nicht automatisch zum Ingenieur. Die Tatsache, dass es Organisationen gibt, die wissenschaftliche Forschung betreiben, um neue Praktiken bereitzustellen, ist wiederum ein Zeichen dafür, dass es so etwas wie Ingenieurwesen gibt.

Nein, es ist kein Engineering. Wir sind nicht so wissenschaftlich und wir müssen keinen dieser State-Engineering-Tests bestehen. In der Tat ist es illegal, sich an einigen Stellen als "Softwareingenieur" zu bezeichnen, da es an Tests mangelt.

IMHO wurde der Begriff "Software-Engineering" geprägt, um zu versuchen, die Bandbreite der Tätigkeiten eines Entwicklers besser zu beschreiben, anstatt nur ein "Programmierer" zu sein (der die Obertöne eines mechanistischen Prozesses mit wenig Nachdenken oder Kreativität aufweist).

Persönlich bevorzuge ich die aufkommende Analogie eines Entwicklers als "Handwerker", der unter anderem von den pragmatischen Programmierern vertreten wird.

In der Vergangenheit haben die Menschen versucht, die Erstellung von Software mit der Herstellung zu vergleichen. Ich denke, Jack Reeves hat in seinem Artikel What Is Software Design eine ziemlich gute Argumentation gemacht, um diese Idee zu diskreditieren .

Aus dem Wiki:

Ingenieurwesen :

Software-Engineering ist die Anwendung eines systematischen, disziplinierten und quantifizierbaren Ansatzes für die Entwicklung, den Betrieb und die Wartung von Software sowie die Untersuchung dieser Ansätze. das heißt, die Anwendung von Engineering auf Software.

Software-Entwicklung

Softwareentwicklung ist die Reihe von Aktivitäten, die zu Softwareprodukten führen. Die Softwareentwicklung kann Forschung, Neuentwicklung, Änderung, Wiederverwendung, Neuentwicklung, Wartung oder andere Aktivitäten umfassen, die zu Softwareprodukten führen. [1]

Insbesondere die erste Phase des Softwareentwicklungsprozesses kann viele Abteilungen umfassen, darunter Marketing, Engineering, Forschung und Entwicklung sowie allgemeine Verwaltung.

Sie sind sich also ziemlich ähnlich und können auch dasselbe bedeuten.

Aus Dictionary.com: en · gi · neer · ing / ˌɛndˌɛnʒəˈrɪə /

- Substantiv 1. die Kunst oder Wissenschaft der praktischen Anwendung des Wissens der reinen Wissenschaften als Physik oder Chemie, wie beim Bau von Motoren, Brücken, Gebäuden, Minen, Schiffen und chemischen Anlagen.

Ich würde sagen, dass das Erstellen von Software die praktische Anwendung von Mathematik und Informatik ist, und möglicherweise von jeder anderen Anzahl von reinen Wissenschaften, abhängig von der Anwendung.

[EDIT] FWIW, ich bezeichne mich nicht als Software-Ingenieur, sondern als Software-Entwickler, also habe ich keinen persönlichen Anteil daran.

Aus meiner Sicht sind ein Software Engineer und ein Software Developer zwei verschiedene Dinge.

Ich sehe einen Softwareentwickler als einen, der plant, wie der Lebenszyklus der Entwicklung, die Anforderungen / Spezifikationen usw. aussehen. Grundsätzlich befasst sich ein Softwareentwickler mit vielen Dokumentationen. Dies kann von einem Softwareentwickler und / oder Projektmanager durchgeführt werden.

Ein Softwareentwickler wäre eher mit einem Programmierer verwandt, verfügt jedoch über mehr Kenntnisse in anderen Bereichen wie Datenbankverwaltung usw.

Eine interessante Sache, die angesprochen werden sollte, ist Architektur . Jemand, der auch daran beteiligt ist, herauszufinden, welche Hardware / Software für den Lebenszyklus des Projekts benötigt wird.

Ich werde hier mit "Nein" gehen. Mein Bruder ist Maschinenbauingenieur und beschreibt das Ingenieurwesen als "Die Kunst, billig zu sein":

"Ingenieure sind mehr darum bemüht, die Dinge so schnell wie möglich, zu möglichst geringen Kosten und mit möglichst wenig Material zu erledigen . "

Als Reaktion habe ich die Softwareentwicklung (nicht das Software-Engineering - das sind im Grunde genommen zwei unterschiedliche Bereiche) als "Die Kunst, effizient zu sein" beschrieben:

"Entwickler sind mehr darum bemüht, die Dinge so schnell wie möglich, zu möglichst geringen Kosten und mit möglichst wenig Wiederholungen zu erledigen . "

Der Unterschied liegt im letzten Teil dieser Sätze.

Ist Softwareentwicklung Engineering?

Nein. Ingenieur zu sein bedeutet, dass Ihr Projekt einem Zeitplan für Ursache und Wirkung folgt - Sie befolgen die Bauvorschriften, sodass Ihr Gebäude nicht herunterfällt (oder zumindest nicht beschuldigt werden kann, wenn dies der Fall ist). Wenn Sie Software schreiben, können Sie alle Richtlinien befolgen (und es stehen so viele verschiedene zur Auswahl!), Und es kann immer noch vorkommen, dass sie hängen bleiben, abstürzen oder falsche Antworten geben (es sei denn, Sie sind in das bemerkenswert kleine Feld involviert, nachweisbare Programme zu schreiben -effektlose funktionale Sprachen).

Ich verstehe einen Ingenieur (Mechaniker, Konstrukteur, Software) als jemanden, der das Produkt im Voraus auf der Grundlage der verstandenen Bedürfnisse entwirft und versteht, was und wie die Materialien angewendet werden müssen, um diese Bedürfnisse zu befriedigen.

So sieht man beispielsweise häufig einen Statiker, der nach verschiedenen Stahlfestigkeiten sucht und physikalische Regeln anwendet, um die erforderlichen Materialien und deren Implementierung zu berechnen. Tragwerksplanung ist ein hervorragendes Beispiel, da Sie am Ende immer einen Entwurf (eine Spezifikation) dessen haben, was Sie bauen werden, bevor Sie bauen. Das passiert bei Software nicht immer.

Für mich ist der Unterschied zwischen einem Softwareentwickler und einem Programmierer, dass der Entwickler in der Lage ist, die Spezifikation für das zu erstellende Produkt zu erstellen, bevor Code geschrieben wird, wobei ein Programmierer den Code entweder nur auf der Grundlage anderer Spezifikationen schreibt oder einer dieser Codes ist Wild-West-Programmierer, die Code ohne Spezifikationen schreiben. Auch der Ingenieur hat seinen Abschluss.

Ich vergleiche den Unterschied zwischen einem Bauarbeiter und einem Statiker mit dem Unterschied zwischen einem Programmierer und einem Software-Ingenieur.

Zur Klarstellung, ich habe nur ein Hochschuldiplom und kann mich daher nicht als Ingenieur bezeichnen.

Ich würde den Begriff "Engineering" aus zwei Hauptgründen nicht als am besten geeignet ansehen, um Softwareentwicklung zu beschreiben:

• Es vermittelt viele alte Ideen, Konzepte und sogenannte "goldene Regeln", die ihren Ursprung in traditionellen Ingenieurdisziplinen wie Industrie-, Zivil-, See- oder Maschinenbau haben. Ich spreche von Regeln in Bezug auf Arbeitsteilung, Produktionsprozesse, Qualitätsstandards ... Diese gelten meist nur am Rande für Software.

• Es wird nicht in befriedigender Weise beschrieben, was Programmieren mehr als andere Disziplinen hat (und ich glaube, es hat viel mehr und viel andere Disziplinen) und welche neuen Herausforderungen Entwickler im Vergleich zu ihren Kollegen im traditionellen Alltag haben enineering domains. Dabei spielt die virtuelle und immaterielle Natur der Software eine große Rolle.

Die Softwareentwicklung wurde lange Zeit als "nur eine weitere technische Disziplin" angesehen. Angesichts der Misserfolgsraten von Softwareprojekten, die wir seit ihrer Messung kennen, ist es höchste Zeit, die Entwicklung als ein völlig neues Tier, den Code als einen ganz besonderen Material- und Anwendungslebenszyklus als eine völlig andere Art von Produktionszyklus zu erkennen und den verzweifelten Versuch einzustellen alte Rezepte auf sie anzuwenden.

Ja, man sollte in der Lage sein, Standards und Prinzipien anzuwenden, um zu einem anständigen Produkt zu gelangen. Was es schwierig macht, ist die Denkweise des Kunden (es ist nur Code - es sollte nicht so viel kosten, sich zu ändern), die extreme Schwierigkeit, zu codieren, was das Produkt in Maschinencode (gesprochene / geschriebene Sprache zu Code) und Quantifizierung " Qualität". Ihre Definition von Qualität ist nicht meine.

Es ist auch Wiederholbarkeit. Nehmen Sie eine Reihe von Anforderungen und geben Sie sie an zwei Teams weiter. Wenn Sie das Gleiche herausholen können (ohne dass die Teams miteinander sprechen), sind Sie der Technik ziemlich nahe.

Andere Bereiche des Ingenieurwesens haben ebenfalls Strafen und eine strenge Überprüfung und Abnahme. Rechenschaftspflicht.

Nein. Software Engineering ist kein Engineering. Meiner Meinung nach liegt der Unterschied in der Menge an Kreativität. Im Bauwesen zum Beispiel kann es sehr wenig oder gar keine Kreativität geben. Das ist eine gute Sache.

Um eine Brücke zu bauen, müssen Sie eine Reihe von Spezifikationen haben (ich muss diese Anzahl von Autos von dieser Seite des Flusses auf die andere Seite bringen).

Daraus kann ich ableiten:

1. die Anzahl der von mir benötigten Fahrspuren (unter Verwendung einer von der Regierung festgelegten Standardberechnung);
2. die Lasten, die ich tragen muss (unter Verwendung von Berechnungen, die von der Regierung festgelegt wurden)
3. Die Materialien, die ich verwenden muss, um diese Lasten zu tragen (entweder mit Standardmaterialien, die ich von verschiedenen Lieferanten beziehen kann, oder mit Nicht-Standardmaterialien, von denen ich nachweisen muss, dass sie die richtigen Eigenschaften haben).

Dann muss ich das Design von einem Dritten (einem anderen Unternehmen) genehmigen und prüfen lassen, um sicherzustellen, dass ich meine Berechnungen korrekt durchgeführt habe.

Wenn die Brücke dann tatsächlich gebaut wird, werden die Arbeiten von qualifizierten Mitarbeitern auf übliche Weise ausgeführt. Sie werden Arbeiten erledigen, die sie hunderte, vielleicht tausende Male zuvor gemacht haben.

Versteht mich nicht falsch, jedes Tiefbauprojekt ist anders, aber jedes Mal, wenn ich eine neue Anwendung / Website entwickle, werden die Dinge anders gemacht.

Ja, ich würde vermuten, dass Entwicklung eine Teilmenge der Technik ist:

• Das Software-Engineering enthält die anfängliche Spezifikation ("Welche Art von Software benötigen wir hier?"), Die wohl der Entwicklung vorausgeht
• "Engineering" könnte beispielsweise auch die Definition des Qualitätssicherungsprozesses umfassen, der sicherlich mit der Entwicklung zusammenhängt, aber wohl auch außerhalb des Umfangs der "Konstruktion" selbst liegt.

Code Complete definiert "Konstruktion" als Synonym für Codierung und Debugging (und Kommentieren), auch mit detailliertem Design im Vorfeld und mit anschließenden Unit- und Integrationstests. Kapitel 1, Willkommen bei Software Construction (PDF), beginnt mit der Auflistung vieler Themen im gesamten Software Development Lifecycle (einschließlich Problemdefinition, Softwarearchitektur, Korrekturwartung usw.).

Wie aus der Abbildung hervorgeht, handelt es sich bei der Konstruktion hauptsächlich um Codierung und Debugging, aber es werden auch detaillierte Entwürfe, Baupläne, Komponententests, Integrations- und Integrationstests und andere Aktivitäten durchgeführt. Wenn dies ein Buch über alle Aspekte der Softwareentwicklung wäre, würde es eine ausgewogene Diskussion aller Aktivitäten im Entwicklungsprozess beinhalten. Da es sich um ein Handbuch der Bautechniken handelt, liegt der Schwerpunkt auf dem Bauen und es werden nur verwandte Themen behandelt. Wenn dieses Buch ein Hund wäre, würde es sich an die Arbeit machen, beim Entwerfen und Testen mit dem Schwanz wedeln und bei den anderen Entwicklungsaktivitäten bellen.

Softwareentwicklung ist Engineering.

Einige Argumente anderer, warum Software-Engineering nicht dem Standard eines Ingenieurs entspricht:

Einige sagen, Ingenieure befassen sich mit der Gestaltung von "Dingen" für das Gemeinwohl - sind ICBMs, Panzer usw. im Gemeinwohl? Einige würden ja sagen (eine gute Offensive ist eine gute Verteidigung), andere würden nein sagen. Ich glaube jedoch nicht, dass irgendjemand anderer Meinung ist, dass der Typ, der das Tankzielsystem der nächsten Generation entwirft, ein Ingenieur ist. Das Gemeinwohl kann subjektiv sein. Auf jeden Fall ist eine Menge Software im öffentlichen Interesse, daher ist der Punkt in beiden Fällen umstritten.

Andere sagen, Ingenieure entwerfen, sie bauen nicht. Ich habe mehrere Kommentare vom Typ "Maschinenbauer schweißen nicht" gesehen. Ich würde argumentieren, dass Maschinenbauer Blaupausen produzieren - detaillierte Entwürfe, die etwas anderes umsetzt. Wenn ein Maschinenbauingenieur eine Blaupause erstellt und diese einer CNC-Maschine zuführt, ist er dann kein Maschinenbauingenieur mehr - weil eine Maschine die Implementierung anstelle einer Person durchführte? Ich würde argumentieren, dass der Quellcode eine detaillierte Blaupause ist, die einer Maschine zugeführt wird, die die Implementierung durchführt, und ich kann nicht erkennen, wie sich dies von einem MechE-Zuführcode für eine CNC-Maschine unterscheidet. Und wir haben jetzt 3D-Drucker. Bedeutet das das Ende der Maschinenbauingenieure? Sind sie jetzt mechanische Entwickler?

Lizenz ist das andere Thema, das ich aufkommen sehe. Derzeit lizenzieren nur wenige Gerichtsbarkeiten Software-Ingenieure. Es gibt (bis jetzt) ​​keine US-weite Lizenzierung von Software-Ingenieuren (ich denke, nur Texas tut dies). Einige haben dies als Grund dafür angeführt, dass Software-Engineering nicht als Engineering bezeichnet werden sollte. Das PE für Softwareentwickler kommt. Auf einer eher philosophischen Ebene hat dies jedoch keine Auswirkung auf die Realität, nur weil einige staatliche Gesetzgeber die Bezeichnung Software Development Engineering wählen (oder nicht).