Professionelles Software Engineering

Software Engineering: Fakten, Best Practices (und allzu Naives)

Die folgende Sammlung kurzer Aufsätze zum Thema Best Practices in Software Engineering sollte jeden interessieren, der bestrebt ist

• aus der Erfahrung anderer zu lernen,
• bekannte, aber doch immer wieder beobachtete Fehler gezielt zu vermeiden und
• Modeerscheinungen (wie z.B. Agile Methodik) auf das zu reduzieren, was daran wirklich Fortschritt bedeutet.
  
  

Als Modeerscheinung und allzu naiv bezeichne ich alles, was

• berechtigter Anforderungen wegen entstand,
• was breit diskutiert (und als Wundermittel angepriesen) wird,
• was aber dennoch — in der eben jetzt verwendeten Form — keinen Bestand haben kann (da noch viel zu wenig durchdacht).
  
  

UML etwa, Extreme Programming, oder im Agile Manifesto aufgestellte Handlungsanleitungen sollte man verwenden wie Salz in der Suppe — die Suppe selbst lässt sich dadurch auf keinen Fall ersetzen.


Wer das dennoch versucht, handelt zu naiv.

Man wird dann mit viel Aufwand wenig Nützliches — oder gar Chaos — produzieren (!)

Dass die Erfinder jener Konzepte das nicht einsehen wollen (und Studenten ebenso wie Hochschullehrer ihnen blind folgen — also nicht ausloten, wo solche Techiken angebracht oder nicht angebracht sind), dient ganz sicher nicht der schnellen Fortentwicklung von methodischem Fortschritt im Software Engineering.



Stichworte (Links)
und was man dahinter diskutiert findet:

Fakten:

• Software Engineering als Aufgabe
  
  Software Engineering treffend definiert ... (8 Seiten, 2004) und wie erfolgreich man damit ist
   
• Unverzichtbares:
  
  Die drei Eckpfeiler für den Erfolg jeden Software-Projekts ...
   
• Fatale Projektmanagement Fehler:
  
  Warum Projekte scheitern ...
   
• Ein oft unterschätzter Kostentreiber:
  
  Zu spät beginnende Qualitätssicherung kommt allzu teuer ...
   
• Projektübergreifend ist wichtig:
  
  Ständige Verbesserung der Prozessreife ...
  
   

Modeerscheinungen:

• Zu naive agile Methodik:
  
  Die nun schon mehr als 10 Jahre anhaltende Diskussion über Agile Methodik tritt auf der Stelle. Hier wird diskutiert, warum das so ist und was uns aus dieser Sackgasse herausführen kann ...
   
• Agile Methodik verstehen:
  
  Vorteile und Gefahren agiler Methodik. Wer die Gefahren ignoriert, handelt allzu naiv ...
   
• Be agile – think beyond the Agile Manifesto:
  
  Das Manifest muss endlich als Sackgasse erkannt werden: Seine Prinzipien werden zu Gift, wo sie mehr als nur Salz in der Suppe sind ...
   
• Die richtige Definition agiler Ziele:
  
  Sie sollte nur darüber sprechen, was es zu erreichen gilt ...
  Mehr und mehr gute Wege dorthin zu finden ist eine ganz andere Sache ...
  
   

Best Practices zu:

• Software Design:
  
  Empfehlenswerte Techniken, Software-Design zu erstellen, zeichnen sich dadurch aus, dass man schnell vorankommt und das Entwurfsergebnis dann übersichtlich und wartungsfreundlich notiert hat. Spitzenreiter solcher Techniken sind:
  
  
  • [1]   ERD Notation — Königsweg für Datenmodellierung
  • [2]   OOD Notation — zum Entwurf objektorientierter Klassenstruktur
  • [3]   Specification Cards — optimal für top-down Entwurf von Architektur und Schnittstellen
  • [4]   Collaboration Cards — sehr gutes Template für semi-formales Interaktionsdesign
  
   
• Code Architecture:
  
  Think hard to avoid writing code at all ...
  
  
  • [1]   Reuse or generate — Best Code is No Code: 7 ways to avoid errors by programming less ...
  
   
• Software Test:
  
  Stand der Kunst (2011) in Sachen Software Test ...
  
  
  • [1]   Testphasen — ein allgemein anerkanntes Testmodell ...
  • [2]   SOA Test — dazu braucht man ein modifiziertes Testmodell ...
  • [3]   ISTQB — was jeder Tester wirklich wissen sollte ...
  • [4]   Testautomatisierung — Stand der Kunst in 2011 ...
  • [5]   Testwerkzeuge — und ihre Einordung ...
  • [6]   Werkzeugeinführung — eine ganz eigene Herausforderung ...
  • [7]   Testtreiber — How to design Team and Drivers ...
  • [8]   Testtreibergüte — eine Checkliste ...
  • [9]   Testabdeckung — warum es wichtig ist, sie messbar zu machen ...
  • [V]   Testverwaltung — gute und weniger gute Alternativen hierfür ...
  
   
• Dokumentationstechnik:
  
  Seitdem es HTML gibt, kann (und sollte) man verlangen, dass sämtliche Software-Dokumentation — insbesondere jene, die für Entwickler, Tester und Support bestimmt ist — nicht als Aufsatz vorliegt sondern stattdessen als eine Menge aus logischer Sicht hierarchisch angeord­neter Dokumentationsatome, deren Beziehung zueinander automatisch erkennbar ist. Sie sollten in MS Office pflegbar und zudem jederzeit automatisch als Webauftritt präsentierbar sein.
  
  Geeignete Konventionen für Namen und Specification Templates können sicherzustellen, dass solche Dokumentation
  
  
  • automatisch indizierbar,
  • automatisch durch Hyperlinks verknüpfbar und auch
  • automatisch auf formale Lücken und formale Konsistenz hin prüfbar ist.
    
    
  
  Project Web Generator (docs2web.exe) ist Prototyp eines all diese Anforderungen unterstützenden Werkzeugs.

Das professionellste Vorgehensmodell:

Bester Kandidat hierfür ist in meinen Augen der Prozess SST (Specify, Subcontract, Test), denn:

• Er unterstützt gezielt ein 4-Augen-Prinzip.
• Er liefert Software, die auch langfristig ausreichend gut dokumentiert ist (und damit gut wartbar).
• Spiralartig angewandt und kombiniert mit KANBAN sowie einem geeigneten Change Management Prozess unterstützt er auch Agile Projektabwicklung.

stw5123EPA — Engineering . Practices . Agile — News?

Mehr + B G E + S H A + More