Bevor wir zu dem Abschnitt Ende 1,3 Aktivitätsdiagramm kommen,
das wird hier gleich das nächste sein.
Haben wir vorher noch die Frage, ach zu beantworten,
Änderungsmanagement. Das gehört insgesamt zu dem Kapitel Anforderungsbeschreibung,
Problembereichsmodellierung mit dazu, wo auch immer wir das einschieben.
Es ist wichtig, dass wir uns klar werden,
dass Änderungen immer passieren, auch wenn wir uns mit Anforderungen beschäftigen.
Für diese Änderungen brauchen wir in kleinen Systemen nichts.
Ja, wir ändern,
dass einfach ungut ist
Wenn mehrere Leute zusammenarbeiten, müssen wir versuchen,
diese Änderung, möglichst gut zu koordinieren.
Weil während Änderungen passieren, Missverständnisse, Auslastungen in Konsistenzen,
Widersprüche, all sowas. Und deswegen gibt es das Änderungsmanagement,
Änderungsmanagement, hier steckt das Wort to manage drin.
Das heißt eigentlich, sowas wie handhaben? Es wird aber
ganz häufig gebraucht, so wie Führen und Steuern
Also Management, nicht im Sinne von, wir verwalten etwas,
insofern, dass wir es in Listen schreiben, nein,
wir versuchen es zu koordinieren.
Wir versuchen, Änderungen in unserem Fall zu koordinieren.
Ich habe hier ein Diagramm mitgebracht, leider ist es hier
irgendwie in der PDF-Darstellung ein bisschen blass geraten.
Ich hoffe, sie können das besser sehen. Das sind also
hier so verschiedene Kreise und das habe ich mitgebracht aus dem V-Modell.
Das ist ein Vorgehensmodell nach dem Wasserfallschema,
was in der Industrie sehr verbreitet ist.
Ich habe das deswegen mitgebracht, weil es in anderen Bereichen
sehr ähnlich vorkommt
Das V-Modell, das Vorgehen, dieses Änderungsmanagement, wie es
zum Beispiel die NASA benutzt, ist sehr ähnlich. Manche Unternehmen,
für die ich schon gearbeitet habe, hatten auch ein sehr ähnliches,
aber die Sachen aus den Unternehmen darf man immer nicht mitbringen,
weil die das teilweise als Firmengeheimnis schützen wollen.
Deswegen kennt man das von der NASA, das ist veröffentlicht,
weil die staatliche Organisation und dieses V-Modell ist auch veröffentlicht,
weil ein nationaler Standard in Deutschland. Dieses Vorgehensmodell ist eigentlich,
nein, das V-Modell ist ein Vorgehensmodell, wasserfallartig,
was für die Industrie vorgeschrieben ist für öffentliche Aufträge, nur so,
dass sie an, wo das, aus welcher Richtung das kommt.
Und das hat eine sehr weite Verbreitung, weil alle Unbeauftragtnehmer das auch machen müssen.
So, was wir damit erreichen wollen, ist,
dass wir Änderungen koordinieren, das sagte ich schon.
Ja, aber auch durchaus vor ungeplanten Änderungen verschützen,
dass man nicht einfach mal irgendwie das und das macht,
weil sich das jemand denkt.
Oder wir haben ganz häufig die Situation,
dass der Auftraggeber da anruft und versucht, ja,
hurra, ich habe die Telefonnummer meines Entwicklers,
der das und das gerade macht.
Und jetzt kläre ich das nochmal,
bespreche ich das doch mal mit dem direkt.
Ehe ich das in Formulare schreibe,
gibt es Missverständnisse
Das ist gut gedacht von dem Auftraggeber. Er weiß,
dass die am direktesten, er kann es vielleicht am besten erklären.
Und im Zwiegespräch kann man auch klären, was ist wirklich gemeint.
Es geht manchmal direkter als per Papier, aber es kann sein,
dass dabei Änderungen aufkommen, die eigentlich so nicht vorgesehen sind.
Oder nicht an dieser Stelle vorgesehen sollen, nicht zu diesem Zeitpunkt vorgesehen sind.
Ja, der Auftraggeber denkt, oder irgendein Bearbeiter denkt in dem Moment,
ich brauche jetzt da und die und die Funktion.
Und das soll ja eigentlich so und so funktionieren, der kann das doch hier einbauen.
Ja, und ruft den direkt an und dann das Ganze schlimm.
Was los, da baut das einen im Besten ab,
der Entwicklung, will ich nein sagen, er weiß,
das ist mein Auftraggeber, von dem kommt mein Geld.
Also deswegen sage ich da nicht nein,
ich höre mir das mal an, ja,
kann ich machen und Schulen sind irgendwelche Zusagen gemacht.
Und das ist dann an Stellen eingebaut,
wo es vielleicht gar nicht hingehört oder es ist an anderen Stellen
schon gemacht und dann gibt es das doppelt oder es soll gar nicht gemacht werden,
weil es nicht ins Konzept passt.
Und der Bearbeiter ist eigentlich gar nicht aussageberechtigt dazu.
Wir wollen sie also erreichen, dass Änderungen in koordinierter Weise ablaufen.
Koordiniert, dass die entscheidenden Leute zugestimmt haben,
dass es ins Konzept passt, dass das Konzept gebrummt ist.
Und dass es mit anderen Aufträgen abgestimmt ist. Ja,
das heißt, dieses Koordinieren. So, und deswegen muss
man manchmal Sachen auch ablehnen. Insgesamt gehört diese Tätigkeit und wird jedenfalls von vielen Autoren als Teil des Konfigurationsmanagements bezeichnet,
Konfigurationsmanagement, da geht es um die korrekte Zuordnung,
Anordnung von Teilen, welche Version gehört zu welcher Version,
wie passt das Ganze zusammen, was wird ein Neues,
eine neue Version,
dass auch das Bild wird davon gesteuert und das Konfigurationsmanagement ist
auch dazu da,
vor Änderungen
zu schützen
Okay, jetzt geht's los,
was wir hier eigentlich sehen, sind Zustände,
also diese ganzen Kreise hier sind eigentlich Zustände,
wir werden später das Zustandsdiagramm der UML in einigen Vorlesungen behandeln,
wo wir dann sehen, okay,
in der UML sieht das ein bisschen anders aus,
das sind das keine Kreise.
Aber uns reicht das,
wir akzeptieren das hier einfach mal, das sind Zustände.
Diese Kreise, und zwar sind das Zustände jeweils eines Elements.
Und dieses eines Elements des Projekts und das könnte zum Beispiel eine Anforderung sein,
es könnte eine Komponente sein, eine Klasse oder wie auch immer.
Oder sogar ein Interface oder was auch immer.
Jedes Element kann diese Zustände alle haben und jetzt schauen wir
uns die Zustände ein.
Es beginnt mit beantragt
Dieser Mitarbeiter, der sie anruft vom Auftraggeber,
da würden sie dann so freundlich sagen und sagen,
ja, ich verstehe, dass das wichtig ist,
aber sie müssen da bitte so ein Antragsformular schreiben.
Und das ist, hm, wird häufig als Change-Request
bezeichnet.
Request,
der Antrag
Es gibt da meistens ein Formular dafür, ob das
ein Web-Formular, so ein Papierformular, ist erstmal egal.
Da schreibt man drauf, wer hat das beantragt,
wozu soll es gehören? Was ist da eigentlich Inhalt?
Wie dringlich ist das? Was hat das für Auswirkungen?
Und natürlich, wer hat das beantragt mit der Telefonnummer drauf?
Vielleicht für Rückfragen oder E-Mail-Adresse, für die Rückfragen.
Das geht dann auf einen Stapel, nehmen wir mal an,
das wären Papiere, die gehen auf einen Stapel beantragt.
Und da gehen jeden Tag drei ein, je nachdem wie groß ihr Projekt ist.
Manchmal gehen auch hier pro Tag 30 ein. Jedenfalls hat man dann,
sagen wir mal, nach einer Woche oder nach zwei Wochen
einen ganz schönen Stapel zusammen. Und nach zwei Wochen wird,
trifft sich ein Entscheidungsgremium und diese Entscheidungsgremium geht die Anträge einzeln
durch und da passiert etwas in diese Richtung oder in diese Richtung.
In diese Richtung passiert, okay, ja,
wir nehmen diesen Antrag an, es wird gemacht,
damit ist nicht gesagt, wann, ja,
also wie es hier weitergeht, das ist nicht gesagt,
aber es ist erstmal beabsichtigt.
Es kann aber auch sein, dass man gleich sagt,
nein, liebe Leute, dafür ist kein Geld da.
Oder nein, das gehört ins Projekt XY, ja,
dann würde das abgelehnt. In jedem Fall wird der Autor,
der Urheber, dieser Mensch, der das Formular,
der so Request gestellt hat, darüber informiert.
Liebe Frau Schmidt, vielen Dank für Ihren Change-Request.
Der wurde heute begutachtet und es ist tatsächlich beabsichtigt, dass das umgesetzt wird.
Sie werden informiert, wenn das weitergeht. Oder hier,
wenn das in die Richtung geht, sehr gerne Frau Schmidt,
leider passt dieser Antrag nicht in unser Konzept oder es ist
kein Budget dafür da oder sowas.
Deswegen kann er leider nicht umgesetzt werden. So,
das passiert, sagen wir mal, alle zwei Wochen und
hier tagt ein Gremium dazu, zwei, drei Leute.
Auf jeden Fall müsste er dabei sein, der das Geld gibt,
weil der ja entscheidet, ich bin bereit, das zu bezahlen
Und es muss jemand dabei sein von den technischen,
der die technischen Hintergründe kennt, meistens ein Architekt oder ein Projektleiter.
Ja, der bewerten kann, passt das denn inhaltlich zum Konzept?
So, dann landen so nach und nach ganz viele Dinge hier auf einem Stapel von beabsichtigten.
Wir stellen uns mal weiterhin vor, das wäre ein Papier.
Die gleichen Formulare sind dann alle hier. Und jedes Mal,
wenn eine neue Version gebaut werden soll, zum Beispiel,
sie machen alle zwei Wochen eine neue Version,
weil sie mit Sprintprints arbeiten und im Scrum-Modus.
Und sie machen alle drei Monate eine neue Version,
weil sie eher schwergewichtig mit Wasserfallmodell arbeiten.
Jedenfalls wird dann, wenn die neue Version geplant wird,
sagt man, was kommt in die neue Version alles rein.
Dann wird dieser Stapel von Papieren, die hier gelattet sind,
durchgesucht und dann wird geschaut, okay,
das kommt in die nächste Version, das kommt in die nächste Version.
Das kommt in die nächste Version. Die anderen bleiben hier. Bleiben hier,
wir können das noch durch einen Kreis auch durchaus noch sagen,
okay, es gibt noch diese Zustandsänderung, ja,
es kommt wieder in den gleichen Zustand.
Es bleibt im gleichen Zustand drin. Und dann müssen wir noch sagen,
ja, es kann auch vorsehen, wenn wir da irgendwas drin haben,
was da schon seit zwei Jahren liegt, muss sagen,
also liebe Leute, Jetzt zwei Jahre haben wir das nicht gemacht.
Wir sollten einfach das Rückgrat haben, zu sagen,
nein, wir machen es jetzt nicht mehr.
Also hier kommt dann wieder eine Nachricht raus.
Sehr geehrte Frau Schmidt. Wir müssen sie leider informieren,
dass ihre Änderungen, die sie 2018 beantragt haben,
dass die nun nicht mehr durchgeführt wird.
Es hat sich gezeigt, dass die nicht in unser Konzept
passt und dass dafür keine Priorität vorgesehen ist.
Bob, mit freundlichen Grüßen. Oder bleiben Sie uns gewogen
oder wie auch immer. So, also es landen dann
Dinge hier in dem Zustand beauftragt.
Beauftragt bedeutet, es wird wirklich ein Auftrag dafür geschrieben.
Wenn wir bei den Metaphern mit den Zetteln bleiben,
wird also ein paar Bierauftrag geschrieben. Den kriegt ein Entwickler
auf den Tisch. Bitte entwickle diese Kennzahl, dieses Formular,
diese Datenbank-Tabelle, was auch immer, baue das.
Und da steht dann auch noch drauf, das gehört zu der Version
1,5,13 und fertig zu sein, hat das am 13. September,
dann ist Ben ist Entwicklerschluss,
dann wird das alles zusammengepackt und einschließlich Test und Dokumentation blieb,
wie auch immer.
Und was dann passiert, ist, dass tatsächlich die Entwicklung stattfindet.
Auf diesem Pfeil hier findet alles statt, was wir als Entwicklung bezeichnen.
Wirkliche Anforderungen beschreiben, die Architektur entsprechend anpassen,
die Architektur entwickeln, implementieren, testen in Betriebnahme zusammenbauen.
Alles, das passiert, einschließlich der Installation. Wenn das
hier beauftragt wird, gibt es wieder eine freundliche Nachricht,
sehr geehrte Frau Schmidt. Wir freuen uns, Ihnen mitzuteilen,
dass das in der Version 1,5, 13 drin sein wird.
Die werden Sie vermutlich im Oktober erhalten. So,
wir informieren Sie weiter, wenn es neue Schritte gibt.
Und dann, wenn das hier angekommen ist,
dann heißt es, sehr gerne Frau Schmidt.
Wir freuen uns, ihn mitteilen zu können,
die Version 1,5, 13 wird übermorgen bei Ihnen installiert.
Und da ist ihr Feature drin. So,
also dann herzlichen Glückwunsch. Es ist fertig. Ja,
also die ganzen Entwicklungsschritte sind hier
Der wesentliche Kern ist, dass wir hier entscheiden,
wird es wirklich gebaut. Und dass wir hier entscheiden,
wollen wir es wirklich, will es jemand wirklich bezahlen.
Und es nur dann passiert, es wird hier einen Auftrag gegeben,
wenn das mit den anderen Aufträgen zusammenpasst.
Das ist im Wesentlichen ein Bestandteil. Und das war ein
kurzer Einschub zu Änderungsmanagement. Das betrifft alle Teile, die
wir als Änderungen haben. Und wie wir hier gesagt haben,
für diesen Abschnitt, die tatsächlich betrifft das aller Entwicklungsphasen.
Aber vor allen Dingen geht die Änderung natürlich von Anforderungen aus.
Für Bugs wurde übrigens das Gleiche passiert. Auch ein Bug würde
hier vorne irgendwie landen und die Bugs werden dann auch geprüft,
welcher kommt dann in die nächste Version.
Und wenn das ganz dringend ist, macht man auch mal eine Sonderversion.
Soweit die Beantwortung der Frage, was ist das Änderungsmanagement,
wozu ist das erforderlich?
Weiter geht es jetzt wirklich mit Aktivitätsdiagramm