Der Teil 6 der ISO 26262 (Funktionale Sicherheit) stellt einige Tabellen bereit, die bestimmte Methoden in Abhängigkeit von ASIL empfehlen oder gar vorschreiben. Inhaltlich beschreiben diese Tabellen “Best Practices” aus der Software. Daher möchte ich heute eine dieser Tabelle vorstellen und einmal genauer hineinsehen, was eigentlich dort gefordert wird. Interessant finde ich hier, dass die Forderungen eigentlich dem gesunden Menschenverstand folgen und keine “neuen” Anforderungen an die Softwareentwicklung stellen.

Als Beispiel möchte ich für die Funktionale Sicherheit die Tabelle 3 aus der ISO 26262 nutzen. Diese Tabelle macht einige Aussagen zur Entwicklung von Software in Abhängigkeit zum geforderten ASIL. Da ich im Bereich der Programmierung Erfahrungen mit Java habe, möchte ich hier einige Vergleiche anstellen. Was fordert die Funktionale Sicherheit hier von der Softwareerstellung? Sind das besondere Anforderungen oder ist es gar nur Stand “anständiger Programmierung”? In der Tabelle 3 geht es um das Design der Software Architektur. Die Tabelle der ISO 26262 adressiert sieben Bereiche, ich betrachte die ersten fünf. Dabei geht es um die hierarchische Struktur von Softwarekomponenten, die begrenzte Anzahl von Softwarekomponenten, die begrenzte Anzahl von Interface, hohe Kohäsion von Softwarekomponenten und begrenzte Kopplung von Softwarekomponenten.

Die Tabelle 3 der ISO 26262

Der Grundgedanke der Funktionalen Sicherheit ist sichere Produkte zu entwickeln. Die in der Tabelle aufgeführten Eigenschaften sind verständlich und richtig. Doch ist das wirklich ein Thema der Funktionalen Sicherheit? Ich bin der Meinung, dass ich für die ersten fünf Reihen verneinen kann. Diese Prinzipien sind mir vom Studium noch sehr gut geläufig.

Funktionale Sicherheit und die Hierarchische Struktur von Softwarekomponenten

Hierarchie in der Software ist bekannt und kommt so auch in der Vererbung bzw. Ableitung von Klassen vor. Das hat nicht nur die Vorteil, dass man bekanntes erneut benutzt, sondern auf diese Art und Weise lassen sich Fehler recht gut ausmerzen, wenn der Fehler weit oben in der Hierarchie aufgetreten ist. Rein für Funktionale Sicherheit ist das Thema nicht relevant. Das sieht man auch daran, dass alle ASIL die gleiche Empfehlung haben, Hierarchie zu nutzen – sprich es ist immer empfehlenswert.

Funktionale Sicherheit und die Anzahl der Softwarekomponenten

Eines ist klar: Haben Sie viele Softwarekomponenten, können auch viele Fehler auftreten. Je weniger Sie haben, desto weniger Fehler können auftreten. Auch wenn diese Regel recht einfach ist, gewinnt diese bei der Funktionalen Sicherheit eine große Rolle. Es hilft auch, sich auf das wesentliche zu besinnen und Ballast von Board zu werfen. Diese Aussagen sind mir durchaus auch geläufig – nicht nur aus dem Bereich der Funktionalen Sicherheit. Auch hier für jedes ASIL die gleiche Empfehlung.

Funktionale Sicherheit und die Anzahl von Interfaces

Zum einen fällt mir natürlich sofort im Java Kontext implements ein um ein Interface zu implementieren. Zum anderen generelle Schnittstellen bei Softwaremodulen. Ich denke, das erste wird hier nicht so stark aus Sicht der Funktionalen Sicherheit gemeint sein.Auch hier lässt sich aus Sicht der Funktionalen Sicherheit grob sagen, je mehr Schnittstellen, desto mehr potentielle Gefährdungen.

Funktionale Sicherheit und Kohäsion bzw. Kopplung

Kohäsion beschreibt in der Informatik, wie gut Klassen bestimmte Aufgaben lösen. Eine Klasse oder auch eine Methode soll genau die Aufgabe, die ihr zuteil ist, lösen. Nicht mehr aber auch nicht weniger. Die Kopplung beschreibt, wie stark Klassen von einander abhängen. Löst eine Klasse nur die vorhandene Aufgabe, benötigt sie ggf. weitere Klassen um zusätzliche Informationen anzufordern. Damit steigt die Kopplung, das heißt, es entstehen Abhängigkeiten. Nun kann man sich leicht vorstellen, dass eine Kohäsion zu 100% und eine Kopplung zu 0% schwer möglich sind. Je höher aber die Kopplung steigt, desto schwieriger sind die Abhängigkeiten zu handhaben. Das sieht auch die Funktionale Sicherheit.

Fazit

Was die Funktionale Sicherheit hier fordert ist einleuchtend. In meinen Augen ist es aber sowie guten Programmierstil zuzuschreiben, so zu arbeiten. Letztendlich wird Funktionale Sicherheit aber auch genau durch solche einfachen, aber einzuhaltenden Richtlinien unterstützt.

Screenshots werden im Privat- und Berufsleben oft benötigt. Ob Sie nun einen Screenshot zum Beweis einer bestimmten Situation machen oder aber Screenshots zur Visualisierung für Abläufe einsetzen wollen. Bei den Szenarien müssen Sie die Screenshots anpassen, beschriften oder in der Größe ändern. Screenpresso ist dann der richtige Begleiter für Sie! Hier stehen Ihnen viele wichtige Funktionen zur Verfügung, die Screenshots Ihren Wünschen und Ihrem Bedarf anpassen!

Screenpresso ist sehr einfach und intuitiv in der Bedienung. Das muss es auch, denn vor allem muss es schnell gehen bei der Erstellung von Screenshots. Screenpresso kann auf zwei Arten benutzt werden. Sie können es fest installieren oder aber als ausführbare Datei immer wieder aufrufen, ohne es im System zu installieren. Nach dem Ausführen oder dem Start nach der Installation belegt Screenpresso die Druck-Taste auf der Tastatur. Ein Druck auf diese Taste aktiviert Screenpresso und zeigt auf dem Bildschirm on-screen Hilfe zur Erstellung des Screenshots an. Es ist leicht ganze Fenster aufzunehmen oder aber auch nur bestimmte Teilbereiche, in dem die Maustaste gedrückt gehalten und gezogen wird.

Bedienung von Screenpresso

Die Bedienung von Screenpresso ist sehr einfach. Das liegt auch an dem gut gestalteten Interface, das Sie in dem folgenden Bild sehen können. Dieses ist Ihr Hauptfenster bei Ihrer Arbeit mit Screenpresso.

Die hier angezeigten Screenshots können mit der Symbolleiste bearbeitet werden. Es gibt zwei Menüs, das eine bezieht sich auf das Bild selber (2) und erlaubt die Änderung der Größe oder den Zuschnitt. Das andere Screenshot-Menü (1) zeigt die Bearbeitungsmöglichkeiten von Screenpresso.

Als Werkzeuge bietet Screenpresso die rot umrandeten Tools. Die Bearbeitung von Screenshots kann so ohne Probleme durchgeführt werden. Screenpresso bietet für die Screenshots auch ausgefranzte Ecken, dieser Effekt ist für Tutorials oft sehr angebracht.

Fazit zu Screenpresso

Ich nutze es als favorisiertes Screenshot Programm. Neben der kostenlosen Version von Screenpresso gibt es auch noch eine Bezahlversion, die keine Einblendungen nach einer bestimmten Anzahl von aufgenommenen Screenshots enthält. Welche Version von Screenpresso auch immer – für Screenshots ist es für mich das Tool.

Mit Peer Reviews ist es wie mit vielen anderen in der Organisation auch: ohne die Management Akzeptanz lässt sich eine Einführung und erfolgreiche Durchführung nicht bewerkstelligen. Es gibt Anzeichen, die erkennen lassen ob Peer Reviews vom Management unterstützt und akzeptiert werden. Ich stelle Ihnen heute fünf dieser möglichen Anzeichen vor.

Review Prozess wird etabliert und unterstützt

Es wird ein Review Prozess vom Management aufgesetzt und unterstützt. Das Management steht hinter dem Vorhaben.

Peer Reviews sind in den Plänen vorgesehen und werden durch das Management eingefordert

Die Unternehmenskultur ist dahingehend geprägt, dass Fehler nicht als Übel angesehen werden. Durch das permanente Einfordern von Peer Reviews sind diese in den Plänen enthalten und werden aufgrund der Management Beachtung auch durchgeführt.

Peer Reviews sind keine Personenkontrolle

Richtig angewendet, werden Peer Reviews durch das Management nicht dazu benutzt, Personen zu tracken. Peer Reviews sind als Qualitätsmerkmal verstanden und werden auch nur als solches eingesetzt.

Trainings werden durchgeführt

Peer Reviews als Methode werden geschult. Das Management nimmt selbst daran teil, um die Wichtigkeit zu unterstreichen.

Peer Reviews sind in Unternehmensrichtlinien verankert

In den Unternehmensrichtlinien gibt es klare Anweisungen zu Peer Reviews. Die Erwartungshaltung sowie die Ziele sind dort verankert und für jeden Mitarbeiter sichtbar. Jedem Mitarbeiter sind diese Richtlinien bekannt.

In diesem Jahr findet die Veranstaltung “Open Change Community Conference 2012″ am 15. und 16. Mai in Esslingen statt. Unter der inhaltlichen Leitung von der BMW Car IT GmbH, der Itemis AG und KUGLER MAAG CIE GmbH erwartet die Teilnehmer ein spannendes Programm. Dieses Jahr steht die Konferenz unter dem Motto “Wertschätzung des Menschen – über Netzwerke hinaus”. Die besondere Stellung des Menschen und somit auch der (Entwicklungs-)Teams ist ein wichtiger Faktor für die zukünftige Aufstellung von Unternehmen und wurde auch von mir in einigen meiner Artikel thematisiert. Ich freue mich dieses Jahr auf die Open Change Community – sind Sie mit dabei?

Das Programm der Open Change Community Conference ist reichlich mit interessanten Beiträgen gespickt. Da wäre aus meiner Sicht der äußerst spannende Beitrag von Björn Schneider zum Thema ”Ist Agilität der Anfang oder das Ende eines Trendes?” - schon auf dem Forum Anfang 2012 konnte Hr. Schneider mit einem tollen Vortrag zu diesem Thema bei den Teilnehmern punkten. Das Thema passt auch hervorragend in die Expert Area in der ich bei KUGLER MAAG tätig bin.

Für meine Arbeit interessiert mich schon besonders das Praxisforum über Open Source Software: “Die Open Source Integrations-Initiative – Entwicklung eines dynamischen Marktplatzes für Open-Source-IT Services”. Praxisforen ist ein neues Konzept, bei dem Praktiker Ihre Standpunkte darstellen und dann in einer Podiumsdiskussion Rede und Antwort stehen. In die gleiche Richtung geht dabei das Praxisforum ”Community-Konzepte als Erfolgsfaktoren” oder “Was Sie über Open Source wissen sollten”.

Fast etwas mystisches hat in meinen Augen der Vortrag Gerhard Conzelmann vom Shaolin Institute “Intuition und Meditation als Schlüsselkompetenzen für das Management der Zukunft”. Auch hier freue ich mich auf neue Erfahrungen und Einsichten.

Ich habe nur drei der insgesamt 21 Blöcke (inkl. Empfang, etc) genannt und tue diesen bestimmt Unrecht, diese hier nicht zu nennen. Die Referenten, wie auch die Vorträge wirken große Klasse. Ich werde während und nach dem Event noch etwas dazu verfassen und auf dem Blog veröffentlichen.

Ich bin live dabei!

Nach heutigem Stand werde auch ich an der Open Change Community Conference teilnehmen. Über Twitter berichte ich von Inhalten und Ereignissen. Ja, Twitter habe ich zwar lange nicht mehr genutzt, aber ich sehe gerade hier ein gewisses Potential für Konferenzen, Messen und Veranstaltungen. Unter dem HashTag #OCCC12 finden Sie alle Infos:

Um Ihnen die Möglichkeit zu bieten auch online dabei zu sein, habe ich einen RSS Feed für den HashTag #OCCC12 angelegt: http://search.twitter.com/search.atom?q=%23OCCC12 Wenn alles funktioniert, dann werden Sie hier auch die Feeds vorfinden:

• #OCCC12 #OSF12 Danke noch mal an alle Organisatoren, Teilnehmer & Referenten. Es hat Spaß gemacht!
• RT @SeSchneider: #OCCC12 #OFS12 "#Linux ist Programmieren für Kommunisten" (ehm. VP IBM) ;-)
• #OCCC12 Optimalabs.de sucht noch #Mitgründer – Open Enegry Monitor
• Analyse des Fahrstils hilft auch beim Spritsparen. Setz auch einen Notruf beim Unfall #OCCC12 #OSF12 http://t.co/GkLTq7wK
• RT @mycrm -Innovativer Ansatz: Überwachung der Körperwerte und die Vernetzung mit dem Auto. #OSF12 #OCCC12 #apps… http://t.co/DmT01PSF

Wenn Sie auch twittern oder sonstigen Inhalt digital veröffentlichen wollen, lassen Sie es mich doch über die Kommentar-Funktion wissen, dann kann ich Ihren Inhalt auch mit einbauen! Vielen Dank, wir sehen uns am 15./16. Mai in Esslingen!

Auch wenn Sie den Fortschritt noch nicht wirklich sehen können, mein Open Source Projekt geht seine ersten kleinen Schritte. Heute möchte ich Ihnen einen Einblick in die Fragestellung geben, welche Software für ein Open Source Projekt benötigt wird. Ich gehe darauf ein, warum Sie überhaupt Software benötigen und für welche ich mich entschieden habe. Die Auflistung der Kosten ermöglicht es Ihnen Parallelen zu Ihren eigenen Projekten zu ziehen und Alternativen zu bewerten.

Ich habe mir bereits zwei Tools gekauft: Confluence und Jira. Im Confluence sammle ich meine ganzen Anforderungen, die ich habe. Ich werde hier auch weitere Projektdetails hinterlegen. Mein Open Source Projekt behandelt Software, weshalb ich mir auch darüber Gedanken machen muss, wo und wie ich diese verwalte. Da ich auch gerne mit Linux arbeite, habe ich mich dafür entschieden einen virtuellen Rootserver anzumieten (den besitze ich allerdings schon länger). Auf dem Server möchte ich dann auch noch meine Quellen verwalten. Natürlich steht auch Github zur Verfügung, welches Open Source Projekte kostenlos hostet. Mir geht es hier aber überwiegend um meine eigene Erfahrungen, weshalb ich zunächst die Quellen bei mir selber halten möchte. Aktuell entstehen dadurch folgende Kosten:

Sehr gut gefallen mir die Starter-Lizenzen. Mit 10 Usern kann ich für 10$ preislich sehr gut hinkommen und muss das auch nur einmalig bezahlen. Ich installiere diese Software auf meinem eigenen Server. Die Serverkosten fallen so oder so an und da bietet es sich an, Jira und Confluence auch hier zu installieren. Aktuell evaluiere ich noch Greenhopper und Fisheye. Ein agiles Projektmanagement welches Taskboards erstellt und mit bspw. Scrum und Kanban umgehen kann. Fisheye soll mir später helfen meinen Code zu verwalten (auf Basis von Git). Ob ich mich dafür dann wirklich entscheide, steht noch aus.

Braucht man Software für ein Open Source Projekt?

Je komplexer die Programme werden, desto besser ist es, wenn man gute Software zur Auswahl hat. Generell müssen Sie das natürlich nicht investieren. Solche Programme enthalten aber eine Menge von Best Practices, die es sich lohnen zu nutzen.

Ich habe das Gefühl, dass Atlassian eigentlich alles bereitstellt, um produktiv zu werden. Für kleine Teams, oder Open Source Projekte wie meins, ist die professionelle Software sehr erschwinglich! Ich habe zwar noch keine wirklichen Projekterfahrungen damit gesammelt, nach der Evaluierungsphase sieht alles gut aus.

Die Macht von Peer Reviews wird häufig unterschätzt. Kennen Sie Aussagen wie “das lasse ich von meinen Kollegen noch mal ansehen, bevor ich Ihnen mein O.K. geben kann” oder “ich brauche noch eine Experten Meinung dazu”? Bei solchen alltäglichen Formulierungen kann es sich schon um ein Peer Review handeln. Dabei gibt es verschiedene Arten von Peer Reviews. Sie sind sehr gut geeignet, Fehler bereits zu zu identifizieren, bevor diese viel Geld kosten.

