Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE 3.1 ProzessqualitätLM 5 V-Modell-AnwendungenFolie 1 LE3-1-5-1 Inhalt und Vorbemerkungen

Universität Stuttgart Universität Stuttgart

Institut für Kernenergetik und Energiesysteme

LE 3.1 Prozessqualität LM 5 V-Modell-Anwendungen Folie 1

LE3-1-5-1 Inhalt und Vorbemerkungen




V - Modell Anwendung auf grosse Projekte

Inhalt Kurze Beschreibung des Projektes ABRKFUe: Grobkonzept

Grundlagen: Management großer technischer Projekte

Vorgehensmodell

Submodell Softwareentwicklung (SE) und das ABR-System

Softwareentwicklung eines Dienstes im ABR-System

Risikomanagement - Erfahrungen aus dem Projekt ABRKFUe




Das sollten Sie heute lernen

Es wird die Anwendung des V-Modells für die Erstellung großer Software Pakete erläutert.

Basis ist Erstellung eines Softwareproduktes am Beispiel des Projektes ABRKFUe.

Als Prozessmodell war zu Beginn ein Wasserfallprozess vorgegeben, im Läufe des Projektes wurde zu einem iterativ-inkrementellen Vorgehen in Anlehnung an dem Rational Unified Prozess (RUP) übergegangen.

Es werden Beschreibungsmuster für wichtige Produkte solcher Projekte vorgegeben. Sie sind auf die speziellen Anforderungen des IKE zugeschnitten, können aber leicht auf die Erfordernisse anderer Institutionen angepasst werden (Tayloring).




LE3-1-5-2 V-Modell für grosse Projekte




V-Modell für grosse Projekte

Der Entwicklungsstandard des Bundes für IT-Systeme besteht

aus drei Teilen:

Vorgehensmodell (Was ist zu tun?),

Methodenzuordnung (Wie ist etwas zu tun?)

Funktionale Werkzeuganforderungen (Womit ist etwas zu tun?)

Für eine Gruppe wie sie an Universitäten möglich ist, ist zusätzlich die Frage der Rollen von Bedeutung (Wer muss was tun? )

Im V-Modell wird der Entwicklungsprozess als eine Folge von Tätigkeiten, den Aktivitäten, und deren Ergebnisse, den Produkten, beschrieben. Sie werden im Folgenden für Projekte angegeben, die wir am IKE durchgeführt haben. Der Projektbudget betrug dabei zwischen 0.1 und 1.5 MEuro

Werkzeug-anforderungen

Methoden

Vorgehensweise

Konfigurationsmanagement

Qualitätssicherung

Systemerstellung

Projektmanagement




Die Kernreaktor- Fernüberwachung (KFÜ) ist ein Entscheidungshilfesystem,

welches im Rahmen des Notfallschutzes eingesetzt wird.

Es ist wesentliche Grundlage, um im Ernstfall die richtigen Entscheidungen zu treffen

Beispielprojekt: Kernreaktor- Fernüberwachung BW

Dazu muss es die Entscheider unterstützen bei• der zeitnahen Erfassung der Lage ( Messdaten )• der Interpretation der Ereignisse ( GIS-Bezug und Grenzwerte )• der vorsorgenden Untersuchung möglicher Handlungsalternativen und der Beurteilung Ihrer Konsequenzen ( Simulation )




Simulation im Notfallschutz

Ziel der Simulation ist es, vorherzusagen, wie sich radioaktive Emmissionen ausbreiten und welcher Belastung die Bevölkerung dadurch ausgesetzt wird.

Ziel des Notfallschutzes ist es, diese Belastung so gering wie möglich zu halten.

Kern der Simulation sind daher Ausbreitungs- (ABR) und Dosisberechnungsprogramme




Das physikalische Modell einer Ausbreitungsrechnung




Das Simulationsmodell der Komponente ABR




Die Komponente ABR als komplexes System

System besteht aus vielen Anwendungssystemen, die durch eigene Workflows beschrieben werden

Entwicklung des Systems erforderte Basisentwicklungen im Hinblick auf die Anwendungsentwicklung

Entwicklung des Systems erforderte Integration vorhandener Soft- und Hardware und die Vergabe von Unteraufträgen

System muss unter Echtzeitbedingungen laufen und Ergebnisse von hoher Verlässlichkeit liefern




Klassische Lösung - Verarbeitung des Wissens durch menschliche Agenten




Die Vision - Entscheidungsunterstützung auf hoher Ebene




LE3-1-5-3 Das ABR-System




Das ABR-System im Projekt ABRKFUe

Anwendung und Kontext

Die ABR ist ein Simulationssystem welches im Rahmen des

Notfallschutzes eingesetzt wird

