Downloaden Sie, um offline zu lesen
Hochgeladen vonHendrik Lösch
Der Healthcheck für Softwareprojekte
Das Dokument beschreibt einen strukturierten Ansatz zur Analyse und Optimierung von Geschäftsprozessen, der von der Zieldefinition über die Identifizierung von Problemstellungen bis zur Präsentation von Ergebnissen reicht. Es werden Methoden zur Datenerhebung und -verarbeitung dargestellt, um Effizienz zu steigern und Risiken zu bewerten. Zudem werden spezifische technische Aspekte bezüglich der Datenhaltung und des User Interfaces behandelt.
Der Healthcheck für Softwareprojekte
- 3.
- 4.
- 7. Antoine de SaintExupéry
- 8. •Zieldefinition •Rahmenbedingungen •Vision Vorbesprechung •Befragen •Messen •Vergleichen Analyse •Problemstellen aufzeigen •Risiken bewerten •Lösungenaufzeigen •Aufgaben priorisieren Handlungsempfehlung •Zusammenfassung in Kurzform •Detaillierte Begründung in Schriftform Ergebnispräsentation
- 9.
- 11.
- 13.
- 14.
- 15.
- 16. • • • • • ✘ Geschäftslogik aufrufen Konvertiere Daten ausClient Model in Domain Model Konvertiere Daten aus Domain Model in Client Model Bereite Daten für Transport zum Client auf Gib Ergebnis an Client weiter Ermittle Daten anhand der Nutzereingabe Gib Daten an Client weiter Berechtigung prüfen Berechnung Berechtigung prüfen Daten in gloablen Kontext übertragen
- 17.
- 18. • • • • • • Method’s CC %of coverage required to be below CRAPpy threshold 0 – 5 0% 10 42% 15 57% 20 71% 25 80% 30 100% 31+ No amount of testing will keep methods this complex out of CRAP territory.
- 19. • • • • Publications = repository.GetPublications().Select(x =>new PublicationViewModel(x)).ToList(); != Publications = repository.GetPublications().Select(x => new PublicationViewModel(x));
- 20.
- 25.
Hinweis der Redaktion
- #5 Features bieten dem Kunden sichtbare Mehrwerte, daher müssen sie nicht verteidigt werden. Wartungs- und Reparaturarbeiten sind unsichtbar und daher schwer für Außenstehende zu bewerten.
- #9 Irgend wann kommt man an den Punkt, da größere Umbauarbeiten notwendig sind. Für diese braucht man einen Plan da sie sonst mehr Schaden anrichten. Für einen Plan braucht man eine Bestimmung des Ist-Zustandes -> Healthcheck.
- #10 Vorbesprechung: Diese Dinge sollten im Vorfeld festgestellt werden und nicht erst während man den Healthcheck bereits durchführt. Wer steht zur Verfügung? Welche Technologien, Sprachen, Frameworks werden im Projekt eingesetzt? Welches System wird betrachtet und welche anderen Systeme gibt es noch, die mit diesem System interagieren? Welche Aspekte werden explizit nicht betrachtet? Gibt es bestimmte Arbeitsabläufe die von der Software abgedeckt werden? Lässt sich schon eine Aussage darüber treffen „wie groß“ das Projekt ist. Soll die Software auf technische Schwächen (Speicherlecks, …) oder strukturelle Schwächen (Architektur) untersucht werden?
- #14 Kontextsichten zeigen den Zusammenhang des Systems mit seiner Umgebung aus einer Vogelperspektive. Hier zeigen Sie die Schnittstellen zu Nachbarsystemen, die Interaktionen mit wichtigen Stakeholdern sowie die wesentlichen Teile der umgebenden Infrastruktur. Diese Sicht können Sie als „Vision“ etwas abstrakter betrachten als die übrigen Sichten10. Bausteinsichten – Wie ist das System intern aufgebaut? Bausteinsichten zeigen die statischen Strukturen der Architekturbausteine des Systems, Subsysteme, Komponenten und deren Schnittstellen. Sie können (und sollten!) die Bausteinsichten top-down entwickeln, ausgehend von einer Kontextsicht. Die letzte mögliche Verfeinerungsstufe der (Baustein-)Zerlegung bildet der Quellcode. Bausteinsichten unterstützen Projektleiter und Auftraggeber bei der Projektüberwachung, dienen der Zuteilung von Arbeitspaketen (in Form von Architekturbausteinen) an Teams und Mitarbeiter und fungiert darüber hinaus als Referenz für Software-Entwickler. Laufzeitsichten – Wie läuft das System ab? Die Laufzeitsichten beschreiben, welche Bausteine des Systems zur Laufzeit existieren und wie sie zusammenwirken. Im Gegensatz zu der statischen Betrachtungsweise bei den Bausteinsichten beschreiben Sie hier dynamische Strukturen. Verteilungssichten (Infrastruktursichten) – In welcher Umgebung läuft das System ab? Diese Sichten beschreiben die Hardwarekomponenten, auf denen das System abläuft. Sie dokumentiert Rechner, Prozessoren, Netztopologien und -protokolle sowie sonstige Bestandteile der physischen Systemumgebung. Die Infrastruktursicht zeigt das System aus Betreibersicht.
- #29 Top 10 der komplexesten Klassen aufstellen -> dort gibt es höchst wahrscheinlich noch weitere Fehler
- #39 Es darf nicht vergessen werden was man erreichen will. Daher unbedingt vorher das Ziel klären, dann die Analyse durchführen, daraus priorisierte Aktionen ableiten und danach in die Umsetzung gehen. Erst mit der Umsetzung wird etwas geändert und somit können damit auch Probleme entstehen.
- #40 Argumente müssen begründet werden. Man sollte nach Möglichkeit nicht als Gefahr auftreten. Es gibt häufig Menschen die von der aktuellen Situation profitieren. Bewertungen werden evtl. instrumentalisiert und können über die berufliche Zukunft einzelner Personen entscheiden.
- #41 Ausreichend Zeit einplanen (meist etwa 5 bis 10 Tage für Systeme die man nicht kennt). Es sollten am besten zwei, aber nicht mehr als drei Personen sein die die Bewertung durchführen. Am besten mit verschiedenen Personengruppen sprechen die am Projekt beteiligt sind, dazu zählen auch Nutzer und Tester.
- #42 Zwei verschiedene Ergebnisdokumentationen: Eine Zusammenfassung als Powerpoint die die wichtigsten Punkte herausarbeitet. Eine Ausführliche Dokumentation als Word oder Wikieintrag.
- #43 Metriken deuten auf eine Tendenz hin. Ergebnisse kann man nur mit entsprechender Erfahrung heraus lesen und in dem man sie in ein Verhältnis zu einander stellt.
- #44 Es ist wichtiger das eine Sache funktioniert. Es ist nicht so wichtig, dass das neuste Framework oder Pattern verwendet wird. Wir sollten Dinge ohnehin so lassen wie sie sind, wenn die (zukünftigen) Anforderungen eine Änderung nicht direkt erzwingen.
- #53 Fachlicher Druck, wenn der Auftraggeber auf die Projektbeteiligten Druck ausübt, neue Fachlichkeiten schnell und bevor technische Aufräumarbeiten abgeschlossen sind, geliefert zu bekommen. Ungenügende qualitätssichernde Prozesse, wenn es in einem Projekt keine qualitätssichernden Prozesse gibt (oder diese nicht gelebt werden), welche die Technische Schuld laufend messen und Verbesserungsmaßnahmen einleiten. Ungenügendes technisches Wissen, um technische Entscheidungen treffen zu können, welche die Technische Schuld nicht erhöhen und im Optimalfall reduzieren. Ungenügende Kommunikation der gewählten technischen Lösungen und ihrer Hintergründe. Die Kommunikation kann auf vielerlei Arten erfolgen, beispielsweise durch selbsterklärenden Code, Dokumentation, Diagramme, Videos etc. Parallele Entwicklung in eigenen Branches (beispielsweise Featurebranches) führt zu erhöhten Zusammenführungsaufwänden und somit Technischer Schuld. Hintangestelltes Refactoring, wenn in Codeteilen, welche verbesserungswürdig sind, weiter Fachlichkeiten umgesetzt werden, ohne davor die Verbesserungen umzusetzen. Je mehr diese notwendigen Refactorings verzögert werden, desto aufwändiger werden sie bzw. die Umsetzung von Fachlichkeiten.