Manches mal komme ich mir fast komisch vor, wenn ich nach einem Peer Review frage. Da wird man komisch angesehen und auf Freigabe-Prozesse sowie Validierung verwiesen. Dabei sind Peer Reviews sehr einfach und auch kostengünstig, aber scheinbar fast vergessen.

Dabei ist es gar nichts besonderes, sich mit einem Kollegen über die geleistete Arbeit zu unterhalten. Eine kurze Erklärung an den Kollegen, warum man sich für diesen Weg entschieden hat und schon kann eine Diskussion beginnen. Und so nehmen Sie auch schnell am Peer Review teil.

In meinen Augen wird man schnell etwas nachlässig im Umgang mit der Arbeit, weil man sich oft darauf verlässt, die “Qualitätsabteilung wird schon die Fehler finden”. Aber sollte man nicht selber den Anspruch haben, immer gute Arbeit abzuliefern? Ist es nicht deutlich billiger sich mit einem Kollegen über das Thema auszutauschen, als eine andere Instanz mögliche Fehler finden zu lassen? Ich denke schon.

Peer Reviews lassen sich für vieles einsetzen: Code, eine Dokumentation, Mockup’s oder irgendein Element bei dem es auf Korrektheit ankommt. Bei der Erstellung betrachte ich das Artefakt immer mit meinen Augen. Deshalb ist auch immer mein eigenes Domänenwissen mit im Spiel. Dieses Domänenwissen hat der andere aber nicht bzw. er schaut mit anderen Augen auf das zu prüfende Thema. Und genau das ist oft ausreichend, um ein Peer Review erfolgreich werden zu lassen.

Peer Reviews einführen

Für die erfolgreiche Durchführung von Peer Reviews müssen Manager lernen, wie diese Einfluss auf die Organisation haben. Für das Review müssen (wenn auf nur kurze) Zeiten in Plänen vorgesehen werden. Peer Reviews müssen kommuniziert und gelebt werden. Werden Peer Reviews nicht vorgelebt und eingefordert, werden sie auch nicht gemacht.  Bei den Personen, die Reviews durchführen sollen existieren oft Vorbehalte gegen das Inspizieren von der Arbeit anderer. Ein gern benutztes Argument ist sehr oft, dass Peer Reviews aus einem bestimmten Grund in der konkreten Situation nicht angewandt werden können. Es verhält sich also genauso, wie wenn Sie Prozesse, Vorgehensmodelle oder kurz, etwas Neues einführen wollen.

Hier müssen die Vorteile von Peer Reviews aufgezeigt und in eine Diskussion mit den Anwendern gegangen werden. In stark hierarchisch geprägten Unternehmen hilft das Einfordern durch Management oft schon eine Menge.

Peer Reviews sind keine Meilensteine!

Betrachten Sie bitte Peer Reviews nicht als Meilenstein. Ein Peer Review ist nicht der “Abschluss” von etwas, sondern ein durchgehender Prozess. Dieser findet immer wieder statt, während Arbeitspaket entstehen.

Peer Reviews stellen inhärente Qualität sicher!

Peer Reviews sind kostengünstig! Die Zeit von Kollegen, die einem Peer Review widmen ist deutlich billiger als Korrekturen kurz vor der Fertigstellung eines Produktes. Einfache Dinge und “Bäume, die man vor lauter Wald nicht sieht”, können so früh erkannt und korrigiert werden

Peer Reviews sind eine Frage der (Unternehmens-)Kultur!

Je nach dem wie Peer Reviews durchgeführt werden, so entwickelt sich dazu auch die Akzeptanz. Es ist immer etwas anderes zu sagen, wie “ich verstehe nicht, warum …” als wenn Sie fragen, “das hier ist bestimmt falsch, …”. Die Frage der Umsetzung ist also ganz entscheidend. Ob die Kultur nun im Unternehmen herrscht oder sich noch weiter fasst, auch hier wird unterschiedlich damit umgegangen, wie Menschen mit Fehlern umgehen.

Confluence ist ein mächtiges Werkzeug und bietet sich als Wiki an, um Daten von Projekten zu strukturieren. Confluence kann auch für Anforderungen benutzt werden. Anforderungsmanagement ist eine zentrale Disziplin in der Softwareerstellung.  Zwar kann Confluence alleine nicht unbedingt mit Tools wie DOORS oder MKS konkurrieren, aber das muss es über kleine Projekte oder Teams auch gar nicht. Ich stelle Ihnen einen einfachen Weg vor, wie Sie Ihr Anforderungsmanagement mit Confluence erledigen können.

Anforderungen sind erst einmal nichts weiter als eine (textuelle) Beschreibung einer gewünschten Funktion oder Funktionalität. Genauer möchte ich Anforderungen für diesen Fall nicht spezifizieren. Wer sich genauer mit verschiedenen Arten von Anforderungen und Requirements befassen möchte, findet in der Literatur und im Internet genug Quellen. Auch möchte ich noch nicht das Thema Rechte ansprechen. Ich nehme vereinfacht an, dass keine nicht autorisierten Personen an Anforderungen arbeiten, an denen Sie das nicht dürfen / sollen. Wenn Sie Tools wie DOORS oder MKS im Anforderungsmanagement kennen, dann ist Ihnen dort bestimmt auch immer die hierarchische Abhängigkeit einzelner Elemente aufgefallen. Diese Abhängigkeit lässt sich prima zum Clustern von Anforderungen nutzen.

Genau diese Art stellt auch unsere Basis für die Anforderungen in Confluence dar. Wenn Sie einen neuen Bereich anlegen, dann haben Sie immer die Auswahl, wie diese Daten strukturiert sind. Stellen Sie dazu die folgende Option ein:

Anforderungen werden im Automobilbereich klassisch in Lasten- und Pflichtenheft aufgeteilt. Im Lastenheft schickt Ihnen der Kunde was er gerne hätte und im Pflichtenheft beschreiben Sie, ob und wie Sie die Anforderungen umsetzen. In der Regel werden diese Anforderungen per Datenaustausch übertragen und diese Requirements unterliegen auch Updates. In diesem Beispiel möchte ich auch diesen Teil nicht betrachten. Vereinfacht gehe ich davon aus, dass das Lastenheft manuell in Confluence erstellt oder importiert wird und sich erstmal nicht aktualisiert. Für kleine Teams oder Projekte können Sie so Confluence für das Anforderungsmanagement nutzen – in großen natürlich nicht.

Ich habe ein Beispiel von Anforderungen vorbereitet. Ich habe mir ja vorgenommen ein Open Source Projekt ins Leben zu rufen und hierzu auch Confluence benutzt. Im Confluence sieht das Anforderungsmanagement natürlich nicht wie in DOORS und Co aus, aber für eine bestimmte Projektklasse mag das schon ausreichend sein.

Wie gehe ich beim Anforderungsmanagement vor? In Confluence nutze ich die Navigation um zu strukturieren. So gibt es hier mein Lastenheft und auch das Pflichtenheft. Hier spiele ich aktuell noch mit den Anforderungen rum, aber für mich selber ist das vorgehen recht passend. Mein Anforderungsmanagement nutze ich nur für mich und Confluence braucht auch keine weitere Abgleiche – in sofern einfache Bedingungen. Wie Sie sehen können gruppiere ich. Ich habe immer ein “Oberrequirement” und dann weitere Anforderungen, die das Requirement verfeinern. Auf unterster Ebene habe ich die konkreten Requirements durchnummeriert. Das ist zwar alles manuell aber ich nutze dieses Vorgehen jetzt um alle Anforderungen in Confluence zu dokumentieren. Vielleicht vergleiche ich das später noch mal mit Jira.

Fazit zum Anforderungsmanagement mit Confluence

Es benötigt einiges an Disziplin, alle Anforderungen mit Confluence zu verwalten. Wenn diese Motivation allerdings mitgebracht wird, dann lässt sich dieses Wiki gut nutzen, um die Anforderungen zu verwalten. Werden stärkere Regel benötigt oder konkrete Workflows, sollten Sie einen Blick auf Jira werfen. Ich werde in meinem Open Source Projekt auf jeden Fall damit starten.

