Skip to content

Fax-Empfang "small & simple" mit mgetty

Linux Seit ein paar Monaten hab ich mal wieder einen Server. Linux natürlich, obwohl oder gerade weil ich mich als MCSE mit Windows-Servern durchaus auskenne. Davor hatte ich die fromme Idee, Energie zu sparen und ein Fujitsu Storagebird statt eines dedizierten Servers laufen zu lassen. Das ist an sich keine schlechte Lösung, wenn, ja wenn diese Festplatten mit Ethernet-Interface nicht so grottig lahm wären, dass es keinen Spass mehr macht mal eben ein bis zwei Gigabyte Backup auf den Server zu schieben. Also musste doch wieder ein lärmender, stromfressender Server in den Heizungsraum.
Mit der Installation von Suse 10.2 hab ich dann auch ein altes USRobotics Faxmodem (gabs für einen Euro bei ebay) als Faxserver installiert, die Telefonanalage lag einfach zu nah. Hylafax sollte es sein, das gilt so als die Empfehlung für Linux und ist bei der Suse auch gleich dabei. Der Hylafax-Server ist schon eine durchdachte Lösung, man kann mit Windows-Clients auch komfortabel faxen, wenn denn erst mal alles läuft. Die Konfiguration ist aber schon reichlich fummelig, es gibt zwar ein Setup, das die notwendigen Einstellungen vornimmt, aber man sollte schon alles gleich richtig eingeben: Wenn man hinterher etwas ändern möchte, muss man doch wieder in die Konfigurationsdateien eingreifen. Vor allem wenn man Wünsche wie "warte nicht auf das Freizeichen an der Telefonanlage und wähle gleich eine 0 vorweg" hat - zu alten FIDO-Mailbox-Zeiten sagte man "ATX3DT0," dazu.
Selten gibt es bei Linux den Fall, dass man nur das eine, aber nicht das andere Programm gleichzeitig installiert haben kann. Hylafax und mgetty/sendfax sind zwei solche Programme. Nun kenne ich mgetty schon sehr lange, in Linux-Gründerzeiten gab es dieses Programm schon, und es ist immer noch installierbar. Will man damit faxen, möglicherweise gar von Windows-Kisten, wirds mindestens genauso eine Frickelei wie bei Hylafax. Aber nur für den Fax-Empfang ist die Konfiguration völlig einfach. Nach der Installation wird der mgetty einfach mit dem vorbereiteten Eintrag in der Inittab aktiviert.
Da muss auch nichts groß konfiguriert werden, mgetty findet das Modem und wartet auf Anrufe (ok, die Schnittstelle muss man schon angeben, und alles unter der Voraussetzung, wir reden von richtigen Modems, so mit seriellem Kabel und externen Netzteil). Einzige Hürde ist das Skript "new_fax", mit dem die eingehenden Faxe an einen oder mehrere User gemailt werden. Mit diesem Skript kann man sich selbst ausdenken, was mit einem eingehenden Fax passieren soll, aber Weiterleitung als Anlage einer E-Mail ist so die übliche Variante. Es liegen auch diverse Skripte bei, meine Wahl ist das unter den Beispielen als "new_fax_mime4" im mgetty-Paket enthaltene. Dazu muss man dann noch die Pakete "netpbm" für die Konvertierung der Grafiken und "metamail" für die Konvertierung der Faxe als MIME-Attachment nachinstallieren.
In der installierten Form ist mgetty eine bestechend schlanke Lösung: Das ausführbare Programm hat keine 100 KB, die Konfiguration für Linuxer sehr naheliegend, für alle anderen in den /etc-Dateien gut dokumentiert. Wenn es nur darum geht, auf einem Server Faxe entgegenzunehmen, ziehe ich mgetty dem fetten Hylafx-Paket deutlich vor.

Lastenheft

Software Das Lastenheft stellt eine grobe Produktskizze für ein zu erstellendes Software-Produkt dar. Damit ist das Lastenheft vereinfachte Form des Pflichtenhefts. Da es nicht detailliert ausfallen soll, muss es vom Umfang so knapp wie erforderlich gehalten werden, meist werden nur wenige Seiten benötigt.

