Skip to content
Permalink
Branch: master
Find file Copy path
Find file Copy path
Fetching contributors…
Cannot retrieve contributors at this time
842 lines (644 sloc) 22.6 KB
title author toc export_on_save html puppeteer
Zusammenfassung SWEN2
Michael Schaufelberger
depth_from depth_to ordered
2
6
false
html puppeteer
true
true
offline
true
landscape format headerTemplate footerTemplate displayHeaderFooter
false
A4
<div style="width: 100%; margin: 0 10mm; text-align: center; font-size: 8px;"><span class="title"></span></div>
<div style="width: 100%; display: inline-flex; justify-content: space-between; margin: 0 10mm; font-size: 8px;"><span class="author">Michael Schaufelberger</span><span><span class="pageNumber"></span></span></div>
true

@import "styles.less"

SWEN2

[TOC]

Einführung Software Engineering

SWEBOK - Software Engineering Body of Knowledge

Beschreibt generell akzeptiertes Wissen. Fasst in 15 Kapitel Basiskonzepte zusammen und enthält Referenzlisten zu mehr Quellen.

  • Chapter 1: Software Requirements
  • Chapter 2: Software Design
  • Chapter 3: Software Construction
  • Chapter 4: Software Testing
  • Chapter 5: Software Maintenance
  • Chapter 6: Software Configuration Management
  • Chapter 7: Software Engineering Management
  • Chapter 8: Software Engineering Process
  • Chapter 9: Software Engineering Models and Methods
  • Chapter 10: Software Quality
  • Chapter 11: Software Engineering Professional Practice
  • Chapter 12: Software Engineering Economics
  • Chapter 13: Computing Foundations
  • Chapter 14: Mathematical Foundations
  • Chapter 15: Engineering Foundations

Plangetriebene Methoden

  • Vorteile
    • Ziel vor Augen
    • Lange Planung, man weiss was man möchte nach langer Planung?
    • Artefakte werden erstellt
    • Kann auch iterativ gemacht werden (UP)
    • Klare Prozesse
  • Nachteile
    • Sensibel bzgl. ändernder Requirements
    • Viele Prozesse und Artefakte
    • Man kann nicht wieder einfach so zurück

Problem: Fehlerrate zu hoch

  • Obwohl klare, durchgedachte Methoden
  • Neue Technologie lässt Methoden alt aussehen
  • Gründe
    • Methodik falsch
      • Poorly scoped
      • Falsche Leute / Services genutzt
      • Requirements unbrauchbar
      • Loss of executive sponsorships
    • Lösung failt
      • Tech issues
      • Buggy software

Featurenutzung Oft/immer genutzte Features: nur 20% Selten oder nie: Fast 2/3

Grundidee zur Lösung

  • Mehr Planung
  • Mehr Requirement Engineering
  • Scoping festschreiben
  • etc.

$\Rightarrow$ failt immernoch

No Silver Bullet

Werwölfe

Agile Manifesto

Entstand aus verschiedenen Ideen wie:

  • Extreme Programming
  • Scrum
  • DSDM
  • Adaptives SD
  • etc.

Werte

Individuen und Interaktion > Prozesse und Tools Funktionierende Software > Dokumentation Zusammenarbeit mit dem Kunden > Vertragsverhandlung Reagieren auf Veränderung > Befolgen eines Plans

Wichtig: die rechts nicht unwichtig... die links sind wichtiger

Autoren

Kent Beck author eXtreme Programming Ron Jeffries co-author eXtreme Programming Ward Cunningham co-author eXtreme Programming Ken Schwaber Agile Software Development with Scrum Mike Beedle Agile Software Development with Scrum Martin Fowler TODO!

Prinzipien

Deliver Working Software Frequently Regelmässige Lieferung funktionierender Software +: Frühes Feedback, Kunden sehen dass gearbeitet wird, schnelle Fehlerbehebung möglich Je öfters desto besser?

Face-to-Face Conversations Am besten kann man Absicht und Tonfall face-to-face rüberbringen. Kommunikation ist sehr wichtig

Nachhaltige Prozesse in konstantem Takt Wenn man Software oft releasen möchte, müssen auch Prozesse nachhaltig und taktgetreu sein.

Simplicity die Kunst, Arbeit, die nicht getan werden muss, zu maximieren Beispiel: Keinen Code schreiben der nicht nötig ist

