Im Kapitel 6 geht es uns darum, wie man
Re-Engineering-Prozesse steuert und wie man sie in die Organisation einbindet.
Es geht ja nicht nur um das Technische Allein,
sondern es geht darum, erfolgreich in großen Projekten zu arbeiten
und wenn viele Menschen zusammenarbeiten müssen, ist Organisation ein erfolgskritischer Faktor.
Da ich nicht davon ausgehen kann, dass jeder,
die genauso viel zu Projektmanagement weiß,
habe ich hier den Abschnitt 6.1 eingeführt,
wo ich kurz einmal etwas über Projektmanagement sage,
ein paar grundlegende Worte für die,
die das noch nicht in ihrem Studium
in irgendeiner Form hatten
Wir werden dabei auf die Fragen eingehen. Zunächst erst mal
etwas, was Projektmanagement umfasst. Typischerweise hat Projektmanagement das Ziel
, Projekte erfolgreich durchzuführen. Das heißt, dieses Führen,
der Begriff Management steht für das Führen eines Projektes.
In manchen Firmen wird das auch so ein bisschen als Verwalten gesehen.
Also ich verwalte das Budget und so weiter.
Es geht hier um das Führen. Führen im Sinne von erfolgreich
die Ziele erreichen. Das passiert. Der Projektleiter ist typischerweise
die Rolle, die das ausführt
Projekte, der kümmert sich darum, Ziele vorzugeben, diese Ziele zu kommunizieren,
vom Auftraggeber an das Team umzusetzen auf die verschiedenen Beteiligten,
ihre detaillierten Aufgaben beziehungsweise sogar Spezialisten.
Und darum die Arbeitsmöglichkeit des Teams zur sicherstellen,
also der ist sozusagen Dienstleister des Teams, im Sinne von Bereitstellen von Ressourcen.
Neben dieser Dienstleisterrolle ist er für die Führung verantwortlich,
Führung ist jetzt also nicht unbedingt jemand, der,
ich bin hier der große Diktator und ich sage jetzt jeden Morgen,
jeden, der was gemacht wird, nein,
es geht vielmehr darum, die Zusammenarbeit zu verbessern,
Kommunikation herzustellen, natürlich dafür zu sorgen,
dass die Motivation erhalten bleibt.
Wenn erstmal die Motivation da ist, ist ganz schlecht.
Motivation kann man nämlich ganz schwer nur erzeugen. Und gleichzeitig
spielt natürlich der Aspekt der Erfolgskontrolle auch eine wichtige Rolle.
Außerdem ist die Aufgabe des Projektleiters die Tätigkeiten in der Arbeitsteilung zu koordinieren.
Ja, also er muss dafür sorgen, nicht nur,
dass die Voraussetzungen wie solche Ressourcen, sowas,
dass sie gegeben sind, sondern auch, muss berücksichtigen,
welche Abhängigkeiten zwischen zwei Tätigkeiten sind.
Zum Beispiel, wenn die Tätigkeit B nach der Tätigkeit A ist,
dann muss, wenn B, ein F entsteht,
muss er dafür sorgen, dass das zeitlich so liegt,
dass da die Tätigkeit,
die Ergebnisse von A zur Verfügung steht
Für diese Kontrolle muss ja die Prüfungen organisieren,
dass die entsprechend getan werden, gemacht werden.
Und natürlich, dass das Budget und der Termin eingehalten werden.
Die wesentlichen Tätigkeiten des Projektleiters sind nicht etwa mit Tools tolle Pläne zaubern.
Das mag vielleicht auch noch eine gewisse Rolle spielen.
Das Wesentliche ist die wesentliche Tätigkeit besteht darin, Informationen zu
vermitteln und selbst zu kommunizieren. Solche Kommunikationen in verschiedene Richtungen,
das hatten wir hier trüben ja schön auf der linken Seite schon dargestellt.
Vor allen Dingen die Gespräche mit dem Auftraggeber, mit der eigenen Geschäftsführung,
des Softwareentwicklungsunternehmens, muss man es hier zu nennen,
wo es darum geht, entsprechend zu informieren,
was ist denn da passiert, über Probleme zu informieren,
bis auch hin, das voll Probleme,
die dann nicht auf Ebene des Projekts lösen kann,
dass man die auf der darüber liegenden Ebene oder durch Kooperation,
durch Kommunikation mit dem Auftraggeber löst.
Und natürlich diese Aufgaben der Teamführung, die wir hier drüben
stehen haben, das sind auch wichtige Aufgaben eines Projektleiters.
Hinzu wird das es nicht zu vergessen,
häufig gibt es Dinge, wo es nicht so einfach ist,
eine Lösung herbeizuführen,
dass Interessenkonflikte oder technische Konflikte gibt
Interessenkonflikte können zum Beispiel sein, dass die Vermittlung zwischen verschiedenen Konkurrenten,
Zielen zu erreichen ist, also Ziele Richtung Qualitätsziele.
Ich kann nicht Performance und Speicherplatz. Gleichzeitig optimieren oder wenn ich,
kann ich die Qualität steigern und schneller sein und weniger Budget haben.
Also irgendwo muss ich solche Konflikte dann lösen,
auch besehen, Konflikte zwischen Menschen.
Manchmal muss man da vermittelnd eingreifen und der eine meint,
der hat mir, schuldet mir noch was und der andere sagt,
nee, jetzt bist du aber mal dran.
Da muss man manchmal auch noch sagen, liebe Leute,
wir sind gemeinsam hier um das Projekt auf Erfolgreich
durchzuführen.
Wir müssen jetzt hier zusammenarbeiten
Tatsächlich gibt es einen Bereich von der Tätigkeiten des Projektleiters.
Entschuldigung, dass ich das hier so ganz kurz plakativ zusammenfasse.
Aber der dritte Bereich, den ich hier nenne,
der ist, da geht es um die Projektplanung und das
ist tatsächlich was, wo Tools auch helfen können.
Zum Beispiel für die Aufwandsschätzung ist es sinnvoll,
Daten aus vergangenen Projekten aufzubereiten, zusammenzurechnen, Ähnlichkeiten abzuschätzen,
Abschätzung der Sicherheit der Schätzung könnte man dafür machen,
um bessere Kapazitäts- und Terminplanung machen zu können
Für Kapazitäts- und Terminplanung ist eine Menge Abhängigkeiten zu beachten.
Zum Beispiel, es gibt bestimmte Spezialisten im Projekt, die man am liebsten fünfmal hätte.
Ja, und dann muss man aber das irgendwie so koordinieren,
dass deren Arbeitsleistung immer dann zur Verfügung steht, wenn sie gebraucht werden.
Das wäre also Kapazitätsplanung. Gleichzeitig möchte man das nicht,
dass irgendjemand Leerlaufzeiten hat, zwischendurch mal drei Tage nichts zu tun hat.
Ja, ich meine, da beschäftigt sich schon,
aber es kostet ja Geld. Also das heißt,
wir wollen versuchen, dass jeder immer Aufgaben hat,
die ihn auslasten und natürlich nicht möglichst, nicht zu viel.
Die Terminplanung basiert natürlich auf so einer Aufwandsschätzung,
gleichzeitig der Auftraggeber, die Gewährleistung, die Einhaltung von vereinbarten Endterminen.
Das ist also auch eine ganz wichtige Tätigkeit des Projektleiters. Er muss dafür sorgen,
während des Projektes, und das nennt man beim Plan,
Verfolgung, nachdem der Plan aufgestellt worden ist,
es ändert sich ja immer etwas, dass man dann schaut,
okay, wenn ich hier etwas ändere, kann ich es schaffen,
den Endtermin noch einen aufrechtzuerhalten oder wenn nicht, wann ist denn die Prognose, wann wird das Projekt beendet sein.
Also das sind diese Folie, zeigt so kurz mal
ein paar Tätigkeiten des Projektleiters und jetzt würden wir den Schwenk
zurückmachen,
zu Re-Engineering-Aufgaben
Dazu, wir hatten hier ein paar Fragen,
Ziele des Re-Engineering aus Projektmanagement-Sicht. Wir haben diese,
was muss Projektmanagement denn leisten, beziehungsweise was braucht Re-Engineering?
Ich würde dazu mal hier mit einer neuen Folie starten,
einmal Gewehrformat.
Also,
da machen wir natürlich
einen Stift
Diese Ziele des Projektmanagements bei Re-Engineering haben natürlich mit den Voraussetzungen
zu tun. Als erste Voraussetzung möchte ich hier nennen,
die Komplexität
Komplexität kann man, ich schreibe hier Komplexität verringern.
Super. Ja, wenn das gelingt, der muss
ein Maria sein. Tatsächlich, wenn wir Projekte haben,
die komplex sind, dann wird es uns nicht gelingen,
deren Komplexität auf ein ganz kleines Maß zu verschumpfen.
Aber alles, was zusätzliche Komplexität ist, die hinzukommt,
dass wir komplizierte Verflechtungen haben,
dass wir Abhängigkeiten haben,
dass wir
das versuchen zu verringern
Keine zusätzliche Komplexität durch Abhängigkeiten. Im Sinne der Fragen,
für die wir hier als Frage eins formuliert haben,
gehe ich gleich mal von der Priorität,
gebe ich gleich mal meinen Antworten eine gewisse Priorität.
Und zwar wäre der nächste Punkt aus meiner Sicht,
dass wir Risiken minimieren, Und zwar,
indem wir die Risiken behandeln,
man sagt meistens von Risiken und Auflösen, Risiken ermitteln,
nicht für,
sondern doch für größte Risiken
Man macht also eine Risikoanalyse für ein Projekt und stellt fest,
die und die organisatorischen, technischen Risiken,
also das kann von technischen Risiken, ob man weiß nicht,
ob das und das zusammenspielt oder ob das zur Verfügung steht,
über organisatorische Risiken, man kann sich noch nicht vorstellen,
ob man da, ob der Support reicht,
den man da bekommt oder ob der einen Vertrag abgeschlossen werden kann mit einem wichtigen Partner,
den man aber braucht,
um die Lösung gemeinsam zu machen.
All solche Sachen können Risiken sein und das Projektmanagement muss sich
um solche Risiken kümmern, als drittwichtigsten Punkt muss ich,
möchte ich hier nennen,
die Verringerung von Kosten oder Begrenzung
von Kosten
Und um diese Ziele zu erreichen,
sind Maßnahmen in Bezug auf Free-Engineering,
sind vor allen Dingen die Dinge,
die wir beim Reengineering ja als klassisches Ziel bezüglich Verbesserung der Wartbarkeit erreichen wollen.
Das wäre zunächst Struktur verbessern, womit wir das Projektmanagement vereinfachen,
womit wir es schaffen, dass wir weniger Komplexität haben,
wenn wir
die Struktur verringert haben
Das Gleiche trifft zu für das Zeitverhalten. Oder die Zuverlässigkeit,
Marktbarkeit sowieso, das, vielleicht schreibe ich hier nochmal die Wartbarkeit, als übergeordnetes Ziel hinzu.
Diese Qualitätseigenschaften, wir können noch beliebig viele weitere fortsetzen,
sind vor allen Dingen dann kritisch, wenn das Wichtige Erfolgskriterien sind...
Ich bitte hier, nein, das muss ein bisschen,
ein bisschen besser geht das noch, Kriterien.
Oder wenn das Risiken sind, ja,
also das sind die wesentlichen Maßnahmen, die das Projektmanagement hier fördern kann,
wo es darum geht, einfach das Re-Engineering klassischerweise so durchzuführen.
Für dieses Bring, das sollte ich nicht,
sollte ich wirklich nicht malen, sondern ich wollte dir nur was zeigen.
Dieses Projektmanagement, Ziele schlagen da natürlich voll durch, dass wir die Maßnahmen entsprechend machen. Ich möchte ganz,
möchte wieder daran erinnern, dass die Herausforderung immer darin besteht,
dass Re-Engineering etwa nichts ist,
was direkt sichtbaren Wert für den Kunden zu bereitstellt,
weil es eigentlich erst auf die lange Frist auszahlt,
indem man ein System wartbar erhält in diesem Wiederbezug auf das Stage-Model,
in dem Zustand Evolution, können wir das System halten durch Re-Engineering,
ja, und das ist nichts,
wo der Kunde direkt sofort ein Feature hat,
eine Ergänzung,
eine Umsetzung eines Wunschs oder so etwas
Lassen Sie uns als nächstes zu Aufwand und Nutzen etwas sagen.
Für die Frage Aufwand und Nutzen spielt natürlich die Rolle,
was ist Aufwand, was ist Nutzen.
Wir gehen mal... Achso, ich wollte gerne erst noch
was sagen zu den Risiken. Zu den Risiken beim Reingenieuren
gehört ganz besonders so ähnlich wie zu den Risiken bei Softwareentwicklungsprojekten
allgemein,
dass wir
unter Unsicherheit entscheiden müssen
Im Projektleiter APC lernt man, wenn man als Bruce-Anfänger da
in irgendwelche Kurse gesteckt wird, die Bedeutung von Entscheidungen.
Ja, es gibt nichts Schlimmeres als eine unterlassene oder spätere Entscheidung.
Falsche Entscheidungen sind nicht ganz so schlimm. Also das heißt,
auch wenn wir Unsicherheit haben, die Entscheidung wird jetzt gebraucht,
dann müssen wir jetzt entscheiden aufgrund der aktuellen Sachlage.
Und deswegen ist es immer ganz wichtig zu überlegen,
was brauche ich jetzt,
was habe ich zur Verfügung und ich entscheide jetzt aufgrund der aktuellen,
des aktuellen Kenntnisstands, aber ich entscheide.
Ich kann die Entscheidung selten offen lassen,
weil dann der Schäden die Nachteile
viel größer sind
Ich habe deswegen hier mal auf einer Folie zusammengesetzt,
wie kann man das am Ende, wie läuft Entscheidungsentscheidungen ab?
Das ist ja das, was der Projektleiter,
genauso wie der Architekt, da täglich zu tun haben.
Insofern trifft es auch für das Reengineering zu,
nicht nur für das Projektmanagement. Eigentlich läuft das so,
dass man zunächst analysiert, was sind überhaupt die Ziele?
Gibt es dabei Widersprüche? Und dann ermittelt,
was könnten denn mögliche Lösungen sein?
Und dann aufgrund der Bewertung der Lösungen bezüglich bezüglich der Ziele
ermittelt,
wie machen wir es dann
So klingt das erst mal total straightforward, aber tatsächlich ist es so,
dass wir viele häufig das so antreffen in der Praxis,
dass Entwickler, dass sie Entscheidungen unbewusst treffen.
Sie reflektieren nicht, sie kriegen nicht mit, ah,
ich treffe jetzt eine Entscheidung und nochmal drüber nachdenken, ja, gibt es denn Alternativen?
Nein, das ist so, das machen wir so und so.
Ja, so quasi, das haben wir schon immer so gemacht.
Das ist weniger Sturheit, sondern einfach, man bemerkt nicht,
dass man hier gerade eine Möglichkeit hat,
nach Alternativen zu suchen und manchmal gibt es ja bessere Alternativen.
Aber indem man sich das bewusst macht, also ich treffe
jetzt hier eine Entscheidung, Und was sind denn überhaupt die Ziele?
Gibt es da Widersprüche oder wie auch immer,
häufig tritt es so ein, dass gerade erfahrene Praktiker,
die finden, sehen etwas und haben sofort eine Idee,
wie die Lösung sein könnte und überlegen gar nicht erst mal,
ob es noch weitere Ziele gibt oder ob es noch weitere Alternativen gibt,
um dazu am Ende zu kommen,
dass man eine vielleicht bessere Lösung als die aktuelle,
als die erste Idee finden kann.
So, das Ganze findet natürlich ständig statt,
also so klar aufgedröselt, wie wir das jetzt hier in
dieser Folie haben oder vielleicht gar nicht mit diesem Ablauf.
So wird man das in der Praxis kaum machen,
weil man die Zeit dafür häufig nicht aufbringen kann
Sondern man muss einfach relativ schnell ermitteln,
dass ich muss eine Lösung haben, die kann dann die Lösung raussehen,
dann muss ich die Lösung noch ausprobieren, ob sie den trägt.
Und dann setze ich sie um. Und das,
aber das ist ein Weggangswesen der Punkt und deswegen möchte ich drauf kommen,
ist, dass einem überhaupt bewusst wird,
dass es hier eine Lösung gibt, eine Entscheidung gibt,
dass wir möglicherweise verschiedene Ziele, verschiedene Ziele haben,
die wir erstmal analysieren müssen und dass wir versuchen sollten,
Alternativen in auch noch aufzustellen.
Und das kann dann passieren, wir können natürlich hier noch
Leute zur Hilfe nehmen, irgendwelche Stakeholder Und dann,
wir haben hier in diesem Bildchen von Seekord, ja,
weil ihr und ihn, wir finden eine Zielstruktur und dann
ein Weg dorthin und dann machen wir das so,
ich nehme da eine Struktur auf.
Das sind jeweils Entscheidungen drüber drin, ja,
also hier ist eine Entscheidung drin, hier sind Entscheidungen drin,
hier sind Entscheidungen drin und dann machen wir irgendwie ein Projektvorgehensplan, um das durchzuführen.
Okay, ich hatte hier noch eine weitere Folie drin,
die uns auch noch einen Punkt geben,
in Bezug mit Konfigurationsmanagement sieht, sehen kann,
uns sagt, wo es um Änderungen geht,
die Aufgabe von Konfigurationsmanagement sind Änderungen zu koordinieren.
Also hier unten steht es unter Ziel.
Wir wollen Routinetätigkeiten automatisieren, um dem wir Fehler vermeiden.
Aber eigentlich geht es darum, Änderungen zu steuern.
Ich markiere das mal hier rot.
Es geht häufig dabei Änderungen, Steuern
Das ist wieder dieser Begriff Management, den ich gerne mit Steuerung übersetzt haben möchte. Ja,
es gehören mehrere Teilaufgaben dazu, ich muss identifizieren,
was sind denn überhaupt Elemente, Ergebnisse meines Prozesses,
die werden häufig in diesem Umfeld als Produkt bezeichnet,
wie geht läuft Änderungen ab dazu, gleich die nächste Folie,
dass wir am Ende Fertigmeldungen oder sowas sagen,
das ist wirklich abgeschlossen, das ist geprüft,
dass wir die an den Projektleiter geben und dass wir das Bild,
die Bildprozesse steuern, ja, das ist, und das hilft uns,
dass man Arbeit nicht nochmal machen muss, dass man Änderungen koordiniert hat,
dass man am Ende immer lauffähige Konfigurationen irgendwo hat,
zum Projekten, zum Änderungsmanagement, auch für diejenigen von ihnen,
die sowas noch nicht irgendwie gehört haben, die,
die hier besser gemacht haben,
haben das möglicherweise von mir gehört.
Ich möchte kurz, ich habe hier zwei Zustandsdiagramme mal zusammengetragen,
die stammen weiter aus dem Vorgehensmodell mit dem Namen V-Modell,
was für deutsche Behörden die Anwendung findet,
und zwar zum Änderungsmanagement im Sinne von Schutz von Veränderungen, Fritz vor Veränderungen.
Wir wollen Änderungen koordinieren und ungewollte Veränderungen haben. Und hier sieht das so aus,
dass zum Beispiel, wenn es ein Änderungswunsch gibt,
das kann ein Ticket sein, das kann ein Kundenwunsch sein,
ein Change Request, dann ist er zunächst im Zustand beantragt.
Und dann kann man vielleicht den, wird gleich entschieden in einem Gremium,
wo der Auftraggeber auf jeden Fall mit dabei ist, der das bezahlt.
Und der Architekt auf jeden Fall auch als jemand,
der einschätzen kann, kann das umgesetzt werden, mit welchem Aufwand.
Da kann entschieden werden, so ein Erinnerungswunsch wird abgelehnt oder
so ein Änderungswunschwort wird gesagt, ja okay, wir wollen das irgendwann tun.
Und dann, wenn wir, jedes Mal,
wenn wir eine neue Version planen, Dann würde man diesen Stapel von Änderungswünschen,
die auf diesem hier die unteren Zustand beabsichtigt sind, anschauen,
würde sagen, okay, was kommt denn in die nächste Version?
Das wäre dann, ich beauftrage den,
also es gibt einen Arbeitsauftrag an irgendeinen Entwickler oder wenn es dann,
wenn wir da merken, okay,
da gibt es Änderungsbudgets in den zwei Jahren da in meinem Stadion,
immer weil die Priorität zu niedrig,
wir sollten uns heute mal dazu durchringen, zu sagen,
also wir werden das nie tun.
Ja, und dann würde man jeweils,
jeder Pfeil ist mit einer Information des Erstellers,
des Vorursachens, dieses Change-Requests dann verbunden,
der würde der Ursache dann kriegen, Herr Müller oder Frau Schmidt,
Ihr Änderungsmensch von so und so vielen wurde leider abgelehnt.
Der wird in der, wird in dieser Version nicht durchgeführt oder wenn es hier hingeht,
kriegt sie die Informationen, also Frau Schmidt, ihre Änderungsbunde.
Vielen Dank dafür. Der wird jetzt in der Version Mitte September ausgeliefert. Ja,
dann gibt es den Arbeitsauftrag an den Entwickler und der Entwickler
macht dann alles aus diesem Punkt vom Übergang zwischen diesen Motiven,
stehen die ganzen Softwareentwicklungstätigkeiten, stecken hier drin in diesen kleinen Pfeilchen,
also Anforderungsanalyse, Entwurf, Integration, Test, Deployment und so weiter.
Und wenn das Deployment erledigt ist, die Version ist beim Kunden,
würde die Frau Schmidt wieder eine freundliche Mail kriegen vom Konsumationsmensch oder vom Projektleiter und sagen,
Frau Schmidt, ihr Change Request, der ist jetzt in der Version,
die ab seit heute Nacht bei Ihnen auf dem Rechner installiert ist.
Da ist sie Dortmund dort zu finden. Also so wird Silber
in Änderungen im Wesentlichen im Kern werden Änderungen so organisiert.
Das kann natürlich noch aufwendiger sein, indem man noch weitere Entscheidungsgremium gibt.
Hier gibt es also eine Entscheidungsgremium,
wo das Change Request Man Award könnte das zum Beispiel sein
oder hier ist das Versionsmanagement,
was die Entscheidung trifft
Im gleichen Zusammenhang, also das ist ein Diagramm,
ich habe deswegen einen fetten roten Strich dazwischen gemacht,
damit sie das nicht denken, das Gehör zusammen.
Es gibt aber ein zweites Zustandsdiagramm und das wollte ich einfach
auch noch mit ihnen mitgeben. Und das würde ich jetzt
auch gleich noch besprechen. Und zwar geht es darum,
um den Schutz vor Veränderungen für ein Teilsystem,
ein Teilergebnis, ein sogenanntes Produkt.
Also man benimmt den mit Produkt hier nicht nur für fertig,
sondern auch zum Beispiel ein Testfall,
ein Testprotokoll ist ein Produkt oder ein Antwortungsbeschreibung ist ein Produkt.
Alles, was irgendwie entsteht,
das neudeutsche Wort dafür wäre,
vielleicht Artefakt,
also vom Menschen gemacht
So, und es gibt für jedes,
nehmen wir mal durchaus eine Antwortungsbeschreibung, ja, man sagt,
okay, irgendwann, wir sollten eine Antwortungsbeschreibung haben für dieses Projekt.
Ja, dann ist es nur geplant, das gibt die aber noch nicht.
Dann gibt man den Arbeitsauftrag, dass jemand diese Arbeit,
dieses, Requireanforderungsdokument schreibt. Und dann ist es in Bearbeitung,
ja, dann ist derjenige nach, sagen wir mal,
nach acht Wochen Arbeit, ist derjenige fertig oder ein kleines Team.
Und dann ist das, wird das vorgelegt und zwar vorgelegt im Qualitätsmanager,
demjenigen, der die Abnahme macht, vielleicht auch einen Kollegen,
der eine Abnahme macht, da findet zum Beispiel ein Review,
Antwortungsbeschreibung statt.
Und dann gibt es zwei mögliche Ergebnisse. Das eine sagt super
, ist fertig. Ja, aber das andere sagt,
nein, also liebe Leute, bitte nochmal das und das nachbessern.
Und das hier bindet also mit dem Zustand, hier findet die Qualitätsprüfung statt.
Und danach, wenn man es fertig hat, ist es akzeptiert,
es wird freigegeben. Interessant ist jetzt in dem Zusammenhang,
deswegen verhandeln es wir jetzt mit nach dem paar Worten über Konfigurationsmanagement,
dass man hier gibt es wieder Schreibzustand, Schreiblesezugriff aussieht.
Ja, also hier gibt es noch nichts,
wo ich schreibe, da lesen darauf zugreifen kann,
darf der Entwickler lesen, darauf zugreifen.
Für alle anderen ist es noch nicht da.
Hier darf nur das Qualitätsmanagement lesen, darauf zugreifen.
Der Entwickler kann nicht mehr noch was nachbessern.
Der hat es ja vorgelegt, ist fertig.
Und die anderen bekommen es aber noch nicht.
Während hier in dem Zustand ist es auch schreibgeschützt.
Also der Entwickler kann nicht einfach was ändern.
Aber die anderen alle können es zugreifen.
Das ist normalerweise dieses eingecheckt ist hier. Und hier,
um etwas zu bearbeiten, würde ich es dann vielleicht auch auschecken.
Also das wäre dieses Änderungsmanagement, die Einbindung von Qualitätsmanagement,
nämlich genau die Entscheidung an diesem Punkt
Einschätzung, die Qualitätsmanagement für Änderungen. So,
damit möchte ich zur nächsten Frage,
also das war nochmal so ein bisschen zum Projektmanagement und wir
hatten hier noch die Frage, Aufwand und Nutzen.
Zu der möchte ich jetzt kommen.
Dazu brauchen wir
ein neues Blatt
So. Und zwar haben wir hier Aufwand.
Aufwand nutzen. Wir möchten über Aufwand und Nutzen nachdenken.
Beim Aufwand ist das, oder Kosten-Nutzen-Verhältnis aufwand,
Nutzenverhältnis ist jetzt für mich mal das Gleiche.
Da würde man
eine Aufwandsschätzung machen
Aufentschätzung macht man klassischerweise so, dass man entweder die Erfahrungen,
also in Erfahrungen sagt, das werden ein vergleichbares Projekt,
das war so und so umfangreich.
Oder dass ich die Aufgabe zur legenden Teilaufgaben für die,
die Aufwände bekannt waren
Zurückführen auf Teilaufgaben mit bekanntem Aufwand. Und ansonsten könnte man noch sagen,
so ganz allgemein ohne ein konkretes Projekt zu haben, könnte man sagen,
dass der Aufwand abhängig ist von einer Reihe von Faktoren.
Zum Beispiel Wie ist denn die Wartbarkeit? Wartbarkeit war ja
genau das Maß für den Aufwand, für Änderungen.
Dazu gehört Verständlichkeit, Qualität der Struktur bzw. des Entwurfs,
wobei man jetzt noch mal ausführlicher sagen könnte, was Entwurfsqualität jetzt ist,
Der Umfang oder die Anzahl der Beteiligten, Elemente.
Also wenn wir ganz viele abhängige Teile haben,
die betroffen sind, dann ist das natürlich ein höherer Aufwand.
Das wäre soweit auf der Aufwandsseite und auf der Nutzenseite
könnten wir sagen, dass wir Verbesserungen der Wortbarkeit,
Unwartbarkeit sind ja wieder Aufwand für Veränderungen.
Und dabei geht es um Verringerung zukünftiger. Aufwände. Das
ist ja ein Nutzen, den wir so sehen können.
Das wäre einer der Punkte des Nutzen,
dann Verringerung technischer Schulden
Dazu werden wir noch was sagen,
was Technical Debt ist,
über technische Schulden sind und damit wäre das Verbesserung,
das wäre eine Möglichkeit oder es trägt dazu bei,
dass wir
die Fortbarkeit insgesamt verbessern
Außerdem kommt es dazu, dass wir Nutzen erreichen,
dadurch, dass wir den Umfang von Software verringern,
falls falls wir Clones entfernt haben, Oder dass wir Totenkot entfernt haben.
Das wäre auch noch ein Nutzen, den wir insgesamt erreichen.
Aber der wesentliche Punkt ist der,
den wir hier ganz am Anfang haben,
die Verbesserung der Wartbarkeit trägt direkt dazu bei,
dass wir zukünftige Wirtbarkeits-, zukünftige Änderungsmaßnahmen sehr viel besser durchführen können.
So, das wäre also Aufwand und Nutzen. Hier steht noch
die Frage zusammensetzen, das sollten wir hier mit hinzufügen,
zusammengesetzt ist das Das scheint mir das mutiert mit dem Turndaum.
Im Wesentlichen nennt es sich hier um Zeitaufwand. Das müssen wir
also sagen. Und hier Und hier ist Verängerung von zukünftigem Aufwand,
ist einer der Punkte und weitere Punkte,
die wir vorher schon besprochen hatten, war Verringerung von Risiken.
Und als letzten Punkt möchte ich noch nennen,
Verringerung der Entwicklungszeit. Entwicklungsdauer, hier stört der Dozent,
den schieben wir mal weg
Wenn ich die mal zu hoch. Ja,
also die Verringerung von Risiken und die Empfängerung von Entwicklungsdauer
gehört hier auch mit zum Nutzen,
den wir erreichen können