Was ist mit CrossTalk passiert? + Die 10 besten Artikel
Im Jahr 1987 gründete die US Air Force das Software Technology Support Center (STSC). Seine Mission war es, „Organisationen dabei zu unterstützen, Technologien zu identifizieren, zu bewerten und einzuführen, die die Qualität von Softwareprodukten, die Produktionseffizienz und die Vorhersagbarkeit verbessern“ (Quelle). Um dieses Ziel zu erreichen, gründete das STSC eine Online-Publikation namens CrossTalk: The Journal of Defensive Software Engineering, die von 1996 bis 2016 auf ihrer Website (Stsc.hill.af.mil) betrieben wurde.
Später erstellte das STSC die Website Crosstalkonline.org, auf der CrossTalk weiterhin veröffentlicht wurde. Seit 2017 ist die Seite jedoch nicht mehr zugänglich.
Was könnte damit passiert sein? Wir versuchen es herauszufinden, indem wir die Geschichte der Publikation beleuchten. Am Ende dieses Artikels werfen wir einen Blick auf die 10 wichtigsten veröffentlichten Artikel.
Die Geschichte von CrossTalk
CrossTalk begann 1988 zu erscheinen, um Methoden zu fördern, die die Entwicklung hochwertiger Software sicherstellen sollen. Laut STSC bestand das Ziel der Publikation darin, „die Zuverlässigkeit, Wartbarkeit und Reaktionsfähigkeit unserer Kampffähigkeit zu verbessern und die Leser über aktuelle politische Entscheidungen und neue Technologien im Software Engineering zu unterrichten, informieren und weiterzubilden“ (Quelle).
Unter der Leitung von Reuel Alder (Herausgeber), Tracy Stauder (Managing Editor) und Sandi Gaskin (Senior Editor) wuchs CrossTalk von etwa 200 auf 29.000 Abonnenten (Quelle).
Stsc.hill.af.mil, die Website, auf der CrossTalk ursprünglich veröffentlicht wurde, wurde im Dezember 1996 eingerichtet. Frühere Ausgaben sind hier zu finden.
Stsc.hill.af.mil beinhaltete ein Abonnementformular, Richtlinien für angehende Autoren und Themenankündigungen. Es gab außerdem eine Seite mit Kontaktinformationen des festen Redaktionsteams.
CrossTalk verblieb bis November 2010 auf der STSC-Website, bevor sie auf die eigene Domain Crosstalkonline.org umzog. Die letzte im Internet verfügbare Ausgabe von CrossTalk stammt aus dem August 2017.
Es gibt nur sehr wenige Informationen darüber, was mit der Website und der Publikation nach August 2017 passiert ist.
Die 10 wichtigsten Artikel, die von CrossTalk veröffentlicht wurden
Im Andenken an CrossTalk haben wir 10 der wichtigsten Artikel identifiziert, die während des Bestehens der Zeitschrift veröffentlicht wurden.
Um diese Artikel auszuwählen, haben wir die Anzahl der Links, die die jeweiligen Artikel von Webmastern und Redakteuren erhielten, herangezogen. Artikel, die mehr Links (also Zitate) erhalten, sind in der Regel wichtiger als solche, die weniger Links bekommen.
1. Informatik-Ausbildung: Wo sind die Software-Ingenieure von morgen?
Die Wissenschaftler Robert Dewar und Edmond Schonberg, beide damals Professoren für Informatik an der New York University, nutzen diesen Beitrag, um zu argumentieren, dass die Informatikausbildung (im Jahr 2008) notwendige Kompetenzen vernachlässigte.
Die Autoren machen die allgemeine Einführung von „Java als erste Programmiersprache“ für diese Entwicklung verantwortlich. Sie geben eine Zusammenfassung der Fähigkeiten, die ihrer Ansicht nach zum Handwerkszeug jedes Softwareprofis gehören: Programmiersprachen, Testmanagement-Tools für die Erstellung von groß angelegten, vertrauenswürdigen Programmen und formale Beweismethoden (Quelle).
2. Agile Entwicklung skalieren: Große und verteilte Produktentwicklung mit Large-Scale Scrum
Die Berater Craig Larman und Bas Vodde nutzten diesen im Jahr 2013 verfassten Artikel, um die Inhalte ihrer zweiteiligen Buchreihe über agile Entwicklung im sehr großen Maßstab zusammenzufassen. Sie beschrieben, wie sie mit Kunden zusammenarbeiteten, um zwei groß angelegte Scrum-Frameworks in großen, globalen Organisationen einzuführen. Zu den Unternehmen, mit denen sie gearbeitet haben, zählen unter anderem die Bank of America und Erickson, ein Anbieter von Telekommunikations-Infrastrukturausrüstung.
Larman und Vodde berichten, dass ihre Erfahrungen sie dazu veranlasst haben, zwei Bände zu veröffentlichen. Band 1 ist Denken und Organisationstools für Large-Scale Scrum. Er konzentriert sich auf Führung und Organisationsdesign. Der zweite Band ist Praktiken für die Skalierung von Lean & Agile Development: Große, verteilte & Offshore-Produktentwicklung mit Large-Scale Scrum. Er bietet praktische Vorschläge für das Skalieren in verschiedenen Situationen.
3. Sowohl inkrementelle als auch iterative Entwicklung einsetzen
Der Autor von diesem Artikel von 2008, Dr. Alistair Cockburn (von CrossTalk als Experte für objektorientiertes (OO) Design, Softwareentwicklungs-Methodologien, Anwendungsfälle und Projektmanagement beschrieben), konzentriert sich auf inkrementelle und iterative Entwicklung im Bereich Software.
Dr. Cockburn benennt Herausforderungen, auf die Teams bei der Arbeit mit inkrementeller und iterativer Entwicklung stoßen: Sie versuchen, beide auf dieselbe Weise zu managen, oder glauben, dass wenn eine Methode verwendet wird, die andere nicht eingesetzt werden sollte. Er fasst seine Ideen folgendermaßen zusammen: „Das Wort Inkrement bedeutet hinzufügen; das Wort iterieren bedeutet wiederholen“ (Quelle).
4. SmartCam3D bietet neue Ebenen der Situationswahrnehmung
In diesem Beitrag von 2005 konzentrieren sich Janis White (statistische Beraterin), Frank Delgado (arbeitet für die NASA) und Mike Abernathy (Software-Spezialist) auf das SmartCam3D (SC3D). Dies ist ein „hybrides synthetisches Sichtsystem, das Live-Sensordaten mit Daten eines synthetischen Sichtsystems kombiniert, um ein virtuelles Cockpit-Fenster zu erzeugen.“
Die Autoren stellen das Hybrid Synthetic Vision System (HSVS) vor. Dies ist ein System, das sie als die Kombination von „Live-Sensordaten mit Informationen aus einem synthetischen Sichtsystem (SVS) zur Erzeugung von Echtzeit-Visualisierungen mit hohem Informationsgehalt“ beschreiben. Sie schlussfolgern, dass das SC3D das erste Echtzeit-HSVS-System war, und schlagen vor, dass „diese Software Leben retten wird“ (Quelle).
5. CMMI unterstützt unternehmensweite Prozessverbesserungen
Lt. Col Joe Jarzombek, damals Direktor bei Earth Science Information Partners (ESIP), einer Gemeinschaft, die daran arbeitet, wissenschaftliche Daten besser zugänglich zu machen, nutzte diesen Beitrag, um das Konzept der Capability Maturity Models (CMMs) vorzustellen. Dies bezieht sich auf eine Sammlung von Modellen, die sich mit organisationsweiten Prozessen und Kompetenzen befassen, welche disziplinübergreifend wirken.
Jarzombek führt das Konzept von CCMI-Teams ein, die er als „gemeinsame Initiative zur Integration von CMMs“ bezeichnet. Solche Einheiten, so argumentiert er, würden eine Sammlung integrierter Produkte schaffen, die die Prozess- und Produktverbesserung im Bereich der Softwareentwicklung unterstützen (Quelle).
6. Warum große Softwareprojekte scheitern: Die 12 wichtigsten Fragen
In diesem Artikel von 2005 von Watts S. Humphrey vom Software Engineering Institute (SEISM) der Carnegie Mellon University stehen die 12 Schlüsselfragen im Vordergrund, warum große Softwareprojekte scheitern.
Für Humphrey helfen die Antworten auf die im Artikel gestellten Fragen Softwareentwicklern dabei, ihre Projekte zu verbessern. Er ist der Ansicht, dass die Hauptprobleme mit den Gründen zusammenhängen, warum das Management großer Softwareprojekte oft herausfordernd ist, welche Managementsysteme erforderlich sind und was bei deren Einführung getan werden muss (Quelle).
7. Cloud Computing entmystifizieren
Qusay F. Hassan von der Fakultät für Computer und Information der Mansoura-Universität in Ägypten blickt auf die Entwicklungen im Bereich Softwareentwicklung im Jahr 2011 zurück und konzentriert sich auf Cloud Computing.
In dem Artikel versucht er, mit der Idee umzugehen, dass der Begriff „Cloud Computing“ häufig von Menschen missbraucht wird, wenn sie sich auf Dinge beziehen, die möglicherweise gar nichts mit der tatsächlichen Definition und dem Umfang zu tun haben. Geht es ausschließlich um Webhosting? fragt er. Anschließend definiert er mehrere Konzepte wie Webhosting, Application Service Provider (ASP), Volunteer Computing und Online-Dateifreigabe unter vielen anderen (Quelle).
8. Korrektheit durch Konstruktion: Ein Manifest für hochintegre Software
„Hochintegre Softwaresysteme sind oft so groß, dass konventionelle Entwicklungsprozesse bei Weitem keine tolerierbaren Fehlerraten erreichen können“, sagen Martin Croxford und Dr. Roderick Chapman zu Beginn dieses Beitrags. Als die beiden Autoren diesen Artikel verfassten, arbeiteten sie für Praxis High Integrity Systems, ein britisches Systemtechnikunternehmen, das sich auf missionskritische Systeme spezialisiert hat (Quelle).
In diesem Artikel von 2005 versprechen die Autoren, einen Ansatz zu liefern, der „kostengünstig Software mit extrem niedrigen Fehlerraten produziert“ hat. Die Methode, über die sie schreiben, ist die Correctness by Construction (CbyC). Dies ist ein Ansatz in der Softwareentwicklung, der sich über die gesamte Lebensdauer gut an Änderungen anpassen lässt und dessen Fehlerraten niedriger waren als bei damals gängigen kommerziellen Praktiken (Quelle).
9. Designfehler in der Benutzeroberfläche des Browsers: Ausnutzen von Benutzerunwissenheit
Dieser Artikel wurde 2011 von Aditya Sood, damals Doktorand an der Michigan State University, und Richard Enbody, Associate Professor am Fachbereich für Informatik und Ingenieurwesen ebendort, verfasst. Im Abstract des Artikels vermerken die Autoren, dass „Designfehler in Browsern ernste Gefahren für Nutzer-Sicherheit, Privatsphäre und Integrität darstellen“.
Der Beitrag konzentriert sich auf Designfehler in der grafischen Benutzeroberfläche (GUI)
von Browserelementen. Die Autoren führen aus, dass gerade diese Schwachstellen von Betrügern ausgenutzt werden, wenn sie Nutzer dazu bringen, Dinge zu tun, die ihre Sicherheit gefährden (Quelle).
10. Geriatrische Probleme alternder Software
Capers Jones, der damals in der Software-Produktivitätsforschung arbeitete, widmet sich den Problemen alternder Software im Geschäfts- und im öffentlichen Bereich. In diesem Beitrag von 2007 stellt Jones fest, dass es damals nicht überraschend war, Unternehmen oder Behörden zu finden, die Software einsetzten, die älter als 10 Jahre, teils sogar 25 Jahre alt war.
Jones beschäftigt sich außerdem mit den Folgen alternder Software und bemerkt, dass es schwierig wird, solche Software zu warten, da Updates häufig die ursprüngliche Struktur der Anwendungen zerstören. Dies erhöht die Entropie (Unvorhersehbarkeit und Unordnung). Er stellt fest, dass bei alternder Software das Problem der Fix Injection entsteht, bei dem „als Nebenprodukt der Behebung früherer Fehler versehentlich neue Fehler eingeführt werden“ (Quelle).
