Aufwandsabschätzung und Projektplanung · Function Point Verfahren Vorgehen im Überblick...

Dr. Ina SchaeferSoftware Systems Engineering

Technische Universität Braunschweig

(mit Folien von Dr. Gerhard Pews)

Aufwandsabschätzung und ProjektplanungSoftware Engineering 1

WS 2010/2011

Dr. Ina Schaefer Software Engineering 1 Seite 6

Übersicht

• Sätzung• Allgemeine Grundlagen• Function Point Verfahren• Expertenschätzung (Delphi-Verfahren)• CoCoMo Verfahren

• Projektplanung• Inhalte der Planung• Planungstechniken


Schätzungen


Gewünschter Zeitpunkt der Schätzung

Test &Integration

FachlicheKonzeption

TechnischeKonzeption Realisierung

Umfang der Funktionalität bekanntFachliche Funktionen, MaskenUmsetzung bekannt


Tatsächlicher Zeitpunkt der Schätzung

Test &Integration

FachlicheKonzeption

TechnischeKonzeption Realisierung

Nur Anforderungen aus Auftrag sind bekannt

Schätzungen sind „unfair“• Finden zu einem sehr frühen Zeitpunkt statt.• Man weiß dann wenig über die Aufgabe.Aber:• Auf die Zahlen wird man später festgenagelt


Top-Down vs. Bottom-Up Schätzung

Top-down• Fragestellung: Wenn ich einen

festen Kostenrahmen habe, wie viel dürfen die einzelnen Arbeitspakete dann kosten?

• Vom fixierten Aufwand zu den Arbeitspaketen• Projekt so aussteuern,

dass es im Kostenrahmen bleibt

• Aufgaben werden nur so „gut“ erledigt, wie Geld da ist

• Beispiel: Validierung eines Kostenrahmens

Bottom-up• Fragestellung: Wenn ich das

alles machen will, wie viel kostet es dann?

• Von den Arbeitspaketen zur Aufwandszahl• Schätzung der einzelnen

Arbeitspakete• Summe ergibt

Gesamtaufwand• Beispiel: Abschätzung der

Gesamtkosten als Arbeitsgrundlage für weitere Planung


Folgen von Fehlschätzungen

• Schätzzahl liegt höher als die tatsächlich zu leistenden Aufwände.

• Im nachhinein kaum festzustellen. Jedes Projekt schöpft den Kostenrahmen voll aus.

Schätzung Beschreibung

zu hoch

zu niedrig• Geld reicht nicht, Projekt kann im Budget

nicht durchgeführt werden

• Konsequenz: Schätzungen sind gern zu hoch• Gefahr: Business Case rechnet sich nicht, bzw. Projekt wird an Mitbewerber

verloren.


Schätzung als Planungsgrundlage

Wenn Schätzungen so fehlerbehaftet und schwierig ist, warum schätzt man dann überhaupt?

Top-down• Auch eine „falsche“ Schätzung ist

besser als ein kompletter Blindflug.• Eine Schätzung ist die Grundlage

der Planung.• Man merkt bei der Planausführung

frühzeitig, ob eine Schätzung falsch ist und kann dann nachsteuern

• Auch Schätzen ist ein Prozess: sobald erste Erfahrungen und ermittelte Aufwände im Projekt vorliegen, wird nachgeschätzt und die Schätzung korrigiert

• Die Schätzung wird im Laufe des Projekts immer genauer.


Einflussfaktoren für Schätzungen

Wichtigste Einflussfaktoren auf den AufwandUmzusetzende Fachlichkeit (funktional)

• Masken• Druckstücke• Batches• Berechnungen• zu berücksichtigende Fehlersituationen• Migrationen aus Altsystemen• Abhängigkeit von andern Systemen

Technologische Umsetzungnicht-funktionale Anforderungen

• Performance, Antwortzeitverhalten• Mengengerüste• Architektur• Systemplattform, Basis-Technologien

PM-Faktoren

• Team– Mitarbeiterqualifikation– Erfahrung– Eingespieltes Team

• Projektorganisation• Projetvorgehen, Methodik• Unterstützung durch Tools

Sonstige Faktoren

• Auftraggeber• Aufwände steigen mit

Größe der Aufgabe


Vorgehen bei einer Schätzung

VorbereitenMessen,VergleichenLernen