Es wird nicht beschrieben, "wie" etwas gemacht werden soll, sondern nur "was" die neue Software leisten soll. Die Basisfunktionen der neuen Software und ihr Sinn muss deutlich herausgearbeitet werden.

Da das Lastenheft die Grundlage für Entscheider darstellt, muss es sprachlich so gehalten sein, dass diese es verstehen und vor allem die Argumente nachvollziehen können. Wenn der Auftraggeber eine Fachsprache verwendet, sollten die entsprechenden Begriffe auch an den erforderlichen Stellen eingesetzt werden, hier sollte eine Fachkraft der Branche gegebenenfalls noch einmal Korrektur lesen.

Hier sagt ein Bild auch oft mehr als 1000 Worte - eine Zeichnung kann viele Abläufe verdeutlichen! Auch Tabellen sollten eigesetzt werden, um Werte übersichtlich zu präsentieren. Zahlenreihen sollten in grafischer Darstellung visualiert werden.

Die Gliederung des Lastenhefts ist nicht verbindlich geregelt und es gibt verschiedene Empfehlungen dazu: Balzert empfiehlt
Zielbestimmung: Was soll die Software können?
Produkteinsatz: Wer soll die Software einsetzen?
Produktfunktionen: Welches sind die Hauptfunktionen?
Produktdaten: Welche Daten werden verarbeitet?
Produktleistungen: Wie schnell, umfassend, genau?
Qualitätsanforderungen: Wie zuverlässig, portabel...?
Ergänzungen: Was sonst noch?

Projektstudie (feasibility study)

Software Die Projektstudie wie sie nach DIN 69905 richtig heißt, auch Machbarkeitsstudie oder auf plattdeutsch auch "feasibility study" genannt, steht am Anfang größerer Projekte als erste Projektphase, teilweise noch vor dem Kick-off. Über die Tätigkeiten und Ergebnisdokumente gibt es in der Literatur keine Einigkeit. da die Gestaltung dieser Phase sehr von der Situation abhängt.

Mit der Projektstudie soll das Risiko für eine Erreichen des Projektziels geprüft werden, wenn nicht sicher ist ob dies überhaupt möglich ist. So kann man versuchen herauszubekommen, mit welchen Aufwand (zeitlich und damit auch finanziell) der Projekt realisiert werden kann. Rein organisatorisch bringt die Projektstudie Ordnung ins anfängliche Chaos.

Im Hauptteil der Projektstudie steht die Machbarkeitsprüfung: Hier wird die organisatorische Umsetzung und wirtschaftliche Machbarkeit (z.B. Kostenrahmen, Finanzierung), aber auch die technische Machbarkeit und die Verfügbarkeit von Ressourcen (Mitarbeiter, Räume, Geräte und Zeit) geklärt.

Für die Projektstudie wird üblicherweise ein strammes Zeitfenster angesetzt, nach deren die Untersuchungen abgeschlossen sein müssen.

Ist das Ergebnis dieser Studie negativ muss das Projekt abgelehnt oder komplett geändert werden. Nach der Machbarkeitsstudie fällt auf jeden Fall die Entscheidung "stop-or-go".

Im Bereich der Software-Entwicklung hat die Projektstudie auch noch eine weitere Funktion neben der eigentlichen Untersuchung der Machbarkeit, nämlich festzulegen, was die Software überhaupt leisten soll.

Neben den Anforderungen an die Software und die Funktionen sind auch die Gestaltung des Benutzer-Interfaces der Inhalt einer Vorstudie zu einer Software-Entwicklung. Ergebnis der Studie sollte daher auch ein Lastenheft sein.

Dazu sind Ausschreibungsunterlagen und gesetzliche Vorgaben zu beachten, es muss der Markt oder die bestehende Software analysiert werden sowie Interviews mit Anwendern und späteren Fachleuten geführt werden.

Wasserfall-Modell

