Projektantrag bewerten: Automatisiertes End-to-End-Monitoring

[kne217]

Hallo zusammen, bis zum 15. August muss ich meinen Projektantrag für die Winterprüfung einreichen.

Hier meine erste Fassung zur Bewertung bitte:

2.1 Kurzbeschreibung

Um den von der *Unternehmen* betriebsgeführten Web-Anwendungen zusätzlich zur bereits vorhandenen technischen Komponentenüberwachung ein fachliches Monitoring hinzuzufügen, gilt es, ein geeignetes Produkt auszuwählen, die nötigen Komponenten zu installieren und in die bereits vorhandene Infrastruktur und Monitoring-Systeme zu integrieren.

2.2 Ist-Analyse

Derzeit bietet die *Unternehmen* bereits End-to-End-Monitoring-Lösungen mit Topas an. Diese sind den meisten Kunden jedoch zu kostenintensiv und schwer zugänglich. Eigenentwicklungen gestalten sich schwierig und das notwendige Know-How ist kaum vorhanden. Dadurch verzichten die allermeisten Kundenverfahren auf diese Leistung. Daraus ergeben sich mitunter Prozessstö-rungen, die ich im weiteren Verlauf beschreiben werde.

Das neue End-to-End-Monitoring soll im Endzustand automatisiert stattfinden. Das soll den Zweck ha-ben, Anwendungsfehler entdecken zu können, bevor Anwender darauf stoßen und deren Arbeits-fluss dadurch gestört wird.

Derzeit gibt es nur sehr kostenintensive und komplexe Lösungen für End-to-End-Monitoring im Portfolio der *Unternehmen*. Das soll sich mit der Realisierung dieses Projekts ändern und eine kostengünstige Alternative soll geschaffen werden.

Die bisherigen Monitoring-Systeme melden lediglich Störungen der zu Grunde liegenden Platt-form, treffen jedoch keine Aussage über die tatsächliche momentane Funktionalität der laufenden Anwendung.

2.3 Soll-Konzept

Ziel der Durchführung des Projektes ist es, das gewählte End-to-End-Monitoring-System in die vorhandene Monitoring-Infrastruktur zu integrieren. Hierbei soll eine echte Simulation von An-wenderverhalten entstehen, um Rückschlüsse auf die tatsächliche Funktionalität der Web-Anwendung ziehen zu können.

Hintergrund dieser Anforderung ist die Tatsache, dass in der Vergangenheit sporadisch Ausfälle von Applikationen nicht rechtzeitig erkannt wurden, da alle darunter liegenden Komponenten ord-nungsgemäß arbeiteten. Somit wurden die Ausfälle nur von den Anwendern der Applikation be-merkt und es kam zu einer Störungsmeldung. In Zukunft soll dem Kunden eine kostengünstige Möglichkeit geboten werden, derartige Störungen frühzeitig erkennen zu können.

Die Kriterien für die Auswahl des Produktes belaufen sich auf folgende Schwerpunkte:

• Kosten

• Stabilität

• Regelmäßigkeit der Softwarepflege

• Flexibilität

Das System soll eine grafische Benutzeroberfläche bieten, um Zugang ohne Betriebssystemspe-zifische Kenntnisse zu ermöglichen. Um die Einstiegshürden möglichst gering zu halten, muss die Entwicklung eigener Testfälle auf dem Anwender-Client der Benutzer stattfinden können, woraus sich ergibt, dass es sich um eine Windows-Umgebung handeln muss. Diese Eigen-entwicklungen werden dann von der Monitoring-Betriebsführung abgenommen und ins produktive Monitoring-System eingespielt.

Ein virtueller Windows-Server 2008 bietet die optimale Plattform zur Umsetzung dieses Vorha-bens, da er stellvertretend für Benutzer-Clients automatisiert diese Testfälle unter der Vorausset-zung der grafischen Oberfläche abarbeiten kann.

Diese virtuelle Plattform wird zum Zeitpunkt der Projektdurchführung bereits vorhanden sein und muss nicht mehr bereitgestellt werden. Dadurch geht keine Zeit zur Betriebssystemeinrichtung verloren und es steht mehr Zeit für die Durchführung zur Verfügung.

Hauptteil der Projektdokumentation soll ein Benutzerleitfaden zur Installation und Handhabung des Systems, sowie zur Entwicklung und zum Einsatz eigens erstellter Testfälle im produktiven Einsatz entstehen. Dieser soll möglichst einfach gehalten und leicht verständlich sein, um auch Anwendern ohne Programmiererfahrung die Entwicklung eigener Tests zu ermöglichen.

Die Hauptaufgaben in der Durchführung des Projekts bestehen aus:

• Planung und Vorbereitung der Durchführung

o Vergleich verfügbarer Softwarekomponenten nach o.g. Kriterien

o Festlegung auf ein Produkt, Begründung der Entscheidung

o Erstellung eines Projektstrukturplans

• Installation und Inbetriebnahme der Softwarekomponente

o Installation der Serverkomponente

o Lokale Installation der Entwicklungskomponente

o Anbindung an vorhandene Komponentenüberwachung über geeignete Schnittstellen

• Dokumentation für Installation, Bedienung und Erstellung von Eigenentwicklungen

• Erstellung der Projektdokumentation

2.4 Projektphasen und Zeitplanung

Die nachstehende Tabelle gibt Aufschluss über die Zeitplanung der Projektdurchführung. Laut Antragshinweisen soll die Projektdauer 35 Stunden nicht überschreiten, darf diesen Zeitraum je-doch nicht um mehr als 1/3 unterschreiten.

Tätigkeit Planungsphase Zeit in h

Ist-Analyse 1

Recherchieren verfügbarer Softwarekomponenten 1,5

Evaluieren der Softwarekomponenten 1,5

Erstellung Projektstrukturplan 0,5

Tätigkeit Durchführungsphase

Installation Softwarekomponente 1

Installation lokale Komponente 1

Erstellung eines Beispiel-Testfalls 2

Erstellung des Entwicklungsleitfadens 8

Nachvollziehbarkeit durch andere Anwender prüfen 3

Tätigkeit Dokumentationsphase

Qualitätssicherung der durchgeführten Arbeiten 4

Erstellung der Projektdokumentation und Vorstellung in der Abteilung 9

Sonstiges

Puffer 2,5

Summe 35

-----------

Grüße

kne

[127.0.0.1]

mir fehlen am anfang ein paar sätze zum projektumfeld. schon im ersten ersten satz schwingst du die techi-fachbegriffs-keule und niemand weiß, um was es geht.

wie sieht denn eigendlich punkt 1 aus?

[flashpixx]

Ich-Form geht nicht in einem Projektantrag, Du willst

Simulation von An-wenderverhalten

End-to-End-Monitoring-System in die vorhandene Monitoring-Infrastruktur zu integrieren

die Entwicklung eigener Testfälle

Was willst Du überhaupt machen? Mir ist das zu viel Technik im Inhalt und zu viel nicht konkret drum herum Geschichte. Werde bitte mal konkret was Du in Deinem Projekt real machen willst.