Softwareentwicklungsprozess

Im Softwareentwicklung, a Softwareentwicklungsprozess ist ein Prozess der Trennung Software-Entwicklung Arbeiten Sie in kleinere, parallele oder sequentielle Schritte oder Unterprozesse, um sich zu verbessern Entwurf, Produkt Management. Es ist auch als a bekannt Lebenszyklus der Softwareentwicklung (SDLC). Die Methodik kann die Vordefinition von Spezifisch umfassen Leistungen und Artefakte, die von einem Projektteam erstellt und fertiggestellt werden, um eine Anwendung zu entwickeln oder zu pflegen.[1]

Die meisten modernen Entwicklungsprozesse können vage beschrieben werden als agil. Andere Methoden umfassen Wasserfall, Prototyp entwickeln, iterative und inkrementelle Entwicklung, Spiralentwicklung, Schnelle Anwendungsentwicklung, und extremes Programmieren.

Ein Lebenszyklus-Modell wird manchmal als allgemeinerer Begriff für eine Kategorie von Methoden und eine Softwareentwicklung "Prozess" ein spezifischerer Begriff für einen bestimmten Prozess, der von einer bestimmten Organisation ausgewählt wurde, als ein spezifischerer Begriff angesehen. Zum Beispiel gibt es viele spezifische Softwareentwicklungsprozesse, die zum spiralförmigen Lebenszyklusmodell passen. Das Feld wird oft als Teilmenge der Lebenszyklus für Systementwicklung.

Geschichte

Das Framework der Softwareentwicklungsmethodik (auch als SDM bekannt) wurde erst in den 1960er Jahren entstanden. Nach Elliott (2004) die Lebenszyklus für Systementwicklung (SDLC) kann als der älteste formalisierte Methodik -Rahmen für den Aufbau angesehen werden Informationssysteme. Die Hauptidee des SDLC bestand darin, "die Entwicklung von Informationssystemen auf sehr bewusste, strukturierte und methodische Weise zu verfolgen und jede Stufe des Lebenszyklus zu erfordern - von der Einführung der Idee bis zur Abgabe des endgültigen Systems - - - starr und nacheinander ausgeführt werden "[2] im Kontext des angewandten Frameworks. Das Hauptziel dieses Methodik -Frameworks in den 1960er Jahren war die Entwicklung von großem Umfang funktional Geschäftssysteme In einem Zeitalter großer Business -Konglomerate. Aktivitäten für Informationssysteme drehten sich um schwer Datenverarbeitung und Zahlenverarbeitung Routinen ".[2]

Methoden, Prozesse und Frameworks reichen von spezifischen präskriptiven Schritten, die direkt von einer Organisation in der täglichen Arbeit verwendet werden können, bis hin zu flexiblen Rahmenbedingungen, mit denen ein Unternehmen einen benutzerdefinierten Satz von Schritten generiert, die auf die Anforderungen eines bestimmten Projekts oder eines bestimmten Projekts oder eines bestimmten Projekts zugeschnitten sind Gruppe. In einigen Fällen verteilt eine "Sponsor" oder "Wartungs" -organisation eine offizielle Reihe von Dokumenten, die den Prozess beschreiben. Spezifische Beispiele sind:

1970er Jahre
1980er Jahre
1990er Jahre
2000er Jahre

2010er

Es ist bemerkenswert, dass seit DSDM im Jahr 1994 alle Methoden auf der obigen Liste mit Ausnahme von RUP agile Methoden waren - doch viele Organisationen, insbesondere Regierungen, verwenden immer noch Vor -Agile -Prozesse (oft Wasserfall oder ähnliches). Softwareprozess und Softwarequalität sind eng miteinander verbunden; Einige unerwartete Facetten und Effekte wurden in der Praxis beobachtet [3]

Unter diesen wurde ein weiterer Softwareentwicklungsprozess festgelegt in Open Source. Die Einführung dieser bekannten und etablierten Prozesse innerhalb der Grenzen eines Unternehmens heißt diese bewährten Verfahren, heißt innere Quelle.

Prototyp entwickeln

Software -Prototyping Es geht darum, Prototypen zu erstellen, d. H. Unvollständige Versionen des zu entwickelnden Softwareprogramms.