Schätzen Nachschätzen

Hinweise• Eine gute Vorbereitung ist elementar für die Schätzung• Komplettieren und Strukturieren der Schätzgrundlage

(osintots – oh shit, I never thought of this)• Sammeln aller Faktoren• Nachschätzen und aus Projekterfahrungen lernen ist ein stetiger Kreislauf

während des Projekts


Function Point Verfahren

Vorgehen im Überblick

Bewertung der Kom-plexität der Fachlichkeit (Datenfluss)

Bewertung sonstiger Einflussfaktoren

Ermittlung der Gesamtkomplexität,Berechnung des Aufwands

Hinweise• Function Point Schätzungen werden in verschiedenen Firmen

unterschiedlich gelebt.• Alle arbeiten nach dem gleichen Prinzip, Unterschiede gibt es in:

• Kriterien, nach denen die Komplexität der Fachlichkeit gemessen wird• Betrachtete sonstige Einflussfaktoren• Unternehmensspezifische Gewichtung

• Im Folgenden: ursprüngliches Verfahren


Bewertung der Fachlichkeit Details zum ersten Schritt




Inhalte• Strukturierte Erfassung der Fachlichkeit:

• Eingabedaten (Bildschirm, Batch, etc.)• Ausgabedaten (Bildschirm, Druck, Interface, etc.)• Anfragen (Suchanfragen)• Eigene Datenbestände (lesen & schreiben)• Extern referenzierte Datenbestände (nur lesen)

• Zu jedem Punkt Bewertung: geringe/mittlere/hohe Komplexität• Ableiten der FP aus Tabelle mit FP-Werten für die jeweilige Komplexität


Bewertung durch Function Points

Beispiel für eine Function Point Bewertung

Schätzposten Komplexität FP… … …EingabedatenKunde gering 3Bankverbindung mittel 4… … …AnfragenKundensuche mittel 10… … …Summe 458

BewertungenEingabedatengering 3mittel 4hoch 6Eigene Datenbeständegering 7mittel 10hoch 15……

Schätztabelle FP-Werte für jeweilige

Komplexitäten


Bewertung der Einflussfaktoren Details zum zweiten Schritt




Inhalte• Bewertung sonstiger Einflussfaktoren:

• Verflechtung mit anderen Systemen• Dezentrale Verarbeitung und Datenhaltung• Transaktionsrate und Antwortzeitverhalten• Verarbeitungskomplexität (Rechenoperationen, Ausnahmebehandlungen, Logik, …=)

• Wiederverwendbarkeit• Migrationen• Benutzerfreundlichkeit

Auch daraus wird wieder ein numerischer Faktor abgeleitet.


Berechung des Gesamtaufwands Details zum dritten Schritt




Inhalte• Gesamtkomplexität in „Total Function Points“ (TFP) durch Verrechnung (i. d.

R. Multiplikation) der Faktoren• Errechnung des Aufwands z. T. mit Zwischenschritt über die zu erstellenden

Codezeilen (Lines of Code – LOC) für eine jeweilige Programmiersprache.

Personenmonate

TFP/LOC


Bewertung des FP-Verfahrens

Bewertung• Systematische Herangehensweise• In Function Points wird die fachliche Komplexität der Aufgabe

gemessen, nicht die Komplexität der technischen Lösung.• Lebt von den jeweiligen Erfahrungswerten des Unternehmens

und der Personen.• Insbesondere in den zweiten Schritt gehen

unternehmensspezifische Erfahrungen ein, die schwer zu begründen und in anderen Kontexten zu reproduzieren sind.

• Wird in unterschiedlichen Unternehmen auch unterschiedlich gehandhabt.

• Nach einiger Zeit der Anwendung erzielt man reproduzierbare Ergebnisse in der Function Point Messung.


Expertenschätzung

Hinweise zum Vorgehen• Aufwände und Umsetzung werden explizit geschätzt, nicht

über Lines of Code oder Faktoren.• Bei einer Expertenschätzung sind in der Regel mindestens

zwei Experten beteiligt, um Schätzergebnisse vergleichen zu können.

• Generelle Unterscheidung in der Vorgehensweise:• Standard-Delphi-Verfahren: Experten schätzen

komplett unabhängig• Breitband-Delphi-Verfahren: Experten diskutieren

Zwischenergebnisse.


Expertenschätzung nach Delphi-Verfahren

Liste mit jedem Experten durchsprechen, erläutern

Erstellen Schätzpostenliste

Experte schätzt jeden Schätzposten, Rückfrage

möglich

Prüfung Ergebnisse Neue Liste mit unklaren Posten, neu kommentiert

z. B. falls unplausibel, Abweichungen

zwischen ExpertenErgebnis = Durchschnittwerte der Einzel-Schätzungen

Falls Breitband-Verfahren:Experten-Diskussion


Schätzpostenliste

Schätzposten• Benötigt: vollständige funktionale Beschreibung des Systems• Beispiele für Schätzposten

• Dialog• Druckstück• Funktionen, Services• Entitäten & Persistenz der Entitäten• Querschnittliche Funktionen (Drucken, Fehlerbehandlung, etc.)

• Granularität eines Schätzpostens (Daumenregeln)• nicht kleiner als 1 Tag, sonst addieren sich Nichtigkeiten zu

großen Aufwänden• nicht größer als 20 Tage, sonst wird die Schätzung zu

ungenau• guter Bereich: 5 – 10 Tage


Schätzgröße in der Expertenschätzung

Hinweise zur Schätzgröße „BT“Schätzgröße• BT = Bearbeitungstag, auch PT = Personentag oder MT = Manntag• Die Arbeit, die eine Person an einem Tag erledigen kann• Die Arbeit ist brutto gerechnet, d. h. die wirkliche Zeit, die man

benötigt, d. h. Entwicklung inklusive:• Entwicklertest• Code-Dokumentation• Nacharbeiten• Reisekostenabrechnung, Stundenkontierung in SAP, …• Kaffee trinken, Zigarrettenpause• Teilnahme an Meetings• Anderen Kollegen helfen• Rechner ist abgestürzt, Netzwerk ist weg,…


Vorgehen bei einer vereinfachten Schätzung

• Schätzung der reinen Realisierungs-Aufwände

Schritt Beschreibung

Schätzung der Realisierung

Hochrechnung auf alle Phasen

• Hochrechnung von • Fachlicher Konzeption• Technischer Konzeption• Test & Integration

aus den Rea-Werten

Zuschläge • Addieren von Zuschlägen, z. B. für

Projektkoordination, Gewährleistung, Qualitätssicherung, etc.


Schätzung der Realisierung

Vorgehen bei der Schätzung der Realisierung• Geschätzt wird die reine Brutto-Realisierung. Annahmen dabei:

• Alle fachlichen Fragen sind geklärt• Algorithmen sind klar• Technologie ist klar• Mitarbeiter ist geschult• „Normale“ Projektmitarbeiter, keine Technologie-Experten (wie

diejenigen, die schätzen)• Eigentlich ist eine detaillierte Schätzung erst nach Abschluss der

fachlichen Konzeption möglich. Zu diesem Zeitpunkt kennt man die Aufwände der fachlichen Konzeption schon bzw. kann sie abschätzen. Diese Aufwände kann man zur Plausibilisierung mit den geschätzten Realisierungsaufwänden vergleichen.

Schätzung


Hochrechnung von Realisierungsaufwänden

Beispiel: Erfahrungswerte der Firma sd&m

fachl. Konzept

30%

tech.Konzept

15%

Reali-sierung

40%

Test und Integr.15%

Nutzung der Werte• Hochrechnung: Nach

diesen Erfahrungswerten ist der Gesamtaufwand 2,5x so hoch wie der Realisierungsaufwand

• Plausibilisierung: Nach Abschluss des fachlichen Konzepts sollten 30% des Projektbudgets verbraucht sein.


Aufschläge bei der Realisierungsschätzung

Erfahrungswerte für Zuschläge bei sd&mZuschlag ErfahrungswerteTechnik - Software-Entwicklungsumgebung Aufbau geplant, Pflege MA über Zeit - Technische Infrastruktur 5-10%, oder MA über Zeit - Konfigurationsmanagement Aufbau geplant, Pflege MA über ZeitDatenadministration (optional) 5-10%Abnahmesupport MA über ZeitChefdesign (CD) 5-10%, oder MA über ZeitQualitätssicherung (QS) Aktivitäten oder 10-20%Einarbeitung 2-4 Wochen bei ProjekteinstiegTeam-Meetings MA über ZeitPM/PL 10-25%, 1 PL pro ca. 7 MA über ZeitPuffer bzw. Risikozuschlag 10-40%Gewährleistung 3-12%Sonstiges ProjektspezifischReisezeit MA über ZeitReisespesen ableitbar aus ReisezeitZugekaufte Leistungen tatsächliche Kosten

