Artiso solutions GmbH | Oberer Wiesenweg 25 | 89134 Blaustein | info@artiso.com 10 Gründe für das...

artiso solutions GmbH | Oberer Wiesenweg 25 | 89134 Blaustein | info@artiso.com

10 Gründe für das Fehlschlagen von

Softwareprojekten

Thomas Schissler, artiso AG

Wer bin ich?

Thomas SchisslerSoftware-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

Wer sind Sie?

Was machen Sie?

Produktentwicklung

Auftragsprogrammierung

Interne Entwicklung

Wer sind Sie?

Welche Position haben Sie?

Entwickler

Projektleiter

Sonstiges?

Wer sind Sie?

Wie definieren Sie ein fehlgeschlagenes Software-Projekt?

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

1 Zunehmende Komplexität

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.

Komplexität

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

2 Unklare Spezifikation

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

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.

Workflow Diagramme

Kontext Menu Tree

Icon Symbol-

leiste

Tastatur Entf

Hat Kunde Aufträge?

Kunde löschen

Wollen Sie Aufträge löschen?

Alle Aufträge abgeschlossen

Kunde löschen

Löschen nicht möglich

Löschen? Aufträge löschenJa

Fertig

Funktionsbaum

Test als Spezifikation

3 Unzureichende

Planung

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

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

Aufwandsabschätzung

Terminplanung

4 Fehlendes Projekt-

Controlling

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

Projektcontrolling = Plan – Ist-Vergleich

Statusaktualisierung

Zeit-Controlling

Budget-Controlling

5 Entscheidungen

aufschieben

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

Probleme möglichst früh addressieren

Regelmäßige Reviews einführen

Erkannte Probleme dokumentieren und deren Lösung planen, nicht aufschieben

6 Kommunikation

Problemsituationen

Missverständnisse führen zu Mehraufwand

Keine konsistente Code-Qualität bei mehren Entwicklern

Kommunikation zwischen Tester und Entwickler ist zu aufwändig

Contract First Design

Kommunikation Tester Entwickler

7 Qualitätsprobleme

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.

Testplanung

Planung Implementierung Testen

Testplanung

Planung Implementierung Testen

Testplanung

Planung Implementierung

Testplanung

PlanungImplementierung

Testen

Testplanung

Iteration

Test-Methoden

Integration Tests

Manual Tests

UI-Tests

Unit-Tests

Testaufwand

8 Feature Creep

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

UI Driven Development

SenderSenderSender

Puffer-Verwaltung

9 Falsche Prioritäten

Problemsituationen

Punkte die für den Kunden wichtig sind, werden erst erkannt, wenn diese durch den Kunden bemängelt werden.

Probleme werden zu spät im Projekt erkannt und behoben

Entwickler fokusieren sich zu stark auf Technologie-Themen

Prioritäten richtig festlegen

Den Kunden fragen, was ihm wichtig ist

Prioritäten regelmäßig reviewen

Prioritäten im Team Kommunizieren

Prioritäten betreffen meist nicht-technische Aspekte

Requirement Management

V-Modell

User Requirements

Function Specification

Software Design

Developer Tests

Unit-Tests

Acceptance Tests

Implemen-tation

Requirements und Features

Feature

Requirement

Specification Specification

TasksTasks

RisksRisks

TestsTests

Module

Requirement Decomposition

Requirements aufnehmen

Features und Module

definieren

Spezifikation erstellen

Risiken analysieren

Aufgaben planen

Implementieren und Testen

Business Cases

Vision Use Cases

Nicht funkt. Requirements

Tasks / Testanf.

Code / Tests

Qualitäts-dokumente

SD RADT

Agiles vs. Klassisches Prozessmodell

Start ZielZiel

Agiles vs. Klassisches Prozessmodell

Start ZielZiel

10 Unterschätzte Technologie-komplexität

Problemsituationen

Durch den Einsatz einer modernen Technologie hätte Entwicklungsaufwand eingespart oder Vorteile beim Betrieb der Software realisiert werden können

Beim Einsatz einer neuen Technologie ist die Einarbeitszeit deutlich höher als geplant oder die implementierten Lösungen sind nicht ideal.