Die Grundprinzipien sind:[1]

  • Prototyping ist keine eigenständige, vollständige Entwicklungsmethode, sondern ein Ansatz, um bestimmte Merkmale im Kontext einer vollständigen Methodik auszuprobieren (z. B. inkrementelle, spiralförmige oder schnelle Anwendungsentwicklung (RAD)).
  • Versuche, das inhärente Projektrisiko zu reduzieren, indem ein Projekt in kleinere Segmente eingebaut und während des Entwicklungsprozesses eine bessere Veränderungsfunktionen liefern.
  • Der Kunde ist während des gesamten Entwicklungsprozesses beteiligt, der die Wahrscheinlichkeit einer Kundenakzeptanz der endgültigen Implementierung erhöht.
  • Während einige Prototypen mit der Erwartung entwickelt werden, dass sie verworfen werden, ist es in einigen Fällen möglich, sich vom Prototyp zum Arbeitssystem zu entwickeln.

Ein grundlegendes Verständnis des grundlegenden Geschäftsproblems ist erforderlich, um die Lösung der falschen Probleme zu vermeiden. Dies gilt jedoch für alle Software -Methoden.

Methoden

Agile Entwicklung

Hauptartikel: Agile Software Entwicklung

"Agile Software Development" bezieht sich auf eine Gruppe von Softwareentwicklungsrahmen, die auf iterativen Entwicklung basieren, bei denen sich Anforderungen und Lösungen durch Zusammenarbeit zwischen selbstorganisierenden funktionsübergreifenden Teams entwickeln. Der Begriff wurde im Jahr 2001 geprägt, als die Agiles Manifest wurde formuliert.

Agile Software Development nutzt iterative Entwicklung als Grundlage, befürwortet jedoch einen leichteren und mehr Menschen zentrierten Standpunkt als herkömmliche Ansätze. Agile Prozesse beinhalten grundlegend die Iteration und das kontinuierliche Feedback, das es bietet, um ein Softwaresystem nacheinander zu verfeinern und zu liefern.

Das agile Modell enthält auch die folgenden Softwareentwicklungsprozesse:[4]

Kontinuierliche Integration

Hauptartikel: Kontinuierliche Integration

Kontinuierliche Integration Ist die Praxis, alle Entwickler zu verführen, die Kopien zu einem gemeinsam genutzten Arbeiten haben Hauptlinie mehrmals am Tag.[5] Grady Booch zuerst benannt und vorgeschlagen CI in Seine Methode von 1991,[6] Obwohl er sich nicht mehrmals am Tag einsetzte. Extremes Programmieren (XP) übernahm das Konzept von CI und befürwortete mehr als einmal pro Tag - vielleicht bis zu zehnmal pro Tag.

Inkrementelle Entwicklung

Hauptartikel: Iterative und inkrementelle Entwicklung

Verschiedene Methoden sind akzeptabel, um lineare und iterative Systementwicklungsmethoden zu kombinieren, wobei das Hauptziel jedes Unternehmens zur Verringerung des inhärenten Projektrisikos durch Aufschlüsse eines Projekts in kleinere Segmente und die Bereitstellung von mehr Veränderung während des Entwicklungsprozesses reduziert wird.

Es gibt drei Hauptvarianten inkrementeller Entwicklung:[1]

  1. Es werden eine Reihe von Mini-Wasserfällen durchgeführt, in denen alle Phasen des Wasserfalls für einen kleinen Teil eines Systems abgeschlossen sind, bevor sie mit dem nächsten Inkrement fortfahren, oder
  2. Die Gesamtanforderungen werden definiert, bevor die Entwicklung einzelner Inkremente eines Systems oder mit der Entwicklung von Evolutionärs, Mini-Wasserfallentwicklung
  3. Das anfängliche Softwarekonzept, die Anforderungenanalyse und das Design von Architektur und Systemkern werden über Wasserfall definiert, gefolgt von einer inkrementellen Implementierung, die bei der Installation der endgültigen Version, einem Arbeitssystem, gipfelt.

Schnelle Anwendungsentwicklung

Hauptartikel: Schnelle Anwendungsentwicklung
RAD -Modell (Rapid Application Development)

Schnelle Anwendungsentwicklung (RAD) ist eine Softwareentwicklungsmethode, die bevorzugt iterative Entwicklung und die schnelle Konstruktion von Prototypen anstelle großer Mengen an Vorabplanung. Die "Planung" der mit RAD entwickelten Software ist mit dem Schreiben der Software selbst verschachtelt. Durch das Fehlen umfangreicher Vorplanung kann die Software im Allgemeinen viel schneller geschrieben werden und erleichtert die Änderung der Anforderungen.

