***************************************************************** ** Filename: $RCSfile: lessonsLearned.txt,v $ ** Revision: $Revision: 1.6 $ ** **-------------------------- History ---------------------------- ** $Log: lessonsLearned.txt,v $ ** Revision 1.6 1999/07/16 16:31:38 vorwiege ** lange Liste hinzugefuegt. ** ** Revision 1.5 1999/05/23 13:16:06 vorwiege ** hinzugefuegt: ** - Praktikumsdurchfuehrung/Projektmgt; Nr 5 ** ** Revision 1.4 1999/05/12 08:57:55 vorwiege ** hinzugefuegt: ** ** - Praktikumsdurchfuehrung/Projektmgt 3 + 4 ** - Verwendete Werkzeuge 3 ** ** Revision 1.3 1999/05/11 12:10:34 vorwiege ** Ansprechpartner hinzugefuegt. ** ** Revision 1.2 1999/05/11 08:18:51 vorwiege ** Hinzugefuegt: ** ** - Praktikumsdurchfuehrung/Projektmgt 2 ** - Entwicklung - Erstellung von Szenarien 8 ** - Entwicklung - Statediagramme 4 ** - Testfall-Erstellung Akzeptanztest 1 ** ** (Stefan) ** ** Revision 1.1 1999/03/14 22:32:15 vorwiege ** Initial revision (Antje + Stefan) ** ** **---------------------- Description ---------------------------- ** ** Informelle, strukturierte Beschreibung der Erfahrungen ** aus dem Praktikum SE-I Sommersemester 99 ** **---------------------------------------------------------------- ****************************************************************** Erfahrungen aus dem SE-I Praktikum 99 ===================================== Praktikumsdurchfuehrung/Projektmgt ================================== 1 Es scheint sinnvoll zu sein, den Studenten die Systemdokumentation des urspruenglichen Systems ausgedruckt vorzugeben. Ansonsten schauen sie sich die Dokumente nicht an. (AP: Antje) 2 Kommunikationskanaele etablieren, wenn Gruppen an unterschiedlichen Teilsystemen mit gemeinsamer Schnittstelle arbeiten; z.B.: email Gruppen-Aliase, ... (AP: Stefan) 3 Fuer die Durchfuehrung der verschiedenen Verifikationen sollte mindestens 1,5 Wochen geplant werden: - lesen (0,5) - Sitzung (0,5) - rework (0,5) Dabei spielt es keine Rolle, ob von externen Gruppen gelesen wird, da auch diese ca. 0,5 Wochen fuer einen Review benoetigen. Der Vorteil, der sich aus der Auslagerung der Leseaktivitaet ergibt, ist die Reduzierung des Aufwandes fuer die Praktikanten, nicht jedoch Vorteile fuer den Zeitplan! Der Zeitraum, der fuer die Sitzungen geplant ist, resultiert aus der Koordination von fuenf Terminen, an denen jeweils zwei Gruppen beteiligt. Diese muessen sich dann innerhalb von 2,5 Tagen (=0,5 Wochen) alle! getroffen haben. Eine Sitzung darf dabei nicht laenger als 2,5 Stunden sein. Dies ist jedoch fuer die aufwendigeren Gruppen nicht machbar! (s. schon die weiniger aufwendige Analyse-Verifikation) Der daraus resultierende hohe Aufwand fuer die einzelnen Mitglieder liegt darin begruendet, dass diese Sitzungen nicht parallelisierbar sind! => Bei gegenseitigen Reviewn sollte darauf geachtet werden, dass komplexere Gruppen mit weniger komplexen gemischt werden!!! (AP: Stefan + Antje) 4 Beruecksichtigung der Feiertage bei der Planung (Zeitplanung)! (AP: Antje + Stefan) 5 Bereits in der Analysephase sollen zumindest die Dokumentationsrichtlinien als Basis fuer die Namensvergabe zur Verfuegung gestellt und verwendet werden, um eine Verfolgbarkeit der Namen bis zum Code hin zu ermoeglichen. Bei der Erstellung der Problembeschreibung/B-Anforderungen sollte diesen Richtlinien ebenfalls Rechnung getragen werden. (AP: Stefan + Antje) Generierung von Dokumenten ========================== 1 Die Generierung von Dokumenten sollte nicht von den Gruppen sondern vom Betreuer/betreuenden HiWi vorgenommen werden. Vor der Generierung muessen alle unref'd objects aus dem StP-Repository geloescht werden. (AP: Antje) 2 Versionierung ist ebenfalls problematisch, wenn Generierung von unterschiedlichen Gruppen uebernommen wird. (AP: Antje) 3 Existierende Skripte scheinen die Aktualisierung der Dokumentation wesentlich zu erleichtern. (AP: Antje) Verwendete Werkzeuge ==================== 1 StP stuerzt teilweise ab. Sicherheitshalber zwischendurch abspeichern. (AP: Antje) 2 Einen runden Pfeil in einem parallelen Zustand bekommt man, wenn man den Pfeil aus dem Zustand herauszieht und fallenlaesst. Anschliessend mit dem gewuenschten State verbinden. (AP: Antje) 3 Studenten rufen versehentlich die falsche FrameMaker-Version auf (5 statt 4). Dies kann verhindert werden, wenn sie eine entsprechend vorbereitete Oberflaeche uns aliase erhalten, die default-maessig nur die Version 4 des FrameMaker aufrufen. (AP: Antje + (Stefan)) Entwicklung - Erstellung von Use Cases ====================================== 1 Use Cases werden von Personen mit Programmiererfahrung funktional verstanden. Typisches Problem: Einzelne Use Cases modellieren Teilfunktionen des Systems und Use Case Diagramm spiegelt die notwendigen Informationen, die zur Erbringung einer Teilfunktion relevant sind, wider. Zur Vermeidung dieses Problems ist es besser keine Verfeinerung von Use Cases vorzunehmen. Es sollte betont werden: Ein Use Case modelliert eine typische Systemnutzung von ausgehendem Akteur bis zu einem Verhalten des Systems. Wenn ein Use Case ein anderes benutzt, muss man das Use Case mit dem anderen fortgesetzt werden koennen. (AP: Antje) 2 Fuer jeden Use Case sollte ein Akteur benennbar sein, der das Use Case ausloest. (AP: Antje) 3 Mehrere Akteure in einem Use Case koennen evtl. durch zwei Use Cases modelliert werden. (AP: Antje) 4 Im Use Case Diagramm sollten alle Aktuatoren der Strukturbeschreibung auftauchen. Ein Autreten aller Sensoren ist nicht notwendig, da sie nur dann eingezeichnet werden, wenn sie ein Verhalten eines Systems ausloesen. (AP: Antje) 5 Als Akteure werden Sensoren eingezeichnet, nicht interne Controller, die die Sensoren regelmaessig abfragen. Die Sensoren veranlassen die System- reaktion eigentlich, auch wenn dies dem System erst durch eine Controllerabfrage mitgeteilt wird. (AP: Antje) Entwicklung - Erstellung von Szenarien: ======================================= 1 Ein Szenario modelliert nur eine Interaktionssequenz. Das bedeutet, dass ein Szenario mit der ersten Systemreaktion endet. Verschiedene Systemreaktionen gehoeren in unterschiedliche Szenarien. (AP: Antje) 2 Alle im Szenario benoetigten Variablen muessen im Szenario beschrieben werden (AP: Antje) 3 Ein Szenario modelliert eine konkrete Interaktionssequenz des Systems. Es enthaelt daher konkrete Werte. (AP: Antje) 4 Ein Szenario enthaelt alle Bedingungen, die fuer die Systemreaktion wichtig sind. (AP: Antje) 5 Ein Szenario eines Use Cases soll durch jedes Szenario eines anderen Use Cases fortsetzbar sein, wenn eine Benutzrelation zwischen den Use Cases besteht. (AP: Antje) 6 Problematisch ist die Durchnumerierung der Szenarien. Werden sie einfach durchnumeriert, tritt das Problem auf, dass ein anschliessendes Einfuegen eines Szenarios die Reihenfolge vollstaendig ueber den Haufen wirft (dies ist insbesondere dann kritisch, wenn verschiedene Gruppen verschiedene Teilfunktionalitaeten des Systems modellieren). (AP: Antje) 7 Je groesser das System, desto groesser auch die Menge der Szenarien. Es sollte ueberlegt werden, ob die Modellierung von Use Cases in der Form von Szenarien nicht sinnvollerweise bevorzugt werden sollte. Siehe hierzu auch die Modellierung von Use Cases bei OCTOPUS. (AP: Antje) 8 Im Falle der Zeitenverwaltung existieren zu einigen Klassen eine Reihe von Instanzen, die jedoch von verschiedenen Benutzer-Anforderungen beschrieben werden. Die entsprechenden Szenarien zu den Instanzen sind aehnlich (gleich bis auf Werte-Belegungen). Einerseits muesste nun jede Benutzer-Anforderung durch ein Szenario abgedeckt werden, andererseits enthalten die Szenarien unnoetige Redundanz mit all ihren bekannten Nachteilen. Loesung: ein Szenario exemplarisch als Vertreter fuer alle Instanzen + Auflistung aller moeglichen Wertebelegungen (s. auch Testfall-Erstellung Akzeptanztest 1) (AP: Stefan) Entwicklung - Klassendiagramm ============================= 1 Die Aktuatoren sollten an die kontrollierende Groesse aggregiert und damit von ihr gekapselt werden. Eine Gruppe ist fuer die Modellierung der Controller-Komponente zustaendig und stellt sie anderen Gruppen zur Verfuegung (AP: Antje) 2 Modellierung von Zeiten erfordert ein anderes Vorgehen als die Modellierung von Regelungsfunktionalitaeten. Gegebene Hinweise zur Modellierung mittels Hilfs- und Regelungsklassen waren wenig hilfreich. (AP: Antje) 3 Bei anderen Gruppen schienen die gegebenen Hinweise, die Modellierung erleichtert zu haben. Die Aufteilung in Klassen schien eher einfach. (AP: Antje) 4 Unklar bleibt die Verwendung von Aggregations- und Assoziationsbeziehungen. An welche Komponente soll ein Sensor/Aktuator aggregiert werden? Strukturklasse oder Controllerklasse? Weiterfuehrende Hilfestellungen waeren sinnvoll. (AP: Antje) Entwicklung - Statediagramme: ============================= 1 Statediagramme sind informell zu beschreiben (AP: Antje) 2 Do-Aktivitaeten: wie kenntlich machen, dass eine Methode laufend aufgerufen wird? Eine Moeglichkeit: alle 5 sec: ... (AP: Antje) 3 Wie sollen Rueckgaben von Methodenaufrufen waehrend der Analyse modelliert werden? Eine Moeglichkeit: mit Hilfsvariablen (AP: Antje) 4 Rein funktionale Teilsysteme (wie z.B. die Modellierung/Verwaltung der verschiedenen Zeitintervalle etc.) kommen ohne State-Diagramme aus. Die Berechnungen/Verwaltung werden durch Activity-Diagramme beschrieben, die an Methodenaufrufe gebunden werden (nicht an die nicht-vorhandenen States ;-) ) (AP: Stefan) Entwicklung - Sequenzdiagramme: =============================== 1 Regeln fuer die Modellierung von Bedingungen im Sequenzdiagramm In Bedingungen darf der Wert einer Variablen referenziert werden. (AP: Antje) Entwicklung Analyse: ======================= 1 Regelungsalgorithmus zu spaet zur Verfuegung gestellt: Benoetigte Algorithmen sollten bereits von Anfang an bereitstehen und bekannt gemacht werden. Es war unklar, was sich die Gruppe ausdenken musste und was bereitgestellt werden wuerde. (AP: Antje) 2 Unzureichende Analysephase: Die vorgegebene Zeit fuer die Feinanalyse war zu kurz. Wenn die Zeit laenger gewesen waere, haette die Gruppe ein Teil der beim Review gefundenen Fehler selbst gefunden. (AP: Antje) Entwicklung Entwurf: ======================= 1 Verwendung des Konzeptes "Klassentemplates" Die Verwendung von Klassentemplates wird von StP nicht ausreichend unterstuetzt. Insbesondere ist unklar, wie Klassentemplates beerbt werden koennen (kein Template) ohne eine tatsaechliche Klasse zu instanziieren. Der Einsatz von Klassentemplates beim Testen hat ebenfalls Schwierigkeiten gemacht, so dies besser vorbereitet werden muss. Weiter ist zu beachten, dass das Konzept der Klassentemplates nicht von allen OO-Sprachen unterstuetzt wird (bei Wechsel z.B. auf Java) (AP: Stefan) 2 Bisher ungenutzte Vererbung im System: Es gibt verschiedene Klassen, die mit Hilfe von Vererbungsbeziehungen vereinfacht werden koennten. Z.B. PRTempController und PRBlindController. Dies sollte bei einer Ueberarbeitung der Dokumente beachtet werden. (AP: Antje) Review-Sitzung Analyse (+allgemein): =================================== 1 Die Checklisten sollten schon zu Beginn der Entwicklung der zu reviewenden Artefakte ausgeteilt werden, da sie weitere Details der Technik/Methode enthalten bzw. hier kompakt beschrieben sind. (AP: Stefan) 2 Fehlerlisten der Reviewer muessen zu Beginn der Reviewsitzung vorliegen. Diese koennen dann in kurzer Zeit gemaess der Ergebnisse der Sitzung korrigiert werden. (AP: Stefan) 3 In den Checklisten werden Activity-Diagramme nicht erwaehnt (AP: Stefan) 4 Die interne Konsistenz sollte an wenigen Punkten noch eingeschraenkt werden, da 'Objekte' referenziert werden, die nicht unbedingt existieren muessen. Beispiel: Sequenzdiagramm -> interne Konsistenz -> 5. - 8. (AP: Stefan) 5 Wird die Ueberpruefung der UML-Syntax nicht schon von StP vorgenommen? (vielleicht in Klammern setzen) (AP: Stefan) 6 Schnittstellen: Insbesondere Fragen zum Ueberpruefen der Schnittstellen zwischen den Teilsystemen waeren hilfreich. (AP: Antje) 7 Entwurf: Beim Review des Entwurfs sollte die Initialisierung ueberprueft werden. Dafuer muessen Fragen in der Checkliste ergaenzt werden. (AP: Antje) 8 Vererbung: Alle Attribute werden als private deklariert, d.h. wollen Unterklassen auf die Attribute zugreifen, benoetigen sie Zugriffsmethoden. Dies sollte bereits im Entwurf beruecksichtigt werden -> Aufnehmen von entsprechenden Fragen in die Checkliste. (AP: Antje) 9 Allgemein: Die Inspektionen fanden immer in der gleichen Gruppenkonstellation statt. Dies fuehrte zur Demotivation bei einigen Gruppenteilnehmern (immer diese Pedanten, koennt Ihr vielleicht einmal richtig reviewen). Es bietet sich daher an, die Inspektionen rotierend stattfinden zu lassen. (AP: Antje) 10 Zeit: Die fuer Inspektionen geplante Zeit war zu kurz. Teilweise waere sogar ein qzweiter Review (nach Durchfuehrung der Aenderungen) sinnvoll gewesen. (AP: Antje) Testfall-Erstellung Akzeptanztest: ================================== 1 Um fuer die Tests die unterschiedlichen Instanzen mancher Szenarien zu beruecksichtigen (s.a. Entwicklung - Erstellung von Szenarien 8), werden diese aehnlich generisch ausgelegt wie die entsprechenden Szenarien. Die Numerierung erfolgt zweistufig (z.B. AK-Test76a..k), um die Aehnlichkeit der Tests zu dokumentieren und entsprechende Aenderungen in der Anzahl der Instanzen beruecksichtigen zu koennen ohne dabei nachfogende Testfall-Nummern zu aendern. (AP: Stefan) Implementierung: ================ 1 Unvollstaendige Implementierungsrichtlinien: Methodenaufrufe vom Init-Zustand zu anderen Zustaenden werden durch die Richtlinien nicht abgedeckt. (AP: Antje) 2 Die Einhaltung der Richtlinien fuehrt dazu, dass die Statenamen im Kode nicht mehr mit denen im Entwurf uebereinstimmen. Vielleicht kann man bereits frueher fuer eine Konsistenz zwischen den Namen sorgen. (AP: Antje) 3 StP Generierung: Die Generierung von Kode sollte angesprochen und von den Betreuern unterstuetzt werden. Bei der Erstellung von Kode von Hand koennen zwar Fehler gefunden werden, gleichzeitig werden durch den manuellen Erstellungsprozess aber auch Fehler integriert. Die Object Annotations werden generiert, was zu einer erheblichen Zeitersparnis fuehrt. (AP: Antje) 4 StP Generierung: Die Generierung von Kode hilft im wesentlichen bei der Neuerstellung. Wird der Kode geaendert, wurde im Praktikum nicht erneut generiert. Hier koennte die Anbindung zu einer Programmierumgebung helfen. (AP: Antje) Komponententest: =============== 1 Ungenuegende Testkriterien fuer Komponenten: Es gibt bisher keine Testkriterien fuer Konstruktoren und Destruktoren. Kommunikation: ============== 1 Die Kommunikation zwischen den Gruppen ist verbesserungswuerdig. Entscheidungen zwischen zwei Gruppen sollten an alle bekannt gegeben werden, um gegebenenfalls weitere betroffene Gruppen ausfindig zu machen. (AP: Antje) 2 Experten (z.B. Queins (Simulator)) sollten frueher in den Entwicklungsprozess einbezogen werden, damit nicht Dinge modelliert werden, die sich nicht realisieren lassen (Fehler nicht zweimal machen) (AP: Antje) Dokumente: ========= 1 Die Beschreibung der Gebaeudearchitektur sollte verbesert werden. Ausserdem sollte Ihre Bedeutung betont werden. (AP: Antje) 2 Die Kommentare der Klassen aus der Bibliothek sollte ausfuehrlicher sein. Z.B. SList - Was liefert get? Das erste Element? (AP: Antje)