Web Engineering
am KIT Karlsruhe
am KIT Karlsruhe
-
- 1 / 72
-
Lernkarten
CSS
Separate Sprache um alle Präsentationsaspekte zu steuern (Farben, Grenzen, Textfluss, Positionierung,...)
--> Aussehen und Inhalt der HTML-Dateien kann separat entwickelt und weiterverwendet werden
XML
universelles Format für strukturierte Dokumente und Daten im Web
hierarchisch strukturiert
besteht aus Elementen und Attributen
CHAOS Top Success Factors
- Unternehmensleitung
- Nutzer einbeziehen
- erfahrener Projektmanager
- klare Geschäftszwecke/ziele
- Scope minimal halten
.....
Project Failure Rates
ca. 25% scheitern, 45% haben Probleme, nur ca 1/3 verlaufen nach Plan
--> Scheitern oft nicht technologiebedingt!
Mögliche Projektstrategien
- outsourcen
- in die Cloud bringen
- finden und kaufen
- neue Lösung entwickeln (Development with reuse not for reuse --> braucht man im Endeffekt eh nicht)
SCRUM: Rollen
Product Owner
Scrum Master
Team
- ALLE Rollen sind MANAGEMENT-Rollen! -
Legende von Huhn und Schwein
Tenor: jeder muss gleich viel beisteuern
Was ist ein Projekt?
Vorhaben, das insbesondere EINZIGARTIG ist (in Bezug auf die Gesamtbedingungen)
Work Breakdown Structure
unterhalb eines Projektes
Kategorisierte Liste an Aufgaben
Program
oberhalb von Projekten
--> Gruppe von zentral koordinierten Projekten
eher für langfristige Ziele
Probleme bei Projekten
nur 28% in vorgegebener Zeit (98% davon hatten aber Projektmanager)
unrealisitsche Zeitpläne (Nachlässigkeit, unrealistische Ziele, unterschätzten Problemen, beschönigten Erwartungen, Chicken&Pig!)
verschiedene Stakeholder früh einbeziehen (für Erwartungen besser, aber Konsens schwieriger!)
Dokumentation (werden wiederbenutzt --> kann zu Versionierungshölle werden, am besten Wiki)
GANTT
Projektmanagement Tool um Abhängigkeiten und zeitliche Abfolge mithilfe von Balken übersichtlich darzustellen
Pro: einfach
Contra: gerade Großprojekte sind zu komplex um sie damit abbilden zu können
PM-Tools: durchzuführende Arbeiten
Requirement Analysis
Requirement Definition
Design
Implementation
Testing
Operation&Maintenance
Risikomanagement
Risiko: alle Events die das Vorhaben potenziell negativ beeinflussen KÖNNEN
Evaulieren: Qualität ("Schwere") und Qunatität (Eintrittswahrscheinlichkeit) des Risikos
Prozessmodelle allgemein
Ziel: systematische (Wer macht was), disziplinierte (=zuverlässig), quantifzierbarer (Zeit, Kosten,...) Ablauf&Entwicklung
Prozessmodelle im WebEng
Jede Menge ... Zum Beispiel:
Code and Fix (ad hoc Entwicklung) (für kleine Projekte gut, oft genutzt)
Wasserfall (klare von-oben-herab-Entwicklung, Schritt-für-Schritt/Meilensten für Meilenstein, problematisch wenn Probleme am Anfang)
Prototyping (Anforderungen festlegen, Prototyp bauen, Prototyp schrittweise verbessern)
Rational Unified Process (RUP): siehe extra Karte
MSFv3
Agile Prozesse
Scrum
RUP
vier große Phasen:
Inception: Vision, Anwendungsfall, grobe Architektur, Größe des Projektes
Elaboration: = Detailplanung
Construction = Implementierung
Transition = Auslieferung & Schulung
MSF
Prozessmodell: Vision, Planung, Entwicklung, Stabilisierung, Auslieferung
Prozessübersicht:
- Product Management: Konzeptionales Design (Szenarien, Konzeptionale Datenbank)
- Program Management: Logisches Design (Objekte und Services, UserInterface, logishce Datenbank) und physisches Design (Komponenten, User Interface und physische Datenbank)
Agile Prozesse
Reaktion auf bürokratisierte Prozesse ( zu viel vs. zu wenig Prozess)
Individuen & Interaktion > Prozess&Werkzeuge
Funktionierende Software > Umfassende Doku
Kundenbeteiligung > Vertragsverhandlungen
Auf Veränderungen reagieren > dem Plan folgen
Agile Methoden
XP:
Tests als Grundlage der Entwicklung --> Tests zuerst schreiben, Iterationsdauer zw. 1 und 3 Wochen
Scrum:
Iteration von 2-4 Wochen, Einzeltasks nicht länger als 24 Stunden, wird täglich überprüft (Sprintmeeeting 15 Minuten) Product Backlog mit Änderungswünschen wird priorisiert und in einem Sprit umgesetzt, am Ende überprüft und ein neuer Product Backlog für nächsten Sprint erstellt
Requirements Engineering Phasen
Initiate
Elicitate
Assess
Specification and Validation
Spezielle Requirements für Webanwendungen
datenintensiv, unterschiedliche Performance-Aspekte
verteilte und heterogene Umgebungen
Sicherheit und Datenschutz
Accessibility und Usability
Ästhetik und Trends
Rechtliche Aspekte
Internet/Weltweiter Scope: Nutzer/Zielgruppe unbekannt
Was ist bei Requirements zu beachten
Sie ändern sich!
Requirements zu definieren und zu managen ist ein Haupterfolgsfaktor!
--> bedeuten unterschiedliche Dinge für unterschiedliche Leute!
--> Dokumentation sehr wichtig!
Requirements: Stakeholders
Sind diese Personen bekannt?
Enduser
Kunde
Mitarbeiter
Marketing/Presse
Verwaltung
Betriebe
Kundensupport
Redakteure/Inhalteersteller
Domänenexperten
----
Intranet: Personen bekannt
Internet: Personen unbekannt
Was ist eine Anforderung/ein Requirement?
ein Bedürfnis! Eine gut beschriebene Anforderung vermittelt das Bedürfnis in einer klaren, präzisen und verifizierbaren Art&Weise denjenigen, die das Bedürfnis erfüllen sollen
Arten von Anforderungen
Funktionale Anforderungen: Was das Produkt können muss, Datenwerte, Klassendiagramme, Algorithmen,...
Non-Funktionale Anforderungen: zielt ab auf Qualität (Effizienz, Wartung, Mobilität, Usability, Zuverlässigkeit, funktionale Qualitäten, ...)
Requirements Development Process
Initiate -> Elicitation -> Assess -> Specification -> Validation
Requirements Levels
Business Requirements: High-Level-Ziele
User Requirements: Aufgaben, die Nutzer bewältigen können sollen
Environmental Requirements: Verfügbare Technologie als auch Ökosystem der Anwendung
Operational Requirements: Aufgaben, die Administratoren bewältigen können sollen
Initiate Phase - Ziele
Vision und Scope-Dokument, verifiziert durch Stakeholder
Business Requirements sind gesammelt und fix (idealerweise)
Erste Scopes definiert, aber noch änderbar
Glossar
Project Team und Kunden: Memorandum of Agreement
Project Team und Management: Projekt ist abgesegnet
Elicit Phase - Ziele
Präzisieren der Business Requirements: Warum (Business Requirement) mache ich was (Funktional) und wie (Non-Funktional/Qualität)?
Besseres Verständnis der Produktfeatures
Vision verbessern/Scope spezifieren durch Präzisierung des Scopes
Assess Phase - Ziele
Anforderungen verstehen und organisieren
Review der funktionalen Anforderungen (Features definieren, Prototyping,...)
Non-funktionale Anforderungen handeln (Invarianten, Constrains, Triggers, Berechnungen, Fehlerbehandlung,...)
Specifiation and Validation - Ziele
Software Requirements Specification (muss man sich drauf verlassen können!)
Benutzbar und bereit für Änderungen
Featurebeschreibungen: Von wem, Ressourcen, Priorität, Abhängigkeiten/Risiken/mögl. Lösungen, User Stories, Test-Kritierien(!)
SRS-Template: Intro, Allgemine Beschreibung, System Features, Externe Interface Anforderungen, Andere non-funktionale Anforderungen, andere ANforderungen
Managing Requirements and Change
Project's Change Management: nichts wird geändert ohne Erlaubnis (--> Change Control Board)
kann sehr aufwändig sein
Content Management
sammeln, managen, veröffentlichen
Content Types
Definieren Content-Struktur (nicht zu verwechseln mit MIME-Types!)
DTD
Wird genutzt für: Sharing/Wiederverwendung von Grammatiken, Parservalidierung, Default-Werte
Schwächen: nicht sehr mächtig (Datentypen stark begrenzt), eigene Sprache notwendig, teilweise inkompatibel mit Datenbanken
XML Schema Definition Language (XSD)
"Übermenge" der Möglichkeiten von DTD
W3C-Empfehlung
Meta-Sprache um Syntax und Semantik (Datentypen) eines Markups zu definieren
Formale Grammatik-Spezifizierung einer Sprache
Herausforderungen: Namenskonflikte (--> Namespaces), Erweiterbarkeit (--> Vererbung), Wiederverwendbarkeit (--> Einbindung und Neudefinition)
Templates
schließen die Lücke zwischen Komponenten und Veröffentlichungen
Typen: Seiten-, Navigations- und Komponententemplates
Systeme: Sprachenunabhängige (XSLT), Teil eines Frameworks (ASP.NET, JSF), Teil eines CMS, Stand-alone (für PHP, Perl, Python,...)
Metadata
Daten über Daten, zur Kategorisierung, Verwaltung großer Contentmengen,...
Zum Finden, Weiterverarbeiten, Teilen,...
Probleme: Nutzer sind sich (oft) nicht der Wichtigkeit bewusst --> strikte Richtlinien, Zwang zur Nachbearbeitung durch Experten
Workflows
besteht aus aufeinanderfolgenen Unteraufgaben
treten wiederholt in CMS auf
CMS unterstützt Aufgabenzuweisung, Aufgabentrigger und AUfgabenbewältigung
--> Analyse und Implemeniterung notwendig, evtl. Verknüpfung mit anderen Prozessen, Schulung der Anwender
