Projekte - Projektphase Realisierung

Die Phase der Realisierung umfasst in IT-Projekten im Wesentlichen die Programmierung, diverse Tests sowie die programmtechnische Dokumentation eines neuen Systems bzw. der Systemänderungen und wird mit der Fertigstellung des Produktes beendet.

Die Fertigstellung umfasst nicht nur das eigentliche Produkt sondern auch die erforderliche Dokumentation sowie Testpläne, Testfälle und Testnachweise seitens des Auftragnehmers (= Entwickler) als auch des Auftraggebers (in der Regel = Fachbereich).
Für die Entwicklung und Anpassung von Anwendungen müssen im Rahmen von IT-Projekten die für das jeweilige System gültigen Entwicklungs- und Programmierstandards eingehalten werden.

Ziel der Projektphase Realisierung

» Abschluss der fachlichen und technischen Planung

In Organisations- und Fachbereichsprojekten hingegen geht es um die tatsächliche Umsetzung des Produktes (z.B. Geschäftsprozessänderungen, Organisationsänderungen).

Wesentlichen Aufgaben der Projektphase Realisierung

» Überprüfung / Sicherstellung der Umsetzung der Produktanforderungen

» Umsetzung und Tests des Produktes

» Erstellung / Anpassung Entwicklerdokumentationen

» Erstellung / Anpassung Benutzerdokumentationen inkl. Schulungen

» Erstellung / Anpassung Betriebshandbuch

Anwendungssteckbrief

Im Anwendungssteckbrief sollen - entsprechend dem Entwicklungsstand des Projektes - die wesentlichen Stammdaten zu einer (neue) Applikation (= Anwendung) erfasst werden.

Der Nutzen eines Anwendungssteckbriefes

» Technische und fachliche Eigenschaften jeder Geschäftsanwendung

Mögliche Inhalte eines Anwendungssteckbriefes

Laufende Aktualisierung und Ergänzung

 

» Verwendete Technologie

» Daten

» Schnittstellen

» Infrastruktur

» Plattformen

Systemarchitekturplan

Die zur Unterstützung der Geschäftsprozesse aktuelle oder zukünftig einzusetzende Hard- und Software eines Unternehmens muss festgelegt und dokumentiert werden.
Ein Systemarchitekturplan ist als zentraler Leitfaden für an der Errichtung und Instandhaltung der IT- Architektur beteiligten Personen und Organisationseinheiten zwingend erforderlich. Er stellt sicher, dass die Entwicklung der IT-Systeme und der IT-Infrastruktur in geordneten Bahnen erfolgt.

Der Nutzen eines Systemarchitekturplans

» Alle Systeme sind gegliedert nach Geschäftsfeldern und Themengebieten

Ein operativer Systemarchitekturplan beschreibt die operative Unterstützung durch eine bestimmte Anwendungsversionen für eine Abteilung und eine Geschäftsfähigkeit (Referenzkette, Scope Matrix) in einem definierten Zeitfenster. Der operative Systemarchitekturplan sollte gegen den taktischen und strategischen Systemarchitekturplan geprüft werden.

Systemkonfiguration

Eine Systemkonfiguration (Hardware, Software, Netzwerk, Schnittsellen etc.) - soweit abweichend vom Unternehmensstandard - muss explizit beschrieben sein bzw. werden. Erste Entscheidungen hinsichtlich der Architektur und der Plattform des späteren Systems wurden in der Regel bereits in der Projektphase Auftragsklärung getroffen.

Der Nutzen einer Systemkonfiguration

» Darstellung Konfigurationseinheiten: Hardware, Software und Dienstleistungen

Eine vollständige Darstellung beteiligter Komponenten und Kommunikation lässt sich über ein Infrastrukturdiagramm darstellen.

Mögliche Inhalte einer Systemkonfiguration

» Identifikation, Beschreibung, Klassifizierung, Bewertung, Genehmigung und Umsetzung

   von Änderungen / Anforderungen

 

» Hardware-Planung

» Architektur-Planung

» Definition und Dokumentation der Zuständigkeiten für involvierte Komponenten bzw. Prozesse

Testaktivitäten

Im Rahmen eines Umsetzungsprojektes muss eine detaillierte Planung der Testaktivitäten mit Terminen, Ressourcen und einer verbindlichen Festlegung von Testkriterien erstellt werden.
Des Weiteren muss auch eine Liste der Testobjekte mit Risikobewertung, ein Zeitplan der Testvorbereitung und Testdurchführung erstellt werden sowie eine Zuordnung zu den Testern erfolgen.

Mögliche Inhalte einer Testplanung

» Liste der Testobjekte mit Risikoeinschätzung

» Zeitplan der Testvorbereitung und Testdurchführung

» Zuordnung der Testobjekte zu den Testern

Zu guter Letzt ist auch zu beachten, dass die bereitzustellende Testumgebung getrennt von der Produktivumgebung nutzbar sein muss.
Die Testplanung ist zum Zecke einer Übersichtlichkeit und Nachvollziehbarkeit mit qualitätssichernden Maßnahmen abzustimmen.

Der Qualitätssicherungsplanung beschreibt den Umfang und Inhalt der Qualitätssicherungsmaßnahmen eines Projekts. Er gilt für den gesamten Projektzeitraum und muss als ein lebendes Dokument entsprechend den tatsächlichen Projektgegebenheiten bei Bedarf aktualisiert werden.

Mögliche Inhalte einer Qualitätssicherungsplanung

» Formale und inhaltliche Prüfung

» Nachweis der Prüfung durch jeweiligen Qualitätssicherer

» Links auf Projektergebnisse

Für geänderte oder neue IT-Systeme sind im Rahmen eines Umsetzungsprojektes prinzipiell geeignete Testfälle zu spezifizieren.

Eine methodische Testfallermittlung (z.B. für Prozesstests oder Funktionstests) definiert die Eigenschaften eines Testobjektes und dient einer späteren Arbeitsvorlage für die Tester.

Mögliche Inhalte einer methodischen Testfallermittlung

» Vorbedingungen

» Eingabewerte

» Sollwerte / Nachbedingungen

» Aufteilung in Positiv- und Negativ-Testfälle  (Robustheitstest)

Durch geeignete Nummerierung sollte eine eindeutige Zuordnung zwischen Zielen, Anforderungen und Testfällen hergestellt werden können.
Um eine Klarheit über durchgeführte Tests und die dazugehörigen Testergebnisse zu erlangen sollten sogenannte Testnachweise erstellt werden. Die Testergebnisse sollten hierbei im Sinne eines besseren Überblickes getrennt nach Testphasen/Teststufen dokumentieren sein.

Mögliche Inhalte von Testnachweisen

» Detaillierter Nachweis über durchgeführte Tests und Re- Tests

» Nachweis über Protokollierung und Behebung der entdeckten Fehler

» Nachweis welche Testobjekte wann, von wem, wie intensiv, mit welchem Ergebnis getestet

Im Teststatus sollten neben den Testergebnissen auch noch geplante Testaktivitäten dokumentiert werden.

Möglicher Inhalt eines Test Fehlerprotokolls

Meldungsnummer

 

Testende Person

 

Verwendete Testdaten

 

Beschreibung des Fehlers

 

Bemerkungen zur Fehlerbehebung

 

Nachtest

 

Beispiel: Workflow einer Testdurchführung

Fehlerbearbeitung (Defects)

Für eine Fehlerbearbeitung wird in der Regel ein geeignetes Dokumentationstool benötigt. Dieses ergänzt aber keines ersetzt eine zur Fehlerbehebung erforderliche (mündliche) Kommunikation zwischen der IT und dem betroffenen Fachbereich.

Identifizierte Fehler bei einer Testdurchführung sind zu dokumentieren

» Status der Testdurchführung

» Überprüfung der Testende Kriterien

» Ausführung der Testfälle mit Testergebnis

» Ergebnisse von Re-Tests

» Protokollierung und Priorisierung der Fehler

» Dokumentation der Fehlerbehebung

Von daher gibt es Situationen in denen der Griff zum Telefonhörer schneller zu einer Behebung einer Abweichung führt. Dennoch sollten dann die wesentliche Gesprächsinhalte bzw. Vereinbarungen in einem Dokumentationstool erfasst werden.

Korrekturmaßnahmen bei kleineren Abweichungen

» Anleiten/ Qualifizierung/ Auswechslung von Mitarbeitern

» Änderung der Aufgabenverteilung/ Entlastung von Mitarbeitern

» Überstunden/ Erhöhung der Mitarbeiterzahl

» Verbesserung der Kommunikation/ Durchführung von Teambesprechungen

» Änderung der Projektinfrastruktur

Mögliche benötigte Attribute für eine Fehlerdokumentation

Attribut

Beschreibung

Typ

Attributwert

Status

Status des Fehlers

Auswahlliste

» New

» Open

» Work

» Reopen

» Clarify

» Closed

» Fixed

» Re- Test

Severity

Schwere der Abweichung

Auswahlliste

» Very High

» High

» Medium

Priority

Behebungspriorität des Fehlers

Auswahlliste

» Very High

» High

» Medium

Phase

Projektphase

Auswahlliste

» Auftragsklärung

» Fachkonzeption

» DV Konzeption

» Realisierung

Subject

Pfad des Testfalls im Testplan

Auswahlliste

» Ordner im Testplan

Assigned to

User dem der Fehler

zugeordnet wurde

Userliste

» Alle hinterlegten User

Detected by

Ersteller des Defect

Userliste

» Alle hinterlegten User

Closing Date

Datum an dem die Behebung der

Fehlermeldung akzeptiert wurde

Datumsfeld

» Format TT.MM.JJJJ

Category

Kategorie des Fehlers

Auswahlliste

» Echter Defect

» Change Request

Actual Fix Time

Tatsächliche Bearbeitungszeit

Integer

» Eingabe der Dauer (h)

Component

Komponente in der der Fehler

aufgetreten ist

Auswahlliste

» Komponentenliste

Detected on

Date

Erstellungsdatum der

Fehlererfassung

Datumsfeld

» Format TT.MM.JJJJ

Detected in

Cycle

Phase, in der der Fehler

festgestellt wurde

Link

» Teststufe oder Version

Detected in

Release

Release, in dem der Fehler

festgestellt wurde

link

» Release Nummer

Estimated Fix

Time

Geschätzter Behebungsaufwand

in Stunden

Integer

» Eingabe der Dauer (h)

Modified

Datum der letzten Änderung

Timestamp

» Format TT.MM.JJJJ

   hh.mm.ss

Test Data

Möglichkeit zum Hinterlegen

der verwendeten Testdaten

String

» Beliebige Eingabe

Priority

Behebungspriorität des Defect

Auswahlliste

» Very High

» High

» Medium

» Low

Severity

Schwere des Defect

Auswahlliste

» Very High

» High

» Medium

Status

Status des Defect

Auswahlliste

» New

» Open

» Clarify

» Work

» Fixed

» Closed

» Reopen

» Retest

Subject

Pfad des zugehörigen Testfalls

Auswahlliste

» Ordnerstruktur Test

Release

Release Termin, zu dem der Fehler behoben werden soll

Link

» Release Nummer

Mögliche Statusbeschreibungen eines Defect

Status

Status wird gesetzt vom

Bemerkung

New

Tester

 

Open

Tester/ Defectmanager

 

Clarify

Entwickler/ Defectmanager

Es gibt noch Fragen zwischen IT und Fachbereich

Work

Entwickler

Entwickler bearbeitet den Defect

Fixed

Entwickler

Entwickler hat den Defect behoben

Retest

Entwickler /Defectmanager

Behobene Fehler wird zum Re-Test freigegeben

Closed

Tester

Fehlerbehebung wurde erfolgreich erledigt

Reopen

Tester

Re-Test führte zu einer Abweichung bzw.

die Lösung (= Test- Ergebnis) wird nicht akzeptiert

Mögliche Prioritätenbeschreibungen eines Defect

Priorität

Bedeutung

Reaktionszeit

1

hohe Priorität

Beginn der Fehlerbehebung sofort

2

mittlere Priorität

Beginn der Fehlerbehebung innerhalb von x Arbeitstag (en)

3

geringe Priorität

Beginn der Fehlerbehebung wird individuell festgelegt.

Mögliche Schweregradbeschreibungen (Severity) eines Defect

Gewicht

Wirkung

Beispiele

Very

High

Software ist nicht einsatzfähig.

 

Diese Fehler sind produktionsverhindernd. Alle Aktionen, die eine nicht zu erwartende Fehlermeldung zur Folge haben zählen zu diesen Fehlern.

» Komplettabstürze

» Anzeigen nicht abgefangener Fehler

» Applikation steht temporär nicht zur Verfügung

» Daten werden nicht oder falsch gespeichert

» Eingegebene Daten lassen sich nicht mehr finden

» Grundlegende Funktionsprobleme

» Zugriff auf Daten ist möglich, obwohl dieses nach

   den Spezifikationen verboten ist.

» Funktionen werden angeboten, die gemäß Rolle

   nicht verfügbar sein sollten

High

Einschränkung der Funktionalität. Diese Fehler sind schwerwiegende Fehler, die eine Benutzung der Applikation nur mit Mühe zulassen.

» Das Ergebnis von Berechnungen und Prüfungen

   entspricht nicht den Anforderungen

» Schnittstellen lassen sich nicht ansprechen

» Felder werden falsch initialisiert

» Dokumente mit falschen Textbausteinen erstellt

Medium

Geringe Einschränkung der Funktionalität. Diese Fehler sind „unschön“, aber der Anwender kann damit weiterarbeiten.

» Vorbelegung von Feldern ungleich der Spezifikation

» Texte werden bei der Ausgabe abgeschnitten

» Layout der Dokumente entspricht nicht Vorgaben

» Labels von Feldern sind nicht vollständig

» Keine Plausibilitätsprüfung von Eingabewerten

Eine Beratung, so wie sie sein soll – Hettwer UnternehmensBeratung GmbH – Eine Beratung, so wie sie sein soll – Hettwer UnternehmensBeratung GmbH – Eine Beratung, so wie sie sein soll – Hettwer UnternehmensBeratung GmbH – Eine Beratung, so wie sie sein soll – Hettwer UnternehmensBeratung GmbH – Eine Beratung, so wie sie sein soll – Hettwer UnternehmensBeratung GmbH

Hettwer UnternehmensBeratung

Hettwer UnternehmensBeratung GmbH - Spezialisierte Beratung - Umsetzungsdienstleistungen im Finanzdienstleistungssektor – Experte im Projekt- und Interimsauftragsgeschäft - www.hettwer-beratung.de

H-UB ERFOLGSGESCHICHTE

Auszeichnung:

Gold-Partner-Zertifikat

Hettwer UnternehmensBeratung GmbH wurde aufgrund der erbrachten Beraterleistungen in den exklusiven Kreis der etengo Gold-Partner aufgenommen.

H-UB EXPERTENWISSEN

Hettwer UnternehmensBeratung GmbH – Expertenprofil Klaus Georg Hettwer (Geschäftsführer): Beratungskompetenz, Fachliche Kompetenz, Methodische Kompetenz, Soziale Kompetenz, Kommunikationskompetenz; Sonderthemen: SEPA, EMIR, TARGET2, MiFID, T2S

- Eine Beratung mit PROFIL -

H-UB Leistungskatalog

H-UB Leistungskatalog.pdf
Adobe Acrobat Dokument 89.4 KB

Projekt:

Hanseatische Container Logistik GmbH

Spedition, Logistik

Projekt:

WERDER BAU Bremen GmbH

Bauunternehmen

Projekt: Vino Bello

„La Dolce Vita“

 

H-UB SOCIAL MEDIA PRÄSENZ

© 2010-2024 Hettwer UnternehmensBeratung GmbH