Inhalt : Vorgänge um Projekte

Created by Stefan Bachert, last modified on 17. Jan 2013

These

Wir reden hier zwar über Projekte, sind uns aber nicht wirklich im Klaren welche Aspekte darunter zu verstehen sind. Insbesondere scheinen wir aneinander vorbei zu reden weil man unterschiedliche Projekttypen im Kopf hat. Daher will ich eine - wohl unvollständig bleibende - Liste von Aktivitäten angeben, die ein Projekt bestimmen.

Vorgang

Die nachfolgenden Schritte werden in der Regel sequentiell von oben nach unten ausgeführt. Iteration zu vorangehenden Schritten sind üblich.

1 Klären der Ziele

zum Beispiel

  • Listen der gewünschten Funktionalität
  • Listen der genehmigten Freiheitsgrade
  • Listen der sonstigen gewünschten Eigenschaften

Diese Liste könnte man auch Anforderungen oder Requirements nennen

2 Erstellung der Anweisungen / Vorschrift

um das Ziel zu erreichen. Manche würde dies auch (Bau-, Schalt-) Plan nennen. Aber ein Haus zu planen heiß nicht zwingend einen Bauplan zu erstellen. Daher meide ich das Wort Plan.

  • Anweisungen zur Funktionalität
  • Anweisungen zur Produzierbarkeit
  • Anweisungen zur Gesetzeskonformität
  • Anweisungen zur Umweltverträglichkeit

3 Prüfen der Anweisungen

  • Führen die Anweisungen wirklich zum Ziel?
  • Welche Nebeneffekte führen nicht spezifizierte Freiheitsgrade ein? Welche sind erwünscht, welche unerwünscht?
  • Müssen Kompromisse gemacht werden? "Abspec(k)en"
  • ggf. Simulation
  • ggf. Behördliche Genehmigungen einholen

4 Durchführen der Anweisungen

5 Prüfen des Ergebnisse

  • Anweisungen können physikalische Prozesse mit Streuungen sein. Streuungen, die das Ergebnis unbrauchbar machen können.
  • Testfälle können abweichendes Verhalten zeigen.

Projekttypen

Unterschiedliche Projekttypen haben unterschiedliche Schwerpunkte. Damit gelten auch andere Spielregeln, die je nach Ansatz/Methodik mehr oder weniger gut abgedeckt werden.

Die gelisteten Typen unterscheiden sich eher grobschlächtig. Innerhalb eines gelisteten Typ finden sich sicher weitere unterscheidbare Subtypen.

Softwareprojekt

Der Hauptaufwand liegt bei etwas (1) und viel (2).

Die Schritte (3) (4) (5) sind meist so effizient automatisiert, dass sie fast nicht mehr auffallen. z.B. (3) IDE (4) Compiler (5) UnitTest, Debugger

Softwareentwicklung ist meist Arbeiten am Prototyp

Straßenbauprojekt, Hausbauprojekt

 (1) (2) sind zwar wichtige Schritte, aber als Aufwand regelmäßig unter 10%.

(3) wird nicht immer gemacht

(4) ist eindeutig der Hauptaufwand

(5) führt bei Auffälligkeiten selten zur Wiederholung von (4), meist zu irgend einer Art des Flickens

Selten gibt es hier Prototypen. Die Anweisungen/Planung muss stimmen. Eventuell werden kritische Aspekte simuliert.

Hochkritische Projekte

Darunter könnte ich mir Projekte aus dem Medizinbereich vorstellen, oder die Kernkraftwerkssteuerung.

Da dürfte der Aufwand vor allem in den Prüfschritten (3) und (5) liegen und den Folgen der häufigeren Zurückweisungen an vorherige Schritte

Produktionstypen

Wohin gehört eigentlich das "Produkt" Lebensversicherung?

Kopieren

Kopieren eines Urstücks, das aus Schritt (4)+(5) entstand. Typisch für Software, Musik, Video (immaterielle Dinge).

Nach Vorschrift

Wiederholtes Anwenden der Anweisungen, also Schritt (4) + (5). Typisch für physikalische Gegenstände

 

Comments:

Stefan Bachert: Mir gefallen die Begriffe Anweisungen/Vorschriften nicht. Meinst du Requirements (oder siehst du die noch bei den Zielen)? Ansonsten sind mir die Begriffe zu eindeutig und passen nicht zu der typischerweise mit Projekten einhergehenden Unsicherheit über den Lösungsweg.
Posted by bschloss at 17. Jan 2013 20:33

Hallo Bernhard,

ja, ich sehe Requirements als Punkt unter (1). "Ziele"

Ich gebe Dir recht, dass Projekte ganz erheblich mit Unsicherheiten ausgestattet sind. Implizit kommt das bei (3) 2. Listenpunkt zum Ausdruck.

Ich sehe nur nicht, wie/dass man überraschend auftretende Unsicherheiten explizit vorsehen kann (Zwinkern) Wenn man offene Punkte sieht, dann werden die im Punkt (1) entschieden oder explizit als Freiheitsgrad freigegeben.

 

Der gefundene Lösungsweg ist doch ganz konkret durch Anweisungen bestimmt. Falls eine Lücke existiert würde im Falle eines Programmes, die Antwort auf eine Eingabe zufällig sein. Das würde man doch als Fehler betrachten und mit zusätzlichen/geänderten Anweisungen beheben.
Posted by stefanbachert at 17. Jan 2013 21:42