FMK2015: Software Engineering Basics by Jan Rüdiger

Vortragende(r) Titel Vortrag

FileMaker Konferenz 2015 Hamburgwww.filemaker-konferenz.com

Software Engineering Basics

Planung und Durchführung von FileMaker Software-Projekten

oder

In 28 Schritten durch ein FileMaker Software-Projekt



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.36Helmut 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. Anforderungsanalyse2. Softwareentwurf3. Programmierung4. Softwaretest5. Softwarewartung6. Konfigurationsmanagement7. Projektmanagement8. Vorgehensmodell9. Entwicklungswerkzeuge und -methoden10. Softwarequalität

https://de.wikipedia.org/wiki/Software_Engineering_Body_of_Knowledge

https://de.wikipedia.org/wiki/Prinzip

https://de.wikipedia.org/wiki/Methode_(Softwaretechnik)

https://de.wikipedia.org/wiki/Werkzeug

https://de.wikipedia.org/wiki/Helmut_Balzert

https://de.wikipedia.org/wiki/Spezial:ISBN-Suche/3827404800

https://de.wikipedia.org/wiki/Softwarequalit%C3%A4t

https://de.wikipedia.org/wiki/Software_Engineering_Body_of_Knowledge



I Consulting, Analyse, Spezifikation und Entwurf

11 Schritte, die der Durchführung des Projekts vorausgehen



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 Pflichtenheft erfasst, Skizzen erstellt oder sonst irgendwelche Diagramme. Sie beginnt nicht mit Spezifikationen 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



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 branchenspezifische , wie auch firmenbezogene 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”.



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 Office-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



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 einfließ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.



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.



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.



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 fließen dann auch alle Ausschlüsse, Ziele, Rahmenbedingungen und so weiter mit ein. Es fließt eben ein, wo das Projekt SEINE GRENZEN HAT.



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.

ACHTUNGVermeiden Sie durch diese Maßnahmen ein “inflationä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.



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.



I. 10. Schriftliches Angebot erstellen und vom Kunden bestätigen lassen (Puffer einplanen finanz. und zeitlich)

Endlich können Sie das schriftliche Angebot erstellen und alle gewonnenen Informationen dort einfließ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.



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.



II Codierung / Programmierung

10 Schritte für die Durchführung



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.



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.

ACHTUNGWird 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.



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.

ACHTUNGIch möchte erneut davon abraten, selbst wenn der Kunde es bezahlt, nach einem wie auch immer definierten 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.



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



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 definiert stattfinden und schriftlich niedergelegt sein.

ACHTUNGWann 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.



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.

ACHTUNGVergessen 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.



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äufige 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.



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 zurechtfinden, 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 zurechtfinden zu können. Eine erfolgreiche Wartung ist ohne ein solches Vorgehen schwer möglich.



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 einfließ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 Konfliktfragen zu klären.



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.



III Programmtest, Abnahme, Integration

3 Schritte in der Testphase bis zur Abnahme



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.



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 identifizierbar 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



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.



IV Wartung

3 Schritte in der Nachbereitung



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 offiziell abgeschlossen aber “noch nicht zu Ende” ist.

Erst wenn der Kunde nach wenigen Wochen flü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.



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)



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.



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



ENDE

Weiterführende Literatur, ausgewählte Beispiele

“ProjektManager”Verlag: GPM, Deutsche Gesellschaft für ProjektmanagementAutoren: Heinz Schelle / Roland Ortmann / Astrid Pfeiffer

“Software-Engineering”Grundlagen, Menschen, Prozesse, TechnikenVerlag: DPunkt VerlagAutoren: Jochen Ludewig / Horst Lichter

“FileMaker Training Series Advanced” v13 als auch v14



Vielen Dank unseren Sponsoren

Danke für das Bewerten dieses Vortrages

FMK2015: Software Engineering Basics by Jan Rüdiger

Technology

Transcript of FMK2015: Software Engineering Basics by Jan Rüdiger