Heute stelle ich ein sehr mächtiges Tool für die Administration von Linux-Servern vor: Der Midnight Commander (mc). Dieser Midnight Commander läuft ohne grafische Oberfläche auf so ziemlich jedem vorhandenen Linux System. Mit einer SSH (secure shell) Verbindung können Sie so über die normale Konsole in den Genuss von einer grafischen Anwendung kommen, die praktisch keine Systemanforderungen hat. Es muss kein Dienst auf Ihrem Server dazu laufen, wie es bspw. bei Plesk oder Webmin der Fall ist. Wer die pure Administration über SSH bevorzugt, dem kann ich Midnight Commander nur ans Herz legen!

Am vergangenden Wochenende war es mal wieder so weit. Der Server musste angepasst werden und bei einer Neuinstallation habe ich mich von Plesk auch verabschiedet. Ich selber kenne nicht jeden Befehl unter Linux auswendig und bin ganz froh, wenn ich dann mit etwas Hilfe zum Ziel komme. Genau diese Hilfe bietet der Midnight Commander. Die grafische Oberfläche ist mit reinen ASCII Zeichen erstellt und hat ein zweispaltiges Layout. Er unterstützt sämtlich Funktionen, die Sie benötigen um einen Linux Server zu verwalten: Schnell die Rechte einer Datei geändert, andere Gruppen zugewiesen, Dateien zwischen Verzeichnissen hin und her kopiert und eine gute Editierfunktion für Files. Alle Erfahrenen Administratoren werden wahrscheinlich die reine Konsole bevorzugen, doch allen anderen kann ich Midnight Commander nur empfehlen. Probieren Sie es einfach einmal aus.

Sie werden feststellen, dass es gerade in den täglichen Dingen wie dem Editieren von Konfigurationsfiles immer wieder mehr als praktisch ist, auf den Midnight Commander zurückzugreifen. Das folgende Bild zeigt Ihnen den Midnight Commander in dem Basislayout, jeweils eine Spalte links und Rechts.

Sehr gut umgesetzt finde ich auch die Mausunterstützung. Sie können im Putty sogar die Maus nutzen und auf die Menüeinträge klicken und Einstellungen vornehmen.

Seltsame Steuerzeichen im Midnight Commander?

Auch das ist kein Problem. Nutzen Sie den Midnight Commander über Putty, dann müssen Sie darauf achten, dass der richtige Zeichensatz eingestellt ist. Öffnen Sie dazu Ihre Konfiguration von Putty für Ihren Server und passen Sie die folgenden Einstellungen an:

Ein wichtiger Unterschied beim Assessment liegt in der Prozess- und Produktreife.

Diesen Unterschied haben Sie wahrscheinlich auch schon einmal dann wahrgenommen, wenn Sie gute Ergebnisse mit einem Produkt erzielen, ein Assessment Ihnen aber einen geringen Level bescheinigt.

Diesen Unterschied betrachte ich genauer an einem einfachen Beispiel.

Interpretieren wir das Thema einmal mit gesunden Menschenverstand. Betrachten wir kleine Projekte mit einer Hand voll Mitarbeiter, dann sind Prozesse zur Entwicklung eines Produktes nicht besonders entscheidend. Ist das Projekt aber einige 100 Mitarbeiter groß, dann ist es wichtig Prozesse zur Durchführung definiert zu haben.

Das kleine Projekt hat in unserem Beispiel gar keine Prozesse definiert. Es ist ein Start-Up Unternehmen, das eine App entwickelt, die sich prächtig verkauft (Sie können hier natürlich auch etwas anderes einsetzen). Durch das Wissen der Mitarbeiter ist das Produkt reif. Es hat keine bekannten Fehler mehr und läuft auf allen Plattformen gut, die Kunden sind zufrieden. Hier können wir also auch von einer hohen Produktreife sprechen. In einem Assessment mit Fokus aus Software (bspw. die ISO 15504) wäre die Prozessreife wahrscheinlich schlecht.

Das Gleiche kann aber auch in einem großen Unternehmen passieren. Prozesse sind hier zwar oft definiert, aber auch oft “überdefiniert”. Die einen halten sich nicht daran, andere kennen die Prozesse vielleicht gar nicht, befolgen diese aus anderen Gründen nicht. Durch motivierte oder generell gute Mitarbeiter wird dieses Defizit aber vielleicht aufgefangen und es kommt ein gutes Produkt heraus. Die Prozessreife ist auch wieder schlecht, basierend auf der Nichteinhaltung und den geschilderten Problemen.

