Your SlideShare is downloading. ×
Ueberlegungen Projektmanagement Web Applications
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Saving this for later?

Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime - even offline.

Text the download link to your phone

Standard text messaging rates apply

Ueberlegungen Projektmanagement Web Applications

975
views

Published on


0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
975
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
6
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Überlegungen….SoftwareentwicklungsprozessWasserfallmodell  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 gehts:  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.pdfProjektprozess 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: CDSupPortVorü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 gibts 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 istProdukt-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  AbnahmeUse 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 dasFreigeschaltBis-Datum abgelaufen, so ist der IP-Zugang nicht mehr möglich. Durch Ändern desDatums ist der Zugang wieder verfügbar. Durch Farben sollen aktive und inaktive Einträgeersichtlich 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 reinFreigabe 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 werdenLastenheft 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 UmsetzungWeitere 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  SupportschnittstelleErstellung der Roadmap  Todo-Liste  Test-Liste  Wer macht was bis wann  Ausf&#252;hrliche Beschreibung der Todos mit ZieldatumAufwandssch&#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 SponsorUmsetzung  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 / StakeholderTesten  verschiedene Browser  verschiedene BS-Auflösungen  verschiedene Betriebssysteme  Javascript ausschaltenOnlinegang  Trackingscodes drin, sprechende URLs eingerichtet: /buch1/kapitel1.html statt /9484/si7373  alle Dateien online  Links ok  Backup-Strategie  Files  DatenbankBearbeiten 9 © Günther Haslbeck http://www.guentherhaslbeck.de
  • 10. Administration bei ServeranwendungenBackups  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