1. Überlegungen….
Softwareentwicklungsprozess
Wasserfallmodell
 die meißten Projekte werden (immer noch) in der SW-Industrie nach
demhttp://de.wikipedia.org/wiki/Wasserfallmodell][Wasserfallmodell abgearbeitet.
 neuere Projekte laufen nach http://de.wikipedia.org/wiki/Scrum][Scrum
 Der Unterschied liegt hauptsächlich darin, dass im Wasserfallmodell oft unendlich viele
Features angesammelt und dann in einem Schwung umgesetzt werdeb. Das macht es
schwierig, zu kontrollieren wie der Stand ist, was man sich wünscht usw. Nach
Projektbeginn werden neue Anforderungen nur unter großem Aufwand integriert, wenn
überhaupt.
 Bei Scrum dagegen wird in kleinen Schritten das Produkt erarbeitet und immer sofort online
gestellt. Zudem wird täglich ein Meeting gehalten.
 Egal welche Methode verwendet wird, die Erkenntnis, die sich daraus ergibt, ist immer
ganz einfach:
So geht's:
 Definiere kleine Schritte genau und gehe online
 Vorteil 1: Kunde erhält ein klares, eindeutiges und funktionierendes Produkt
 Rede viel mit den Leuten, die deinen Wunsch umsetzen, denn was du nicht genau
definiert hast, wird nicht so umsetzt, wie du es gerne hättest
 Vorteil 2: Bei jedem neuen Relase (neue Version) kannst du deine Kunden anschreiben
(Marketing)
 Baue das Produkt modular auf, damit du Kunden jedes Modul einzeln verkaufen kannst
 Verkaufe den Kunden zeitliche Zugänge
 Schenke ihnen den 1 Monat: Kunden können testen, senkt die Stornorate und ist ein gutes
Werbemittel
 Soll das Produkt Einzelkunden, Institutionen oder beides erreichen?
 Wie soll dann jeweils das Kundenprofil, die Ansprache, welche Inhalte usw. funktionieren?
 Wie und wann soll auf neue technische Änderungen reagiert werden
(Folgeentwicklungen)?
Projektlaufzettel
 Ideen/Punkte die in einem Projekt wichtig sind / sein könnten als Mindmap
 %ATTACHURL%/project.pdf][project.pdf: project.pdf
Projektprozess
1
© Günther Haslbeck http://www.guentherhaslbeck.de

2. Vorüberlegungen
 Was gehört in den Vertrag:
 Wer leistet Support? Wird das Tool extern erstellt, muss auch nach Bereitstellung ein
Support vereinbart sein (z.B .Entwickler muss 4h / Woche verfügbar sein)
(Vertragsbestandteil)
 Bei Software einen http://de.wikipedia.org/wiki/Service-Level-
Agreement][SLA / Service-Level-Agreementabschliessen
 Läuft das Programm als Windows Client Software oder braucht das Programm einen
Webserver
 Windows-Client / App
 Welche Programmiersprache ?
 Gibt es den Quellcode dazu (wenn nicht: Was ist, wenn Entwickler nicht mehr
verfügbar)
 Was, wenn es in 10 Jahren unter Windows 27, 128Bit nicht funktioniert. Wenn
Quelltext nicht vorhanden, dann keine Bugfixingmöglichkeit. Allerdings ist auch der
Quelltext nutzlos, wenn die Zeitspanne sehr gross ist, da auch die
Programmiertools dann kaum noch zur Verfügung stehen.
 Braucht die Software einen Kopierschutz
 Webseite
 Welche Programmiersprache?
 Wie funktioniert Login / Sessionmanagement
 Schnittstellen zu anderen Websites (SingleSignOn)
 Vermeide Flash
 Vermeide Javascriptlibraries
 Webserver
 Wer betreibt diesen?
 Gibts es 24/7 Bereitschaft
 Wenn Software auf „privaten“ / Uniserver läuft und kein
Ansprechpartner bei Störungen erreichbar?
 Gibt es den Quellcode dazu (wenn nicht: Was ist, wenn Entwickler nicht
mehr verfügbar)
 Sicherheitskopie von Dokumenten und Quellcode anlegen
 Vertragsbestandteile nochmals kurz
 Supportvertrag mit Programmierer / Author (auch für Updates)
 Max Zeit für Bugfixes
 Max Zeit für Antwort von Kundenanfragen, Erreichbarkeit Programmierer / Autor
 Kann die Software automatische Updates?
 Dokumentation bei Updates, was wurde geändert, wieso, wann
 Quelltext vorhanden
 Wer pflegt die Webseite/Software in Zukunft?
 CDs usw werden oft jahrelang noch als „Sonderaktion“ verkauft. Was, wenn die
Kunden dann Probleme haben, weil Software veraltet?
2
© Günther Haslbeck http://www.guentherhaslbeck.de

3.  Wem gehört der Content? Muss Programmierer / Autor für geklauten und uns angebotenen
Content haften?
 Tritt der Programmierer / Autor alle Rechte an uns ab oder darf er die Software / kompletten
Content / Softwaregerüst weiterverkaufen (= tw Quelltext) ?
 Wenn Programmierer / Autor Kundendaten speichert.. Wo (EU/US)? Datenschutz Server
usw. Wer haftet?
 Wie werden neue Versionen entwickelt.. Neue Version = Abhängigkeit (auch preislich) von
Entwickler/System/Programmiersprache?
 Dürfen wir den Produktpreis selbst festlegen?
 Was ist bei Aktionen?
 Was wenn wir das Produkt als Aktion verschenken? und Autor bekommt
Prozente?
 Support
 Schätzen wieviele Kunden anrufen bzw. das Produkt zurückgeben möchten
 Was soll dann passieren?
 Rechne die Supportkosten vom Gewinn weg: CDSupPort
Vorüberlegungen zum Produkt selbst
 Usability gegeben ?
 Wer testet / hat getestet / was / gibt es ein Protokoll dazu?
 Funktioniert Produkt in allen gängigen Betriebssystemen?
 Welche? Windows 98, XP, Vista, 7, (32 Bit, 64 Bit), MacOsX, Linux
 Funktioniert Produkt in allen gängigen Browsern (und Versionen)?
 Internet Explorer 7,8,9, Firefox (Windows + Mac + Linux), Safari (Windows + Mac), Chrome
(Windows + Mac + Linux),
Opera http://www.webhits.de/deutsch/index.shtml?webstats.html][Welche Browser nutzen
die Leute gerade
 Mobile Browser: Ipad, Iphone, Android usw
 Flash sollte so wenig wie möglich verwendet werden, da nicht auf Iphone
 Ausnahme für Videodarstellung
 Welche mind. Bildschirmauflösung ist
nötig http://www.webhits.de/deutsch/index.shtml?webstats.html][Welche
Bildschirmauflösung nutzen die Leute gerade
 Performance
 Lädt die Seite schnell (sollte nicht mehr als 2 Sek komplett! brauchen / Seite)
 Wieviele User hält die Seite aus, wie wurde da getestet? (Protokoll)
 Ist die Seite sicher gegen typische Sicherheitslücken wie http://de.wikipedia.org/wiki/SQL-
Injection][SQL-Injection , XXS usw?
(Protokoll) http://www.heise.de/security/artikel/Sicherheit-von-Webanwendungen-
270870.html][weitere Sicherheitslücken
 Ist die Datenbank nach aussen mit einer Firewall gesichert (Portscan) ?
 Sind spezielle Plugins nötig, wenn ja, unter welchen Betriebssystemen / Browsern gibt's
die?
3
© Günther Haslbeck http://www.guentherhaslbeck.de

4.  Wenn die Seite Popups öffnet: Merken Toolbars das und blockieren diese? Das kann so
programmiert werden, dass das kein Problem ist
Produkt-Entwicklungsprozess (kurz)
 Produktmanager hat eine Idee
 Freigabe der Projektierungsphase durch Sponsor (Geldgeber)
 Absprache mit Projektmanagement
 Erstellung Lastenheft
 Lastenheft Review
 Erstellung Pflichtenheft (durch Agentur)
 Pflichtenheft muss! von der Gliederung mit Lastenheft zusammenpassen, sonst Abgleich
schwierig
 Jeder Punkt muss ausformuliert werden, nur dann kann man sicher sein, dass die Agentur
verstanden hat, was gewünscht wird
 Erstellung einer Roadmap (http://de.wikipedia.org/wiki/Gantt-Diagramm][Gantt-Chart) -
Wer macht was bis wann
 Darauf basierend eine Aufwandsschätzung in Tagen und Euro
 Typisches Gantt Chart
 <img
src=„http://www.guentherhaslbeck.de/private/album/data/sonstiges/gantt_diagramm.png“
width=„1005“ height=„233“ />
 Finale Freigabe des Sponsors anhand der Schätzung
 Umsetzung
 Testphase
 Onlinegang
 Nachkontrolle
 Abnahme
Use Cases / Wireframes
 Beschreibe genau, wie die Seiten aussehen
als http://de.wikipedia.org/wiki/Anwendungsfall][Use Cases, am besten erstellt du
einfache Wireframes z.B. mit http://pencil.evolus.vn/en-US/Home.aspx][Pencil, damit der
Entwickler versteht wie die Seite aussehen soll:
 Beispiel Screen und Beschreibung: IP-Freischaltung des OT <i>Die Oberfläche könnte in
etwa wie im folgenden Scribble aussehen. Abhängig von den Anforderungen aus Punkt 1.
Zugänglich ist die Oberfläche nur für das Elsevier-Büro (Redaktionssystem)
Die Einträge können nach „Freigeschaltet bis“-Datum oder Schulnamen sortiert werden. Ist das
FreigeschaltBis-Datum abgelaufen, so ist der IP-Zugang nicht mehr möglich. Durch Ändern des
Datums ist der Zugang wieder verfügbar. Durch Farben sollen aktive und inaktive Einträge
ersichtlich sein.</i>
 <img src=„http://www.guentherhaslbeck.de/private/album/data/sonstiges/OT-Screen.png“
alt=„OT-Screen.png“ />
4
© Günther Haslbeck http://www.guentherhaslbeck.de

5.  Erstelle http://de.wikipedia.org/wiki/Anwendungsfall][Use Cases als Text und
alshttp://de.wikipedia.org/wiki/Anwendungsfalldiagramm][Use Case
Diagramm oderhttp://de.wikipedia.org/wiki/Anwendungsfall_%28UML%29][Diagramme (UML)
 <img src=„http://www.guentherhaslbeck.de/private/album/data/sonstiges/ot-usecase1.png“ alt=„ot-
usecase1.png“ width=„594“ height=„248“ />
 UseCases als Text könnten so aussehen (genaue Beschreibung sollte vom Aufragnehmer im
Pflichtenheft erfolgen, vorformulieren kann aber nicht schaden)
 Vorbedingungen
 Nachbedingungen im Erfolgsfall
 Nachbedingungen im Fehlerfall
 Auslösendes Ereignis (User clickt…)
 Hauptszenario (Was muss der User machen, welche Bedingungen müssen erfüllt sein
(Pflichtfelder)..)
 Weiterführende Informationen (z.B. Verweis auf andere Usecases)
 Testszenario
 kurz erläutern auf welcher technischen Basis die Umsetzung der einzelnen
Teilkomponenten geschieht (jsp/Javascript usw)
Produkt-Entwicklungsprozess (ausführlich)
 Folgendes ist die Mindmap: %ATTACHURL%/project.pdf][project.pdf als Text:
Produktmanager hat eine Idee
 Kunden Nutzen in einem Satz beschreiben - Geht das? Wenn nicht, wie soll Kunde das
dann verstehen?
 Welches Bed&#252;rfnis wird gedeckt
 Lieber kleine Schritte als 1 grossen
 Zielgruppe definieren
 Kosten grob sch&#228;tzen optimistisch | realistisch | pessimistisch
 Gesch&#228;ftsmodell / Einnahmen definieren
 Produktmanager ist auch nachher f&#252;r Produkt verantwortlich
 Webprodukte enden nicht / nie !
 Gew&#252;nschter Endtermin?
 Point of No Return (bis wann muss man wissen, ob das Produkt was wird, um z.B.
Printaufträge oder Werbeschaltungen noch stoppen zu können)
 Aufwand f&#252;r Lastenhefterstellung grob sch&#228;tzen
 Soll Prototyp gebaut werden? / Wireframes - Dann auch Kosten mit rein
Freigabe der Projektierungsphase durch Sponsor (Geldgeber)
Absprache mit Projektmanagement
 Wiki-Seite erstellen
 Nach Vorlage -ProjektVorlage- und in TimSaTo eintragen
 Projectowner / Auftraggeber
 Idee / Problem beschreiben
5
© Günther Haslbeck http://www.guentherhaslbeck.de

6. Lastenheft
 Inhalt
 Zusammenfassende Beschreibung
 Zielsetzung
 Zielgruppe
 Kernfunktionen
 Sep Domains n&#246;tig
 Generell
 Auftraggeber
 Projektmanager
 Abteilungen
 Verbundene Dokumente + Inhalt
 Personen
 Rollen / Veranwortlichkeit
 z.B. Auftraggeber
 Projektmanager
 Qualit&#228;tssicherung / Tester / Doku
 Technik
 Operations
 Funktionale Anforderungen
 Use-Cases - Jeweils pro Use-Case
 Use-Case-Diagramme (UML)
 Beschreibung des UC-Diagrammes
 Text der genauen Abl&#228;ufe
 Wireframes / Screenshots
 Use-Cases
 Kurzbeschreibung
 Vorbedingung
 Nachbedingung im Erfolgsfall
 Nachbedingung im Fehlerfall
 Ausl&#246;sendes Ereignis
 Hauptzenario
 Schritt 1
 Schritt 2
 Alternative Szenarien
 Nicht-funktionale Anforderungen
 Mengenger&#252;st (Anzahl User usw)
 Performance
 SLAs
 Sicherheitsanforderungen
6
© Günther Haslbeck http://www.guentherhaslbeck.de

7.  Anforderungen an Statistik
 Support
 Briefing
 Aufwand
 Kosten
 Kundensupport
 Laufender Aufwand / Kunde
 Kosten / Kunde
 Technik
 Briefing
 Kosten
 Schulungsaufwand
 Technische Rahmenbedingungen
 AGB / Datenschutz usw definieren
 Checkliste für Lastenheft
 Alle Dokumente vollst&#228;ndig und vorhanden
 Alle Personen / Firmen aufgelistet,
 die umsetzen (entwickeln)
 die testen
 die Review machen
 Vermittelt Zusammenfassung eindeutig das Projektziel und Kernfunktionen
 Sind alle Schnittstellen nach / von Extern definiert
 Funktionale Anforderungen ausreichend beschrieben
 Daten
 Prozesse / Workflows
 Was passiert wenn User Aktion ausf&#252;hrt
 ggf. Fehlermeldungen / Fehlerverhalten
 Nichtfunktionale Anforderungen ausreichend beschrieben
 Muss im MeinAccount was verkn&#252;pft werden
 Evtl kann zum Lastenheft / Nutzerkonzept ein Prototyp erstellt werden
Lastenheft Review
 Ist alles drin was der Auftraggeber haben möchte?
 Ist jeder Punkt durchnummeriert? (Gliederung)
 Was nicht im Lastenheft steht oder nur schwammig, wird auch nicht oder nur schwammig
umgesetzt!
Pflichtenheft
 Sollte von der Gliederung mit Lastenheft zusammenpassen, sonst Abgleich schwierig
 = Punkte des Lastenhefts mit Details zur Umsetzung
Weitere Punkte f&#252;r Pflichtenheft:
 Inhalt
7
© Günther Haslbeck http://www.guentherhaslbeck.de

8.  Einleitung
 Einf&#252;hrung und Projektziele
 Funktionale Anforderungen
 Beschreibung des Dienstes / Der Webseite
 Use-Case-Diagramme
 Beschreibung des UC-Diagrammes
 Text der genauen Abl&#228;ufe
 Wireframes / Screenshots
 Usermanagement
 Nicht-funktionale Anforderungen
 Technische Rahmenbedingungen
 Vorgegebene Hardware
 Zu verwendende Software
 Verwendete Frameworks
 Serversoftware
 Datenbanktabellen
 Schnittstellen
 verwendete Protokolle
 verwendete Partner
 Schnittstellen
 Monitoring
 Mengenger&#252;st
 Userzahlen erwartet
 Performance
 Verf&#252;gbarkeit
 Skalierung (zB wie)
 Webdesign
 Navigation
 Breadcrumb (Wo liegt die Seiten)
 Header / Bottom der Seite
 Tracking
 Backup-Strategie
 SLAs
 Datenmodelle
 Screendesigns
 Tests
 automatische Tests
 Testszenarien festlegen
 Testkonzepte festlegen
 Wer
8
© Günther Haslbeck http://www.guentherhaslbeck.de

9.  Wie
 Testabl&#228;ufe
 Deployment Strategie (Online-Gang-Strategie)
 Wann umschalten
 Wie umschalten
 Betrieb
 &#220;berwachung
 Statistiken
 Support
 Supportschnittstelle
Erstellung der Roadmap
 Todo-Liste
 Test-Liste
 Wer macht was bis wann
 Ausf&#252;hrliche Beschreibung der Todos mit Zieldatum
Aufwandssch&#228;tzung auf Basis v Roadmap
 Summe in Tagen muss nicht Euro sein. z.B. 8 Arbeitstage: wenn jemand nur 1/2 Tag
arbeitet sind nur 4*Tagessatz!
Finale Freigabe des Aufwands / Kosten durch Sponsor
Umsetzung
 Laufende Kontrolle der Roadmap
 Eskalation bei Problemen / Terminverzug
 Termine f&#252;r Entscheidungen festlegen
 Keine Entscheidung: Projekt On-Hold
 W&#246;chentliche Info &#252;ber Stand an Auftraggeber / Stakeholder
Testen
 verschiedene Browser
 verschiedene BS-Auflösungen
 verschiedene Betriebssysteme
 Javascript ausschalten
Onlinegang
 Trackingscodes drin, sprechende URLs eingerichtet: /buch1/kapitel1.html statt
/9484/si7373
 alle Dateien online
 Links ok
 Backup-Strategie
 Files
 Datenbank
Bearbeiten
9
© Günther Haslbeck http://www.guentherhaslbeck.de

10. Administration bei Serveranwendungen
Backups
 Vom Code-Repository, Livesystem, Konfigurationen (Apache/Tomcat) und der Datenbank
sind regelmässig Updates zu ziehen und in einem separaten Filesystem abzulegen.
 Es muss ein Wiedereinspielungsszenario vorliegen, damit im Fehlerfalle zumindest
schnell der letzte Stand wiederhergestellt werden kann.
Logfiles
 Um Vorgänge der Kunden zu protokollieren, sind Logfiles in einem Verzeichnis zu
erstellen.
 Die Logfiles haben jeweils folgenden entsprechenden Namen:
 ../[YYYY][MM][DD]-[servername]-[Tool/Bereich/Usecasename].log also z.B.
 20090626-www1-ipoberflaeche.log
 Die Inhalte sind jeweils in 1 Zeile pro Eintrag zu schreiben, die Inhalte sind Tab-getrennt.
 und beginnen immer mit:
 [Datum]t[Uhrzeit}t[Warnlevel]t[IP des Kunden]t[zu loggender Inhalt]
 Als Warnlevel ist im normalfalle INFO (in Grossbuchstaben) zu verwenden
[DEBUG,INFO,WARN,ERROR,FATAL = (log4j, Apache usw) ]
Systemüberwachung
Programmüberwachung
 Zur Überwachung sollten Systeme eingesetzt werden, die melden wenn ein System
Fehler feststellt. Diese Oberfläche muss Elsevier und dem Entwickler zugängig sein.
 Die Logfiles sollten
über http://manpages.ubuntu.com/manpages/hardy/man7/hobbit.7.html][Hobbit oderhttp:/
/www.nagios.org/][Nagios eingelesen und verarbeitet werden.
 Treten gehäuft Fehler auf ,so wird in Hobbit/Nagios die Oberfläche rot. Man sieht, wo die
Fehler aufgelaufen sind. Gleichzeitig wird ein Admin alarmiert, um das Problem zu beheben.
 In die Mailingliste sollte auch Elsevier eingetragen sein, um die Störungen
mitzubekommen
Systemüberwachung
 http://de.wikipedia.org/wiki/Multi_Router_Traffic_Grapher][MRTG oder RTT oder
ähnliches sollten eingesetzt werden um CPU, Memory, Festplatten- Auslastung
mitzuzeichnen und Spitzen usw. zu erkennen.
10
© Günther Haslbeck http://www.guentherhaslbeck.de