-
Lehmans Laws nennen
- Law 1: Continuous Change - Systeme in Real-World Environment muessen sich immer aendern
- Law 2: Increasing Complexity - Stuktur von System wird mit jeder Entwicklungsiteration komplexer.
-
Welche Faktoren von Warungskosten gibt es?
- Alter von Software
- Skills und Knowledge von Entwicklern
- Stability von Wartungsteam
-
Was ist der Hauptaufwand bei Wartung?
- Understanding frisst 50% der Zeit
- Zweite 50% ist Coding, Testing und Dokumentation
-
Welche zwei Arten von Traceability gibt es?
- Forward Traceability - Trace Requirements to Software Artefacts - Architecture, Code, Test Plan. Ich habe eine Anforderung - ich ueberlege, wie wird diese Anforderung umgesetzt.
- Backward Traceability - trace Requirements to Source (Stakeholder) - Person, Institution, Law. Wo kommt die Anforderung her? Ist es noch aktuell?
-
Welche drei Arten von Aenderungen gibt es?
- Korrektiv: Bugfix, Fix design errors.
- Adaptiv: Switch Software und Hardware Platform, neue Frameworks und Libraries. Adapt auf Evolution.
- Perfektiv: Neue Implementierungen oder Aenderungen in Funktionalitaet. (65%)
-
Wie kann man guten Software-Qualitaet erreichen?
- Softwarearchitektur auswahlen und konsisten bilden
- Designprobleme identifizieren und korrigieren
- Unit Tests, Integration Tests, E2E tests, hoehe Testcoverage
- Linters
- Dokumentation
- SOLID, KISS, DRY
- Code-Review und Dokumentation-Review
- CICD mit Tests
- Metriken erstellen und optimieren.
-
Wie kann man erkennen dass die Software schlechte Qualitaet hat?
- Design Metriken
- schlechte oder keine Dokumentation
- Anti Patterns, Designprobleme
- Bad Smells
- keine Tests
-
Was ist External Quality?
- Customers Perspective - Quality of the Product
- Beispiel: ob man bequem in Online-Shop Produkt kauft
-
Was ist Internal Quality?
- Internal Perspective - Quality of the Architecture and Design
- Beispiel: Maintability, Bugs Rate
-
Was ist Bad Smell?
- Buzzword fuer Designprobleme - Strukturen in System, die negativ auf Wartbarkeit auswirken
-
Was sind die Statements im Kontext von Software Evolution
- Statement ist logische Einheit in code
x = 5; y = 10; z = x + y; - 3 Statements, 1 LOC- x = 5;
y = 10;
z = x + y; - 3 Statements, 3 LOC
-
Over-Engineering vs Under-Engineering
- An over-engineered software is more flexible and more sophisticated than it needs to be, so as to accommodate future changes that never come
- Difficult to understand and learn
- An under-engineered software is poorly designed and lacks the needed flexibility to accommodate the simplest changes
- Expensive to maintain with longer evolution cycles
-
What is Technical Debt?
- Technical debt is a metaphor referring to the eventual consequences of poor system design, software architecture or software development within a codebase
- If the debt is not repaid, then it will keep on accumulating interest, making it hard to implement changes later on.
- Refactoring TODOs, Documentation TBD etc
