Der Healthcheck für Softwareprojekte
•Als PPTX, PDF herunterladen•
1 gefällt mir•305 views
Innerhalb eines Softwareprojektes geht es nicht vorrangig um Quellcode. Dieser ist meist eher das End- oder Zwischenprodukt verschiedenster externer Einflüsse. Zu solchen Einflüssen zählen natürlich die Anforderungen und die Zusammensetzung des Projektteams, aber beispielsweise auch der Zeitrahmen innerhalb dem eine Leistung zu rbringen ist, die fachliche Domäne, sowie das Alter des bestehenden Systems.Im Rahmen dieses Vortrags sollen die Herausforderungen bei der Bewertung von Softwaresystemen skizziert und ein Vorgehen erläutert werden, mit dem es möglich ist Risiken innerhalb der Code Basis, aber auch der Projektzusammensetzung zu erkennen. Denn nur wenn man konkrete Risiken kennt, kann man auch Maßnahmen einleiten um jenen effektiv zu begegnen.
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Ähnlich wie Der Healthcheck für Softwareprojekte
Ähnlich wie Der Healthcheck für Softwareprojekte (20)
Mehr von Hendrik Lösch
Mehr von Hendrik Lösch (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (6)
Der Healthcheck für Softwareprojekte
- 7. Antoine de Saint Exupéry
- 8. •Zieldefinition •Rahmenbedingungen •Vision Vorbesprechung •Befragen •Messen •Vergleichen Analyse •Problemstellen aufzeigen •Risiken bewerten •Lösungen aufzeigen •Aufgaben priorisieren Handlungsempfehlung •Zusammenfassung in Kurzform •Detaillierte Begründung in Schriftform Ergebnispräsentation
- 9. • • • • • •
- 11. • • • • •
- 13. • • • • •
- 14. • • • •
- 16. • • • • • ✘ Geschäftslogik aufrufen Konvertiere Daten aus Client 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));
Hinweis der Redaktion
- 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.
- 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.
- 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?
- 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.
- Top 10 der komplexesten Klassen aufstellen -> dort gibt es höchst wahrscheinlich noch weitere Fehler
- 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.
- 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.
- 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.
- Zwei verschiedene Ergebnisdokumentationen: Eine Zusammenfassung als Powerpoint die die wichtigsten Punkte herausarbeitet. Eine Ausführliche Dokumentation als Word oder Wikieintrag.
- 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.
- 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.
- 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.