| Inhalt | | |
|---|
| | | | | | | |  |  | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
|
Kull AG fokussiert sich auf die Plattformen und Tools von Microsoft.
|
|
|
|
|
Der direkte Weg zu Ihrer Lösung1 EinführungAm Anfang steht das Bedürfnis des Kunden, einen betrieblichen Ablauf zu modernisieren, bestehende Software abzulösen oder unzulängliche Lösungen zu verbessern.
Heute stehen dazu in nie dagewesener Weise Technologien und Werkzeuge zur Verfügung: Leistungsfähige Datenbanken, Internet/Intranet/Extranet, Programm-Entwicklungswerkzeuge und nicht zu vergessen, die Mittel für eine effiziente Kommunikation unter allen Projektbeteiligten.
Die klassischen Methoden für Software-Entwicklung (z.B. mit den Phasen Anforderungsspezifikation, Systementwurf, Codierung, Einzeltests, Integrationstests, Einführung und Betrieb) stammen aus der Zeit, in der die Software-Entwicklung mühsamer und langwieriger war.
Sie stammen aber auch aus einer Zeit, in der die Datenbanken bedeutend teurer, weniger leistungsfähig und umständlicher zu programmieren waren.
Kennzeichnend für heutige Projekte sind:- Die Anforderungen an die Software ändert während des Projektes ("Moving Target").
- Die Realisierungszeit muss kurz sein, gewisse Funktionen sollen innerhalb von ein paar Tagen produktiv zur Verfügung stehen.
Dieses Dokument gibt eine Übersicht wie Kull AG diese Anforderungen meistert, und wie sie bei Projekten vorgeht.
Die im folgenden beschriebene Vorgehensweise kombiniert bewährte Techniken mit einer pragmatischen Entwicklungs-Philosophie, welche konsequent den heutigen Stand der Technik und die Kundenbedürfnisse berücksichtigt.
Übrigens konnten wir mit Genugtuung feststellen, dass in letzter Zeit auch die Methoden anderer Software-Entwickler in eine ähnliche Richtung zielen. Beispielsweise wird in letzter Zeit das eXtreme Programming stark propagiert. Diese Methode weist erstaunliche Parallelen auf, jedoch mit dem Unterschied, dass sich eXtreme Programming mehr auf den Programmcode als auf die Daten konzentriert.
2 Der Schlüssel zum erfolgreichen ProjektIn der Fülle von möglichen Regeln, Techniken, Vorgehensweisen, Qualitätssicherungsmethoden usw. fokussieren wir uns auf drei Punkte. Es sind dies :
- Gute Datenstruktur
- Verständliche Kommunikation mit dem Auftraggeber und den Anwendern der Software
- Erkennen und Eliminieren von Risiken
In den folgenden Kapiteln werden diese drei Punkte näher erläutert und die zu treffenden Massnahmen behandelt.
3 Die Daten sind fundamentalDer Erfolg eines Projektes hängt direkt von einer guten Strukturierung der Daten und von verlässlichen Daten in der Datenbank ab.
Etwa ab 1995 zeichnete es sich in unserer Firma ab, dass wir damit begannen, vermehrt über Datenstrukturen (im Gegensatz zu den Prozessen) nachzudenken.
Dies aus dem einfachen Grund, dass Datenstrukturen unabhängig von den Prozessen sind, und sich somit zu einem frühen Zeitpunkt ein stabiles Fundament bauen lässt ("die ersten Pfähle können früh und definitiv eingeschlagen werden").
 3.1 Daten sind kostbarDie Daten sind die teuersten Ressourcen in der Informatik. Ihre Erfassung und Pflege ist oft um ein Mehrfaches teurer als die Entwicklung der Programme. Die Lebensdauer der Daten ist in der Regel auch grösser als dasjenige der Programme. Die Daten überdauern oft mehrere Programmgenerationen.
