Wenn Sie kurz davor stehen, Software in Auftrag zu geben, sollen Sie einen Prozess freigeben, den Sie selbst nie durchlaufen haben: eine Discovery-Phase, eine Reihe von Sprints, einen QA-Zyklus, einen Release-Plan. Zu wissen, was diese Begriffe abdecken, ist das, was einen realistischen Plan von einem teuren unterscheidbar macht, und ein Team, das dies schon gemacht hat, von einem, das rät.
Softwareentwicklung ist der Prozess des Planens, Entwerfens, Bauens, Testens, Auslieferns und Wartens von Software. Er läuft in wiederkehrenden Zyklen statt in einem geraden Durchgang und umfasst Entwickler, QA-Ingenieure, Designer sowie einen Produkt- oder Projektmanager. Der Begriff reicht von einer einzelnen mobilen App bis zu einer mehrjährigen Unternehmensplattform.
Dieser Leitfaden zeigt, wie dieser Prozess tatsächlich aussieht, wer was macht, welche Methoden Ihnen begegnen werden, welche Hauptarten von Software gebaut werden, was die Kosten bewegt und über welche Zusammenarbeitsmodelle Sie das einkaufen können. Redwerk hat diesen Prozess seit 2005 in über 170 Projekten durchlaufen, in der maßgeschneiderten Softwareproduktentwicklung für Kunden in Nordamerika und Westeuropa.
Was Softwareentwicklung in der Praxis bedeutet
Im Kern ist Softwareentwicklung ein Zyklus mit sechs Phasen: planen, entwerfen, bauen, testen, ausliefern, warten.
Entscheidend ist, dass er sich wiederholt. Ein Team plant einen kleinen Teil des Produkts, baut ihn, lernt dabei etwas, das den Plan verändert, und startet die nächste Runde mit diesem neuen Wissen.
Das ist das Nützlichste, was ein nicht technischer Entscheider verinnerlichen kann. Wenn ein Anbieter einen Plan präsentiert, in dem jede Phase genau einmal und der Reihe nach abläuft, ohne Rückkopplung dazwischen, beschreibt er ein Dokument, keinen Lieferprozess.
Wer tatsächlich beteiligt ist
Ein typisches Projektteam hat fünf Rollen, und Sie werden ihnen in der Regel allen begegnen:
- Entwickler schreiben den Code. In den meisten Projekten teilen sie sich in Frontend (was der Nutzer sieht) und Backend (Daten, Logik, Integrationen) auf.
- QA-Ingenieure testen die Software bewusst und systematisch und suchen nach den Stellen, an denen sie bricht, bevor Ihre Nutzer sie finden.
- Designer legen fest, wie das Produkt aussieht und wie sich ein Nutzer darin bewegt. Bei Business-Software zählt das mehr, als viele erwarten, denn ein internes Werkzeug, in dem sich niemand zurechtfindet, wird nicht genutzt.
- Ein Produkt- oder Projektmanager verantwortet Umfang, Reihenfolge und Zeitplan und ist meist Ihr Hauptansprechpartner.
- Ein technischer Kundenverantwortlicher ist bei ausgelagerter Arbeit die erfahrene Person, die für die Zusammenarbeit insgesamt geradesteht, nicht für einen einzelnen Sprint.
Nach der Bedeutung des Begriffs Softwareentwickler wird viel gesucht, und die ehrliche Antwort lautet: Ein Entwickler schreibt und pflegt den Code, aber funktionierende Software auszuliefern braucht auch die anderen vier Rollen. Ein Team, das nur aus Entwicklern besteht, ohne QA und ohne jemanden, der den Umfang verantwortet, ist eine häufige und teure Form des Scheiterns.
Der Softwareentwicklungsprozess Schritt für Schritt
Diese Phasen wiegen nicht gleich schwer. Die frühen sind günstig, wenn man sie richtig macht, und teuer, wenn man sie wiederholen muss, während in den späteren der sichtbare Fortschritt passiert und der Großteil des Budgets ausgegeben wird. Wie viel Zeit ein Anbieter den ersten beiden einräumt, ist ein brauchbares Signal dafür, wie er arbeitet.
Discovery und Scoping
Das ist der Schritt, den die meisten Projekte überspringen und später bereuen. In der Discovery legen Sie fest, was die Software leisten muss, wer sie nutzt, womit sie sich verbindet und was “fertig” bedeutet. Sie liefert einen Umfang, gegen den sich tatsächlich schätzen lässt.
Ihn zu überspringen spart kein Geld. Es verschiebt die Kosten an eine schlechtere Stelle, denn die Anforderungen werden trotzdem entdeckt, nur später, mitten im Bau, wenn ein Richtungswechsel bedeutet, Arbeit wegzuwerfen.
Sie brauchen keine vollständigen Anforderungen, um zu starten. Die meisten Kunden haben sie nicht. Was Sie brauchen, ist ein strukturierter Weg, sie zu finden, und genau dafür ist eine Discovery-Phase da, sowie ein schriftliches Ergebnis, dem alle zustimmen, und das liefert eine funktionale Leistungsspezifikation.
Design und Architektur
Hier passieren zwei Dinge. Designer erarbeiten die Oberfläche und die Nutzerflüsse. Ingenieure erarbeiten die Architektur: den Stack, das Datenmodell, wie das System in Teile zerlegt wird und wie es mit Wachstum umgeht.
Architekturentscheidungen sind die teuren zum Zurückdrehen. Die falsche Datenbankstruktur zu wählen oder zwei Systeme zu koppeln, die getrennt hätten bleiben sollen, ist eine Entscheidung, für die Sie noch lange nach dem Launch zahlen. Ein Team, das schon etwas Ähnliches gebaut hat, weiß bereits, wo diese Art von Entwurf typischerweise bricht, und genau dafür bezahlen Sie es in dieser Phase.
Bauen, Testen und Ausliefern
Moderne Lieferung ist iterativ. Das Team baut einen funktionierenden Ausschnitt des Produkts, testet ihn und stellt ihn irgendwo bereit, wo Sie darauf klicken können, und wiederholt das. Sie sollten erwarten, innerhalb von Wochen etwas Funktionierendes zu sehen, nicht erst am Ende.
Das Testen läuft parallel zum Bauen, nicht danach. QA schreibt Tests, während Funktionen entstehen, sodass ein am Dienstag gefundener Fehler eine Stunde kostet, statt drei Monate später aufzutauchen, verwoben mit Code, der inzwischen darauf aufbaut.
Deployment ist eine eigene Disziplin. Code zuverlässig, wiederholbar und umkehrbar auf Server zu bringen, unterscheidet ein Release, das Sie an einem Donnerstagnachmittag machen können, von einem, das ein Wochenende und einen Rollback-Plan braucht.
Für die phasenweise Aufschlüsselung des vollständigen Lebenszyklus siehe Redwerks Leitfaden zu SDLC Best Practices. Wenn Sie bereits einen Prozess haben und wissen wollen, ob er standhält, ist die SDLC-Audit-Checkliste die diagnostische Variante.
Wartung und Iteration
Software ist mit dem Launch nicht fertig. Abhängigkeiten altern, Sicherheitspatches erscheinen, Browser ändern sich, und Ihr Geschäft braucht Dinge, die der ursprüngliche Umfang nie vorgesehen hat. Den Bau zu budgetieren, aber nicht die Wartung, ist einer der verlässlichsten Wege, zwei Jahre später eine Anwendung zu haben, die niemand mehr gefahrlos anfassen kann.
Agile, Wasserfall und Hybrid im Vergleich
Die Methode ist die Art, wie das Team den Zyklus organisiert. Drei Formen decken fast alles ab, was Ihnen angeboten wird.
Agile
Kurze Zyklen von zwei bis vier Wochen, die jeweils lauffähige Software liefern. Der Umfang passt sich an, während man lernt.
Produktarbeit, bei der sich Anforderungen entwickeln, und die meiste kommerzielle Software
Schwerer als eine feste Zahl im Voraus zu kalkulieren, und es braucht Ihre Mitwirkung über die gesamte Laufzeit
Wasserfall
Phasen laufen nacheinander, jede wird vor Beginn der nächsten abgenommen. Der Umfang steht zu Beginn fest.
Arbeiten mit festem Umfang, regulierte Umgebungen, Projekte mit wirklich vollständiger und stabiler Spezifikation
Änderungen sind teuer, und Probleme zeigen sich spät, weil das Testen erst gegen Ende kommt
Hybrid
Fester Umfang und festes Budget auf Vertragsebene, agile Lieferung darin
Kunden, die Budgetsicherheit brauchen, aber etwas wirklich Neues bauen
Erfordert Disziplin dabei, was als im Umfang gilt, sonst wird daraus Wasserfall mit Sprints
Agile Softwareentwicklung ist der Standard für die meiste moderne Produktarbeit, und das aus gutem Grund. Sie ist nicht automatisch die richtige Antwort. Wenn Sie gegen eine regulatorische Spezifikation bauen, die sich nicht ändern wird, erzeugt die Zeremonie zweiwöchiger Zyklen Aufwand, ohne viel Erkenntnis zu bringen.
Die wichtigsten Arten der Softwareentwicklung
Das Wort “Software” verbirgt große Vielfalt, und die Art bestimmt die Werkzeuge, das Team, den Zeitrahmen und die Randbedingungen.
- Webentwicklung baut Anwendungen, die im Browser laufen. Die häufigste Form für Business-Software, weil es nichts zu installieren gibt und Updates alle gleichzeitig erreichen. Übliche Stacks sind React, Vue.js, Angular, .NET, Django und PHP.
- Mobile Entwicklung baut für iOS und Android, entweder nativ (Swift, Kotlin) oder plattformübergreifend (Flutter). Die Randbedingungen sind die Prüfung durch die App-Stores, die Gerätefragmentierung und die Tatsache, dass Nutzer eine schlechte Verbindung haben werden.
- Desktop-Entwicklung baut Software, die auf einem Rechner installiert wird. Weiterhin die richtige Antwort für rechenintensive lokale Verarbeitung, Offline-Arbeit und tiefe Betriebssystemintegration.
- Embedded- und IoT-Entwicklung baut Software, die auf Hardware läuft, wo der Speicher knapp ist, Updates schwer auszuliefern sind und ein Fehler bedeuten kann, dass sich ein physisches Gerät im Feld falsch verhält.
Individualsoftware gegenüber Standardsoftware
Ein fertiges Produkt zu kaufen ist schneller und günstiger, und für ein gelöstes Problem wie Lohnabrechnung oder E-Mail ist es fast immer richtig. Individuell zu bauen lohnt sich, wenn der Prozess, den Sie automatisieren, wirklich spezifisch für Ihre Arbeitsweise ist, wenn der Aufwand, mehrere Standardwerkzeuge zusammenzuflicken, die Kosten eines passenden Systems übersteigt, oder wenn die Software das Produkt ist, das Sie verkaufen.
Ein sinnvoller Mittelweg ist, die kleinste Version zu bauen, die die Idee belegt, bevor Sie sich auf das vollständige System festlegen. Wie man ein MVP richtig erstellt erklärt, wie Sie das so zuschneiden, dass es Fundament bleibt und kein Wegwerfprodukt wird.
Was die Kosten der Softwareentwicklung wirklich treibt
Niemand kann Ihr Projekt allein anhand eines Kategorienamens kalkulieren. Was man Ihnen sagen kann, ist, welche Variablen die Zahl bewegen, und das sind die wichtigsten:
- Klarheit des Umfangs. Der mit Abstand größte Faktor. Ein gut spezifiziertes System lässt sich eng schätzen. Ein vages wird mit Puffer versehen, weil das Team seine Unsicherheit einpreist.
- Integrationen. Jedes externe System, an das Sie anbinden, bringt Arbeit, die schwer zu schätzen ist, weil Sie das andere Ende nicht kontrollieren. Drei Integrationen sind ein anderes Projekt als keine.
- Compliance- und Sicherheitsanforderungen. Arbeiten im Gesundheitswesen, im Finanzsektor und im öffentlichen Bereich bringen Audit-, Datenschutz- und Dokumentationspflichten mit sich, die echter Entwicklungsaufwand sind.
- Datenmigration. Jahre bestehender Datensätze sauber in ein neues System zu überführen, wird regelmäßig unterschätzt. Altdaten sind unordentlicher, als sich irgendjemand erinnert.
- Seniorität und Zusammensetzung des Teams. Erfahrene Ingenieure kosten mehr pro Stunde und meist weniger pro Ergebnis, weil die teuren Fehler architektonisch sind und früh gemacht werden.
- Designtiefe. Eine ausgefeilte, stark genutzte Kundenoberfläche ist eine andere Investition als eine interne Verwaltungsmaske für sechs Personen.
- Der Wartungsschwanz. Laufender Support, Hosting und Updates sind eine wiederkehrende Position, kein Rundungsfehler beim Bau.
Sie wollen wissen, wo Ihr eigenes Projekt landet? Redwerk erstellt kostenlose Schätzungen. Sagen Sie uns, was Sie bauen, auch wenn die Details noch grob sind, und wir melden uns mit einer realistischen Spanne und den Annahmen dahinter.
Zusammenarbeitsmodelle: wie Sie Softwareentwicklung einkaufen
Das Zusammenarbeitsmodell entscheidet, wer das Risiko trägt, dass Dinge länger dauern als erwartet. Das ist die ganze Frage, und es lohnt sich, sie zu verstehen, bevor Sie Angebote vergleichen.
Festpreis
Eine vereinbarte Summe für einen vereinbarten Umfang
Klar definierte Projekte mit stabilen Anforderungen und einem klaren Ziel
Jede Änderung wird zur Verhandlung, und das Angebot enthält einen Risikoaufschlag
Time and Materials
Für tatsächlich geleistete Stunden
Sich entwickelnder Umfang, discovery-lastige Arbeit, laufende Produktentwicklung
Braucht Vertrauen und echte Transparenz darüber, wohin die Stunden fließen
Dediziertes Team
Eine monatliche Rate für ein Team, das nur an Ihrem Produkt arbeitet
Langlaufende Arbeit, das Schließen einer Kapazitäts- oder Kompetenzlücke, für die Sie nicht einstellen können
Zahlt sich erst über Monate aus, nicht für eine kurze einmalige Aufgabe
Team-Erweiterung
Pro Spezialist, der zu Ihrem bestehenden Team dazukommt
Sie haben ein funktionierendes Team und einen Prozess und brauchen eine bestimmte Fähigkeit
Steuerung, Architektur und Ergebnis bleiben weiterhin bei Ihnen
Die Wahl folgt meist daraus, wie sicher Ihr Umfang ist. Der Festpreis belohnt Sicherheit. Time and Materials und dediziertes Team tragen der Realität Rechnung, dass Sie während des Baus dazulernen werden.
Eine ausführlichere Betrachtung, wo ein dediziertes Entwicklungsteam gegenüber den Alternativen steht, finden Sie unter Teilzeit-CTO gegenüber Softwareentwicklungsberatung gegenüber Team-Erweiterung, und zur grundsätzlichen Frage danach, ob Sie selbst bauen oder das Team einkaufen, eigene gegenüber ausgelagerter Softwareentwicklung.
Was Sie vor der Beauftragung eines externen Teams abwägen sollten
Auslagern ist nicht immer richtig, und ein Anbieter, der Ihnen etwas anderes erzählt, verkauft.
Der erste Einwand, den Menschen vorbringen, ist Wissen. Wenn ein externes Team es baut, geht dann das Verständnis, wenn der Vertrag endet? Das ist eigentlich eine Frage von Dokumentation und Übergabe. Ein Anbieter, der Dinge festhält, die Spezifikation aktuell hält und eine dokumentierte Codebasis übergibt, hinterlässt Ihnen mehr nutzbares Wissen als ein internes Team, das alles in den Köpfen von zwei Personen behalten hat. Fragen Sie jeden Anbieter, welche Dokumentation zur Zusammenarbeit gehört und wem sie am Ende gehört. Eine vage Antwort sagt Ihnen mehr als jede Verkaufspräsentation.
Behalten Sie es intern, wenn Sie bereits ein starkes Entwicklungsteam mit freien Kapazitäten haben, denn eine zusätzliche externe Gruppe erzeugt Abstimmungsaufwand, den Sie nicht brauchen.
Überlegen Sie gut, bevor Sie auslagern, wenn intern niemand Produktentscheidungen treffen kann. Ein externes Team kann ohne vollständige Anforderungen arbeiten, und ein gutes rechnet damit. Ohne was kein Team arbeiten kann, ist jemand auf Ihrer Seite, der befugt ist, Fragen zu beantworten und zu entscheiden. Fehlt das, stockt das Projekt, ganz gleich wer den Code schreibt.
Bei den Zeitplänen hat KI-gestützte Entwicklung die Grenze verschoben. Arbeit, die früher ein Quartal brauchte, kann in Wochen fertig sein, wenn das Problem gut verstanden und der Code konventionell ist, und danach darf man einen Anbieter heute fragen. Was sie nicht verkürzt hat, ist die Zeit, um sich darauf zu einigen, was gebaut wird, oder um Systeme anzubinden, die Sie nicht kontrollieren. Bei einer sehr knappen Frist für ein verbreitetes Problem kann ein Standardprodukt zu kaufen und passend einzurichten immer noch der schnellere Weg sein.
Begriffe der Softwareentwicklung, die Sie hören werden
Sprint, Backlog, technische Schulden, CI/CD, Staging, Refactoring, API. Anbieter benutzen diese Begriffe ständig und halten selten inne, um sie zu erklären.
Redwerk pflegt genau dafür ein Glossar in verständlicher Sprache: Begriffe der Softwareentwicklung, die 60 wichtigsten. Ein Blick darauf lohnt sich vor Ihrem ersten Scoping-Gespräch, denn fragen zu können “ist das in diesem Sprint oder im Backlog?” verändert das Gespräch.
Wie Redwerk diesen Prozess umsetzt
Redwerk baut seit 2005 Software, mit über 170 Kunden in Nordamerika und Westeuropa. Drei Dinge darüber, wie wir den Prozess umsetzen, sind wissenswert, wenn Sie Teams vergleichen.
Wir beginnen mit strukturierter Discovery, und wir verlangen nicht, dass Sie mit vollständigen Anforderungen ankommen. Die meisten Kunden haben sie nicht. Die Spezifikation gemeinsam zu erarbeiten ist Teil der Arbeit, keine Voraussetzung, um sie zu beginnen.
Wir besetzen nach Stack, nicht nur nach Branche. Wenn Ihr System auf .NET und Azure läuft, bekommen Sie Ingenieure, die .NET- und Azure-Systeme ausgeliefert haben, und genau das macht eine kurze Einarbeitung realistisch statt bloß wünschenswert.
Wir kommunizieren bewusst mehr als nötig. Das beständigste Thema in unseren Kundenrückmeldungen ist, dass sie immer wussten, wo das Projekt steht. Für nicht technische Entscheider, die vollständig von dem Team abhängen, das sie beauftragt haben, ist das der Unterschied zwischen einem beherrschbaren und einem nervösen Projekt.
Wenn Sie ganz am Anfang stehen und den richtigen Umfang und Ansatz geklärt haben wollen, bevor jemand Code schreibt, beginnen Sie mit Softwareentwicklungsberatung.
Häufig gestellte Fragen
Was ist Softwareentwicklung einfach erklärt?
Softwareentwicklung ist die Arbeit des Planens, Bauens, Testens und Wartens von Computerprogrammen. Sie umfasst ein Team aus Entwicklern, Testern, Designern und einem Manager, die in wiederkehrenden Zyklen arbeiten, statt einer einzelnen Person, die von Anfang bis Ende Code schreibt.
Was ist der Unterschied zwischen Softwareentwicklung und Software Engineering?
Die Begriffe überschneiden sich stark und werden oft synonym verwendet. Software Engineering betont in der Regel stärker den formalen Prozess, die Architektur und die langfristige Wartbarkeit, während Softwareentwicklung der weiter gefasste Begriff für die gesamte Arbeit am Erstellen von Software ist.
Welche Phasen hat der Softwareentwicklungszyklus?
Der Softwareentwicklungszyklus hat sechs Phasen: Planung, Design, Entwicklung, Test, Auslieferung und Wartung. In der modernen Praxis wiederholen sich diese in kurzen Zyklen, statt einmal nacheinander abzulaufen, sodass ein Team Planung und Design im Projektverlauf viele Male erneut durchläuft.
Wie lange dauert ein Softwareentwicklungsprojekt?
Das hängt vor allem vom Umfang und von der Integrationskomplexität ab. Ein Minimum Viable Product, das einen einzelnen Kernablauf belegt, ist typischerweise eine Frage von Monaten, während eine vollständige Plattform mit mehreren Integrationen, Datenmigration und Compliance-Anforderungen deutlich länger läuft. Eine Discovery-Phase ist das, was aus dieser Spanne einen echten Zeitplan macht.
Brauche ich vollständige Anforderungen, bevor ich ein Entwicklungsteam beauftrage?
Nein. Die meisten Kunden starten ohne sie. Ein gutes Team führt eine strukturierte Discovery-Phase durch, um den Umfang gemeinsam festzulegen. Was Sie brauchen, ist jemand auf Ihrer Seite, der befugt ist, während des Baus Produktentscheidungen zu treffen.
Erfahren Sie, wie wir AWE Learning geholfen haben, von einer lokalen Lösung in die Cloud zu migrieren und mit einer skalierbaren SaaS-Lösung Nutzer außerhalb der USA zu erreichen
