So, also, einen guten Morgen allerseits.
Wir bewegen uns in der Vorlesung Softwaretechnik jetzt auf die
Zielgerade zu.
Wir haben ja nur noch diese Woche und ich muss ehrlich sagen, mir
fehlt ungefähr ein Tag.
Die Puzzler, die Java-Rätsel haben mir doch ein bisschen viel Zeit
gekostet.
Jetzt lasse ich sie in den nächsten zwei Tagen weg.
Wir haben zwar noch welche und wenn wir dann nächsten Mittwoch noch
Zeit haben, dann mache ich einen, aber ich fürchte, wir werden keine
Zeit haben.
Ich werde also heute ein bisschen schneller vorgehen, aber das Thema
ist auch gar nicht so kompliziert.
Was wir also noch machen müssen ist, die Abnahmephase haben wir jetzt
gesehen, jetzt kommen wir zur Wartungsphase, das machen wir heute noch
fertig und dann kommt die Schätzmethoden.
Ich hoffe, dass ich die noch zum Guteil heute schaffe.
Und der letzte Tag ist dann für die verschiedenen organisatorischen
Modelle, die sogenannten Prozessmodelle, reserviert, wo wir etwas
hören, wie zum Beispiel über Scrum oder XP oder auch Prototypmodelle
und sowas.
Also jetzt fangen wir hier gleich an mit der Wartungs- und
Pflegephase.
Die beginnt einfach definitionsgemäß ab dem Tag oder Augenblick, wo
die Software erfolgreich abgenommen wurde und vom Kunden eingesetzt
wird.
Ob sie komplett richtig ist, ob sie nicht noch erweitert werden muss,
ob nicht noch Nacharbeiten zu machen sind, ist da unerheblich, sondern
hier definiert man ganz knallhart, sobald es der Kunde einsetzt,
beginnt die Wartungsphase.
Was passiert jetzt, wenn die Software in Betrieb ist?
Naja, als erstes soll es vorkommen, dass Versager auftreten, die
Software abstürzt oder sonst irgendwie Mist macht.
Es ändern sich die Umweltbedingungen, Umgebungsbedingungen, es kommen
zum Beispiel neue Geräte hinzu, neue Arten von Speichermedien,
Speicherstifte, neue Schnittstellenarten, neue Systemsoftware, neue
Hardware, neues Betriebssystem, neue organisatorische Einbettung,
plötzlich gehört die Firma einer anderen.
Oder es entstehen Wünsche und Anforderungen im Gebrauch, insbesondere
sagen dann manche Kunden, aber es wäre doch noch schön, wenn wir die
Funktion auch noch hätten und das hier fehlt, das ist aber ganz, ganz
wichtig.
Es war zwar in ursprünglichen Anforderungen nicht vorgesehen, aber das
wäre dann eine neue Funktion, die hinzugefügt werden muss.
Das ist dann eher eigentlich eine fortgesetzte Entwicklung.
Es können sich die Benutzungsoberflächen ändern, da sagen Leute
plötzlich, aber jetzt brauche ich auch eine mobile App dazu, oder ich
brauche eine Schnittstelle, die auf Sprache reagiert, oder ich muss
jetzt endlich die Daten auch auf einer Web-Schnittstelle zugreifen
können.
Oder es kommen, das ist natürlich auch eine zusätzliche
Funktionalität, die ursprünglich nicht da war, oder aber das System
ist zu langsam.
Oder die Leute, die Benutzer, benutzen es für so große Datenmengen,
dass man die Geschwindigkeit erhöhen muss, die Kapazität der
Speicherung nicht ausreicht und so weiter.
Es gab zum Beispiel Zeiten, da konnte Word nicht eine gesamte
Diplomarbeit packen, sondern sie mussten das in Einzelkapitel zerlegen
von ungefähr 20, 30 Seiten, dann konnte Word das auch tatsächlich
setzen.
Das ist so ein Fall von nicht vorgesehen für große Dokumente gewesen.
Und das hatte ich schon mehrfach erwähnt, man spricht auch von der
Alterung von Software, obwohl sich Software natürlich nicht abnützt.
Wie ein physisches Projekt, wie zum Beispiel ein Auto, das nach so und
so vielen Jahren einfach abgenutzt ist, kaputt ist, Lager sind locker,
Dichtungen sind nicht mehr dicht, Türen schließen nicht mehr richtig
und so weiter.
Passiert bei Software ja überhaupt nicht.
Die Software ist so gut oder schlecht am ersten wie am letzten Tag.
Aber was sich ändert, ist die Umgebung dieser Software.
Sie kann plötzlich nicht mehr für den vorgesetzten Zweck eingesetzt
werden, weil sie mit anderen Systemen, die sich geändert haben,
wegentwickelt, fortentwickelt haben, nicht mehr zusammenpasst.
Sie alle kennen das, sie installieren eine neue Software.
Und dann heißt es aber, sie müssen auch noch dies und das und jene
andere Bibliothek nachziehen.
Im Englischen gibt es den Begriff DLL-Hell.
DLL ist Dynamically Loaded Libraries.
Das ist eine Software, die automatisch zugeladen wird zu einer
bestimmten Anwendung.
Und davon gibt es dann möglicherweise auch vier, fünf verschiedene
Versionen.
Und plötzlich laden sie eine neue Software, die läuft aber nicht.
Und dann gibt es eine alte Software, die eigentlich die ursprüngliche
Version gebraucht hat, die läuft jetzt mit der neuen nicht.
Also solche Dinge führen eben dazu, dass die Software nicht mehr
benutzt werden kann oder aber sie kaufen sich überhaupt einen neuen
Rechner und sagen, ich habe aber da noch eine Lizenz dafür, die will
ich jetzt auf diesem Rechner ausführen können.
Und das kann auch sein, dass das nicht klappt.
So, das heißt also, irgendwann mal ist Software so veraltet, dass sie
unbrauchbar ist, wenn sie nicht beständig erneuert, nachverbessert,
gewartet wird, gepflegt wird, müsste man eigentlich sagen.
Von der Wartung und Pflege, da gibt es jetzt mehrere unterschiedliche
Kategorisierungen, es sind alle nicht schwierig zu verstehen, aber Sie
brauchen mal wieder die Begriffe dafür.
Da spricht man zum einen von korrektiven Tätigkeiten, nämlich die
sogenannte Stabilisierung oder Fehlerkorrektur und der Optimierung
oder der Leistungsverbesserung, das war unser letzter Punkt von der
vorigen Folie, das werden als die korrektiven Tätigkeiten angesehen.
Und dann gibt es die progressiven Tätigkeiten, die damit zu tun haben,
die Software in die Zukunft hinein zu verbessern, für die Zukunft
anzupassen, da gibt es Anpassungen, Änderungen und natürlich
Erweiterungen.
Okay, sollte eigentlich alles klar sein, was da draufsteht,
Stabilisierung und Korrektur dient dazu, Defekte zu beheben.
Es kann gut sein, dass die Defekte ursprünglich in der ersten
Entwicklung beim Systemtest oder Modultest nicht entdeckt wurden.
Es kann auch sein, dass sie in der Wartung erst entstanden sind.
Und das ist gar nicht so unüblich, man spricht etwa von einem in zehn
entstehenden Wartungen.
Jetzt zeige ich Ihnen einige erschreckende Faustregeln.
Die sagen, 10.000 Zeilen Code sollte man ungefähr mit 75 Defekten
rechnen, die ausgeliefert werden.
10.000 Zeilen ist nicht so viel, das sind ungefähr 20 Seiten,
Bildschirmseiten voll.
Und da sitzen noch 75 Defekte drin, das heißt, wenn Sie gleich
ausrechnen, auf jeder Seite drei, vier Stück.
Und davon werden die meisten erst im Betrieb festgestellt und diese
Defektbeseitigung verursacht erhebliche Kosten.
Und diese Lokalisierung und Behebung dieser Restdefekte ist natürlich
klar, das sollte eigentlich Teil der ursprünglichen Entwicklung sein,
wird aber in der Wartungszeit durchgeführt.
Diese Behebung dieser Restdefekte bezeichnet man manchmal aus Wartung
im engeren Sinn, also diese Teil der korrektiven Tätigkeit.
Second Level Defects, das sind diejenigen, die in der Wartung
eingeführt werden, entweder bei der Korrektur oder auch bei den
Erweiterungen und Anpassungen.
Wir können ziemlich rasch die Mehrzahl der Defekte ausmachen.
Und die Ursachen sind natürlich schlechte Konstruktion, schlechte
Strukturierung der ursprünglichen Software.
Sodass Leute, die die Wartung durchführen, einfach nicht alles
überblicken können, was sie überblicken müssten.
Natürlich mangelhafte Dokumentation oder Mangel des Verständnisses für
das, was die Software tun soll.
Typischerweise ist so ein Horrorszenario das hier.
Am Anfang gab es keine Vollständigkeit oder Konsistenzprüfung der
Anforderungen.
Ein formales Produktmodell wurde nie gemacht.
Es gibt keine Modelle, nichts.
Es gibt bloß Code.
Sonderfälle wurden übersehen, kommen in den Testfällen auch nicht vor,
werden daher nicht gefunden.
Dann läuft das ausgelieferte Produkt so lange, bis diese Sonderfälle
nicht auftreten.
Wenn der erste Sonderfall auftritt, sagt man, das haben wir gar nicht
gedacht.
Und anstelle das betroffene Modul vollständig nochmal durchzudenken
und zu sagen, da hätten wir etwas anders machen müssen, hängt man
einen sogenannten Rucksack dran.
Dieser Rucksack heißt, wenn wir die und die Klasse von Eingaben haben,
dann machen wir hier einen Sonderfall.
Dann haben wir diese Bedingungen erfasst und dann funktioniert das für
diesen einen Fall.
Und dann kommt Sonderfall 2, dann kommt Sonderfall 3, Sonderfall 4 und
noch mehr.
Am Schluss haben Sie einen Wust von Sonderfällen, die dann auch noch
miteinander zu interagieren beginnen.
Und dann stürzt das System aus unerfindlichen Gründen ab.
Und dann haben Sie wirklich einen großen Verhau vor sich liegen mit
all diesen Sonderfällen irgendwo eingeflochten und Sie wagen es nicht,
an der Software irgendwas zu ändern.
Weil Sie nicht wissen, wenn Sie jetzt diese IF-Bedingung anders
schreiben oder wegnehmen, oder dieses Stück Code, was soll das
überhaupt, keine Ahnung, muss irgendwie ein Sonderfall gewesen sein,
von dem ich nichts weiß, ich rühre das besser nicht an.
Und dann haben Sie eine Situation, dass die Software so gut wie
unwahrtbar wird.
Sie können die Fehler gar nicht mehr rauskriegen.
Okay.
Deswegen, unsere ganze Arbeit am Anfang der Vorlesung, wo wir sagten,
wir sollten uns ein sauberes Pflichtenheft entwerfen, wir sollten
genau wissen, was wir wollen, es soll vollständig sein, konsistent,
wir brauchen einen sauberen Entwurf, damit wir jederzeit
identifizieren können, wo etwas geändert werden muss, auch was
geändert werden kann, um diese Situation mit den angebauten Rucksäcken
und Erkern zu vermeiden.
Man sagt also jetzt, ungefähr, wenn man von zehn Defekten, die vor der
Produktfreigabe durch Testen gegeben sind, gibt es mindestens einen,
der nach der Freigabe gefunden wird, und ein Defekt, der sich in die
Freigabe hineingeschlichen hat, kostet ungefähr vier bis zehn Mal so
viel Zeit, um ihn wieder zu korrigieren.
Damit auch entsprechend die Kosten.
Daher ist die Qualitätssicherung schon bei der Entwicklung sehr
wichtig.
Die Qualitätssicherung beim Kunden zu machen, funktioniert nicht.
Das war also der Punkt bei den korrektiven Tätigkeiten, der
Fehlerbehebung.
Dann, was ich Ihnen sagte, die Optimierung und Leistungsverbesserung.
Oftmals braucht die Software eben mehr Zeit, mehr Speicher, als
wirklich zur Verfügung steht.
Irgendjemand hat noch einen alten PC, hat halt noch nicht zwei
Gigabyte Speicher.
Und in der Regel ist es so, dass die Optimierungen erst spät erfolgen.
Die großen Verbraucher vielleicht kennt man noch gar nicht, aber
meistens wird die Software einfach freigegeben, wenn sie in
Anführungszeichen läuft.
Und diese Feinoptimierung und Reduzierung des Speicherverbrauchs
passiert dann ebenfalls während der Wartungsphase.
Jetzt zu der anderen Klasse, die progressiven Tätigkeiten, nämlich die
Anpassung und Änderungen.
Die werden, wie gesagt, erzwungen durch Änderungen der Umgebung.
Neue technische Geräte werden eingeführt, neue Verbindungen gibt es,
neue Speichermedien, größere Speicher, andere Speicher.
Und die Software muss irgendwie darauf angepasst werden.
Bei den Funktionen kann es auch sein, dass sie gezwungen sind zu
ändern, weil es plötzlich eine andere Vorschrift gibt.
Denken Sie nur an die Änderungen der Mehrwertsteuer, die ab und zu
passiert, oder die Mehrwertsteuerreduzierung bei Hotels, wo es ein
unglaubliches Durcheinander gegeben hat, dadurch, dass die
Mehrwertsteuer für Übernachtungen, ich denke, auf sieben Prozent
reduziert wurde.
Warum, weiß man heute noch nicht, aber Mahlzeiten nicht.
Also, wenn Sie dort ein Frühstück einnehmen, dann muss es auch noch
separat herausgerechnet werden.
Selbst wenn Sie eine Gesamtsumme zahlen, Übernachtung mit Frühstück,
das Frühstück wird mit 19 Prozent.
Sie sehen schon, das so richtig hinzukriegen, rein von der Berechnung
ist eine Sache, aber auch in der Benutzeroberfläche scheint es durch,
dass das richtig funktioniert.
Alles richtig angegeben wird, die Hotelrechnung richtig gedruckt wird.
Und das kommt einfach daher und Sie haben eine Hotelsoftware, die muss
das dann plötzlich können.
Das ist eine typische Änderung in den Funktionalitäten.
Diese Erweiterungen führen auch, hier werden Funktionen geändert.
Eine Anpassung an Ergebnis, aber die Funktion wird nur geändert, sie
ist ja schon vorhanden.
Die Erweiterungen sind dann so, dass tatsächlich funktionale
Erweiterungen, neue Funktionen hinzukommen, einschließlich der
Benutzeroberfläche zum Beispiel.
Oder aber es ergeben sich einfach neue Funktionen aus den
Erfordernissen des Betriebs der Software.
Plötzlich heißt es aber, wir müssen noch mit dem anderen System hier
eine Verbindung aufnehmen, denn da müssen diese Daten mitgeliefert
werden oder sie kommen von der Stelle und dann müssen diese
Erweiterungen mit eingebaut werden.
Wir hatten jetzt also gesagt, korrektive und progressive Tätigkeiten.
Es gibt noch eine andere Klassifizierung, da gibt es auch die
korrigierenden Aktivitäten.
Da werden Software-Defekte entfernt, aber die Leistungsmängel werden
hier hinzugefügt.
Übrigens gehören zu den korrigierenden Fähigkeiten auch diese
Notfallreparaturen, wo der Hersteller tatsächlich mit einem Team zu
seinem Kunden gehen muss und die Software in Ordnung bringen muss.
Das sind eigentlich die Daten, die eventuell zerstört wurden durch die
fehlerhafte Software.
Dann gibt es bei dieser Klassifizierung die Korrektiven, die
Anpassenden und die Perfektionierenden.
Die Anpassenden und Perfektionierenden waren vorher zusammengefasst
als die sogenannten progressiven Tätigkeiten, nur damit Sie diese
Wörter mal gehört haben.
Interessant ist aber jetzt, und wie viel macht das in der Praxis aus?
Und zwar ist der Aufwand eigentlich nicht, wie man zunächst meinen
könnte, der Korrekturaufwand wäre der höchste, im Gegenteil.
Es sind die Aufwand für die Anpassungen und Erweiterungen, der am
höchsten ist, nämlich zwischen 60 und 80 Prozent der Gesamtkosten.
Wenn das also 80 Prozent ist, ich habe ein Bildchen, ein Schaubildchen
hier, also das ist die eine Korrektive und die progressiven
Tätigkeiten, Stabilisierung, Optimierung, Anpassung und Erweiterung.
Da haben Sie 38 korrektiv, einzeln die Optimierung und progressiv sind
62 Prozent, das heißt also weniger als 40 Prozent.
Wenn also das Projekt geliefert wurde, haben Sie weniger als die
Hälfte der Arbeit geleistet.
So muss man sich das vorstellen.
Hier ist eine andere Untersuchung, die auf ähnliche Werte kommt.
Perfektionierend und anpassend sind hier sogar 80 Prozent und
korrigieren 20 Prozent, einschließlich der Optimierung.
Das ist also nicht genau gleich, das sind andere Studien gewesen.
Und wenn es also 80 Prozent ist, heißt das, wenn Sie mit der ersten
Entwicklung fertig sind, haben Sie erst ein Fünftel der Kosten bezahlt
und ein Fünftel der Arbeit geleistet.
Ich hatte jetzt vorhin gesagt, wir unterscheiden so eine
Nebenbewertung und Pflegephase.
Im Deutschen unterscheidet man tatsächlich zwischen diesen beiden
Begriffen.
Bei der Wartung ist es so, dass man im Wesentlichen die Lokalisierung
und Behebung von Defekten im Betrieb vornimmt.
Wenn der Versager bekannt wird und wann der Versager auftritt, das
wissen Sie ja nicht.
Irgendwann kommt ein Telefonanruf oder eine E-Post oder sonst wie, ein
Fax, eine Meldung und Sie müssen darauf reagieren.
Aber Sie können nicht vorhersagen, Sie können keine Teamplanung machen
und sagen, am Montag beheben wir diesen und jenen Fehler, denn den
kennen Sie noch nicht.
Die Pflege hingegen, nämlich die Durchführung von Anpassungen und
Änderungen und Erweiterungen, die können Sie sehr wohl planen, denn
die ist nicht so zeitkritisch.
Wenn ein Kunde sagt, ich hätte noch gerne die folgende Funktionalität
oder wäre es nicht schön, auch noch eine App zu haben, die auf die
gleiche Datenbank zugreift, dann können Sie sagen, ja gut, können wir
machen, aber das machen wir im Kalenderwoche so und so oder Monat so
und so des laufenden Jahres.
Das ist dann meistens ein bisschen eine Verhandlungssache, aber Sie
können das dann planen.
Meistens gibt es ja dann mehrere Kunden, die so eine Erweiterung
wünschen.
Deswegen spricht man eben von der Pflege des Systems, wenn man anpasst
und ändert und diese Arbeiten können besser geplant werden.
Im Englischen wird aber meistens dazu bei den Dingen Maintenance
gesagt, Pflege und Wartung.
Wartung und Pflegeaufwand, das brauche ich jetzt nicht mehr sagen, das
ist einfach eine andere Sichtweise auf die vorigen beiden
Tortenscheiben, nämlich Wartung und Pflege 80%, Wartung und Pflege
67%.
In diesen Bereichen bewegt sich das.
Also die Faustregel ist jetzt, Wartung und Pflege ist mehr, größer der
Aufwand, als der Entwicklungsaufwand und zwar im Faktor 2 bis 4.
Das heißt jetzt wieder für Sie, wenn Sie in eine Firma gehen, da ist
die Wahrscheinlichkeit sehr, sehr hoch, dass Sie nicht Software auf
der grünen Wiese erstellen, sondern eigentlich, wenn Sie sich
vorstellen, diese Firma hätte 100 Mitarbeiter, da werden nur 20 davon
eigentlich mit neuer Software zu tun haben und der Rest, ich weiß es
nicht, Sie am Anfang mindestens, mit der Wartung von existierender
Software.
Wenn man auf Software schreibt, völlig neu, ist ja fast schon selten,
vergleichsweise selten.
Die Pflegeaktivitäten, also die Anpassungen und Erweiterungen, die
sollte man so sehen, dass es eigentlich eine Fortschreibung der
wirklichen Entwicklungsprozesse ist.
Das heißt, man geht jetzt bei der Pflege und Erweiterung nicht einfach
her und modifiziert den Code drauf los, sondern man sollte eigentlich
hergehen und sagen, da haben wir jetzt ein inkrementelles Modell, wir
müssen eine Erweiterung einführen, das heißt, wir müssen ein klein
wenig an den Anforderungsdokumenten ändern, müssen die
Anforderungsdokumente erweitern oder ausbessern, wir müssen den
Entwurf nochmal überdenken, möglicherweise gibt es dazu zusätzliche
neue Komponenten und andere Komponenten werden ersetzt, wir müssen
wieder einen kompletten Komponententest machen für die Komponenten,
die hinzugefügt wurden bzw.
geändert wurden, wir müssen einen Integrationstest machen und wir
müssen möglicherweise sogar eine neue Abnahme machen.
Das heißt, eigentlich ist die Pflege eine Bordentwicklung und die
sollte man entsprechend durchführen und nicht nur mit dem Editor im
Code rumdrehen und irgendwo was ändern.
Denn dann weiß man später auch wieder nicht mehr, was aus der Software
geworden ist.
Also gewissermaßen einen Teil des Entwicklungszykluses wieder
durchführen.
Natürlich in reduzierter Form, denn jetzt ist nicht mehr so viel zu
tun.
Und es steht dann eine neue Produktversion.
Der Aufwand für Wartung und Pflege wächst natürlich mit dem Umfang des
Softwareproduktes, das ist klar, aber auch mit dem Alter, auch eine
Faustregel, ungefähr 10% wächst dieser Aufwand.
Und je älter ein Produkt ist, desto schwieriger wird es, damit
umzugehen und ab einem bestimmten Zeitpunkt muss man sich dann eben
die Frage stellen, soll weiter gewartet und gepflegt werden oder ist
es Zeit, das Produkt komplett zu sanieren oder kann ich das Produkt
vielleicht durch ein völlig anderes von einem anderen Hersteller
überhaupt ersetzen.
Also zum Beispiel die Firma Microsoft ist dazu bekannt, dass sie
gelegentlich, wo ich sage gelegentlich, weil ich nicht weiß, in
welchen Rhythmus das gemacht wird, alle Software komplett neu
geschrieben wird.
Das Office-Paket ist durch mehrere solche Zyklen hindurchgegangen,
dass es nicht einfach rumgeschraubt wurde, sondern man hat gesagt, so,
das lassen wir jetzt sein, wir schreiben das komplett neu.
Weil eben die alte Version nicht mehr tragfähig war.
So, wenn man also ein Altsystem hat und sich entschieden hat, es noch
eine Weile zu warten, dann gibt es da auch den Begriff der Software
Sanierung oder Software Restaurierung, im Englischen re-engineering
oder auch Software re-engineering.
Das ist so ähnlich wie Sanieren eines alten Hauses.
Und ich zeige Ihnen besser ein Bild, was damit gemeint ist.
In der Regel haben Sie also dieses Altsystem und bevor Sie an dem
überhaupt etwas ändern können, müssen Sie es erst sanieren.
Das heißt, umstrukturieren, erst einmal verstehen lernen,
umstrukturieren, möglicherweise, wenn sich zum Beispiel die
Programmiersprache geändert hat, eine neue Version von Java zum
Beispiel dabei ist, dass Sie unter Umständen das, was markiert ist als
zukünftig wegfallend, dass Sie das ausbessern, ersetzen durch neuere
Konstrukte, die berühmte deprecated, zukünftig wegfallend oder
zurückgestellt, möglicherweise komplett neu schreiben in der Form,
dass Sie von einer alten Programmiersprache in eine neuere, modernere
umsetzen, aber ohne die Funktionalität drastisch zu ändern.
Also einfach eine 1 zu 1 Übersetzung.
Dann haben Sie ein restrukturiertes Altsystem, das laufen muss, das
sogar die komplette Funktionalität des Altsystems können muss noch und
erst wenn es restrukturiert ist, sauber strukturiert ist, Module sind
gebildet, Dokumentation ist geschrieben, dann sagen Sie so, und jetzt
können wir überlegen, wo die neuen Komponenten reingehören und welche
Komponenten zu ersetzen sind.
Also jetzt erst kann ich erweitern und anpassen.
Und dann habe ich ein restrukturiertes und erweitertes System.
Das ist das, was man im Bereich Software Reengineering macht, dazu
gibt es jede Menge Hilfsmittel und eigentlich wäre das Kapitel
Software Restrukturierung oder Sanierung selbst eine ganze Vorlesung
wert.
Können wir natürlich nicht mehr machen, insbesondere wo wir uns noch
zweimal treffen, einschließlich heute.
Daher nur ganz eben diese kurze Übersicht.
Mir ist erstmal wichtig, dass Sie verstehen, dass ich bei der
Restaurierung oder Sanierung hergehen muss und das Altsystem erst auf
den neuen, sauberen, restrukturierten Stand bringen muss, bevor ich
mich dran mache, es zu verbessern.
Okay, gibt es Fragen soweit?
Ich sehe keine.
Gut, natürlich kommt jetzt das Kapitel Änderungsverwaltung.
Wie mache ich das?
Sie kriegen jetzt dutzende, hunderte von Fehlermeldungen, wenn Sie mal
in Open Source Projekten nachgeschaut haben, da gibt es ganze
Datenbanken, die nur die Fehlermeldungen enthalten.
Das wollte ich Ihnen jetzt auch kurz sagen.
Für jede Fehlermeldung oder auch Erweiterung könnte man sogar
hernehmen, Änderungsanträgen nennt man das, sagt man sich, okay, wir
müssen irgendwann mal, wenn die neue Version des Systems ausgeliefert
wird, sagen können, was passiert ist.
Welche Fehlermeldungen überhaupt ausgeführt wurden oder bearbeitet
wurden und erfolgreich bearbeitet wurden, dass Sie also am Schluss,
haben Sie sicher auch schon gesehen, Sie kriegen eine neue Version von
irgendeiner Software und Sie sagen, jetzt können wir das und das und
das und das und das zusätzlich, dieses neue Format können wir
verstehen und dieser eine Fehler ist berechnet.
Das wollen Sie alles wissen.
Es wäre ein Fehler, keine Buchführung dieser Art zu machen, denn am
Schluss sagt der Manager, nächsten Montag müssen wir liefern, was kann
ich denn dem Kunden sagen, was sich geändert hat?
Moment mal, da hatten wir doch diesen einen Fehler, ich weiß jetzt
nicht mehr so genau.
Das geht nicht.
Das heißt, man führt jetzt ein System ein zur Änderungsverwaltung.
Zum einen, wenn ich einen Defekt habe, der behoben werden soll, muss
das Gemälde auch reproduzierbar sein, denn wenn es nicht
reproduzierbar ist, kann ich es ja nicht finden.
Manchmal ist es aber auch die Aufgabe des Entwicklers, dass jemand
sagt, unter den und den Umständen gibt es einen Fehler, dann müssen
Sie möglicherweise tagelang arbeiten, um eine Situation, diese
Situation wiederherzustellen.
Das heißt also, die richtige Version des Kunden der Software zu
benutzen, die richtigen Eingabedaten, die er hatte, die
Netzwerksituation nach simulieren und dann alles so aufstellen, dass
tatsächlich der Fehler auftritt.
Jetzt sollten natürlich nur alle zur Defektbehebung relevanten
Informationen in dieser Fehlermeldung mitgeliefert werden.
Die Produktverversion, das verwendete Betriebssystem, die Größe des
Hauptspeichers, andere Anwendungen, die damit zusammenarbeiten und so
fort.
Das ist nochmal das eine.
Dann gibt es, wie ich schon erwähnte, diese Systeme zur Verfolgung der
Änderungsverwaltung.
Ein bekanntes ist Bugzilla oder Jira oder auch Track.
Das Bugzilla gibt es jetzt auch kommerziell.
Bugzilla sagt also zum Beispiel, jede Meldung, jeder Vorfall, den wir
haben, besteht aus natürlich, wer es gemeldet hat, das Problem zu
beschreiben, der Schwerdegrad.
Der Schwerdegrad kann sein, es ist ein bisschen ungeschickt, dann ist
der Schwerdegrad niedrig.
Oder es ist kritisch, das heißt, ich kann ohne Reparatur nicht
weiterwachen.
Da gibt es also mehrere Schwerdegrade.
Eine Priorität, wie wichtig wird das als nächstes behandelt?
Und sieben Zustände, nicht bestätigt oder not confirmed, das heißt, da
ist es gerade erst eingegangen, hat sich noch keiner angeschaut.
Wir wissen nicht mal, ob das überhaupt ein Fehler ist.
Das ist ein neuer Fehler.
Das heißt, jemand hat sich ihn angeschaut und festgestellt, ja, das
ist ein Fehler, den haben wir auch noch nicht behoben, auch noch nicht
in der gegenwärtigen Fortentwicklung.
Dann zugewiesen heißt, jemand macht es, behoben ist, es ist
tatsächlich verschwunden, und Behebung wurde sogar verifiziert, das
ist der nächste Zustand, geschlossen heißt, das ist erledigt.
Und am Schluss kann ich dann bei der nächsten Lieferung des Systems,
bei der nächsten Freigabe hergehen und sagen, okay, schauen wir mal
nach in Baxilla, was alles an Fehlermeldungen in dem Zeitraum von A
bis B als behoben markiert ist, und das ist die Liste, die wir dann in
dem Manifest der Software aufschreiben und dem Kunden zukommen lassen.
Okay, hier sind das typische Automat, nicht bestätigt, neu, zugewiesen
hatten wir schon gesagt, behoben, es gibt natürlich Übergänge deswegen
von nicht bestätigt, nämlich dann, wenn es ein Ungültig ist oder ein
Duplikat, dann wird es gleich als behoben markiert, ohne dass
überhaupt etwas passiert ist.
Bei zugewiesen kann es natürlich sein, dass es behoben wird, aber die
Verifizierung schlägt, der Fehler ist dann offensichtlich verkehrt,
dann wird er erneut geöffnet.
Das kann natürlich auch hier unten passieren, dass wir meinten, dass
der Fehler behoben ist, aber in Wirklichkeit doch noch nicht.
Hoffentlich ist das dann selten.
So läuft das ungefähr ab, bringt natürlich eine Bildschirmmaske, eine
Bildschirmmaske hier ist eine Übersichtsmaske erstmal, die
Übersichtsmaske hier gibt eine Nummer für jeden Fehler an, und hier
ist die Severity, hier ist die Priorität, hier ist das Betriebssystem,
da ist das Produkt, da ist der Status, das sind alle noch unconfirmed
hier auf der Seite.
Unconfirmed und hier ist eine Zusammenfassung.
Und natürlich gibt es, das können Sie wieder nicht lesen, tut mir
leid, hier wäre in diesem verschwommenen Text, das ist die textuelle
Beschreibung des Fehlers, kann man sich anzeigen lassen und es gibt
Übersichten und so weiter.
Also Sie sehen schon, wenn ich die Daten mal erfasst habe, Sie als
Informatiker sind klar, dass ich dann natürlich auch Übersichten in
verschiedensten Detaillierungsgraden liefern kann.
Das kann also Baxiller.
Das hatten wir schon, weitere relevante Informationen.
Natürlich ist es auch möglich, dass Sie sagen, wir könnten auch den
Absturz automatisch erfassen.
Wenn also ein System, ein Softwaresystem beim Benutzer abstürzt, dann
kennen Sie das vielleicht auch schon, dürfen wir dem Hersteller eine
Information liefern über diesen Absturz.
Dann können Sie ja oder nein sagen.
Je nachdem, ob Sie meinen, das sind jetzt private Daten drin oder
nicht.
In der Regel würde man zum Beispiel beim Textverarbeitungssystem
natürlich meinen, wenn das Ding abstürzt, dann muss ich wohl den Text
mitschicken.
Das wollen Sie wahrscheinlich nicht unbedingt.
Dass Sie beliebige Kommunikation dann mitschicken.
Also da ist dann zu überlegen, ob man das machen will oder nicht.
Aber im Prinzip ist es eine sehr gute Methode, von den Kunden zum
Beispiel oder auch im anonymen Markt Fehlermeldungen zu bekommen, ohne
dass der Kunde viel tun muss.
Das nächste ist Organisation.
Wer macht eigentlich die Wartung?
Also wir sagten ja vorhin, 100 Leute, 80 davon machen Wartung und
Pflege, 20 davon machen Neuentwicklung.
Ist es so, dass die 80 Leute festgelegt sind auf nur Wartung und
Pflege?
Oder machen eigentlich alle Entwicklung und nur 20% ihrer Zeit
arbeiten sie an Neuentwicklung und 80% ihrer Zeit arbeiten sie an
Wartung und Pflege von anderen Produkten?
Wie ist das organisiert?
Und da gibt es zwei Organisationsformen.
Die eine Form ist, dass man eine vollständig eigene
Wartungsorganisation baut.
Das heißt also, bei 100 Leuten, beim Beispiel von vorhin, werden 80
Leute abgesetzt, die machen nichts als Wartung existierender Software.
Wenn eine Neuentwicklung fertig ist und dem Kunden übergeben wird,
wandert die gesamten Daten, das gesamte Archiv, die gesamte
Dokumentation und allen so weiter zur Wartungsorganisation.
Die Wartungsorganisation muss sich darüber mit diesem System jetzt
befassen, muss dieses neue System kennenlernen, sodass eingehende
Fehlermeldungen oder Änderungswünsche sie auch wirklich bearbeiten
können.
Vorteil ist, wir haben eine klare Zuordnung, ich mache Wartung, du
machst Entwicklung.
Wir bekommen dann auch Leute, die spezialisiert sind auf Wartung und
das besonders gut können, vielleicht die Fehlersuche schnell können
oder sehr gute Tests schreiben können.
Wir bekommen also eine Spezialisierung, Konzentration auf die Wartung.
Ich bin nicht da und abgelenkt mit einer neuen Freigabe, die nächste
Woche eben rauskommen muss.
Spezialisierte Mitarbeiter, effiziente Kommunikation zwischen den
Wartungsmitarbeitern und damit eine höhere Produktivität durch diese
Spezialisierung auf Wartung.
Allerdings gibt es auch Nachteile.
Die Nachteile stehen hier auf dieser Folie.
Möglicherweise könnte es sein, dass die Leute, die Wartung machen,
herabgesetzt werden.
Du machst ja bloß Wartung, wir sind die Besseren, wir sind die Guten,
wir machen die Software.
Es kann aber auch umgekehrt sein, dass die Warter die Haare zu Berge
stehen, wenn sie die Software von den Entwicklern bekommen, weil die
das so schreiben, dass sie sich für Wartung überhaupt nicht
interessieren und deswegen schlecht wartbare Software schreiben.
Kümmern Sie sich zum Beispiel nicht um ein Turf oder ein Turfmuster
oder kleine Module, die einfach zu testen sind.
Oder die ganzen Programmierkonventionen werden ignoriert, die Tests
sind oberflässig und das macht ja die Wartungsorganisation.
Und dann ist das natürlich auch schlecht, wenn die
Wartungsorganisation den Mist der Entwickler ausbessern soll.
Beim Übergang außerdem von der Entwicklung zur Wartung, die sind ja
völlig voneinander getrennt, gibt es Informationsverlust.
Der Entwickler weiß natürlich, was er geschrieben hat, wüsste
wahrscheinlich sofort, wo der Fehler ist oder ziemlich schnell während
der Wartung muss ich erstmal schauen, wie sind das überhaupt
aufgebaut, was tut denn das, was sind denn die Funktionen, man muss
unglaublich viel Zeug lesen.
Das ist natürlich mehr Arbeit, als wenn es die Entwickler machen
würden.
Und die Konsequenzen schlechter Entwicklungsarbeit müssen die
Entwickler auch nicht tragen.
Das Einarbeiten ist also aufnässig und eine gleichmäßige Auslastung
der Mitarbeiter ist nicht unbedingt gegeben.
Es kann sein, dass die Entwickler nichts zu tun haben, aber warten
würden sie nicht.
Es könnte sein, dass die Warter gerade keine Fehlermeldungen bekommen,
aber entwickeln dürfen sie nicht.
Das hat auch seine Nachteile.
Es gibt da keine perfekte Organisation, aber was man empfiehlt ist
Folgendes.
Und das gilt natürlich jetzt nur für größere Firmen.
Wenn Sie bei einer Fünf-Mann-Klitsche sind, geht das nicht.
Aber eine getrennte Organisation heißt, es gibt eine
Wartungsorganisation und es gibt eine Entwicklungsorganisation.
Und die Entwicklungsorganisation ist in der Regel kleiner.
Aber die Mitarbeiter dürfen mal in der einen als auch in der anderen
Entwicklungsorganisation arbeiten.
Das heißt, sie arbeiten erstmal in der Wartungsorganisation und dann
bekommen sie die Chance, rüber zu wechseln in die Entwickler und dafür
wechselt ein Entwickler in die Wartungsorganisation.
Das hat sich also herausgestellt als praktikabel.
Dann sehen nämlich die Entwickler, was in der Wartung wichtig ist,
nämlich saubere Dokumentation, ausführliche Beschreibung der
Modulschnittstellen, ein sauberer Entwurf, begründet und dokumentiert
Programmierkonventionen, Testfälle, ausreichend viele Testfälle, die
automatisch ablaufen, dass sie jede Zeit wiederholbar sind.
Das merkt dann jeder Entwickler, wenn er ein System hat, wo das alles
fehlt.
Und außerdem bleibt man dann, wenn man die Wartung nicht immer
gefällt, nicht ewig in der Wartung hängen.
Jetzt macht man das in der Regel bei größeren Organisationen so.
Bei kleinen Softwareglitschen ist es so, dass jeder alles macht.
Und das führt eben zu der berühmten Konfusion.
Was mache ich heute?
Soll ich weiterentwickeln?
Das ist wichtig.
Oder soll ich diesen Fehler beseitigen?
Das wäre auch wichtig.
Was mache ich jetzt eigentlich?
Der Vorteil der Entwickler, der seine eigene Software wartet, ist
natürlich, dass er sie kennt.
Jedenfalls bis zu einem bestimmten Grad.
Nach einem halben Jahr oder Jahr kann es durchaus sein, dass der
Vorsprung immer kleiner wird, der Wissensvorsprung, das System zu
kennen immer kleiner wird.
Also merken, größere Organisationen, da in Ihrem Softwarehaus die Welt
ummodeln wird mit toller neuer Software, Sie wachsen wie Facebook und
Google, dann haben Sie eine separate Wartungsorganisation und schicken
die Leute hin und her.
Jetzt sind wir mit dem Kapitel eigentlich schon durch.
Gibt es noch Fragen dazu?
Zu dem letzten Punkt vielleicht oder auch zu dem vorigen?
Sie merken sich, das Re-Engineering, das war glaube ich ein wichtiger
Punkt und auch, dass Anpassung und Erweiterung eigentlich ein neuer
Entwicklungszyklus ist, in dem sowohl Anforderungen gemacht werden als
auch ein neuer Entwurf und dann erst mit dem Codieren begonnen wird.
So, das nächste Kapitel für heute, das sind die Schätzmethoden.
Und zwar springen wir jetzt zurück in die Planungsphase.
In der Planungsphase sagte ich ja, natürlich müssen wir planen, aber
etwas, was wir nicht planen können, ist die Kosten.
Weil wir noch nicht wissen, was alles gemacht werden muss.
Jetzt sind wir also durch diese gesamte Tätigkeitsliste hindurch.
Wir wissen jetzt also, was bei den Anforderungen passiert, wir wissen,
was bei der Systemanalyse passiert, wir wissen, was beim Entwurf
passiert, bei der Implementierung, beim Test und sogar bei der
Wartung.
Und jetzt sollen wir zurückgehen und sagen, gut, jetzt stehe ich da
und soll ein neues System bauen und mein Chef sagt mir, und was kostet
es?
Dann sagen sie, weiß ich nicht.
Schätz das mal, morgen sagst du mir das und dann kriegen sie die
Krise, weil sie das nicht mögen.
Also was wir hier machen, ich werde mehrere Schätzmethoden geben und
Sie sollten sie auf Beispiele anwenden können.
Da gibt es also Einflussfaktoren, was die Schätzung beeinflussen wird,
Basismethoden der Aufwandsschätzung.
Darüber finden Sie übrigens am besten im Balzert, Lehrbuch der
Softwaretechnik, Softwareentwicklung, zweite Auflage usw.
Vielleicht schon der dritte, keine Ahnung.
Dann spreche ich ganz kurz über eine ganz bestimmte Schätzmethode, die
heißt COCOMO oder Constructive Cost Model.
Ist allerdings auch schon ziemlich alt, in den letzten 80er Jahren,
glaube ich.
So, dann schauen wir mal.
Also als erstes sollten wir sagen, dass die Aufwandsschätzung für den
Informatiker und besonders derjenige, der viel Mathematik gemacht hat,
ein Graus ist.
Weil es so total ungenau ist.
Da gibt es zwar Formeln, aber in diese Formeln gehen geschätzte Werte
rein, nämlich wie viel Zeilencode die Software sein wird und dann
dividiere ich das durch die Anzahl Zeilencode, die ein Entwickler pro
Monat leisten kann und dann kriege ich eine Anzahl von Monaten heraus,
wie die Software zu schreiben ist und dann habe ich noch einen Preis
für den Mitarbeiter pro Monat, das ist vielleicht sogar ganz exakt
festzustellen und dann multipliziere ich das und dann weiß ich, was
die Software kostet.
Aber was in diese Schätzung reinging, ist eben eine Schätzung der
Zeilencode, die benötigt werden.
Und wer kann das schon sagen?
Sie sind alle in höherer Mathematik und linearer Algebra und es ist
natürlich klar, dass für Sie mathematische Formeln super oberexakt
sind.
Jetzt müssen Sie plötzlich mit Formeln arbeiten, wo die
Eingabevariablen sehr ungenau sind.
Aber ich sage immer, Sie als Informatiker müssen auch mit ungenauen
Problemstellungen fertig werden.
Leider ist es in der Welt so, dass die Welt nicht als HM Übungsblatt
daherkommt.
Punkt 1, Aufgabe 2, Aufgabe 3.
Sondern da kommen ungefähre Ansprüche oder Anforderungen daher und Sie
müssen trotzdem eine Schätzung abgeben.
Und deswegen heißt dieses Kapitel auch Schätzen.
Es heißt nicht Kosten berechnen.
Wenn es nämlich möglich wäre, die Kosten exakt zu berechnen oder die
Dauer exakt zu berechnen, dann würden wir es nicht Schätzen nennen,
sondern wir würden sagen Berechnung.
Geht leider nicht, wir müssen Schätzen.
Die Wirtschaftlichkeit ist natürlich hier das Wichtige.
Die Wirtschaftlichkeit kann man natürlich vereinfacht so ausdrücken.
Man sagt, der Gewinn oder Verlust, den die Firma macht mit ihrer
Arbeit, ist ein Deckungsbeitrag mal die geschätzte Menge minus die
einmaligen Entwicklungskosten.
Jetzt müssen wir noch, geschätzte Menge ist klar.
Wenn Sie 100.000 Stück davon verkaufen, wissen Sie, was Sie bekommen.
Wenn Sie wissen, dass das Teil 10 Euro bekommt, dann kriegen Sie eine
Million.
Was ist dieser Deckungsbeitrag?
Der Deckungsbeitrag ist natürlich der Preis minus die laufenden
variablen Kosten.
Die laufenden variablen Kosten können sein die Kosten für die Werbung
oder die Kosten für das Marketing oder die Kosten für jemanden, der
einfach da sitzen muss und das Telefon beantwortet.
Also das sind variablen Kosten.
Der Preis ist ja nicht so, dass der 100% in die Kasse fließt.
Also das ist die erste Überlegung.
Und wir wissen jetzt, den Deckungsbeitrag kann man sich irgendwie
ausdenken, gibt einem vielleicht der Wettbewerber vor, was der Betrag
ist, die geschätzte Menge, schon wieder eine Schätzung, aber für uns
wird die Schätzung der einmaligen Entwicklungskosten wichtig sein.
Denn wie Sie sehen, geht das ein in die Gewinn- und Verlustprognose.
Der Hauptanteil Kosten an einem Softwareprojekt sind die
Personalkosten.
Natürlich kommt da noch ein bisschen was dazu, nämlich die Kosten für
die Rechner, die muss man auch irgendwann mal kaufen, aber die werden
über mehrere Jahre abgeschrieben, die Softwarekosten für andere
Software, die man braucht, zum Beispiel für einen Übersetzer oder das
Betriebssystem.
Dann die anteiligen Kosten für die Dienstleistungen, Schulungen,
Reisen, auch das fällt überall an, Büromaterial, Druckkosten,
Dokumentation und so fort.
Das sind die Kosten, über die werde ich jetzt nicht mehr weiter
sprechen, denn die sind relativ einfach festzustellen, wenn Sie
erlauben, dass die Leute zwei Dienstreisen im Jahr machen, dann so und
so viel Geld vielleicht, da kostet mich eine Dienstreise von einer
Woche vielleicht, vier Übernachtungen im Hotel, 100 Euro plus
Reisekosten innerhalb Europas, so und so viel, das kann ich irgendwie
schätzen, das hat aber nichts mit Informatik zu tun, deswegen werde
ich das jetzt nicht machen.
Sondern wir schauen uns die Personalkosten für die eigentliche
Softwareentwicklung an.
Wir können die dann auch übertragen auf die Kosten, die entstehen,
wenn wir Wartung machen.
Also die meisten Modelle gehen jetzt einfach so her, dass sie sagen,
wir schätzen mal den ungefähren Umfang dieser Software.
Also ich könnte zum Beispiel sagen, eine bestimmte neue Software ist
120.000 Zeilen Code, also 120 Kilo Lines of Code.
Was ist das?
Eine Line of Code, das sind alle Vereinbarungs- und Anweisungszeilen,
die vorkommen in der Software, aber nicht die Kommentarzeilen und
nicht die Leerzeilen.
Auch die geschweiften Zeilen, die nur mit der geschweiften
Klammerenden zählen wir auch mit.
Wir brauchen nur einen Standard für das Zählen, aber die
Kommentarzeilen müssen natürlich auch geschrieben werden, werden aber
in der Regel nicht mitgezählt.
So, der geschätzte Umfang wird jetzt durch die
Programmierproduktivität in Lines of Code eines Mitarbeiters pro Jahr
oder pro Monat dividiert und fertig bin ich.
Also Personenjahre, Personenmonate oder auch Mitarbeiterjahre,
Mitarbeitermonate genannt, je nachdem, das heißt jetzt schon lange
Mitarbeitermonate, ich bin noch aufgewachsener, da durfte man noch
Mannjahre und Mannmonate sagen, aber das darf man jetzt nicht mehr.
Aber Mitarbeiter geht auch.
So, jetzt kommt es auch ein bisschen an, wo man lebt, was ein
Personenjahr ist.
Ein Personenjahr sind nämlich nicht zwölf Personenmonate, sondern
weniger, so etwa um die zehn.
In manchen Ländern, westlich von uns, vielleicht nur neun.
Aber rechnen Sie mal mit zehn.
Ein Personenjahr sind vier bis sechs Wochen Urlaub dabei und dann gibt
es jede Menge andere Ferien.
Also auf mehr als zehn tatsächlich volle Personenmonate kommt kaum
jemand.
So, ein Personenmonat ist natürlich klar, besteht in der Regel aus
vier Personenwochen, natürlich ein klein bisschen mehr.
Personenwoche besteht aus fünf Personentagen, ein Personentag besteht
aus acht Personenstunden, alles klar, können wir runterrechnen bis zur
Stunde.
Und dann hat natürlich ein Kalendermonat vier Personenwochen, fünf
Personentage, acht Stunden, wenn Sie das ausmultiplizieren, kommen
also in einem Kalendermonat ohne Ferien, ohne Urlaub, 160
Arbeitsstunden heraus.
So, jetzt schauen wir mal, bei einer Produktivität von 3500 Zeilencode
pro Jahr, da ist ein kleiner Schocker dabei, schauen Sie mal, 3500
Zeilencode pro Jahr, das heißt, Sie setzen nur 350 Zeilencode pro
Person pro Monat an.
Das sind nur zwei Zeilencode pro Tag.
Sie sind natürlich viel produktiver, wenn Sie an Ihrer Hausaufgabe
arbeiten, weil die Hausaufgabe ja viel besser vorbereitet ist als ein
Softwaresystem und konzentriert ist auf ein bestimmtes Thema.
Wenn man aber überlegt, wie viele Sitzungen man gehen muss, um dieses
Projekt überhaupt in Gang zu kriegen und auch während das Projekt
läuft, wie viele Telefongespräche man führen muss, wie viel Vorarbeit
man leisten muss, wenn man jetzt auch noch die Anforderungsermittlung,
die Definition, den Entwurf usw.
und das Testen miteinbezieht und dann am Schluss nur die Zeilen zählt,
dann kommt natürlich eine geringere Zahl an Zeilen heraus.
Das sind aber auch wirklich Zeilencode, für die die
Anforderungsermittlung, die Definition, das Testen mit eingezählt ist,
mit eingerechnet ist.
Das ist trotzdem sehr niedrig.
Ein Kollege nannte das mal, ja gut, wir schreiben ungefähr eine Zeile
Code pro Meeting, pro Treffen, pro Besprechung.
So, und dann gehe ich natürlich her und jetzt ist die Frage, und wie
viel Zeit brauche ich jetzt?
Ich kann jetzt ausreichen, wie viele Personenmonate ich habe, die ich
brauche, oder um das gesamte Projekt abzuwickeln.
Und wenn ich jetzt sage, ich muss das aber in einem Jahr schaffen,
dann nehme ich die Personenmonate, dividiere durch zwölf und bekomme
die Anzahl der Personen heraus, die ich brauche.
Okay, das hatte ich eigentlich schon gesagt.
Sagen wir mal, wir hätten 21.000 Zeilencode zu liefern,
durchschnittliche Produktivität ist tatsächlich 3.500 pro Jahr, und
dann können Sie das ausrechnen, dividieren, das heißt es werden sechs
Mitarbeiterjahre benötigt.
Wenn Sie drei Mitarbeiter im Team zusammenfassen, heißt das, Sie
werden zwei Jahre bis zur Fertigstellung brauchen.
Das ist extrem langsam.
21.000 Zeilencode werden Sie im PSE zu sechst wahrscheinlich
schreiben.
Das ist gut anstrengend, das ist eher realistisch, dass Sie 10.000
schreiben.
Das Projekt wird aber innerhalb eines halben Jahres fertiggestellt
werden, dann brauchen Sie dafür zwölf Mitarbeiter.
Und da ist immer noch die Frage dahinter, ob dieser Zusammenhang
linear ist.
Wenn Sie nämlich mehr Mitarbeiter haben, haben die auch mehr
Abstimmungsbedarf, müssen öfter miteinander sprechen, müssen sich die
Softwarestruktur entsprechend hinzimmern, sodass auch zwölf Leute
gleichzeitig dann arbeiten können.
Das ist zum Beispiel bei 21.000 Zeilencode nicht unbedingt gegeben,
dass sich wirklich Vollzeit zwölf Leute 100% mit der Arbeit zu
aufteilen können hier, um immer ausgelastet zu sein.
Okay, dazu haben wir aber noch ein bisschen mehr.
Wie gesagt, das ist eine ganz grobe Schätzung, diese zwei, drei Zeilen
pro Tag, mit allen zusätzlichen Arbeiten, die noch gemacht werden
sollen, eingerechnet.
Aber natürlich gibt es große Einflussfaktoren, wenn Sie qualitativ
sehr hochwertige Software schreiben wollen, die also garantiert nie
abstürzt und ein Kernkraftwerk regelt und auch im schlimmsten aller
Fälle die richtige Berechnung durchführt und den Kernreaktor
rechtzeitig abschaltet und was weiß ich, was alles gemacht werden
muss, dann brauchen Sie eine Software von sehr hoher Qualität und die
wird teurer sein zu entwickeln.
Genauso, wenn Sie sehr schnell entwickeln müssen, das heißt eine hohe
Quantität liefern müssen, dann wird sich das auch auswirken und zwar
wirkt sich das auf die Qualität aus.
Diese gegenseitige Einwirkung, da gibt es ein schönes Bildchen, das
ist das Teufelsquadrat.
Das versucht diesen Zusammenhang zu veranstalten, aber nicht
quantitativ, sondern nur qualitativ.
Also vier Ecken in diesem Quadrat, Qualität, Quantität, Kosten und
Entwicklungsdauer.
Und dann schreiben wir hier diese Achsen ein, wir sagen, die
Produktivität wird dargestellt durch die Fläche dieses Rechtecks,
dieses Quadrats in der Mitte, für mittlere Qualität, mittlere
Quantität, mittlere Kosten und mittlere Entwicklungsdauer.
Wenn Sie jetzt hergehen und sagen, ich will aber die Qualität erhöhen,
dann stellen Sie sich vor, Sie ziehen an dieser Ecke des Quadrates
hier rauf, dann verzieht sich dieses Quadrat, aber, das war ja nicht
so ganz geglückt in der Zeichnung, die Fläche dürfte sich nicht
vergrößern.
Das heißt, Sie ziehen also hier diese Ecken ein bisschen runter.
Das heißt, wenn Sie die Qualität erhöhen, werden Sie langsamer, die
Quantität sinkt.
Wenn Sie auch noch die Entwicklungsdauer reduzieren wollen, dann
passiert das Gleiche, dann müssen Sie auch irgendwie höhere Kosten und
die Abstriche in der Quantität hinnehmen.
Umgekehrt, wenn Sie die Kosten reduzieren wollen, dann können Sie
natürlich nicht so hohe Qualität liefern, oder die Entwicklungsdauer
verlängert sich, nämlich in diese Richtung von Plus.
Also diese vier Eigenschaften wirken aufeinander ein und ich kann also
nicht alles auf einmal wollen.
Ich kann nicht eine extrem kurze Entwicklungsdauer, eine extrem hohe
Qualität und dann auch noch niedrige Kosten haben.
Das klappt nicht.
Das muss man sich einfach klar machen.
Aber ist ansonsten nicht schwierig zu verstehen, denke ich.
So, dann das Nächste ist...
Und woher weiß ich denn überhaupt, dass ich nur 350 Zahlen pro Person
pro Monat erwarten kann?
Da ist zum einen zu sagen, dass es, wenn Sie mehr Personen einsetzen,
natürlich eine überproportionale Beziehung besteht.
Wenn die Software also noch immer noch größer wird, dass Sie dann auch
die Kosten überproportional steigen werden, weil mehr Personal
benötigt wird, dieses Personal hat mehr Abstimmungsbedarf.
In anderen Worten, es geht mehr Zeit drauf, sich abzustimmen und
weniger Zeit ist übrig, um an der Entwicklung zu arbeiten.
Außerdem ist dieses Maß natürlich extrem abhängig von der
Programmiersprache.
Wie mache ich denn das?
Also, wenn Sie in Java programmieren, ist die Produktivität sicher
eine andere, als wenn Sie in reinem C produzieren.
Und das ist wahrscheinlich immer noch sehr viel besser, als wenn Sie
in reinem Assembler schreiben würden.
350 Zahlen Assembler sind so gut wie nichts.
Und sind das genauso schwer zu schreiben wie 350 Zahlen Code C?
Die Antwort ist nein.
Da ist eine andere Produktivität, die Produktivität ist abhängig von
der verwandten Programmiersprache.
Dann gibt es eben die Komplexität, die ist wieder sehr schwer zu
fassen, analytisch.
Sag mal, qualitativ mittel, leicht und schwierig.
Oder Noten von 1 bis 6.
Besser kann man das nicht sagen.
Es gibt schon auch Qualitätsmetriken, aber die erfordern immer, dass
man bereits einen Teil der Software geschrieben hat.
Darum gehe ich darauf nicht ein.
Aber Schätzen ist natürlich auch, so ungenau es ist, immer noch ein
offenes Forschungsproblem in der Softwaretechnik.
Wir machen hier also nur die ganz einfachen Schritte.
So, Qualität hatten wir schon gesagt.
Einflussfaktor Entwicklungsdauer hatten wir auch in Teufelsquadrat
gesehen.
Produktivität ist natürlich noch abhängig von dem Personal selbst.
Sind die Leute gut ausgebildet?
Sind sie lernfähig?
Sind sie flott?
Kennen sie die Programmiersprachen?
Müssen sie die erst lernen?
Haben sie schon mal Eclipse benutzt oder haben sie schon mal Studio
benutzt?
Wenn nicht, wie schnell lernen sie das eigentlich, um produktiv
umzugehen?
Sind sie vertraut mit der Anwendung?
Sehen sie vor, sie kommen irgendwie zu einem digitalen
Kartenhersteller bei einem Autohersteller und sollen jetzt die
Navigationssoftware schreiben.
Keine Ahnung, wie das geht.
Ich habe nicht mal eine Ahnung davon, wie eine Karte digital
dargestellt wird.
Wissen wir nicht.
Wie schnell lernen wir das?
Sind wir damit vertraut?
Und dann wollen die auch noch eine Schnittstelle, mit der ich sprechen
kann.
Wie komme ich nach München?
Das muss das System verstehen.
Auch etwas, was sie nicht kennen.
Und anschließend das Arbeitsklima.
Ist das von Kooperation geprägt oder von Feindseligkeiten oder von
Missachtung der Kollegen?
Gibt es das ganze Spektrum?
Das wirkt sich selbstverständlich auf die Produktivität ein.
Wenn sie jederzeit mit einem Kollegen sprechen können über ein Problem
und sagen, kannst du mir mal da helfen, wie ist denn das und das
gedacht?
Und der macht das bereitwillig, dann haben sie keine Zeit verloren
oder sehr wenig.
Wenn der sich aber dumm anstellt und sagt, nein, ich weiß nicht, dann
müssen sie es selbst rauskriegen.
Also, jetzt fangen wir mit den Basismethoden der Schätzung an.
Jetzt wissen Sie ungefähr, dass es ein schwieriges und ungenaues
Gebiet ist.
Die Modellierung, eine exakte Modellierung für Produktivität,
Qualität, Entwicklungsdauer usw.
gibt es nicht, trotzdem müssen wir es machen.
Wir können natürlich sagen, als Informatismus machen wir es nicht.
Soll jemand anderer machen.
Da warne ich immer davor, denn wenn Sie Ihr Chef mal fragt, kennen Sie
sich da ein bisschen aus, was meinen Sie denn, wie das lang dauert?
Und Sie sagen, keine Ahnung, traue ich mich nicht.
Dann fragt er jemand anderen.
Das ist dann vielleicht der Kollege aus den Wirtschaftswissenschaften.
Er traut sich das.
Er hat damit kein Problem.
Und beim nächsten Mal fragt Sie Ihr Chef auch nicht mehr.
Ihr anderer Kollege kann genauso daneben liegen, aber er hat den Mut
zu sagen, ist ungenau, ich weiß das, ich schätze, das würde so und so
lange dauern, plus und minus drei Monate.
Naja, und das reicht meistens.
Also Mut dazu muss man schon aufbringen.
So, was wir jetzt machen, ist die Basisschätzmethode, die sagt
einfach, wir haben schon ein ähnliches System entwickelt und ich
schätze mal, was das Delta ist zwischen den beiden.
Also ein Beispiel, sagen wir mal, Sie hätten schon an einem uralten
Pascal -Übersetzer gearbeitet, der hatte 20 Personenmonate
Entwicklungsdauer erfordert.
Und jetzt kommt jemand und sagt, da gibt es eine Nachfolgersprache,
diese Modula-II-Sprache, was übrigens Pascal ist, mit Modulen.
Haben Sie wahrscheinlich noch nicht gesehen, aber nicht
objektorientiert, sondern modulorientiert.
Das hatte ich, glaube ich, mal bei der Modulisierung erwähnt.
Und dann sagen Sie, gut, da gibt es 20% neue Konstrukte, neue
Sprachkonstrukte, die es in Pascal nicht gibt.
Ich schätze mal, dass ich 50% des Codes wiederverwenden kann und 50%
müssen überarbeitet werden.
Klar ist auch das eine Schätzung.
Aber jetzt gehe ich hier und sage, ihr könnt 20% neue Konstrukte
wiederverwenden, neu bearbeiten.
Das neue, das wird so lange kosten wie, sagen wir mal, das
Überarbeiten ist so teuer wie neu.
Dann kann ich mir folgende Schätzung machen.
50% leicht modifiziert, 50% von 20, klar ist 10 Personenmonate mal 0
,25, auch eine Schätzung.
Gut, das Überarbeiten kostet mich 2,5.
50% neue Überarbeitung, das sage ich, gut, das kann ich auch gleich
neu schreiben.
Das Überarbeiten, das ist übrigens oft so, dass sie meinen, das
Überarbeiten ist weniger Aufwand, aber wenn sie dann am Schluss
durchgekommen sind, haben sie festgestellt, dass sie es auch gleich
neu schreiben hätten können.
Auch so ein Erfahrungswert, also sagen wir einfach, so teuer wie neu.
Und dann kommen 20% neu, zusätzliche hohe Komplexität, das ist
meistens Sachen, die sie noch nicht implementiert haben, zum Beispiel
das Modulkonstrukt, das kommt da drin vor.
Gut, 20% mehr, das sind also 4 Personenmonate mal 1,5, vielleicht 1,5
mal so teuer als Komplexitätszuschlag, macht 6 Personenmonate, alles
aufaddiert, 18.
Dann gehen sie zu ihrem Chef und sagen, ich denke wir brauchen
zwischen 18 und 20 Personenmonate.
Er sagt, Sie sind ja verrückt, wir hatten doch schon letztes Mal 20.
Dann sagen sie, tut mir leid, aber das ist die beste Schätzung, die
ich Ihnen geben konnte, weil...
Und dann erklären sie das.
Das wäre eine Analogieschätzung, geht natürlich nur, wenn sie einen
Analog haben.
Und das ist natürlich der Nachteil, es ist relativ einfach, haben Sie
ja gesehen, und es gibt eine intuitive globale Schätzung, ist leider
nicht übertragbar.
Jemandem, der noch nie einen Übersetzer geschrieben hat, für den ist
diese Schätzung wahrscheinlich zu optimistisch.
Es ist keine allgemeine Vorgehensweise, weil ich eben nur über diese
Analogien arbeiten kann, und wenn ich die nicht habe, dann geht sie
nicht.
Aber wenn Sie können, benutzen Sie es, das klappt.
Sie können natürlich auch sagen, naja, wenn ich nicht etwas sehr
Ähnliches habe, vielleicht gibt es etwas, das ein bisschen weiter weg
ist, mit ähnlicher Entwicklung, und ich habe bestimmte Erfahrungswerte
gesammelt.
Und da nehme ich jetzt Faktorenlisten oder Richtlinien her, das sieht
etwas so aus.
Da sagen Sie, also unser Standard ist C, 100% gleich 100%.
Wenn Sie in COBOL die gleiche Funktion schreiben müssen, dann rechnen
wir 20% drauf.
Das ist unsere Erfahrung mit COBOL-Projekten.
Und wenn Sie in Assembler schreiben, dann rechnen wir 40% drauf.
Das ist sogar noch relativ harmlos.
Wenn die Teilnehmer, die da programmieren, eine Programmiererfahrung
von 300 Jahre sind, dann sind das 1,0 oder 100%.
Wenn Sie fünf Jahre haben, dann können wir erwarten, dass Sie
schneller arbeiten.
Das heißt, von nominal 100 Einheiten, sagen wir Tagen, würden die nur
80 brauchen.
Und wenn Sie erst ein Jahr haben, dann schlagen wir 40% drauf.
Dateiorganisation, das ist eine spezielle Art von Dateiorganisation
auf Großrechnen, sequenzieller Dateizugriff, da sagen wir, es gibt 80
Punkte indexsequenziell, das heißt, Sie haben eine Dateistruktur, die
einen Index dazu hat, in dem Sie schneller positionieren können.
Das ist immer mühsam auszurechnen.
Sagen Sie, wenn das auf diese Dateiorganisation berührt, dann kriegt
das 120 Punkte.
Werden Sie vielleicht nie erleben, diese Art Problematik, es sei denn,
Sie arbeiten mit sogenannten Mainframes.
Aber da geht es eben darum, das ist jetzt nur ein Platzhalter für
andere Dinge, da sagen Sie, wenn ich nur eine textuelle Schnittstelle
brauche, dann ist das 100 Punkte.
Wenn es aber eine HTML-Schnittstelle sein muss, für das Internet, dann
muss ich da was draufschlagen.
Dazu brauchen Sie einen Vergleichswert und das versuchen Sie aus Ihren
vergangenen Projekten irgendwie abzuleiten oder auch sonst einfach zu
schätzen.
Dann haben Sie also diese Faktoren und dann sagen Sie, okay, und was
mache ich jetzt damit?
Was Sie machen können ist, Sie haben ein neues Produkt in C
realisieren.
Das Durchschnittsteam hat etwa drei Jahre Programmiererfahrung, es ist
die indexfektuelle Dateiorganisation zu verwenden und wir hatten eine
ähnliche Entwicklung von ähnlichem Umfang, aber nicht die gleiche
Software von ähnlichem Umfang, in Assembler programmiert, mit
sequenziellen Dateiorganisationen und ein Team mit fünf Jahren
Programmiererfahrung.
Kann ich das für das hier benutzen?
Und das ist natürlich so hingeschrieben, dass das tatsächlich geht.
Dann sagen Sie jetzt folgendes, wenn alle drei Faktoren den Aufwand
gleichgewichtig beeinflussen, das ist wieder die Annahme, die dahinter
ist, wenn ich von Assembler zu C ist, dann ist es da, wir hatten ja
ein Assemblerprogramm, C ist 100, also kostet mich das 40 Prozent
weniger.
Fünf Jahre statt drei Jahre Programmiererfahrung, das heißt, die
brauchen nur 80, ich brauche jetzt 20 mehr, weil ich drei Jahre gehabt
habe und sequenziell zu indexsequenziell, das heißt sequenziell 80 zu
120, das heißt 40 Punkte mehr, 40 Prozentpunkte, aufaddiert, das heißt
am Schluss bleiben nur noch 20 Punkte extra Aufwand übrig.
Und dann sage ich, wenn das neue Projekt vom Umfang größer oder
kleiner ist, kann ich halt noch einen zusätzlichen Abschlag machen,
Abschlag oder Aufschlag.
Wenn es gleich ist, dann sage ich einfach, nehme die Werte von damals,
rechne 20 Prozent drauf und dann ist das eine brauchbare Schätzung.
Wenn das System allerdings doppelt so groß ist, dann muss ich
natürlich die Kosten auch noch mal verdoppeln.
Eine andere Schätzungsmethode, die auch ein bisschen mit Analogie
arbeitet, aber besser formalisiert ist, weil es die einzelnen
Faktoren, die die Richtung, die die Schätzung beeinflussen, explizit
aufgeführt sind.
Programmiererfahrung, Programmiersprache, technische Gesichtspunkte,
wie zum Beispiel die Dateiorganisation.
Ok, ich gebe es zu, es ist an mehreren Stellen diese Rechnung, hier
muss man immer fragen, was ist 100 Prozent,
aber egal, man macht es so.
Ich könnte es noch genauer rechnen, aber ich gehe von so ungenauen
Vorgaben aus, dass es sich nicht rentiert.
Das ist also die Relationsmethode.
Und dann gibt es noch eine Methode, das ist die Multiplikator-Methode.
Die Multiplikator-Methode ist ein bisschen verwandt mit dem, was wir
vorhin hatten, aber jetzt sagen wir, wir haben Teilprodukte, die ich
bestimmten Kategorien zuweisen kann.
Das Beispiel, das wir hatten, ist Steuerprogramme, Ein- und
Ausgabeprogramme, Datenverwaltungsroutinen und Algorithmen.
Nehmen wir an, wir haben diese Kategorien.
Heute würde vielleicht hier noch am Punkt stehen, Mobilität.
Und dann sage ich, ich versuche jetzt zu schätzen, welchen Anteil
diese vier Kategorien in dem zukünftigen System haben, und zwar in
Anzahlzeilen -Code, in etwa.
Und dann gewichte ich die mit Aufwandsfaktoren.
Also, das sehen Sie jetzt gleich.
Also, hier ist das Beispiel.
Sie sagen also, Sie haben Steuerprogramme, Ein-Ausgabe,
Datenverwaltung, Algorithmen.
Sie haben ein Steuerprogramm, setzen Sie das auf 500 Zeilen.
Dann haben Sie Ein-Ausgabeprogramme, eins mit 700 Zeilen und zwei mit
500 Zeilen.
Das sind also insgesamt 1700 Zeilen Ein-Ausgabeprogramme.
Dann sagen Sie, Datenverwaltungszeugs, da habe ich eins mit 800, zwei
Komponenten mit 250, Summe ist 1300.
Und dann sagen Sie, Algorithmen, das ist speziell kompliziert, aber da
haben wir sechs Stück, deren Summe insgesamt 800 ist.
Und dann sagen Sie, also ich brauche jetzt wieder Zeilen-Code.
Und dann sagen Sie, ich habe einen Aufwandsfaktor, das leichteste, das
wird mit 1,0 gewichtet, sind die Datenverwaltungsroutinen.
Und das schwierigste ist Algorithmen, da habe ich einen Aufwandsfaktor
von 2.
Das heißt also, diese Zeilen-Code werden stärker gewichtet.
Mit dem Faktor 2, 1600, 1300 und die hier sind irgendwo in der Mitte,
1,5 und 1,8.
Und dann rechne ich das um in bewertete Zeilen-Code oder nominelle
Zeilen von Code und summiere das Ganze auf.
Gesamt kommt da also von der Standard-Zeilen-Code 6053 heraus.
Wenn ich jetzt dann von einem vergangenen Projekt weiß, wie viel
Zeilen -Code dieser Sorte es hatte und wie viele Personenmonate dafür
benötigt wurden, kann ich mit einer ganz normalen Drei-Satz-Rechnung
herausfinden, was das hier kostet.
Okay.
Das wäre also die Multiplicator-Methode.
Um das natürlich machen zu können, Sie sehen schon, es wird immer ein
bisschen komplizierter, brauche ich natürlich die Daten dafür.
Und wenn ich die nicht habe, kann ich natürlich nichts machen.
Deswegen gibt es in größeren Firmen eben diese Datensammlung, die
sagt, bei jeder Entwicklung halten wir fest, zu welcher Kategorie die
Software gehörte, überlegen uns gelegentlich, welche neuen Kategorien
wir brauchen und beobachten, was die Zeile-Code für diese Kategorie
kostet.
Wir können das ja dann sehen.
Wir wissen, wie lange die Leute daran gearbeitet haben, wir wissen,
wie viele Zeilen-Code drin vorkommen, da haben wir ein spezielles
Programm, das das automatisch zählt.
Durch die Personenmonate dividiert und dann wissen wir, was der
Aufwandsfaktor ist.
Aber man muss das wollen und die Buchführung auch einführen.
Gibt es Fragen dazu?
Datensammlung, haben wir, technischen Fortschritt müssen wir auch
berücksichtigen, das ist natürlich klar, gewisse Kategorien
verschwinden, manchmal werden Kategorien besser, manchmal werden sie
schlechter.
Wenn es keine Fragen gibt, dann machen wir gleich weiter.
So, jetzt erzähle ich Ihnen noch eine andere Methode, gleich mit dem
Hinweis, sie funktioniert nicht, ich erzähle es Ihnen nur, damit Sie
es wissen, wenn es jemand vorschlägt, sagen, vergiss es.
Die Idee ist folgendermaßen, Sie sagen, Sie schätzen den Aufwand für
die Phasenaufteilung.
Sie sagen zum Beispiel, ich nehme an, für die Definition brauchen wir
30%, Entwurf 30%, Codierung 15-20%, Testnummer 20-25%, die Zahlen
haben Sie irgendwo aus anderen Projekten her.
Und dann sagen Sie folgendes, Sie sagen, jetzt schauen wir mal, wie
lange wir für die Definition brauchen.
Wenn wir für die Definition schon 6 Monate erfordern, dann sind es ja
nur 30%.
Das heißt, 10% wären 2 Monate und 100% 20 Monate.
Das heißt, aus der Beobachtung, wie lange wir bei der Definition
brauchen, schließen wir auf das Ganze.
Wenn wir die Aufteilung dieser Art kennen.
Klingt ziemlich schlau.
Zunächst mal klingt das ziemlich schlau.
Man sagt, wir müssen nur einen Teil der Entwicklungsschritte machen,
wir wissen, welchen Gesamteinteil das haben wir, damit können wir
hochrechnen.
So ähnlich wie bei den Wahlvorhersagen.
Das Dumme ist leider, also man kann sie frühzeitig einsetzen, aber der
Nachteil ist, dass die empirischen Untersuchungen gezeigt haben, dass
diese Aufteilung höchst instabil ist.
Manchmal ist eben die Definition nur 5% und der Entwurf auch 5% und
die Hauptarbeit ist dann die Implementierung oder die Hauptarbeit ist
irgendwo im Entwurf.
Also diese Grenzlinien sind leider so, dass sie von Projekt zu Projekt
völlig anders sein können und damit funktioniert die ganze Methode
nicht.
Also, das nur zu dem Punkt.
Zunächst mal eine bestechende Idee, aber in der Praxis nicht
durchführbar.
Wenn also jemand zu Ihnen kommt, machen wir es doch so, machen wir es
doch so, dann sagen Sie, da gibt es empirische Untersuchungen, die
gezeigt haben, die funktioniert überhaupt nicht, die Funktioniert
tatsächlich überhaupt nicht.
Drastisch überhaupt nicht.
Gut, wenn Sie dann mal wissen wollen, was die empirische Untersuchung
ist, das kann ich Ihnen dann geben.
Das schauen wir uns zum Beispiel an in der Vorlesung empirische
Softwaretechnik, da schauen wir uns diese Methode an und die
entsprechende Untersuchung davon, aha, so haben die das gemacht.
Wir haben tatsächlich mehrere Projekte untersucht und unter
verschiedensten Gesichtspunkten analysiert und kamen zu dem Schluss,
geht nicht.
Die anderen Methoden gehen auch nicht perfekt, aber sie sind
brauchbar.
Also, keine der Methoden allein ist ausreichend.
Je nach Zeitpunkt und Kenntnis des, was man hat, soll man die
geeignete Methode einsetzen.
Je mehr man natürlich weiß, je länger ein Projekt fortgeschritten ist,
desto besser kann man es schätzen.
Wenn Sie eine frühzeitige Schätzung abgeben müssen, die ist natürlich
naturgemäß ganz grob, dann nehmen Sie die Analogie-Methode, wenn sie
geht, oder die Relations-Methode, wie ich Ihnen gesagt habe.
Oder, wenn Sie Einflussfaktoren und bei der Entwicklung genauer
bekannt sind, ist klar, wenn ich ganz am Anfang stehe, ist mir nicht
klar, wie viel Ein-Ausgabe-Programm ich haben werde.
Da muss ich zumindest einen groben Entwurf gemacht haben.
Aber dann könnte ich die Multiplikator-Methode benutzen.
Und wie gesagt, die Phasen-Aufteilungs-Methode benutzen wir nicht.
Das ist jetzt die Grundidee.
Ich zeige Ihnen später noch zwei, es kommen noch drei Schätzmethoden.
Das eine ist die Kokomo-Methode, das andere sind Konsens-Methoden.
Die kann man natürlich jederzeit auch benutzen.
Die Kokomo-Methode.
Kokomo, wie gesagt, heißt Constructive Cost Model.
Das erste kam 1981 heraus, das Kokomo jetzt, das Kokomo 2.
Es gibt auch ein Kokomo 3, aber das Kokomo 3 ist so kompliziert, dass
ich eigentlich bezweifle, dass es überhaupt angewendet werden kann.
Kokomo 2 geht aber schon.
Und das arbeitet wieder mit einer Formel.
Und diese Formel sagt also zunächst mal, ich brauche den Size, also
die Größe, und herauskommen würde Anzahl Personenmonate.
Und das Zeug muss ich Ihnen jetzt erklären.
A ist also vorne eine Konstante, die ich schonmal für das
Modellkalibrieren einsetzen kann.
Und zum Beispiel könnte ich die Größe in Zahlen Code berechnen.
Also dann muss ich Zahlen Code schätzen.
Oder was eigentlich besser ist, die sogenannten Funktionspunkte.
Aber die Funktionspunkte kennen wir noch nicht.
Ich sage Ihnen nur kurz, was es ist.
Bei Funktionspunkten sagt man, welche Funktion muss die Software
eigentlich erfüllen und zählt diese Funktionen?
Nicht die Zahlen Code, die zu ihrer Implementierung notwendig ist.
Und dann gibt es noch ein kompliziertes Bewertungsschema, dass jeder
dieser Funktionen dann Punkte zuordnet, je nachdem, wie kompliziert es
ist.
Wenn es zum Beispiel ein Dialog orientiert, der ein Ausgabezeile Code
ist, dann sage ich, gebe ich dem mehr Punkte als was ganz einfaches in
einer Datei zu schreiben.
Aber wie gesagt, Funktionspunktmethode, dafür reicht uns die Zeit
nicht.
Wir tun also so, als hätten wir hier nur Zahlen Code und entsprechend
müssen wir hier das anpassen.
Das ist mal das Einfache.
So, das sind die sogenannten Skalierungsfaktoren.
Und jetzt müssen wir kurz diese Formel anschauen.
Das steht nämlich im Exponenten.
Das sehen Sie, das ist 1,01, also etwas mehr als 1 plus die Summe
dieser Skalierungsfaktoren.
Ich sage Ihnen gleich, welche das sind.
Das sind 5 Stück.
Wir werden noch mal mit 0,01 multipliziert.
Die Skalierungsfaktoren haben einen Wert von 3.
Das heißt also, hier oben steht ein 1,0 ein bisschen was.
Das heißt, wenn die Größe wächst, dann wachsen die Anzahl
Personenmonate überproportional.
Das ist so eine Kurve, die einfach nach oben steigt.
Exponentialkurve, aber eine relativ flach steigende Exponentialkurve.
Ich habe gleich noch ein Bild dafür.
Das hat also den Grund, dass man sagt, die Größe, die Software wird,
dann werden bei bestimmten Einflussfaktoren, oder auch wenn die alle
nominell wären, steigt es überproportional mit der Größe.
Das kriegen wir also hier raus.
Dann gibt es noch lineare Skalierungsfaktoren.
Das sind die Kostenfaktoren.
Das gibt 17 Stück davon.
Da können Sie sich dann aussuchen, was Sie brauchen.
Gut, das habe ich gesagt.
Jetzt schauen wir uns die Skalierungsfaktoren an.
Die stehen also hier vorne.
Presidentedness, Development Flexibility, Architecture, Risk
Resolution, Team Cohesion, Process Maturity.
Presidentedness heißt, haben wir sowas schon mal gemacht?
Gibt es davor einen Präzedenzfall?
Daher presidentedness.
Thoroughly unprecedented heißt, kennen wir überhaupt noch nicht.
Be thoroughly familiar.
Das ist unser tägliches Brot.
Inzwischen ist es somewhat unprecedented.
Largely unprecedented.
Da müssen Sie sich so einen Wert hier schätzen.
Dann gibt es Development Flexibility, das heißt, wie flexibel ist Ihr
Entwicklungsteam?
Und das geht jetzt also auch von ganz streng eingespannt, was schlecht
ist, zu sehr flexibel.
General Goals können Sie ausführen.
Was tun wir, um Probleme in der Architektur, in der Software
-Architektur zu lösen?
Geschieht da viel oder wenig?
Und ein paar Punkte dazwischen.
Wie oft passiert das?
Dann, wie gut arbeitet das Team zusammen?
Sehr schwierige Interaktionen, bis total integriert.
Basically cooperative hier sieht so etwas in der Mitte.
Das sind also immer, übrigens hier oben stehen auch noch die Werte
dafür.
Und die Prozessreife, das heißt, da gibt es ein Prozessreifemodell,
haben wir auch noch nicht besprochen, das heißt das CMM, das hat so
mehrere Fragen und da nimmt man einfach die Antwort, die Ja-Antworten,
haben wir, haben wir nicht?
Zum Beispiel ist eine der Fragen, gibt es Software
-Konfigurationsmanagement, Versionshaltung, nutzen Sie sowas wie
Bugzilla und ähnliche Fragen kommen davor, müssen wir auch nicht genau
anschauen, aber dann nimmt man die Dinge zusammen und die Antworten
und gewichtet sie, macht die Software dann schon die Gewichtung.
Und dann hat man diese Skalierungsfaktoren.
Die multiplikativen Kostfaktoren, wie gesagt, 17 Stück, da ist
voreingestellt ein Nominalwert von 1 und nur wenn Sie davon abweichen,
nach oben oder nach unten, stellen Sie einen anderen Wert ein.
Produktfaktoren, zum Beispiel die Zuverlässigkeit, die Datenbankgröße,
die Produktkomplexität, die erforderliche Wiederverwendbarkeit, wenn
man Software so baut, dass sie in anderen Projekten wiederverwendet
werden kann, erfordert sie mehr Aufwand.
Dokumentation, Plattformfaktoren, wie zum Beispiel Ausführungszeit,
Hauptspeicherbedarf, Plattformveränderbarkeit, wird da ein neues
Betriebssystem eingegeben, Computer-Turnaround-Time für Simulationen,
weniger wichtig, Personalfaktoren, nämlich wie gut sind die Analysten,
die Programmierer, die Anwender, die Plattformerfahrung, die
Vertrautheit mit Sprachen und Werkzeugen und wie stark das Personal
wechselt.
Also Continuity ist das Gegenteil von Wechseln natürlich, sondern
Personalbestand gleichbleibend.
Projektfaktoren, moderne Programmierpraktiken, Softwarewerkzeuge,
Multi -Site Development, das heißt, ist die Produktentwicklung über
mehrere Standorte verteilt, was zusätzliche Probleme verursacht, die
sogenannte globale Softwareentwicklung, nicht ein Team in Nürnberg,
ein Team in Bangalore und ein Team in New Jersey.
Dann haben sie großartige Softwareprobleme.
Ist der Abwicklungsplan, Durchführungsplan für das Projekt sehr eng,
dann gibt es nach unseren Faktoren da auch ein Problem.
Je schneller wir arbeiten müssen, desto weniger Qualität, desto höher
die Kosten.
Classified Security Application ist auch noch sicherheitsrelevant.
Sie sehen schon, eine Reihe von Faktoren müssen Sie auch für die
Prüfung nicht auswendig wissen, ich würde das auch nachschauen, aber
Sie sollten schon wissen, ein oder zwei aus dieser Klasse und die
ungefähre Form und die Form dieser Formel.
Größe im Exponenten, Skalierungsfaktoren und hinten noch ein Produkt
von anderen Einflussfaktoren, Kostenfaktoren.
Wäre natürlich nicht Informatik...
Achso, jetzt wollen wir noch mal schauen, wie sich das Zeug verhält.
Wie sieht denn so eine Kurve aus?
Also, gehen wir an, das A habe den Wert 3, alle Kostenfaktoren hier
hätten den Wert 1, das ändert sich also an der Multiplikation gar
nichts.
Die Skalierungsfaktoren sind jetzt folgendermaßen, wir haben ja hier
dieses B und wir variieren jetzt das B zwischen 1,26,1,16 und 1,01.
In diesem Fall haben Sie alle den Wert 0.
Hier haben Sie alle den maximalen Wert, nämlich 5, dann kommt 1,26
raus und hier haben Sie alle den Wert 3, das ist der Nominalwert in
der Mitte, dann kommt 1,16 raus.
Und dann schauen wir mal, was mit dieser Formel passiert.
Und dann variieren wir auch die Projektgröße zwischen 10.000 und 10
Millionen.
Brauchen wir eine logarithmische Skala.
Das heißt, wir schauen diese Formel an.
Dreimal Größe hoch B, B variiert und das ist das, was rauskommt.
Also, Skalierungsfaktor sehr niedrig, von 54 bis 300, bis 205.000.
Sie sehen hier, nicht ganz so weit, 100.050, 175, was ist das hier
hinten, 205.000, also es geht noch ein bisschen weiter, müsste noch
ein bisschen weiter, da brauche ich dann, wie gesagt, noch mehr Platz.
Aber Sie sehen schon, wenn die Skalierungsfaktoren sehr niedrig sind,
dann geht die Kurve natürlich in diese Form, das heißt von 100.000 auf
200.000, das wäre diese und diese hier habe ich mehr als eine
Verdopplung.
Da wäre ich bei Kosten von Personenmonaten von 1.000 bei 100.000
Zeilen Code und hier ein bisschen mehr habe ich 2.500 Personenmonate.
Das zur Überproportionalität und wenn die Skalierungsfaktoren extrem
gut sind, dann sieht die Kurve auch noch etwas flacher aus.
Aber das ist die Vorstellung davon, dass je größer das Projekt ist,
desto überproportional, mit dem Projektgröße wächst der Aufwand
überproportional.
Das ist diese Beispielrechnung.
Und natürlich gibt es eine Software, die das macht für Sie.
Das schaffen wir gerade noch.
Und zwar da können Sie nachschauen, wo das ist oder Sie schauen
einfach nach Kokomo und da gibt es ein Formular, da können Sie
Presentedness, Development, Flexibility, diese fünf Dinge, Skalen,
Faktoren eingeben und die Produktattribute hier unten von very low bis
very high.
Natürlich müssen Sie angeben, wie viel Zeilencode Sie brauchen.
Das gibt es neu.
Aber es gibt auch die Unterscheidung davon, wenn man vorhandene
Software modifiziert, auch das können Sie eingeben.
Also Anzahlcode neu, Prozent geändert, Entwurfprozent vom Code
verändert, wiederverwendet und sofort.
Dann kommt eine magische Zahl raus und zum Beispiel war dieses Modell
sehr, sehr wichtig bei den Verhandlungen über Toll Collect, wo es ja
darum ging, dass Toll Collect nicht rechtzeitig rauskam und die
Behauptung der Auftraggeber war, wir hätten falsch geschätzt.
Also mussten wir dieses Modell unter anderem an, um nachzuprüfen, wie
schlecht die Schätzung tatsächlich war.
Ob sie schlecht war oder nicht, das sei dahingestellt.
Da gibt es die Webseite dazu, finden Sie, geht gleich weiter, aber
nachdem wir noch sechs Minuten haben, gebe ich Ihnen die letzten
beiden Schätzmethoden, die sind jetzt Konsens basiert.
Wir hatten also bis jetzt immer gesagt, wir schätzen die Anzahl
Codezahlen und dann rechnen wir damit rum.
Wir skalieren, wir unterteilen, wir haben Kategorien, wir haben
Aufwandsfaktoren und dann haben wir Formeln, das sind also
Berechnungsmodelle.
Das hier ist eine Schätzmethode, die beruht auf Konsens von Experten,
Sie möglicherweise.
Da gibt es zwei verschiedene, die Delphi-Methode und die
Planungspoker.
Die Delphi-Methode funktioniert ganz einfach, man setzt sich zusammen,
das ist die Runde der Schätzer oder Experten.
Jeder der Schätzer gibt anonym einen Schätzwert ab, mit einer
Begründung und schreibt das auf eine Karte.
Ohne dass er die Schätzwerte anderer sieht, deswegen Delphi.
Da gibt es einen Moderator, der sammelt diese Karten ein, schaut sie
sich an, er weiß nicht von wem sie kommen, aber er sieht natürlich die
Werte und fasst dann die Zusammenergebnisse auf, erklärt sie und wenn
jetzt die Ergebnisse weit auseinanderliegen, zum Beispiel der eine
sagt, da brauchen wir einen Monat und der andere sagt, da brauchen wir
ein halbes Jahr, dann muss das diskutiert werden, wird die Begründung
vorgelesen unter Umständen, aber es ist nicht erforderlich, dass
derjenige, der die Schätzung abgegeben hat, sie nochmal erklärt und
dann macht man eine weitere Runde.
Das heißt also, es ist eine Art Demokratie basierend gegenseitiges
Beeinflussen.
Die Idee ist, dass hoffentlich die Schätzungen zum richtigen oder zu
einem einigermaßen brauchbaren Wert konvergieren.
Wenn sie das nicht tun oder wenn sie sich nicht mehr ändern, jeder
besteht auf seiner Schätzung, wir brauchen unbedingt sechs Monate, das
geht überhaupt nicht, das habe ich letztes Mal schon...
Spinnst du, das mache ich in einer Woche mit ein paar Studenten.
Okay, dann tut sich nichts mehr und dann machen sie einfach den
Mittelwert.
Wichtig dabei ist, dass die erste Schätzung eben unbeeinflusst ist von
den Teilnehmern.
Denn das ist eine Persönlichkeitsfrage, manchmal ist dadurch klar,
dass der Manager es so schnell haben möchte, wie möglich.
Das heißt, das könnt ihr doch alles in zehn Tagen, das ist doch alles,
was ihr braucht.
Während der Entwickler genau die gegenteilige Ansicht hat, er will auf
Nummer sicher gehen und gibt die Schätzung eher zu hoch an.
Also zwei Monate brauchen wir da schon.
Und diese Schätzungen sollten eben zuerst mal gegeben werden, ohne
dass man von einem anderen mit beeinflusst ist.
Die Beeinflussung ist zwar sehr subtil, aber sie ist da.
Das ist die Delphi-Schätzmethode und der Planungspoker ist eine
Variation davon.
Der Planungspoker sieht so aus, dass alle Teilnehmer einen
Kartenstapel bekommen, der bedeutet ihre Schätzung.
Und der Stapel ist so, dass die Zahlen zum Beispiel sind sowas wie
Fibonacci -Zahlen, sie steigen also kräftig an.
Da gibt es also 0, 1, 1, 2, 3, 5, 8, 13, 20, 40, 100 und weiß nicht.
Also Fragezeichen bedeutet, unmöglich zu schätzen.
Ähnlich wie bei der Delphi-Methode überlegt sich jetzt jeder, wie
lange er denkt zu brauchen.
Die Einheiten muss man sich natürlich voraus angeben, gibt es in
Stunden an, rechnet es in Tagen oder in Monaten.
Dann legt jeder Teilnehmer seine Karte auf den Tisch mit der Zahl nach
unten.
Wenn jeder das gemacht hat, dann werden alle Karten gleichzeitig
aufgedeckt.
Und der Schätzer mit den hohen und niedrigen Werten dürfen jetzt
aufstehen oder sitzenbleiben und erklären, wieso sie zu diesen Werten
kamen, ähnlich wie bei Delphi.
Und dann wird dieser Prozess wiederholt, bis hoffentlich sich ein
Konsens einstellt.
Auch hier anonym, die erste Schätzabgabe anonym.
Und wenn sie jetzt weit draußen liegen, haben sie die Freude oder die
Peinlichkeit, das erklären zu müssen.
Und wenn man das dann durchdiskutiert hat, dann hofft man eben auf
einen besseren oder genaueren Schätzwert hinzukommen.
Ohne, dass man viel rechnet, sondern einfach eine Schätzung aus dem
Bauch heraus.
Das war jetzt meine letzte Schätzmethode.
Gibt es noch Fragen?
Also, wenn Sie in die schöne oder unbequeme Lage kommen, eine
Schätzmethode abzugeben, und Sie haben überhaupt keine Daten, dann
sagen Sie uns hier im Chef, eigentlich müssen Sie jetzt eine
umfangreiche Datensammlung machen und mir die geben, den Zustand,
damit ich die Schätzung benutzen kann, die ich zur Schätzung benutzen
kann.
Wenn Sie das nicht haben, dann machen wir entweder eine Analogie
-Schätzung, weil wir sowas schon mal gemacht haben, oder aber wir
machen die Methode.
Planning Poker, das ist ein schönes modernes Wortchen mit den agilen
Methoden verknüpft und macht jedem Spaß, das mal so zu machen mit den
Karten.
Es gibt sogar ein App dazu, wie kann es anders sein, man kann es auch
sogar mit seinem Telefon machen.
Und das würde ich dann empfehlen.
Und diese agilen Methoden, die lernen wir dann am Mittwoch kennen.
Vielen Dank und bis dann.