FMK2015: Software Engineering Basics by Jan Rüdiger

Vortragende(r)
Titel Vortrag
FileMaker Konferenz 2015 Hamburg
www.filemaker-konferenz.com
Software Engineering Basics
Planung und Durchführung von FileMaker Software-Projekten
oder
In 28 Schritten durch ein FileMaker Software-Projekt

Vortragende(r)
Titel Vortrag
Vorab: Software-Engineering: Worum geht´s?
„Zielorientierte Bereitstellung und systematische Verwendung von Prinzipien, Methoden und Werkzeugen für die
arbeitsteilige, ingenieurmäßige Entwicklung und Anwendung von umfangreichen Softwaresystemen.“
– Lit.: Balzert, S.36
Helmut Balzert: Lehrbuch der Software-Technik. Bd.1. Software-Entwicklung.
Spektrum Akademischer Verlag, Heidelberg 1996, 1998, 2001, ISBN 3-8274-0480-0.
Grundsätzliche Einteilung in 10 Wissensgebiete: 10 Wissensgebiete:
gemäß “Software Engineering Body of Knowledge (SWEBOK)”
1. Anforderungsanalyse
2. Softwareentwurf
3. Programmierung
4. Softwaretest
5. Softwarewartung
6. Konﬁgurationsmanagement
7. Projektmanagement
8. Vorgehensmodell
9. Entwicklungswerkzeuge und -methoden
10. Softwarequalität
https://de.wikipedia.org/wiki/Software_Engineering_Body_of_Knowledge

Vortragende(r)
Titel Vortrag
I Consulting, Analyse,
Spezifikation und Entwurf
11 Schritte, die der Durchführung des Projekts vorausgehen

Vortragende(r)
Titel Vortrag
I. 1. Den Kunden kennenlernen. Firma und Mitarbeiter ansehen, Umfeld, Branche
Software-Entwicklung beginnt nicht mit dem Programmieren von Code-Zeilen.
Sie beginnt ebenso wenig damit, das man ein Pﬂichtenheft erfasst, Skizzen erstellt oder sonst irgendwelche Diagramme.
Sie beginnt nicht mit Speziﬁkationen und auch nicht mit einem Dialog über die Bedürfnisse, die eine Software abdecken
sollte.
Und zwar in Bezug auf folgende Aspekte:
Das Umfeld
- wo bin ich, wie sieht die Firma aus, wie sind die Räume gestaltet, wie die Ausstattung?
Die Menschen
- Was für Erwartungen oder Ängste bestehen in Bezug auf Computer und Programme im allgemeinen?
- Welche Programme sind den Mitarbeitern vertraut, welche weniger? Gibt es besondere Gewohnheiten (evtl. auch in Bezug auf
FileMaker)
Die Überzeugungen
- Es muss schnell laufen
- Es muss mit den vorhandenen Tools zusammenarbeiten
- Wir mögen kein Apple-Script… usw.
Erfolgreiche Software-Entwicklung beginnt mit folgenden Tätigkeiten:
- Wahrnehmen und Beobachten

Vortragende(r)
Titel Vortrag
I. 2. Verständnis dafür entwickeln, mit wem man es zu tun hat
Wenn man sich ausführlich und offen auf Punkt Eins eingelassen hat und dem Kunden aufmerksam beim ersten Treffen
begegnet, dann gelingt es einem sehr viel leichter, einzuschätzen, wie man am besten mit seinem Kunden umgeht.
Noch einmal ein Beispiel: Sind Alt-Systeme vorhanden? Gibt es mit diesen schlechte Erfahrungen? Was sollte unbedingt
vermieden werden deswegen? Was für Vorlieben haben sich etabliert, die es zu erhalten gilt? (ob es nun dafür
systematische Gründe gibt oder nicht.)
Mit “Verständnis” sind wie gesagt, allgemeine menschliche oder branchenspeziﬁsche , wie auch ﬁrmenbezogene Aspekte
gemeint. Zusätzlich aber auch technische Aspekte wie Vorlieben, Sorgen, Ängste, Gewohnheiten etc.
Es führt so gut wie nie zum Erfolg, einem Kunden ein Konzept überzustülpen, von dem man einfach sehr überzeugt ist.
Es gilt die Regel: Der Kunde ist König, und seine Überzeugungen müssen nicht die des Software-Entwicklers sein.
Natürlich versucht man grundsätzlich, dem Kunden Konzepte nahezubringen, von denen man überzeugt ist.
Letztendlich gilt: um so mehr Verständnis man dafür entwickelt, mit wem man es zu tun hat, um so erfolgreicher
kann man eine individuell erstellte Software auf jemanden “zuschneidern”.

Vortragende(r)
Titel Vortrag
I. 3. Bedürfnisse rational wie emotional erfassen
Die Bedürfnisse, Wünsche, Vorlieben, Sorgen, Gewohnheiten und Ängste des Kunden drücken sich
grundsätzlich auf zwei Ebenen aus:
z.B. Wir verwenden kein Apple-Script, da es nicht plattformübergreifend zur Verfügung steht
z.B. Wir möchten möglichst auf den Einsatz von Plugins verzichten, weil es schlicht mehr Komplexität und mehr Update-Risiken
z.B. Wir wünschen uns ganz spezielle Formulare für den Druck, die der Anwender in der Druckansicht sehen und auch im Layout
noch verändern kann. Dafür verwenden wir gerne Word, weil wir dann die gesamte Flexibilität haben.
z.B. wir wollen einfach nur dieses kleine Tool neu haben, weil wir im Moment nicht mehr benötigen.
z.B. wir verwenden kein Apple-Script, weil ich es nicht mag.
z.B. wir wollen möglichst keine Plugins, weil ich mit einem Plugin vor 5 Jahren einfach schlechte Erfahrungen gemacht hatte.
z.B. Meine Großtante Erna fand schon immer, das man am besten auf Ofﬁce-Programmen wie WORD heraus druckt. So wollen
wir das auch weiter haben.
z.B. Ich habe immer schon gedacht, eine gute Datenbank dürfe nicht mehr als 2 MB Speicherplatz belegen.
1. rational
2. emotional

Vortragende(r)
Titel Vortrag
I. 4. Mündlich mit dem Kunden besprechen
Wer die Punkte eins bis drei zuvor sorgsam gehandhabt hat, kann beginnen, mit dem Kunden darüber inhaltlich und
technisch zu sprechen.
Dies ist eine sogenannte ROTE PHASE im Vorfeld des Projekts. Hier trifft der Kunde die erste Vorauswahl, ob man mit ihm
zuvor am Telefon oder vor Ort gesprochen hat.
Zum einen sollte man natürlich seine Vorteile und Kenntnisse hervorheben und dem Kunden damit signalisieren, das man
das Problem kompetent lösen kann. Zum anderen sollte man versuchen, aufzugreifen, was sich der Kunde wünscht und
diese Bedürfnisse ernst nehmen und als zentralen Punkt formulieren.
Wie gesagt, dabei kann man immer eigene Konzepte und Überlegungen einﬂießen lassen. Nur sollte man vermeiden,
verblendet davon, den besten Weg zu kennen, dem Kunden ein Konzept überzustülpen, was ihm evtl. entweder rational
oder emotional zuwider läuft.
z.B. hat ein Kunde eine kleine Projektmanagement Datei in Access angelegt. Er ist mit der Funktionalität unzufrieden und
auch mit der Anwenderfreundlichkeit und kommt nicht weiter.
Während sie mit ihm darüber sprechen, dass Sie genau die vorhandenen Schwachstellen gut in FileMaker beheben
könnten, kommen Sie auf die Idee, dass es das Beste wäre, ihm ohnehin gleich das eigene ERP mit allen Modulen
anzubieten. Das kann möglicherweise auf den Kunden “erstickend” wirken.
Der Kunde will nicht nur wissen, dass er inhaltlich verstanden wurde, sondern auch, dass seine Art, die Dinge
anzugehen, auch in seinem Interesse so umgesetzt werden.

Vortragende(r)
Titel Vortrag
I. 5. Schriftlich Anforderungen auflisten und mit Kunden abgleichen
Ist der Kunde interessiert und gehen die Verhandlungen weiter, wird man in irgend einer Form schriftlich die Anforderungen
des Kunden zunächst ganz allgemein festhalten und später dann verfeinern. Der Kunde hat damit die Möglichkeit, zu
erkennen, dass Sie sein Problem verstanden haben und umsetzen können.
Hier beginnt die eigentliche Consulting-Phase. Man skizziert die Bedürfnisse, kann dem Kunden evtl. schon eine
unverbindliche Schätzung geben, die zumindest eine Richtung anzeigt.
Im wesentlichen wird man hier die Funktionalitäten erfassen, sich ein Gesamtbild von der Struktur und der Anforderung
machen, um das Projekt einschätzen zu können.
Schnittstellen aller Art wie ODBC oder für Webpublishing, oder Anbindung an Banksoftware sind in dieser Phase auch
grundsätzlich zu klären.
Man spricht auch über eine mögliche Projektdauer, über die Ressourcen, die nötig sind, um das Projekt in der skizzierten
Zeit durchzuführen, und evtl. auch Zahlungsmodalitäten.
Nennen Sie nie unrealistische Zahlen, sei es zeitlich oder finanziell. Rechnen sie in beides Puffer ein.
In weniger häufigen Fällen wird man ein fertiges Pflichten- / Lastenheft vorfinden. Aber selbst wenn eine mehr oder weniger
genaue Beschreibung des Projekts vorliegt, ändert dass nicht an dem hier vorgeschlagenen Vorgehen, das sich wesentlich
am “evolutionären Prototyping” orientiert.
Ergebnis dieser Phase, ob aus einem oder mehreren Terminen bestehend, sollte eine schriftliche Grundlage sein,
in der definiert ist, was das Programm zu leisten hat.

Vortragende(r)
Titel Vortrag
I. 6. Ausschlüsse schriftlich festhalten und mit Kunden abgleichen
(technologisch wie inhaltlich)
Ist die Beschreibung einmal zu Papier gebracht und mit dem Kunden abgestimmt, gelangt man zu einem der
wesentlichsten Aspekte im Vorfeld der eigentlichen Programmierung, den Ausschlüssen.
Ausschlüsse fließen dann entweder später in ein schriftliches Angebot ein mitsamt der Programmbeschreibung oder sie
werden separat aber schriftlich vereinbart.
Typische Ausschluss-Punkte sind:
- Das Layout wird für eine Bildschirmauflösung optimiert. (selbst wenn das Layout in teilen skalierbar gemacht wird, sollte
man diesen Punkt einhalten. Vor allem ist hierbei eine Mindest-Auflösung und Bildschirmgröße wichtig, da es heute zwar
nicht mehr so viele kleine Schreibtisch-Monitore gibt, aber durchaus z.B. Laptops mit 11 Zoll Bildschirmen.
- Verbindungen, die nicht standardmässig enthalten sind wie Custom-WebPublishing, Verbindung zur Homepage, Web-
Direct Anbindung, SQL Datenbanken einbinden die vorhanden sind oder noch erstellt werden… .etc.
- FileMaker Lizenzen sind nicht enthalten. (kann je nach Angebot unterschiedlich sein)
- Ausschlüsse zu formulieren, ist wichtig, damit man nicht später im Projekt möglicherweise vor dem Satz steht:
“Ich habe gedacht, das wäre alles mit drin.”
Eine Liste von Ausschlüssen ist nicht nur wichtig, um grundsätzliche Missverständnisse zu vermeiden, sondern
auch für beiden Seiten zur Sicherheit, damit der Rahmen des Projekts abgesteckt ist.

Vortragende(r)
Titel Vortrag
I. 7. Dummy erstellen, um sich mit dem Kunden eine optisch,
funktional und Interface-bezogen abzustimmen. (Master-Dummy)
“Evolutionäres Prototyping" bedeutet nicht, das der Kunde während der Entwicklung mehrfach grundsätzlich neue Wege gehen
kann.
Selbst wenn der Kunde oder Sie selbst die Anforderungen des Programms gründlich festgehalten haben, sollten Sie nicht darauf
verzichten, einen Dummy zu erstellen. Lassen Sie sich diesen Dummy in Bezug auf Layout und Formate abnehmen.
Dies ist der erste Dummy, bei dem grundsätzliche Fragen geklärt werden und eine Richtung entsteht. Es ist ihr “Master-Dummy”
An einem Beispiel wie Adresseingabe oder Rechnungserstellung, wofür man ein Layout ein ein paar Eingabefelder erstellt und
er ggf. ein paar Buttons und einfache Skripte, können Sie sehr schnell ablesen, ob sie verstanden haben, welche Begriffe von
Anwender-Komfort, Bedienbarkeit und Funktionalität im allgemeinen hat.
Ein Beispiel:
Sie sind dabei, dem Kunden ihren Dummy-Entwurf für ein Adresseingabe-Layout zu zeigen. Sie haben schon einmal 15 Felder
und zwei Portale mit weiteren Feldern angelegt. Nun haben Sie die Adresse eingegeben und fahren fort damit, die
Telefonnummer zu tippen, schon unterbricht Sie ihr Kunde mit einem sehr überraschten Gesichtsausdruck.
Der Kunde fragt Sie, warum die Länder- und Ortsvorwahl nicht automatisch aus der Adresse ermittelt und gleich einsetzt werden,
und die Telefonnummer nicht gleich bei der Eigabe automatisch formatiert wird. Zudem möchte er einfach einen weiteren kleinen
Button neben dem Telefonfeld, der dann gleich den Telefonanruf auslöst und diesen Vorgang protokolliert.
Nicht, dass man das nicht alles machen kann; nur ist es wesentlich, dem Kunden auch klar zu machen, das dieser Komfort eben
auch seinen Preis und einem zügig umgesetzten ersten Release entgegensteht, wenn dieser Maßstab in allen Programmteilen
angewandt wird.
Erst wenn man hier davon ausgehen kann, dass man über die Erwartungen an die Funktionalität im allgemeinen
Einigkeit erzielt hat, sollte man ein schriftliches Angebot abgeben. Und hier ﬂießen dann auch alle Ausschlüsse,
Ziele, Rahmenbedingungen und so weiter mit ein. Es ﬂießt eben ein, wo das Projekt SEINE GRENZEN HAT.

Vortragende(r)
Titel Vortrag
I. 8. Durchführungszeitraum und Ressourcen abschätzen, formulieren und in Phasen
unterteilen und mit Kunde abgleichen
Sie sollten nie vergessen, den Kunden darauf hinzuweisen, dass auch er in einem gewissen Rahmen Ressourcen zur
Verfügung stellen muss, wenn das Projekt in einem bestimmten Zeitrahmen durchgeführt und abgeschlossen werden soll.
Größere mögliche Urlaubsphasen sind zu berücksichtigen und Puffer für Krankheit und andere Fälle einzubauen.
Legen Sie “Meilensteine” fest und besprechen Sie diese Hauptpunkte der Entwicklung. Vereinbaren Sie Zielzeitpunkte und
wann diese fertiggestellt werden. Auch ist wichtig, welche Voraussetzungen dafür gegeben sein müssen, das eine Phase
erreicht und abgeschlossen wird und man zur nächsten übergehen kann.
Machen sie klar, dass nach der Abnahme eines Bereichs nicht erneut Wünsche an Funktionalität oder Layout gestellt
werden können, sondern, dass diese im Idealfall separat nach Abschluss in einem zweiten Release separat umgesetzt
werden.
ACHTUNG
Vermeiden Sie durch diese Maßnahmen ein “inﬂationäres Projekt”, bei dem das Projekt durch immer neue Anforderungen
und Änderungswünsche (selbst wenn der Kunde bereit ist, diese zu bezahlen !!) immer mehr in die Länge gezogen wird.
Denn es passiert dann schnell, dass die saubere Trennung der Phasen für Entwicklung, Abschluss und Testphase nicht
mehr aufrechterhalten werden könne. Als Folge davon kann das gesamte Projekt scheitern, oder zumindest nicht die
Wünsche des Kunden erfüllen. Zudem kann es auch dazu führen, das die Projektkosten immer weiter wachsen.
Vereinbaren Sie einen Zeitrahmen für die reine Entwicklung, unterteilen Sie diesen z.B. nach Themen-Bereichen in
Abschnitte. Legen Sie darüber hinaus einen Zeitraum für die Testphase und Regeln für die Abnahme eines
Bereichs fest, und vergessen Sie nicht, mögliche Ausfallzeiten mit zu kalkulieren.

Vortragende(r)
Titel Vortrag
I. 9. Betreuung während des Projekts mit dem Kunden klären, auch seine Aktivitäten
abklären
Nicht jedem Kunden fällt auf, wann er selbst Verzögerungen verursacht hat, nur fallen ihm immer auf, wenn es
welche gibt.
Sind die Zuständigkeiten, Antwortzeiten und Kontaktpersonen und alle Ressourcen auf beiden Seiten geklärt, sollten sie
schriftlich festgehalten werden.
Auch auf ihrer Seite sollte es natürlich einen gut erreichbaren Ansprechpartner für ein Projekt geben, die nächsten Monate
sollten vom Ablauf auch in Ihrem Team besprochen und geklärt sein.
Außerdem sollten Remote Zugänge inkl. VPN geklärt sein. Egal wie man Remote auf das System des Kunden zugreift,
egal ob man bei sich in der Firma entwickelt und die Zwischenstände dann zum Kunden trägt - es sollte immer
sichergestellt sein, dass alle technischen Voraussetzungen gegeben und auch geklärt sind.
Legen Sie unbedingt fest, dass Sie sich in regelmässigen Abständen mit ihrem Ansprechpartner des Kunden
zusammensetzen oder sich remote via Team-Viewer usw. abstimmen.
Ein fester Ansprechpartner ist wesentlich ,und dieser sollte auch zu bestimmten Zeiten oder in einem
bestimmten Rahmen für Sie ansprechbar sein.
Zudem sollte dieser Ansprechpartner auch innerhalb einer festgelegten Zeit antworten, da sonst ihr Zeitplan
ohne ihr Zutun in Verzug gerät. Halten Sie dies schriftlich fest.
Klären Sie zweifelsfrei: Wer wie während der Entwicklungs-Phase auf die Projektdateien zugreifen kann.

Vortragende(r)
Titel Vortrag
I. 10. Schriftliches Angebot erstellen und vom Kunden bestätigen lassen
(Puffer einplanen ﬁnanz. und zeitlich)
Endlich können Sie das schriftliche Angebot erstellen und alle gewonnenen Informationen dort einﬂießen lassen. So ein
Angebot kann viele Stunden in Anspruch nehmen und einige Seiten umfassen.
Das ist die zweite ROTE PHASE im Projekt, in der im wesentlichen entschieden wird, ob das Projekt zustande kommt.
Denken Sie daran, Ihre AGB anzugeben oder darauf zu verweisen, z.B. wenn diese online einsehbar sind.
Nehmen Sie zusätzlich in JEDEM FALL die erarbeiteten Ausschlüsse und Zielsetzungen in das Angebot mit auf,
ob es sich zum Teil mit Ihren AGB allgemein deckt oder nicht.

Vortragende(r)
Titel Vortrag
I. 11. Entwicklungsumgebung bereitstellen, lokal, remote beim Kunden oder in der Cloud
Das Angebot wurde akzeptiert und die Arbeit kann beginnen.
Jetzt wird von Ihnen oder von Kundenseite die FileMaker-Entwicklungsumgebung bereitgestellt.
Dies sollten Sie in Punkt 9 geklärt haben.
Idealerweise hat auch ihr Kunde während der Entwicklungsphase Zugriff auf die FileMaker-Dateien.

Vortragende(r)
Titel Vortrag
II Codierung / Programmierung
10 Schritte für die Durchführung

Vortragende(r)
Titel Vortrag
II. 1. Mit dem festen Ansprechpartner frühzeitig Kontakt aufnehmen
Gleichen Sie regelmässige Arbeitsfortschritte ab, so das Ihr Kunde stets auf dem neuesten Stand ist.
Ein gemeinsames “Archiv” in dem alle besprochenen Fragen zu allen Programmabschnitten gespeichert und
nachlesbar sind, ist von großem Vorteil. Ebenso sollten alle Antworten dort gespeichert sein.
Stellen vor Skype- oder Telefonkonferenzen schriftlich Ihre Fragen an Ihren Ansprechpartner. Halten Sie
schriftlich die Ergebnisse fest und senden Sie sie dem Gesprächspartner erneut zur Bestätigung.

Vortragende(r)
Titel Vortrag
II. 2. Kontinuierlich mit dem Kunden in Kontakt bleiben und ihn informieren
Informieren Sie Ihren Kunden regelmässig in engen Abständen, auch wenn er von sich aus nicht Kontakt
aufnimmt. Ihnen kommt die Aufgabe zu, Ihr Software-Projekt als Entwickler zu “moderieren” und die
Kommunikation zielgerichtet zu halten.
Selbst wenn Sie von Kundenseite her nicht kontaktiert werden, oder keine Nachfragen kommen, und Sie
zudem Ihren Ansprechpartner nicht erreichen sollten, teilen Sie unbedingt regelmässig die Arbeitsfortschritte
wie vereinbart mit. Bitten Sie um Rückmeldung innerhalb einer gewissen Zeit. (Das Wort Frist vermeide ich
hier ganz konkret)
Die Kommunikation sollte von ihrer Seite her immer freundlich und offen sein, jedoch auch klar und
zielgerichtet.
ACHTUNG
Wird an einem Abschnitt unmäßig viel Zeit (im Verhältnis zum Gesamtprojekt und dem Zeitplan) mit Detail-
Änderungen oder erneuten Nachfragen des Kunden verbracht, sollten Sie den Kunden unbedingt darauf
hinweisen. “Drängen” Sie nötigenfalls darauf, den Abschnitt abzuschließen, um im Zeitplan keine
Verzögerung zu bekommen.
Es ist auch Ihre Aufgabe, den Zeitplan im Auge zu behalten.

Vortragende(r)
Titel Vortrag
II. 3. Abschnitt für Abschnitt entwerfen Sie nun das Layout / die Layouts und wichtigsten
Felder und Funktionen für jeden Bereich
Haben Sie einen weiteren Programm-Abschnitt skizziert / als Dummy umgesetzt, dann stellen Sie diesen Ihrem
Ansprechpartner vor und notieren Sie alle Änderungswünsche. Tauschen Sie auch diese schriftlich aus und lassen Sie sich
diese bestätigen.
Haben Sie alle Änderungen erarbeitet, dann besprechen Sie das Layout erneut mit Ihrem Kunden und halten das Ergebnis
fest.
Ist dieser Abschluss für einen Bereich gegeben, dann sind keine grundsätzlichen neuen Funktionswünsche für den Kunden
mehr formulierbar. Bemerkt der Kunde später bei den Tests, dass er gern weitere Funktionen zur Verfügung gestellt hätte,
dann halten sie diese für ein späteres Release fest.
ACHTUNG
Ich möchte erneut davon abraten, selbst wenn der Kunde es bezahlt, nach einem wie auch immer deﬁnierten Abschluss-
Zeitpunkt erneut Änderungswünsche in Bezug auf neue Funktionen einzuarbeiten.
Dauer und Zielgerichtetheit (sog. “goal-directedness”) sowie ein sauberer erster Release rücken damit in weitere Ferne. Der
Kunde selbst wird , auch wenn er zusätzliche Wünsche bezahlt , irgendwann rein durch die Tatsache frustriert sein, das die
Software nicht zu Ende gebracht wird, auch wenn er das ( mit ) selbst verursacht.
Stimmen Sie Ihren jeweiligen Entwurf/ Modell/ Dummy für einen Programmabschnitt / ein Modul mit Ihren
Ansprechpartner ab und lassen Sie alle Änderungwünsche zeitnah formulieren.
Weisen Sie ihren Kunden darauf hin, dass Ein Layout / Bereich grundsätzlich nach einem Änderungs-Durchlauf,
ggf. nach einem zweiten, abgeschlossen werden muss, um im Zeitplan zu bleiben.

Vortragende(r)
Titel Vortrag
II. 4. Termine vor Ort beim Kunden rechtzeitig und vorausschauend klären und einplanen
Verzögerungen, die aus irgendwelchen Gründen auftreten, ebenso schriftlich austauschen mit den Kunden
und darauf hinweisen, das eine Verzögerung eintritt und diese nach Möglichkeit zeitlich benennen.
Hierzu:
- Änderungen im Unternehmens-Alltag des Kunden, die in Bezug auf das Projekt Änderungen nötig machen,
z.B. neue Bankanbindung z.B. SEPA Export usw.
(Sind dies klar umrissene in sich geschlossene Zusatzanforderungen, die man direkt an die geplanten
Arbeiten anhängen kann, ohne das Projekt in seiner Zielsetzung zu gefährden.)
- Personalwechsel kann in Ihrem Team ein Mitarbeiter oder beim Kunden auftreten.
Folgende Änderungen bzw. Verzögerungen können sich in jedem Projekt ergeben:
- Ausfälle von Mitarbeitern oder Technik
- Zuvor nicht besprochene Urlaube auf Seiten des Kunden
- Krankheitsbedingter Ausfall
- Änderungen im Unternehmens-Alltag des Kunden
- Personalwechsel

Vortragende(r)
Titel Vortrag
II. 5. Geklärte, funktionierende Abschnitte abnehmen lassen
Das Thema “Abnahme” ist zuvor schon erwähnt worden und ist wiederholt ein wesentlicher Bestandteil.
Ganz egal, wie Sie vorgehen oder wann Sie Abnahmen durchführen; sei es zum Schluss, sei es
Abschnittweise, nach dem Testen, oder in Bezug auf Änderungswünsche nach der Programmierung, eine
Abnahme sollte immer deﬁniert stattﬁnden und schriftlich niedergelegt sein.
ACHTUNG
Wann und wie Sie diese auch unterteilen oder durchführen, halten Sie diese unbedingt fest und teilen Sie
Ihrem Ansprechpartner die Ergebnisse und Vereinbarungen mit. Lassen Sie diese vom Kunden bestätigen.
Abnahmen können sich auf Programmteile, Layouts, Funktionen, den Funktionsumfang gesamt beziehen.
Abnahmen können sich auf die Gesamtheit der Software als auch auf Phasen, Teilbereiche / Module beziehen.

Vortragende(r)
Titel Vortrag
II. 6. Arbeitsfortschritte regelmässig sichern und Backups auslagern
Ob Sie sich mit der IT des Kunden abstimmen, oder selbst dafür verantwortlich sind, letztlich sind immer Sie
selbst gefordert, zu prüfen und auch sicherzustellen, das Backups regelmässig gesichert und ausgelagert
werden.
Verschwindet aus irgendeinem Grund heraus von heute auf morgen Ihre gesamte Arbeit ist es relativ sinnlos,
darauf hinzuweisen, das die IT des Kunden das versäumt hat. Ihr Projekt ist mindestens geplatzt und darüber
hinaus für Sie und den Kunden ein enormer Schaden entstanden.
Vor allem überprüfen Sie regelmässig, ob alle Backups wie geplant ausgeführt und gesichert werden, auch
ausserhalb des FM Servers. Ein Backup Prozess kann aus vielen Gründen an verschiedenen Stellen
unterbrochen sein, und wird es nicht überprüft, merkt man das leider erst oft Wochen oder Monate später,
meist wenn es benötigt wird.
ACHTUNG
Vergessen Sie nicht: es ist Ihre Entwicklung, Ihre geleistete Arbeit um die es geht, nicht nur ein Projekt für den
Kunden. Der Schaden liegt immer auch auf Ihrer Seite.
Machen Sie idealerweise zusätzlich eigene Backups während der Entwicklungsphase und teilen Sie dies dem
Kunden mit. (Falls Sie auf einem Kundenserver entwickeln.)
Arbeiten Sie auf einem Ihrer Server , sollten Sie auch hier die Backups regelmässig auslagern und nicht nur lokal
sichern.

Vortragende(r)
Titel Vortrag
II. 7. Möglichst bewährte Verfahren anwenden, die aus eigener Erfahrung heraus erfolgreich
angewendet werden können
Haben Sie eine Code-Library angelegt? Oder haben Sie im Laufe der Zeit nützliche Beispiele von
Konferenzen und dem Internet gesammelt?
Es ist von enormem Vorteil, wenn man nicht jedes mal erneut über eine immer wiederkehrende Fragestellung
erneut nachdenken muss und diese dann eventuell auch noch immer wieder unterschiedlich löst.
Haben Sie eine solche Fragestellung einmal im Verlauf Ihrer Tätigkeit als Entwickler erfolgreich gelöst, dann
sollten Sie das festhalten und in Zukunft immer wieder darauf zurückgreifen. Es sei denn, Sie entwickeln Ihre
bewährte Vorgehensweise im Verlauf der Zeit weiter und machen eine neuere Variante zum Standard. Wie
auch immer, halten Sie solche zentralen und wiederkehrenden Codes / Skripte / Konzepte fest und greifen
Sie später erneut auf Sie zurück.
Zum einen erhält der Kunde einen funktionierenden Code, in dem weder er noch Sie mit Fehlern und
Fehlersuche konfrontiert werden, zum anderen sparen Sie sich Entwicklungszeit und die sinnlose Arbeit ein
und die selbe Fragestellung immer wieder erneut lösen zu müssen.
Verwenden Sie nach Möglichkeit Techniken oder Code-Modelle, die Sie bereits erfolgreich eingesetzt haben.
Haben Sie in der Vergangenheit typische oder häuﬁge Fragestellungen als Musterskript oder Beispielsdatei
formuliert, greifen Sie darauf zurück, anstatt jedesmal neu an eine Aufgabe heranzugehen.
Es sei denn, Sie haben dafür gute Gründe, z.B. dass eine neue FileMaker Version neue Möglichkeiten aufzeigt.

Vortragende(r)
Titel Vortrag
II. 8. Eigenen Code ausführlich dokumentieren und eine einheitliche Arbeitsweise im Code
wie im User-Interface anwenden
Insbesondere die Arbeit im Team macht es nötig, dass alle nach der selben Art und Weise programmieren. Das betrifft alle
Objekte und Elemente des Codes, sei es Layouts, Wertelisten, Skripte, Feldbezeichnungen und die Art und Weise Sub-
Skripte aufzurufen, den Code zu modularisieren, Benutzerführung, Navigation und Menüs zu gestalten und einzusetzen
und und und….
Legen Sie auch einheitliche Regeln beim Skripting selbst fest, z.B. sollte man sich darauf einigen, dass für alles eine
einheitliche Grammatik im Code gewählt wird.
ACHTUNG So wird evtl. die Abfrage ob ein Bezugswert vorhanden ist auf verschiedene Weise formuliert:
Count (Bezugstabelle::Zielfeld)>0
oder
IsValid (Bezugstabelle::Zielfeld), etc…
was in diesem Fall zu Fehlern führt, falls ein Bezugsdatensatz mit leerem Zielfeld-Wert vorhanden ist. Die Formeln liefern
ein unterschiedliches Ergebnis. (Seriennummern-Feld abfragen ist empfehlenswert)
Nicht nur Sie werden vor allem bei der Arbeit im Team erfolgreicher sein und sich auch nach Jahren noch schnell
zurechtﬁnden, sondern auch Ihr Kunde und alle Anwender werden für ein einheitliches Konzept dankbar sein.
Wenden Sie strickt Ihre Developer-Guidelines an. Sie benötigen klare und einheitlich durchgeführte Richtlinien
und Verfahren, um sich selbst in Ihrem Projekt zu einem späteren Zeitpunkt wieder schnell zurechtﬁnden zu
können. Eine erfolgreiche Wartung ist ohne ein solches Vorgehen schwer möglich.

Vortragende(r)
Titel Vortrag
II. 9. Fragen, Kritik oder Befürchtungen des Kunden ernst nehmen und sachlich und
inhaltlich positiv beantworten
Egal ob Kritik von Mitarbeitern oder dem Auftraggeber selbst kommen, Reagieren Sie zeitnah und offen.
Gehen Sie nicht als allererstes in eine Verteidigungshaltung, selbst wenn Sie glauben - oder es sogar wissen
- dass die Kritik unbegründet ist.
z.B. kann es sein, dass ein Kunde im Verlauf eines Projekts vergisst, dass in irgendeinem Bereich bestimmte
Funktionen auf seinen Wunsch hin so oder so festgelegt wurden. Bei Tests kommt dann Ihr Ansprechpartner
auf Sie zu und konfrontiert Sie damit, dass das nicht wunschgemäß arbeitet.
Die aus meiner Sicht schlechteste Reaktion ist, sich sofort und nur auf den Nachweis zu versteifen und zu
sagen, man habe das halt vor Monaten so festgelegt.
Natürlich können und sollen Sie den Kunden darauf verweisen, wenn das so gewesen ist, aber hören Sie
trotzdem zuvor aufmerksam und offen zu. Signalisieren Sie immer Bereitschaft. Dann lassen Sie Ihre Antwort-
Möglichkeiten einﬂießen, wie man auf die neuen Bedürfnisse des Kunden - möglichst in einem späteren
Release - eingehen könnte.
Es kommt öfter vor, dass ein Kunde im Verlauf eines Projekts irgend ein Detail, z.B. beim Testen anders sieht
als zu einem früheren Zeitpunkt.
Im Verlauf eines Projekts können Zweifel, Bedenken und vielerlei Unklarheiten aufkommen.
Gehen Sie möglichst großzügig und offen damit um. Versteifen Sie sich möglichst nicht auf eine Position des
Recht-Habens gegenüber dem Kunden. Suchen Sie “weiche” / diplomatische und zugleich klare Wege um
Konﬂiktfragen zu klären.

Vortragende(r)
Titel Vortrag
II. 10. Entwicklung klar abschließen und Testphase einleiten
Nach diesem Zeitpunkt startet die Testphase, so wie mit dem Kunden bei diesem Abschluss-Meeting der
Codierungs-Phase besprochen.
In der Testphase durch die Anwender geht es mehr darum, die vorhandene Funktionalität durch Test-
Anwender prüfen zu lassen und nicht neue Programmwünsche und größere Änderungen aufzunehmen.
Dies sollte man strickt so einhalten und zuvor auch kommunizieren.
Haben Sie zuvor regelmässig Rücksprache mit dem Kunden gehalten und Layouts und Funktionen der
einzelnen Abschnitte ausführlich besprochen, wird es in der Testphase auch keine grundsätzlich neuen
Bedürfnisse geben, die einer Fertigstellung des ersten Release im Wege stehen.
Ist die Entwicklung abgeschlossen und haben Sie alle Bereiche, Layouts und Funktionen umgesetzt, dann wird die
gesamte Entwicklung abgeschlossen.
Dies sollte man nach Möglichkeit bei einem Meeting mit mindestens dem Haupt-Ansprechpartner durchführen und
auch schriftlich festhalten.

Vortragende(r)
Titel Vortrag
III Programmtest, Abnahme,
Integration
3 Schritte in der Testphase bis zur Abnahme

Vortragende(r)
Titel Vortrag
III. 1. Testphase zeitlich festlegen, Verantwortliche mit dem Kunden schriftlich klären
Jetzt können Sie die Testphase mit dem Kunden besprechen und zeitlich festlegen.
Klären Sie, wer hier ihr(e) Ansprechpartner ist / sind
Weisen Sie schriftlich darauf hin, dass auch hier der Zeitplan nur eingehalten werden kann, wenn auch von
Kundenseite innerhalb einer festgelegten Antwortzeit die Rückmeldungen und Antworten kommen.

Vortragende(r)
Titel Vortrag
III. 2. Testergebnisse einfordern um im Zeitrahmen zu bleiben
Fordern Sie von sich auch regelmässig die Testergebnisse ein, besonders wenn Sie nichts von Ihren
Ansprechpartnern hören
Weisen Sie im Zweifelsfall mehrfach schriftlich darauf hin, dass die Einhaltung der Antwortzeiten und
Meldungen vom Kunden wesentlich für die Einhaltung des Zeitplans ist.
Sorgen Sie gleichzeitig natürlich dafür, dass eingehende Testergebnisse zeitnah und kompetent bearbeitet
werden und melden Sie die Fortschritte jeweils dem Ansprechpartner schriftlich zurück.
Dokumentieren Sie alle Anfragen und Arbeitsfortschritte / Fehler-Behebungen und teilen Sie diese Information
mit Ihrem Kunden.
Dieser Schritt ist durch starke Iteration gekennzeichnet. Der Ablauf von Test, Protokollierung, Behebung,
Protokollierung der Behebung, erneuter Test, wird vom Prinzip her so oft wiederholt, bis keine wesentlichen
Einschränkungen mehr identiﬁzierbar sind.
Auch wenn Sie viel mit ihrem Ansprechpartner telefonieren, bereiten Sie das Material jeweils schriftlich vor jedem
Gespräch auf und tauschen Sie Ihre schriftlichen Ergebnisse aus

Vortragende(r)
Titel Vortrag
III. 3. Testphase abschließen, Abnahme durchführen, schriftlich bestätigen lassen
Die Testphase ist abgeschlossen, das Programm läuft im wesentlichen. Der Kunde ist zufrieden, Sie sind
zufrieden.
Sobald Sie eine schriftliche Abnahme haben, ist das Projekt “abgeschlossen”. (noch nicht ganz)
Teilen Sie dem Kunden schriftlich mit, dass Sie ihm die Software zu dem und dem Datum um die und die
Uhrzeit funktionsfähig übergeben haben. Lassen Sie sich die Abnahme bestätigen.

Vortragende(r)
Titel Vortrag
IV Wartung
3 Schritte in der Nachbereitung

Vortragende(r)
Titel Vortrag
IV. 1. Dem Kunden in den ersten Wochen nach der Abnahme noch möglichst intensiv
zur Seite stehen
Auch in dieser Phase halten Sie noch möglichst intensiven Kontakt zum Kunden, nachfragen “wo evtl. der
Schuh noch drückt”.
Bearbeiten Sie Bagatell-Änderungen, wie z.B., einen Button zu verschieben oder ein Feld hinzufügen, (das
keine weitreichenden Auswirkungen hat), möglichst sofort.
Beheben Sie Fehler zügig, die nach der Abnahme auftauchen.
Im Kopf behalten, dass das Projekt zwar ofﬁziell abgeschlossen aber “noch nicht zu Ende” ist.
Erst wenn der Kunde nach wenigen Wochen ﬂüssig arbeitet und kaum noch Meldungen oder Anfragen
auftauchen, ist das Projekt für das erste Release wirklich komplett beendet. Sie können Ihre Konzentration auf
etwas neues lenken.

Vortragende(r)
Titel Vortrag
IV. 2. Mit dem Kunden besprechen, zu welchen Konditionen er welche Art Service möchte
Kosten für telefonischen Support? Welche Verfügbarkeit wünscht sich der Kunde und welche
Reaktionszeiten?
Ist der Kunde bereit, einen Servicevertrag abzuschließen?
Den Kunden auch in Zukunft regelmässig bei Neuerungen zu FileMaker oder für ihn nützliche Themen
informieren. (z.B. Newsletter)

Vortragende(r)
Titel Vortrag
IV. 3. Führen Sie nach Möglichkeit eine Form eines Helpdesk ein
Sei es Form einer FileMaker Datei oder via Webdirekt oder eMail. Der Kunde wird dankbar sein, wenn Sie
ihm eine systematische Protokollierung und transparente Bearbeitung seiner Anfragen anbieten.
Der Kunde möchte Klarheit, wann und wie seine Anfragen bearbeitet werden. Transparenz und
vorausschauende Planung sind hier wichtig.
Geben Sie dem Kunden die Möglichkeit, seine Anfragen entweder via FileMaker zu erfassen, oder lesen Sie
Service-Anfragen via eMail / Skype oder Telefon in einer solche Datei ein, um einen Überblick und eine Planung
bezüglich der zeitlichen Bearbeitung von Anfragen zu ermöglichen.

Vortragende(r)
Titel Vortrag
IV. 4. Alle weiteren Wünsche und Anregungen des Kunden notieren und auf eine Liste für
das zweite Release nehmen
Sammeln und erfassen Sie alle weiteren Wünsche des Kunden
Kalkulieren Sie diese, und bieten Sie diese mit einem neuen Durchführungszeitraum an

Vortragende(r)
Titel Vortrag
ENDE
Weiterführende Literatur, ausgewählte Beispiele
“ProjektManager”
Verlag: GPM, Deutsche Gesellschaft für Projektmanagement
Autoren: Heinz Schelle / Roland Ortmann / Astrid Pfeiffer
“Software-Engineering”
Grundlagen, Menschen, Prozesse, Techniken
Verlag: DPunkt Verlag
Autoren: Jochen Ludewig / Horst Lichter
“FileMaker Training Series Advanced” v13 als auch v14

Vortragende(r)
Titel Vortrag
Vielen Dank unseren Sponsoren
Danke für das Bewerten dieses Vortrages

FMK2015: Software Engineering Basics by Jan Rüdiger

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Andere mochten auch

Andere mochten auch (20)

Ähnlich wie FMK2015: Software Engineering Basics by Jan Rüdiger

Ähnlich wie FMK2015: Software Engineering Basics by Jan Rüdiger (20)

Mehr von Verein FM Konferenz

Mehr von Verein FM Konferenz (20)

FMK2015: Software Engineering Basics by Jan Rüdiger