Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

05.02.1993 - 

Forscher untersuchen Entwicklungsumgebungen unter Unix (Teil 2)

Testergebnis: JAM/Teamwork ist fuer grosse Gruppen geeignet

Nach dem Motto "Nicht reden, sondern handeln" haben wir im Rahmen unseres dreitaegigen Benchmark-Tests den Performanceumfang einer Entwicklungsumgebung untersucht, indem wir von den Teilnehmern die praxisorientierte Erstellung eines Projekt-Management- Informationssystems mit 135 Funktionspunkten forderten. Der Benchmark-Test war so konzipiert, dass der vollstaendige Werdegang einer Software-Entwicklung unter Normalbedingungen demonstriert wurde.

Der Hersteller beziehungsweise das Vertriebsunternehmen stellte dazu ein Team auf, das mit Hilfe der Entwicklungsplattform die gestellte Aufgabe loeste. Der Benchmark-Test fand beim Vertriebspartner der Jyaccu, der Datenrevision GmbH in Hamburg, unter Aufsicht der Forschungsgruppe statt. Als CASE-Werkzeug fuer die Planung setzte die Gruppe Teamwork von Cadre ein.

Das relativ grosse Entwicklungsteam bestand aus acht Mitgliedern. Dabei reichte die Erfahrung der Teilnehmer vom Anfaenger bis zum Experten. Teamwork wurde von der Gruppe zum ersten Mal benutzt und durch diesen Benchmark-Test vom Team selbst geprueft.

Waehrend des dreitaegigen Tests konnten alle im Anforderungskatalog gestellten Aufgaben zur vollen Zufriedenheit in die Loesung eingebunden beziehungsweise realisiert werden. Die Datenrevision GmbH implementierte in einigen Faellen sogar nach strengeren Massstaeben als in der Spezifikation vorgeschrieben war. Die Vollstaendigkeit der Loesung bewerteten wir daher mit "ausgezeichnet".

Um das geforderte Projekt-Management-Informationssystem zu erstellen, wurden insgesamt 113 Stunden und 50 Minuten benoetigt. In dieser Zeit sind allerdings auch 32 Stunden der Vorbereitung enthalten. Die acht Teammitglieder erstellten die Loesung innerhalb von 21 Stunden und 35 Minuten. Auf den ersten Blick erscheint dieser Zeitverbrauch vergleichsweise hoch. Zu bedenken ist aber, dass innerhalb von 21 Stunden und ohne Hetze eine mehr als komplette Loesung erbracht wurde. Daher wurde die Entwicklungsgeschwindigkeit mit "sehr gut" beurteilt.

Neben der eigentlichen JAM-Entwicklungsumgebung kam wie erwaehnt das CASE-Werkzeug der Firma Cadre zum Einsatz. JAM verfuegt ueber eine Schnittstelle zu dem Tool. Mit Teamwork erstellten die Entwickler das Entity-Relationship-Modell sowie Datenfluss- und Kontextdiagramm. Alle Diagramme bildeten dann die Grundlage fuer die Erstellung der Rohmasken und des Datenlexikons.

Leider fehlte die Schnittstelle zur direkten Uebergabe des Datenlexikons an das relationale Datenbanksystem. Ein solches Interface ist laut Cadre zwar vorhanden, stand dem Entwicklungsteam aber nicht zur Verfuegung. Eine Verbindung von generiertem Quellcode zum logischen Entwurf ist nicht moeglich. Insgesamt erhielt die Integration der Werkzeuge dennoch die Note "sehr gut".

Eine effektive Unterstuetzung des Endanwenders zur Generierung von einfachen Reports fehlte. So musste bei deren Erarbeitung auf den vom System zur Verfuegung gestellten JAM-Report-Writer zurueckgegriffen werden. Einem ungeuebten Anwender kann das Probleme bereiten. Die Endbenutzerunterstuetzung erschien uns somit nur als "maessig".

Die Dokumentation des Quellcodes legte der Entwickler in jedem Modul schablonenartig an. Jedes verwendete Modul besass einen Kopf, in dem Modulfunktion, Name des Entwicklers sowie Projekt- und Aenderungsdatum eingetragen wurden. Diese Form der Dokumentation ist allerdings nicht JAM-spezifisch, sondern ein professioneller Standard in Entwicklungshaeusern. Die grafische Dokumentation des logischen Entwurfs mit Teamwork war vollstaendig, auf dem Bildschirm aber in sehr kleinem Format dargestellt. Insgesamt war die Dokumentation dennoch "sehr gut".

Zum Abschluss des Tests stand die Wartbarkeit des entwickelten Informationssystems auf dem Pruefstand. Das Entwicklungsteam hatte eine ihm vorher unbekannte Aenderung vorzunehmen. Insgesamt fuenf Teammitglieder fuehrten die Modifikationen in knapp fuenf Stunden durch. Dabei gingen die Beteiligten vom logischen Entwurf aus. Die Wartungsgeschwindigkeit ist unter diesen Umstaenden als "ausgezeichnet" zu bezeichnen (Abbildung 1 zeigt die Ergebnisse auf einen Blick).

Insgesamt erwies sich der Jyacc Application Manager (JAM) zusammen mit Cadres Teamwork als eine sehr effektive Entwicklungsumgebung, die auch vielkoepfige Teams unterstuetzt. Die einzigen groesseren Schwachstellen waren die fehlende Unterstuetzung von einfachen Abfragen und ein passives Datenlexikon.

Nun zum Ablauf der einzelnen Phasen (Analyse bis Wartung). Die Spannweite der Einzelbewertungen liegt zwischen sehr gut (1) und mangelhaft (5).

Analyse und Design: 2

Vor Beginn wurden fuer die Durchfuehrung des Benchmark-Tests die Geschaeftsregeln und der Maskenaufbau sowie die Arbeitsverteilung des Teams festgelegt. Das nahm 32 Stunden in Anspruch. Der Test begann mit dem Entwurf von Entity-Relationship-Modell, Kontext- und Datenflussdiagramm sowie Entitaeten. Dazu benutzten die Entwickler das CASE-Werkzeug Teamwork.

Aus diesen Diagrammen wurden dann fuer X-Windows Rohmasken erzeugt, die danach problemlos auf ein RS/6000-System portiert und zu zeichenorientierten Masken gewandelt werden konnten. Der Systementwurf funktionierte ebenso wie der der Rohmasken problemlos. Eine Schwaeche lag allerdings darin, dass Teamwork die Datendefinition nicht direkt uebernehmen konnte.

Datenbankerstellung: 2

Das DDL-Script zur Generierung der Datenbank unter dem relationalen Datenbanksystem Sybase erstellte das Team ohne Werkzeugunterstuetzung als Script-Datei manuell. Allerdings wurden Regeln zur Datenvalidierung miteinbezogen. Der Zeitaufwand fuer die Generierung der Datenbank betrug eine Stunde und fuenfzig Minuten. Eine Staerke der Entwicklungsumgebung ist die Unterstuetzung einer Reihe von relationalen Datenbanken. Als Nachteil wirkte sich aus, dass das Datenbankschema neu erstellt werden musste.

Einfache Transaktionen: 3

Die zu Character-Masken gewandelten Rohmasken konnten in dieser Phase mit Hilfe des JAM-Screen-Editors leicht ueberarbeitet werden - zweifellos ein Vorteil des Systems. Zusaetzlich wurden sie mit der fehlenden notwendigen Funktionalitaet ausgestattet. Dazu war aber der erhebliche Zeitaufwand von 24 Stunden und 40 Minuten erforderlich, der nur teilweise auf die aussergewoehnliche Teamgroesse zurueckzufuehren war. Langwierige Einzelarbeiten waren selbst dann vonnoeten, wenn nur eine einfache Logik eingebaut werden musste.

Komplexe Transaktionen: 2

Die Realisierung einer gewuenschten komplexen Arbeitszeit-Eingabe nahm verhaeltnismaessig viel Zeit in Anspruch. Wie bereits bei den einfachen Transaktionen war viel Einzelarbeit noetig, die von einem Teammitglied geleistet wurde. Der gesamte Zeitbedarf fuer diesen Bereich belief sich auf den vergleichsweise langen Zeitraum von 18 Stunden und 30 Minuten. Allerdings stand am Ende ein Modul, das durch seine Funktionalitaet ueberzeugen konnte. Als guenstig stellte sich die Datumsberechnung mit der Sybase-Funktion Math heraus. Unerfreulich war dagegen der Zeitverlust durch wiederholte Routinearbeiten, der aufgrund fehlender Standardisierung zustande kam.

Abfragen und einfache Berichte: 3

Zum Anfertigen der Abfragen wurde der zur Produktfamilie gehoerende JAM/Report-Writer eingesetzt. Die Umsetzung der einfachen Abfragen oder Berichte bereitete zwar keine groesseren prinzipiellen Probleme, zog sich aber sehr in die Laenge. Selbst unerfahrene Entwickler sollten diesen Teil des Benchmark-Tests in erheblich kuerzerer Zeit bewaeltigen als in acht Stunden und zehn Minuten. Positiv ist jedoch zu erwaehnen, dass das Resultat einwandfrei war. Letztlich wurde aber der Endbenutzer nicht effektiv dabei unterstuetzt, Abfragen selbstaendig zu erstellen.

Komplexe Berichte: 2

Der komplexe Bericht mit seiner Datenpflege wurde aus Zeitgruenden ohne Unterstuetzung des Planungswerkzeuges Teamwork erstellt. Dies zahlte sich aus, denn es wurde mit sechs Stunden und 15 Minuten weniger Zeit benoetigt als fuer die erheblich einfacheren Abfragen.

Staerke: Anspruchsvolle Ausgabenformate konnten abgebildet werden.

Schwaeche: Kleinere Probleme mit der Verarbeitung der Null-Werte von Sybase.

Schnittstelle: 3

Die vorliegenden Dbase-Dateien konnten nur in umgewandelter Form in ASCII-Format gelesen werden. Analog zur komplexen Transaktion wurden in erheblicher Detailarbeit und entsprechendem Zeitaufwand von 14 Stunden und 20 Minuten eine Reihe von Validierungsroutinen implementiert. Letztlich wurden die Dbase-Dateien korrekt uebernommen. Positiv fiel ins Gewicht, dass die produkteigene Sprache JPL die Einbindung externer Programmiersprachen ermoeglicht. Nachteilig wirkte sich dagegen aus, dass Daten von kommerziellen PC-Datenbanken nicht direkt eingelesen werden koennen.

Wartung: 1

Die geforderten erheblichen Aenderungen des urspruenglichen Informationssystems (ungefaehr 60 Funktionspunkte) wurden von den fuenf beteiligten Mitarbeitern (fuenf) recht schnell, naemlich in vier Stunden und 55 Minuten, realisiert (Abbildung 2). Wie schon in den vorangegangenen Phasen waren bei dem Endprodukt keinerlei Fehler festzustellen. Es handelt sich um eine ueberschaubare Umgebung, in der sich auch grosse Teams koordinieren lassen. Eine Schwaeche besteht allerdings darin, dass bei einem passiven Datenlexikon die Aenderungen einzelner Datenfelder zusaetzlich auch in den Masken vorgenommen werden muessen.

wird fortgesetzt

*Eberhard Rudolph ist Professor fuer Informationssysteme an der Fachhochschule Bremerhaven. Er beaufsichtigte den Benchmark-Test gemeinsam mit den Studenten Dieter Kern und Detlef Witte.

Abb. 1: Beim Test durch ein achtkoepfiges Entwicklerteam machte JAM einen ueberzeugenden Eindruck.

Abb. 2: Der Gesamtaufwand betrug 113 Stunden und 50 Minuten. Die Testdauer lag bei 21 Stunden und 35 Minuten. Das Team bestand aus acht Personen.

Systemumgebung:

Als Hardware- und Software-Entwicklungsplattform kamen folgende Produkte zum Einsatz:

- BM RS/6000-520 fuer die Anwendungsentwicklung,

- IBM 3151 Terminals,

- PCs mit Jterm/Vterm-Emulator,

- Sun-Sparcstation fuer CASE-Werkzeug,

- AIX 3.1.5 als Betriebssystem fuer die Anwendungsentwicklung,

- Sybase DBMS 4.8 als relationales Datenbank-Management-System,

- JAM 5.02 Entwicklungssystem, JAM DBI 4.8 JAM-Sybase- Schnittstelle, JAM Report Writer 4.8.,

- Sunos 4.1.2 als Betriebssystem fuer das CASE-Werkzeug,

- Teamwork 4.1 als CASE-Werkzeug,

- JAM CASE Interface 1.0 als Schnittstelle zu CASE-Werkzeugen.

Entwicklungskosten in den Griff bekommen

Bei Softwareprojekten werden die urspruenglich veranschlagten Kosten und Termine oft ueberschritten. Das liegt unter anderem daran, dass diese Vorhaben zuvor nicht nach einer einheitlichen Methode bewertet wurden. Die Messbarkeit und Kontrolle von Kosten und Produktivitaet der Software-Entwicklung ist Thema einer Veranstaltungsreihe ueber Funktionspunkte-Technik, die am 27. April in Muenchen startet und dann in mehreren Staedten wiederholt wird.

Die Teilnehmer sollen die standardisierte Messweise der Funktionspunkt-Methode verstehen, anwenden und ihren Einsatz unter Management-Gesichtspunkten leiten koennen. Die Veranstaltung wird von Eberhard Rudolph, Professor fuer Informationssysteme an der Hochschule Bremerhaven, geleitet.

Informationen: Computerwoche Verlag GmbH, Computerwoche Forum, Rheinstrasse 28, 8000 Muenchen 40, Telefon 089/36086-162.