Web Engineering
am KIT Karlsruhe
am KIT Karlsruhe
Kartei Details
| Karten | 72 |
|---|---|
| Sprache | Deutsch |
| Kategorie | Informatik |
| Stufe | Universität |
| Erstellt / Aktualisiert | 27.05.2014 / 27.01.2021 |
| Weblink |
https://card2brain.ch/box/web_engineering
|
| Einbinden |
<iframe src="https://card2brain.ch/box/web_engineering/embed" width="780" height="150" scrolling="no" frameborder="0"></iframe>
|
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
