Softwareprojekte verwalten

Softwareprojekte sind das A und O von Access-Entwicklern und somit auch für Sie. Es sei denn, Sie schnuppern rein zufällig hier herein – und selbst dann können Sie mit der hier vorgestellten Lösung vielleicht etwas anfangen. Diese soll nämlich helfen, ein Softwareprojekt in seine Meilensteine, Iterationen, Kundenstories und Tätigkeiten aufzuteilen und deren Abarbeitung zu organisieren.

Ein Softwareprojekt lässt sich in den seltensten Fällen und selbst unter Access nicht auf einer Karteikarte darstellen – und wenn doch, brauchen Sie sicher keine Datenbankanwendung, um ein solches Projekt zu verwalten. Sobald eine Anwendung jedoch aus einigen Tabellen, Abfragen, Formularen, Berichten und dem notwendigen VBA-Code besteht, kann es nicht schaden, das Projekt vernünftig zu planen und auch die Fortschritte festzuhalten. Gerade wenn Sie ein Projekt für einen Kunden entwickeln, werden Sie keine ungenauen Prognosen bezüglich des zeitlichen und finanziellen Aufwands machen und den Kunden bei Abweichungen enttäuschen wollen.

Es ist daher immer sinnvoll, ein Projekt in der Entwurfsphase so genau wie möglich zu skizzieren, was am einfachsten geht, wenn Sie die Anforderungen genau kennen. Deren Erfassung soll nicht Thema dieses Beitrags sein, sondern lediglich deren Umwandlung in eine Form, die Sie mit der hier vorgestellten Lösung verwalten können. Zugrunde liegen sollten die Informationen jedoch in der folgenden Aufgliederung:

• Kundenstories: Sie und der Kunde müssen wissen, welche Aufgaben die Benutzer mit der Anwendung erledigen sollen. Dies erfassen Sie grob in Form von Kundenstories, die aus einem Titel und einer kurzen Beschreibung bestehen, zum Beispiel “Kunde anlegen” und “Der Benutzer legt einen neuen Kunden mit Adresse und Ansprechpartner an”.
• Meilensteine: Die daraus resultierende Menge von Kundenstories wird auf verschiedene Meilensteine aufgeteilt. Warum nicht nur ein Meilenstein, der alle Funktionen enthält Nun: Kunden wollen schnell produktiv mit ihrer Software arbeiten, also entscheiden Sie zusammen mit dem Kunden, mit welchen Kundenstories sich eine sinnvoll einsetzbare Software entwickeln lässt, und erklären dies zu Meilenstein 1. Den Rest verteilen Sie auf weitere Meilensteine, zu denen Sie die Software um die übrigen Funktionen anreichern.
• Iterationen: Meilensteine heißen nicht umsonst Meilensteine und nicht Metersteine, weil zwischen ihnen ein ordentlicher, genau definierter Fortschritt erfolgen soll. Vom Start der Softwareentwicklung bis zum ersten Meilenstein ist es aber oft ein weiter Weg, auf dem vieles schiefgehen kann. Also planen Sie kleinere Zwischenstationen ein, sogenannte Iterationen. Diese sollten eine überschaubare Anzahl aufweisen und in regelmäßigen Abständen erfolgen. Eine Iteration entspricht hier einer Vorführung des Zwischenstands der Software, der noch nicht alle für den jeweils nächsten Meilenstein geplanten Elemente enthält, aber dennoch funktionstüchtige Abschnitte präsentiert. Die Betonung liegt hier auf “funktionieren” im Gegensatz zu “perfekt sein”: Der Kunde soll sich hier ein Bild von den bereits fertigen Elementen machen und dem Entwickler Feedback liefern, ob man sich auf dem richtigen Weg befindet oder die Richtung geändert werden muss.
• Aufgaben: Eine Kundenstory beschreibt ein funktionierendes Element der Anwendung, dessen Erstellung aber eine ganze Reihe von Schritten umfassen kann, die wiederum in Aufgaben resultieren. Aufgaben sind die kleinsten Einheiten in der Projektplanung. Die Aufgaben für die Kundenstory “Kunde anlegen” heißen beispielsweise “Kundentabelle anlegen”, “Formular zum Anlegen von Kunden erstellen” oder “Funktion zur Validierung der Kundendaten erstellen”. Aufgaben sollten so elementar aufgebaut sein, dass man sie in möglichst kurzen Zeiträumen erledigen kann – also beispielsweise in einer oder wenigen Stunden. Dies hat den Vorteil, dass Sie Ihren Fortschritt erkennen und Aufgaben abhaken können, was eine gute Motivationshilfe sein kann. Denken Sie einmal daran, als Sie das letzte Mal tagelang an einer umfangreichen Aufgabe arbeiteten und einfach nicht fertig wurden – wenn Sie diese in kleine Häppchen aufteilen und diese Stück für Stück abhaken können, ist viel schneller Land in Sicht.