Gutes Risiko-Management, Eskalationsszenarien einplanen

Zeit für Evaluierung neuer Technologien einplanen

Durch Architektur Entkopplung ermöglichen

Fragen ???

Gerne jetzt.

Oder gerne per Mail an Tschissler@artiso.com

Mein Blog: http:// www.artiso.com/problog

Artiso solutions GmbH | Oberer Wiesenweg 25 | 89134 Blaustein | info@artiso.com 10 Gründe für das...

Documents

VS one Veranstalter: VSone 13.-14. Feb. 08 Folie 1 Copyright by Mit 3 Schichte zum Erfolg Thomas Schissler TSchissler@artiso.com

Qualitätsmanagement mit VSTS und TFS. artiso solutions GmbH | Oberer Wiesenweg 25 | 89134 Blaustein | info@artiso.com Agenda Einführung Qualitätsmanagement

Gutes und bezahlbares Wohnen heute und in Zukunft...Auf Erfolgskurs 164.838,15 € ... Rudolf Schreiner, 89075 Ulm Gebhard Lang, 89075 Ulm Thomas Schlumberger, 89134 Blaustein

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

TRIAS ALUMINIUM-UNTERKONSTRUKTION FÜR …trias-terrasse.de/downloads/BF_TRIAS_PlanenMontieren_low.pdf · TRIAS | PLANEN UND MONTIEREN Blauform GmbH | Lindenstraße 90 | 89134 Blaustein

Refactoring von Legacy Code Michael Kokonowskyj Thomas Schissler artiso AG

ich elt ist (d)eine Bühne. - fantastik-kempten.de · Es schreiben: Marla Graf, Tim Lau, Sebastian Meinl, Vinja Schade, Theresa Scheule und Frederik Schissler Die Teilnehmer besuchen

Performance-Testing als Basis für Performanceoptimierungen Thomas Schissler artiso AG

artiso solutions GmbH | Oberer Wiesenweg 25 | 89134 ...download.microsoft.com/download/F/7/E/F7E9A431-DD1D-4082-9257-E07B6BE... · artiso solutions GmbH | Oberer Wiesenweg 25 | 89134

Torcman GmbH Hauptstr. 1 89134 Blaustein Tel. (49) 7304 961020old.torcman.de/Generator/preisliste_torcman_generator_V2.2.pdf · um einen ungeregelten Generator handelt, darf dieser

Christian Binder (Microsoft) Thomas Schissler (artiso) Moderne Software- Entwicklung mit TFS 2013 und Visual Studio 2013

Übersicht und Highlights Visual Studio 2010 ALM. artiso solutions GmbH | Oberer Wiesenweg 25 | 89134 Blaustein | info@artiso.com Vorstellung Thomas Schissler

Ein Referat von Simon Schissler. James Naismith, Erfinder des Basketballs Der beliebte Sport wurde 1891 in Springfield, Massachusetts, erfunden

Thomas Schissler | MVP Visual Studio ALM, artiso AGdownload.microsoft.com/.../MVA_Moderne_Software_Entwicklung_Modul_05.pdfUML.NET Classdesigner. Workflow Foundation. Architecture

VS one Veranstalter: VSone 13.-14. Feb. 08 Folie 1 Copyright by XML-Serialisierung zur Persistierung von Objekten Thomas Schissler TSchissler@artiso.com

Erweiterungen für den TFS selbst programmieren Thomas Schissler, artiso AG

Qualitätsmanagement in der Entwicklung !?. artiso solutions GmbH | Oberer Wiesenweg 25 | 89134 Blaustein | info@artiso.com Agenda 1. Ziele und Probleme

Requirement Management in agilen Prozessen. artiso solutions GmbH | Oberer Wiesenweg 25 | 89134 Blaustein | info@artiso.com Achtung! Wasserfall = Agil

1 Testing Practices Thomas Schissler, artiso AG. 2 Vorstellung Thomas Schissler Software-Architekt und Projektleiter artiso AG Schwerpunkte sind Team

Agiles Projektmanagement mit Scrum und Userstories Thomas Schissler TSchissler@artiso.com