Problembereich

Die ABR ist eine wesentliche Grundlage, um im Ernstfall die

richtigen Entscheidungen zu treffen




Anforderungen im ABRKFUe

Höchste Qualitätsansprüche da Einsatzbereich Notfallschutz

Sehr hohe Verfügbarkeit und Ausfallsicherheit im Ernstfall

Auch unter Stress sichere Verwendung

Berücksichtigung aktuellster Messdaten

Im Ernstfall automatische Simulation

Integration in das Rest-KFÜ

Wartungsfreundlich

Leicht und kostengünstig erweiterbar




Architektur des KFÜ

KS

DatenabrufDaten versenden

ReplikationProtokoll-GeneratorAlarmierung

ZDH

DatenverarbeitungAnnehmenValidierenVerdichtenPseudomeßwerteAlarmieren

Protokoll-GeneratorZeitsteuerung

Externe SchnittstellenZeitsteuerungParameter-Einstellung

ABR

Schnittstelle ABR - ZDH Initialisierung zeitschrittabh.Parameter

Schnittstelle ABR - Client

Rechnungsdurchführung

Client

Benutzeroberfläche ABR Meßwerte Steuerung

Intern-format

ABRProtokolle

AS

Proto-kolle

Datenbank

Datenbank

ABR

Repository

Architektur

DCOM

SQL*Net

Replikationen

Messdaten

DarstellungenAuswertungen

Simulationen




Architektur des ABR-Systems (1)

Flache Struktur Aufgaben sind auf einzelne Dienste verteilt Zur Kommunikation zwischen den Diensten wird ein

Kommunikationsframework verwendet Basis für das Kommunikationsframework ist Corba Kopplung von Einzeldienstleistung zu Gesamtdienstleistungen mittels

Workflows Schnittstellen nach außen verwenden DCOM bzw. SQL*NET für die

Kommunikation Trennung zwischen Daten und Metadaten Austausch der Daten erfolgt über ein Repository




Architektur des ABR-Systems (2)

ZDHZDHServiceService

Emissions-Emissions-datendaten

ServiceService

ErsatzwertErsatzwertServiceService

StammdatenStammdatenServiceService

CalculatorCalculatorServiceService

AdminAdminServiceService

ProtokollProtokollServiceService

ArchivArchivServiceService

ClientClientInterfaceInterface

9 Simulation9 SimulationServicesServices

ClientClientManagerManager

AlarmAlarmServiceService

SimulationsdiensteSimulationsdienste

Datenbeschaffungs-Datenbeschaffungs-dienstedienste

SystemdiensteSystemdienste

sonstige Dienstesonstige Dienste

RepositoryRepositoryServiceService

RessourceRessourceServiceService

StrategieStrategieServiceService

WorkflowWorkflowServiceService

KlientendiensteKlientendienste

ABRABRWatchdogWatchdog

Kommunikationsframework Service Agent Layer (SAL), Corbabasierte Middleware




Was bei der Modellierung komplexer Systeme bedacht werden sollte

ABR-System

Vorgehensmodell(e)

Standardnotation undProgrammierrichtlinien

Konfigurations- undVersionsmanagement

Spezifikation, Anforderungs-und Änderungsmanagement

Kooperation mitProjektpartnernund Kunden

InkrementellesVorgehen

Risikomanagement

Fehlerverfolgung

Gemeinsames Vokabular

Mitarbeiterentwicklung

Ressourcenplanung

Projektcontrollingund -Steuerung

Projektvorbereitung




Vorgehensmodelle in ABRKFUe

Zu Beginn des Projektes V-Modell in Kombination mit Wasserfallmodell

(Vorgabe strukturierte Analyse)

Im Laufe des Projektes Wechsel zu V-Modell in Kombination mit einer

iterativ-inkrementellen Vorgehensweise (in Anlehnung an RUP). Dadurch

wurden viele Spezifikationsarbeiten wertlos, es konnten aber in einer

endlichen Zeit experimentierbare Ergebnisse erzielt werden

Das V-Modell kam über den gesamten Projektlebenszyklus zum Einsatz. Dies ergab hohe

Transparenz, jedoch musste die Handhabung geändert werden, um die Prozessbeteiligten nicht durch eine Flut von Informationen lahmzulegen.




Submodell Projektmanagement

Projekt initialisieren

Hauptaktivität initialisieren

Hauptaktivität begleiten

Hauptaktivität abschließen

Projekt abschließen

Auftrag erteilt

Aufgaben verteilt

Produkte abnehmen

Werkabnahme

Schlussrechnung




LE3-1-5-4 Planung von Projekten




Planung von Projekten bei iterativ-inkrementellem Vorgehen (PM)