Die Aufteilung, wie Sie sie hier vorfinden, lehnt sich an das Buch Softwareentwicklung von Kopf bis Fuß an (O€Reilly, ISBN 978-3-89721-862-8). Es vermittelt Wissen zum Thema Softwareentwicklung auf witzige Weise, ohne sich auf spezielle Entwicklungsumgebungen festzulegen. Wenn Sie mehr zur Planung von Softwareprojekten erfahren möchten, schauen Sie beim nächsten Besuch Ihrer Lieblingsbuchhandlung einfach einmal hinein, es lohnt sich wirklich.

Die vorliegende Lösung können Sie natürlich auch ohne die Lektüre dieses Buchs einsetzen. Sie besteht im Wesentlichen aus einem Formular mit einem TreeView-Steuerelement, mit dem Sie die oben genannten Elemente einer Softwareentwicklung verwalten können. Das oberste Element ist dabei das Projekt selbst. Darunter finden Sie, hierarchisch untereinander angeordnet, die Meilensteine, Iterationen, Kundenstories und Aufgaben.

Über Kontextmenüeinträge stellt das TreeView-Steuerelement Funktionen zum Anlegen untergeordneter Elemente und zum Löschen der Elemente selbst bereit. In einem Bereich rechts des TreeView-Steuerelements finden Sie Informationen zum jeweils aktivierten Eintrag.

Damit sich auch der oben angesprochene Motivationseffekt einstellt, gibt es für die Aufgaben auch einen Kontextmenüeintrag, mit dem sich eine Aufgabe als “in Arbeit” und als “erledigt” abhaken lässt. Beides führt zur Anzeige eines veränderten Symbols des jeweiligen Eintrags. Sind alle Aufgaben einer Kundenstory erledigt, erhält auch diese ein entsprechendes Symbol.

Aber die Lösung soll nicht nur beim Erledigen der Aufgaben selbst helfen, sondern auch bei der Planung des Aufwands und somit bei der Kalkulation. In Anlehnung an oben erwähntes Buch können Sie auf zwei Ebenen den geplanten Aufwand eintragen: auf der Kundenstory-Ebene und auf Aufgaben-Ebene.

Zu Beginn eines Projekts werden Sie sich noch keine Gedanken über die einzelnen Aufgaben machen, die zur Implementierung der für eine Kundenstory nötigen Funktionen führen, sondern zunächst grob abschätzen, wieviel Aufwand die Umsetzung der Kundenstory selbst erfordert. Die Summe dieser Aufwände ergibt eine Grobkalkulation des Projekts, auf deren Basis die grundsätzliche Entscheidung über die Durchführung erfolgen kann. Später werden Sie die einzelnen Aufgaben definieren und deren Aufwand abschätzen. Meilensteine, Iterationen und Kundenstories sollen dann jeweils die Kalkulation auf Basis der groben Abschätzung der Kundenstories und zusätzlich die verfeinerte, auf den Aufgaben basierende Berechnung liefern.

Als Letztes sollen die Entwickler noch den tatsächlichen Aufwand für die Durchführung einer Aufgabe eintragen, um eine Nachkalkulation zu ermöglichen.

Zusätzliche Kundenstories und Aufgaben

Natürlich kann und wird es passieren, dass Kundenstories hinzukommen, wegfallen oder sich ändern und dadurch Aufgaben neu organisiert werden müssen. Die Projektverwaltung soll dazu eine Funktion enthalten, mit der Sie die Planungsphase für das Projekt für beendet erklären können. Neu hinzugefügte Elemente werden dann speziell gekennzeichnet, gelöschte Elemente ebenfalls – nur können diese auch noch ausgeblendet werden.

Dies dient vor allem dazu, dass der Entwickler dem Kunden erklären kann, warum das Projekt plötzlich zeitintensiver und teurer wird als geplant.

Mehrbenutzerfähigkeit

Bei großen Softwareprojekten sind meist mehrere Softwareentwickler involviert. Aber Access ist nicht gerade für die Entwicklung mit mehreren Personen optimiert und die Erfahrung zeigt, dass die meisten Projekte von Einzelkämpfern durchgeführt werden. Wir verzichten daher zunächst auf die Einrichtung einer zusätzlichen Tabelle zum Speichern mehrerer Benutzer und auf Funktionen zum Zuteilen von Aufgaben an diese Benutzer.

Datenmodell

Das Datenmodell besteht aus einigen hierarchisch verschachtelten Tabellen (siehe Bild 1). Die oberste Tabelle in der Hierarchie heißt tblProjekte. Sie enthält neben dem Primärschlüsselfeld lediglich ein Feld zum Speichern des Projektnamens sowie ein Feld namens PlanungAbgeschlossenAm. Nach diesem Zeitpunkt hinzugefügte Elemente sollen zur besseren Nachvollziehbarkeit von änderungen, die während des Projekts erfolgen, entsprechend gekennzeichnet werden.

Bild 1: Das Datenmodell der Softwareprojektverwaltung

Die Tabelle tblMeilensteine ist über das Feld ProjektID mit dem Primärschlüsselfeld der Projekte-Tabelle verknüpft und enthält eine Bezeichnung und das Datum des Meilensteins.

Die Tabelle tblIterationen ist genauso aufgebaut, aber mit der Tabelle tblMeilensteine verknüpft. Gleiches gilt für die Tabelle tblKundenstories, die über das Fremdschlüsselfeld IterationID mit der Tabelle tblIterationen verknüpft ist.

Interessant wird es bei der Tabelle tblAufgaben, die wiederum mit tblKundenstories verknüpft ist. Sie enthält ebenfalls die beiden Felder Titel und Beschreibung sowie Felder namens GeschaetzterAufwand und TatsaechlicherAufwand, die eine Angabe des Aufwands in Stunden erwarten (eine exakte Erfassung der einzelnen Zeiten, zu denen sich der Entwickler mit der Aufgabe beschäftigt, ist hier zunächst nicht geplant).

Das Feld FertiggestelltAm erhält das Datum, an dem der Entwickler diese Aufgabe erledigt hat – damit das Symbol des entsprechenden TreeView-Elements auch ein nettes “Erledigt”-Häkchen bekommt und der Entwickler sich frohen Mutes der nächsten Aufgabe zuwenden kann. Damit der Entwickler einen Überblick über den Fortschritt gewinnen kann, gibt es noch ein Feld namens ProzentFertiggestellt, das Werte von 0 % bis 100 % in Zehnerschritten annimmt.

Alle Tabellen erhalten ein Feld namens ReihenfolgeID, das zur Sortierung der Datensätze im TreeView-Steuerelement und darüber zum Festlegen der Priorität genutzt werden kann. Außerdem erhalten alle Tabellen die Felder AngelegtAm und GeloeschtAm.

Alle Tabellen besitzen außerdem Felder, die für die Anzeige im TreeView-Steuerelement nötig sind. Das Feld Image gibt den Namen einer Bilddatei an, die zum Zeitpunkt der Anzeige in einem entsprechenden ImageList-Steuerelement vorliegen muss – dazu weiter unten mehr. Außerdem gibt es je ein Feld namens Expanded, das angibt, ob das zum Datensatz gehörende TreeView-Element seine Unterelemente anzeigen oder verbergen soll.

Formular zur Verwaltung der Softwareprojekte

Das Formular soll frmSoftwareprojektverwaltung heißen und fürs Erste lediglich drei Steuerelemente enthalten:

• ein ImageList-Steuerelement namens ctlImageList zum Speichern der Bilddateien, die als Icons im TreeView-Steuerelement angezeigt werden sollen,
• ein TreeView-Steuerelement namens ctlTreeView (Sie brauchen hier keine Eigenschaften anzupassen, dies erledigen wir später) und
• ein Unterformular-Steuerelement namens sfm.

Ordnen Sie die Steuerelemente wie in Bild 2 und passen Sie Größe und Ausrichtung großzügig an. Das ImageList-Steuerelement ist später unsichtbar und kann an beliebiger Stelle platziert werden. Access 2007-Benutzer nutzen die Eigenschaften Horizontaler Anker und Vertikaler Anker, damit sich die Steuerelemente automatisch mit dem Formular vergrößern.

Bild 2: Steuerelemente der Softwareprojektverwaltung

Mit dem TreeView-Steuerelement fügen Sie dem VBA-Projekt der Anwendung einen Verweis auf die Bibliothek Microsoft Windows Common Controls 6.0 hinzu; zusätzlich benötigen Sie einen Verweis auf die Bibliothek Microsoft Office x.0 Object Library, die das CommandBars-Objektmodell für die Programmierung von Kontextmenüs liefert.

TreeView-Konfigurator

Unter uns gesagt würde die Beschreibung der Ausstattung des TreeViews inklusive Füllung und Funktionen, wie Drag and Drop sowie der restlichen Elemente des gewünschten Formulars und die Synchronisierung zwischen TreeView und Formular, den Rahmen dieses Beitrags bei Weitem sprengen.

Zum Glück stellen wir im Beitrag TreeView-Konfigurator (s. Shortlink 667) ein Tool vor, mit dem das Programmieren des TreeViews viel einfacher vonstatten geht – Sie brauchen hier beispielsweise nicht selbst das Füllen des TreeViews, das Anzeigen von Kontextmenüs oder Drag and Drop zu implementieren.

Alles, was Sie tun müssen, ist das Importieren der im oben erwähnten Beitrag genannten Access-Objekte, welche die Funktionalität und die Benutzeroberfläche für das einfache Füllen des TreeViews mitbringen.

TreeView mit Leben füllen

Fügen Sie dem Formular eine Prozedur für das Ereignis Beim Laden hinzu. Diese dient als Ausgangspunkt für das Initialisieren und Füllen des TreeView-Steuerelements.

Erweitern Sie die Prozedur wie folgt und deklarieren Sie außerdem die modulweit gültige Variable objTreeViewHandler:

Private WithEvents objTreeViewHandler As µ
clsTreeViewHandler
Private Sub Form_Load()
    Set objTreeViewHandler = New clsTreeViewHandler
    With objTreeViewHandler
    Set .TreeViewInst = Me.ctlTreeView.Object
    Set .ImageListInst = Me.ctlImageList.Object
    .InitTreeView (3)
    .LineStyle = tvwTreeLines
    .FillTree
    End With
    Me.sfm.SourceObject = "sfmProjekte€
    End Sub

Im Gegensatz zur Vorgehensweise bei der direkten Programmierung des TreeView-Steuerelements brauchen Sie hier noch nicht einmal eine Objektvariable für dieses Element anzulegen.

Die erste Anweisung weist der Objektvariablen objTreeView einen Verweis auf das entsprechende Steuerelement des Formulars zu, die beiden Folgenden initialisieren und füllen das TreeView-Steuerelement. Das Initialisieren ersetzt die Einstellungen, die Sie normalerweise im Eigenschaften-Dialog des TreeView-Steuerelements vornehmen würden. Dies hat rein praktische Gründe: Sie brauchen nicht lange in den Eigenschaften herumzuspielen, sondern können einfach die Routine InitTreeView in die Zielanwendung kopieren und sie anpassen. Sollten die Eigenschaften des TreeView-Steuerelements nicht Ihren Vorstellungen entsprechen, können Sie diese später über die Eigenschaften der Klasse clsTreeViewHandler anpassen.

Benutzername oder E-Mail-Adresse: