CAFM-System: Performance – Zugriffs- und Antwortzeiten

In dieser Kategorie wird ein dedizierter Desktop-Client (installierte Anwendung) betrachtet. Die Kommunikation mit dem Server (Datenbank, Applikationsserver) erfolgt typischerweise über das Firmennetz (LAN/VPN). Der Desktop-Client könnte umfangreiche Funktionalität bieten, was initiale Ladezeiten beeinflusst. Anforderungen und Prüfungskriterien ähneln der Web-Lösung, sind jedoch auf die Desktop-Charakteristika angepasst.

• MUSS-D1: Programmstart und Login: Der Start des Desktop-Clients inkl. Benutzeranmeldung muss bei Standardauslastung in unter 15 Sekunden abgeschlossen sein (vom Starten der Anwendung bis zum vollständigen Laden der Startoberfläche). Obwohl komplexe Unternehmensanwendungen gelegentlich längere Ladezeiten haben können, sind >30 s nicht akzeptabel. Abnahmeprüfung: Start der Client-Software auf einem Referenz-PC im Firmennetz; Zeitmessung vom Doppelklick bis zur Anzeige des Hauptfensters nach Login. Fünf Versuche im Abstand von jeweils 5 Minuten; alle unter 15 s, keiner > 20 s (Toleranz für ersten Start nach PC-Neustart).

• MUSS-D2: Modulaufruf und Navigation: Modulwechsel und Fensteröffnungen im Client (z. B. Wechsel ins Wartungsmodul, Öffnen eines Tickets im Helpdesk-Modul) dürfen maximal 2 Sekunden benötigen, um das jeweilige Fenster mit allen Daten darzustellen. Der Desktop-Client sollte nach dem Initialstart GUI-Interaktionen nahezu verzögerungsfrei ermöglichen. Abnahmeprüfung: In einer Testdatenumgebung nacheinander verschiedene Module per Menü oder Icon aufrufen. Mitlaufende Zeitmessung (Stoppuhr) bis das Fenster fertig geladen ist. Kein Aufruf darf > 2 s dauern.

• MUSS-D3: Speicheraktionen und Rückmeldungen: Speicher-, Update- und Löschvorgänge müssen auch im Desktop-Client nahezu unmittelbar erfolgen. Innerhalb von 1–2 Sekunden nach dem Klick auf „Speichern“ muss eine Bestätigung oder das aktualisierte Datenobjekt sichtbar sein. Abnahmeprüfung: Bearbeiten eines Datensatzes (z. B. Raumdaten ändern) und Speichern. Die Zeit bis zur Bestätigungsnachricht bzw. bis das Speichern im UI erkennbar ist, wird gemessen. Erlaubt sind ≤ 2 s.

• MUSS-D4: Lokale Such- und Filterfunktionen: Der Desktop-Client muss Suchabfragen in lokalen Daten (sofern Teilmenge lokal gecacht) quasi sofort liefern. Suchen, Filtern oder Springen in Tabellen soll in unter 2 Sekunden Resultate zeigen. Bei serverseitigen Abfragen auf großen Tabellen gilt analog die 5-Sekunden-Regel wie bei Web (siehe MUSS-W4). Abnahmeprüfung: In einer Tabelle von ~10.000 Einträgen einen Filter setzen oder Scroll-Suche durchführen; Zeit bis zur Aktualisierung der Ansicht messen (< 2 s). Zudem einen globalen Suchauftrag stellen (der serverseitig alle Gebäude nach einem Stichwort durchsucht); Zeit messen (< 5 s).

• MUSS-D5: Berichtserstellung im Client: Werden Berichte direkt im Desktop-Client generiert (via eingebettete Reporting-Engine), gelten dieselben Grenzwerte wie im Web: Standardberichte in < 10 Sekunden, komplexe Berichte in < 30 Sekunden (ansonsten Hintergrundverarbeitung). Abnahmeprüfung: Entsprechende Reports analog MUSS-W5 erzeugen und Zeiten messen, ggf. prüfen ob bei >30 s ein asynchroner Prozess genutzt wird.

• SOLL-D1: Schneller Wiedereinstieg: Der Desktop-Client sollte einen Warmstart oder Resume-Modus unterstützen, sodass nach einmaligem Laden die Anwendung bei erneutem Öffnen (am selben Tag) in ≤ 5 Sekunden bereit ist. Z.B. wenn der Client im Tray weiterläuft, soll das Öffnen nahezu sofort erfolgen. Abnahmeprüfung: Client öffnen, schließen/minimieren, nach 10 Minuten erneut öffnen – die Startzeit beim zweiten Mal messen (< 5 s).

• SOLL-D2: Belastbarkeit und Peaks am Desktop: Falls viele Desktop-Clients parallel aktiv sind, soll die Server-Kommunikation so effizient sein, dass auch 100 gleichzeitig aktive Clients die Reaktionszeiten nur geringfügig verschlechtern. Ziel: selbst unter dieser Last keine Antwortzeit > 4 Sekunden für Kernaktionen (Navigation, Speichern). Abnahmeprüfung: Simulation von 100 Clients (z. B. durch virtuelle Maschinen oder Skripte) und Messen der Antwortzeiten für definierte Aktionen. Überprüfen, dass 90% der Aktionen < 3 s und alle < 4 s bleiben.

• SOLL-D3: Offline-Fähigkeit für Performance: Soweit möglich, sollte der Desktop-Client gewisse Daten offline bzw. client-seitig cachen (z. B. zuletzt geladene Gebäudepläne), um auch bei kurzzeitigen Netzwerkaussetzern oder im VPN-Betrieb gute Performance zu bieten. Im Offline-Modus sollen Lesezugriffe auf bereits vorhandene Daten sofort erfolgen (0–1 s), und Änderungen zwischengespeichert und bei Wiederverbindung synchronisiert werden. Abnahmeprüfung: Netzwerkverbindung kappen (Simulation eines Verbindungsverlusts) und prüfen, dass zuletzt geladene Inhalte noch zugreifbar sind. Zeiten messen für das Öffnen einer bereits geladenen Maske (nahe 0 s) vs. einer nicht im Cache befindlichen Maske (Fehlermeldung oder Hinweis auf Offline, aber kein Freeze).

• SOLL-D4: Ressourcenverbrauch und Performance: Der Desktop-Client soll performant arbeiten, ohne dauerhaft hohe Systemressourcen zu binden. Insbesondere soll die CPU-Last im Leerlauf < 5% und während Standardaktionen < 20% (auf Referenz-PC) liegen, um flüssige Bedienung zu gewährleisten. Ebenso soll Speicherbedarf moderat sein (< 500 MB im Normalbetrieb). Abnahmeprüfung: Taskmanager/Performance-Monitor während eines Testlaufs beobachten. Sicherstellen, dass keine ungewöhnlich hohen Peaks außer bei Ladevorgängen auftreten und dass die Anwendung nicht durch Memory-Leaks zunehmend langsamer wird.

• KANN-D1: Hintergrundaktualisierung: Wünschenswert ist, dass der Desktop-Client im Hintergrund Daten vorab lädt oder aktualisiert, sodass der Nutzer bei Aufruf eines Moduls keine Wartezeit hat. Beispielsweise kann das System periodisch im Hintergrund neue Ticketdaten oder Messwerte laden. Dies darf zwar optional sein, würde aber die wahrgenommenen Antwortzeiten weiter reduzieren. Abnahmeprüfung: Konzeptprüfung – der Anbieter legt dar, welche Hintergrund-Refresh-Mechanismen existieren. Gegebenenfalls prüfen, ob beim zweiten Aufruf eines zuvor langsamen Reports deutlich geringere Ladezeiten auftreten (was auf Vorab-Berechnung hindeutet).

• KANN-D2: Konfigurierbare Performance-Optionen: Optional kann der Client dem Administrator Einstellungen bieten, um Performance vs. Ressourcennutzung zu steuern (z. B. Cache-Größe, Detailgrad von Grafiken). So könnte z. B. bei schwächeren Netzwerken ein Low-Bandwidth-Modus aktiviert werden, der die Datenmenge reduziert. Abnahmeprüfung: In den Einstellungen nach Optionen suchen, die explizit Performance betreffen. Falls vorhanden, diese ausprobieren (z. B. Grafikdetails reduzieren) und prüfen, ob sich Ladezeiten messbar verbessern.

• KANN-D3: Spitzenlast-Verteilung: Bei sehr hoher Last könnte der Desktop-Client Mechanismen unterstützen wie Queueing von Benutzeraktionen oder Load Balancing auf Serverseite (wenn mehrere Anwendungsserver vorhanden sind). Zwar wird dies nicht vorausgesetzt, aber Anbieter, die darlegen, wie ihr System auch bei ungewöhnlichen Peaks (>>100 Nutzer) stabil und bedienbar bleibt, erhalten einen Bonus. Abnahmeprüfung: Architekturbeschreibung des Anbieters bewerten – insbesondere wie das System skaliert. Möglicher Test: künstliche Überlast erzeugen und beobachten, ob der Client Wartehinweise gibt statt unresponsiv zu werden.

Mobile Zugriffe erfolgen über eine native App oder ggf. Web-App auf Smartphones und Tablets. Hier stehen oft eingeschränkte Hardware-Ressourcen und schwankende Netzwerkverbindungen (WLAN, 4G/5G) zur Verfügung. Benutzer erwarten von mobilen Apps besonders kurze Reaktionszeiten und unmittelbare Rückmeldungen. Die Anforderungen tragen dem Rechnung, indem sie kurze Ladezeiten fordern und Offline-Fähigkeiten betonen, wo sinnvoll.

• MUSS-M1: App-Start und Anmelden: Die Startzeit der mobilen App (Kaltstart aus dem nicht laufenden Zustand) inklusive Login muss bei guter Verbindung ≤ 8 Sekunden betragen. Mobile Apps werden vom Nutzer sonst schnell als zu langsam empfunden. Ist der Nutzer bereits eingeloggt (Warmstart aus dem Hintergrund), muss der Zugriff auf die App-Oberfläche in < 3 Sekunden erfolgen. Abnahmeprüfung: Stoppuhrmessung auf einem Referenz-Smartphone (aktuelles Mittelklassemodell). Einmal App komplett schließen und neu starten (Zeit messen bis Start-Dashboard erscheint, < 8 s), dann App schließen und innerhalb 1 Minute erneut öffnen (Dashboard < 3 s).

• MUSS-M2: Reaktionszeit bei Eingaben: Bedienaktionen in der App (Menüaufrufe, Öffnen eines Datensatzes, Scrollen durch Listen) müssen nahezu verzögerungsfrei erfolgen. Konkret darf die Anzeige neuer Inhalte nach einer Nutzeraktion höchstens 2 Sekunden dauern (bei Standardbedingungen im WLAN/LTE). Aktionen wie Foto aufnehmen und anhängen oder Barcode scannen sollen ebenfalls ohne spürbare Wartezeit (< 3 s inkl. Upload) vonstattengehen. Abnahmeprüfung: In der mobilen Test-App werden typische Arbeitsabläufe durchgespielt (z. B. Öffnen eines Tickets, Navigieren zur nächsten Seite, Anhängen eines Fotos). Mitlaufende Zeitmessung via Screen-Recording mit Zeitstempel. Auswertung: Keine sichtbare Aktion > 2 s, auch Medien-Uploads nicht > 3 s bis zur Bestätigung.

• MUSS-M3: Datenabruf und Synchronisierung: Online-Abfragen (z. B. Suche nach einem Raum, Laden einer Geräteliste) müssen bei 4G/LTE Empfang in ≤ 5 Sekunden Ergebnisse liefern. Die mobile App muss effiziente API-Aufrufe und Datenkompression nutzen, um auch im Mobilfunknetz zügig zu sein. Synchronisationsvorgänge (z. B. Laden neuer Aufgaben beim App-Start) dürfen bei normalem Umfang ebenfalls max. 5–10 Sekunden dauern; längere Synchronisation ist in den Hintergrund zu verlagern. Abnahmeprüfung: Mit aktiviertem 4G (und ggf. etwas gedrosselter Bandbreite ~10 MBit/s, Latenz ~50ms) die App nutzen: Suche ausführen, Liste laden, etc., Zeit bis Ergebnis messen (< 5 s). Zudem nach Login einen Sync-Vorgang beobachten; ist er länger als 5 s, sicherstellen dass UI nutzbar bleibt und ein Ladeindikator sichtbar ist.

• MUSS-M4: Offline-Verfügbarkeit kritischer Funktionen: Für eine mobile Anwendung im CAFM-Bereich ist es essenziell, dass Basisinformationen offline verfügbar sind, um bei Netzlücken weiterarbeiten zu können. Die App muss daher zuletzt geladene Datensätze (z. B. offene Tickets, Grundrisse für einen zugewiesenen Bereich) lokal puffern. Bei Offline-Nutzung sollen gecachte Inhalte sofort abrufbar sein (< 1 Sekunde), und Eingaben/Änderungen zwischengespeichert werden, bis wieder Netz verfügbar ist. Abnahmeprüfung: Gerät in den Flugmodus schalten und versuchen, kürzlich betrachtete Daten (z. B. Ticketdetails, einen Raumplan) erneut zu öffnen – diese müssen angezeigt werden (< 1 s). Änderungen an einem Ticket offline durchführen, dann Netz aktivieren und prüfen, ob binnen kurzer Zeit die Synchronisation erfolgt.

• SOLL-M1: Optimierte mobile Ladezeiten: Idealerweise lädt die App häufig genutzte Inhalte bereits beim Start vor. Die meisten Standardansichten sollen in ≤ 1–2 Sekunden erscheinen – der Zielwert sind unter 1 Sekunde für Listen und Detailansichten, um ein schnelles, app-typisches Nutzungserlebnis zu bieten. Abnahmeprüfung: Messung der Zeit bis zur Anzeige für mehrere häufige Views (Startliste, Ticket-Detail, etc.) und Verifizierung, dass diese im Bereich 1–2 s liegen. Vergleich mit Muss-Werten zeigt deutliche Unterschreitung.

• SOLL-M2: Effiziente Netzwerknutzung: Die mobile App soll sparsam mit der Netzbandbreite umgehen, um schnelle Antworten zu ermöglichen. Paging bei Listendaten (> 50 Einträge) und Delta-Synchronisation (nur Änderungen nachladen) sollen eingesetzt werden. Dadurch bleiben auch bei größeren Datenmengen die Antwortzeiten stabil unter den Grenzwerten, anstatt mit der Datenmenge anzusteigen. Abnahmeprüfung: Bei einer Liste mit z. B. 1000 Einträgen prüfen, ob die App Daten seitenweise lädt (z. B. Scroll -> neue Seite). Netzwerkmonitoring des Smartphones nutzen, um zu sehen, dass keine unnötig großen Datenmengen übertragen werden. Response-Zeiten vor und nach Befüllung mit vielen Daten vergleichen – dürfen nicht signifikant steigen.

• SOLL-M3: Nutzerfeedback bei Wartezeit: Falls in Ausnahmefällen eine Aktion in der App länger als 3 Sekunden dauert (z. B. schwaches Netz beim Datenladen), soll dem Benutzer unverzüglich visuelles Feedback gegeben werden (z. B. Ladespinner). Ab 5+ Sekunden ist eine Statusanzeige (Fortschritt oder Hinweis “Bitte warten…”) erforderlich, damit der Nutzer informiert ist. Abnahmeprüfung: Netzwerksignal künstlich verschlechtern (z. B. nur 3G) und eine datenintensive Aktion ausführen. Beobachten, ob spätestens nach 3 s ein Ladesymbol erscheint. Bei längerem Warten (>5 s) auf den Screen schauen, ob eine Meldung/Progress angezeigt wird.

• SOLL-M4: Angepasste Performance auf Gerätetyp: Die App soll ihre Performance an das Gerät anpassen (Responsiveness soSOLL-M4: Angepasste Performance auf Gerätetyp: Die App soll ihre Performance an das Gerät anpassen (Responsiveness sowohl auf High-End-Smartphones als auch auf älteren oder leistungsschwächeren Geräten). Das bedeutet z. B. geringere Detailtiefe oder Effekte auf schwachen Geräten, um flüssige Animationsraten und Ladezeiten zu halten. Abnahmeprüfung: Installation der App auf einem älteren Gerät (mind. 3 Jahre alt, untere Mittelklasse damals). Test der Hauptfunktionen – es dürfen keine deutlich längeren Wartezeiten auftreten als auf dem Referenzgerät (max +50%). Sichtprüfung, ob z. B. komplexe Grafiken heruntergebrochen werden (vergleichende Beobachtung evtl. Unterschiede in Darstellungsqualität).

• KANN-M1: Erweiterte Offline-Funktionen: Wünschenswert ist eine vollständige Offline-Nutzbarkeit für definierte Module. Z.B. könnte die App alle relevanten Tickets einer Woche vorausladen, sodass im Feld ohne Netz gearbeitet werden kann und Synchronisation später erfolgt. Dies ist vorteilhaft, aber optional. Wenn angeboten, muss jedoch sichergestellt sein, dass bei erneuter Netzverbindung die Synchronisation konfliktfrei und zügig (innerhalb weniger Sekunden) abläuft. Abnahmeprüfung: Vom Anbieter dokumentierte Offline-Funktion testen: App im WLAN starten, Daten laden lassen, dann ins Offline wechseln und typische Aufgaben ausführen. Später online gehen und prüfen, ob die Daten konsistent hochgeladen werden.

• KANN-M2: Push-Optimierung: Die App kann optional Push-Benachrichtigungen und Hintergrundupdates nutzen, um dem Nutzer aktuellste Informationen ohne manuelle Aktualisierung bereitzustellen. Beispielsweise können neue Ticketzuweisungen per Push gemeldet und im Hintergrund vorab geladen werden, sodass beim Öffnen kein Ladevorgang nötig ist. Abnahmeprüfung: Falls unterstützt, einen Test-Push vom Server an die App senden (z. B. neues Ticket). Prüfen, ob die Benachrichtigung erscheint und beim Tap darauf der Inhalt sofort oder sehr schnell (<1 s) sichtbar ist (dank Hintergrundrefresh).

• KANN-M3: Cross-Plattform Performance-Konsistenz: Es ist vorteilhaft, wenn die mobile App auf verschiedenen Plattformen (iOS/Android) gleiche Performance bietet. Unterschiede in Ladezeiten oder Responsiveness zwischen den Betriebssystemen sollten minimal sein. Abnahmeprüfung: Gleiche Testszenarien auf einem iPhone und einem Android-Gerät ausführen. Die gemittelten Lade-/Antwortzeiten vergleichen – idealerweise Abweichung < 20%. Höhere Abweichungen könnten auf Optimierungsbedarf auf einer Plattform hindeuten (kein Ausschlusskriterium, aber fließt in Bewertung ein).

• Performance-Testumgebung: Es ist eine Testumgebung aufzubauen, die das zu erwartende Produktionsszenario hinreichend nachbildet (Serverleistung, Netzwerklatenzen, Datenvolumen). Nur so sind die Messwerte belastbar und vergleichbar. Dokumentation der genutzten Umgebung und Lastsimulation ist erforderlich, damit die Ergebnisse nachvollziehbar und wiederholbar sind.

• Automatisierte Lasttests: Wo möglich, sollen automatisierte Performance-Tests (z. B. mit Tools wie JMeter, LoadRunner etc.) eingesetzt werden, um konsistente Lastbedingungen für 50, 100, 200% der erwarteten Last zu erzeugen. Dabei sind besonders die Metriken Antwortzeit (End-to-End), Durchsatz (Transaktionen pro Sekunde) und Ressourcenauslastung zu erfassen. Kritische Grenzwerte aus diesem Anforderungskapitel sind in den Testskripten abzubilden (z. B. Assertions, dass 95% der Requests < X s).

• Nutzerbasierte Tests: Zusätzlich zu technischen Lasttests werden Use-Case-Tests mit echten Bedienern empfohlen. Hierbei wird geprüft, ob sich die Anwendung subjektiv flüssig anfühlt und ob die Nutzer die Performance als ausreichend empfinden (Ergonomie-Faktor). Gerade Aspekte wie die Wirksamkeit von Ladeanzeigen (SOLL-W4, SOLL-M3) können so evaluiert werden.

• Spitzenlast-Simulation: Insbesondere die Szenarien mit gleichzeitiger Lastspitze (z. B. End of Month) sind im Auswahlverfahren zu simulieren. Dies kann durch eine Kombination von Lasttests und gleichzeitigen Batch-Jobs erfolgen. Die Systemreaktion ist dabei genau zu beobachten – das System darf nicht instabil werden. Geprüft wird, ob weiterhin alle Muss-Anforderungen (ggf. mit etwas erhöhten Zeiten innerhalb Soll-Grenzen) erfüllt bleiben.

• Dokumentation und Monitoring: Die Anbieter sollen im Pflichtenheft darlegen, wie die geforderten Performancewerte erreicht werden (Architektur, Sizing-Empfehlungen) und wie im Betrieb die Einhaltung überwacht werden kann. Z.B. könnte vorgeschlagen werden, bestimmte SLAs/SLOs zu vereinbaren, etwa „95% aller Transaktionen unter 3 s“, und entsprechendes Monitoring bereitzustellen.

Durch diese klar formulierten Anforderungen und Prüfkriterien wird sichergestellt, dass das ausgewählte CAFM-System eine hohe Performance bietet. Schnelle Zugriffszeiten – sowohl für alphanumerische Daten als auch für grafische Informationen – sind entscheidend für die Akzeptanz beim Anwender. Das System soll auch bei großen Datenmengen und Mehrbenutzerbetrieb kurze Antwortzeiten liefern, sodass z. B. Abfragen „auf Knopfdruck“ Ergebnisse liefern. Insgesamt gewährleistet dieses Performance-Lastenheftkapitel, dass nur Lösungen in Frage kommen, die den heutigen Best Practices entsprechen und auch unter realen Bedingungen (viele Nutzer, viel Daten, unterschiedliche Netzwerke) zuverlässig performant sind.