Web Engineering
am KIT Karlsruhe
am KIT Karlsruhe
-
- 1 / 72
-
Lernkarten
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
CMS
unterstützt die CM-Aufgaben: Sammlung, Management, Veröffentlichung
Auswahl nach Anforderungen, Logisches Design (Workflows, Organisation des Contents), Kosten
muss angepasst werden!
Usability
Ausmaß mit dem man ein Produkt effektiv, effizient und zufriedenstellend nutzen kann
User Experience
Vorstellung und Reaktion einer Person bei der Nutzung eines Produktes
User Centered Design Process
Fokus auf Nutzern statt Stakeholdern
Research -> Modelling -> Requirements -> Framework -> Refinement -> Support
Usability als Wettbewerbsvorteil
erhöht ROI
Conversion Rate als Maßzahl für ROI
Implementation Model und Represented Model
Implementation: Programmierersicht
Represented: Anwendersicht, sollte möglichst nach am Mentalmodell des Nutzers sein (--> Warenkorb)
User Interface Modelling
Visual Design, Structure, Interaction
Personas
fiktionales Benutzermodell
entwickelt aus Nutzerforschung
Modeling Interaction
Flow Charts, Story Boards, Wireframes (Tiles&Controls)
Usability Testing
Empirisch: Usability Lab, Remote Testing
Analytical: Experten
Business Process
zwei oder mehr autonome Teilnehmer
Kommunikation zwischen Beteiligten (z.B. über Operationen)
systematisch und wiederkehrend
Endpoint (aka Service Access Point)
spezifiert durch Protokolle und Datenformate
werden von einem Service bereitgestellt (XML Webservice, Komponenten, Dateisystemen,...)
SOA
Service Oriented Architecture, bestehend aus Service Provider, Service Consumer, Service Broker
architektonisches Konzept, das die Verwendung und Bereitstellung von Services zwischen Teilnehmern in einem standardisierten Verfahen definiert
technologieunabhängig, konzentriert sich auf Beziehungen
Service
Autonomes, in sich abgeschlossenes, wiederverwendbares Softwaresystem das eine bestimmte Businessfunktion erfüllt mithilfe von Nachrichtenaustausch in einem standardisierten Format
Remote Procedure Call und IDL
Programmiersprachenbasierter Fremdaufruf einer Funktion/Prozedur
IDL: Interface Definition Language: Signatur, Input/Output-Parameter
Probleme:
- Firewalls
- schwieriges Debugging
- keine Standardsyntax
WSDL
Web Service Description Language
für XML Web Services
genügen festen Schemata: SOAP Bindung, HTTP GET od. POST-Binding, WSDL MIME Binding