Der schnelle Entwicklungsprozess beginnt mit der Entwicklung von Vorläufigkeit Datenmodelle und Geschäftsprozessmodelle Verwendung Strukturierte Techniken. In der nächsten Stufe werden die Anforderungen mithilfe von Prototypen überprüft, um die Daten und Prozessmodelle zu verfeinern. Diese Phasen werden iterativ wiederholt; Weiterentwicklung führt zu "einer kombinierten Geschäftsanforderungen und technischen Designabrechnungen, die für die Konstruktion neuer Systeme verwendet werden können".[7]

Der Begriff wurde zunächst verwendet, um einen Softwareentwicklungsprozess zu beschreiben, der von eingeführt wurde, James Martin 1991. nach Whitten (2003) ist es eine Fusion verschiedener Fusionen Strukturierte Techniken, insbesondere datengetrieben Informationstechnologie Engineeringmit Prototyping -Techniken zur Beschleunigung der Softwaresystementwicklung.[7]

Die Grundprinzipien der schnellen Anwendungsentwicklung sind:[1]

  • Das Hauptziel ist die schnelle Entwicklung und Bereitstellung eines Systems mit hoher Qualität zu relativ geringen Investitionskosten.
  • Versuche, das inhärente Projektrisiko zu reduzieren, indem ein Projekt in kleinere Segmente eingebaut und während des Entwicklungsprozesses eine bessere Veränderungsfunktionen liefern.
  • Ziel ist es, hohe Qualitätssysteme schnell zu produzieren, hauptsächlich durch iterative Prototyping (in jeder Entwicklungsphase), aktives Benutzerbeteiligung und computergestützte Entwicklungstools. Diese Tools können umfassen Grafische Benutzeroberfläche (GUI) Bauherren, Computergesteuerte Software -Engineering (Fall) Tools, Datenbankmanagementsystem (DBMS), Programmiersprachen der vierten Generation, Codegeneratoren und objektorientierte Techniken.
  • Wichtiger Schwerpunkt liegt auf der Erfüllung des Geschäftsbedarfs, während technologische oder technische Exzellenz von geringerer Bedeutung ist.
  • Die Projektsteuerung beinhaltet die Priorisierung der Entwicklung und die Definition von Lieferfristen oder „Zeitboxen“. Wenn das Projekt zu rutschen beginnt, liegt der Schwerpunkt darauf, die Anforderungen zu reduzieren, um dem Zeitraum zu entsprechen, und nicht in der Erhöhung der Frist.
  • Im Allgemeinen einbezogen gemeinsames Anwendungsdesign (JAD), wo Benutzer intensiv beteiligt sind System-Designüber Konsensgebäude entweder in strukturierten Workshops oder über elektronisch erleichterte Wechselwirkung.
  • Aktive Benutzerbeteiligung ist unerlässlich.
  • Iterativ produziert Produktionssoftware im Gegensatz zu einem Wegwerfprototyp.
  • Erstellt eine Dokumentation, die zur Erleichterung der künftigen Entwicklung und Wartung erforderlich ist.
  • Standardsystemanalyse- und Designmethoden können in diesen Framework eingebaut werden.

Wasserfallentwicklung

Hauptartikel: Wasserfall-Modell
Die Aktivitäten des Softwareentwicklungsprozesses in der Wasserfall-Modell. Es gibt mehrere andere Modelle, die diesen Prozess darstellen.

Das Wasserfallmodell ist ein sequentieller Entwicklungsansatz, bei dem die Entwicklung durch mehrere Phasen als stetig nach unten (wie ein Wasserfall) angesehen wird, typischerweise:

Die erste formale Beschreibung der Methode wird häufig als Artikel angeführt, der von veröffentlicht wurde Winston W. Royce[8] 1970, obwohl Royce den Begriff "Wasserfall" in diesem Artikel nicht verwendete. Royce präsentierte dieses Modell als Beispiel für ein fehlerhaftes, nicht arbeitendes Modell.[9]

Die Grundprinzipien sind:[1]

  • Das Projekt ist in sequentielle Phasen unterteilt, wobei sich etwas überlappt und zwischen den Phasen akzeptabel ist.
  • Der Schwerpunkt liegt auf Planung, Zeitplänen, Zieldaten, Budgets und Implementierung eines gesamten Systems gleichzeitig.
  • Die enge Kontrolle wird über die Lebensdauer des Projekts über umfangreiche schriftliche Dokumentation, formelle Überprüfungen und Genehmigung/Signoff durch den Benutzer und durchführend gewartet Informationstechnologie Management am Ende der meisten Phasen vor Beginn der nächsten Phase auftreten. Die schriftliche Dokumentation ist eine ausdrückliche Erbringung jeder Phase.

Das Wasserfallmodell ist ein traditioneller technischer Ansatz, der für Software -Engineering angewendet wird. Ein strenger Wasserfallansatz entmutigt, eine vorherige Phase zu überdenken und zu überarbeiten, sobald sie abgeschlossen ist.[Nach wem?] Diese "Inflexibilität" in einem reinen Wasserfallmodell war eine Quelle der Kritik durch Anhänger anderer "flexiblerer" Modelle. Es wurde weithin für mehrere groß angelegte Regierungsprojekte verantwortlich Big Design vorne sich nähern.[Nach wem?] Sofern nicht vertraglich erforderlich ist, wurde das Wasserfallmodell weitgehend durch flexiblere und vielseitigere Methoden, die speziell für die Softwareentwicklung entwickelt wurden, weitgehend ersetzt.[Nach wem?] Sehen Kritik am Wasserfallmodell.

Spiralentwicklung

Spiralmodell (Boehm, 1988)
Hauptartikel: Spiralmodell

1988,, Barry Boehm veröffentlichte ein formelles Softwaresystementwicklungsentwicklung "Spiralmodell", das einige wichtige Aspekte des Wasserfall-Modell und Rapid-Prototyping Methoden, um Vorteile von zu kombinieren Top-Down und Bottom-up Konzepte. Es lieferte den Schwerpunkt in einem Schlüsselbereich, den viele von anderen Methoden vernachlässigt worden waren: absichtliche iterative Risikoanalyse, insbesondere für groß angelegte komplexe Systeme.

Die Grundprinzipien sind:[1]

  • Der Fokus liegt auf der Risikobewertung und auf die Minimierung des Projektrisikos, indem ein Projekt in kleinere Segmente eingebaut und während des Entwicklungsprozesses eine bessere Veränderungsfreundlichkeit bereitgestellt und die Möglichkeit bietet, Risiken zu bewerten und die Berücksichtigung der Projektdauer während des gesamten Lebenszyklus zu bewerten.
  • "Jeder Zyklus beinhaltet einen Fortschritt durch die gleiche Reihenfolge von Schritten, für jeden Teil des Produkts und für jede seiner Ausarbeitungsstufen, von einem Gesamtdokument der Operation bis zur Codierung jedes einzelnen Programms."[10]
  • Jede Reise um die Spirale durchquert vier grundlegende Quadranten: (1) Ziele, Alternativen und Einschränkungen der Iteration bestimmen und (2) Alternativen bewerten; Risiken identifizieren und lösen; (3) Entwicklung und Überprüfung von Ergebnissen aus der Iteration; und (4) die nächste Iteration planen.[11]
  • Beginnen Sie jeden Zyklus mit einer Identifizierung von Stakeholdern und ihren "Gewinnbedingungen" und beenden Sie jeden Zyklus mit Überprüfung und Engagement.[12]

Erweiterte Methoden

Weitere hochrangige Software-Projektmethoden sind:

  • Verhaltensgetriebene Entwicklung und Geschäftsprozessmanagement[13]
  • Chaosmodell - Die Hauptregel löst immer zuerst das wichtigste Problem.
  • Inkrementelle Finanzierungsmethode - ein iterativer Ansatz
  • Leichte Methodik - Ein allgemeiner Begriff für Methoden, die nur wenige Regeln und Praktiken haben
  • Strukturierte Systemanalyse- und Entwurfsmethode - Eine bestimmte Version des Wasserfalls
  • Langsame Programmierung als Teil des größeren Langsame Bewegung, betont sorgfältige und allmähliche Arbeit ohne (oder minimale) Zeitdruck. Langsames Programmieren zielt darauf ab, Fehler und übermäßig schnelle Freigabepläne zu vermeiden.
  • V-Model (Softwareentwicklung) - Eine Erweiterung des Wasserfallmodells
  • Einheitlicher Prozess (UP) ist ein iterativer Rahmen für die Softwareentwicklungsmethodik, basierend auf Einheitliche Modellierungssprache (Uml). UP organisiert die Entwicklung von Software in vier Phasen, die jeweils aus einer oder mehreren ausführbaren Iterationen der Software in dieser Entwicklungsphase bestehen: Inception, Ausarbeitung, Konstruktion und Richtlinien. Es gibt viele Werkzeuge und Produkte, um die Implementierung zu erleichtern. Eine der beliebtesten Versionen von UP ist die Rational einheitlicher Prozess (RUP).
  • Big Bang -Methodik - Ein Ansatz für kleine oder undefinierte Projekte, die im Allgemeinen aus wenig bis gar keiner Planung mit hohem Risiko bestehen.

Verarbeiten Sie Meta-Modelle

Etwas "Prozessmodelle"sind abstrakte Beschreibungen zum Bewerten, Vergleich und Verbesserung des spezifischen Prozesss, der von einer Organisation angewendet wird.

  • ISO/IEC 12207 ist der internationale Standard, der die Methode zur Auswahl, Implementierung und Überwachung des Lebenszyklus für Software beschreibt.
  • Das Integration der Fähigkeitsreifemodellintegration (CMMI) ist eines der führenden Modelle und basiert auf Best Practices. Unabhängige Bewertungen bewerten Organisationen, wie gut sie ihren definierten Prozessen folgen, nicht in der Qualität dieser Prozesse oder der produzierten Software. CMMI hat ersetzt CMM.
  • ISO 9000 Beschreibt Standards für ein formell organisiertes Verfahren zur Herstellung eines Produkts und der Methoden zur Verwaltung und Überwachung des Fortschritts. Obwohl der Standard ursprünglich für das verarbeitende Gewerbe erstellt wurde, wurden auch ISO 9000 -Standards für die Softwareentwicklung angewendet. Wie CMMI garantiert die Zertifizierung mit ISO 9000 die Qualität des Endergebnisses nicht, sondern dass formalisierte Geschäftsprozesse befolgt wurden.
  • ISO/IEC 15504 Informationstechnologie - Bewertung der Prozessbewertung ist Auch als Softwareprozessverbesserungsfunktion (Spice) bezeichnet, ist ein "Rahmen für die Bewertung von Softwareprozessen". Dieser Standard zielt darauf ab, ein klares Modell für den Prozessvergleich einzurichten. Gewürz wird ähnlich wie CMMI verwendet. IT modelliert Prozesse zum Verwalten, Steuerung, Leitfaden und überwacht die Softwareentwicklung. Dieses Modell wird dann verwendet, um zu messen, was ein Entwicklungsorganisation oder ein Projektteam während der Softwareentwicklung tatsächlich tut. Diese Informationen werden analysiert, um Schwächen zu identifizieren und die Verbesserung voranzutreiben. Es identifiziert auch Stärken, die für diese Organisation oder dieses Team in die allgemeine Praxis fortgesetzt oder integriert werden können.
  • ISO/IEC 24744 Software Engineering - Metamodel für Entwicklungsmethoden, ist ein auf Leistungstyp basierendes Metamodel für Softwareentwicklungsmethoden.
  • SPEM 2.0 von der Objektverwaltungsgruppe
  • Methodik weicher Systeme - Eine allgemeine Methode zur Verbesserung der Managementprozesse
  • Method engineering - Eine allgemeine Methode zur Verbesserung des Informationssystemprozesses

In der Praxis

Die drei grundlegenden Ansätze, die auf Softwareentwicklungsmethodik -Frameworks angewendet werden.

Im Laufe der Jahre haben sich eine Vielzahl solcher Rahmenbedingungen entwickelt, die jeweils eigene anerkannte Stärken und Schwächen haben. Ein Rahmenwerk für Softwareentwicklungsmethodik ist nicht unbedingt für alle Projekte geeignet. Jedes der verfügbaren Methodik -Rahmenbedingungen eignet sich am besten für bestimmte Arten von Projekten, die auf verschiedenen Überlegungen zur technischen, organisatorischen, Projekt- und Teams basieren.[1]

Software-Entwicklung Organisationen implementieren Prozessmethoden, um den Entwicklungsprozess zu erleichtern. Manchmal müssen Auftragnehmer Methoden eingesetzt werden. Ein Beispiel ist der USA, der die USA ist. Rüstungsindustrie, was eine Bewertung basierend auf erfordert Prozessmodelle Verträge erhalten. Der internationale Standard zur Beschreibung der Methode zur Auswahl, Implementierung und Überwachung des Lebenszyklus für Software ist ISO/IEC 12207.

Ein jahrzehntelanges Ziel war es, wiederholbare, vorhersehbare Prozesse zu finden, die die Produktivität und Qualität verbessern. Einige versuchen, die scheinbar widerspenstige Aufgabe, Software zu entwerfen, zu systematisieren oder zu formalisieren. Andere bewerben sich Projektmanagement Techniken zum Entwerfen von Software. Eine große Anzahl von Softwareprojekten erfüllt ihre Erwartungen in Bezug auf Funktionen, Kosten oder Lieferungsplan nicht - siehe Liste der fehlgeschlagenen und überbudget benutzerdefinierten Softwareprojekte für einige bemerkenswerte Beispiele.

Organisationen können a erstellen Software -Engineering -Prozessgruppe (SEPG), was der Schwerpunkt für die Prozessverbesserung ist. Die Gruppe besteht aus Linienpraktikern, die unterschiedliche Fähigkeiten haben, und steht im Mittelpunkt der Zusammenarbeit aller in der Organisation, die an der Verbesserung des Software -Engineering -Prozesses beteiligt sind.

Ein bestimmtes Entwicklungsteam kann auch den Programmdetails der Programmumgebung zustimmen, wie dies integrierte Entwicklungsumgebung wird ein oder mehrere dominant verwendet Programmierparadigmen, Programmierstil Regeln oder Auswahl der Spezifischen Software -Bibliotheken oder Software -Frameworks. Diese Details werden im Allgemeinen nicht durch die Wahl des Modells oder der allgemeinen Methodik bestimmt.

Lebenszyklus der Softwareentwicklung (SDLC)

Siehe auch

Verweise

  1. ^ a b c d e f g Centers for Medicare & Medicaid Services (CMS) Office of Information Service (2008). Auswählen eines Entwicklungsansatzes. Webartikel. US -Gesundheitsministerium (HHS) der Vereinigten Staaten. Neubewertet: 27. März 2008. Abgerufen am 27. Oktober 2008.
  2. ^ a b Geoffrey Elliott (2004) Globale Geschäftsinformationstechnologie: Ein integrierter Systemansatz. Pearson Ausbildung. S.87.
  3. ^ Suryanarayana, Girish (2015). "Softwareprozess versus Designqualität: Tug of War?". IEEE -Software. 32 (4): 7–11. doi:10.1109/ms.2015.87.
  4. ^ "Softwareentwicklungsprozess". 19. August 2020.
  5. ^ "Kontinuierliche Integration".
  6. ^ Booch, Grady (1991). Objektorientiertes Design: mit Anwendungen. Benjamin Cummings. p. 209. ISBN 9780805300918. Abgerufen 18. August 2014.
  7. ^ a b Whitten, Jeffrey L.; Lonnie D. Bentley, Kevin C. Dittman. (2003). Systemanalyse- und Designmethoden. 6. Ausgabe. ISBN0-256-19906-x.
  8. ^ WasserfallModell> EntstehungsKontext, Markus Rerych, Institut für Gestaltungs- und Wirkungsforschung, Tu-Wien. Zugriff auf Online 28. November 2007.
  9. ^ Conrad Weisert, Wasserfallmethode: Es gibt so etwas!
  10. ^ Barry Boehm (1996)., "Ein Spiralmodell der Softwareentwicklung und -verbesserung". Im: ACM Sigsoft Software Engineering Notizen (ACM) 11 (4): 14-24, August 1986
  11. ^ Richard H. Thayer, Barry W. Boehm (1986). Tutorial: Software -Engineering -Projektmanagement. Computer Society Press of the IEEE. S.130
  12. ^ Barry W. Boehm (2000). Schätzung der Softwarekosten mit Cocomo II: Band 1.
  13. ^ Lübke, Daniel; Van Linder, Tammo (2016). "Modellierungstestfälle in BPMN für die verhaltensgetriebene Entwicklung". IEEE -Software. 33 (5): 15–21. doi:10.1109/ms.2016.117. S2CID 14539297.

Externe Links