Bei Großprojekten kann die Realisierung nach Berechnung aller Zuschläge nur noch 16% des Gesamtaufwands betragen!


Repräsentanten und Stützpunkte schätzen

Tipps zur Schätzung großer Schätzpostenlisten• Problem: Was tun, wenn die Schätzpostenliste sehr groß ist, z. B.

wenn das System mehrere hundert Dialoge umfasst? Der Aufwand zur Schätzung wird dann sehr groß

Problem

• Klassen: Einfache Dialoge, Mittelschwere Dialoge, Schwierige Dialoge

• Extrem schwierige Dialoge trotzdem individuell schätzen• Schätzen von einem Repräsentanten jeder Klasse

Lösung 1: Beispiel mit Bildung von Klassen.

• Fünf Dialoge wählen, die das ganze Spektrum der Komplexität abdecken.

• Andere Dialoge werden nicht geschätzt, sondern mit den Stützpunkten verglichen. Aufwandszahlen der Stützpunkte werden übernommen und ggf. leicht angepasst.

Lösung 2: Beispiel mit Schätzung von Stützpunkten


Schätzunsicherheit

Vorgehen bei einer Min-Max-Schätzung• Schätzungen sind immer mit einer Schätzungenauigkeit und einem

Risiko behaftet.

Problem

• Idee: Experte schätzt minimalen und maximalen Aufwand für die Aufgabe.

• Wichtig: kein zu großes Delta zwischen Min und Max, guter Erfahrungswert ca.: 20%, in der Praxis aber leider oft höher.

• Die Planung wird am Minimalwert ausgerichtet, aber so mit Personen hinterlegt, dass die maximalen Aufwände in der Projektlaufzeit möglich zu erbringen sind.

• Weitere Möglichkeit zur Min-Max-Schätzung: Min, Max und Normalwert schätzen, dann rechen mit:(Min + Max + 4*Norm) / 6

Min-Max-Schätzung


CoCoMo Verfahren

• Schätzung der Projektgröße in LOC (Lines of Code) bzw. KDSI (Kilo Delivered Software Instructions), d. h. ohne Kommentare.

• Nach Verrechnung mit weiteren Kennzahlen wird der Gesamtaufwand E berechnet (MMDEV Entwicklungsaufwand in PM) und die Projektlaufzeit (TDEV)

Idee

MMDEV = a * KDSIb * m(X)Formel

Entwickelt von Barry Boehm


Projektklasse Einfluss der Projektklasse auf die Aufwandsschätzung

• einfache SW-Projekte• eingespieltes Team,

bekannte Umgebung, wenig Neuland

• Größe <50 KDSI• Faktor b = 1,05

Organic Mode• mittelschwere

Projekte• Größe <300 KDSI• Faktor b = 1,12

Semi-detached Mode• schwierige Projekte• starker Kosten-

Termindruck, viel Neuland

• Größe: beliebig• Faktor b: 1,20

Embedded Mode

MMDEV = a * KDSIb * m(X)


Modellvarianten Einfluss der Modellvarianten auf die Schätzung

MMDEV = a * KDSIb * m(X)

• früh, zu Beginn eines Softwareprojekts

• ganzheitliche Betrachtung

• Ausgangspunkt für weitere Schätzungen

Basismodell• Berücksichtigung von

15 Einflussparametern• keine Differenzierung

zwischen Phasen

Zwischenmodell• Berücksichtigung von

15 Parametern• Abweichungen der

Aufwände aus den einzelnen Phasen berücksichtigt

Detailmodell


Weitere 15 Einflussfaktoren

RELY: geforderte Zuverlässigkeit der SoftwareDATA: Größe der DatenbasisCPLX: Komplexität des Produktes

Produkt

TIME: benötigte RechenzeitSTOR: Nutzung des verfügbaren

SpeicherplatzesVIRT: Änderungshäufigkeit der

SystembasisTURN: Bearbeitungszyklus

Computer

MODP: Verwendung moderner Entwicklungsmethoden