eXtreme Programming

Kent Beck, Ron Jeffries, Ward Cunningham

Sammlung von Prinzipien ind Praktiken, um mit Risiken umzugehen.

4 Variablen

  • Zeit
  • Ressourcen
  • Qualität
  • Scope

Idee: 3 können externe bestimmen, 1 das Dev-Team

Cost of Change Traditionell: Immer höhere Kosten je länger es geht XP: Anfänglich bisschen höher, dann mehr oder weniger konstant

XP: Core Values

Kommunikation Alle sind Teil des Teams, direkte Kommunikation Wir arbeiten gemeinsam Gemeinsam beste Lösung

Einfachheit (Simplicity) Geschaffenen Wert im Verhältnis zum Aufwand maximieren Tun, was notwendig kleine, einfache Schritte, Fehler sofort lösen vernünftige Kosten

Feedback Commitment ernst nehmen indem lauffähige Software Software früh wie möglich zeigen Auf Feedback reagieren und adaptieren

Mut Wahrheit über Fortschritt aussprechen Keine Ausreden Dokumentieren $\Rightarrow$ Für Erfolg planen Niemals jemand allein arbeiten (bzw. verantwortlich) Sich immer an Veränderungen anpassen

Respekt Alle haben Respekt vor allen Alle bringen sich ein

XP: Prinzipien

Rapid feedback Assume simplicity Incremental change Embrace change Quality work

Praktiken

The Planning Game Balance zwischen business und technischen Betrachtungen business: Scope, Priorität, Release-Komposition, Release Dates tech: schätzungen, konsequenzen, prozesse, detailplan

Small releases Jedes Release so klein wie möglich mit den wertvollsten requirements Release muss sinn machen

Metaphor Alle haben gemeinsames Vokabular und Verständnis

Simple design

  • Tests laufen
  • keine duplizierte Logik
  • möglichst wenig Klassen und Methoden
  • "Programmiere hinein, wenn du es brauchst"
  • Emergent, wachsendes Design $\rightarrow$ Refactoring

Unit testing Automatisiert Tests sind Teil vom System Tests akzeptieren veränderung Listen $\rightarrow$ test $\rightarrow$ code $\rightarrow$ design

Refactoring Code verbessern, damit zukünftige Features einfacher sind zu implementieren

Pair programming 2 Rollen: Keyboard $\rightarrow$ Aktuelle Methode; other $\rightarrow$ denkt an Kontext Paare oft wechseln

Collective code ownership Jeder ist Verantwortlich Jeder sollte dazu beitragen, wann immer Wert des Codes gesteigert werden kann

Continuous integration Code ist ständig getestet und wird integriert Automatischer Build Automatische Tests

40 hours week Work life balance ausruhen, etc.

On-site customer REAL Customer möglichst nahe Schnell fragen beantworten

Coding standards

Test-Driven Programming (TDD) Test first, all red $\rightarrow$ green

Slack Tasks mit tiefer prio hinzufügen

Spike Fokussierter Research Task

Incremental Design Immer wieder chli refactore

Self-organized team

User Stories / Estimation and Planning

User Story Kurze, prägnante Beschreibung von Funktionalität. Rolle, Ziel, Nutzen

User Role Rolle eines Benutzers (Person kann mehrere Rollen haben)

Epic Grosse Story $\Rightarrow$ aufbrechen

Theme Sammlung von Stories

INVEST Independent, Negotiable, Valuable to users/customers, Estimatable, Small, Testable

Story Points Repräsentiert übergeordnete Grösse der Story: Aufwand, Komplexität und Risiko Relative Messung der Komplexität

Velocity Rate of progress, Summe story points

Planning Poker

Conditions of Satisfactions "As a user, I want to be able to cancel a reservation" Diskussion mit PO: $\rightarrow$ refund for cancellation > 24h, partial refund < 24h, cancellation code emailed

Levels of planning Agiles Team plant für Tag, Iteration, Release

Product Backlog Liste der Stories bzw. Requirements, Priorisiert durch PO

Priorisierung (der User Stories) Durch PO

Techniques for Estimating Es wird nicht besser, je länger man versucht zu schätzen @import "images/acc_to_effort.png" {.max} Planning Poker