Zu den Daten ist entsprechend Sorge zu tragen. Falsche Daten produzieren falsche Resultate, und ein Totalverlust der Daten ist der GAU in der Informatik.
3.2 Die Datenstruktur ist (fast) immun gegenüber ProgrammänderungenDie gute Nachricht: Die Datenstruktur bildet die reale Welt ab, und sie ist daher weitgehend unabhängig von der Art und Weise wie die Software implementiert und wie die Daten verwendet (dargestellt, bearbeitet) werden. Der grösste Teil der benutzten Datenfelder kann schon in einer frühen Projektphase eindeutig identifiziert werden.
Interessant ist auch die Tatsache, dass die Datenstruktur im Laufe der Zeit auffallend stabil bleibt, auch wenn die Software veränderten Bedürfnissen angepasst wird.
3.3 NormalisierungUnd noch eine gute Nachricht: Es ist allgemein anerkannt, dass das Datenschema in einer relationalen Datenbank so weit wie möglich normalisiert werden soll. Das heisst, dass wenn die Datenstruktur bekannt ist, ist es auch schon klar, wie das Datenschema aussehen muss.
Somit kann das Datenschema in einer frühen Phase festgelegt werden. Bei guter Strukturierung (Relationenbildung) und Normalisierung können später weitere Datenfelder relativ problemlos hinzugefügt werden.
Die modernen Datenbanken unterstützen alle auch die Überprüfung der referentiellen Integrität. Diese Überprüfung kann durch das Datenbanksystem automatisch erfolgen und schützt die Datenbank weitgehend vor der Speicherung von unpassenden Daten. Wir nützen diese Möglichkeit - trotz aufwendigerer Programmierung – ausgiebig. Dadurch erhalten wir eine zusätzliche Sicherheit, dass wir jederzeit tadellose Daten haben.
3.4 Mit echten Daten testenWenn das Datenschema steht und die Datenbank eröffnet ist, können die ersten Daten abgelegt werden.
Dazu verwenden wir - wenn immer möglich - echte Daten, und in der Menge, wie sie auch im Betrieb zu erwarten sind. Im besten Fall können Daten aus einem bestehenden (dem abzulösenden) System übernommen werden. Für diesen Fall werden auch die entsprechenden Export- und Import-Programme realisiert. Diese Programme werden mehrere Male angewendet: vorerst für die Tests und schlussendlich für die definitive Datenübernahme.
Daten aus älteren Systemen sind selten normalisiert und oft inkonsistent. Diese Daten müssen – eventuell unter Benutzung von Hilfsprogrammen - unbedingt bereinigt werden.
Wenn es sich um sensible Daten handelt, werden diese – solange das Projekt in der Testphase steckt - beim Export vom alten System mittels einem Hilfsprogramm verfremdet.
Die Übernahme der Daten in dieser frühen Phase ermöglicht es:
- Fehler im Datenschema zu erkennen
- Mehr Zeit für die Bereinigung der Daten zu haben
- Spezialfälle zu erkennen, an die sich niemand mehr erinnert hatte
- Performance-Probleme frühzeitig zu erkennen
Grundsatz:
Wir versuchen so früh wie möglich, das Datenschema zu entwerfen und mit echten Daten zu füllen. Beim Entwurf des Datenbankschemas gehen wir (fast) keine Kompromisse ein.
4 KommunikationDie Kommunikation mit dem Kunden (Auftraggeber und Anwender) läuft über zwei Kanäle ab :
- Kommunikation zwischen Kunde und Kull AG mittels Gesprächen und Dokumenten (z.B. Fachkonzept, Software-Spezifikation, Bedienungsanleitung). Diese Kommunikation findet in beide Richtungen statt.
- Kommunikation von Kull AG über die realisierte Software zum Kunden. Kull AG stellt die neueste Version der Software bereit. Die Anwender arbeiten mit der Software (eventuell zuerst mit Testdaten und erst dann mit den produktiven Daten). Von den Anwendern kommen die Verbesserungsvorschläge für die nächste Version (Release) der Software.
Bemerkenswert ist, dass die Benutzung der implementierten Software deren Funktionsmängel besser als jedes vorher erstellte Dokument aufzeigt. Das Gleiche gilt für die Schnittstellen zu anderen Programmen.
4.1 Schnell Resultate zeigenWir legen immensen Wert darauf, dass die Anwender die Software bereits in einem frühen Entwicklungsstadium benutzen. Nach Möglichkeit wird parallel zum Testsystem das produktive System hochgefahren und in mehreren Schritten (Releases) werden fertiggestellte Programmteile der Produktion übergeben. Diese Arbeitsweise ist nur dank einem guten, kompromisslosen Datenbankdesign und weiteren Massnahmen (vergl. Wiederholbarkeit der Batch-orientierten Funktionen in Kapitel 5) möglich.
Mit diesem Vorgehen werden erstaunliche Resultate erreicht :
- Es kann schnell mit der Erfassung (bzw. Bereinigung) der echten Daten begonnen werden.
- Es entsteht schon früh ein Nutzen für den Kunden.
- Vom Anwender festgestellte Mängel (Fehler, schlechte Bedienbarkeit) können schnell behoben werden.
- Durch den intensiven Dialog mit dem Anwender, wird dieser enger in die Software-Entwicklung eingebunden (ergibt bessere Identifikation des Anwenders mit dem Projekt).
- Die Programmierer lernen die Abläufe und Probleme des Anwenders besser kennen.
- Es entsteht ein wesentlich besser auf die Kundenbedürfnisse abgestimmtes Produkt. Neue oder geänderte Kundenbedürfnisse können laufend übernommen werden.
- Der jeweilige Stand des Projektes ist für alle Beteiligten besser ersichtlich.
4.2 Kommunikation in der Sprache des AnwendersEs wäre natürlich nicht sehr effizient, nach dem Eröffnen der Datenbank einfach drauflos zu programmieren, und die Reaktion des Anwenders abzuwarten, um dann die entsprechenden Korrekturen vorzunehmen.
Der grosse Rahmen eines Projektes muss wohl überlegt, geplant und dokumentiert werden. Dies gilt insbesondere für die komplexen und risikobehafteten Objekte/Vorgänge.
Diese Dokumente müssen in einer allgemeinverständlichen Sprache und auch für den Anwender gut lesbar erstellt werden. Es geht nicht an, dass man einen Auftraggeber oder Anwender ein Dokument unterschreiben lässt, welches nur von einem – in diesen formellen, abstrakten Darstellungen geübten - Informatiker verstanden werden kann.
Zudem ist die allgemein geübte Praxis, dass sich der Software-Ersteller gegenüber dem Kunden mittels Unterschriften absichert, fraglich. Denn praktisch alle Anforderungsspezifikationen und Design-Dokumente sind nicht vollständig und weisen noch Fehler auf. Es ist nicht ganz fair, die Verantwortung für diese Fehler (die man zum Teil selber hätte erkennen können) auf den Kunden abzuschieben. Überdies wäre ein wirklich vollständiges Dokument zu umfangreich.
Es ist besser sich in den Dokumenten auf die Beschreibung der wesentlichen und kritischen Funktionen zu beschränken, als dieses mit allen Selbstverständlichkeiten zu überladen. Der Leser oder die Leserin muss sich sonst auch wieder durch all diesen Ballast durchkämpfen und verliert womöglich den Blick aufs Wesentliche.
Oft sieht man, dass in umfangreichen Spezifikationen alle bekannten und einfachen Dinge im Detail dargelegt werden; für die Behandlung der diffizilen Angelegenheiten aber die Zeit und die Ausdauer fehlte.
Bei richtigem Design der Software, können heute Änderungen in Bedieneroberfläche und Detailfunktionen relativ leicht geändert werden.
Oder man kann es auch so sagen: Es macht keinen Sinn, die Software ins kleinste Detail zu planen, wenn die Planung fast aufwendiger als die Realisierung ist.
4.3 DokumentationDie mit den Software-Programmen mitgelieferte Dokumentation spricht zwei unterschiedliche Empfänger an :
- den Anwender (Bedienungsanleitung)
- den Programmierer bzw. Systemintegrator, die das Programm warten bzw. installieren müssen
Die Bedienungsanleitung soll einen Überblick über den ganzen Funktionsablauf geben und keine Details enthalten. Die Bedienung des Programms ist so (selbsterklärend) zu realisieren, dass die Übersichtsbeschreibung ausreicht.
Oft ist nicht einmal eine Hilfe-Funktion nötig (diese kann bei Bedarf auch nachträglich noch realisiert werden). Vorteilhafterweise wird der Content für die Hilfe-Funktion vom Anwender erstellt oder wenigstens mitgeprägt.
Die Dokumentation für die Wartung der Software-Programme kann sich auf eine grobe Übersicht beschränken, wenn durch entsprechend übersichtliche Codierung (u.a. klare ausführliche Namensgebung) der Code gut lesbar ist.
Grundsatz : Wir verbessern die Kommunikation durch - Release-orientierte Entwicklung (Entwicklung in kleinen Schritten)
- Dokumente in leicht lesbarer Form
- Selbsterklärende Bedienung
- Selbsterklärenden Code.
5 Risiken minimierenAlle grösseren IT-Projekte bergen irgendwelche Risiken in sich. Typisch sind :
- Performance-Probleme
- Schnittstellenprobleme
- Datenverlust, Datenverfälschung, Zugriffsberechtigungsprobleme
- Termin- und Budgetüberschreitungen
- "vergessene" bzw. falsch implementierte Funktionen
- laufende neue Anforderungen an die zu realisierende Software.
Es gilt nun, die Risiken frühzeitig zu erkennen, zu beurteilen und bereits bei der Planung und im Software-Design die entsprechenden Massnahmen zu treffen.
Grundsatz : - so früh wie möglich mit echten Daten und der vollen Datenmenge arbeiten
- komplexe Abläufe vor den einfachen, selbstverständlichen Funktionen behandeln.
- Schnittstellen zu anderen Programmen so früh wie möglich ausprobieren
- Alle Batch-orientierten Funktionen nach Möglichkeit wiederholbar gestalten¹
- Aktiv nach Risiken suchen
Die Diskussion mit dem Auftraggeber über Risiken muss vorsichtig und offen geführt werden, um zu verhindern, dass der Auftraggeber verunsichert wird, oder gar die Fähigkeiten des Software-Erstellers in Frage stellt.
Wenn man aber weiss, dass die meisten erfolglosen Software-Projekte aufgrund von nicht erkannten oder falsch eingeschätzten Risiken gescheitert sind, wird man dieses Thema problemlos zur Sprache bringen können.
6 FazitMit der oben beschriebenen Methodik werden erreicht :
- Risiken werden minimiert
- Es werden schnell erste Resultate (produktiv) sichtbar.
- Hohe Zufriedenheit des Anwenders ("what you need is what you get")
"Wer etwas will sucht Wege. Wer etwas nicht will sucht Gründe"
Autor unbekannt
Kull AG, Information Technology Services
Bahnhofstrasse 17, CH-5000 Aarau
|
|
|
|
