1 / 67

10 Gründe für das Fehlschlagen von Softwareprojekten

10 Gründe für das Fehlschlagen von Softwareprojekten . Wer bin ich?. Thomas Schissler Software-Architekt und Projektleiter artiso AG Schwerpunkte sind Team Foundation Server Entwicklungsprozesse Software-Architektur und Software Design

zoe
Download Presentation

10 Gründe für das Fehlschlagen von Softwareprojekten

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Thomas Schissler, artiso AG 10 Gründe für das Fehlschlagen von Softwareprojekten

  2. Wer bin ich? • Thomas Schissler • Software-Architekt und Projektleiter artiso AG • Schwerpunkte sind • Team Foundation Server • Entwicklungsprozesse • Software-Architektur und Software Design • Leiter der .net Developergroup Ulm (www.dotnet-ulm.de) • Blog : http://www.artiso.com/problog

  3. Wer sind Sie? Was machen Sie? • Produktentwicklung • Auftragsprogrammierung • Interne Entwicklung

  4. Wer sind Sie? Welche Position haben Sie? • Entwickler • Projektleiter • Sonstiges?

  5. Wer sind Sie? Wie definieren Sie ein fehlgeschlagenes Software-Projekt?

  6. Wer sind Sie? Waren Sie schon mal an einem fehlgeschlagenen Software-Projekt beteiligt? • Termin oder Budget um mehr als 50% überschritten • Termin oder Budget um mehr als 100% überschritten • Kunde unzufrieden

  7. 1 Zunehmende Komplexität

  8. Problemsituationen • Bewährte Prozesse werden beibehalten obwohl das Umfeld sich verändert hat • Moderne Softwareentwicklung erfordert geänderte Team- und Projektstrukturen die aber wiederum geeignete Prozesse voraussetzen.

  9. Komplexität

  10. Komplexität beherrschen • Spezialisten vs. Generalisten • Über Prozesse relevante Themen addressieren • Risiken erkennen und vorbeugen • Abstraktion durch Tool-Unterstützung • Komplexität reduzieren • Dokumentation • Architektur

  11. 2 Unklare Spezifikation

  12. Problemsituationen • Kunde akzeptiert implementierte Lösungen nicht • Fehlende Basis für aufwandsabschätzung • Entwickler hat keine genaue Beschreibung der Funktion für die Implementierung • Tester stellen Spezifikationslücken fest • Ewige Nacharbeiten

  13. Textliche Spezifikation Kunden sollen gelöscht werden können. Der Lösch-Vorgang kann durch das Kontext-Menü, durch ein Icon in der Symbol-Leiste oder durch die Entfernen-Taste auf der Tastatur ausgelöst werden. Beim Löschen eines Kunden soll zunächst geprüft werden, ob der Kunde Aufträge zugeordnet hat. Ist dies nicht der Fall, kann der Kunde sofort gelsöcht werden. Andfernfalls muss geprüft werden, ob alle Aufträge die dem Kunden zugeordnet sind abgeschlossen sind. Hat der Kunde nicht abgeschlossene Aufträge zugeordnet, so kann der Kund zu diesem Zeitpunkt nicht gelöscht werden und dies soll durch eine entsprechende meldung angezeigt werden. Bei ausschließlich abgeschlossenen Aufträgen soll zunächst der Anwender gefragt werden, ob alle Aufträge zum Kunden ebenfalls gelöscht werden sollen. Wird diese mit Ja bestätigt, werden zunächst die Aufträge und anschließend der Kunde gelöscht. Andernfalls wird der Lösch-Vorgang für den Kunden abgebrochen.

  14. Workflow Diagramme

  15. Funktionsbaum

  16. Test als Spezifikation

  17. 3 Unzureichende Planung

  18. Problemsituationen • Aufwand und Termine werden nur grob geschätzt, der Kunde pocht aber auf die Einhaltung • Der Aufwand um die Planung zu pflegen ist viel zu hoch • Der aktuelle Projektstatus wird aus dem Bauch beurteilt

  19. Aufwandsabschätzung • Voraussetzung ist eine detaillierte Spezifikation • Anforderungen werden in Lösungen überführt • Lösungen werden verfeinert und in Aufgaben heruntergebrochen • Aufwand für Aufgaben abschätzen (in Stunden) • Tests wie Aufgaben einplanen

  20. Aufwandsabschätzung DEMO

  21. Terminplanung

  22. 4 Fehlendes Projekt-Controlling

  23. Problemsituationen • Budget ist fast aufgebraucht, aber es fehlen noch wichtige Funktionen • Zugesagte Termine können nicht eingehalten werden • Die Funktionen sind fertiggestellt aber es bleibt keine Zeit zum Testen • Probleme im Projekt werden zu spät erkannt

  24. Projektcontrolling = Plan – Ist-Vergleich

  25. Statusaktualisierung

  26. Zeit-Controlling

  27. Budget-Controlling DEMO

  28. 5 Entscheidungen aufschieben

  29. Problemsituationen • Längst bekannte Probleme verursachen einen hohen Anpassungsaufwand • Anpassungen und Fehlerbehebungen müssen über Gewährleistung erbracht werden • Architektur- oder Technologieentscheidungen stellen sich als problematisch heraus

  30. Probleme möglichst früh addressieren • Regelmäßige Reviews einführen • Erkannte Probleme dokumentieren und deren Lösung planen, nicht aufschieben

  31. 6 Kommunikation

  32. Problemsituationen • Missverständnisse führen zu Mehraufwand • Keine konsistente Code-Qualität bei mehren Entwicklern • Kommunikation zwischen Tester und Entwickler ist zu aufwändig

  33. Contract First Design

  34. Kommunikation Tester  Entwickler

  35. 7 Qualitätsprobleme

  36. Problemsituationen • Die Entwicklung verläuft planmäßig, jedoch das Testen und die Fehlerbehebung dauert wesentlich länger als angenommen. • Der Kunde findet im Test-Betrieb zu viele Fehler • Nach Monaten wird festgestellt, dass Ergabnisse, mit denen gearbeitet wurden, falsch waren.

  37. Testplanung Planung Implementierung Testen

  38. Testplanung Planung Implementierung Testen

  39. Testplanung Planung Implementierung

  40. Testplanung Planung Implementierung Testen

  41. Testplanung Iteration

  42. Test-Methoden

  43. Testaufwand

  44. 8 Feature Creep

  45. Problemsituationen • Budget und Termin reichen nicht aus, als Begründung werden ungeplante zusätzliche Funktionen angegeben – aber welche waren das nochmals genau? • Die Architektur-Basis passt irgendwann nicht mehr zu den aktuellen Funktionen

  46. Sender Sender Sender UI Driven Development

  47. Sender Sender Sender UI Driven Development

  48. Sender Sender Sender UI Driven Development

  49. Sender Sender Sender UI Driven Development

More Related