Hallo, dieses Semester geht zu Ende. Wir sind,
nähern uns dem letzten Block oder hier ist schon das
letzte Kapitel und wir beschäftigen uns zum Abschluss etwas damit,
wie man Softwareentwicklung in großen Projekten organisiert.
Das Vorgehensmodelle ist etwas, was aus der Ferne sehr bürokratisch,
langweilig oder wie auch immer klingt, wenn sie in großen Projekten arbeiten,
kann es sein, dass sie durchaus das Bedürfnis haben,
nach mehr klareren Regelungen.
Und dabei sind wir schon beim Einstieg.
Wir haben zu Anfang wieder ein paar Fragen,
auf die werden wir wieder eingehen und zunächst erstmal,
worum handelt es sich?
Was ist ein Vorgehensmodell
Staaten möchte ich mit dem Begriff Projektmanagement. Dabei geht es
ja darum, dass man Projekte steuerbar macht. Ja,
Steuern, Management, Management als nicht etwas verwalten,
sondern etwas steuern, gezielt in Richtung Erfolg steuern.
Und für das Projektmanagement braucht man eine Reihe von, ja,
wie soll ich sagen, Inkredienzen, wo man sagt,
das sind Sachen, die uns, die wir hilfreich,
die uns helfen, ein Projekt erfolgreich zu gestalten.
Zum Beispiel, dass wir eine Zeitplanung haben. Zeitplanung brauchen vor allen Dingen der Auftraggeber,
der genau wissen muss, wann wird die Software fertig,
wann muss er sie in den Prozess eintakten,
wo die Software angewendet werden muss.
Da gehört zum Beispiel dazu, dass entsprechend bei Zeiten die Kunden informiert sind,
dass die Mitarbeiter geschult sind, dass alle Materialien dafür vorbereitet sind,
dass vielleicht die Hardware-Ausstattung da ist, wenn da eine umgestellt werden muss.
Das ist ein Migrationsprozess gibt vom Wechsel von der alten
zur neuen Umgebung, wenn damit ein Wechsel verbunden ist.
All solche Sachen braucht man,
damit man pünktlich fertig wirst und das müssen wir natürlich intern fortsetzen,
dass das Softwareentwicklungsprojekt so gesteuert wird,
dass wir es
pünktlich fertig haben
Wenn wir arbeiten im größeren Teams machen,
dann reicht es nicht auf Zuruf,
sich in irgendeiner Weise für die Gesamtaufgabe zu engagieren,
sondern da kommt es darauf an,
dass jeder eine oder jedes Team oder gar wenn mehrere Firmen beteiligt sind,
jeder Auftragnehmer, nicht der Unterauftragnehmer, eine klare Teilaufgabe bekommt.
Diese Teilaufgabe soll möglichst in einer Form sein, dass man
die auch mal verschieben kann. Zeitlich und auch zu anderen Partnern.
Der Projektleiter muss immer wissen, wo stehen wir denn jetzt?
Sind wir Im Zeitplan haben wir noch Puffer oder sind wir gar,
außer dem Zeitplan haben wir, sind wir im Moment gerade mit Verspätung unterwegs.
Wenn das Letztere der Fall ist, was ganz häufig ist,
weil wir häufig unvorhergesehene Aktivitäten haben, dann muss er nachsteuern.
So, die Arbeitsteilung steuern. Es gibt Leute,
die sind zwischendurch mal nicht ausgelastet. Andere sind viel zu
viel ausgelastet, haben ständig zu viele parallele Tätigkeiten.
Da verliert man an Effizienz, wenn man zu viel umschalten muss.
Und ganz wichtig, man muss frühzeitig darauf hinwirken,
dass am Ende die Software Eigenschaften hat, die sie brauchen soll.
Also zum Beispiel Performance, Skalierbarkeit, Sicherheit, Zuverlässigkeit und überhaupt,
dass sie alle Antwortungen erfüllt, auch alle Features hat.
Also das muss man unbedingt reichen. Ich habe jetzt rangeschrieben,
Projekte unterscheiden sich. Das ist eine der wesentlichen Punkte. Ja,
man kann nicht für jedes einzelne Projekt ist irgendwie anders. Trotzdem,
wenn viele Leute zusammenarbeiten, reicht es nicht,
die Organisation irgendwie auf Zuruf oder wie ich es mir gerade denke zu machen,
sondern es ist gut, ein etabliertes Verfahren zu haben,
eine Aufteilung, was gehört alles dazu?
Zum Beispiel, um diese Sachen hier, diese Teilaufgaben des Projektmanagements zu regeln.
Und alle müssen wissen, wie das funktioniert. Jedenfalls die
, soweit sie betroffen sind. Und dazu ist es gut
, so etwas zu entwickeln. Ein Schema zu anzuwenden und
dieses Schema im Lauf der Zeit zu verbessern.
Nicht zu sehr detailliert, weil eben Projekte sich unterscheiden.
Man muss es in gewisser Weise allgemein halten.
Aber Zusammenarbeit in großen Teams funktioniert nicht,
ohne dass man in gewisser Weise die Leute informiert,
was machen denn die anderen?
Und dazu, es sind Vorgehensmodelle, das allgemeine Schema,
was man anwenden kann.
Und das muss man dann konkretisieren
So, jetzt habe ich genug gesagt dazu,
was ein Vorgehensmodell ist, wie Vorgehensmodelle funktionieren.
Und jetzt etwas dazu, woraus ein Vorgehensmodell besteht,
was es mitbringt, was es für eine Unterstützung mitbringt für den Projektleiter.
Zunächst gibt es erst mal einen Teil der Informationen,
die drehen sich um Rollen. Nicht um den Einzelnen,
die einzelne Funktion, den einzelnen Mitarbeiter.
Man kann nämlich durchaus Sachen in Personalunion zu machen.
Zum Beispiel, welche Aufgaben hat ein Tester?
Welche Aufgaben hat ein Konfigurationsmanager
Stellt der Tester selbst die Testdaten bereit oder führt er die Tests nur durch?
Welche Aufgaben hätte ein Architekt? Wie weit reichen die Aufgaben desjenigen,
der für Kundenschulung zuständig ist? Da gehören also die Aufgaben
dazu und natürlich auch, was muss derjenige an Ausbildung,
an Qualifikationen mitbringen? Und mit wem muss er reden?
All diese Informationen gehören zu einem größeren Geflecht von Rollen,
man kann das durchaus dann anpassen,
dass es zum Beispiel in kleinen Projekten gar nicht so viele Leute gibt,
wie es Rollen gibt, dann macht einer mehrere Rollen,
ganz klar,
in Personalunion so zum Beispiel
Ein weitergerichtiger Informationsanteil im Vorgehensmodell, in den Informationen über Projekte
, sind die Aktivitäten, die gemacht werden sollen.
Manche, für manche ist das sogar das Wichtigste.
Was muss denn eigentlich gemacht werden? Und dazu steht da drin,
was man in welcher Reihenfolge macht, wie das genau abläuft
und in vielen Fällen auch noch eine mehr oder weniger detaillierte Anleitung.
Natürlich, und jetzt wieder der Sasatz hier, Projekte unterscheiden sich,
man kann diese Anleitung nicht so ganz konkret machen,
mit den und den Sachen in den Datenbankobjekten machst du das und das.
Nein, das ist sehr weit verallgemeinert
Zum Beispiel so eine Methodik wie Wamm oder Objektorientierung steht dort meistens nicht drin.
Sondern das ist unabhängig. Sie können es auch benutzen,
um den Assembler oder Kobalt etwas zu programmieren.
Manchmal sogar gibt es Vorgehensmodelle, die sind nicht mehr für Softwareentwicklung vorgesehen,
sondern sie könnten auch damit Elektronik oder etwas aus Metall entwickeln.
So, und dann gibt es noch die Elemente,
mit denen man etwas macht. Ja,
ins Kommen heißt das Material, also am Vorgehensmodell heißt das Produkt,
weil es etwas ist, was Menschen produzieren.
Es gibt auch noch den wissenschaftlich klingenden Titel Artefakt,
etwas,
was künstlich gemacht ist
Ja, und für diese Produkte gibt es Vorlagen.
Zum Beispiel, wie muss ein Testprotokoll aussehen? Wie muss
ein Bug-Report aussehen? Wie sollte eine Konfiguration beschrieben sein?
Wie sollte eine Architektur beschrieben sein? All solches über diese Sachen
gibt es Vorlagen. Und diese Vorlagen sind ganz hilfreich,
wenn man nicht so genau weiß, was soll ich denn da reintun?
Weil sie hilft, dass man nichts vergisst.
Und da steht natürlich auch etwas,
wie hängt dieses eine Dokument, wie heißt das Produkt,
wie hängt es mit anderen Sachen zusammen
Wie hängt der Test mit dem Code zusammen?
Wie hängt der Code mit den Anforderungen zusammen? Oder mit
dem Entwurf? All solche Sachen stehen da dabei. Ja,
das beantwortet gleich die erste Frage, Vorgaben und Hilfsmittel,
die ein Vorgehensmodell liefert. Das sind genau diese Sachen,
Informationen über Rollen, Informationen über Aktivitäten, Informationen über Produkte.
Das ist das, was wirklich hilfreich ist für sie als Projektleiter.
Habe ich auch mal gemacht, als ich irgendwann
das erste Mal ein Projekt geleitet habe
Da habe ich mir, da war irgendwie ja
Bedarf nach Organisationen, wie macht man so etwas?
Wie macht man eine Anforderungsbeschreibung? Wie macht man eine Projektplanung
? Und ich wusste, dass es dieses Vorgehensmodell gibt.
Und da habe ich mir ein Buch darüber genommen und versucht,
mir die wichtigen Teile rauszunehmen. Später habe ich gemerkt,
dass es nicht reicht, einzelne Teile rauszunehmen,
sondern das ist Gesamtes, ein großes System, weil einfach die Sachen,
die Rollen hängen zusammen mit der Reihenfolge und die Produkte werden von den Aktivitäten gemacht.
Also es ist schon ganz gut, dieses System einzuwenden.
Und wenn dieses System sinnvoll ist und gut angepasst wird an das,
was man was das Projekt ausmacht, was die Eigenschaften des Projektes sind.
Kann es für große Projekte sehr hilfreich sein?
Wenn es zu bürokratisch ist, versuchen Sie etwas davon wegzulassen.
So, jetzt kommen wir dazu, einzelne Vorgehensmodelle anzuschauen.
Typischerweise sind Vorgehensmodelle, weil dort noch ein Haut drinsteckt, irgendwie Firmeneigentum. Ja,
ich kenne zwar von zwei, drei Firmen die Vorgehensmodelle,
weil ich schon danach gearbeitet habe als Projektleiter,
aber die sind irgendwie Firmengeheimnis, ich darf sie ihnen nicht geben.
Was ich ihnen aber geben kann, sind typische Vorgehensmodelle.
Ich habe drei, wir behandeln hier drei typische Vorgehensmodelle,
die erstens veröffentlicht sind.
Zweitens typisch für eine ganze Klasse von Projekten
Und drittens, fiel als Vorlage gedient, haben für vieles,
was sie in Firmen in der Industrie vorfinden.
Wir starten mit dem Vorgehensmodell namens V-Modell. Zunächst hier auf dieser Folie
ein paar Sachen zum Allgemeinen. Also dieses V-Modell ist ein
Vorgehensmodell, was die Bundesbehörden der Bundesrepublik Deutschland entwickelt haben.
Die geben, die haben meistens keinen eigenen Softwareentwickler an Bord
, sondern die geben Aufträge nach außen.
Und da muss das natürlich in irgendeiner Weise koordiniert laufen,
dass am Ende nicht das Steuergeld verschwendet wird und am Ende kommt nichts raus,
außer ein paar bösen Zeitungsmeldungen und einer Erwähnung im Schwarzbuch der Steuerverschwender.
So, dadurch, dass dieses Das wurde so entwickeln,
dass es erstmal für alle Arten von Entwicklungen geeignet ist,
für die Entwicklung eines Datenbanksystems genauso wie die Entwicklung für die Entwicklung des Mautsystems oder eines Steueralgorithmus oder was auch immer.
Dieses System, dieses Vorgehensmodell ist erstmal deswegen ziemlich allgemein,
ja, also für eine Objektorientierung, wenn sie da nichts finden,
sie werden auch nichts darüber finden,
dass man nach Scrum vorgehen kann oder sowas,
das ist ein Modell, was ziemlich wasserfallartig daherkommt,
aber ja,
wir kommen noch gleich dazu,
inwiefern es Iterationen auch unterstützt
Man kann es anpassen an die konkreten Gegebenheiten eines Projekts.
Und dafür ist es sehr gut vorbereitet,
weil nämlich die Anpassung an Projekte schon eingebaut ist.
Sie ist bereits Teil des Vorgehensmodells, da gehört das Zuschneiden dazu.
Die haben hier einen Begriff davon, Tayloring als Anpassung haben die gewählt,
das ist so ein bisschen der Slang, dieses Vorgehensmodells.
Also Tayloring steckt da drin. Dabei kann ich Ihnen gleich noch sagen,
hier uns steht es auch auf der Folie, XT,
das war die letzte Version der Weiterentwicklung dieses V-Modells,
nach 92 und 97 gab es 2019 5, die Version V-Modell XT,
die wird da jetzt seitdem auch ein bisschen weiterentwickelt,
aber das ist die letzte ganz große,
das ganze ganz große Paket und XD steht für Extreme Tayloring,
also manchmal ist das ganz besonders gut,
anpassen an den Projekten.
Und damit den Geschmack von etwas Bürokratie loswerden. Doch ob
etwas bürokratisch ist oder genau richtig für den Regeln hängt,
von dem Umfang ab der Sachen, die ich regeln muss,
also von der Größe des Projektes, von der Komplexität,
von der Unerfahrenheit der Mitarbeiter, von der Verteiltheit über den Standorte.
All solche Sachen spielen eine Rolle,
ob es
gut einsetzbar ist
Diese Einsetzbarkeit ist auch für mich das Stichwort gleich für,
wofür ist so ein Vorgehensmodell geeignet?
Dieses V-Modell XT ist geeignet für große Projekte,
für lange dauernde Projekte und für verteilte Projekte.
Also wo es mehrere Projektteams gibt, manchmal sogar mit Unterauftragnehmern.
Dafür ist es gut vorgesehen. Es ist außerdem geeignet,
weil es so stark wasserfallartig ist. Also es muss möglichst alles definiert sein.
Es ist dann gut geeignet, wenn die Anforderungen zu Anfang
möglichst gut, Klaas, möchtest du weitgehend klar sind.
Und auch wenn die Risiken klar sind,
damit man weiß, welche Maßnahmen muss man auswählen,
bei eben bei diesem Tayloring, anpassen an diese Projektziele,
an die Risiken,
die bestehen
Es gibt tatsächlich auch ein bisschen Unterstützung für iteratives
Vorgehen. Jedenfalls sagt das V-Modell XT, das macht,
dass es so wäre. Ich persönlich würde mal sagen,
ja, ja, also es ist schon ganz schön stark Wasserfall.
Ja, also Wasserfall heißt ja,
ich habe die Antwortungen abgeschlossen, da werde ich geprüft,
werde eingefroren und dann macht keiner mehr was dran.
Dann kommt der Entwurf, bis ich fertig bin mit dem Entwurf,
wird da geprüft, wird eingefroren und keiner macht mehr was dran.
Und dann kommt die Implementierung. Und wir alle wissen,
Oder sie ist, glauben es mir vielleicht, die Welt ist nicht so.
Es ändert sich ständig irgendwas. Oder man merkt das und
das geht nicht. Oder man hat es einfach nicht komplett gemacht.
Dann muss man nochmal zurück. Und dieses iterative Vorgehen,
das fehlt in diesem V-Modell so ein bisschen. Ja,
ich will nicht sagen, das ist 100% fehlt,
aber es gibt nicht wirklich Unterstützung, insbesondere ist nicht klar,
in welcher Reihenfolge ich auf dem Rückweg da die Ergebnisse,
die Arbeitsschritte nochmal machen soll
Ja, das V-Modell XT hat seinen Namen von genau dieser Grafik oder
einer solchen Grafik, wo man so einen V wählt.
Es ist nicht etwa die Abkürzung für Vorgehensmodell,
sondern es ist von dieser V-förmigen Grafik hat man das irgendwie abgeleitet.
Und hier auf diesem Bildchen, sie sehen es jetzt hier,
wenn sie das auf ihrem Computer haben, besser,
als wenn ich das an die Tafel projizieren würde,
da sieht man so ein bisschen, wie das mit Unterauftrag niemand funktioniert.
Aber die Ebenen, Dieses V, die Höhen des Faust,
das sind Ebenen. Ja, ich habe das Gesamtprojekt-Ebene,
das Einzelprojekt, das System und Teile des Systems.
Systemelemente. Ja, und man geht so von oben
nach unten, beziehungsweise so quer.
Ja, also das hier hinten entspricht dem hier vorne. Zum Beispiel,
ich teile das System auf in Komponenten und dazu passt,
dass ich das System hinterher,
wenn die Teile gebaut sind,
dass ich sie wieder zusammenbaue,
So, und daher kommt das V. Wir schauen nicht
so ganz genau jetzt alles an.
Ich möchte nur darauf aufmerksam machen, es ist dafür vorbereitet,
dass es Auftraggeber, AG und Auftragnehmer gibt.
Dass man also das unterstützt, dass eine Arbeitsteilung auch zwischen Firmen passiert.
So, wir springen mal zwischendurch zu den Folien,
zu den Fragen zurück, dass wir sagen, was passiert denn da?
Also wir haben jetzt schon so was zur Frage 3 gesagt,
nämlich, dass es dieses Tayloring gibt, wo man das konkret anpasst.
Und zu der Frage 2 werden wir gleich
noch was sagen
Ja, dieses Bild hat man gerade, hier gibt es noch,
hier mache ich mal einen Ausschnitt rausgenommen, zentral ist dieses Produkt.
Ja, also Produkt ist ja alles, was irgendwie entwickelt wird.
Das kann natürlich ein Stück Software sein,
das kann aber auch ein Entwurf sein.
Das kann auch ein Prüfprotokoll sein oder dieser Satz Testfälle.
Alles das kann produziert werden und das ist hier,
läuft immer so,
dass man hier auf einer bestimmten Ebene irgendwie das entwickelt und
dann integriert oder prüft oder so etwas
Ich glaube, das habe ich schon mal gezeigt,
als wir über Anforderungen gesprochen haben.
Ich möchte es einfach hier noch mal bringen,
weil es ihnen sagt, wie man koordiniert mit Änderungen umgeht.
Wir gehen das nur noch mal kurz durch, weil wir das,
wie gesagt, schon im Weich Anforderungsanalyse schon mal hatten.
Also wenn wir eine Änderung haben, ein Änderungswunsch,
generell ein Entwicklungsauftrag. Das kann ein neues Feature sein,
das kann ein Fehler sein, der behoben werden muss.
Eine Ergänzung, was auch immer,
dann hat das verschiedene Zustände und das,
was wir hier als Kreise sehen,
sind eigentlich Zustände und die Pfeile
sind Zustandsübergänge
Und das, was hier dransteht, das ist jeweils im V-Modell eine Bezeichnung eines Abschnitts einer Tätigkeit.
Also das, was wir hier haben, das ist dieser Teil Aktivitäten.
Ich springe nochmal zurück, wo ich gesagt habe,
was Ihnen zu einem V-Modell alles dazugehört, ja,
da gehören die Aktivitäten und Ihre Reihenfolgen dazu.
Und dieses KM33, das steht für eine Aktivität. So,
also hier, das sind einzelne Aktivitäten,
in dem Fall KM, Aktivitäten des Konfigurationsmanagements,
wo es darum geht, dass ich Produkte, so Teilergebnisse,
ich wollte den Begriff Produkte nicht unkommentiert benutzen,
wo man diese einfriert, verwaltet,
mit Änderungen umgeht,
sagt,
was passt denn dazu
So, jetzt nochmal die Änderungszustände, die Zustände einer Änderung. Geht von beantragt,
zu beabsichtigt, da wird dann entschieden, in welcher Version,
ja, wenn sie in der nächsten Version kommt, wird es beauftragt,
dann ist der Entwickler tätig und wenn der Entwickler das fertig hat,
liegt das vor und es ist erledigt.
Ja, also,
dass es so laufen Änderungen und jeweils hier wird hier entschieden,
da wird es gemacht,
wird es nicht gemacht oder hier wird es entschieden,
kommt es in die nächste Version oder bleibt es hier drin
und wenn etwas lange hier drin geblieben ist,
sagt man auch mal,
nee,
wir machen es nicht
Also da hatte ich ja schon mal ausführlich was dazu gesagt.
Im Kapitel 1. Wir haben noch so ein ähnliches Bild,
auch schon in Kapitel 1 gehabt, wo wir das mit der Freigabe,
mit dem Qualitätsmanagement, mit der Prüfung gesagt haben.
Das möchte ich auch gerne noch mal kurz vorstellen. Das nützt man,
nutzt man unter anderem auch, damit der Projektmanager immer den Überblick hat,
was ist denn wirklich abgeschlossen? Ich kann Ihnen sagen,
wenn man als Projektleiter neugierig ist,
wie weit denn mein Projekt ist oder wenn man das Gefühl hat,
es ist Zeitdruck und man geht so durch die Reihen,
man spricht mit den Entwicklern,
dann wird man von ganz vielen Hörern,
ja,
ist fast fertig,
fast fertig
Ja, das nützt ihnen aber nicht viel.
Es nützt ihnen erst das, wenn sie wirklich definitiv sagen,
es ist ganz fertig. Und deswegen hilft das,
so eine Sache, wann etwas abgeschlossen ist,
diese Informationen hilft dem Projektler, da einzuschätzen,
wie viel ist denn wirklich jetzt schon geschafft und wie lange wird es denn noch dauern?
Denn erst wenn es ganz fertig ist, weiß man derjenige,
der Entwickler oder die Entwicklerin, kann das Nächste machen.
So, also, was wir hier sehen, sind wieder Zustände,
ja, die, was in den Pfeilen dransteht,
sind wieder Aktionen, Aktivitäten,
die da, die jemand macht.
Und hier QS-Quali-Aktivitäten der Qualitätssicherung
Das läuft also so, dass das zunächst ein Produkt,
damit ist gemeint, also wir hatten schon mehrfach jetzt gesagt,
was Produkte alles sind, das kann ein Entwurf sein,
das kann eine Schnittstellendefinition sein, das kann ein Prüfprotokoll sein oder ein Testdatensatz,
aber natürlich auch ein Stück Software.
Irgendwie zu Anfang wird geplant, wir werden das brauchen,
ja, dann wird das in Auftrag gegeben,
das ist diese Aktivität PM221,
das kann man mit dieser,
unter diesem Kürzel findet man das dann in der Beschreibung dieses V-Modells,
das kommt also so ein ganz schön heftiges Buch daher,
die eine Hälfte ist Beschreibung der Zeitteil des V-Modells und
die andere Teilhefte
ist ein Anbindungsbeispiel
Deswegen ganz hilfreich, wenn sie Bedarf haben, wenn sie das erste Mal Projektleiter sind.
Und in ihrem Unternehmen wird sowas ähnliches wie das V-Modell der Bundesbehörden angewendet.
Dann holen sie sich einfach dieses Buch und schauen sie rein.
Für die Vorlesung müssen sie das natürlich nicht im Detail auswendig lernen.
Hier haben wir ein paar Fragen,
die wir am Anfang haben, die ihnen sagen,
die und die Eigenschaften sollen solchen Vorgehensmodellen, sollten sie kennen.
Gut, also hier wird das in Auftrag gegeben,
dann ist es bei irgendjemand in Bearbeitung,
zum Beispiel der Entwickler entwickelt den Quellcode.
Und wenn er fertig ist,
dann geht es in die Prüfung.
Und das ist,
dass dieser Zustand vorgelegt
Dann hat der Entwickler seine Arbeit abgeschlossen. Er hat quasi
kein Schreibrecht mehr darauf. Und dann wird die QS das prüfen,
werden die Tester das prüfen oder man macht eine Kultinspektion.
Auf jeden Fall kommt hinterher raus, ja, es ist gut.
Und dann nein, es ist nicht gut. Und das
sehen wir hier auch. Es gibt ja zwei Pfeile,
die hier weggehen. Ja, es ist gut, heißt,
es kann weitergehen. Es wird also akzeptiert, es wird
freigegeben. Es wird eingefroren und damit vor Veränderungen geschützt.
Das Check-in. Und wenn es nicht gut ist,
dann geht es nochmal zurück zum Entwickler und da macht nochmal Nachbeisorge.
So, und natürlich, wenn die Sachen freigegeben sind,
dann gehen sie irgendwann wieder, werden sie Teil des nächsten Produkts fließen,
dort mit ein oder wie auch immer
Und jetzt nochmal das, was der Projektmann leider daraus braucht,
wenn etwas wirklich akzeptiert ist, ja,
Unterstützung des Projektmanagements hat, das hier unten heißen,
wenn das wirklich 100 Prozent fertig ist, dann kann er sagen,
ja, super, ist fertig, erreicht.
Ja, und alles vorher ist, man weiß nicht,
wie lange es dauert. Obwohl man das vergnügend kleine Teile macht,
kann man damit schon sagen,
wie weit man ist und wie weit man doch,
wie lange man noch zu tun haben wird.
Ja, Dieses Vorgehensmodell muss erreichen, dass wir möglichst wenig
Fehler machen, dass wir die Sachen richtig machen.
Und vielleicht erinnern Sie sich im Kapitel Qualitätssicherung, Qualitätsmanagement,
hatten wir diese konstruktiven Maßnahmen. Die waren dazu da,
gleich das Richtige zu tun und Fehler zu vermeiden.
Ich hoffe, Sie haben das noch auf dem Radar.
Das waren die wichtigsten Maßnahmen. Fehler gleich vermeiden,
weil die auch Aufwand sparen. So,
und wie ist denn das jetzt hier in dieses Vorgehensmodell eingebettet?
Ich habe hier unten mit roten Kästchen mal die Hauptaktivitäten gemacht,
des Teils Entwicklung
Und blau ist der Teil Qualitätsmanagement, Qualitätssicherung.
Und in deiner Fotosanalyse wird klar, was sind für Risiken.
Es wird klar, was sind für Ziele wichtig in einem Projekt.
Und daraufhin entscheidet man, worauf legt man denn Wert,
was für Schulungen, was für Qualitätszirkel,
was für Arbeitshilfen macht man denn damit und für Maßnahmen,
dass das alles gut funktioniert.
Und die fließen dann hier jeweils ein.
Soweit zu konstruktiven Maßnahmen. Aber wir haben auch analytische Maßnahmen
. Sie erinnern sich hoffentlich,
analytische Qualitätssicherungsmaßnahmen sind
Ja, ich kann sie jetzt nicht hören, weil es zeitversetzt ist.
Ich hoffe, sie sagen Kurt Inspektionen, Inspektionen, Reviews und Tess.
So, und hier haben wir das klassische Test First,
den wir hier in dem V-Modell, ja,
also ich mache das vorbereitender Prüfung vor dem Entwicklungsschritt.
Also der Entwicklungsschritt zum Beispiel, Systemarchitektur einwerfen oder eben
auch Quellcode entwerfen, da mache ich die Prüfung vorher.
Und nach dem Entwicklungsschritt mache ich eine Abnahme.
Und erst dann geht es weiter. Wenn nicht,
geht es nochmal in die Runde
Ja, also dieses Testfirst, was wir immer predigen,
was wir ihnen einschaffen, was in der Praxis nicht alle machen,
das ist tatsächlich das VVMV-Modell auch gefördert, gefordert.
Ja, und soweit etwas dazu, was das V-Modell leistet.
Für die konstruktiven Maßnahmen muss man das Ganze ja,
oder überhaupt für alle Qualitätsmanagementmaßnahmen, muss man das abgestuft machen.
Wenn man zu viel macht, haben wir Bürokratie,
wenn man zu wenig macht, haben wir Chaos.
Also deswegen macht man es genau angepasst und angepasst an die Risiken.
Ja, und wenn die Risiken niedrig sind,
mittel- oder hoch,
macht man unterschiedlich viel
Zum Beispiel in der Stufe niedrig, kann der Entwickler im
Prinzip das so gut machen, wie er es kann.
Und er kriegt kaum Vorgaben. In der Stufe Mittel
kriegt er Vorgaben zum Beispiel für den Test.
Er muss eine Mindestabdeckung des Tests haben bei der Prüfung.
Und man muss eine Dokumentation haben, die so ein Schema erfüllt.
Wenn der Stufe hoch ist, da muss man sehr genau prüfen,
der wird im Mittag ausgerechnet mit einer Vorbereitung der Prüfung,
klar, wie die läuft die Prüfung ab, wie umfangreich,
wie genau muss das sein.
Und da wird auch keiner ausgewertet.
Dabei gibt es
ein Prüfprotokoll
Sind auch Schritte, wo es ein bisschen besser organisiert ist, weil das Risiko einfach höher ist.
Ja, und diese analytischen Maßnahmen sind sehr verzahnt. Das ist ein Bild,
was ich schon mal ganz zu Anfang gesehen habe,
als wir über Qualitätssicherung gesprochen haben, zu Anfang,
nämlich das Test First, den wir hier nochmal,
ja, hier steht jetzt Rot, Entwicklung,
da muss ich das Rot mal hier noch nachzeichnen.
Das Rot ist, hier ist die Entwicklung, ja,
das, was wir hier sehen,
sind so eine Aktivitätsdiagrammik, Sitter sollen diese Linien sind,
Swimlains, also Verantwortungsbereiche, links sind die Sachen,
die Qualitätsmanagement macht.
Hier, SE steht für das Systementwicklung in dem neuesten Modell
des V-Modells und hier rechts das Konfigurationsmanagement bis zu dieser Linie
Und ja, passiert das, was wir schon gerade haben,
Test, First, also das Konfigurationsmanagement stellt Sachen bereit,
mich bereitet den Test, die Abnahme,
die Prüfung vor, Test, First eben.
Und dann mache ich die eigentliche Entwicklung und dann prüfe ich an diesen Vorbereiteten Testfällen.
Das sind soweit diese Maßnahmen und das wäre jetzt auch der Punkt,
wo wir nochmal auf die Fragen schauen,
Wie werden die Inspektionen, Tests mit Entwicklungs- und Projektmanagement-Aktivitäten verknüpft?
Das war das, was wir gerade eben gesagt hatten,
nämlich, dass man zum einen das Test First hat,
ja, und zum anderen, dass man noch ein zweiter,
wo war es denn, ja,
dass man das Projektmanagement dadurch unterstützt, dass man eben sagt,
wann ist es genau fertig?
Soweit zu dem Vorgehensmodell in den V-Modellen,
weiter geht's im nächsten Abschnitt