Nun zum dritten Teil dieser Veranstaltung zum Kapitel 3.
Und da geht es zum letzten Teil dessen,
was in der Überschrift des Themas noch fehlt, Prozesse.
Prozesse ihnen ganz stark mit Vorgehensmodellen zusammen.
Und wir haben hier die Frage 4, 5, 6,
die sich damit beschäftigen. Zunächst hat es was dazu,
wie wir das Ganze mit den Vorgehensmodellen verbinden wollen.
Bevor ich damit richtig einsteige, erst mal für diejenigen,
denen der Begriff Vorgehensmodell vielleicht nicht verwandelt ist,
so bekannt ist, Vorgehensmodelle sind die schematische Vorlage,
in welcher Folge von Aktivitäten
ein Entwicklungsprojekt,
ein Softwareprojekt abläuft
Man möchte im Unternehmen eine gewisse Einheitlichkeit erreichen, damit man
eine Reproduzierbarkeit hat, damit man Planbarkeit hat, Steuerbarkeit.
Das ist also der Punkt hier, Projekte besser steuerbar machen durch Einheitlichkeit.
Es geht also um ein Thema zum Projektmanagement,
Management to Manage heißt es ja, Steuern.
Und die Vorgehensmodelle sollen Gelegenheit geben, Softwareentwicklung zeitlich zu gliedern. Das heißt,
eine Folge von Tätigkeiten, die man ja auch gut dann planen kann,
dass man Teilaufgaben abgrenzt, um Rollen abzugrenzen, um Qualifikationsprofile zu etablieren,
um Schnittstellen zwischen Personen zu organisieren um Kommunikation zu organisieren.
Man möchte Projekte verfolgen in dem Projekt Fortschritt erfassen,
um zeitgerecht fertig zu werden, beziehungsweise das wäre wieder Projektmanagement,
irgendwie Steuern einzugreifen, wenn etwas länger dauert, als erwartet.
Man möchte Arbeitsteilung steuern, Arbeitsteilung zwischen Spezialisten,
die bestimmte Aufgaben übernehmen, Arbeitsteilung auch zwischen mehreren Teams,
die etwas nebeneinander liegendes machen, einfach weil die Aufgaben so groß sind.
Und man möchte durch frühzeitige Prüfungen frühzeitig Qualität erreichen.
All diese Ziele kann man sagen, ja wunderbar,
alle jedes Projekt muss diese Ziele erfüllen, aber Projekte unterscheiden sich sehr stark.
Ja, also jedes Projekt ist in gewisser Weise irgendwie einzigartig und man versucht,
das zu verallgemeinern und gemeinsame Regelungen zu finden, die innerhalb eines Unternehmens gelten.
Das ist erstmal das Wesen eines Vorgehensmodells. Und dieses Vorgehensmodell,
das ist etwas, was dann daherkommt, dass man etwas vorschreibt.
Zunächst deswegen so viel zur Vorrede, wozu das?
Ganz und jetzt, was ist ein Vorgehensmodell?
Ein Vorgehensmodell ist erstmal Beschreibung einer Organisation,
einer Organisation von Projekten, und zwar sowohl der Aufbauorganisation,
also aus welchen Teilen besteht es, welche Rollen wirken damit,
als auch Ablauf, in welcher Reihenfolge werden etwas gemacht.
Und es geht eben ganz klar, wenn es um Softwareentwicklung geht,
nicht nur um die Entwicklung, sondern auch um die Weiterentwicklung.
Also das, was wir als Wartung bezeichnen. Kern,
und das ist soweit geht, nur die Einführung hier,
enthält es Vorgaben, die für Projekte dann angepasst werden müssen.
Also wir hatten hier gerade gesagt, Projekte unterscheiden sich.
Das heißt, das Vorgehensmodell enthält nur die verallgemeinerten Regeln,
und zwar für Aktien
Aktivitäten, also das sind die Tätigkeiten in einem Prozess,
nicht nur die Reihenfolge, sondern auch was wird dort gemacht,
so ein Vorgehensmodell enthält Anleitungen,
enthält die einzelnen Schritte darin und durchaus so etwas wie ein phasenartiges Vorgehen.
Damit haben wir schon mal die Folge der Tätigkeiten.
Was da, womit das gemacht wird? Wie sieht eine Testfallbeschreibung aus?
Wie sieht eine Anforderungsbeschreibung aus? Wie sieht ein Architekturdokumentation aus?
Wie sieht ein Testprotokoll aus? All das sind irgendwelche Dokumente.
Hier gibt es diesen Begriff Artefakte. Wir können durchaus reinschreiben, das entspricht Dokumente, Arbeitsergebnisse. Das Begriff,
der Begriff Artefakt heißt ja, künstlich Gemachtes,
das ist so ein Sammelsuurium, ein bisschen in der Sprechweise,
im Slang, dieser Vorgehensmodellleute, die dann darüber,
das Begriff Artefakt benutzen, im V-Modell sogar, was wir denn haben,
gibt es auch noch den Namen Produkt im V-Modell für diese Artefakte,
für diese Dinge,
die der Mensch macht.
Diese Ergebnisse, für die können wir Projekte Der Inhalt ist
natürlich ganz klar von jedem Projekt abhängig. Aber was
tatsächlich verallgemeinert werden kann, ist so eine Art Vorlage.
Nämlich, wie sind die aufgebaut? Das heißt, was
haben die für eine Struktur? Was haben sie für Inhalte?
Wie sind diese Inhalte zu sehen? Wie wirken sie mit?
Und das ist tatsächlich etwas, was man als Projekt,
was dem Projekt dann hilfreich ist.
Soweit, also wir haben jetzt die Tätigkeiten,
wir haben die Ergebnisse, Input und Output.
Und jetzt müssen wir noch sagen, wer macht das?
In jedem Projekt sind es Personen, Personen mit,
die genauso einzigartig sind wie das Projekt, aber übergreifend kann man Rollen sprechen.
Also man kann an die Rolle des Projektmanagers definieren,
die Rolle des Konfigurationsmanagers, die Rolle des Softwarearchitekten,
die Rolle des Entwicklers, die Rolle des Testers und die Rolle desjenigen,
der die Anforderungen ermittelt oder die er dem Markt repräsentiert,
als Product Owner oder so etwas in der ähnlichen Weise.
Ja, also diese Rollen, die abstrahieren vom konkreten Projekt und tatsächlich
kann so ein Vorgangsmodell auch Vorgaben für Rollen empfinden.
Ob sie das konkret dann die Rolle in Personalunion machen,
zum Beispiel bei einem kleinen Projekt, wird es häufig gemacht,
dass der Softwareprojektleiter gleichzeitig der Softwarearchitekt ist.
Ja, dann kann man Rollen durchaus zusammenlegen im Personalunion
Für jede Rolle wird beschrieben, was gehören für Aufgaben zu dieser Rolle.
Das ist ja eine wichtige Sache. Zum Beispiel,
wenn Sie jemanden einstellen wollen,
auf eine bestimmte Position oder wenn derjenige die Position übernehmen soll,
möchte sich damit vertraut machen.
Die Verantwortlichkeiten, das ist seine Rolle in der Kommunikation im Zusammenspiel.
Welche Qualifikation wird gebraucht? Das wird in großen Unternehmen teilweise dazu geführt.
Schulungsmaßnahmen zu konzipieren. Und wie kommunizieren diese Menschen miteinander?
Das ist sozusagen diese drei wichtigen Punkte, Aktivitäten,
Artefakte, Rollen. Das ist das,
was ein Vorgehensmodell ausmacht,
was ein Vorgehensmodell definiert
Und jetzt noch ein paar Beispiele zu nennen.
Wir sprechen jetzt hier über das Vorgehensmodell V-Modell,
wo das herkommt, sage ich gleich noch was dazu.
Außerdem hatte ich schon, als es zur UML ging,
ein paar Folien vorher darüber gesprochen, dass es den Rechner Unified Proses gibt.
Das ist der, das ist der Prozess zur UML.
Während die UML sehr bekannt ist und auch durchaus als Industriestandard weit akzeptiert wird,
ist der Unified Proses nicht wirklich so bekannt,
so populär, aber ist ein Vorgehensmodell.
Er hat gesagt, ganz klar, Was ist die Rolle des Architekten?
Was ist die Rolle des Entwicklers? Wie sieht ein Architekturdokument aus?
Wie sieht ein Testdokument aus? Wie sieht eine Schnittstellenbeschreibung aus?
Sehr hilfreich. Und Scrum möchte ich durchaus hier auch nennen,
als Vorgehensmodell, weil es auch Rollen definiert,
wie zum Beispiel, was macht der Scrum Master?
Was macht der Product Owner? Was macht das Team?
Und was für Tätigkeiten gibt es, was für Artefakte,
Beispiel für Artefakt, sei jetzt hier zum Beispiel der Product Backlog.
So, soweit, was ein Vorgehensmodell ist.
Und damit, ich schauen wir mal zurück auf die Fragen.
Davon haben wir die erste jetzt schon rangegangen
Na, was ist hier? Was ist ein Vorgehensmodell der Softwareentwicklung? Ja,
das haben wir behandelt und jetzt gehen wir ganz konkret weiter.
Wir wollen ja am Ende, wollen wir erreichen,
darüber zu sprechen, wie muss denn das mit der Modellierung,
mit den Modellierungstätigkeiten abgestimmt sein?
Einen Punkt, den ich gleich nennen möchte, irgendwer mir muss das Modell erstellen.
Irgendjemand muss es weiterentwickeln, wenn Änderungen sind und irgendjemand muss prüfen,
ob es am Ende noch konsistent ist. Zum Beispiel,
es konsistent zu den Änderungen, die man während der Implementierung macht.
Diese Dinge, diese Folge von Tätigkeiten, das ist das,
gehen wir wieder zurück zu dem, was ist ein Vorgehensmodell?
Das ist zum Beispiel in den Aktivitäten zu regeln.
Also die Aktivitäten, die Folge von Aktivitäten,
nämlich das nach der Erstellung immer eine Prüfung kommt.
Das ist im VRL darzustellen. Und diese Vorlagen für Aufbau,
Inhalt, das sind die Inhalte,
das sind die Anforderungen an eine Modellierungssprache, wenn dort Modelle eingesetzt werden.
Also deswegen, das sind die Punkte, wo wir das
Vorgehensmodell abstimmen wollen mit den Modellen, beziehungsweise meistens umgekehrt.
Meistens ist das Vorgehensmodell schon da. Und jetzt praktischer Punkt für ihre berufliche Entwicklung,
wenn sie in einem Unternehmen sind und haben solche Aufgaben,
die hier mit dem Projektmanagement,
das war ja auf der vorgehenden Folie, ja,
in irgendeiner Form zu tun haben und es ist in einer anderen Rolle koordinierend in einem Projekt,
auch wenn sie nicht der Projektmanager sind.
Schauen Sie nach, ob es ein Vorgehensmodell gibt, ja,
mal schauen Sie nach, was es für Regelungen hier gibt.
In manchen Unternehmen sind diese Vorgehensmodelle zwar existent,
das ist einfach Staub der Ordner irgendwo in der Ecke oder
eine Datei tief irgendwo auf einem Laufwerk, aber sie wird nicht geliebt.
Selbst in so einem Fall können sie sich das greifen,
können rausschauen, was ist für sie sinnvoll. Häufig ist das deswegen,
weil keiner von den Führungspersonen das für wichtig hält,
dass man das umsetzt, aber vielleicht auch,
weil es ein bisschen weltfremd ist,
bürokratisch nicht passend
Sie können sich vielleicht Verdienste erwerben, indem sie es ein bisschen aktualisieren.
Auf jeden Fall können sie ganz persönlich Nutzen daraus ziehen,
indem sie solche Informationen, was für Vorgaben gibt es denn,
was für Aktivitäten, was für Vorgaben für Artefakte oder was für Vorgaben für Rollen,
Verantwortlichkeiten gibt es denn.
Ich persönlich habe es sehr davon profitiert, dass ich in einem Projekt,
wo es kein wirkliches Vorgehensmodell gab, mir das Vorgehensmodell oder gelebt wurde,
mir das Vorgehensmodell genommen habe und geschaut habe,
was daraus kann ich verwenden.
Und daraus zum Beispiel eben zu Dokumenten etwas genommen habe,
was mir dann half,
für Tätigkeiten nicht zum ersten Mal gemacht habe,
dann eine Vorgabe zu machen
Machen sie das Beste daraus, wenn es in Firmen,
wo es das nicht gibt. Und in Firmen,
wo es das gibt und gelebt wird,
bringen sie ihr Feedback ein, wenn es konkreter oder allgemeiner sein soll,
wenn es entschlackt werden muss, von zu viel Bürokratie.
Solche, und versuchen sie, das durchaus durchzusetzen,
versuchen sie in dem Unternehmen,
sich dadurch auch entstanden und einen Namen zu machen,
indem sie an solchen Regelungen Vereinheitlichungen mitwirken.
Wenn das nicht ein ganz autoritärer Führungskultur ist, wird man ihre Mitarbeit schätzen.
Und wenn es eine ganz autoritäre Führungskultur ist und sie mögen die nicht,
dann haben sie es bei der Gelegenheit wenigstens kennen und können rechtzeitig die Kurve kratzen.
Okay, soweit zu dem, was ein Vorgehensmodell ist.
Jetzt können es konkret zum V-Modell
So, hier kommt es. V-Modell hat seinen Namen nicht durch die Abkürzung Vorgehensmodell,
dass man irgendwie gesagt hat, ich kürze das ein bisschen ab,
sein, nein, sondern man hat es dadurch,
dass man so eine V-förmige Struktur hier nimmt und dieses V immer als Symbolik,
wir kommen gleich zu diesem Bild zurück,
nimmt und daher kommt der Name.
Es wurde entwickelt, nicht für ein Unternehmen,
sondern zunächst für die Bundesbehörden,
zunächst für die für Verteidigung und Sicherheit,
weil die typischerweise nicht selbst entwickeln,
sondern alles in Auftrag geben und das sollen natürlich die Projekte
in gewisser Weise wiederkehrend sein,
nämlich um besser kontrolliert werden zu können,
abgerechnet werden zu können und
besser steuerbar sein zu können
So, nachdem die Bundesbehörden das eingeführt haben,
uns dann auch weitere Ministerien wie Finanzministerium, Gesundheitsministerium,
Verkehrsministerium eingeführt hat und das Ding, die Regelungen hat,
dass es auch unter Auftragnehmer anwenden müssen,
hat sich das in Deutschland sehr weit verbreitet.
Bis dahin, die großen Staatsunternehmen, Bahnbrüst, Telekom oder früheren Staatsunternehmen,
haben das in ihrer eigenen Vorgehensmodelle ziemlich eins zu eins abgebildet.
Ein paar Kleinigkeiten gibt es da unterschiedlich.
Das ist das eine und deswegen ist es weit verbreitet.
Außerdem muss man sagen, es ist sehr allgemein,
das heißt, es passiert fast für alle Arten von Entwicklung,
die irgendwie technische Systeme entwickeln
Natürlich spielt ein Computer eine Rolle, aber Hardwareentwicklung ist ganz genauso.
Sie würden es jetzt vielleicht nicht verwenden, wenn Sie Fleischproduktion beschreiben wollen.
Aber für Geräteentwicklung und so weiter ist das auch geeignet, Hauptware-Software-Systeme sind geeignet.
Ein weiterer Punkt, warum es sich so verbreitet hat,
also der erste Punkt war, weil es auch vorgeschrieben wurde für Unterauftragnehmer,
ist, dass es Anpassungssysteme vorgesehen hat.
Es ist also tatsächlich etwas enthalten,
die Leute haben den Namen Tayloring gegeben, Taylor war eigentlich der,
der seinen Namen dafür, des Namen verwendet wird,
dafür für die Arbeitsteilung, an einem Fließband passiert.
Also in die tiefgehende Arbeitsteilung überhaupt nicht agil, sondern eher fest.
Aber die Zusammenarbeit von vielen Menschen regelt. Und hier
hat man das benutzt für die Anpassung, diese Namen.
Und tatsächlich ist es in dem Fond-Modell eingebaut,
wie ich für kleine Projekte, für sehr Datenbank-lastige Projekte,
für wissenschaftliche Projekte oder für Projekte mit höherem Risiko eine Anpassung vornehme,
eine Anpassung an diese Eigenschaften.
Es ist ein schwergewichtiges Modell, schwergewichtig heißt,
mit hohem Aufwand. Das schreibe ich einfach mal noch
mit dran
Viele Regelungen, viele Dokumente. Das ist für manche Socken von Projekten notwendig,
insbesondere für verteilte Projekte, wenn Sie unter Auftragnehmer haben,
muss ja alles irgendwie vertraglich geregelt sein.
Da muss ich es aufschreiben. Das heißt,
ich brauche solche Dokumente und ich brauche auch Regelungen,
die für die Unterauftragnehmer Geld hin.
Und ich brauche für lange dauernde Projekte,
brauche ich das, weil ich muss das Ganze aufbewahren.
Ich kann nicht darauf vertrauen,
wie bei Scrum eher das Team wird es schon wissen und
nicht vergessen
In fünf Jahren habe ich da komplett andere Leute.
Oder in zehn Jahren. Und für große Projekte,
die mit Risiken verbunden sind, da muss ich einfach mehr für Kommunikationsregelungen tun.
So, es ist nicht besonders agil, auch wenn XT
steht für Extreme Tailoring, das steht hier in der nächsten Zeile.
Man sagt, okay, ich kann das super anpassen und
an tatsächlich sagen sie auch, sie wird ein iterativ unterstützen.
Meine Meinung ist, sie unterstützen nicht wirklich. Ja,
also der Rückweg ist sie zum Beispiel von der Tätigkeit her
nicht wirklich definiert. Ja, also wie überarbeite ich etwas?
Wie mache ich
Reverse Engineering
Wie mache ich Architecture Recovery, wenn irgendwas fehlt?
Was ist, solche Tätigkeiten sind im Fondsmodell XT nicht wirklich definiert?
Es ist eher ein Wasserfallartiges Projekt und solche Projekte haben ihre Stärken,
wenn die Anforderungen und auch die Riesiken von vornherein klar sind.
Wenn sich da also nicht viel ändert. Wenn alles noch
im Fluss ist und ich weiß noch gar nicht, was ich mache,
sind agile Vorgehensweisen wie Scrum oder Extremprogramming auf jeden Fall besser.
Aber für Projekte mit Unterauftragnehmern können sie eh nicht mehr so viel ändern,
weil sie sonst die ganzen Verträge über den Haufen schmeißen müssten,
keine Projektbahn mehr hinkriegen. Das heißt, solche Projekte mit
ganz vielen Partnern sind sowieso eher behäbig und träge da passieren,
dürfen nicht so viele Anforderungen sich mehr ändern.
Das, was wir hier besprechen, ist die Version von 2005, das V-Modell XT.
Es gab vorher schon welche Sachen, 92, 92 oder 97,
gab es auch schon Vorgehensmodelle, die ähnliche Sachen enthalten.
Ja, hier unten steht nochmal, das ist eigentlich nicht
viel Unterstützung oder die Unterstützung aus meiner Sicht für iteratives
Vorgehen, nicht sehr weit geht. So, lange Vorräte,
jetzt kurze Vorstellung zum Entwicklungsprozess, wie sieht denn das aus?
Hier habe ich ein Foto mal rausgenommen aus einem solchen Darstellung,
einer solchen Darstellung für Projekte. Hier sehen Sie schon mal,
dass es manche Sachen für manche Projekte gibt, für manche nicht.
Wir sehen das V und diese Ebenen,
die wir hier sehen, das sind die Ebenen der Verfeindung.
Ja, also es gibt die Ebene des gesamten Projektes,
dann gibt es die Ebene des gesamten Systems,
dann gibt es die Ebene des Teil von Teilsystemen, von Komponenten.
Und dann gibt es die Ebene darunter, Feinentwurf,
grob Entwurf, Feinenwurf für den anderen Darstellung, manchmal noch dargestellt.
Ich habe hier mal so eine Darstellung gewählt,
es gibt verschiedene ähnliche Darstellungen, wo darum geht,
wo es darum geht, dass es hier eine Ausschreibung gibt,
dass es Angebote gibt, Aufträge gibt.
All solche Sachen sind hier in dem Ding mit drin und sie können ahnen,
dass das mit Softwareentwicklung erstmal relativ wenig zu tun hat.
Klar, man macht hier, also die Softwareentwicklung haben wir hier als Systemaentwicklung,
also Hardware und Software. Tatsächlich gibt es hier die Antwortungsdefinition,
dann gibt es das spezifizierende Systems,
also das Pflichtenheft und dann den Entwurf,
da würden wir vielleicht sagen, Architektur dazu, feinen Wurf abgeschlossen,
die Implementierung hat man hier gleich weggelassen in dem Bild,
ja,
und dann wird es wieder zusammengebaut,
Abnahme und so weiter
Soweit zu der kurzen Vorstellung, jetzt zu unseren Fragen.
Ich springe mal ganz zurück. Da wird gefragt,
wieso ist denn hier eine Trennung in Anforderungsanalyse und Entwurf,
wenn wir wieder zurückgehen zu dem Bild,
so sehen wir tatsächlich die Anforderungsanalyse hier vorne,
da gibt es ein, zwei, drei, vier weitere Schritte,
vier Schritte so und dann kommt erst dein Wurf.
Es ist doch ganz häufig so,
dass wir die Antwortung gar nicht vollständig kennen,
dass man während des Entwurfs merkt,
oh, da gibt es typischer Fall, sind Fehlerreaktionen,
ja, man ist das Verhalten, ist beschrieben,
ja,
aber das nur zu fallen im Normalfall
Es ist nicht klar, wie sieht denn das Verhalten im Spezialfall aus.
Und da muss man tatsächlich hier in dem Fall tick-tak-tak-tak-tak zurückgehen und
die Antwortung nochmal erheben. Und dabei ist aber schon ein Angebot,
ich gehe mal in einen Auftrag gegeben und da kann es sein,
dass bei der Gelegenheit noch zusätzliche Positionen zu einem Auftrag dazukommen.
Ja, das ist der Nachteil des Wasserfallmodells,
aber das ist eben, das ist eben die Tatsache,
die wir hier haben, wenn wir so ein Wasserfallmodell haben.
Also ich muss tatsächlich bei Anforderungen ein Kriterium für gültige Anforderungen,
wäre es, wenn Anforderungen prüfen, sind.
Ja, das schreibe ich mal auf ein separates Blatt.
Da fühlt man mir ein Blatt ein. Die Phasenanforderungsanalyse,
Entwurf soll das heißen und Entwurf sind getrennt, Aber die Realisierbarkeit von Antwortungen.
Sie ist ein wichtiges Gütekriterium, wichtiges für eine Anforderungsbeschreibung.
Wir schauen nochmal zurück, also jetzt erstmal der Fakt,
das ist das, was wir zu der Frage hören.
Was ist denn mit Realisierbarkeit gemeint? Die Realisierbarkeit einer Anforderung
? Also zum Beispiel in der Anforderung steht drin,
die Daten werden dort und dorthin per Webservice übertragen.
Weil Webservice ist vielleicht in der Umgebung des Systems wichtig sind.
Dann würde das bedeuten, ich lege die Anforderung hier fest,
schreibe die in den Auftrag, die Ausschreibung mit rein,
im Angebot nehmen die Leute darauf Bezug,
aber es ist noch gar nicht geklärt,
ob das technisch überhaupt möglich ist
Ob das von den Zeitforderungen her passt. Ob das von der Zuverlässigkeit her
die Forderungen erfüllt oder gar von Sicherheit ganz zu reden.
Das heißt, man muss erst prüfen, sind denn die Anforderungen auch realisierbar?
Und deswegen ist es eines der wichtigen Kriterien für eine Anforderungsbeschreibung, Realisierbarkeit von Anforderungen.
Wir können jetzt hier nicht ganz genau in diese Anforderungen,
was ist eine Anforderungsbeschreibung, reingehen. Ich hoffe,
Sie hatten das in Softwaretechnik, diejenigen, die von Ihnen,
die bei mir Softwaretechnik im vierten Semester gehört haben.
Wir haben es auf jeden Fall schon mal gehört.
Also da gehört Anforderungen, Realisierbarkeit, eine Anforderung hier
als Abnahmekriterien
Verantwortungsbeschreibung fertig ist, sieht die Hut. Und typischerweise muss
das jemand machen, der das System entwerfen kann.
Der in der Lage wäre, der macht das vielleicht nur auf Papier,
aber er macht erprüft, ob die Antwortungen erfüllt werden können.
Das heißt, er nimmt eigentlich Tätigkeiten vorweg, die hier passieren.
Das heißt, derjenige, der ein Angebot abgibt,
also zum Beispiel ein Ministerium gibt einen Auftrag oder die Bande,
die Deutsche Bahn gibt eine Verwaltung für ein Signalsteuerungssystem. Sie formulieren Anforderungen,
sie machen eine Ausschreibung und Siemens Rail oder was auch immer,
will ein Angebot davon abgeben, da muss der Projektleiter,
derjenige, der das macht, muss sich einen Architekten dazu holen,
der also normalerweise das eigentlich macht und würde jetzt hier während der Abgebrabe des Angebots prüfen,
ist denn das realisierbar.
Ansonsten würden Sie an Teufels Küche kommen,
wenn Sie sagen, ja, super, machen wir,
kostet 400.000 Euro und nach sechs Monaten ist es fertig.
Und dann stellen Sie nach zwei Monaten Arbeit fest,
geht gar nicht. Dann haben Sie vielleicht einen Vertrag unterschrieben,
mit dem eine Vertragsstrafe steht, bei Nichterfüllung. Das heißt,
ich muss hier prüfen, kann ich die Antwortungen erfüllen,
beziehungsweise die Antwortungsbeschreibung ist nur gut, wenn sie erfüllt werden kann.
So, also nochmal hier, redet Sie über Küdigkeiten für
Einflussungsbeschreibung, Als das wohl mal dran schreiben.
Und muss bei Abgabe eines Angebots geprüft sein, geprüft werden.
Und dazu müssen wir sozusagen wie ein prototypischen Entwurf oder manchmal sogar eine prototypische Realisierung,
wenn wir Performance-Anforderungen prüfen wollen, können wir das denn überhaupt,
da muss man mal was Kleines bauen, einen kleinen belastbaren Prototyp für einen Lasttest?
Oder Brutto, schön, Realisierung, benötigt. Ja,
also ich muss das vorher machen, damit es gemacht wird,
damit man das prüfen kann.
Also das wäre jetzt ein Beispiel für die Frage 5.
Wie kann man denn das Wie kann man denn so etwas prüfen?
Die Trennung dieser beiden Phasen, die Trennung zwischen,
diese deutliche Trennung zwischen Anforderungsbeschreibung und Entwurf ist hier natürlich für Nachteil.
Ja, ganz klar. Das ist aber der Preis,
den ich habe, wenn ich hier Ausschreibung an Trittfirmen haben
möchte und da muss man sicher gehen, dass die Anforderung das auch wirklich erfüllen.
Ja, sonst kommen sie dazu, dass sie sagen,
ja, die Firmen geben ein ganz kleines Angebot ab und wenn sie dann feststellen,
oh ja,
da muss ich ja das noch machen und das noch machen und das noch machen,
weil sie in den Anforderungen eben nicht drinsteht.
Dann kommen die mit Nachforderungen und sagen, ja,
das kostet jetzt eine Million
Und das will man natürlich nicht. Das ist dann teilweise
für die Kostenexplosionen verantwortlich. Soweit zu der ersten Frage,
die Ihnen noch hoffentlich ein bisschen Einblick gibt in das,
was wir hier machen. Und nun zur letzten Frage auf unserer Fragenliste
. Da geht es darum, um Wiederverwendung von Ergebnissen.
Wiederverwendung von Ergebnissen bedeutet ja, es kommt nochmal vor,
es wird woanders in einer Form verwendet. Wiederverwendung ist natürlich immer,
ich gehe wieder zurück zu dem Bildchen mit dem V. Wiederverwendung ist natürlich,
und da habe ich,
ich habe noch ein anderes Bild mit dem V,
das hier,
das zeigt diese Ebene nochmal
ein bisschen besser
Und letztlich ist es das Gleiche wie das,
was wir hier haben, so ein bisschen verwandt.
Sie sehen hier auch Systeme, Spezifiziertsysteme, ja hier entworfen, integriert.
Und hier ist die Abnahme, also dieses V,
diese V-förmige Sache gibt es schon auch.
Aber wir gehen mal noch zu diesem Bild, das zeigte sehr viel detaillierter.
Wie sieht denn das aus? Das bezieht sich jetzt nur
auf Aktivitäten der Systementwicklung. Und da ist es dann halt so,
dass ich zunächst auf die Ebenen stellen jeweils da,
was das ist, die erste oberste Ebene,
ist die fachliche Ebene, die Ebene der Anforderungen,
die Sicht von außen.
Die nächste Ebene ist die Ebene des Systems
Systems als Ganzes mit seinen Schnittstellen nach außen.
Die nächste Ebene ist das System als inneres an sich,
der Innere mit seinen Teilen. Und das ist das System
nur betrachtet auf den Seilsoftware. Nehmen wir mal an,
es besteht aus Software, Hardware und Konfiguration als verteiltes System.
Und hier wäre dein Entwurf von Implementierung, Realisierung mit dabei.
Das ist also noch eine Ebene,
hier wäre dann sozusagen die Code-Ebene, die Architekturebene,
hier das gesamte System mit Hardware und Software und Konfiguration und
Datenbank und Webserver und was nicht noch alles.
So, jetzt hierzu die Frage,
wo kann ich denn
etwas wiederverwenden
Tatsächlich ist es ja so, dass wir zum Beispiel hier eine Anforderungsbeschreibung haben.
Und die können wir verwenden für die Abnahme.
Bei der Abnahme kann man sie, ist sie das Prüfziel.
Sind die Anforderungen denn erfüllt? Die Architektur hat hier
zum Beispiel so etwas wie Komponenten und Schnittstellen
Und diese Komponenten und Schnittstellen brauche ich,
wenn ich das System wieder zusammensetzen will.
Der Entwurf beschreibt das Verhalten an Schnittstellen, zum Beispiel.
Und diese Beschreibung des Verhaltens kann ich benutzen,
um dann Testfälle zu entwickeln. Also das heißt,
auch hier, sowohl bei den Integrationstests,
also bei Unitors,
kann ich
das dann verwenden
Das ist ein Zeichen dafür, wie die Ergebnisse sich dann fortpflanzen im Projekt.
Das ist nicht wirklich Wiederverwendung, aber die Frage oder wenigstens teilweise beantwortet.
Aber was wir aber natürlich immer als Wiederverwendung haben, ist, in ähnlichen Projekten,
in ähnlichen Teilen des gleichen Projektes kommt das Ganze vor.
Damit haben wir die Fragen alle beantwortet. Wir haben,
sollten noch einen Blick werfen auf kleine Projekte.
Tatsächlich gibt es nicht nur diese Schwergewichtigen,
die wir hier in dem V-Modell haben,
in dem Vorgehensmodell, mit mehr Auftraggebern,
sondern es gibt durchaus auch die kleinen Projekte,
die man agil entwickelt
Dazu mache ich mal eine neue Seite hier da hinten dran.
Vorgehen, Prozesse und Verwendung von Modellen. In kleinen Teams,
so steht es in unserem Buch, als Kapitel,
aber wir erweitern das mal um den agilen Prozessen
In agilen Vorgehensweisen. Wir haben natürlich immer diese Vielfalt,
die wir in meinem V-Modell schon besprochen haben, jedes Projekt ist anders.
Deswegen lässt es sich ganz schwer sagen, was können wir
denn gemeinsam sagen. Aber was wir auf jeden Fall sagen
könnten, das Team prägt das sehr.
Ja, und deswegen haben wir hier eigentlich zwei Szenarien,
die ich skizzieren wollen will.
Zum Beispiel zum einen das Szenario, wir nehmen
ganz viel Modellierung
Dieses Szenario würde zum Tragen kommen,
wenn wir zum Beispiel hohe Qualitätsforderungen haben.
Also ein System muss sehr zuverlässig sein,
ein System muss sehr,
hat sehr viele Risiken zu bewerten
Die Risiken schreiben wir hier gleich mit dazu,
die gehören in die gleichen Gruppe. Ja,
dann hilft uns das, hilft uns das sehr,
wenn wir Modelle verwenden, um frühzeitige Prüfungen zu machen.
Oder auch Simulationen könnte ich da machen, mithilfe der Modelle.
Das ist ein Punkt, der dafür spricht,
dass man viel Modellierung einsetzt.
Der nächste ist,
dass wir einen hohen Wiederholgrad haben
Also verschiedene Sachen, zum Beispiel viel chematischer Code.
Das könnte eine Variantenvielfalt, könnte das sein,
das könnte sein, dass wir sehr viel ähnliche Sachen haben,
die wir generieren müssen, zum Beispiel als Nutzeroberfläche,
dann kann man versuchen,
durch Generierung
etwas zu machen
Dass man also die Entwicklung auf einer etwas höheren Ebene macht,
also etwas abstraktere Konstrukte, zum Beispiel für einen Workflow,
für Benutzerstrukturen, für Interaktionen, für Datenstrukturen,
für Datentransformationen beschreibt.
Und diese dann durch Generierung und Transformation die Realisierung überführt.
Das wäre hier denkbar. Ein weiterer Punkt wäre,
dass wir sehr stark effizient hohe Effizienzforderungen haben.
Das muss man schreiben hier
Also wir müssen rationalisieren, wir müssen sehr schnell sein oder
sehr viel Änderung haben. Dann würden wir auch versuchen,
auf höherer Ebstraktionsebene etwas zu entwickeln und dann auch die Modelle
direkt ausführbar zu machen, zu generieren.
Ausführbare Modelle, Und die Entwicklungstätigkeit wird auf einem höheren Abstraktionslevel
eben zum Beispiel, der Entwurf ist direkt ausführbar gemacht.
Es bleibt jetzt kaum noch Platz für das Szenario 2,
das klappt nicht, nehme mal ein bisschen kurz.
Szenario 2 unterscheidet sich natürlich, das ist,
Sie können schon erwarten,
das ist ein wenig Modellierung
Ich hebe das mal farbig hervor, damit man das ein bisschen besser sieht.
Das eine ist hier, das nächste ist hier. So,
und dieses Szenario wenig Modellierung trifft zum Beispiel zu,
wenn wir Mitarbeiter mit geringer Qualifikation haben.
Das ist schlecht, etwas besser geht das noch,
mit geringer Qualifikation. Also das wäre eine Möglichkeit,
Und das begrenzt unsere Möglichkeiten, komplexe Techniken einzusetzen.
Ich gehe nochmal zurück. Wir hatten, kannst du anfangen,
dieses Bildchen, was wir ganz am Anfang hatten,
wo ja gesehen war, wo er zu sehen war,
ja, die Komplexität steigt.
Und wenn wir nicht so qualifizierte Mitarbeiter haben,
dann werden die so ein Modelltransformationssachen nicht beherrschen.
Wenn die die Methoden nicht beherrschen, dann können die schon kaum
das noch machen, geschweige denn so ein Repository-zentriertes Modellierungsvervorgehen durchführen.
Der nächste Punkt ist, wenn wir geringe Komplexität oder geringe Risiken haben,
Also hier schreiben wir noch dahin, nicht schwer beherrschbar.
Und hier können wir ganz klar sagen,
wenn es geringe Risiken gibt, wenn nicht geringe Konkretität sind,
dann haben wir,
dann bezahlt sich der Aufwand nicht.
Aufwand lohnt nicht.
Es geht auch ohne
So, und als weiteren Punkt,
weil man wenig Modellierungen macht, sondern relativ gleich entwickelt,
das wäre immer dann, wenn wir ganz viel Agilität brauchen,
das heißt, wir müssen immer sofort umsetzen,
man kann es natürlich auch machen durch,
wir hatten das hier oben mit hohem Änderungsbedarf, ja,
aber wenn man vorher gar nicht weiß, wohin die Reise geht,
dann wird man nicht eine grundsätzliche Toolentscheidung machen,
dann wird man nicht einen Generator einsetzen,
wenn sich alles immer ändert
Dann wird man das eher einem qualifizierten Team überlassen und das
Team arbeitet mit wenigen Formalismen. Und mit hoher Flexibilität.
So, damit nur noch ein paar Worte.
Was wäre sinnvoll, wenn wir mit kleinen Teams arbeiten?
Hier gehen wir nicht weiter ein. Ich möchte Sie darauf verweisen,
dass es im Buch eine ganze Menge mehr Informationen dazu gibt,
Best Practices für kleine Teams.
Das wird aber auch nicht Gegenstand der Prüfung sein.
Vielen Dank dafür und wir sehen uns wieder am Donnerstag 9 Uhr,
beziehungsweise dann in der kommenden Woche.
Vielen Dank