Will man jetzt aber systematisch eine gute Produktreife erreichen ist es wichtig auf eine hohe Prozessreife zu kommen. Gute Prozesse können bspw. die Wiederverwendung regeln und auch klar definieren, wann, was getestet werden soll und wogegen. Unternehmen die mit einer hohen Prozessreife Produkte entwickeln werden deshalb in der Regel bevorzugt. Nicht selten wird die Prozessreife auch Bestandteil der Vergabekriterien für einen Auftrag.

Automotive Agile bezeichnet die Anwendung von Agilität im Automotive Bereich. Ich verfolge Trends gerne im Google Insight und Automotive Agile ist nun auch dort vertreten. Vor einiger Zeit hatte ich nach bestimmten agilen Methoden im Zusammenhang mit Prozessverbesserungsmodellen gesucht. Auch hier war schon ein leichter Anstieg dies Interesses bei den Google Suchbegriffen zu erkennen. Lesen Sie heute warum sich Automotive Agile durchsetzen wird.

Mit Google Insight können Benutzer sehen, wie oft ein Begriff im Netz gesucht wurde. Das lässt sich historisch über verschiedene Parameter wie bspw. das Land vornehmen. Automotive Agile habe verfolge ich so auch. Der Begriff Automotive Agile oder Agile Automotive entstand bei uns im beruflichen Umfeld. Ich bevorzuge hier den Begriff Automotive Agile, da er den Fokus auf die Automotive Branche setzt, für den er überwiegend gilt. Wir sehen die Notwendigkeit von Veränderungen im Unternehmen. Dabei kommt uns das Thema Agilität (bitte zunächst nicht einfach mit agiler Softwareentwicklung gleichsetzen) zu Hilfe. Es gibt Elemente von Agilität, die in Automotive Agile einfließen. Dabei werden aber bestehende Standards wie Automotive SPICE® und ISO 26262 nicht vernachlässigt oder verletzt.

Das Interesse für Automotive Agile ist da, das zeigt Google Insight recht deutlich. Es fehlen bis jetzt konkrete Angaben aus welchen Ländern oder Städten Automotive Agile besondern häufig gesucht wird.  Das ist aufgrund der Neuheit für das Thema aber nicht ungewöhnlich. Interessant ist, dass es einen Unterschied macht, ob Automotive Agile oder Agile Automotive gesucht wird. Dabei ist Agile Automotive nicht so stark vertreten und kam auch erst später auf. Ob die gesuchten Themen auch mit “meiner Auffassung” übereinstimmen sei mal dahin gestellt. Semantisch könnte der Suchende auch etwas anderes gemeint haben.

Scheinbar ist das Thema aber auch noch für Google so neu, dass sich die Insight Werte zwischen den Tagen ändern – das sollte nicht sein, aber alleine die Aufnahme von Automotive Agile finde ich als Trend sehr wichtig. Ich habe Automotive Agile und Agile Automotive trotz allen Schwankungen als Vergleich von Google Insight hier eingebunden:

Beachten Sie bitte auch unsere Angebote von KMC zum Thema Agile Automotive sowie meine Rubrik Automotive Agile auf meinem Blog. Hier erscheinen immer wieder Artikel zu diesem Thema.

Warum sich Automotive Agile durchsetzen wird

Der Automotive Bereich ist in einem Wandel. Es existieren immer kürzere Entwicklungszyklen, die sich aber durch eine hohe Qualität auszeichnen sollen. Automotive Agile integriert an entscheidenden Punkten im Automotive Bereich Elemente aus der Agilität. In meinen Augen sind die Schlüsselkriterien

Potential gibt es weiterhin genug, um sich zu verbessern. Wer die Innovation verschläft wird bald nicht mehr dort stehen, wo er sich im Moment vielleicht noch befindet. Deshalb ist es gut neue und sinnvolle Entwicklungen im Auge zu behalten. Achten Sie deshalb auch auf Automotive Agile als Thema. Es wird Ihnen im Automobilbereich noch häufiger begegnen!