SlideShare ist ein Scribd-Unternehmen logo
1 von 10
Downloaden Sie, um offline zu lesen
Ü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
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
   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
   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
   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
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
      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
      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
      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
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

Weitere ähnliche Inhalte

Andere mochten auch

Open Initiatives: Vorteile offener Wissensproduktion und Informationsbereitst...
Open Initiatives: Vorteile offener Wissensproduktion und Informationsbereitst...Open Initiatives: Vorteile offener Wissensproduktion und Informationsbereitst...
Open Initiatives: Vorteile offener Wissensproduktion und Informationsbereitst...
uherb
 
Chiffrofete - Divers élements de réflexions
Chiffrofete - Divers élements de réflexionsChiffrofete - Divers élements de réflexions
Chiffrofete - Divers élements de réflexions
Jérôme aka "Genma" Kun
 
Figaronron - Ducasse d'Ath 03 (23-08-2009)
Figaronron - Ducasse d'Ath 03 (23-08-2009)Figaronron - Ducasse d'Ath 03 (23-08-2009)
Figaronron - Ducasse d'Ath 03 (23-08-2009)
Figaronron Figaronron
 
Microblogging & Networking
Microblogging & NetworkingMicroblogging & Networking
Microblogging & Networking
Damien Guinet
 
Informaticabeni
InformaticabeniInformaticabeni
Informaticabeni
benilde
 

Andere mochten auch (20)

Open Initiatives: Vorteile offener Wissensproduktion und Informationsbereitst...
Open Initiatives: Vorteile offener Wissensproduktion und Informationsbereitst...Open Initiatives: Vorteile offener Wissensproduktion und Informationsbereitst...
Open Initiatives: Vorteile offener Wissensproduktion und Informationsbereitst...
 
Escale santé n°7
Escale santé n°7Escale santé n°7
Escale santé n°7
 
Loi de finances 2014
Loi de finances 2014Loi de finances 2014
Loi de finances 2014
 
Ergebnisse im netzwerk
Ergebnisse im netzwerkErgebnisse im netzwerk
Ergebnisse im netzwerk
 
Chiffrofete - Divers élements de réflexions
Chiffrofete - Divers élements de réflexionsChiffrofete - Divers élements de réflexions
Chiffrofete - Divers élements de réflexions
 
Figaronron - Ducasse d'Ath 03 (23-08-2009)
Figaronron - Ducasse d'Ath 03 (23-08-2009)Figaronron - Ducasse d'Ath 03 (23-08-2009)
Figaronron - Ducasse d'Ath 03 (23-08-2009)
 
Décret n°2002 598-du_25_avril_2002
Décret n°2002 598-du_25_avril_2002Décret n°2002 598-du_25_avril_2002
Décret n°2002 598-du_25_avril_2002
 
Web2.0images
Web2.0imagesWeb2.0images
Web2.0images
 
Le paradoxe des banques coopératives
Le paradoxe des banques coopérativesLe paradoxe des banques coopératives
Le paradoxe des banques coopératives
 
1. banco interamericano de desarrollo
1.  banco interamericano de desarrollo1.  banco interamericano de desarrollo
1. banco interamericano de desarrollo
 
Editorialista de the guardian resalta cambios en ecuador
Editorialista de the guardian resalta cambios en ecuadorEditorialista de the guardian resalta cambios en ecuador
Editorialista de the guardian resalta cambios en ecuador
 
Esen espe
Esen espeEsen espe
Esen espe
 
Social Media Impact: Resonanz und Wirkung in sozialen Medien. Anwendungsbeisp...
Social Media Impact: Resonanz und Wirkung in sozialen Medien. Anwendungsbeisp...Social Media Impact: Resonanz und Wirkung in sozialen Medien. Anwendungsbeisp...
Social Media Impact: Resonanz und Wirkung in sozialen Medien. Anwendungsbeisp...
 
Atelier competence-imprime
Atelier competence-imprimeAtelier competence-imprime
Atelier competence-imprime
 
Figaronron - Lucky star complète collection
Figaronron - Lucky star complète collectionFigaronron - Lucky star complète collection
Figaronron - Lucky star complète collection
 
Vicky_Shalaigh
Vicky_ShalaighVicky_Shalaigh
Vicky_Shalaigh
 
Microblogging & Networking
Microblogging & NetworkingMicroblogging & Networking
Microblogging & Networking
 
Die Masse machts - Crowdinvesting als Finanzierungsalternative
Die Masse machts - Crowdinvesting als FinanzierungsalternativeDie Masse machts - Crowdinvesting als Finanzierungsalternative
Die Masse machts - Crowdinvesting als Finanzierungsalternative
 
Informaticabeni
InformaticabeniInformaticabeni
Informaticabeni
 
Internet Marketing Seminar
Internet Marketing SeminarInternet Marketing Seminar
Internet Marketing Seminar
 

Ähnlich wie Ueberlegungen Projektmanagement Web Applications

Ähnlich wie Ueberlegungen Projektmanagement Web Applications (20)

6 verschiedene Arten von Software
6 verschiedene Arten von Software6 verschiedene Arten von Software
6 verschiedene Arten von Software
 
Software Entwicklung im Team
Software Entwicklung im TeamSoftware Entwicklung im Team
Software Entwicklung im Team
 
Top 10 Internet Trends 2005
Top 10 Internet Trends 2005Top 10 Internet Trends 2005
Top 10 Internet Trends 2005
 
Gewinnung von OPEN SOURCE Techniken für junge Unternehmen
Gewinnung von OPEN SOURCE Techniken für junge UnternehmenGewinnung von OPEN SOURCE Techniken für junge Unternehmen
Gewinnung von OPEN SOURCE Techniken für junge Unternehmen
 
Groupware Linuxtag 2008 Cb
Groupware Linuxtag 2008 CbGroupware Linuxtag 2008 Cb
Groupware Linuxtag 2008 Cb
 
Zinit.leistungen.webentwicklung.v1.0.de
Zinit.leistungen.webentwicklung.v1.0.deZinit.leistungen.webentwicklung.v1.0.de
Zinit.leistungen.webentwicklung.v1.0.de
 
HCL Domino 14 - Leap 1.1.2 - DNUG Stammtisch Wien
HCL Domino 14 - Leap 1.1.2 - DNUG Stammtisch Wien HCL Domino 14 - Leap 1.1.2 - DNUG Stammtisch Wien
HCL Domino 14 - Leap 1.1.2 - DNUG Stammtisch Wien
 
Config as Code: Der Weg zu Configuration as Code
Config as Code: Der Weg zu Configuration as CodeConfig as Code: Der Weg zu Configuration as Code
Config as Code: Der Weg zu Configuration as Code
 
XPages - The Basics
XPages - The BasicsXPages - The Basics
XPages - The Basics
 
Fonda: Erfolgsfaktor Benutzeroberfläche
Fonda: Erfolgsfaktor BenutzeroberflächeFonda: Erfolgsfaktor Benutzeroberfläche
Fonda: Erfolgsfaktor Benutzeroberfläche
 
Code-Generierung vereinfacht IoT-Entwicklung
Code-Generierung vereinfacht IoT-EntwicklungCode-Generierung vereinfacht IoT-Entwicklung
Code-Generierung vereinfacht IoT-Entwicklung
 
Entwicklung mit Volt MX und Co. | Teil 1
Entwicklung mit Volt MX und Co. | Teil 1Entwicklung mit Volt MX und Co. | Teil 1
Entwicklung mit Volt MX und Co. | Teil 1
 
2008 - Gewinnung von OPEN SOURCE Techniken für junge Unternehmen
2008 - Gewinnung von OPEN SOURCE Techniken für junge Unternehmen2008 - Gewinnung von OPEN SOURCE Techniken für junge Unternehmen
2008 - Gewinnung von OPEN SOURCE Techniken für junge Unternehmen
 
Community Camp 2016: Die richtige Forensoftware
Community Camp 2016: Die richtige ForensoftwareCommunity Camp 2016: Die richtige Forensoftware
Community Camp 2016: Die richtige Forensoftware
 
Umsetzungsstrategien für Cross-Plattform Projekte - IA Konferenz 2013 Klaus R...
Umsetzungsstrategien für Cross-Plattform Projekte - IA Konferenz 2013 Klaus R...Umsetzungsstrategien für Cross-Plattform Projekte - IA Konferenz 2013 Klaus R...
Umsetzungsstrategien für Cross-Plattform Projekte - IA Konferenz 2013 Klaus R...
 
20120207 prs ib_js_libraries_v02
20120207 prs ib_js_libraries_v0220120207 prs ib_js_libraries_v02
20120207 prs ib_js_libraries_v02
 
Top 10 Internet Trends 2006
Top 10 Internet Trends 2006Top 10 Internet Trends 2006
Top 10 Internet Trends 2006
 
Slides (2) zu Teil 2 der Veranstaltungsreihe Anwendungsentwicklung mit Volt M...
Slides (2) zu Teil 2 der Veranstaltungsreihe Anwendungsentwicklung mit Volt M...Slides (2) zu Teil 2 der Veranstaltungsreihe Anwendungsentwicklung mit Volt M...
Slides (2) zu Teil 2 der Veranstaltungsreihe Anwendungsentwicklung mit Volt M...
 
Templates, Code & Tools
Templates, Code & ToolsTemplates, Code & Tools
Templates, Code & Tools
 
Case Study: Produktkonfigurator Web-App
Case Study: Produktkonfigurator Web-AppCase Study: Produktkonfigurator Web-App
Case Study: Produktkonfigurator Web-App
 

Ueberlegungen Projektmanagement Web Applications

  • 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