Relative Schätzung

Planning for value

Welche Features sollen priorisiert werden? Wie viel Aufwand/Erlös gibt es? Risiko?, etc..

Financial Value Wie viel Geld wird es geben? ROI, Time value of money

Cost Wie viel Kostet ein Feature? Kosten können sich mit der Zeit verändern Kurze Konvertierung: Story Points $\leftrightarrow$ Kosten

New Knowledge Was wird wie entwickelt? Unsicherheiten reduzieren

Risiken Alle Projekte bringen unmengen an Risiken mit sich @import "images/risk_diagram.png" {.max}

Kano Model Customer Satisfaction Green: Price premium, machen das Produkt aus Yellow: Lineare Features (je mehr, desto besser) Red: Must have, sind sust alli hässig @import "images/kano.png" {.max} Mit der Zeit: Innovationen $\rightarrow$ basic needs

SCRUM

= Agiler Prozess, Lieferung höchst möglichen Wertbeitrag in kürzester Zeit Funktionierend Software oft und wiederholt inspizieren Management setzt Prioritäten, Team setzt selbstorganisiert um Jede Iteration: reale, funktionierende Software

Values

Commitment Courage Focus Openness Respect

Charakteristiken

Self-organising Teams Sprints Requirements im product backlog Keine spezifischen Engineering Praktiken Generelle Regeln, um agil zu arbeiten Agil

Scrum Rollen

Product owner Definiert features Entscheidet über release date und Inhalt Verantwortlich für ROI Priorisiert features Akzeptiert oder weist Resultate zurück

Scrum Master Verantwortlich, dass Scrum Werte und Regeln befolgt werden Entfernt Hindernisse Sorgt für reibungslosen Ablauf Ermöglicht zusammenarbeit Schirmt das Team gegen äussere Einflüsse

Team 5-9 Personen Cross-Functional Vollzeit Selbstorganisierend

Zeremonien

Sprint Planung Priorisierung: Analyse des backlogs, Sprint goal setzen Sprint Planung: Wie Goal erreichen? Sprint backlog erstellen, Sprint backlog schätzen Tasks werden in h geschätzt, bzw. Stories aufgebrochen

Sprint Review Alle sollen teilnehmen keine Demo, sondern working session mit Feedback PO: Was wurde alles (nicht) gemacht? Product backlog state, Release Ausblick Dev Team: Konkrete "Demo", Was passierte im Sprint?, Welche Probleme waren da?

Sprint Retrospektive Nach jedem Sprint Review was ok? was verbessern? was nächstes commitment? alle nehmen Teil (auch Kunden) DoD erweitern, Was kann man am Prozess verbessern?

  1. Set the Stage (Vorbereitung & Rahmenbedingungen, Erwartungen klären)
    • z.B. Check-In: Offene Frage für jeden, "Was beschäftigt dich?" oder "Was ist Ziel dieser Retro?" $\rightarrow$ 1 Satz Antwort
  2. Gather Data
    • z.B. Timeline zeichnen, Personen platzieren Ereignisse auf Zeitachse und reden kurz darüber
    • z.B. Team Radar: Team wählt 4-8 Erfolgsfaktoren, Radar Diagramm und diskutieren
  3. Generate Insights (Warum sind Ereignisse so?)
    • z.B. 5 ways: Pro Problem 5 mal warum fragen, timebox
  4. Decide what to do (Sich auf 1-2 wichtigste Massnahmen einigen)
    • z.B. More Less Equal: 3 Spalten
  5. Close (Retro der Retro, Vorschläge/Verbesserungen)
    • z.B. Noten vergeben

Daily Scrum 15 Minuten Stand-up Keine Problemlösungen, sondern "können alle arbeiten?" Alle eingeladen, aber nur Devs + SM dürfen sprechen Soll unnötige Meetings vermeiden

Artifacts

Sprint Backlog Personen wählen Arbeit selbst aus, zuweisung findet nie statt! Tägliche Schätzung verbleibenden Aufwands Teammitglieder dürfen anpassen Falls Arbeit unklar $\rightarrow$ Grösseres Item machen

= Tabelle: User Story, Task, Tag und wieviele Stunden

Burndown Chart Wie vill to-dos hesch no?

Weitere Scrum Begriffe

Sprint Time-boxed, Produkt wird währenddessen designed, codiert und getestet

Sprint Goal Kruze Formulierung

Chicken and Pigs Pigs: People who are committed, Chickens: People who can watch

Definition of Done Definition: Wann ist eine Story erledigt? Z.B.: Tests pass (min. 85%), Code wurde reviewed, Coding Standards eingehalten, Dokumentation geschrieben

Increment Was wurde erreicht bis jetzt? Muss "Done" sein

Build automation

Manuelle Arbeiten sind fehleranfällig Sich wiederholende Arbeiten sind langweilig Automation ist Dokumentation

Ziele: Produktqualität erhöhen Time to Market reduzieren Risiken minimieren

Build Automation

Individuelle Komponenten builden und Unit Tests laufen lassen Wird vom Dev ausgeführt

Requirements Automatisch Wiederholbar und Konsistent Inkrementell Plattformunabhängig Reibungslose Integration (IDE, CI System)

Schritte Kompilieren Dokumentieren Unit Tests Pakete machen Cleanup

Continuous Integration

Automatisch builden, testen und integrieren + Integration Tests Run by CI Server

Integration Module werden integriert Sie:

  • kompilieren
  • bestehen Tests
  • sind ausführbar
  • sind deploybar

Ergebnis: Regelmässig gibt es ausführbare Releases

Test coverage, artefakte, versionierung, etc.

Continuous Delivery

Releases erstellen Auf Staging Envs deployen Akzeptanztests laufen lassen (Stress tests, Compliance tests) User Akzeptanztests

Sichtbarkeit, Feedback, Kontinuierlich

Continuous Deployment

Automatisches Deployment auf Prod sobald Akzeptanztests OK Kein "Release Day"

ORM/JPA

Domain Model

Entitäten und Beziehungen aus Domänensicht

ORM

Object-Relational Model, Objekte und deren Relationen mappen Kreiert virtuelle Objekt Datenbank

Achtung: Sehr grosse Frameworks, weniger Freiheit

Problematische Abfrage: Kombination mit Entitäten (sprich, Vorname Nachname Produkt) gibt es so nicht, immer nur ganze Objekte

O/R Mismatch

Typen Systeme: NULL, Datum/Zeit Beziehungen: Richtung, Mehrfachbeziehungen Vererbung Identität: Objekte haben implizit, Relationen explizit (PK) Transaktionen

OO: Navigation entlang Referenzen, DB: Beziehungen nicht explizit

POJO

Plain Old Java Objects Ohne Abhängigkeiten / Konventionen, Freiheit im OO-Design Keine vorgefertigte Vererbung oder Frameworkabhängigkeit

Location Transparency

Alle Daten immer Verfügbar Für die Applikation keinen unterschied, ob Daten auf DB oder lokal Frage: Wie viele Daten sollen gecached werden? Lazy-Loading / Eager-Loading

JPA

Java Persistence API "Standard" App $\rightarrow$ JPA $\rightarrow$ JDBC $\rightarrow$ SQL

@Entity auf Klasse @Id auf Id Property

Entity Mapping Access Typ

@Entity
@Table(name = "EMP")
public class Employee {
  @Id
  @Column(name = "EMP_ID")
  ...
}

SOLID

Single Responsibiility Principle

Jedes Modul selbst verantwortlich

Funktionale Kohäsion Nur 1 Variable verändern

Sequentielle Kohäsion 2 Variablen werden verändert

Informationsfluss Kohäsion 1 Input verändert mehrere Variablen

Open Closed Principle

Offen für Erweiterung, geschlossen für Änderung

Mach so vererbigsstuff, zum s erwiitere

Liskov Substitution Principle

Subtypen einer bestimmten Klasse müssen sich ähnlich verhalten Vorbedingungen sollten sich nicht verschärfen Nachbedingungen (Typ, min-max) nicht einschränken Invarianten der Oberklasse müssen immer geleten

Interface Segregation Principle

Keine Abhängigkeiten von Schnittstellen, die man selbst nicht verwendet Sonst Schnittstellen auftrennen

Dependency Inversion Principle

Cynefin Framework

Ku nev in Wie soll ich an das Problem herangehen? In welche Domäne?

Exaptation

Zweckentfremdung Funktionalität von Etwas jetzt für etwas brauchen für das es nicht gedacht ist.

Systems

Ordered Beziehung zwischen Ursache und Wirkung ist da, wiederholbar, voraussehbar Komplex Beziehung zwischen Ursache und Wirkung ist da, aber nicht voraussehbar Chaotisch Beziehung zwischen Ursache und Wirkung unklar (was ist Problem)?

Domains

Simple Obvious Actions Sense $\rightarrow$ Kategorisieren $\rightarrow$ Antwort $\Rightarrow$ Best practices

Kompliziert Sense $\rightarrow$ Analysieren $\rightarrow$ Antwort $\Rightarrow$ Good practices Z.B. Auto kaputt, verschiedene Lösungen, keine Lösung in jedem Fall die beste

Komplex Wir wissen nicht, wie sich Aktion verhalten würde. Probe (Versuchen) $\rightarrow$ Sense (Experiment war positiv/negativ?) $\rightarrow$ Antworten (dämpfen/verstärken) $\Rightarrow$ Emergent practises (Aktivität gibt Lösung)

Chaotisch Einzige falsche Entscheidung, keine Entscheidung Keine Zeit um lange zu analysieren und experimentieren Handeln $\rightarrow$ Sense $\rightarrow$ Antworten $\Rightarrow$ Neue Praktiken

Disorder Wenn man nicht weiss, in welcher Domäne das Problem ist.

Webservices / REST

Verteilte Systeme

Request / Response Call-orientiert (meistens sync) Operationen haben input und output. Fokus: auf Input / Output und der Opration. Kein Fokus: wie man zum Output kommt.

Message passing Datenorientiert (async) Nachrichten werden konstruiert und dann versendet Fokus: auf Nachricht in korrektes Format, wie man (auf welchem Medium) man die Nachricht versendet, Wohin man die Nachricht versendet Kein Fokus: Was nach dem dispatch passiert, Ob eine Antwort kommt

Architekturstile

3 Request / Response (call-based) systeme

Object-Oriented

Verantwortlichkeiten $\rightarrow$ Individuell wiederverwendbare und eigenständige Objekte, die Daten und Verhalten dazu beinhalten

Kommunikation mittels Objektinstanzen mit State, Verhalten und Identität implizit stateful state info ist serverside Pass-by-reference facilities TODO Jeder Zugriff braucht round-trip kommunikation Bulk-data-retrieval für weniger calls

Resource-Oriented

Fokus auf Aspekte und Architektur die auf Ressourcen beziehen

Retrieve resource instances: wie SQL SELECT oder HTTP GET Operationen für Lifecycle management (DELETE PUT PATCH) stateless, kein link zwischen aktuellem und vorherigem request Ressourcen identifiziert mit Adresse (z.B. URL) Master copy bleibt auf Server, Client erhält Kopie

Service-Oriented

Apps, die einen Dienst mittels Nachrichten und Verträgen verwenden

Nachrichten und Anfragen werden an Service gesendet Keine Operationen für service lifecycle management implizit stateless Skalierbar, da stateless Service-Endpunkt entscheidet, wie die Anfrage behandelt wird Service hat Schnittstellenbeschreibung, $\Rightarrow$ lose gekoppelter Vertrag zwischen Client und Server Shared, reusable services

Web Service

= service, der interoperable machine-to-machine Interaktionen über das Netzwerk erlaubt. Schnittstellenbeschreibung (WSDL) SOAP messages

Web Service Technology Stack

@import "images/find_publish_bind.png"

Publish Servicebeschreibung wird veröffentlicht, damit Requestor sie finden kann

Find Service Requestor holt die Servicebeschreibung direkt oder über Registry

Bind Der Service Requestor instanziert, mittels der Details in der Servicebeschreibung, die Interaktion mit dem Service Provider

Stack Bildli @import "images/stack_image.png"

Transport: Protokoll für Transport der Nachrichten

UUDI Universal Description Discovery and Integration Schema für Publizierung und finden von Web Services, Basis für directory service

WSDL Web Service Description Language Standard um zu beschreiben, was zwischen Providor und Requestor ausgetauscht wird

SOAP Simple Object Access Protocol Nachrichtenaustauschformat

SOAP

Envelope, optional Header, Mandatory Body

Header: wie soll Nachricht verarbeitet werden? Routing, Delivery, Authentication, etc. Body: Payload

<?xml version="1.0" encoding="UTF-8"?>
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope">
  <env:Header>
    <tx:Transaction-id xmlns:t="http://www.transaction.com/id" env:mustUnderstand="true">
512
    </tx:Transaction-id>
  </env:Header>
  <env:Body>
    <p:PurchaseOrder orderDate="2010-05-06" 
      xmlns:p="http://www.supply.com/order">
      <p:from>
        <p:accountNumber>239dsd</p:accountNumber>
      </p:from>
      <p:to>
        <p:accountNumber>23540234</p:accountNumber>
      </p:to>
      <p:products> … </p:products>
    </p:PurchaseOrder>
  </env:Body>
</env:Envelope>

2 Kommunikation und 2 Encoding styles: RPC oder Nachricht kodiert oder literal

Faults env:Fault mit Code, Reason, Detail

REST

ist kein Standard MIME-type

Architektur

Gute Architekten liefern gute Qualität

Systemeigenschaften

Qualität der Architektur hat Einfluss auf allgemeine Systemeigenschaften

Messbar zur Laufzeit eines Systems

Performance Reaktionszeit/Durchsatz, geforderte Antwortzeiten garantieren

Security Sicher vor unautorisiertem Zugriff und Zerstörung

Availability Muss zur Verfügung stehen

Usability Einsatzbar für geforderten Zweck

Robustness Stabil laufen, kein unterbruch des Dienstes

Nur indirekt Messbar

Scalability Skalierbar sein

Integrability Nahtlos in bestehende Umgebung einfügbar

Portability Muss verschiedene Plattformen unterstützen

Maintainability Definierte Wartungsschnittstellen haben und übersichtlich sein

Testability Als Ganzes und in Einzelkomponenten testbar. Hilfsmittel (Logs, Traces) stehen zur Verfügung.

Reusability Systemteile müssen sich für andere Systeme wieder verwenden lassen.

Architektur

= Organisierte Struktur eines Systems oder/und einer Komponente sowie deren Beziehungen/Schnittstellen und längerfristigen Prinzipien bzgl. Design und Evolution

Stuff

Software Architektur beschreibt eine Lösung die passt. (func. und non-func. Anforderungen, realisierbar, implementierbar) Prozess: Lösung designen Produkt: Modelle, Doku, Protypen

Software Architekt

Solution Architects sind verantwortlich dass funktionale und nicht-funktionale Anforderungen mit Budget, Zeit usw. eingehalten werden.

Enterprise Architekt sind verantwortlich, dass obige Lösungen in Enterprise Umgebung und Strategien hineinpassen. (koordiniert und standardisiert)

Moduleigenschaften

TODO Modularity (Modularität)

Portability (Portabilität)

Changeability (Formbarkeit)

Conceptual Integrity

Intellectual Control

Buildability

Kopplung / Kohäsion Functional Cohesion, Logik

Schwierigkeiten des Software Designs

Komplexität Software ist das Komplexeste was durch Menschen erschaffen wurde. Speziell kann durch Abstraktion in ein einfacheres Modell keine Eigenschaften weggelassen werden.

Konformität Schnittstellen zu anderen Systemen variieren im Masse, wie die Komplexität der Umsysteme variiert.

Formbarkeit (Changeability) Software wird immer Verändert, kann auch einfach geändert werden $\Rightarrow$ gibt viele Änderungen

Unsichtbarkeit Software ist nicht direkt visualisierbar. Verlangt verschiedene Schichten.

Architekturstile

= Leitlinien für die Gestaltung der Architektur Modularten Funktionen, abstrakte Datentypen oder Prozesse Arten von Kooperation zw. Modulen direkt/indirekter Aufruf? Datenfluss Benutzung Architekturmuster Phys. schicht: Verteilungsmuster, Pipes & Filters, Muster des Ablaufs Orientierung an Architekturmetapher Virtuelle Maschinen, Pluginsystem, Organisationshierarchie

Beispiele

Kette Daten gehen durch Verschiedene Phasen (zeitlich) aneinander

Schichten (logisch) Obere Schicht nutzt untere Schicht (Schnittstellen)

Interpreter JVM, C#

Verteilungsmuster

Thin-Client vs. Fat-Client client-server

@import "images/architektur.png"

You can’t perform that action at this time.