TOOL: Verwendung von ToolsSCED: Anforderungen an die

Entwicklungszeit

Projekt

ACAP: Analysefähigkeit der MitarbeiterAEXP: Erfahrung der Mitarbeiter im

ArbeitsgebietPCAP: Programmierfähigkeit der MitarbeiterVEXP: Erfahrung der Mitarbeiter in der

SystemumgebungLEXP: Erfahrung der Mitarbeiter in der

Programmiersprache

Personal

m(x) = m(x1) * m(x2) * … * m(x15)MMDEV = a * KDSIb * m(X)


Berechnung des Gesamtaufwands in CoCoMo


Bewertung von CoCoMo

• Die Schätzmethode CoCoMo bzw. CoCoMo II ist wenig verbreitet.

• Die Methode macht deutlich, welche Einflussfaktoren für die Schätzung relevant sind:• Zeitpunkt der Schätzung• Typ des Projekts• 15 detaillierte Einflussfaktoren

Bewertung


Tipps zur Schätzung

• Keine Angst vor großen Zahlen.• Schätzungen ergeben oft hohe Werte. Stehen Sie dazu.• Software ist teuer.• Eine ehrliche Schätzung ist die Grundlage für den

Projekterfolg.

Tipps


Projektplanung

• Ein Plan zeigt die Machbarkeit eines Vorhabens. Wenn man nicht einmal einen Plan erstellen kann, dann ist das Vorhaben nicht machbar.

• Ein Plan wird im Projekt ständig nachgeführt und aktualisiert. Dadurch kann der Projektleiter sein Projekt ins Ziel führen.

• Ein Plan ist die Grundlage, um ein Projekt zu steuern• Ohne Steuerung und Plan erkennt man erst zu

Projektende, ob sich der Projekterfolg einstellt• Mit Steuerung: Gefährdungen sind früh erkennbar, man

kann auf darauf reagieren Auch ein „falscher“ Plan ist besser als gar kein Plan. Die

Alternative wäre ein totaler Blindflug.

Planung


Planung als Prozess

„Damals haben wir mit viel Aufwand den Plan gemacht und nach zwei Wochen hat er schon nicht mehr gestimmt.“

Fallbeispiel: Zitat Projektleiter

• Eine Planung wird zu Projektbeginn erstellt und dann ständig verfeinert und angepasst.

• Eine Planung veraltet, sobald sie fertig ist. (Und manchmal auch schon, während sie erstellt wird)

• Eine Planung ist keine Vorhersage. Ein Projekt kann man nicht ausrechnen.

• Die Planung ist ein Werkzeug. Sie ist das wichtigste Arbeitswerkzeug des Projektleiters.

Grundideen einer Planung


Projektverlauf, Ausführen des Plans

Planung Controlling(Überwachen) Steuern

SOLL

Handlungs-bedarf Maß-

nahmen

Anpassen

IST Meilensteine,Restaufwands-schätzungen

SOLL

Projektplanung im Projektmanagement


• WER (Personen) macht• WANN (Termine)• WAS (Aufgaben)• ggf. WOMIT (Arbeitsmittel)?

FragestellungIm Projektplan finden sich die

Elemente:• Aufgabe,

Aktivität/Arbeitspaket (oft synonym verwendet)

• Ressourcen, insbesondere Personen

• Aufwände und Puffer• Termine

Inhalte

Inhalte der Planung


Planungstechniken

• Stellt besonders gut den zeitlichen Verlauf dar

• In der Praxis größte Verbreitung• Unterstützung durch Tools, oft

Default-Ansicht

Gantt-Diagramm

• Z. B.: MPM-Methode• Stellt besonders gut die

Abhängigkeiten zwischen Arbeitspaketen dar

Netzplan


Definition eines Netzplans

In Netzplänen werden dargestellt: Vorgänge, Ereignisse und deren Abhängigkeiten.

Netzplan

• DIN 69900 Definition Netzplan: Der Netzplan ist die graphische Darstellung von Ablaufstrukturen, welche die logische und zeitliche Aufeinanderfolge von Vorgängen veranschaulichen.

• Definition Vorgang: Ein Vorgang ist eine Zeit beanspruchende Tätigkeit, die über einen definierten Anfang und ein definiertes Ende verfügt.

• Definition Ereignis: Ein Ereignis signalisiert das Eintreten eines definierten und beschreibbaren Zustands im Projektablauf (z. B. Meilenstein).

Definitionen


Grundtypen von Netzplänen

Knoten: EreignissePfeile: VorgängeBeispiel: Critical Path Method (CPM)

Vorgangspfeil-Netzplan

Knoten: EreignissePfeile: AbhängigkeitenBeispiel: Program Evaluation and Review

Technique (PERT)

Ereignisknoten-Netzplan

Knoten VorgängePfeile: AbhängigkeitenBeispiel: Metra Potential Method (MPM)

Vorgangsknoten-Netzplan

Ereignis EreignisVorgang

Ereignis Ereignis

Vorgang Vorgang


FAT: Frühester Anfangstermin – Der Termin, zu dem der Vorgang frühestens beginnen kann.

FET: Frühester Endtermin – Der Termin, zu dem der Vorgang frühestens abgeschlossen werden kann, wenn man zum FAT begonnen hat. (FAT + Dauer)

Früher Start

SET: Spätester Endtermin – Der Termin, zu dem der Vorgang abgeschlossen sein muss.

SAT: Spätester Anfangstermin – Der Termin, zu dem man spätestens angefangen haben muss, wenn man zum SET fertig sein will. (SET-Dauer)

Später Start

0706050403020152515049

Ende

FAT FET

Start

5251 04 055049 06 07030201

SAT

EndeStart

SET

Termine eines Vorgangs


Pufferzeiten

Pufferzeit: Die Zeit, um die ein Vorgang verschoben werden kann.Freie Pufferzeit: Die Zeit, um die man einen Vorgang verschieben kann, ohne

dass der nachfolgende Vorgang verschoben werden muss.Gesamtpufferzeit: Die Zeit, um die man einen Vorgang verschieben kann,

ohne dass das Projektende verschoben werden muss.

Pufferzeiten

0652 0149 04 070302 055150

freie Pufferzeit

EndeStart

Zeitfenster

Pufferzeit


Der kritische Pfad

Kritischer Pfad: Der Pfad vom Projektstart bis zum Projektende, auf dem ausschließlich Vorgänge ohne Pufferzeit liegen.

Kritischer Vorgang: Vorgang auf dem kritischen Pfad.

Kritischer Pfad

Kritische Vorgänge erfordern besondere Aufmerksamkeit im Projektmanagement.Jeder Verzug auf dem kritischen Pfad führt dazu, dass der Zieltermin des Projekts

gefährdet ist.

06050403025049 07015251

krit. Vorgang

krit. Vorgang

krit. Vorgang

EndeStart

kritischer Pfad


Metra Potenzial Methode (MPM)

• Ausprägung der Netzplantechnik• Spezielle Notation der Vorgänge mit FAT, FET, SAT, SET und Puffer• Vorwärts- und Rückwärtsrechnung, um diese Daten für alle Vorgänge zu

bestimmen.• 1958 durch die Unternehmensgruppe Metra entwickelt

Grundideen MPM

Vorgangsname

Nr.

SAT Gesamt-puffer SET

FAT Dauer FET

Vorgangsname

Nr.


FAT Dauer FETVorgangsname

Nr.


FAT Dauer FET

Vorgangsname

Nr.


FAT Dauer FETVorgangsname

Nr.


FAT Dauer FET

Vorgangsname

Nr.


FAT Dauer FET


Gantt Diagramme

• Anderer Name: Balkendiagramm• Vorgänge werden durch Balken auf einem Kalender dargestellt.• Vorteil: intuitiv verständlich, man sieht sofort die Dauer der Vorgänge• Abhängigkeiten weniger übersichtlich dargestellt• Durch Henry L. Gantt (1861–1919) entwickelt

Grundideen Gantt


Zusammenfassung

• Was ist ein Projekt?

• Aufgaben im Projektmanagement

• Aufwandsabschätzung• Function Point Verfahren• Expertenschätzung (Delphi-Verfahren)• CoCoMo Verfahren

• Planungstechniken• Netzplantechnik• Gantt Charts

Aufwandsabschätzung und Projektplanung · Function Point Verfahren Vorgehen im Überblick...

Documents

Transcript of Aufwandsabschätzung und Projektplanung · Function Point Verfahren Vorgehen im Überblick...