Software Das Wasserfallmodell ist eine klassische Vorstellung von der Aufeinanderfolge von Projektphasen im Software-Engineering, der Softwareentwicklungsprozess in Phasen aufgeteilt. Der Name kommt daher, weil man dabei davon ausgeht, dass Ergenisse einer Phase wie bei einem Wasserfall immer als bindende Vorgaben für die nächst tiefere Phase eingehen.

Das Problem des Wasserfallmodells ist jedoch, dass es nur dann problemlos eingesetzt werden kann, wenn sich die Anforderungen und Kundenwünsche an das Projekt und das fertige Software-Produkt schon in der Planungsphase präzise beschreiben lassen.

Ende jeder Projektphase sind dabei sogenannte Meilensteine, Sitzungen an denen die Ergebnisse der Projektphasen dokumentiert werden.

Die Phasen können dabei in ihrer Anzahl und Bezeichnung unterschiedlich ausfallen, aber immer findet man die grafischen Darstellung der fünf bis sechs als Kaskade angeordneten Phasen:
wasserfallmodell
Davon gibt es einige Varianten, beispielsweise gehört in bei der Integration gehört auch ein Test zur Qualitätssicherung mit dazu. Zum Kickoff kann es nur ein kurzes Meeting geben, diese Phase kann aber auch die Durchführung einer Studie bedeuten, nach der erst weiter über das Projekt entschieden wird.

In der Praxis überschneiden sich Projektphasen und es ist auch immer wieder mal erforderlich, einen Schritt zurück zu gehen. Dies kann das Wasserfallmodell mit dem Ansatz, dass die Phasen nacheinander ablaufen und voneinander sauber abgrenzbar sind nicht mehr abbilden.

Damit ist das Wasserfallmodell nur auf einfache Projekte anwendbar und unflexibel gegenüber Änderungen. Es ist nur dann verwendbar wenn es möglich ist, schon früh die Anforderungen festzuschreiben. Werden Fehler erst spät erkannt, müssen sie mit erheblichem Aufwand entfernt werden.

Wegen der gravierenden Nachteile des Wasserfallmodells, die meist erhöhten finanzielle Aufwand bedeuten, hat das Wasserfallmodell heute kaum noch praktischen Wert und wurde in der IT-Industrie durch eine Vielfalt alternativer oder ergänzender Vorgehensweisen ersetzt.

Use-Case-Analyse

Software Bei der "Use-Case"-Analyse (auf deutsch auch Anwendungsfall-Analyse) wird genau einen Ablauf oder einen Prozess beschrieben. Dabei definiert man eine Interaktion zwischen Akteuren (dargestellt als Strichmännchen) und dem betrachteten System.

Hintergrund ist dabei immer ein beestimmtes fachliches Ziel (plattdeutsch: "business goal") zu erreichen. Die UML2 vermeidet allerdings den Begriff "System" und verwendet stattdessen den Begriff "Subjekt" um zu betonen, dass ein Anwendungsfall das erforderliche Verhalten einer Vielzahl von Modellelementen der UML2 deklarieren kann.

Definition: Ein Use Case beschreibt eine abgeschlossene, ununterbrochene Abfolge von Aktionen eines Akteurs am System mit Ergebnis von fachlichem Wert.

Schwierig ist die Abgrenzung von Anwendungsfällen, vor allem da sie nicht immer an Geschäftprozessen festzmachen sind. Um festzustellen, ob ein Anwendungsfall schon zu komplex ist, wurde von Cockburn der "Kaffeepausen-Test" vorgeschlagen: Ein Anwendungsfall soll so weit gehen, wie ein Nutzer für diesen Anwendungsfall und die notwendige Interaktion keine Kaffeepause einlegen würde.

Ein CASE-Tool für die Darstellung von Use-Case ist Rational Rose, ein Werkzeuge für die Architektur- und Entwurfsmodellierung, die modellorientierte Entwicklung, die architekturbasierte zeiteffiziente Anwendungsentwicklung (Rapid Application Development, RAD) sowie die Durchführung von Komponententests und Laufzeitanalyse.

(aus einer Use-Case-Modellierung mit Rational Rose)

tweetbackcheck