Was soll geplant werden? Grobe Festlegung der Iterationen während

Antragstellung Meilensteine Was soll wann erreicht werden

Feinplanung mit Aufwandsabschätzung (nur) der nächsten Iteration während Projektdurchführung

Wer plant? Projektleiter Architekt ggf. weitere Fachleute aber auf keinen Fall Jeder und was gefällt




Rollen im Projekt (Das Team)

Zentrale Rollen Fachwissen Architekt Technologie Domänenexperte

Anwenderungsbereiche Projektleiter Organisation Qualitätsmanager Projektziele

Weitere Rollen Fachwissen Systemanalytiker Designer ... Programmierer ....




Besetzung der Rollen Alle als projektnotwendig identifizierte Rollen müssen mit geeignet

qualifiziertem Personal besetzt werden. Eine Person kann gleichzeitig mehrere Rollen übernehmen. Ggf. muss benötigtes Know-How durch Weiterbildung geschaffen oder

zugekauft werden. Die Zuordnung von Rollen zu Mitarbeitern kann frei erfolgen mit zwei

Ausnahmen: Personen mit QS-Rollen dürfen nicht an der Erstellung der von ihnen

zu prüfenden Produkte beteiligt sein (dies ist abhängig von der Kritikalität unterschiedlich streng zu handhaben).

Zu trennen ist auch die Rolle des Projektmanagers von QS- und SWE-Rollen.

Es ist somit eine Mindestanzahl von zwei bis drei Personen an einem Projekt beteiligt.

Besetzung der Rollen kann Aufwände bis zu einem Faktor 10 variieren lassen oder Projekte sogar ganz zum Scheitern bringen.




Anpassung des V-Modells an Projekte - Tailoring

Das V-Modell soll sowohl für kleine als auch sehr große Projekte geeignet sein. Demzufolge definiert es alle Aspekte, die in diesen Projekten auftreten können. Das Tailoring sieht vor, aus dem V-Modell durch Streichungen ein an das Projekt angepasstes Modell zu erstellen.

Für das Tailoring stehen kommerzielle Werkzeuge zur Verfügung.

Die Projects Web-Seiten von Andreas Kitz helfen bei der Erstellung des Projekthandbuches.

Vorschläge für IKE Projekthandbücher werden hier bereitgestellt:

IKE-Projekthandbuch Antrag

IKE Projekthandbuch Durchführung

IKE Muster Abschlussbericht




Stufen des Tailoring

Ausschreibungsrelevantes Tailoring(zu Projektbeginn)

Technisches Tailoring(im Projektverlauf)

Stufen des Tailoring

Auswertung der projektspezifischenAusführungsbedingungen

Festlegung sonstigerprojektspezifischer

Ausführungsbedingungen

Auswahl dererforderlichen

Aktivitäten/Produkte

Projektplan

Projekthandbuch

Auswahlempfehlungenbzw. StreichbedingungenGenerisches V-Modell




Grundaufgaben der Planung

Welche Aufgaben sind durchzuführen (Iterations-Planungs-Matrix) Welche Ziele sollen erreicht werden Wie können diese überprüft werden Welche Randbedingungen sind zu beachten Abgrenzung - was wird nicht getan Bestimmung der Verantwortlichen Zuteilung der Mitarbeiter zu den Aufgaben Aufwandsschätzung




LE3-1-5-5 Qualitätsmanagement als Basis des Erfolges




Qualitätsmanagement als Basis des ErfolgesVereinbarung der Ziele

überprüfbar und realistisch verstehbar akzeptiert von allen Beteiligten

Überprüfung des Erreichten Maßnahmen zur Beurteilung der Ergebnisse Beurteilung der Ergebnisse Hinweis auf Konsequenzen

QM und Projekt QM hat moderierende und organisierende Rolle QM ist aktiv mit verantwortlichen Tätigkeiten verbunden QM unterstützt PM im Bestreben Projekt erfolgreich zu machen




Anforderungenund/oderErwartungenan das Produkt

Merkmale undEigenschaftendes Produktes

PROZESS

Anweisungen Ausführung

Softwarequalität

Qualitätsziele werden während der Konzeptfindung vorgegeben. Der Entwicklungsprozeß bestimmt Eigenschaften und Qualität des Produktes.

Die Qualität des Entwicklungsprozesses kann definiert gemessen und verbessert werden.

Produktqualität wird durch gute Prozeßqualität leichter erreicht QM meint daher Festlegung des Vorgehensmodelles und Prüfung der darin

beschriebenen Produkte

Produktqualität Nachweis durch Prüfung

Prozessqualität Nachweis durch Zertifizierung




Submodell Qualitätssicherung

QS-InitialisierungQS-Initialisierung

PrüfungvorbereitenPrüfung

vorbereitenProzessprüfung

vonAktivitäten

Prozessprüfung von

Aktivitäten

QS-Berichts-wesen

QS-Berichts-wesen

Produkt prüfenProdukt prüfen

Durchführungs-entscheidung

Durchführungs-entscheidung

Fertigproduktprüfen

Fertigproduktprüfen

QM in PH anlegenQM in PH anlegen

Testziele

und Tests

beschreiben

Testziele

und Tests

beschreiben

Tests durchführen Tests durchführen AbnahmetestAbnahmetest

Soll-ist VergleichSoll-ist Vergleich




Das Projekthandbuch als Basis des QM

Das Projekthandbuch beschreibt die Ziele des Projektes die Regeln zur Überprüfung des Erreichten die Wege zum Erreichen der Ziele die zu erfüllenden Rand- und Nebenbedingungen

durch projektspezifische Konkretisierung eines Vorgehensmodells.

Das Projekthandbuch enthält daher Rahmenrichtlinien Prozessleitfaden Durchführungsrichtlinien und -hilfen

Konkretisierungen werden oft erst im Laufe des Projektes möglich. Das Projekthandbuch ist also ein dynamisches Dokument. Das gilt insbesondere bei iterativem Vorgehen




Submodell Softwareentwicklung (SE)




Testgetriebene Entwicklung

Testgetriebene Software-Entwicklung (Thaller: ISO 9001) zeigt die Verbindung von Prozessmodell und Qualitätsicherung




Submodell SE 1(Anforderungsanalyse) im ABRKFUe

Erstellung einer Spezifikation des Gesamtsystems gemeinsam mit dem Kunden und den Projektpartnern als Word-Dokument

Erstellung eines fachlichen Modells mittels eines SA-Werkzeuges (Promod)

Spätere Abweichungen bzgl. der Anforderungen müssen mittels eines Change-Requests beantragt und von einem Projektkontrollgremium genehmigt werden

ZDH_ABR_Scenarien ZDH_ABR_

Ergebnisreports

ZDH_ABR_EIN

Zustand_A_NCLIENT_ABR

ABR_ZDH_Ergebnisreports

B_berechnete_Ergebnisse

ABR_ZDH_Scenarien

ABR_ZDH_EIN

B_Eingabe_Session

B_Anfrage_Ergebnisse

ABR_CLIENT

B_Init

B_Session_Eingabe

B_Anforderung_Inputdateien

B_Rechnungsstatus

B_Data_Repository

B_Ergebnismanager

.4

B_Arbeitsdaten

manager.2

B_Sessionmanager

.1

B_Rechnungs

durchfuehrung.3

Spec

Change-Requests




Submodell SE 2 (Entwurf) im ABRKFUe

Grobentwurf der Architektur des ABR-Systems

Erstellung der Rahmenkonzeption der Architektur als Word-Dokumente

Entwurf der Architektur mittels UML und Rational Rose und Bestimmung der einzelnen Dienste

Entwurf eines Kommunikationsmodells mittels UML und OCL

Object services

application objects

service service

SAL

service

SAL

KB

DM

Object Request Broker (ORB)

common facilities

Client Interface admin agent

RepositoryServiceStrategie

ServiceWorkflow Service

RessourceService

SAL

SALSAL

SALSALSAL SAL

Rahmen-konzeption

I - III

ScatteredData

- nrOfValues : Integer

Data(from System)

EdgeGrid

- dimension : Integer = 1

SurfaceGrid

- dimension = 2

SpaceGrid

- dimension : Integer = 3

Length

GridData

- gridConnection : enum {centered, staggered, c_class}

SpaceDirection

- nrOfMeshs : Integer- spacing : enum {uniform, varying}

+x1

+x2+x2

+x1

+x1+x3

0..1

+meshWidth

0..1

0..10..1

IsDescribedBy

IsDefinedOnTime IsDefinedOnSpace

Length LengthIsTimeStepOf

Time

ComputationTime

- nrOfTimeSteps : Integer

+timeStepWidth

TimeStep

1 1..*1 1..*

VolumetricDataQualitativeData QuantitativeData

- dataType : enum {scalar, vector, array}- physicalQuantity : String- unit : String

GeoPoint

- referenceSystem : enum {GK, UTM} = GK

+h +r

ComputationSpace

- dimension : Integer- gridType : enum {cartesian,uniform,rectilinear,regular}

+geoReferenceTimePeriod

- start : Date- end : Date

Group

0..*0..*

ScientificData

- description : String

0..*0..*

IsDefinedOnGroup

Raumbezug

Zeitbezug

Gruppenbezug

Daten

: C G e t P r o p o s e d V a l u e sF o r G e o s t r o p h i c W in d : C I

: C R e q u e s tM a n a g e r : D S : S S : W F S

: C D a t aM a n a g e r

d o J o b ( )

g e t P r o p o s e d V a l u e s F o r G e o s t r o p h i c W i n d ( s t d : : s t r in g , c o n s t O N T : : A B R : : T im e S t e p N u m b e r & , O N T : : A B R : : G e o s t r o p h i c W i n d * , O N T : : S y s t e m : : S A L C o n t a i n e r * , O N T : : S y s t e m : : I s L o c a t e d I n * , O N T : : S y s t e m : : E R R O R & )

G e t d a t a o u t o f t h e s c e n a r i o f o r m

G e t W o r k fl o w

E x e c u t e W o r k fl o w

c h e c k S i m S e s s io n ( s t d : : s t r i n g , s t d : : s t r in g , O N T : : S y s t e m : : E R R O R & )




Submodell SE 3 im ABRKFUe

Erstellung der Lastenhefte für die verschiedenen Dienste (Software-Komponenten) als Text-Dokumente

Erstellung der Pflichtenhefte für die verschiedenen Dienste (Software-Komponenten) als Text-Dokumente

Erstellung der Systemmodelle für die verschiedenen Dienste (Software-Komponenten) mittels Use-Cases in Rational Rose

LastenheftDienst x

PflichtenheftDienst x

ZDH GetAndSetZdhData

<<calls>>

Protokolle ausliefern(DeliverReports)

Protokolle erstellen und verwalten (ManageReports)

<<uses>>

<<uses>>

Protokoll-Modus ändern(ChangeReportMode)

<<uses>>

External Agent

Protokoll-Level ändern (ChangeReportLevel)

<<uses>>




Submodell SE 4(-SW) im ABRKFUe

Erstellung der Systemarchitektur der verschiedenen Dienste mittels UML, Powerpoint-Grafiken und Text-Dokumenten

Erstellung der Dienstleistungs-beschreibungen aller Dienstleistungen der Dienste unter Verwendung des Kommunikations-modells als Text-Dokumente

Dienstleistungs-beschreibung

Dienst x

System-architekturDienst x

S A L

Z D H - K e r n d i e n s t

b e n u t z t

D e b i s - Z D H

P r o t o k o l l i e r u n g

S c h n i t t s t e l l e 1





main SAL ReportComponent

: (CDebisZDH)

Instantiation/Initialisation

1:

2:

ZDH Core Component

4:

3:

1.1.1 Allgemein

Dienstleistungsname nuclideData

Beschreibung Abfrage nach Nukliden und ihren Eigenschaften in Abhängigkeit vomDatenbanktyp. /F20/.

1.1.2 Informationsobjekte (Ausgangszustand)

Beschreibung der einzelnen Informationsobjekte (<Name> innerhalb der Tabelle eindeutig!):

Name Informationsklasse Attributliste Nebenbedingung(en)

dbType ONT::ABR::ZDHDataBase type

1.1.3 Informationsobjekte (Ergebniszustand)

Beschreibung der einzelnen Informationsobjekte (<Name> innerhalb der Tabelle eindeutig!):

Name Informationsklasse Attributliste Nebenbedingung(en)

nuclideDataTable ONT::ABR::NuclidePropertiesTable

nuclideDataContai-ner

ONT::System::SALContainer STRING: ShortName

REAL: HalfLife [d]

STRING: Predecessor

REAL: TransitionProbability

STRING: Prepredecessor

REAL: PreTransitionProbability

STRING: NuclideGroupID

Vorgänger und Vorvorgänger der Nuklide beim Zerfall sind durch deren Nuklid-IDs angegeben. Die zugehörigen Übergangs-wahrscheinlichkeiten von Vorgänger zu Nuklid (TransitionProbability) und von Vorvorgänger zu Vorgänger (PreTransitionPro-bability) sind als Zahlen zwischen 0 und 1 gegeben.

NuclideGroup gibt an, zu welcher Nuklidgruppe das Nuklid gehört.

Beschreibung benötigter Beziehungen zwischen den Informationsobjekten:

Beziehung von Name zu Name Beschreibung

ONT::System::IsLocatedIn nuclideDataTable nuclideDataContainer





Entwurf der Dienste mittels UML und Rational Rose

Erstellung der Komponenten-spezifikationen der Dienste als Text-Dokumente aus dem Entwurf

Erstellung der Testspezifikation für die verschiedenen Dienste

Komponenten-spezifikation

Dienst x

Test-spezifikation

Dienst x

CSAL_Job(from sal)

CZDH_ABR(f ro m InterfaceZDH_ ABR)

CGetZdhDataJob

$ s_rwMutex : AXT_RWMutex$ s_lKeepSessionDataForMinutes : unsigned long = 0$ s_pTidyUpThread : omni_thread*

getPSessionData()tidyUp()

0..* 10..*

#$s_ZDH_ABR

1

CSimulationSessionData

+$s_ses sionDataMap

0..*

simulationSessionID : std::string0..*

0..*

simulationSessionID : std::string0..*

CGetMMIDefaults

doJob()

CSetMMIDefaults

doJob()

CClearMMIDefaults

doJob()

CGetDefaults

doJob()

CSetDefaults

doJob()

CClearDefaults

doJob()

CGetZDHMeasurements

CZDH_ABR(from InterfaceZDH_ABR)

CSimulationSessionDataCGetZdhDataJob

getPSessionData()tidyUp()

10..*

#$s_ZDH_ABR

10..*

0..*simulationSessionID : std::string

0..* +$s_sess ionDataMap0..*

0..*

simulationSessionID : std::string

CSAL_Job(from sal)

CGetMonitoringAreas

doJob()

CGetNuclideGroups

doJob()

CGetNucl ideData

doJob()

CGetPowerPlantData

doJob()

CGetPossibleEmissionPoints

doJob()

CGetOperationTime

doJob()

CGetDecayTime

doJob()

CGetNuclideInventory

doJob()

lfd.Nr.

Prüffälle für Anfrage nach Liste der Überwachungsbereiche Ref.Pfl.

Ref.Prüfpr.

1.1 für einen gültigen DB-Typ1.2 für einen ungültigen DB-Typ1.3 Fehlende Input-Informationsobjekte

lfd.Nr.

Prüffälle für Anfrage nach Liste der Überwachungsbereichefür einen gültigen DB-Typ

Ref.Pfl.

Ref.Prüfpr.

1.1.1 ZDH verfügbar1.1.2 ZDH nicht verfügbar

lfd.Nr.

Prüffälle für Anfrage nach Nukliddaten Ref.Pfl.

Ref.Prüfpr.


lfd.Nr.

Prüffälle für Anfrage nach Nukliddaten für einen gültigenDB-Typ

Ref.Pfl.

Ref.Prüfpr.


lfd.Nr.

Prüffälle für Anfrage nach Liste der Nuklidgruppen Ref.Pfl.

Ref.Prüfpr.


lfd.Nr.

Prüffälle für Anfrage nach Liste der Nuklidgruppen für einengültigen DB-Typ

Ref.Pfl.

Ref.Prüfpr.






Implementierung der verschiedenen Komponenten der einzelnen Dienste in C++ und Fortran

Durchführung von Tests für die jeweiligen Komponenten (Modultests)





Integration der einzelnen Komponenten zu Diensten

Erstellung von Testprozeduren für alle Dienste entsprechend der Testspezifikation der Dienste

Durchführung von Tests für alle Dienste entsprechend der Testspezifikation der Dienste

Erstellung von Testprotokollen als Text-Dokumente

Test-protokollDienst x

Test-prozeduren

Dienst x

1.1.1 Test Prozedur 227

1.1.1.1 Kurzbeschreibung

Es wird eine Diagnose-Rechnung durchgeführt wobei die Fertigstellung der Teilreports gemeldet werdenund aus diesen heraus die Teilreports dargestellt werden

1.1.1.2 Voraussetzungen

ABR-System läuft

Benutzer ist am KFUe-Klienten auf der operationellen Datenbank eingeloggt und mit dem ABR-Server verbunden

1.1.1.3 Prozedurbeschreibung

Test-schritt

Ort Aktion Ort Reaktion Item(s) Bemerkung

1. KFUe-Klient Auswahl Menü Ausbreitungsrechnung ->Neues Szenario Kurzeit-ABR

ABR-Server

KFUe-Klient

Erzeugung der Simulationssession (CM)Beschaffung von Vorschlagswerten für dieerste Maske

Eingabemaske 1: Grunddaten erscheint

11.2 Erzeugung derSimSession mitEnterprise Manager(TabellenCM_SimSession undCM_TempScen)überprüfen

2. KFUe-Klient Eingabe der Grunddaten (RechnungstypDiagnose). Weitere Parameter derKurzzeitausbreitungsrechnung eingebenund/oder vorgeschlagene Daten ändernund mit <OK>-Button bestätigen.

ABR-Server

KFUe-Klient

Konsistenzprüfung der Eingaben der 1.Maske und Eintrag ins Szenario.Beschaffung von Vorschlagswerten für diezweite Maske

Eingabemaske 2 : Emissionsparametererscheint

11.2 Ggf nochmals aktuelleSimSession mitEnterprise Managerprüfen.

DV-PROJEKTAKTE ATS-Prüfprotokoll

Sachgebiet Projektbezeichnung Phase Verfasser Datum Seite

Abt. WN ABRKFUe Integration MW / KD 19.10.2001 1/1

Dokumenten-Nr. Ap001-2001KE-v0100 Verantwortlich Dr. Michael Weigele

1 TestbeschreibungTestitem: 1.1

Prüfprozedur: 101

Systemversion: 1.0.0

Verwendete Testwerkzeuge: DienstManager, WinABRAdmin

Testbeginn (Datum und Uhrzeit): 19.10.2001, 18:12

Testende (Datum und Uhrzeit): 19.10.2001, 18:14

Kurzbeschreibung:

Das System wird zum erstenmal gestartet.

2 Testdurchführung

2.1 Zustand zu Beginn des TestsABR-System ist installiert

Das System ist jungfräulich

2.2 TesteingabenDienst ABR-Watchdog wurde im Dienste-Manager ausgewählt und der Dienst gestartet.

2.3 BemerkungenKeine

2.4 Zustand am Ende des TestsDas ABR-System läuft

2.5 TestauswertungDer WinABRAdmin zeigt an, daß alle Dienste laufen.

3 TestergebnisAbnahme des Tests: Bestanden ohne Einschränkung

Bestanden mit Einschränkung

Nicht bestanden




Submodell SE 8 im ABRKFUe

Integration der Dienste zum ABR-System

Test des ABR-Systems standalone

Bereitstellung einer Abnahmetest-spezifikation (ATS) des ABR-Systems für den Auftraggeber als Text-Dokument

ATS für dasABR-System

Inhaltsverzeichnis

Abbildungsverzeichnis .............................................................................................................................6

Tabellenverzeichnis..................................................................................................................................7

Änderungsnachweis .................................................................................................................................8

1 Einleitung ..........................................................................................................................................9

2 Nachzuweisende Funktionen..........................................................................................................10

2.1 Systemverhalten ......................................................................................................................10

2.2 Bedienung über KFUe-Klient ...................................................................................................10

2.3 Automatische Simulation .........................................................................................................10

2.4 Zusätzliche wichtige Funktionalitäten ......................................................................................10

2.5 Zusammenspiel mit der Simulationsdatenbank.......................................................................10

3 Testumgebung ................................................................................................................................11

3.1 Ort ............................................................................................................................................11

3.2 Hardwareumgebung ................................................................................................................11

3.3 Systemsoftware .......................................................................................................................12

3.4 Datenbasis ...............................................................................................................................13

3.5 Anwendungsprogramme..........................................................................................................13

3.6 Testprogramme (Hilfsmittel) ....................................................................................................15

3.7 Testkonfiguration .....................................................................................................................16

4 Testmethoden und Vorgehensweise ..............................................................................................17

4.1 Ablauf der Abnahme ................................................................................................................17

4.1.1 Systemvalidierung ............................................................................................................17

4.1.2 Vorbereitung .....................................................................................................................17

4.1.3 Vorbesprechung ...............................................................................................................17

4.1.4 Durchführung....................................................................................................................18

4.1.5 Abschlußbesprechung......................................................................................................18

4.2 Dokumentation der Abnahme..................................................................................................18

4.2.1 Protokollierung der Testprozeduren .................................................................................18

4.2.2 Globaler Testbericht .........................................................................................................19

4.2.3 Abnahmeprotokoll.............................................................................................................19

5 Testitems.........................................................................................................................................20

5.1 Systemverhalten ......................................................................................................................20

5.1.1 Hochfahren des Systems .................................................................................................20

5.2 Bedienung über KFUe-Klient ...................................................................................................20

5.2.1 Anmelden und Verwalten von KFUe-Klienten ..................................................................21

5.2.2 Diagnose-Rechnung mit Vorschlägen aus dem System..................................................22

5.2.3 MMI-Prognose-Rechnung mit Vorschlägen aus dem System .........................................22




Submodell SE 9 im ABRKFUe Installation des Systems

im Umfeld beim Auftraggeber

Durchführung und Protokollierung der Abnahme auf der Basis der ATS

Einführung des Auftraggebers in den Umgang mit dem System

Erstellung von System- und Benutzerhandbuch

Wartung und Pflege (Fehlerbeseitigung, ...)

Globaler TestberichtTest-

protokollTestfall x.x

ATS-Fehlerliste

Abnahme-erklärung

Benutzer-handbuch

System-handbuch




Handhabung des Submodells SE in ABRKFUe

SE 1 als Wasserfallprozess, Änderungen mittel Change-Requests SE 2 begonnen als Wasserfallprozess, spätere Erweiterungen des

Kommunikationsprozesses erfolgten iterativ-inkrementell SE 3 begonnen als Wasserfallprozess, spätere Modifikationen

erfolgten iterativ SE 4 begonnen als Wasserfallprozess, spätere Modifikationen

erfolgten iterativ-inkrementell SE 5 begonnen als Wasserfallprozess, spätere Modifikationen

erfolgten iterativ-inkrementell SE 6 erfolgte zum Teil als Wasserfallprozess, als auch zum Teil

iterativ-inkrementell SE 7 erfolgte iterativ-inkrementell SE 8 erfolgte iterativ-inkrementell SE 9 als Abschluss entsprechend den Notwendigkeiten




Was wir heute anders machen würdenDie SE Umgebung des Jahres 2003 am IKE

Elemente der SE Umgebung Omondo als Casetool zur Erstellung von UML Diagrammen Eclipse als Entwicklungsumgebung für Java Junit testframework CVS zum Produktmanagement und zur Integration Framework SIMPLAT als Basis der Implementierung Cocoon zur Publikation im Netz

Eine Einführung in die SE Umgebung am IKE liefert Ihnen das Praktikum Simulation komplexer technischer Anlagen

Es ist primär dafür gedacht, Sie in diese Umgebung und ihre Tools einzuführen und Ihnen das Finden und Beherrschen Ihrer Rolle zu ermöglichen




Submodell Konfigurationsmanagement

KM erfolgt am IKE durch CVSDurch Anlegen der Projektstruktur werden die weiteren Aufgaben weitgehend automatisch erledigt

KM-Initialisierung

Konfigurations-verwaltung

KM-Berichts-wesen

Änderungs-management

Datensicherung




KM am IKE

Konfigurationsmanagement erfolgt am IKE auf Basis von CVS Folgende Projektstruktur hat sich bewährt




Risikomanagement - Beispiele aus ABRKFUe

Fachlicher Art Aufwand, Termine

Kosten Äußere Einflüsse

Risiken:

Fachlicher Art:

Zu optimistische Einschätzung bzgl. Umsetzbarkeit und Tragfähigkeit von Konzepten

Aufwand, Termine, Kosten:

Der Aufwand bis zur entgültigen Fertigstellung einer SW-Einheit wird unterschätzt (95% fertig Problem)

Von außen vorgegebene Termine passen nicht zur Umsetzung Mitarbeiterfähigkeiten und Kenntnisse passen nicht zu den Aufgaben

Äußere Einflüsse: Konkurs von Unterauftragnehmer Einstellung des Supports für Basistechnologien und Plattformen




Risikomanagement - Erfahrungen aus ABRKFUe

Risiken sichtbar machen über den gesamten Projektlebenszyklus Risikoanalyse in regelmäßigen Abständen, ab Beginn eines

Projektes aktuelle Planzahlen und Plandaten mit regelmäßigen

Messungen vergleichen

Die größten Risiken frühzeitig angehen Regelmäßige Beobachtung der Entwicklungen im Umfeld

des eigenen Tätigkeitsbereiches Verwendung eines geeigneten Vorgehensmodells Regelmäßige Weiterqualifizierung des Mitarbeiterstammes

Risikoorientierte Vorgehensweise:




Templates für Produkte

Spezifikation - oft Arbeitsprogramm aus Antrag

Projekthandbuch Change RequestKomponenten

Lastenheft Pflichtenheft Spezifikation Testspezifikation Testprozedur

Testprotokoll

Abnahmetests Spezifikation Protokoll Fehlerliste Testbericht Abnahmeerklärung

Benutzerhandbuch Systemhandbuch Abschlussbericht

Im folgenden werden bewährte Strukturen für typische Produkte angegeben. Sie müssen sowohl an die Anforderungen der Auftraggeber als auch an die Technologieentwicklung am IKE angepasst werden. Alle Produkte können sowohl ins Intranet als auch bei Bedarf ins web gestellt werden:




Diese Fragen sollten Sie jetzt beantworten können

Welche Schritte sind bei Planung und Durchführung eines Projektes am IKE zu beachten

Wo findet man geeignete Vorlagen Warum ist Qualitätssicherung eine Aufgabe, die zu Beginn des

Projektes angegangen werden sollte Welche Rollen müssen besetzt werden und wie ertüchtigt man

vorhandene Mitarbeiter/innen

Documents

Universität Stuttgart Institut für Kernenergetik und Energiesysteme LE 3.1 ProzessqualitätLM 5 V-Modell-AnwendungenFolie 1 LE3-1-5-1 Inhalt und Vorbemerkungen