SEMESTERARBEIT B2TRACKING. SA 08 Florian Schwendener & Michael Bolliger

Transkript

1 SEMESTERARBEIT B2TRACKING SA 08 Florian Schwendener & Michael Bolliger

2

3 Projekt: B2Tracking 1 MANAGEMENT SUMMARY 1.1 AUSGANGSLAGE Die Heiniger & Partner AG in Wetzikon entwickelte in den vergangenen Jahren die Software B1, welche dem Management im Bauwesen dient. Für die Nachfolgeversion B2, wird eine Software zur Abhandlung von Support- Anfragen benötigt. Bislang wurde dies durch proprietäre Mittel gelöst, eine Mischung aus s, Papierdokumenten und Office-Dateien. Da diese Variante an seine Grenzen stösst, vor allem im Bezug auf die Benachrichtigung der Kunden, wird ein neues System benötigt. Dies soll durch diese Arbeit umgesetzt und entwickelt werden. Die Realisierung sollte dabei auf der Basis des.net Frameworks mit Verwendung von Visual Studio, ASP.NET und C# erfolgen. Die Applikation soll im Webbrowser laufen, also kam ein Webprojekt zum Zug. B2 wird ebenfalls auf.net Basis entwickelt, was eine spätere Integration von B2Tracking in B2 ermöglicht. Da wir beide grösstenteils mit diesen Technologien arbeiten, haben wir uns stark für diese Arbeit interessiert. Deshalb haben wir uns für dieses Projekt entschieden. Als Betreuer von der HSR konnten wir Rainer Baumann, Dr. sc. ETH Zürich und ehemaliger Dozent von uns, gewinnen. Als Ziel nahmen wir uns ein professionelles, flexibles System vor, welches alle benötigten Features abdeckt. Diese sind vor allem im Bereich Arbeitszuteilung, Übersicht über den Ablauf einer Supportanfrage und Benachrichtigung von Kunden nach dem Abschluss eines Problems zu finden. Der Projektleiter soll dabei stets die Überhand behalten und den kompletten Ablauf steuern. Das System muss bis Ende der Arbeit in der Heiniger & Partner AG eingeführt und ein Handbuch für die Mitarbeiter erstellt worden sein. Da B2 selbst erst in der Entwicklung steht, wird ein regelmässiger Einsatz während der Zeitspanne der Semesterarbeit jedoch kaum zu garantieren sein. Ferner wären die Integration in B2 und die Weiterentwicklung als Kundenplattform weitere Ziele, welche jedoch kaum in Rahmen der Semesterarbeit umgesetzt werden können. 1.2 VORGEHEN Die Umsetzung verlief im vorgesehenen Rahmen. Es entstand ein System, welche alle vorausgesetzten Anforderungen abdeckt und intern im Probe-Einsatz steht. Die Applikation läuft stabil und zur vollen Zufriedenheit des Auftraggebers. Ein Handbuch, welches sowohl das Konzept der einzelnen Teile des Systems, als auch die Verwendung desselbigen beschreibt, ist ebenfalls vorhanden. Es richtet sich an alle Mitarbeiter, vom Supporter bis zum Projektleiter. Zur Planung haben wir uns an die Techniken gehalten, welche wir im Modul Software-Entwicklung an der HSR kennengelernt haben. Diese basieren auf dem sogenannten RUP, dem Rational Unified Process, einem modernen Vorgehensmodell zur Softwareentwicklung. In diesem wird die Arbeitsentwicklung in Phasen, an deren Ende Meilensteine stehen, unterteilt. Diese Phasen werden noch feiner in sogenannte Iterationen gegliedert. Ein wichtiges Ziel dieses Modells ist, dass die grundlegenden Anforderungen zu einem frühen Zeitpunkt umgesetzt werden. Dies hat den Hintergrund, dass sich ein grosser Teil der Anforderungen im Verlaufe des Projekts ändert und im Endprodukt nie benötigt werden. Deshalb sollte nicht früh Zeit für die aufwändige, detaillierte Ausarbeitung aller Anforderungen verschwendet werden. Nach der Detailbeschreibung der wichtigsten Anforderungen liessen wir diese durch den Auftraggeber schriftlich bestätigen. Während der Arbeit befanden wir uns in ständigem Kontakt mit unserem Betreuer, Rainer Baumann. Mit ihm haben wir mehrmals Meetings abgehalten und regelmässig Statusmeldungen per durchgegeben. Da wir einen Tag pro Woche in Wetzikon gearbeitet haben, hatte unser Auftraggeber stets Einblick in die Arbeit und konnte uns mit Rat und Tat zur Seite stehen. Somit hatten wir ständig einen Ansprechpartner, wenn wir vor wichtigen Entscheidungen standen. Seite: 3 von 22 Semesterarbeit Datum:

4 Projekt: B2Tracking 1.3 ERGEBNISSE Als Endprodukt unserer Arbeit entstand eine Applikation, welche die wichtigen Anforderungen weitgehend abdeckt. Das System ist nun im Probeeinsatz und vermochte bislang zu überzeugen. Wie schon erwähnt, befindet sich die Entwicklung von B2 noch in vollem Gange, weshalb der regelmässige Einsatz derzeit noch nicht stattfindet. Es wird jedoch von verschiedenen Mitarbeitern getestet und durchläuft einige Beispiel-Abläufe. Die Einführung in den produktiven Betrieb ist für den Anfang des nächsten Jahres geplant ENTWICKLUNG Das System wurde von Grund auf selbst entwickelt, wobei im Bereich der Darstellung auf vorgefertigte Komponenten gesetzt wurde. Die Basis, also die Datenspeicherung und die Anwendungslogik, wurden komplett selbst programmiert. Zur Ausgabe von Daten und für dynamische Eingabemöglichkeiten haben wir grösstenteils auf die Komponenten der Firma DevExpress gesetzt. Diese sind Weiterentwicklungen der Microsoft-Komponenten und bieten mehr Geschwindigkeit, anspruchsvollere Ansichten und sind wesentlich flexibler. Dabei kamen Elemente wie Tabellen/Grids, Buttons, Navigationsmenüs und viele weitere zum Einsatz. Um die Ladezeit im Webbrowser zu verringen, haben wir ausserdem die Ajax-Technik verwendet, welche das Nachladen von kleinen Teilen einer Webseite ermöglicht, statt immer den ganzen Inhalt neu anzufordern ABWEICHUNGEN Grundsätzlich vermochten wir, alle verlangten Ziele mit unserem Endprodukt abzudecken. Erweiterungen, die ferner geplant waren, konnten jedoch nicht umgesetzt werden, was aber zu keinem Zeitpunkt wirklich eine Rolle spielte. Auf Grössere Probleme stiessen wir vor allem in den Bereichen Browser-Kompatibilität und bei der Verwendung der DevExpress-Komponenten. - Browser-Kompatiblität: Als Planungsfehler machte sich gegen Ende der Arbeit vor allem die fehlende Festlegung auf einen Webbrowser bemerkbar. Während der Entwicklung setzten wir auf die Browser Opera und Chrome, um unsere Applikation zu testen. Leider haben wir es versäumt, einen bestimmten Browser als Vorgabe festzulegen. Dies haben wir erst bemerkt, als unser Auftragsgeber die Software ausprobiert hat. Dabei hat er den Wunsch geäussert, dass die Applikation im Internet Explorer 7 funktionieren soll. Die Umstellung darauf hat uns einigen Zeitaufwand gekostet. - Verwendung von Komponenten: Zu grösseren Problemen führte auch der Einsatz von DevExpress-Komponenten. Obwohl wir diese bereit von der Desktop-Programmierung her kennen, zeigte sich, dass die Webkomponenten doch einige Schwierigkeiten nach sich zogen. Die meisten konnten wir durch Workarounds oder den DevExpress- Support beheben. Abweichungen im positiven Sinne kamen nicht oft vor. Jedoch vermochten wir einen grossen Teil der Administration zu entwickeln. Dies bedeutet, dass der Administrator nun eigene Kategorien für Support-Probleme anlegen oder bereits vorgefertigte Abläufe für solche Probleme planen kann. Eigentlich wurde dies nur als optionale Anforderung formuliert, welche jedoch bei diesen zuoberst auf der Liste stand. Seite: 4 von 22 Semesterarbeit Datum:

5 Projekt: B2Tracking LERNPUNKTE Die Arbeit an diesem Projekt hat uns einige Punkte aufgezeigt, welche wir für zukünftige Projektarbeiten bestimmt berücksichtigen werden. Dies betrifft vor allem Aufteilung der Arbeit und die Einarbeitung in Komponenten, welche bei der Entwicklung zum Einsatz kommen. - Arbeitsaufteilung in Pakete: Wie wir es im Modul Software-Entwicklung an der HSR kennengelernt haben, setzten wir bei der Aufteilung der Arbeit auf Pakete. Jedoch haben wir nun gelernt, dass es wichtig ist, den Fokus mehr auf den Abschluss einzelner Pakete zu legen. Dies haben wir bei der Projektarbeit vernachlässigt. - Einarbeitung in Komponenten: Die Arbeit mit uns bislang unbekannten Komponenten forderte einigen Zeitaufwand. Obwohl die bei uns eingesetzten Komponenten von DevExpress sehr gut dokumentiert sind, haben sie doch immer wieder ein unerwartetes Verhalten gezeigt, was teilweise sogar den Kontakt mit dem Support benötigte, um diese Probleme zu lösen. Für zukünftige Arbeiten nehmen wir es uns vor, vor dem Start des Projekts auf besser bekannte Komponenten zu setzen bzw. uns vorher darin einzuarbeiten. 1.4 AUSBLICK VERBLEIBENDE PROBLEME UND RISIKEN Rechtzeitig zum Abschluss der Arbeit konnten wir alle grossen Probleme lösen und die meisten Risiken beheben. Im Bezug auf die Zukunft stellt aber der grossflächige Einsatz von DevExpress-Komponenten noch ein Risiko dar. Diese werden regelmässig aktualisiert und diverse Fehler behoben. Deswegen ist anzunehmen, dass diese neuen Versionen jeweils eingespielt werden, auch weil sie neue praktische Funktionen bieten werden. Damit läuft man jedoch auch in die Gefahr, vorhandene Funktionen lahmzulegen. Womöglich wäre es besser gewesen, nicht immer auf die DevExpress-Komponenten zu setzen und stattdessen die Standardkomponenten selbstständig weiterzuentwickeln. Doch ein allzu grosses Risiko sollte auch dieser Problemfall nicht darstellen, da jede Aktualisierung der Komponenten vordergründig getestet werden wird WEITERARBEIT Die wohl grösste Aufgabe in Zukunft wird die Integration in B2 selbst sein. Dabei sollen Kunden die Funktionen von B2Tracking als Prozess- und Aufgabenplaner respektive -Verteiler brauchen können. Ob dies in Form einer normalen Desktop-Applikation geschieht oder B2Tracking erst in eine zukünftige Webversion von B2 einfliessen wird, ist noch nicht festgelegt. Natürlich fordert das Projekt während dem Einsatz auch ständig Betreuung, um Mitarbeiter zu unterstützen oder Fehler zu beheben. Für diesen Zweck stehen wir unserem Auftraggeber auch in Zukunft zur Verfügung. Seite: 5 von 22 Semesterarbeit Datum:

6 Projekt: B2Tracking 2 ABSTRACT Um das Erfassen und Verwalten von Anliegen der Kunden unseres Auftraggebers zu optimieren, haben wir die Issue Tracking Software B2Tracking entwickelt. Der optimierte Prozessablauf macht eine stetige Qualitäts- und Fortschrittskontrolle für den Projektleiter möglich. Das System setzt auf ASP.NET, während als Programmiersprache C# zum Einsatz kam. Das rollenbasierte System bietet eine vereinfachte Integration aller Mitarbeiter, indem jeder Arbeitsschritt eines Prozesses einem bestimmten Mitarbeiter oder einer Gruppe zugewiesen werden kann. Das integrierte Benachrichtigungssystem stellt sicher, dass bei einem Ereignis entsprechende Mitarbeiter umgehend informiert werden. Die für die Status der Issues und Arbeitsschritte verantwortliche State Machine wurde so entwickelt, dass der Projektleiter jederzeit die Kontrolle über sämtliche Abläufe hat und bei Bedarf eingreifen kann. Er alleine trägt die Verantwortung für einen Issue und ist für dessen Durchführung verantwortlich. Die Architektur wurde in drei Schichten gegliedert, so dass durch Ersetzen der Präsentationsschicht von einer Web- auf eine Desktop-Applikation umgestellt werden kann. Die Datenbankschicht setzt voll auf die im.net Framework 3.5 neu integrierte Technologie LinqToSql. Die Applikation wurde ausgiebig getestet und beim Kunden in einer produktiven Umgebung eingeführt. Dort wird es voraussichtlich im nächsten Jahr als Ersatz für das aktuelle System, basierend auf Office Dokumenten, eingesetzt. Seite: 6 von 22 Semesterarbeit Datum:

7 Projekt: B2Tracking INHALT 1 Management Summary Ausgangslage Vorgehen Ergebnisse Ausblick Abstract Aufgabenstellung Ausgangslage Zweck und Ziel Annahmen und Einschränkungen Team Auftraggeber Technischer Bericht Ergebnisse Schlussfolgerungen Einführung beim Kunden Produktivumgebung des Kunden Ablauf Feedback des Kunden Persönliche Berichte Michael Bolliger Florian Schwendener Verzeichnisse Literaturverzeichnis Glossar Anhänge Seite: 7 von 22 Semesterarbeit Datum:

8 Projekt: B2Tracking 3 AUFGABENSTELLUNG Gesucht ist eine Software, welche der Erfassung von Fehlern, Anforderungen und Kundenwünschen dient. Dabei soll der gesamte Prozess vom Eingang der Meldung des Kunden über das Beheben und Testen bis hin zur Rückmeldung an den Kunden abgebildet werden. Sie soll sich an bestehenden Issue-Tracking Systemen orientieren, jedoch ist eine dynamische Ablaufplanung verlangt. Die Schritte zur Abarbeitung des Problems sollen frei definierbar sein, passend auf den jeweiligen Fall zugeschnitten. Realisiert wird die Software als Webprojekt, welches unabhängig vom Zugriffsort und ohne spezielle Anforderungen verwendet werden kann. 3.1 AUSGANGSLAGE Für das aktuelle System werden bis heute unterschiedliche Systeme für die Erfassung und Abarbeitung von Fehlern sowie das Verwalten der Supportdatenbank eingesetzt: - Fehler/Anforderungen erfassen: Excel - Dokumentationen der Fehler: Word - Releaseplanung: Excel - Beschreibung der Korrekturen: Word - Tests & Ergebnisse: Papierform - Support-Datenbank: Web / ASP Das jetzige System ist unter den beteiligten Personen gut eingespielt und funktioniert relativ problemlos. Wegen der Anzahl der verschiedenen Systeme und der fehlenden Ordnung soll dieses System jedoch abgelöst werden. 3.2 ZWECK UND ZIEL Das Hauptziel ist die Vereinigung der bislang eingesetzten verschiedenen Systeme und somit eine Zentralisierung auf eine einzige Applikation. Durch eine einfache Bedienung sollen die Abläufe von Supportfällen effizienter durchlaufen. Sehr wichtig ist auch eine bessere Integration von Kunden. So wird jeder Kunde bei der Problemlösung informiert. Das Issue-System soll neu das Informationssystem für folgende Punkte bilden: - Fehlerbehebung - Erweiterungen und Anpassungen der B2-Applikation - Release-Übersicht mit behobenen Bugs - Unterstützung des Supports 3.3 ANNAHMEN UND EINSCHRÄNKUNGEN Da dieses Projekt im Rahmen einer Semesterarbeit durchgeführt wird, steht den Mitgliedern nur eine beschränkte Anzahl Stunden zur Verfügung. Diese beläuft sich pro Person auf etwa 8 * 30h = 240h. Seite: 8 von 22 Semesterarbeit Datum:

9 Projekt: B2Tracking 3.4 TEAM Das Entwicklerteam besteht aus Michael Bolliger und Florian Schwendener, beides Studenten im letzten Studienjahr an der HSR, Hochschule für Technik Rapperswil. Beide sind gleichberechtigte Projektleiter und haben vorher bereits diverse Projekte zusammen realisiert. Neben dem Studium arbeiten sie bei der Heiniger & Partner AG in Wetzikon, welche auch den Auftraggeber dieses Projektes darstellt. Person Florian Schwendener Michael Bolliger 3.5 AUFTRAGGEBER Die Firma Heiniger & Partner AG in Wetzikon entwickelt und betreut Bauadministrations- und Auftragsbearbeitungssoftware. Im Moment wird B1 eingesetzt, während die zurzeit in Entwicklung stehende Version B2 diese ablösen wird. Ansprechperson für das Entwicklerteam ist Toni Fuchs. Neben unserer Studienarbeit betreut und leitet er die Entwicklung von B2, dem Nachfolger von B1. Person Toni Fuchs Seite: 9 von 22 Semesterarbeit Datum:

10 Projekt: B2Tracking 4 TECHNISCHER BERICHT Gesucht ist eine Software, welche der Erfassung von Fehlern, Anforderungen und weiteren Kundenwünschen dient. Dabei soll der ganze Prozess vom Eingang der Meldung vom Kunden über das Beheben und das Testen bis hin zur Rückmeldung an den Kunden abgebildet werden. Sie soll sich an bestehenden Issue-Tracking Systemen orientieren, jedoch ist ein dynamischerer Prozessablauf verlangt. Die Schritte zur Abarbeitung des Problems sollen frei definierbar und passend auf den jeweiligen Fall zugeschnitten sein. 4.1 ERGEBNISSE Es wurde eine Web-Applikation mit ASP.NET entwickelt und beim Kunde eingeführt. Die Anforderungen wurden gemäss den spezifizierten Use Cases alle erfüllt BESCHREIBUNG DES SYSTEMS Um die Anforderungen mit dem System umzusetzen wurden die folgenden Konzepte ausgearbeitet. ISSUE Im Mittelpunkt des Systems steht der Issue. Ein Issue beschreibt ein Anliegen des Kunden, wie zum Beispiel einen Wunsch oder einen Fehlerfall einer Programmkomponente. Dieser wird vom Support erfasst und vom Projektleiter verwaltet. Issues definieren zudem einen Arbeitsablauf bzw. Prozess bestehend aus Arbeitsschritten, nachfolgend Tasks genannt. Dieser Ablauf wird vom Projektleiter definiert und jeder Task einem Mitarbeiter oder einer bestimmten Rolle zugewiesen. Speziell ist, dass ein gestarteter Task nicht gelöscht werden kann. Dies garantiert, dass ein Arbeitsablauf stets nachvollziehbar ist. TASK Ein Task beschreibt einen Arbeitsschritt und enthält weitere Informationen wie Start- und Endzeit, sowie einen Status. Ein gestarteter Task wird von einem zugeteilten Mitarbeiter durchgeführt. Ist zu Beginn des Tasks nur eine Rolle zugewiesen, so haben die Mitglieder dieser Rolle die Möglichkeit, den Task anzunehmen. Somit kann ein Task vom nächsten freien Mitarbeiter einer bestimmten Rolle erledigt werden. ROLLEN Die Verteilung von Benutzerrechten erfolgt mit sogenannten Rollen. Die Rollen Projektleiter sowie Supporter sind fix vorgegeben, da diese spezielle Rechte einnehmen. Weitere Rollen können vom Kunden frei definiert werden. Grundsätzlich können alle Mitglieder einer Rolle Issues und Tasks anzeigen, sowie neue Kommentare erstellen und Dateien hochladen. Jeder Benutzer kann zusätzlich einen ihm zugewiesenen Task abschliessen. Ein Supporter kann, im Gegensatz zu einem normalen Benutzer, auch Issues erstellen. Er ist das Bindeglied zwischen Kunde und System und ist verantwortlich, dass alle Wünsche und Fehlermeldungen von Kunden entsprechend aufgenommen werden. Seite: 10 von 22 Semesterarbeit Datum:

11 Projekt: B2Tracking Ein Projektleiter besitzt alle verfügbaren Rechte des Systems. Im Mittelpunkt steht seine übergreifende Kontrolle, indem er jeden Task bzw. Issue, freigeben und abschliessen muss. Somit ist er für eine stetige Qualitäts- und Fortschrittskontrolle verantwortlich. VERSIONEN Jeder Issue im System ist einer bestimmen Version zugewiesen. Ein vom Supporter neu angelegter Issue wird immer der Version Zukünftige Version zugewiesen. Diese Version ist fix und kann nicht gelöscht oder geändert werden. Zudem kann von dieser Version auch kein Release erstellt werden. Der Projektleiter hat vor dem Starten eines Issues die Aufgabe, den Issue zu klassifizieren und ihn einer bestimmten Version zuzuweisen. RELEASES Ein spezielles Feature wurde mit den Releases implementiert. Der Projektleiter kann eine beliebige Version, welche mindestens einen Issue enthält, releasen. Ein Release ist wiederum ein spezieller Issue, welcher bereits vordefinierte Arbeitsschritte enthält. Die Durchführung erfolgt analog zu einem Issue. Alle Issues einer Version, welche released wurde, können nicht mehr bearbeitet werden. Zusätzlich steht dem Supporter pro Version eine Liste von betroffenen Kunden zur Verfügung, die er nach dem Erstellen eines neuen Release informieren kann. Seite: 11 von 22 Semesterarbeit Datum:

12 Projekt: B2Tracking INTERNE ARCHITEKTUR Eine ausführliche Beschreibung der Architektur befindet sich im Anhang im Dokument [SAD]. Die Softwarearchitektur besteht hauptsächlich aus drei logischen Schichten. class Domain Model B2.Trac king.ui B2.Tracking.Domain Handler Sta tes Notification B2.Track ing.data Abb. 1: Logische Schichten Durch die Aufteilung in eine logische Schichtenarchitektur wird die Unabhängigkeit der austauschbaren Schichten gewährleistet. Wir verwenden in unserer Applikation die drei gängigen Schichten UI, Domain und Data. UI In dieser Schicht befinden sich sämtliche ASP.NET Seiten, sowie die dazugehörigen Code Behind Dateien. Von der UI-Schicht wird ausschliesslich auf die Domain-Schicht zugegriffen. Dies geschieht typischerweise durch das Instanziieren und verwenden eines PageHandlers, welche in der Domain-Schicht enthalten sind. Ein solcher Handler ist während dem gesamten Aufenthalt des Benutzers auf einer bestimmten Seite aktiv. Eine Referenz dazu wird in der Session unter einem automatisch generierten Schlüssel gespeichert. DOMAIN Die Domain-Schicht enthält die Implementation der Hauptlogik des Systems. So sind dort die Handler, welche die Use Cases implementieren, sowie die State Machine, welche für den korrekten Ablauf der Status verantwortlich ist, platziert. Als weiterer Teil befindet sich dort die gesamte Benachrichtigungslogik. DATA Die Daten-Schicht besteht aus dem Datenbankmodell, welches mit LinqToSql abgebildet wurde. Seite: 12 von 22 Semesterarbeit Datum:

13 Projekt: B2Tracking EXTERNE ARCHITEKTUR DMZ DB Server Request Response Client mit Browser Web Server Abb. 2: Externe Architektur Unsere Applikation läuft auf einem Web Server mit ASP.NET Unterstützung. Für die Datenhaltung wird ein MSSQL Datenbankserver verwendet, welcher aus Geschwindigkeitsgründen auf dem gleichen Server installiert ist. BROWSER Die Applikation wurde, wie vom Kunden gewünscht, für den Internet Explorer 7 von Microsoft optimiert. Dennoch haben wir auch weitere Browser wie Opera, Firefox und Chrome erfolgreich getestet. Die grössten Probleme hatten wir mit dem IE7 zu verzeichnen, welcher teilweise ein unerklärliches Verhalten mit einzelnen JavaScripts aufwies. Mit teilweise mehr oder weniger aufwändigen Workarounds konnten diese jedoch behoben werden KONZEPTE Dieses Kapitel soll einem Überblick über wichtige Konzepte geben, welche wir im Rahmen dieser Arbeit implementiert haben. Diese Konzepte werden ausführlicher im [SAD] unter Architekturkonzepte ausgeführt. SEITENAUFRUF Bei einem Seitenaufruf wird jeweils die CodeBehind Klasse der entsprechenden ASPX-Seite instanziiert. Zusätzlich verwenden wir für jede Seite einen PageHandler, welcher den Status der Seite speichert und Aufrufe entgegennimmt. Diese entsprechende Instanz wird in der Session unter einem automatisch generierten Schlüssel gespeichert. Bei einem Postback zum Server wird wieder dieselbe Instanz geholt, um die neuen Befehle abzuarbeiten. Dies ermöglicht beispielsweise auf einer Seite mit einem Speichern- und einem Abbrechen-Button, alle Datenbankbefehle im Memory durchzuführen, auch über mehrere Postbacks hinweg. Danach könnte der Anwender auf Abbrechen klicken und es reicht eine Zeile Code, um alle Änderungen zu verwerfen. Seite: 13 von 22 Semesterarbeit Datum:

14 Projekt: B2Tracking BENACHRICHTIGUNGEN Um die Benutzer des B2Tracking zu benachrichtigen wird ein NotificationManager eingesetzt. Bei diesem können sich beliebige NotificationProvider registrieren, um bei einem Ereignis aufgerufen zu werden. So haben wir standardmässig einen Datenbank- und einen NotificationProvider implementiert. Wird nun der NotificationManager von der StateMachine oder einem PageHandler aufgerufen, so leitet dieser die Meldung an die registrierten Provider weiter. Der DatenankNotificationProvider schreibt die empfangenen Meldungen in die Datenbank. Diese werden dem Benutzer auf der Message.aspx angezeigt. Der NotificationProvider hingegegen versendet die Meldungen per . STATE MACHINE Um die Stati eines Issues respektive der dazugehörigen Tasks zu verwalten, wurde die Klasse StateMachine ins Leben gerufen. Sie übernimmt den ganzen Ablauf eines Issues und ermöglicht anderen Komponenten mit wenig Aufwand den Issue zu steuern. Der Aufbau der Klassen folgt dem Strategy-Pattern, womit für jeden Status eine eigene Klasse existiert, welche wiederum auf einer gemeinsamen Basisklasse basiert. Seite: 14 von 22 Semesterarbeit Datum:

15 Projekt: B2Tracking PROBLEME / DESIGNENTSCHEIDUNGEN Im Verlauf der Analyse mussten wir verschiedene Design-Entscheidungen treffen. Zum Einen musste eine Technologie für den Datenzugriff gefunden werden, was uns schlussendlich etwas mehr an Zeit gekostet hat als erwartet. Zum Anderen standen für die Gestaltung der Oberfläche verschiedene Bibliotheken zur Auswahl. DATENBANKZUGRIFF Zur Auswahl standen die Technologien ADO.NET Entitity Framework und LinqToSql. Beide sind von Microsoft, jedoch vom Konzept her unterschiedlich. Eine ausführliche Beschreibung der beiden Systeme sowie zur Entscheidungsfindung sind im [SAD] vorhanden. Für unser Projekt haben wir haben wir nach der Evaluation auf LinqToSql gesetzt. GUI LIBRARY Eine Auflistung der verschiedenen Komponenten sowie eine entsprechende Beschreibung sind im [SAD] vorhanden. Es wurde auf die Komponentenbibliothek von DevExpress gesetzt. Seite: 15 von 22 Semesterarbeit Datum:

16 Projekt: B2Tracking 4.2 SCHLUSSFOLGERUNGEN Nachfolgend eine Zusammenfassung über den Projektverlauf sowie einen kurzen Ausblick über den zukünftigen Einsatz der Software RÜCKBLICK Das entwickelte System deckt alle Anforderungen ab, welche als nötig spezifiziert wurden. Der strikte und organisierte Aufbau des Systems legt den Grundstein für eine Integration in eine Desktop-Applikation. Als Datenspeicherungsschicht wurde die Technologie LinqToSql von Microsoft gewählt. Diese ist eine moderne Entwicklung und ermöglicht einen einfachen und schnellen Datenbankzugriff. Bei der Entwicklung wurde auch eine andere Technologie geprüft, ADO.NET Entity Framework, gegen die wir uns aber nicht zuletzt wegen einer starken Inflexibilität in LINQ-Befehlen, beispielsweise der fehlenden Typenumwandlung in Datenbankabfragen, entschieden haben. Die Wahl von DevExpress als GUI-Library hat sich trotz einigen Problemen als gute Entscheidung herausgestellt, da die Geschwindigkeit und das Design der Komponenten gegenüber den Microsoft eigenen klare Vorteile aufweisen. Ein Paradebeispiel stellt dabei wohl das Grid dar. Das Standardgrid ist sehr langsam im Aufbau und bietet keine automatischen Filter, wie das im Gegensatz von DevExpress geboten wird. Grosse Probleme im Rahmen der Entwicklung machte vorallem das sehr berühmte Browser-Problem. Die Entwicklung wurde stets auf unseren Testrechnern mit Alternativ-Webbrowsern wie Opera und Chrome getestet, während der Internet Explorer aussen vor gelassen wurde. In der Anforderungsspezifikation wurde die Wahl eines Zielbrowsers versäumt, weswegen nach einer gewissen Entwicklungszeit eine Entscheidung getroffen werden musste. Diese fiel auf den Internet Explorer, was einigen Aufwand nach sich trug, da dieser mit der Darstellung von (sogar der Microsoft-eigenen) Komponenten am meisten Probleme bereitete. Der starke Fokus auf DevExpress-Produkte führt ebenfalls zum Risiko auf spätere Inkompatibilitäten. Diese Komponenten bieten sehr viele Möglichkeiten und Features, welche bei der Entwicklung sehr ausgereizt wurden. Nicht zuletzt mussten einige Workarounds einprogrammiert werden, da die Komponenten teilweise mehr oder weniger mühsame Fehler aufgewiesen haben. Diese Konstellation bietet in Zukunft einige Risiken. Denn neue Versionen dieser Komponenten sollten auf jeden Fall (nach ausgiebigem Prüfen) eingesetzt werden, da diverse neue, interessante Features geplant sind und natürlich viele Bugs behoben werden. Dabei ist jedoch die Gefahr hoch, dass einige Workarounds nicht mehr nötig sind oder gar zu neuen Problemen führen. Deshalb ist ein genaues Prüfen der aktualisieren Versionen zwingend, wobei natürlich das Risiko trotzdem besteht, einige Punkte zu übersehen OFFENE PUNKTE Im Bezug auf die Implementation der Hauptfeatures gibt es nur noch wenige offene Punkte. Diese sind die noch fehlende Möglichkeit, Soll/Ist-Zeiten bei einem Task anzugeben. Die LINQ-Abfragen, durch welche die Daten aus der Datenbank geholt werden, bieten möglicherweise auch noch Optimierungspotenzial. Dabei könnten die Lade- Regeln noch angepasst werden, welche bestimmen, wie verknüpfte Datensätze bei einer Abfrage behandelt werden, respektive ob diese sofort geladen oder erst später evaluiert werden. Relativ offen ist der Einbau von weiteren Administrations-Features wie die Anpassung der Benutzer und Gruppen. Dies wird momentan über die eingebaute Verwaltung von ASP.NET gelöst, welche aber nur über das Visual Studio aufgerufen werden kann. Es gibt aber einige quelloffene Lösungen, welche ein vorgefertigtes Benutzer- und Gruppenmanagement für ASP.NET bieten. Solch eine Lösung sollte entweder in das bestehende System integriert oder mindestens als externe Lösung den Projektleitern zur Verfügung gestellt werden. Seite: 16 von 22 Semesterarbeit Datum:

17 Projekt: B2Tracking AUSBLICK Neben der Behebung der offenen Punkte steht natürlich in erster Linie vor allem das Bugfixing als Aufgabe an. Da wir der Heiniger & Partner AG weiterhin zur Verfügung stehen werden, haben wir die Möglichkeit, dies zu übernehmen. Das System wird erst Anfang 2009 in den Produktivbetrieb übergehen, weshalb diverse Verbesserungsmöglichkeiten in den Prozessen sich wohl erst in dieser Phase zeigen werden. In der Testphase sind bislang nur wenige Punkte aufgefallen, welche wir direkt in Angriff genommen haben. Seite: 17 von 22 Semesterarbeit Datum:

18 Projekt: B2Tracking 5 EINFÜHRUNG BEIM KUNDEN Um die Wünsche und Anforderungen des Kunden möglichst gut zu erfüllen, haben wir unsere Software sobald als möglich beim Kunden installiert. Ab der 10. Semester Woche haben wir jeweils am Mittwoch eine aktuelle Version vorgeführt und entsprechendes Feedback in unsere nächsten Arbeitsschritte einfliessen lassen. Somit haben wir sichergestellt, dass sich unser Produkt mit den Anforderungen des Kunden bestmöglich deckt. 5.1 PRODUKTIVUMGEBUNG DES KUNDEN Die Applikation läuft auf dem Webserver des Kunden, welcher auf den sowohl von intern als auch von extern zugegriffen werden kann. Betriebssystem Windows 2003 Server (x86) WebServer IIS6.NET Framework 3.5 Service Pack 1 Client OS Windows Vista und XP Client Browser IE 6 und ABLAUF Die Einführung beim Kunden verlief fliessend gegen Ende des Projektes. Viele Fehler wurden vor allem im Bereich der verschiedenen Browser gefunden. Da wir für die Entwicklung meistens mit den Browsern Opera, Firefox und Chrome testeten, wurden Fehler im IE erst vom Kunden bemerkt. Dies führte dazu, dass gegen Ende der Testphase vor allem an der IE Kompatibilität gearbeitet wurde. Ein weiteres Problem zu Beginn der Einführung hatten wir mit dem produktiven Webserver des Kunden. Dieser hatte grössere Probleme mit einer Komponente eines Drittherstellers, wie sich später herausgestellt hat. Dies kostete uns vor allem an den Tagen Zeit, an denen wir beim Kunden gearbeitet haben. Alles in allem funktionierte das Ganze aber sehr gut und wir konnten eine Woche vor Abschluss eine funktionierende Version ausliefern. 5.3 FEEDBACK DES KUNDEN Mit einer kleineren Reihe von Fallbeispielen haben wir das B2Tracking System, dass speziell auf unsere Bedürfnisse zugeschnitten wurde, im Idealfall getestet. Der Funktionsumfang und dessen Abläufe wiederspiegeln unsere Aufgabenstellung. Ungereimtheiten und grobe Fehler wurden dabei nicht gefunden. Unstimmigkeiten bei den Fallbeispielen konnten meistens dem Verhalten unterschiedlicher Browsern zugeordnet werden. Die uns zu diesem Zeitpunkt zur Verfügung stehende Dokumentation war für uns verständlich und auch von Projektunkundigen eine Hilfe und nachvollziehbar. Vor der definitiven Einführung des B2Tracking wird das neue Tool noch eine Reihe von Test bei Heiniger & Partner AG durchlaufen. Für die definitive und produktive Version von B2Tracking werden uns die Entwickler Bolliger und Schwendener nach Beendigung des momentanen Semesters noch einmal zur Verfügung stehen. Wir danken allen Beteiligten, im Speziellen den Herren Bolliger und Schwendener für Ihren Einsatz und das Gelingen. Heiniger & Partner AG Toni Fuchs Seite: 18 von 22 Semesterarbeit Datum:

19 Projekt: B2Tracking 6 PERSÖNLICHE BERICHTE Zum Schluss die persönlichen Berichte, welche die Erfahrungen und Erkenntnisse der beiden Teammitglieder während des Projektes beschreiben. 6.1 MICHAEL BOLLIGER THEMAWAHL Da ich neben dem Studium noch bei der Mettler Toledo AG und der Heiniger & Partner AG arbeite, habe ich mich als erstes mit den entsprechenden Personen der beiden Firmen unterhalten. Anfänglich waren beide sehr interessiert mit uns zusammenzuarbeiten, als es jedoch an der Zeit war ein passendes Thema zu finden, haben wir uns für die Firma Heiniger & Partner AG entschieden. Für Florian und mich war es wichtig, dass wir etwas mit.net entwickeln können, was mit dem B2Tracking basierend auf ASP.NET der Fall war PROJEKTVERLAUF Da wir unser definitives Thema erst kurz vor Beginn der Semesterarbeit gefunden haben, war es auch ein Teil der Arbeit, die genauen Anforderungen mit dem Kunde auszuarbeiten. So haben wir die im SE2 Projekt kennengelernten Artefakte zur Anforderungsanalyse erstellt und zur Absicherung vom Kunde unterzeichnen lassen. Die Projektplanung haben wir zum ersten Mal mit MS Project erstellt, was uns einen deutlichen Mehraufwand einbrachte. Nun haben wir das ganze durchgezogen, sind jedoch zum Schluss gekommen, dass wir für ein solch kleines Projekt eher wieder auf Excel oder ähnliche Lösung setzen werden. Die Umsetzung der Anforderungen fand ich sehr spannend und ich konnte auch viel Neues lernen. So habe ich zum ersten Mal ein grösseres ASP.NET Projekt umgesetzt und konnte mich eingehend mit der gesamten Technologie auseinandersetzen. Weiter haben wir uns auch zum ersten Mal mit den neuen Technologien LinqToSql und dem ADO.NET Entity Framework auseinandergesetzt. Gegen Ende des Projektes haben wir die Applikation in der Firma eingeführt und somit weitere Testpersonen mit einbezogen. Dies war sehr hilfreich, da man als Entwickler selbst, das ganze Meist richtig bedient, und allfällige Fehler nur schwer findet. So konnten wir auch das erhaltene Feedback in die abschliessende Entwicklung der Software einfliessen lassen ARBEIT IM TEAM / HEINIGER & PARTNER AG Die Arbeitsumgebung beim Kunden war mir weitgehenden bekannt, da ich bereits seit dem 2. Semester dort arbeite. Für die gesamte Projektdauer stand Florian und mir ein eigener Büroraum zur Verfügung, indem wir ungestört arbeiten konnten. Mit Florian habe ich während dem Studium bereits verschiedene Arbeiten durchgeführt. So auch das SE2 Projekt im 4. Semester, was uns bereits vor der Semesterarbeit zu einem eingespielten Team machte RÉSUMÉE Die Semesterarbeit war ein voller Erfolg für mich und hat mir oft sehr viel Freude bereitet. Trotz einzelnen Tiefpunkten vermochten wir uns gegenseitig immer wieder zu motivieren und es gelang uns, das Projekt erfolgreich umzusetzen. Für die Bachelor Arbeit konnte ich zudem weitere wertvolle Erfahrungen bezüglich Projektplanung sammeln. Seite: 19 von 22 Semesterarbeit Datum:

20 Projekt: B2Tracking 6.2 FLORIAN SCHWENDENER THEMAWAHL Das von unserem Arbeitgeber vorgeschlagene Thema Bug-Tracking Applikation in ASP.NET vermochte mich schnell zu überzeugen. In der Vergangenheit habe ich schon oft mit ASP.NET gearbeitet und es hat immer sehr viel Spass gemacht. Die Möglichkeit, dieses Projekt nun als Semesterarbeit zu absolvieren, war also perfekt für mich. Ausserdem arbeite ich schon lange bei der Heiniger & Partner AG und war stets sehr zufrieden PROJEKTVERLAUF Michael und ich haben von Anfang an sehr engagiert für dieses Projekt gearbeitet und kamen meist ohne Probleme auf die erforderliche Anzahl an Stunden. Es war nicht wirklich ein Muss, sondern hat vor allem am Anfang sehr viel Spass gemacht. Die Anforderungserfassungs- und Planungsphasen haben wir gut und zügig gemeistert, so dass wir schon relativ früh mit der Entwicklung beginnen konnte, wie das beim RUP in Bezug auf die Hauptkomponenten durchaus gewünscht ist. Die Programmierung verlief anfangs reibungslos und wir kamen in grossen Schritten vorwärts. Die Seitengestaltung brachte unseren Arbeitsfluss erstmals ins Stocken. Das Verteilen aller Informationen, welche dem Anwender angezeigt und von ihm editierbar sein müssen, hat sich als sehr aufwändig gestaltet. Bei einer Desktop-Applikation schien dies mir einfacher, da gewohnter, zu sein. Ausserdem muss bei einer Webapplikation auch sehr viel Aufwand für das Design an sich betrieben werden, was wiederum in der Windows Forms Programmierung einfacher fällt. Die grössten Probleme, was dann auch an der Motivation kratzte, war das oft willkürlich scheinende Verhalten der Web-Komponenten bzw. Controls. Vor allem die Komponenten von DevExpress zerrten oft an den eigenen Nerven und verhielten sich teilweise entgegen jeglicher Logik. Somit mussten Michi und ich uns immer wieder gegenseitig mit eigenen Erfahrungen, wie denn nun diese Controls ausgetrickst werden konnten, unterstützen. Schlussendlich konnten wir fast alle Probleme lösen, wenn auch einige mit deutlich mehr Programmiercode als in der Theorie nötig gewesen wäre ARBEIT IM TEAM / HEINIGER & PARTNER AG Mit Michael hatte ich bereits das SE2-Projekt dotnetlocalizer erfolgreich durchgeführt, ausserdem arbeiteten wir gemeinsam seit langer Zeit bei der Heiniger & Partner AG. Somit kannten wir unsere Arbeitsweise und konnten die Arbeitsaufteilung problemlos durchführen. Diese Zusammenarbeit klappte relativ reibungslos, kleine Differenzen und Meinungsverschiedenheiten gehören dazu. Das Arbeitsklima in den Büros der Heiniger & Partner AG in Wetzikon war mir ebenfalls schon seit einem Jahr vertraut und war wie immer sehr angenehm RÉSUMÉE Die Arbeit am Projekt hat wie erwartet sehr viel Spass gemacht und war definitiv eine sehr lehrreiche Erfahrung. Probleme mit der Darstellung und den Bugs der Webcontrols zerrten lange Zeit an unseren Nerven, was jedoch früher oder später meist gemeistert werden konnte. Somit kann ich auf eine interessante Zeit zurückblicken, in der ich in Sachen Projektplanung und Durchführung durchaus sehr profitieren konnte. Alles in allem bin ich sehr zufrieden mit dem Projekt und freue mich, nächstes Semester bei der Heiniger & Partner AG die Bachelorarbeit in Angriff zu nehmen. Seite: 20 von 22 Semesterarbeit Datum:

21 Projekt: B2Tracking 7 VERZEICHNISSE 7.1 LITERATURVERZEICHNIS Tabelle 1: Literaturverzeichnis Kürzel Beschreibung [LARMAN04] Craig Larman, Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development, Oktober 2004 [MACDONALD07] Matthew MacDonald, Beginning ASP.NET 3.5 in C# 2008: From Novice to Professional, Second Edition, November 2007 [RATTZ07] Jr., Joseph C. Rattz, Pro LINQ: Language Integrated Query in C# 2008, November 2007 [MEHTA08] Vijay P. Mehta, Pro LINQ Object Relational Mapping in C# 2008, Juli GLOSSAR Tabelle 2: Glossar Abkürzung VS ASP.NET.NET MSSQL Bedeutung Microsoft Visual Studio Active Server Pages, Webtechnologie von Microsoft auf Basis des.net Frameworks Softwareentwicklungstechnologie von Microsoft Microsoft SQL B2 Bauplus, Version 2 Seite: 21 von 22 Semesterarbeit Datum:

22 Projekt: B2Tracking 8 ANHÄNGE Nr Bereich Kürzel Beschreibung I Projektmanagement PRP Projektplan RSK Risikoanalyse UCS Use Cases II Anforderungen SUP Supplementary Specification VIE Views III Analyse DOM Domänenmodell IV Design SAD Software Architecture Document V Tests UCT Use Case Tests ARP Arbeitspakete VI Zeiterfassung ZPS Zeitplan Soll ZPI Zeitplan Ist VII Handbuch HBM Handbuch für die Verwendung von B2Tracking Seite: 22 von 22 Semesterarbeit Datum:

23 I Projektmanagement

24 asdf

25 Projekt: B2Tracking Seite: 1 von 6 PROJEKTPLAN 1 DOKUMENTINFORMATIONEN 1.1 ÜBERSICHT Dieses Dokument beschreibt detailliert das Projekt B2Tracking. Es enthält die Planung des Projektes mit Meilensteinen und die Aufteilung der Arbeit in Arbeitspakete. 1.2 ÄNDERUNGSGESCHICHTE Version Datum Änderung Autor Dokument erstellt fsc Meilensteine hinzugefügt. Qualitätsmerkmale angepasst. mbo PRP Projektplan.docx Datum:

26 Projekt: B2Tracking Seite: 2 von INHALT 1 Dokumentinformationen Übersicht Änderungsgeschichte Inhalt Projektübersicht Ausgangslage Zweck und Ziel Annahmen und Einschränkungen Projektorganisation Organisationsstruktur Meilensteine Infrastruktur Programmierumgebung NET Framework Richtlinien für Design und Entwicklulng Konfigurationsmanagement Qualitätssicherungsmassnahmen Automatische Tests Anwendungsbereich Systemtests Codierungsrichtlinien Einsatz eines Versionisierungssystems Qualitätsanforderungen Sourcecode... 6 PRP Projektplan.docx Datum:

27 Projekt: B2Tracking Seite: 3 von 6 2 PROJEKTÜBERSICHT Die Firma Heiniger & Partner AG in Wetzikon entwickelt und betreut Bauadministrations- und Auftragsbearbeitungssoftware. Im Moment wird B1 eingesetzt, während die zurzeit in Entwicklung stehende Version B2 diese ablösen wird. Die neue Applikation wird in C# auf.net geschrieben. Gesucht ist nun eine Software, welche der Erfassung von Fehlern, Anforderungen und weiteren Kundenwünschen dient. Dabei soll der ganze Workflow vom Eingang der Meldung vom Kunden über das Beheben und das Testen bis hin zur Rückmeldung am Kunden abgebildet werden. Sie soll sich an bestehenden Issue-Tracking Systemen orientieren, jedoch ist ein dynamischerer Workflow verlangt. Die Schritte zur Abarbeitung des Problems sollen frei definierbar sein, passend auf den jeweiligen Fall zugeschnitten. Realisiert wird die Software als Webprojekt, welches jederzeit unabhängig vom Zugriffsort ohne spezielle Anforderungen verwendet werden kann. 2.1 AUSGANGSLAGE Für B1 werden bis heute unterschiedliche Systeme für die Erfassung und Abarbeitung von Fehlern sowie das Verwalten der Supportdatenbank eingesetzt: - Fehler/Anforderungen erfassen: Excel - Dokumentationen der Fehler: Word - Releaseplanung: Excel - Beschreibung der Korrekturen: Word - Tests & Ergebnisse: Papierform - Support-Datenbank: Web / ASP Das jetzige System ist unter den beteiligten Personen gut eingespielt und funktioniert relativ problemlos. Wegen der Anzahl der verschiedenen Systeme und der fehlenden Ordnung soll dieses System jedoch abgelöst werden. 2.2 ZWECK UND ZIEL Das Hauptziel ist die Vereinigung der bislang eingesetzten verschiedenen Systeme und somit eine Zentralisierung auf eine einzige Applikation. Durch eine einfache Bedienung sollen die Abläufe von Supportfällen effizienter durchlaufen. Sehr wichtig ist auch eine bessere Integration von Kunden. So wird jeder Kunde bei der Problemlösung informiert. Das Issue-System soll neu das Informationssystem für folgende Punkte bilden: - Fehlerbehebung - Erweiterungen und Anpassungen der B2-Applikation - Release-Übersicht mit behobenen Bugs - Unterstützung des Supports 2.3 ANNAHMEN UND EINSCHRÄNKUNGEN Da dieses Projekt im Rahmen einer Semesterarbeit durchgeführt wird, steht den Mitgliedern nur eine beschränkte Anzahl Stunden zur Verfügung. Diese beläuft sich pro Person auf etwa 8 * 30h = 240. PRP Projektplan.docx Datum:

28 Projekt: B2Tracking Seite: 4 von 6 3 PROJEKTORGANISATION Unser Projektteam besteht aus zwei Mitgliedern, welche beide auf der gleichen Hierarchieebene arbeiten. Als Berater kommt Rainer Baumann, Dozent an der HSR zum Einsatz. Um die Programmierung und das Sammeln von Dokumenten zu koordinieren, setzen wir den SVN-Server der Heiniger & Partner AG ein. Mittwochs arbeiten beide Mitglieder in der Firma in Wetzikon. 3.1 ORGANISATIONSSTRUKTUR Person Funktion Kontakt Florian Schwendener Projektleiter, Entwickler fschwend@hsr.ch Michael Bolliger Projektleiter, Entwickler mbollige@hsr.ch Anton Fuchs Kunde fuchs@heiniger.ch Rainer Baumann Betreuer von der HSR rainer.baumann@hsr.ch 3.2 MEILENSTEINE MS Titel Woche Termin Beschreibung M1 Anforderungen / Zeitplan SW Projektplan fertiggestellt - Zeitplan erstellt - Anforderungen erfasst und bereit um vom Kunden unterzeichnet zu werden. - Verantwortlichkeiten zugeteilt M2 Architektur Prototyp SW Erster Architektur Prototyp, welcher dem Kunden gezeigt werden kann. M3 Design SW Das Design der Applikation steht fest, es werden keine entscheidenden Veränderungen mehr vorgenommen. - Architekturen sind getestet und als gut befunden. M4 Beta Version SW Alle Funktionen eingebaut - Testversion, die mit dem Kunden ausgiebig getestet wird. M5 Release Version SW Fertig getestete Version vorhanden - Diese Version wird beim Kunden installiert und eingesetzt. M6 Projekt abgeschlossen SW Projekt fertiggestellt. PRP Projektplan.docx Datum:

29 Projekt: B2Tracking Seite: 5 von 6 4 INFRASTRUKTUR 4.1 PROGRAMMIERUMGEBUNG Wir verwenden Visual Studio 2008 und schreiben unseren Code in C#. Für das Visual Studio wird zusätzlich das Resharper Add-in als Codeanalysetool eingesetzt NET FRAMEWORK All Schichten bis werden auf Basis des.net Framework 3.5 implementiert. Für das ORM (Object Relational Mapping) wird Linq to SQL, welches im.net Framework 3.5 integriert ist, eingesetzt. 4.2 RICHTLINIEN FÜR DESIGN UND ENTWICKLULNG Um bereits gelöste Probleme zu beheben, setzen wir auf bekannte Patterns, welche vor allem in [Larman] erläutert sind. Die Codierungsrichtlinien richten sich nach den Richtlinien, welche im.net-bereich üblich sind. Diese sind den Entwickler bekannt und werden nicht genauer beschrieben. 4.3 KONFIGURATIONSMANAGEMENT Für die Abgleichung der Quellcodes und der übrigen Dokumente setzen wir auf den SVN-Server der Heiniger & Partner AG. Somit sind die Daten in der Regel 3-fach vorhanden (2 Clients, 1 Server), was als Backuplösung ausreichen sollte. Zusätzlich wird der Server regelmässig gesichert. Für die Integration ins Visual Studio wird das Unified SCC Plugin verwendet. PRP Projektplan.docx Datum:

30 Projekt: B2Tracking Seite: 6 von 6 5 QUALITÄTSSICHERUNGSMASSNAHMEN Um sicherstellen zu können, dass die B2Tracking Software bezüglich der verschiedenen Qualitätsmerkmale den Anforderungen entspricht, werden folgenden Vorgehensmodelle und Methoden angewandt. 5.1 AUTOMATISCHE TESTS Das erstmalige Erstellen der Unit Tests unterliegt der Verantwortung des Entwicklers, welcher gleichzeitig ein neues Modul erstellt. Die implementierten Klassen sollen, sofern sinnvoll und machbar, mit NUnit Tests ausgestattet werden. Da dem Projekt kein dedizierter Server zur Verfügung steht, auf dem fortlaufend die Unit Tests durchgeführt werden können, müssen die jeweiligen Tests selbstständig vom jeweiligen Entwickler ausgeführt werden ANWENDUNGSBEREICH Unit Tests müssen nur für die Kernklassen des Projektes erstellt werden. Für die grafischen Komponenten muss dies nicht erledigt werden. 5.2 SYSTEMTESTS Für die geplante Beta und Release Version wird ein Systemtest durchgeführt. Dieser wird im Verlauf der Entwicklung genauer festgelegt. 5.3 CODIERUNGSRICHTLINIEN Siehe EINSATZ EINES VERSIONISIERUNGSSYSTEMS Alle relevanten Projektdaten wie Quellcode und Dokumente werden im Subversionsserver abgelegt. Checkins werden summarisch kommentiert, sodass die anderen Entwickler den Überblick behalten können, welche Änderungen erfolgt sind QUALITÄTSANFORDERUNGEN SOURCECODE Vor dem Einchecken von Quellcode müssen folgende Bedingungen erfüllt sein - Der Quellcode kompiliert ohne Warnungen. - Die Änderungen dürfen nicht zu Kompilierungsfehlern in anderen Modulen führen. - Die Quellcodekommentare müssen auf ihre Gültigkeit überprüft werden. PRP Projektplan.docx Datum:

31 Projekt: B2Tracking Risikoanalyse Risiko Beschreibung W'keit Strategie zur Problemlösung W10 Ende Allgemein Spannungen im Team Uneinigkeit im Team, gemeinsame Problemlösung nicht möglich Höhere Gewalt Unvorhergesehene Ereignisse (z.b. Zug-Ausfall --> gemeinsames Treffen nicht möglich) 10% Betreuer als Vermittler einschalten, evtl. Teammitglied als klein Projektleiter ernennen 5% Zusammenarbeit über Internet, Treffen verschieben normal Anforderungen Kunde ändert Anforderungen Der Kunde hat neue Ideen und möchte grundlegende Anforderungen ändern. 5% Die zu beginn des Projektes festgelegten Anforderungen werden vom Kunden schriftlich bestätigt und unterzeichnet. klein Zeitplan Zeitknappheit Soll-Zeiten können nicht eingehalten werden 20% Arbeit umteilen, Reservezeit verwenden, mehr Arbeitsstunden einsetzen Krankheit Teammitglied wird arbeitsunfänhig 10% Arbeit auf andere Mitglieder verteilen, evtl. Funktionsumfang reduzieren Ressourcen Hardwaredefekt Projektbezogene Technik Inkompatiblität Analyse Technologien Visual Studio.Net Framework 3.5.Net Tiers SVN-Server, Arbeitsstationen der Teammitglieder fallen aus Getrennt entwickelte Komponenten arbeiten nicht zusammen Resultate der Analyse bringen zu umfangreiche Arbeiten hervor Projekt-, Solution- oder Ressourcen-Dateien sind fehlerhaft Das neue Framework hat fehler oder undokumentierte Funktionen. erhöht normal 5% Ersatz besorgen, Zeitplan ändern wenn nötig. normal 15% Schnittstellen überarbeiten, evtl. Neuentwicklung, bessere sehr klein Zusammenarbeit 25% Alternativen prüfen, evtl. Funktionsumfang reduzieren nicht mehr vorhanden 2% Kontakt zu Microsoft klein 2% Kontakt zu Microsoft sehr klein nicht mehr vorhanden RSK Risikoanalyse.xls

32 asdf

33 II Anforderungen

34 asdf

35 Projekt: B2Tracking Seite: 1 von 9 USE CASES 1 DOKUMENTINFORMATIONEN 1.1 ÜBERSICHT Dieses Dokument enthält eine Beschreibung der Use Cases. Die wichtigsten sind in vollem Umfang beschrieben. 1.2 ÄNDERUNGSGESCHICHTE Version Datum Änderung Autor Dokument erstellt fsc Use Case Issue anlegen fully dressed fsc Use Cases Task durchführen, Issue durchführen und Release erzeugen fully dressed, div. Ergänzungen gemacht fsc UCS Use Cases.docx Datum:

36 Projekt: B2Tracking Seite: 2 von INHALT 1 Dokumentinformationen Übersicht Änderungsgeschichte Inhalt Basisinformationen Rollen Begriffe Use Cases Brief Use Cases Fully Dressed UC01: Issue anlegen UC02: Issue durchführen UC03: Task durchführen UC04: Release erzeugen... 9 UCS Use Cases.docx Datum:

37 Projekt: B2Tracking Seite: 3 von 9 2 BASISINFORMATIONEN 2.1 ROLLEN Rolle Projektleiter Mitarbeiter Entwickler Supporter Tester Beschreibung Administrator des Issue-Systems Programmierer am BauPlus-Projekt Mitarbeiter im Kundensupport Führt Funktions- und Release-Tests durch 2.2 BEGRIFFE Begriff Beschreibung Issue - Probleme, Anforderungen und andere Anpassungen, die am BauPlus durchgeführt werden sollen - Definiert einen Ablaufplan für verschiedene Tasks - Muss folgende Felder enthalten: Eingangszeitpunkt Erfasser Betroffene(r) Kunde(n) Computerversion, Bauplus Version etc. Problembeschreibung (inkl. Dateianhänge) Priorität Min. 1 Stichwort (Tag) z.b. Modul, - Vor dem Ablauf muss er um folgende Felder vom Projektleiter ergänzt werden: Ziel-Release Ablauf in Tasks - Kann beliebige zusätzliche Informationen enthalten, welche aus Text + Ahängen besteht, wie z.b. Lösungsvorschlag - Folgende Live-Informationen sind immer verfügbar: Status Infos über betroffenes Release - Ein Issue ist immer in einem der folgenden Stati (Live-Stati): Frisch: Der Issue wurde vom Supporter angelegt. Ggf. hat der Projektleiter auch einige Informationen hinzugefügt. In Bearbeitung: Der Projektleiter hat den Ablauf des Issues gestartet. Abgeschlossen: Alle Tasks des Issues wurden abgeschlossen. UCS Use Cases.docx Datum:

38 Projekt: B2Tracking Seite: 4 von 9 Klassifikation - Beschreibt einen Issue - Wird vom Supporter eingetragen - Schlägt dem Projektleiter einen Ablauf von Tasks vor - Folgende Klassifikationen sind enthalten: Programmierfehler Fehler in Dokumentation Task - Aufgabe, welche ein Mitarbeiter zu erledigen hat - Projektleiter muss folgende Felder ausfüllen: Rolle / Zielperson Beschreibung Soll-Zeit (optional) - Mitarbeiter muss folgende Felder eintragen: Ist-Zeit Soll-Zeit (falls nicht ausgefüllt durch Leiter) analysis Beschreibung Business über Proces... Ablauf - Intern ist der Task in folgenden Stati: Neu Zugeteilt In Bearbeitung An Projektleiter Fertig Tag - Stichwort zur Beschreibung eines Issues - Vorerst vorgegebene Liste - Beispiele: Modul Adressen Terminal Server Version - Auswahl aus: next Version (nächste Version, die veröffentlicht wird) future (keiner konkreten Version zugewiesen) Auswahl aus eingetragenen Versionen UCS Use Cases.docx Datum:

39 Projekt: B2Tracking Seite: 5 von 9 3 USE CASES BRIEF Nr Use Case Beschreibung 01 Issue anlegen Der Supporter erfasst einen neuen Issue im System, danach wird der Projektleiter informiert. 02 Issue durchführen Der Projektleiter öffnet einen erfassten Issue, ergänzt ihn um weitere Eingaben, weist ihn einem kommenden Release zu, plant die Schritte und startet ihn. Es werden dann die betroffenen Mitarbeiter über zu erledigende Tasks informiert. 03 Task durchführen Ein Mitarbeiter wird benachrichtigt und erhält eine Aufgabe, die er erledigen muss. Nach der Durchführung schliesst er den Task im System ab. 04 Release erzeugen Der Projektleiter löst ein neues Release aus. Es beinhaltet alle Issues, welche der gewählten Version zugewiesen und abgeschlossen sind. Anschliessend wird ein Release-Test durchgeführt, dessen Bestätigung durch den Tester den Use Case weiterführt. Durch den Projektleiter wird der Vorgang abgeschlossen. 05 Versionen CRUD Es können neue Versionen angelegt und noch nicht veröffentlichte geändert oder gelöscht werden. 06 Benutzer CRUD Benutzer werden erstellt, geändert oder gelöscht. Ausserdem können sie bestehende Rollen einnehmen. 07 Tasks CRUD (optional) Der Projektleiter kann neue Tasks hinzufügen, diese konfigurieren oder auch löschen. 08 Klassifikationen CRUD (optional) Der Projektleiter kann Klassifikationen erstellen, bearbeiten und löschen. 09 Tags CRUD (optional) Der Projektleiter kann Tags erstellen, bearbeiten und löschen. UCS Use Cases.docx Datum:

40 Projekt: B2Tracking Seite: 6 von 9 4 USE CASES FULLY DRESSED 4.1 UC01: ISSUE ANLEGEN Overview Der Supporter legt einen neuen Issue an. Stakeholder and Interests - Supporter: Will einen neuen Issue erstellen - Projektleiter: Möchte eine umfassende Beschreibung erhalten Preconditions - System ist erfolgreich im Betrieb - Der Supporter ist im System eingeloggt - Ein Kunde hat den Support kontaktiert und äussert einen Wunsch/Fehler oder ähnliches Success Guarantee Im System wurde ein neuer Issue mit allen benötigten Daten angelegt. Der Projektleiter wurde elektronisch informiert. Main Success Scenario 1. Der Supporter eröffnet einen neuen Issue. 2. Die benötigten werden ausgefüllt 3. Der Issue wird gespeichert. 4. Projektleiter wird über den neuen Issue informiert. Extensions or Alternative Flows 1a Der Issue ist bereits im System erfasst worden 1a Issue ist abgeschlossen 1 Der Kunde wird direkt mit den Informationen im System versorgt. 1b Issue ist noch aktiv 1 Der Kunde wird dem Issue als beteiligter Kunde hinzugefügt. 2a Für einige Felder fehlen die Informationen 1 Es folgt ein Hinweis, dass die Felder sobald wie möglich unbedingt auszufüllen sind. 2b Der Supporter möchte weitere Informationen hinzufügen Special Requirements Keine Technology and Data Variations List Keine Frequency of Occurence Sehr oft (ca. 200/Jahr) jedesmal wenn ein Kunde eine Supportanfrage stellt Miscellaneous - UCS Use Cases.docx Datum:

41 Projekt: B2Tracking Seite: 7 von UC02: ISSUE DURCHFÜHREN Overview Der Projektleiter startet den Ablauf eines Issues. Stakeholder and Interests - Projektleiter: Wünscht eine übersichtliche Ansicht, welche den Ablauf klar ersichtlich macht. - Mitarbeiter: Wird über einen durchzuführenden Task informiert und sieht den Status des Issues. Preconditions - System ist erfolgreich im Betrieb - Der Projektleiter ist im System eingeloggt - Issue wurde vom Supporter eröffnet. Success Guarantee Der Issue wurde im System abgeschlossen. Alle Tasks wurden durchgeführt und alle nötigen Informationen sind eingetragen. Main Success Scenario 1. Der Projektleiter betrachtet einen unbehandelten Issue. 2. Er nimmt ihn an. 3. Er wählt ein Ziel-Release (Vorschlag: next Version ) 4. Tasks wählen: Tasks entfernen, hinzufügen, bearbeiten oder in ihrer Reihenfolge umkehren.. Die Taskliste darf auch leer sein. 5. Task einrichten: Für den gewählten Task werden benötigte Felder ausgefüllt/geändert (siehe Beschreibung Task) Schritt 5 für jeden Task wiederholen 6. Der Projektleiter startet den anstehenden Schritt 7. Mitarbeiter wird über einen Task informiert und erledigt ihn UC04 8. Der nächste Task wird ablaufbereit. 9. Projektleiter startet den nächsten Task. Schritte 6-9 werden für jeden Task wiederholt 10. Der Projektleiter trägt abschliessende Informationen ein. 11. Task wird als definitiv erledigt markiert. Extensions or Alternative Flows * Der Projektleiter kann zusätzliche Informationen hinzufügen. 2a Issue wurde bereits von einem anderen Projektleiter übernommen 1 Übernahme nicht möglich Abbruch 3a Issue wird nicht realisiert 1 Keine wählen 3b Es sind keine zukünftigen Versionen vorhanden 1a Projektleiter erstellt eine neue Version 1b Projektleiter wählt offen oder nächste Version 6a Es gibt keine anstehenden Tasks 1a Der Projektleiter hat die Möglichkeit, den Issue abzuschliessen (mit Begründung). 8a Projektleiter ist mit Abschluss nicht zufrieden 1 Weist den Task an den Mitarbeiter zurück 2 Dieser wird informiert und führt den Task aus 3 Meldet den Abschluss erneut an den Projektleiter Wird wiederholt, bis der Projektleiter den Abschluss bestätigt 9a Projektleiter möchte den Task abbrechen 1 Wählt das Stoppen des Issues aus UCS Use Cases.docx Datum:

42 Projekt: B2Tracking Seite: 8 von 9 Special Requirements Keine Technology and Data Variations List Keine Frequency of Occurence Oft (siehe UC01) Miscellaneous UC03: TASK DURCHFÜHREN Overview Ein Mitarbeiter führt einen Task durch. Stakeholder and Interests - Projektleiter: Möchte Infos, wann der Task fertig sein wird - Mitarbeiter: Möchte Infos zum Task einsehen können. Preconditions - System ist erfolgreich im Betrieb - Der Mitarbeiter ist im System eingeloggt - Mitarbeiter/Rolle bekam Task zugeteilt Success Guarantee Der Mitarbeiter hat seinen Task abgeschlossen und dies im System eingetragen. Der Projektleiter wurde informiert. Main Success Scenario 1. Mitarbeiter öffnet einen Task und liest ihn durch. 2. Erledigt die eingetragene Arbeit. 3. Er trägt abschliessende Informationen ein (Kommentare, Dateien, etc.) 4. Der Task wird abgeschlossen. 5. Projektleiter wird über Abschluss informiert. Extensions or Alternative Flows * Der Mitarbeiter kann zusätzliche Informationen hinzufügen. 1a Der Issue wurde einer Rolle zugeteilt 1 Der Mitarbeiter kann die Aufgabe annehmen. 2a Die Soll-Zeit wurde vom Projektleiter vorgegeben. 1 Der Mitarbeiter sollte sich an diese Zeit halten. 4a Er möchte, dass andere Personen durch den Abschluss dieses Tasks benachrichtigt werden. 1 Es können zu benachrichtigende Personen eingetragen werden. Special Requirements Keine Technology and Data Variations List Keine Frequency of Occurence Sehr oft (ca. 2-5 pro Issue). Ein Issue enthält meist mehrere Tasks. Miscellaneous - UCS Use Cases.docx Datum:

43 Projekt: B2Tracking Seite: 9 von UC04: RELEASE ERZEUGEN Overview Der Projektleiter erstellt ein neues Release. Stakeholder and Interests - Projektleiter: Fordert, dass die Benachrichtigungskette eingehalten wird und will alle erledigten Issues miteinbeziehen. - Tester: Will über Testdurchführung informiert werden und den Projektleiter nach dem Testen informieren. Preconditions - System ist erfolgreich im Betrieb - Der Projektleiter ist im System eingeloggt - Es wurden seit der letzten Erzeugung Issues abgeschlossen. Success Guarantee Das Release wurde erstellt. Die Version wurde vom Entwickler erzeugt und vom Tester geprüft. Alle Supporter wurden über gelöste Issues, welche ihre Kunden betreffen, informiert. Main Success Scenario 1. Projektleiter wählt die Version. 2. Projektleiter erstellt einen Release. 3. System schliesst alle noch offenen Issues ab, sofern diese keine aktiven Tasks mehr enthalten. 4. System erstellt ein neues Release für die ausgewählte Version mit einem vordefinierten Task Plan. 5. Projektleiter startet den Release Task Plan. 6. Task Plan wird gemäss Use Case Task Durchführen Task für Task erledigt. 7. Projektleiter schliesst das Release ab. Extensions or Alternative Flows 1a Es sind keine zukünftigen Versionen vorhanden 1. Projektleiter erstellt eine neue Version. 3a Mindestens ein Issue enthält noch aktive Tasks. 1. System zeigt Meldung an, dass für diese Version noch kein Release erstellt werden kann. 2. Use Case wird abgeschlossen. Special Requirements Keine Technology and Data Variations List Keine Frequency of Occurence Jedesmal, wenn ein neues Release veröffentlicht werden soll (ca. 20 / Jahr) Miscellaneous - UCS Use Cases.docx Datum:

44 asdf

45 Projekt: B2Tracking Seite: 1 von 6 ERGÄNZENDE ANFORDERUNGEN 1 DOKUMENTINFORMATIONEN 1.1 ÜBERSICHT Dieses Dokument enthält die Supplementary Specification. 1.2 ÄNDERUNGSGESCHICHTE Version Datum Änderung Autor Initial Version, Draft mbo SUP Suplementary Specification.docx Datum:

46 Projekt: B2Tracking Seite: 2 von INHALT 1 Dokumentinformationen Übersicht Änderungsgeschichte Inhalt Einführung Zweck Referenzen Funktionalität Protokollierung und Fehlerbehandlung Sicherheit Richtigkeit Benutzbarkeit Lokalisierung Anzeige Bedienung Bedienungsanleitung Zuverlässigkeit Speichern von Daten Performance Wartbarkeit Fehlererkennung / Analyse Konfigurierbarkeit Anpassungs- und Erweiterungsfähigkeit Auslieferung Rechtliche Probleme Software Ideenrecht / Urheberrecht... 6 SUP Suplementary Specification.docx Datum:

47 Projekt: B2Tracking Seite: 3 von 6 2 EINFÜHRUNG 2.1 ZWECK Dieses Dokument beschreibt alle ergänzenden Anforderungen für die Software B2Tracking. Die nichtfunktionalen Anforderungen beziehen sich auf die Qualitäts- und Anforderungsattribute FURPS REFERENZEN Dokument Projektplan.docx UseCases.docx Beschreibung Allgemeine Informationen zum Projekt, sowie ergänzende Anforderungen zum Qualitätsmanagement, Codierungsrichtlinien und Infrastruktur. Beschreibung der Use Cases, vorwiegend funktionale Anforderungen. SUP Suplementary Specification.docx Datum:

48 Projekt: B2Tracking Seite: 4 von 6 3 FUNKTIONALITÄT Dieser Abschnitt beschreibt zusätzliche nichtfunktionale Anforderungen, welche für alle Use Cases gemeinsam gelten. Diese müssen dort nicht wiederholt definiert werden. 3.1 PROTOKOLLIERUNG UND FEHLERBEHANDLUNG Sämtliche Programmfehler werden im persistenten Windows Event Log gespeichert. Wichtige Vorgänge werden mit einem Zeitstempel in der Datenbank protokolliert. 3.2 SICHERHEIT Grundsätzlich sind alle Funktionen nur für autorisierte Benutzer zugänglich. Die Anmeldung erfolgt mit einem geeigneten Anmeldeverfahren für Asp.NET. Gewisse Funktionen können auch für nicht autorisierte Personen, Kunden, freigeschaltet werden. Über die gesamte Webapplikation muss sichergestellt sein, dass keine unberechtigten Zugriffe möglich sind. Die Datenbank unterliegt für dieses Projekt keinen besonderen Sicherheitsanforderungen. Für die Verwaltung der Rechte und Sicherheit ist der Kunde verantwortlich. Mitarbeiter in gleichen Rollen haben die Möglichkeit, sich die Issues/Tasks anderer Personen anzuzeigen und diese auch zu bearbeiten. Der Projektleiter darf alles bearbeiten. 3.3 RICHTIGKEIT Sämtliche Daten müssen, wie vom Benutzer eingegeben, in der Datenbank gespeichert werden. Für Auswahllisten muss stets sichergestellt sein, dass das ausgewählte Element dem Zustand der Datenbank entspricht. 4 BENUTZBARKEIT Dieser Abschnitt beschreibt Anforderungen für die Bedienung (Externe Schnittstelle) des Programms. 4.1 LOKALISIERUNG In einem ersten Schritt ist die Anwendungsoberfläche ausschliesslich in deutscher Sprache. Eine Lokalisierung ist nicht Bestandteil dieses Projektes. 4.2 ANZEIGE Um die Webapplikation vernünftig und brauchbar darzustellen, müssen alle wichtigen Komponenten der Oberfläche gut sichtbar und bedienbar sein. Da der Kunde über eine entsprechende Ausrüstung verfügt, kann die Applikation für eine Auflösung von 1280x1024 optimiert werden. Schriftgrösse, Schriftart und Farben richten sich wo möglich nach dem Standard von Windows bzw. Asp.NET 4.3 BEDIENUNG Die meisten Anwender verwenden für ein effizienteres Arbeiten zusätzlich zur Maus auch die Tastatur. Aus diesem Grund müssen folgende Punkte beachtet und eingehalten werden: SUP Suplementary Specification.docx Datum:

49 Projekt: B2Tracking Seite: 5 von 6 - Alle Elemente auf der Oberfläche sind mit dem Tabulator sinngemäss zu erreichen. - Die gesamte Benutzeroberfläche soll möglichst intuitiv bedienbar sein. Um Fehleingaben des Benutzers zu verhindern, werden alle Steuerelemente während oder nach der Eingabe validiert. Wenn möglich, sollten aufgetretene Fehler direkt korrigiert werden. Fehlerdialoge sind nach Möglichkeit zu verhindern, da diesen den Arbeitsfluss negativ beeinflussen. 4.4 BEDIENUNGSANLEITUNG Es muss eine Bedienungsanleitung erstellt werden. Diese soll möglichst klein gehalten werden und alle wichtigen, nicht offensichtlichen Funktionen und Abläufe beschreiben. Der Inhalt muss für einen Durchschnittsanwender gut verständlich sein. 5 ZUVERLÄSSIGKEIT 5.1 SPEICHERN VON DATEN Sämtliche Daten werden in einer SQL Datenbank gespeichert. 5.2 PERFORMANCE Da die Software keine zeitkritischen Funktionen beinhaltet, müssen keine speziellen Anforderungen erfüllt werden. Dennoch sollten lange Wartezeiten womöglich vermieden werden. Ansonsten sollte dem Benutzer ein entsprechender Status angezeigt werden. 6 WARTBARKEIT 6.1 FEHLERERKENNUNG / ANALYSE Grundsätzlich werden im normalen Programmbetrieb keine Vorgänge aufgezeichnet. Um eine Analyse bei einem Fehlerfall dennoch möglich zu machen, werden im Debug Modus entsprechende Ausgaben gemacht. Während dem gesamten Betrieb werden jedoch Fehlermeldungen im Windows Event Log Manager gespeichert. Siehe auch KONFIGURIERBARKEIT Für verschiedene Arten von Issues können Presets definiert werden. Diese werden in der Datenbank gespeichert. Für das Erstellen und Anpassen solcher Presets wird eine entsprechende Oberfläche bereitgestellt. 6.3 ANPASSUNGS- UND ERWEITERUNGSFÄHIGKEIT Die Webapplikation wird gemäss den Anforderungen für den internen Gebrauch entwickelt. Später soll sie als Modul für die Software B2 angepasst und integriert werden. Dies setzt voraus, dass der Aufbau der Software an die bestehende Struktur angepasst wird. Erweiterte Funktionalität, welche nur intern von Nutzen ist, kann unabhängig davon implementiert werden. SUP Suplementary Specification.docx Datum:

50 Projekt: B2Tracking Seite: 6 von 6 7 AUSLIEFERUNG Die Webapplikation wird beim Kunden auf einem produktiven Server installiert und eingerichtet. Die restlichen Projektdokumente wie Bedienungsanleitung und Projektdokumentation sind bereits in einem geschäftsinternen SVN Repository beim Kunden. Dabei wird der Kunde in das System eingeführt. 8 RECHTLICHE PROBLEME 8.1 SOFTWARE Die Entwicklungsumgebung wird von Microsoft im Rahmen des MSDNAA Programms gratis zur Verfügung gestellt. Zusätzlich verwendete Software wird vom Kunden lizenziert und bereitgestellt. 8.2 IDEENRECHT / URHEBERRECHT Die Applikation wird für den Kunden erstellt, welcher die vollumfänglichen Rechte an der Software besitzt. SUP Suplementary Specification.docx Datum:

51 Projekt: B2Tracking Seite: 1 von 3 ANSICHTEN 1 DOKUMENTINFORMATIONEN 1.1 ÜBERSICHT Dieses Dokument beschreibt die Views, welche den Benutzern zur Verfügung stehen sollen. 1.2 ÄNDERUNGSGESCHICHTE Version Datum Änderung Autor Dokument erstellt mbo Einige Anpassungen fsc VIW Ansichten.docx Datum:

52 Projekt: B2Tracking Seite: 2 von INHALT 1 Dokumentinformationen Übersicht Änderungsgeschichte Inhalt Ansichten Allgemein Projekt View Meine Issues View Änderungen View Issues View Suche View... 3 VIW Ansichten.docx Datum:

53 Projekt: B2Tracking Seite: 3 von 3 2 ANSICHTEN Dieses Kapitel beschreibt alle Ansichten, welche zur Verfügung stehen sollen. Weitere Views sind nicht Teil dieses Projektes und können wenn nötig zu einem späteren Zeitpunkt erstellt werden. 2.1 ALLGEMEIN Zu allen unten definierten Ansichten können die im DevExpress Grid zur Verfügung stehenden Filter- und Sortierfunktionen benutzt werden. 2.2 PROJEKT VIEW Zeigt eine Übersicht über das gesamte Projekt. Folgende Auflistungen werden angezeigt: - Anzahl Issues pro Version - Anzahl Issues pro Kategorie - Anzahl Issues pro Module - Anzahl Issues pro Benutzer - Anzahl Issues pro Priorität - Anzahl Issues pro Klassifikation - Anzahl Issues pro Status Die einzelnen Einträge einer Auflistung werden als Link angezeigt. Mit dem klicken auf einen Link wird die Issues Ansicht mit einem entsprechenden Filter angezeigt. 2.3 MEINE ISSUES VIEW Zeigt eine Übersicht mit offenen Issues für den aktuellen Benutzer. Beim Projektmanager werden zusätzlich folgende Informationen angezeigt: - Issues die auf eine Freigabe warten. - Issues die dem aktuellen Projektmanager zugeordnet sind. 2.4 ÄNDERUNGEN VIEW Zeigt alle Änderungen nach Version gruppiert. Die angezeigten Versionen können mit einem von, bis Version Filter festgelegt werden. 2.5 ISSUES VIEW Zeigt eine Liste mit allen Issues. Zusätzlich können benutzerdefinierte Filter gesetzt werden um die Ansicht einzuschränken. Es können auch Issues der anderen Mitarbeiter in der gleichen Rolle angezeigt werden. 2.6 SUCHE VIEW Ermöglicht dem Mitarbeiter eine Suche in ausgewählten Feldern. Das Resultat wird als Liste angezeigt. Durch Klicken auf einen Eintrag gelangt man zur Detailansicht. VIW Ansichten.docx Datum:

54 asdf

55 III Analyse

56 asdf

57 Projekt: B2Tracking Seite: 1 von 1 1 DOMÄNENMODEL Customer * 1 Preset - Name 1 1..* - Name Classification 1 hat * 1 Issue * 1..* Tag - Name * * * 1 enthält finalisiert geplant auf * Task-Type - Description - Name 1 * Task - ActualWork - AllocatedTime - Message - State beinhaltet 3 {ordered} 1 Release Version - Angabe 0..1 erstellt * * 0..1 vergeben an 1 WorkAssignee durchgeführt von während * Comments 1 1 * - Files - Text * Role User 1 * DOM Domänenmodell.docx Datum:

58 asdf

59 IV Design

60 asdf

61 Projekt: B2Tracking Seite: 1 von 12 SOFTWARE ARCHITECTURE DOCUMENT 1 DOKUMENTINFORMATIONEN 1.1 ÜBERSICHT Dieses Dokument beschreibt die Architektur der Software des Grundsystems. Entscheidungen und Alternativen des Designs sind in diesem Dokument erläutert. 1.2 ÄNDERUNGSGESCHICHTE Version Datum Änderung Autor Dokument erstellt fsc Diverse Anpassungen eingefügt mbo Handler eingefügt fsc SAD SAD.docx Datum:

62 Projekt: B2Tracking Seite: 2 von INHALT 1 Dokumentinformationen Übersicht Änderungsgeschichte Inhalt Software-Systemarchitektur Architekturübersicht Systemstruktur Physische Sicht GUI Library Logisches Zusammenspiel der Schichten und Klassen B2.Tracking.Data B2.tracking.Domain B2.Tracking.UI Architekturkonzepte Seitenaufruf Benachrichritungen State Machine Timeout-Problem Anhang Diskussion Design-Alternativen GUI-Library Designentscheidungen Datenbank Layer Upload Controls SAD SAD.docx Datum:

63 Projekt: B2Tracking Seite: 3 von 12 2 SOFTWARE-SYSTEMARCHITEKTUR 2.1 ARCHITEKTURÜBERSICHT Die Softwarearchitektur besteht hauptsächlich aus drei logischen Schichten. Diese sogenannten Haupt- Namespaces enthalten teilweise weitere Unter-Namspaces um die verschiedenen Klassen sinnvoll zusammenzufassen. class Domain Model B2.Trac king.ui B2.Tracking.Domain Handler Sta tes Notification B2.Track ing.data Abb. 1: Logische Schichten SAD SAD.docx Datum:

64 Projekt: B2Tracking Seite: 4 von SYSTEMSTRUKTUR PHYSISCHE SICHT Das B2Tracking ist eine reine Webapplikation und ist somit eine drei Tier Anwendung bestehend aus Datenbank, Webserver und dem Webbrowser (Client). Aus Performance Gründen werden die Datenbank und der Webserver auf demselben physikalischen Computer/Server betrieben GUI LIBRARY Für die Oberflächengestaltung der Applikation werden neben den Standard UI Komponenten noch erweiterte Steuerelemente verwendet. Hierfür verwenden wird eine Library von DevExpress ( Für weitere Informationen zur Evaluation siehe SAD SAD.docx Datum:

65 Projekt: B2Tracking Seite: 5 von LOGISCHES ZUSAMMENSPIEL DER SCHICHTEN UND KLASSEN Abb. 2: Zusammenspiel der Schichten SAD SAD.docx Datum:

66 Projekt: B2Tracking Seite: 6 von B2.TRACKING.DATA Dieser Namespace beinhaltet ein Abbild des Datenbank Models. Zusätzlich sind einige Klassen um nützliche Funktionen und Eigenschaften erweitert worden B2.TRACKING.DOMAIN Die Domain Logik Schicht enthält, die gesamte Kernlogik der Anwendung wie die PageHandler, StateMachine und das Notification System EXPORTKLASSEN Die Presentation Schicht greift ausschliesslich über eine entsprechende PageHanlder Klasse auf die Domain Logik zu. Grundsätzlich besteht pro Seiten Typ ein passender PageHandler. Das heisst, es existiert für Seiten mit ähnlicher Funktion ein gemeinsamer Handler oder zumindest eine gemeinsame Basisklasse DOMAIN.HANDLER Hier befinden sich alle sogenannten PageHandler, welche der Webseite die Daten zur Verfügung stellen und benötigte Domain Logik implementieren DOMAIN.NOTIFICATION Die gesamte Benachrichtigungslogik wird über den NotificationManager gesteuert. Dieser registriert die benötigten NotificationProvider, welche z.bsp. Benachrichtigungen in die Datenbank schreiben oder per versenden. Zu einem späteren Zeitpunkt können beliebige weiter NotificationProvider hinzugefügt werden DOMAIN.STATE Die Logik für die Statusbehandlung eines TaskPlans, sowie eines Tasks wird mit einer StateMachine gesteuert. Dieser Unternamespace beinhaltet die entsprechenden Klassen für die Statusverwaltung B2.TRACKING.UI Die UI Schicht enthält alle WebPages sowie deren Code Behind Dateien. SAD SAD.docx Datum:

67 Projekt: B2Tracking Seite: 7 von ARCHITEKTURKONZEPTE SEITENAUFRUF Bei einem Seitenaufruf wird jeweils die CodeBehind Klasse der entsprechenden Seite instanziiert. Zusätzlich verwenden wir für jede Seite einen PageHandler, welcher den Status der Seite speichert. Diese entsprechende Instanz wird im Session Cache gespeichert um sie nach einem PostBack wieder zu laden. Die Zugriffe auf die Daten Schicht erfolgt ausschliesslich über die PageHandler. Diese führen auch die dem UseCase entnommenen Aktionen durch. Abb. 3: Ablauf eines Seitenaufrufs SAD SAD.docx Datum:

68 Projekt: B2Tracking Seite: 8 von BENACHRICHRITUNGEN Um die Benutzer des B2Tracking zu benachrichtigen wird ein NotificationManager eingesetzt. Bei diesem können sich beliebige NotificationProvider registrieren, um bei einem Ereignis aufgerufen zu werden. So haben wir standardmässig einen Datenbank-, und einen NotificationProvider implementiert. Wird nun der NotificationManager von der StateMachine oder einen PageHandler aufgerufen, so leitet dieser diese an die registrierten Provider weiter. Der DatenankNotificationProvider schreibt die empfangenen Meldungen in die Datenbank. Diese Werden dem Benutzer auf der Messages.aspx angezeigt. Der NotificationProvider hingegegen versendet die Meldungen per . Abb. 4: Ablauf der Benachrichtigungen SAD SAD.docx Datum:

69 Projekt: B2Tracking Seite: 9 von STATE MACHINE Die StateMachine steuert die Status eines Issues und der einzelnen Tasks. Für jeden Status wird eine Status Basisklasse überschrieben und um die notwendige Logik erweitert. Die implementierte Status Logik-Klasse wird bei der entsprechenden StateMachine (TaskPlan oder Task) registriert. Hauptaufgabe der Logik in der StateMachine ist das korrekte Setzen der Stati sowie das Benachrichtigen der Mitarbeiter. Der StateManager kontrolliert die beiden State Machines und dient zugleich als Interface für den TaskPlanHandler. Um einen TaskPlan in den nächsten Status zu versetzen muss der TaskPlanHandler nur die NextState() Methode aufrufen. Diese entscheidet anschliessend, welche StateMachine aufgerufen wird. Abb. 5: Statemachine TIMEOUT-PROBLEM Die Pagehandler, welche den Ablauf einer Seite steuern, werden in der Session hinterlegt. Um den passenden Handler wiederzufinden, wird eine generierte GUID im ViewState hinterlegt. Der ViewState wird von ASP.NET selbstständig bei einem Postback wiederhergestellt. Da nun aber ein Timeout auf dem Server entstehen kann, bei dem die Referenz auf den Handler verloren geht, wurde ein spezielles Feature eingebaut. Ein unsichtbarer Timer, der alle 2 Minuten den Server mit einem Callback kontaktiert. Somit wird verhindert, dass der Benutzer, wenn er eine Seite im Browser einige Minuten unberührt lässt, die Änderungen verloren gehen. Realisiert wurde diese Technik mit der Callback-Komponenten von DevExpress. SAD SAD.docx Datum:

70 Projekt: B2Tracking Seite: 10 von 12 3 ANHANG 3.1 DISKUSSION DESIGN-ALTERNATIVEN GUI-LIBRARY Für eine ansehnliche und flexible Darstellung der B2Tracking-Webapplikation wurde eine UI-Library benötigt. Das ist eine Klassenbibliothek, welche der grafischen Darstellung dient. Da alle Projektmitglieder bereits viel Erfahrung mit der UI-Library von DevExpress haben, stand der Einsatz dieser auch beim B2Tracking zur Diskussion. Weitere Alternativen wurden während des Projektes evaluiert und genauer untersucht. Tabelle 1: Übersicht über GUI-Libraries Bibliothek Vorteile Nachteile Microsoft Standard in der.net-welt Kostenlos Alle Mitglieder kennen sie nicht besonders flexibel oft veraltetes Aussehen nur Standard-Controls wie List, Button, etc. DevExpress Telerik riesige Auswahl an Controls für jeden möglichen Zweck Aussehen über Skins definierbar moderner Look Lizenz vorhanden grosse Auswahl an ASP.NET Controls Aussehen über Skins definierbar moderner Look Gutes Grid teilweise träge Darstellung nicht allen Projektmitarbeitern bekannt Noch keine Lizenz vorhanden Noch keine Erfahrung Da die DevExpress Library vom Kunden bereits lizenziert wurde und erfolgreich eingesetzt wird, verwenden wir diese für das aktuelle Projekt. Einzelne Komponenten können auch von der Standard-Library verwendet werden, falls sie in der DevExpress Library nicht oder nicht schlechter vorhanden sind. Weiter war auch ein einheitliches Design von grosser Wichtigkeit, was am besten mit einer einzigen Library erreicht wird. 3.2 DESIGNENTSCHEIDUNGEN DATENBANK LAYER Für die Realisierung der Datenbank Zugriffsschicht standen drei mögliche Kandidaten zur Auswahl. Neben den zwei neuen Technologien von Microsoft, welche unten erwähnt werden, stand auch das bereits in anderen Projekten verwendete.net Tiers zur Diskussion. Letzteres wurde jedoch schon zu Beginn der Arbeit ausgeschlossen, da wir bereits diverse bekannte Probleme damit hatten, welche uns auch in diesem Projekt belasten würden. Zudem war es ein Teil dieses Projektes, die zwei neuen Technologien von Microsoft zu testen um einen allfälligen Wechseln in bestehenden Projekten in Betracht zu ziehen. SAD SAD.docx Datum:

71 Projekt: B2Tracking Seite: 11 von ADO.NET ENTITY FRAMEWORK Das ADO.NET Entity Framework ist war zu Beginn die interessantere Lösung, da sie auf dem sogenannten Top- Down Prinzip aufsetzt. Auf unsere Applikation bezogen heisst das, dass wir zuerst die Business Layer Objekte entwerfen und anschliessend aus diesen Informationen die Datenbank Layer Objekte, sowie die Datenbank selber generieren können. Für die Erstellung der Business Objekte ist im VS ein spezieller Designer integriert, welcher ab.net Framework 3.5 SP1 verfügbar ist. Zusätzlich zu den Objekten können auch die Beziehungen untereinander detailiert erstellt werden. Für das Mapping auf eine bestehende Datenbank steht ebenfalls ein Designer zur Verfügung, welcher die einzelnen Tabellenspalten den entsprechenden Objekt Properties zuweisen kann. Abb. 6: Klassendiagramm mit ADO.NET SAD SAD.docx Datum:

72 Projekt: B2Tracking Seite: 12 von 12 Für uns wäre jedoch eher interessant gewesen, wenn wir die Datenbank direkt aus dem Model hätten generieren können, was jedoch in der jetzigen Version noch nicht möglich ist. Wir haben jedoch auf diversen Blogs gesehen, dass dies in zukünftigen Versionen enthalten sein wird. Der Zugriff auf die Datenbankobjekte sollten sich jedoch gleich wie bim LinqToSql verhalten. Leider war aber auch dies nicht der Fall, was diese Lösung für uns unbrauchbar machte. Einfache Abfragen mit Contains() resultierten in einem Fehler, was kaum Sinn der Sache ist. Weitere Nachforschungen im Internet bestätigten unsere Probleme worauf wir uns die zweite Lösung, LinqToSql genauer anschauten LINQ TO SQL Die zweite Lösung, welche wir schon im Vorfeld ein wenig testeten war LinqToSql. Da wir mit dem ADO.NET Entity Framework auf zu viele Probleme stiessen, nahmen wir auch diese neue Technologie genauer unter die Lupe. Im gegensatz zum ADO.NET EF basiert LinqToSql auf dem Bottom Up Prinzip. Das heisst, es wird ein Objekt Model aus einem bestehenden Datenbank Schema generiert. Da wir unsere Datenbank bereits für die letzte Lösung erstellt hatten, konnten wir unser Model schnell und einfach generieren. Auch für diesen Zweck ist im VS ein Designer integriert. Durch Drag & Drop der gewünschten Tabellen auf die Designer Oberfläche werden alle nötigen Objekte generiert. Einziger Nachteil ist die fehlende Update Funktion. Bei einer Änderung des Datenbank Schemas müssen alle geänderten Klassen von Hand im Model gelöscht und neu erstellt werden. Für dieses Problem haben wir jedoch ein gutes Tool gefunden, welches den Designer um eine Update Funktion erweitert. Dieses Tool hat sich im Einsatz als sehr zuverlässig erwiesen und kann nur empfohlen werden. Auch die Probleme, welche mit den Abfragen im ADO.NET EF existierten, waren mit dem LinqToSql behoben. Somit war für uns die Entscheidung gefallen und wir haben uns für LinqToSql entschieden UPLOAD CONTROLS Die Benutzer haben die Möglichkeit zu den einzelnen Issues beliebige Dateien hochzuladen. Für diesen Zweck haben wir diverse ASP.NET Upload Controls getestet. Folgende Tabelle fasst die Testresultate fest: Tabelle 2: Übersicht über Upload Controls Name Beschreibung / Problem Microsoft Library - Einfaches Upload-Feld - Keine Status-Anzeige - Nur eine Datei auswählbar Krystalware SlickUpload - Multifunktional mit Status-Anzeige, dynamischer Feldanzahl etc. - Verwendung sehr problematisch in UploadPanels (obwohl dieses korrekt konfiguriert wurde) - Lizenz benötigt Ajax Uploader - Status-Anzeige und alle sonst benötigten Features - Unschönes Design - Lizenz benötigt DevExpress ASPxUpload - Seit der neusten Version (DEZ 08) mit mehreren Upload-Feldern - Läuft problemlos in einem Updatepanel - Keine Status-Anzeige - Lizenz vorhanden Da wir sowieso eine Lizenz für die DevExpress Controls besitzen, haben wir uns für dieses entschieden. Für eine der nächsten Versionen hat DevExpress eine Status-Anzeige angekündigt. SAD SAD.docx Datum:

73 V Tests

74 asdf

75 Projekt: B2Tracking Seite: 1 von 13 TESTS 1 DOKUMENTINFORMATIONEN 1.1 ÜBERSICHT Dieses Dokument enthält die Tests für die Beta- sowie die Release Version. 1.2 ÄNDERUNGSGESCHICHTE Version Datum Änderung Autor Dokument erstellt, Alle Excel Testresultate zusammengefasst mbo 1.3 INHALT 1 Dokumentinformationen Übersicht Änderungsgeschichte Inhalt Testumgebung Test Beta Test Input File UC1: Issue Anlegen UC2: Issue Anlegen UC3: Task Durchführen UC4: Release Erstellen Release Test Input File UC1: Issue Anlegen UC2: Issue Anlegen UC3: Task Durchführen UC4: Release Erstellen UCT Tests.docx Datum:

76 Projekt: B2Tracking Seite: 2 von 13 2 TESTUMGEBUNG Server Typ IBM Server Betriebssystem Windows 2003 R2 Webserver IIS6 Datenbank MSSSQL Server 2005.NET Framework 3.5 Service Pack 1 Client Typ HP Notebook Betriebssystem Windows XP Service Pack 3 Browser Internet Explorer 7 3 TEST 3.1 BETA TEST Informationen Datum Test Person Florian Schwendener SVN Revision 384 UCT Tests.docx Datum:

77 Projekt: B2Tracking Seite: 3 von INPUT FILE UCT Tests.docx Datum:

78 Projekt: B2Tracking Seite: 4 von UC1: ISSUE ANLEGEN Schritt Beschreibung Ergebnis Erfüllt 1 Neuen Issue erstellen auswählen Seite mit allen nötigen Eingaben angezeigt OK 1a Problem bereits erfasst --> Issue öffnen Issue wird angezeigt OK 2 Eingabe der Daten 2a Benötigte Felder nicht ausgefüllt Meldung; Felder werden erzwungen Nein 3 Issue speichern Daten werden gespeichert, Umleitung auf View OK 4 Projektleiter informieren - Projektleiter erhält eine Benachrichtigung - Issue taucht unter 'Alle Issues' und 'Meine Issues' auf, Aufgabe lautet 'Issue bearbeiten / starten' OK Notizen Schritt Notiz Massnahme Erfüllt 2 siehe Input File 4 Issue abschliessen' ist möglich, ohne den Issue angenommen zu haben Bugfix OK 2a Meldung erscheint nicht bei Tags & Beschreibung Fixen OK UCT Tests.docx Datum:

79 Projekt: B2Tracking Seite: 5 von UC2: ISSUE ANLEGEN Schritt Beschreibung Ergebnis Erfüllt 1 Neuen Issue erstellen auswählen Seite mit allen nötigen Eingaben angezeigt OK 1a Problem bereits erfasst --> Issue öffnen Issue wird angezeigt OK 2 Eingabe der Daten 2a Benötigte Felder nicht ausgefüllt Meldung; Felder werden erzwungen OK 2b 3 Issue speichern Daten werden gespeichert, Umleitung auf View OK 4 Projektleiter informieren - Projektleiter erhält eine Benachrichtigung - Issue taucht unter 'Alle Issues' und 'Meine Issues' auf, Aufgabe lautet 'Issue bearbeiten / starten' OK Notizen Schritt Notiz Massnahme Erfüllt 2 siehe Input File UCT Tests.docx Datum:

80 Projekt: B2Tracking Seite: 6 von UC3: TASK DURCHFÜHREN Schritt Beschreibung Ergebnis Erfüllt 1 Issue auswählen Issue wird angezeigt. OK 1a Task gehört noch niemanden. Task annehmen Der Task wurde mir zugeteilt und kann von niemand anderem mehr OK angenommen werden. 2 Eingetragene Arbeit erledigen Arbeiten des aktuellen Tasks werden erledigt. OK 3 Abschliessende Informationen (Kommentar erfassen, Dateien anhängen) eintragen. Kommentare und erstellte Dateien wurden angehängt. 4 Task abschliessen Status des Tasks ist auf "Warte auf Abschluss". Der Projektleiter wurde informiert. 5 Der Projektleiter schliesst den Task ab. Status des Tasks ist auf "Abgeschlossen". Der nächste Task, sofern vorhanden, wurde auf "Warte auf Freigabe" gesetzt. Notizen Schritt Notiz Massnahme Erfüllt 3 Kommentar geschrieben und zwei Dateien angehängt. OK OK OK UCT Tests.docx Datum:

81 Projekt: B2Tracking Seite: 7 von UC4: RELEASE ERSTELLEN Schritt Beschreibung Ergebnis Erfüllt 1 Version im Issues.aspx auswählen und Release erstellen Neues Release für die ausgewählte Version wird angezeigt. Alle in dieser Version OK anklicken vorhandenen Issues werden beim klicken auf Speichern geschlossen. Ein Standard TaskPlan für ein Release wurde eingetragen. 1a Mindestens ein Issue hat noch aktive Tasks und kann nicht Meldung wird ausgegeben, dass das Release nicht erstellt werden konnte, weil es Nein geschlossen werden. noch offene Issues hat. Projektleiter starten den Release Task Plan Status wurde auf In Bearbeitung gesetzt. Erster Task wurde gestartet. Nein 2 TaskPlan gemäss Task Durchführen erledigen. Alle Tasks sind am schluss auf abgeschlossen. Nein 3 Projektleiter schliesst Release Task Plan ab. Status wurde auf Abgeschlossen gesetzt. Nein Notizen Schritt Notiz Massnahme Erfüllt 1 Speichern des Releases noch nicht möglich. Somit sind alle weiteren Schritte noch nicht machbar. UCT Tests.docx Datum:

82 Projekt: B2Tracking Seite: 8 von RELEASE TEST Informationen Datum Test Person Michael Bolliger SVN Revision 451 UCT Tests.docx Datum:

83 Projekt: B2Tracking Seite: 9 von INPUT FILE UCT Tests.docx Datum:

84 Projekt: B2Tracking Seite: 10 von UC1: ISSUE ANLEGEN Schritt Beschreibung Ergebnis Erfüllt 1 Neuen Issue erstellen auswählen Seite mit allen nötigen Eingaben angezeigt OK 1a Problem bereits erfasst --> Issue öffnen Issue wird angezeigt OK 2 Eingabe der Daten 2a Benötigte Felder nicht ausgefüllt Meldung; Felder werden erzwungen OK 3 Issue speichern Daten werden gespeichert, Umleitung auf View OK 4 Projektleiter informieren - Projektleiter erhält eine Benachrichtigung - Issue taucht unter 'Alle Issues' und 'Meine Issues' auf, Aufgabe lautet 'Issue bearbeiten / starten' OK Notizen Schritt Notiz Massnahme Erfüllt 2 siehe Input File UCT Tests.docx Datum:

85 Projekt: B2Tracking Seite: 11 von UC2: ISSUE ANLEGEN Schritt Beschreibung Ergebnis Erfüllt 1 Neuen Issue erstellen auswählen Seite mit allen nötigen Eingaben angezeigt OK 1a Problem bereits erfasst --> Issue öffnen Issue wird angezeigt OK 2 Eingabe der Daten 2a Benötigte Felder nicht ausgefüllt Meldung; Felder werden erzwungen OK 2b 3 Issue speichern Daten werden gespeichert, Umleitung auf View OK 4 Projektleiter informieren - Projektleiter erhält eine Benachrichtigung - Issue taucht unter 'Alle Issues' und 'Meine Issues' auf, Aufgabe lautet 'Issue bearbeiten / starten' OK Notizen Schritt Notiz Massnahme Erfüllt 2 siehe Input File UCT Tests.docx Datum:

86 Projekt: B2Tracking Seite: 12 von UC3: TASK DURCHFÜHREN Schritt Beschreibung Ergebnis Erfüllt 1 Issue auswählen Issue wird angezeigt. OK 1a Task gehört noch niemanden. Task annehmen Der Task wurde mir zugeteilt und kann von niemand anderem mehr OK angenommen werden. 2 Eingetragene Arbeit erledigen Arbeiten des aktuellen Tasks werden erledigt. OK 3 Abschliessende Informationen (Kommentar erfassen, Dateien anhängen) eintragen. Kommentare und erstellte Dateien wurden angehängt. 4 Task abschliessen Status des Tasks ist auf "Warte auf Abschluss". Der Projektleiter wurde informiert. 5 Der Projektleiter schliesst den Task ab. Status des Tasks ist auf "Abgeschlossen". Der nächste Task, sofern vorhanden, wurde auf "Warte auf Freigabe" gesetzt. Notizen Schritt Notiz Massnahme Erfüllt Alles OK OK OK OK UCT Tests.docx Datum:

87 Projekt: B2Tracking Seite: 13 von UC4: RELEASE ERSTELLEN Schritt Beschreibung Ergebnis Erfüllt 1 Version im Issues.aspx auswählen und Release erstellen Neues Release für die ausgewählte Version wird angezeigt. Alle in dieser Version OK anklicken vorhandenen Issues werden beim klicken auf Speichern geschlossen. Ein Standard TaskPlan für ein Release wurde eingetragen. 1a Mindestens ein Issue hat noch aktive Tasks und kann nicht geschlossen werden. Meldung wird ausgegeben, dass das Release nicht erstellt werden konnte, weil es noch offene Issues hat. OK, Notiz! Projektleiter starten den Release Task Plan Status wurde auf In Bearbeitung gesetzt. Erster Task wurde gestartet. OK 2 TaskPlan gemäss Task Durchführen erledigen. Alle Tasks sind am schluss auf abgeschlossen. OK 3 Projektleiter schliesst Release Task Plan ab. Status wurde auf Abgeschlossen gesetzt. OK Notizen Schritt Notiz Massnahme Erfüllt 1a Statt einer Meldung wird der Benutzer wieder auf Issues.aspx umgeleitet. Verhalten OK. Meldungen werden in einem allfälligen Service Release eingeführt. UCT Tests.docx Datum:

88 asdf

89 VI Zeiterfassung

90 asdf

91 Seite 1 von 3 Arbeitspakete 1 Dokumentinformationen 1.1 Übersicht Dieses Dokument beschreibt detailliert das Projekt B2Tracking. Es enthält die Planung des Projektes mit Meilensteinen und die Aufteilung der Arbeit in Arbeitspakete. 1.2 Änderungsgeschichte Version Datum Änderung Autor Dokument erstellt fsc Ergänzungen angebracht mbo ARP Arbeitspakete.xlsx Datum:

92 Seite 2 von 3 Arbeitspaket Soll [h] Ist [h] Differenz [h] Dokumentation Software Architektur Dokument Bedienungsanleitung Gesamtdokumentation Templates Projektmanagement Risikoanalyse Projektplan Zeitplan Konfigurationsmanagement Meetings Analyse Ausarbeitung mit Kunde Use Cases Suplementary Specifications Externes Design Domänenmodel Design Klassendiagramm Logische Architektur UI Architektur Architektur Prototyp Implementation Versionen Verwalten Issues Anzeigen Issue Editieren Releases Anzeigen Releases Editieren Administration Startseite Messages Tasks Kundenanbindung Datenbank Layer Testen Usability Test Use Case Test Code Review Auslieferung Einfühung Kunde Präsentation Total 480h verfügbar, davon 60h Reserve ARP Arbeitspakete.xlsx Datum:

93 Seite 3 von 3 Auswertung Die Arbeit konnte unter Einhaltung der Gesamtzeit durchgeführt werden, wobei es bei den einzelnen Arbeitspaketen teilweise grössere Abweichungen gab. - Das Arbeitspaket Meetings weist eine Differenz von -42.5h auf, was wie folgt zu begründen ist. Da wir uns meist während dem gemeinsamen Arbeiten über wichtige Punkte unterhielten, fliesst die Zeit, welche für "Meeting Team" abzubuchen gewesen wäre, direkt in die Implementation. Dies auch ein Grund für die massive Differenz (+79h) in diesem Bereich. - Für die Implementation wurde zudem ein Teil der Reserve in Anspruch genommen. Ansonsten sind wir mit der Planung der Arbeitspakete sehr zu frieden, was uns auch das Resultat bestätigt. ARP Arbeitspakete.xlsx Datum:

94 asdf

95 ID Task Name Duration Work Actual Work 1 Projekt SA08 96 days 480 hrs 0 hrs 2 Reserve 96 days 60 hrs 0 hrs 3 4 Dokumentation 96 days 28 hrs 0 hrs 5 Dokumente überarbeiten 96 days 20 hrs 0 hrs 6 Iteration Planung 96 days 6 hrs 0 hrs 7 Rapportierung 96 days 2 hrs 0 hrs 8 9 Meetings 96 days 59 hrs 0 hrs 10 Meetings mit Betreuer 96 days 10 hrs 0 hrs 11 Meetings mit Kunden 96 days 16 hrs 0 hrs 12 Meetings Team 48 days 28 hrs 0 hrs 13 Mettingprotokolle 48 days 5 hrs 0 hrs Anforderungen 14 days 13 hrs 0 hrs 16 Ausarbeitung mit Kunde 14 days 8 hrs 0 hrs 17 Use Cases 14 days 4 hrs 0 hrs 18 Suplementary Specifications 14 days 1 hr 0 hrs Projektmanagement 14 days 7 hrs 0 hrs 21 Projektplan 14 days 2 hrs 0 hrs 22 Risikoanalyse 14 days 2 hrs 0 hrs 23 Planung 14 days 2 hrs 0 hrs 24 Konfigurationsmanagement 14 days 1 hr 0 hrs Analyse 7 days 32 hrs 0 hrs 27 Domänenmodell 7 days 6 hrs 0 hrs 28 Systemoperationen 7 days 4 hrs 0 hrs 29 Systemsequenzdiagramme 7 days 4 hrs 0 hrs 30 Externes Design 7 days 2 hrs 0 hrs 31 Software Architektur 7 days 2 hrs 0 hrs 32 Architektur Prototyp 7 days 14 hrs 0 hrs Design 14 days 41 hrs 0 hrs 35 Logische Architekur 7 days 6 hrs 0 hrs 36 Klassendiagramm 14 days 3 hrs 0 hrs 37 UI Architektur 14 days 3 hrs 0 hrs 38 Software Architektur Dokument 7 days 12 hrs 0 hrs 39 Architektur Prototyp 7 days 17 hrs 0 hrs Realisierung 28 days 122 hrs 0 hrs 42 Datenbank 28 days 4 hrs 0 hrs 43 Logik 28 days 40 hrs 0 hrs 44 UI 28 days 40 hrs 0 hrs 45 Technische Dokumentation 14 days 12 hrs 0 hrs 46 Code Review 14 days 8 hrs 0 hrs 47 Testen / Unit Test 14 days 18 hrs 0 hrs Testen 14 days 32 hrs 0 hrs 50 System 14 days 16 hrs 0 hrs 51 Usability 14 days 16 hrs 0 hrs Abschluss / Auslieferung 19 days 86 hrs 0 hrs 54 Bedienungsanleitung 19 days 8 hrs 0 hrs 55 Einführung Kunde 19 days 70 hrs 0 hrs 56 Abschlusspräsentation 19 days 8 hrs 0 hrs Seite 1 von 1 r 2008 October 2008 November 2008 December 2008 January Florian Schwendener[0.04];Michael Bolliger[0.1] Florian Schwendener[0.02];Michael Bolliger[0.01] Michael Bolliger[0.01] Florian Schwendener[0.02] Michael Bolliger[0.02] Michael Bolliger[0.02] Michael Bolliger[0.01] Michael Bolliger[0.05];Florian Schwendener[0.05] Michael Bolliger[0.04];Florian Schwendener[0.04] Michael Bolliger[0.04];Florian Schwendener[0.04] Florian Schwendener[0.04] Michael Bolliger[0.04] Michael Bolliger[0.13];Florian Schwendener[0.13] Michael Bolliger[0.05];Florian Schwendener[0.05] Michael Bolliger[0.03] Florian Schwendener[0.03] Michael Bolliger[0.11];Florian Schwendener[0.11] Michael Bolliger[0.15];Florian Schwendener[0.15] Michael Bolliger[0.04];Florian Schwendener[0.04] Michael Bolliger[0.01];Florian Schwendener[0.01] Michael Bolliger[0.02] Michael Bolliger[0.18] Florian Schwendener[0.18] Michael Bolliger[0.05];Florian Schwendener[0.05] Michael Bolliger[0.04];Florian Schwendener[0.04] Michael Bolliger[0.08];Florian Schwendener[0.08] Michael Bolliger[0.04];Florian Schwende Florian Schwendener[0.01];Michael Bolli Florian Schwendener[0];Michael Bollige Michael Bolliger[0];Florian Schwendene Michael Bolliger[0.07];Florian Schwendener[0.07] Michael Bolliger[0.07];Florian Schwendener[0.07] Michael Bolliger[0.13];Florian Schwende Florian Schwendener[0.5];Michael Bollig Michael Bolliger[0.03];Florian Schwende Michael Bolliger[0.23];Florian Schwende Michael Bolliger[0.03];Florian Schwende Project: Zeitplan Date: Sun Task Split Progress Milestone Summary Project Summary External Tasks External Milestone Deadline ZPS Zeitplan Soll.mpp Datum:

96 asdf

97 ID Task Name Duration Actual Work Start 1 Projekt SA days 427 hrs Mon Reserve days 0 hrs Mon Dokumentation 101 days 38 hrs Mon Dokumente überarbeiten 18 days 38 hrs Tue Iteration Planung days 0 hrs Mon Rapportierung days 0 hrs Mon Meetings days 32 hrs Mon Meetings mit Betreuer 4.25 days 10 hrs Mon Meetings mit Kunden days 10 hrs Mon Meetings Team days 12 hrs Mon Mettingprotokolle 96 days 0 hrs Mon Meilensteine 86 days 0 hrs Wed M1 - Anforderungen / Zeitplan 0 days 0 hrs Wed M2 - Architektur Prototyp 0 days 0 hrs Wed M3 - Design 0 days 0 hrs Mon M4 - Beta Version 0 days 0 hrs Mon M5 - Release Version 0 days 0 hrs Wed M6 - Projekt abgeschlossen 0 days 0 hrs Fri Anforderungen 10 days 14 hrs Mon Ausarbeitung mit Kunde 1 day 8 hrs Mon Use Cases 1 day 4 hrs Wed Suplementary Specifications 2 days 2 hrs Sun Projektmanagement 10.5 days 13.5 hrs Wed Projektplan 2 days 3 hrs Wed Risikoanalyse 2.5 days 1.5 hrs Mon Planung 3 days 7 hrs Wed Konfigurationsmanagement 1 day 2 hrs Wed Analyse 54 days 13.5 hrs Fri Domänenmodell 3 days 6 hrs Fri Systemoperationen 15 days 0 hrs Thu Systemsequenzdiagramme 14 days 3 hrs Wed Externes Design 2 days 4.5 hrs Thu Design 36 days 34 hrs Tue Logische Architekur 5.67 days 12.5 hrs Thu UI Architektur 6.33 days 5.5 hrs Wed Klassendiagramm 6.38 days 7.5 hrs Tue Software Architektur Dokument 2.25 days 8.5 hrs Tue Implementierung 83 days 199 hrs Wed Datenbank 28 days 13 hrs Wed Logik days 59 hrs Wed UI 41 days hrs Sun Code Review 15 days 11.5 hrs Sun Bugfixing 22 days 11 hrs Sun Testen 75 days 19 hrs Wed Fortlaufende Tests 63 days 0 hrs Wed System 21 days 11 hrs Mon Usability 14 days 8 hrs Mon Abschluss / Auslieferung days 64 hrs Mon Bedienungsanleitung 7 days 8 hrs Mon Einführung Kunde days 50 hrs Mon Abschlusspräsentation 9.5 days 6 hrs Mon Florian Schwendener[0.5];Michael Bolliger[0.5] Florian Schwendener[0.5] Michael Bolliger[0.13] Florian Schwendener[0.25] Michael Bolliger[0.13] Michael Bolliger[0.38] Michael Bolliger[0.25] Seite1 von 1 ber 2008 October 2008 November 2008 December 2008 January 2009 February 2009 March Michael Bolliger[0.25];Florian Schwendener[0.25] Michael Bolliger[0.02];Florian Schwendener[0.02] Michael Bolliger[0.38];Florian Schwendener[0.02] Florian Schwendener[0.31] Michael Bolliger[0.25];Florian Schwendener[0.63] Florian Schwendener[0.31] Michael Bolliger[0.31] Michael Bolliger[1.06];Florian Schwendener[0.5] Michael Bolliger[0.04];Florian Schwendener[0.04] Florian Schwendener[0.25];Michael Bolliger[0.19] Florian Schwendener[0];Michael Bolliger[0] Michael Bolliger[0];Florian Schwendener[0] Michael Bolliger[0.17];Florian Schwendener[0.17] Florian Schwendener[0.25];Michael Bolliger[0.25] Michael Bolliger[0.25];Florian Schwend Michael Bolliger[0];Florian Schwendener[0] Michael Bolliger[0.31] Michael Bolliger[1.06] Florian Schwendener[1.13] Michael Bolliger[0.44];Florian Schwendener[0.14] Florian Schwendener[0.07];Michael Bolliger[0.25] Florian Schwendener[0.02];Michael Bolliger[0.02] Michael Bolliger[0.09];Florian Schwendener[0.04] Michael Bolliger[0.14];Florian Schwendener[0.04] Michael Bolliger[0.29];Florian Schwendener[0.14] Michael Bolliger[0.18];Florian Schwendener[0.23] Michael Bolliger[0.1];Florian Schwendener[0.07] Project: Zeitplan Date: Wed Task Split Progress Milestone Summary Project Summary External Tasks External Milestone Deadline ZPI Zeitplan Ist.mpp Datum:

98 asdf

99 VII Handbuch

100 asdf

101 2008 Heiniger & Partner AG Florian Schwendener Michael Bolliger [B2TRACKING] Das Issue-Tracking System, speziell entwickelt für den Support von B2.

102 Projekt: B2Tracking Seite: 2 von 11 Inhalt 1 Einführung Beschreibung Startseite Issues Einführung Ablauf Issue anlegen Einen Issue anzeigen Übersicht über die Issues Issue bearbeiten Tasks Einführung Projektleiter: Steuerung des Ablaufs Annehmen eines Tasks Durchführung eines Tasks Referenz Aktionen Symbole in der Tasks-Liste Issue-Status Task-Status Releases Einführung Erstellen / Bearbeiten Ablauf HBM Handbuch2.docx Datum:

103 Projekt: B2Tracking Seite: 3 von 11 1 Einführung 1.1 Beschreibung Um in der Heiniger & Partner AG Probleme mit B2 zu erfassen wurde dieses Issue-System erstellt. Mithilfe von B2Tracking werden alle eingehenden Probleme, Anforderungen und Verbesserungswünsche erfasst und der Ablauf der Problemlösung koordiniert. 1.2 Startseite Nach dem Anmelden beim System erscheint die Startseite. Darauf sind alle offenen Aufgaben für den jeweiligen Benutzer zu sehen. Mehr dazu später. Ausserdem ist am rechten Bildschirmrand eine Übersicht über die momentan vorhandenen Issues zu sehen. HBM Handbuch2.docx Datum:

104 Projekt: B2Tracking Seite: 4 von 11 2 Issues 2.1 Einführung Unter einem Issue werden sowohl eingehende Probleme von Kunden mit dem B2 als auch neue Anforderungen und Verbesserungswünsche verstanden. Ein Issue enthält Informationen Problem wie ein Titel und eine Beschreibung aber auch weiterreichende Felder wie Informationen zur Softwareversion des Kunden und eine Priorität. Issues werden durch Stichworte klassifiziert und sind somit jederzeit schnell auffindbar. Wird nun ein Issue durch den Support angelegt, wird dessen Ablauf durch einen Projektleiter gesteuert. Dabei legt dieser eine Sammlung von Aufgaben an, die eine reibungslose Durchführung des Issues versichern. Diese Aufgaben werden Tasks genannt. Ein Task wird einem Mitarbeiter zugeordnet und enthält einen Arbeitsauftrag. Mehr dazu ist im Kapitel Tasks zu finden. 2.2 Ablauf Nachdem ein Issue von einem Supporter angelegt wurde, muss er von einem Projektleiter übernommen werden. Danach kann dieser den Issue planen, in dem er eine Liste von Tasks einfügt. Diese werden Personen oder Gruppen zugewiesen. Sobald nun die Ausführung eines Tasks ansteht, muss dieser angenommen werden durch einen Mitarbeiter, sofern er einer Gruppe zugewiesen wurde. Ansonsten erhält er direkt eine Meldung über die Aufgabe. In beiden Fällen ist eine zu erledigende Aufgabe auf der Startseite zu sehen. Dabei durchläuft ein Issue die folgenden Stati: - Neu Der Issue wurde angelegt und wurde noch nicht gestartet. - Aktiv Der Ablauf wurde gestartet. - Abgeschlossen Alle Tasks im Issue wurden erfolgreich abgeschlossen. Die Zustände, in denen die Tasks selbst sein können, werden im Kapitel Tasks beschrieben. Ebenfalls die Steuerung des Ablaufs. HBM Handbuch2.docx Datum:

105 Projekt: B2Tracking Seite: 5 von Issue anlegen Um einen neuen Issue zu erstellen, müssen Sie den Menüpunkt Issue erstellen anwählen. Danach erscheint eine Eingabemaske, welche im Folgenden beschrieben wird. Die Felder Titel, Priorität, Stichworte und Beschreibung sind auszufüllen. Darunter steht eine Dateiauswahl zur Verfügung, wobei durch einen Klick auf Hinzufügen zusätzliche Dateien angehängt werden können. Am rechten Bildschirmrand befindet sich die Kundenauswahl. Soll ein neuer Kunde hinzufügt werden, muss zuerst die Firma auswählt werden. Danach kann ein Sachbearbeiter gewählt werden, der bei etwaigen Rückmeldungen benachrichtigt werden soll. Zusätzlich sollte die B2-Version und das Kundenbetriebssystem festgelegt werden. Nach dem Klick auf Speichern wird die Ansichtsseite angezeigt. HBM Handbuch2.docx Datum:

106 Projekt: B2Tracking Seite: 6 von Einen Issue anzeigen Diese Seite zeigt alle Informationen zu einem Issue an. Jeder Benutzer kann Kommentare hinterlassen und Dateien hochladen. Unter Tasks sehen Sie die einzelnen Schritte, welche der Issue durchläuft. Abgeschlossene Schritte erscheinen ausgegraut, zudem gibt die Spalte Status mehr Auskunft. Jeder Schritt kann offengeklappt werden, um mehr Informationen über ihn zu erhalten. Nun unterscheidet sich die Anzeige dieser wichtigen Seite je nach Rolle, in der Sie sich befinden. Jeder darf einen Kommentar hinterlassen und Dateien hochzuladen. Klicken Sie dazu auf Kommentar hinzufügen im Aktionen-Panel. Die weiteren Schritte hängen von der Rolle ab, in der Sie sich befinden. Einen Issue bearbeiten können Sie aber sowohl als Projektleiter als auch als Supporter. Auf die Tasks, welche auf dieser Seite eine wichtige Rolle spielen, wird im Kapitel Tasks eingegangen. HBM Handbuch2.docx Datum:

107 Projekt: B2Tracking Seite: 7 von Übersicht über die Issues Um alle Issues anzuzeigen, wählen Sie den Menüpunkt Issues. Dabei haben Sie noch die Wahl zwischen Alle Issues und Meine Issues. Unter letzterem werden nur die Issues angezeigt, welche entweder von Ihnen erstellt, von Ihnen übernommen oder Tasks enthalten, welche Ihnen zugewiesen sind. Am linken Bildschirmrand haben Sie die Möglichkeit, die Issues nach den Kriterien B2-Version, Priorität oder Status zu filtern. Rechts kann nach Stichworten gesucht werden. Dabei haben Sie die Auswahl zwischen einer UND- und einer ODER-Verknüpfung. Verknüpfung ODER UND Auswirkung Es werden alle Issues angezeigt, welche mindestens einem der ausgewählten Stichworte zugewiesen sind. Angezeigt werden nur die Issues, welche jedem ausgewählten Stichwort zugewiesen sind. Daüber hinaus ist es möglich, über die Spaltenköpfe die Issues zu filtern. Dabei entspricht der Stern (*) oder das Prozent-Zeichen (%) einer Wildcard. Beispiel: %Problem% liefert alle Issues, welche im Titel das Wort Problem tragen. HBM Handbuch2.docx Datum:

108 Projekt: B2Tracking Seite: 8 von Issue bearbeiten Support-Mitarbeiter und Projektleiter dürfen einen Issue bearbeiten. Dabei ist der Supporter jedoch eingeschränkt. So darf er keine Tasks einfügen, verschieben oder löschen. Am rechten Rand können bestehende Dateien gelöscht oder neue Dateien hinzugefügt werden. Darunter befindet sich die Verwaltung der Kunden, welche von diesem Issue betroffen sind. Die Bearbeitung er übrigen Felder erklärt sich von selbst. Die Schritte, die der Issue durchläuft, werden unter Tasks dargestellt. Dabei werden bereits aktive oder abgeschlossene Tasks schreibgeschützt dargestellt. Um einen Task oder ein ganzes Task-Paket einzufügen, wählen Sie einen Eintrag im Dropdown-Menü rechts unten aus. Sie können auch einen neuen Namen für einen Task eingeben. Nach dem Einfügen erscheinen die Tasks in der Liste. Dabei können der Empfänger, ein Zieldatum und eine Beschreibung eingegeben werden. Um die Reihenfolge zu verändern, klicken Sie einen Task an und benützen die Pfeile links unten. Sie verschieben den ausgewählten Task nach oben bzw. unten. Um die Bearbeitung abzuschliessen, wählen Sie Speichern. Mit einem Klick auf Abbrechen werden alle Änderungen verworfen. In beiden Fällen werden Sie auf die Ansicht des Issues umgeleitet. HBM Handbuch2.docx Datum: