1Vorlesung Automatisierungsprojekte Seite 3/1 Übersicht Produktzyklus Vorphasen Projektgründe ...

1Vorlesung Automatisierungsprojekte Seite 3/1

Übersicht Produktzyklus

Vorphasen Projektgründe Machbarkeit Kosten/Nutzen-Analyse Lastenheft

• Aufbau• Requirement-Engineering

BeschreibungsmittelEntwurfsmethodenEntwurfswerkzeuge

AngebotserstellungSystemerstellung/Entwicklung

Pflichtenheft Systementwurf Softwareentwurf Implementierung Systemintegration Test und Abnahme

Systempflege

Qu

alitätssiche

rung

Ko

nfigura

tion

sm

an

age

me

nt

Pro

jektm

ana

gem

ent


Zweck

Lastenheft• Projektziele bzw. Anforderungen werden aus der Sicht des Kunden oder Anwenders definiert und beschrieben.• Projektziele werden in Form von „Requirements“ vorgegeben.• Darstellung gegenwärtiger Zustand, allgemeine Zielsetzung und Voraussetzungen

Pflichtenheftwird in Abstimmung mit dem Kunden vom Auftragnehmer erstellt.

• Verfeinerung der Anforderungen• Darstellung der Lösungsansätze.

Lastenheft Projektvorphasen


Aufbau

Lastenheft-Bestandteile• Ist-Zustand• Zielsetzung• Voraussetzungen

Einzuhaltende Vorschriften und Richtlinien (z.B. VDI/DIN usw.)Wartung, Reparatur, Qualitätssicherung (V-Modell, ISO 9000 usw.)örtliche GegebenheitenAnkopplung an bestehende Geräte (Systemverbund)

• Technische Anforderungen (Requirements) für Normalbetrieb• Technische Anforderungen (Requirements) für Sonderbetrieb (z.B. Systemausfälle)• Sonstige Anforderungen (Dokumentation, Preislimit, Bedienung, Leistungsdaten, Störsicherheit, Umgebungs- und Betriebsbedingungen)



Ist-Zustand: Stand der Technik

Lastenheft DGS1 Analyse Ist-Zustand1.1 Actual Recording/Analysis

1.1.1 Actual Recording1.1.1.1 Integration of the system into the organisational

structureA/c are required to park in a prescribed position to ensure

required clearance from other a/c, precise positioning for passenger loading facilities andwith respect to installations for refuelling, electric ground

power, water, ground communication lines, compressed air and to

ground vehicle lanes for safe and efficient operation.Guidance by marshallers in earlier times, today more high sophisticated

electronic systems to automate the process. On airports with no aerobridges: apron docking guidance systems. Other airports need more sophisticated systems: visual docking guidance systems.

A/c stand centreline lighting adequate for initiate the turn-on and take up a position on the centreline, but not for the necessary azimuth accuracy of nose-in stands with aerobridges. Further, stopping guidance is essential. ...



Ist-Zustand: Stand der Technik

Lastenheft DGS1 Analyse Ist-Zustand1.1 Actual Recording/Analysis

1.1.1 Actual Recording1.1.1.1 Integration of the system into the organisational

structure... A typical docking guidance system consists of a sensor which detects

the aircraft pose and a display, visible to the pilot, which provides guidance signals to the pilot.

Additionally such systems are integrated into a network of DGSs. Opportunity for central control.DGS can start to operate automatically if the central position is connected to a central airport information system, where gate schedules (gate, expected time, block on time, a/c type, ...) are contained. The DGS returns block on and block off times to the central information system, which can be used to calculate the bills automatically.

1.1.1.2 Available EquipmentInduction Based Measurement ...Moiré Effect and Microwave Radar Based Measurement ...Laser Based 3D Measurement of Spatial GeometrySystems on the market



Zielsetzung:Modellierung der Umwelt eines Projektes mittels Geschäftsprozessen und Akteuren

Produkt als „Black Box“1. Akteure identifizieren und beschreiben: Umweltdiagramm

Akteur (actor) ist aktiv und unmittelbar am Geschehen bet.

Docking Guidance SystemGround

personnel

Central personnel

Aircraft Aircraftpilot

CentralMonitoring

andSurveillance

System

Situation GuidanceInformation

A/c typeEmer-gency,Release,Lock,Chocks on

Status......

... ...



Zielsetzung:2. Geschäftsprozesse identifizieren und benennen

• Basis: Akteure und Datenflüsse• Geschäftsprozess (use case): Mehrere zusammenhängende Aufgaben eines Akteurs zur Erreichung eines Ziels bzw. Ergebnisses• Geschäftsprozessdiagramm (use case diagram)

Aircraft Aircraftpilot

Central personnelDGS

Positionanfahren

Statuszuweisen



Zielsetzung:Umwelt eines Produkts modellieren durch Schnittstellen und

DatenflüsseUmweltmodell: Quellen und Senken von Datenflüssen

1. Schnittstellen identifizierenSchnittstelle kann Informationsquelle oder –senke seinAngabe der ursprünglichen Quelle oder Senke

2. Datenflüsse identifizieren und benennen

Central personnelAircraftpilot

Central personnelAircraftpilot DGS

Control commands

statioccupancy

guidanceverification

info




Datenflüsse

Beispiel DGS



Zielsetzung:Umwelt eines Produkts modellieren: Werkzeug z.B. Rational Rose



Beispiel Handhabungssystem des Automatisierungslabors:Umweltdiagramm

Geschäftsprozesse (use cases)

Umweltmodell

Autolabor Handling System (AHS)User

commands

stati

User

AHSNot-Aus

behandeln

Transportdurchführen

Fehlerbehandeln

Glossar:User commands: Start, Auto/Manu, Emergency stopSystem stati: No item, ......

AutolaborHandling system

User RobotRobot position,

robot stati

actuatorsignals

User commands

Systemstati



RequirementsLastenheft DGS: Requirements

Purpose of the SystemThe DGS has to be designed to guide the approaching aircraft in the last phase of taxiing across the apron until stop at the assigned gate. The DGS shall simplify and speed up the docking procedure and minimize the ground time of the aircraft. ...

System description ...Regular procedure ...Deviations from required position ... Malfunction ...Cabling and equipment ...System configurations ...Time schedules ...Documentation ...Training ...Maintenance ...Acceptance tests ...Mismatch/reliabilty probability ...Reference specifications and standards



RequirementsAnforderungen (Requirements) im Lastenheft DGS

Zweck und Nutzen des Systems Externe Einbindung und interne Funktionen Funktionalität im Normalfall inkl. Genauigkeit, Geschwindigkeit Einsatz-Umweltbedingungen Fehlfunktionserkennung und –behandlung, Validierung und Diagnose Bedienschnittstellen Kalibrierung Gerätschaften und Verkabelung Systemkonfigurationen Zeitplanung Dokumentation Training Maintenance und System-Update Abnahmetests Zuverlässigkeit und Verfügbarkeit Referenzspezifikationen und Normen



Sonstige AnforderungenWeitere mögliche Vorschriften

VDI/VDE-RichlinienCE-KennzeichnungElektrische Schutzklassen

explosionsgeschütztspritzwassergeschütztTemperaturbedingungen

Betriebliche Zulassungen, z.B. BerufsgenossenschaftenGewährleistungsbestimmungen

Weitere mögliche AnforderungenVertriebliche Randbedingungen

Weitere mögliche VoraussetzungenNachweis der Leistungsfähigkeit durch ReferenzprojekteBankbürgschaftenSchulungsverpflichtungen



Requirements: Overhead-Folien

Für jedes Requirement soll gelten:• Es muss ersichtlich sein, was erreicht werden soll (Nutzersicht).• Es muss die Erfordernisse treffen.• Es muss verständlich und klar beschrieben sein.• Es muss eindeutig in der Aussage sein.• Es muss überprüfbar (quantifizierbar) sein.• Es muss eindeutig identifizierbar sein.

Für die Gesamtheit aller Requirements (Requirement-Katalog) muss gelten:

• Vollständigkeit• Widerspruchsfreiheit• Redundanzfreiheit• Realisierbarkeit• Eventuell Priorisierung oder Versiongeplantheit



Formaler Aufbau von Requirements Definierte Grundlage und spätere Bezugspunkte

Realisierung z.B.:

RQ-Nummer sinnvoller Schlüssel

RQ-Titel kurz, aussagekräftig

Erläuterung präzise, verständlich, evtl. formal

Begründung ausreichend, nicht pauschal

Querbezüge bezogene, betroffene RQ



Werkzeuge, z.B.



Werkzeuge, z.B. JANUS/Process



Werkzeuge, z.B. JANUS/Process

V-Modellkonform



Vorphasen Projektgründe Machbarkeit Kosten/Nutzen-Analyse Lastenheft

• Aufbau• Requirement-Engineering

BeschreibungsmittelEntwurfsmethodenEntwurfswerkzeuge

AngebotserstellungSystemerstellung/Entwicklung

Pflichtenheft Systementwurf Softwareentwurf Implementierung Systemintegration Test und Abnahme

Systempflege

Qu

alitätssiche

rung

Ko

nfigura

tion

sm

an

age

me

nt

Pro

jektm

ana

gem

ent

Übersicht Produktzyklus


Requirement-Engineering

Aufstellen von Requirements: Requirement-Engineering

Komponenten des Requirement-Engineering

Entwurfsmethoden Vorgehensweise und Gliederungsschemabeim RQ-Engineering, z.B. OOA

Beschreibungsmittel Darstellungsweise der Ergebnisse des RQ-Engineering, z.B. UML

Entwurfswerkzeuge Rechnerunterstützung als Hilfsmittel fürDokumentation, Wiederverwendbarkeit,

Kommunikation, Aufwandsreduzierung und Fehlerüberprüfung, z.B. Rational RoseMeist voneinander abhängig, kein wirklich durchgehender Analyse- und Entwurfsprozess.


Anforderungen (Requirements): qualitative und quantitative Eigenschaften eines Produkts aus AuftraggebersichtSystemanalyse (Requirement-Engineering): Systematische Vorgehensweise zur Ermittlung der Anforderungen in einem iterativen Prozess

=> Definieren des Produkts• Anforderungen ermitteln• Anforderungen als fachliche Lösung modellieren• Anforderungen analysieren• Anforderungen u.U. animieren, simulieren, ausführen• Anforderungen verabschieden

Ziel: Produktmodell eindeutig vollständig konsistent

Requirement-Engineering


Funktionen• Funktionsbaum• Geschäfts- prozesse• Datenfluss- diagramm

Daten• Entity Relationship• Multidimensionale Datenmodellierung• Data Dictionary

Dynamik• Petri-Netz• Zustandsautomat• Kontrollstrukturen• Sequenzdiagramm

Benutzungs-oberfläche• Graphik-Editor• Kontrollstrukturen• Regeln

System

MaskengeneratorAss

oziat

ionsm

atrix

SA

RT-Erweiterung von SA

OO

A

Zu beschreibende Sichten und ihre Modellierung

Modellierung


Basiskonzepte der SW-Entwicklung: Übersicht

Funk-tions-baum

Ge-schäfts-prozess

Daten-fluss-dia-gramm

DataDictio-nary

EntityRelation-ship

Klassen-dia-gramm

Pseudo-code

Regeln Zu-stands-automat

Petri-Netz

Se-quenz-dia-gramm

Pro-gramm-Ablauf-plan

Strukto-gramm

Ent-schei-dungs-tabelle

Aktivi-täts-dia-gramm

Kollabo-rations-dia-gramm

Funktio-naleHierar-chie

Arbeits-ablauf

Infor-mations-fluss

Daten-struk-turen

Entitäts-typen u.Bezie-hungen

Klassen-struk-turen

Kontroll-struk-turen

Wenn-dann-Struk-turen

EndlicherAutomat

Neben-läufigeStruk-turen

Inter-aktions-struk-turen

Funktionale Sicht Datenorientierte Sicht

Objekt-orient.Sicht

Algo-rithm.Sicht

Regel-basierteSicht

ZustandsorientierteSicht

Szenario-basierteSicht

Konzepte und Sichten

Alte

rna

tive

No

tatio

ne

n

Hä

ufig

ve

rwe

nd

et

Se

lten

ve

rwe

nd

et

Modellierung


Auswahl Basiskonzepte und Modellierungskonzepte

Funktions-Baum

Zustands-automat

Sequenz-diagramm

Kollaborations-diagramm

Entscheidungs-tabelle

Regeln

Pseudo-code

Geschäfts-prozesse

Datenfluss-diagramm

Petri-Netz

EntityRelationship

Klassen-diagramm

DataDictionary

Strukto-gramm

Programm-ablaufplan

Definitionsphase

Entwurfsphase

Implementierungsphase

Wird eingesetzt in

Modellierung


Abbildung Anwendungsbereiche auf Basiskonzepte

Anwendungsbereich Komplexität von BasiskonzepteDaten Data Dictionary

Entity Relationship(Zustandsautomat)Klassendiagramm

Funktionen GeschäftsprozesseDatenflussdiagrammFunktionsbaum

Algorithmen PseudocodeProgrammablaufplanStruktogrammEntscheidungstabelleRegeln

Systemumgebung Datenflussdiagrammzeitabhängiges Petri-NetzVerhalten Zustandsautomat

AktivitätsdiagrammSequenzdiagrammKollaborationsdiagramm

Benutzungsoberfläche Grafische Spezifikation(Petri-Netz)(Zustandsautomat)KontrollstrukturenRegeln

ad

min

stra

tivE

chtz

eit

Te

chn

isch

-w

isse

nsc

ha

ftlic

h

Me

nsc

h-

Ma

sch

ine

-In

tera

ktio

n

Modellierung


Kombination der Basiskonzeptein OOA

EntityRelationship

Klassen-diagramm

Pseudo-code

Zustands-automat

Kollaborations-diagramm

Geschäfts-prozesse

Sequenz-diagramm

OOA 1990

EntitätstypenundBeziehungen

Klassen-strukturen

Kontroll-strukturen

EndlicherAutomat

Interaktions-strukturen

Arbeits-ablauf

A B

A B

A ist in B enthalten

A ist implizit in B enthalten

Modellierung

Petri-netz


Funktions-Baum

Datenfluss-diagramm

DataDictionary


Entscheidungs-bäume

Pseudo-code

SA 1979

FunktionaleHierarchie

Informations-fluss

Daten-strukturen

Kontroll-strukturen

Kombination der Basiskonzeptein SA

Modellierung


Funktions-Baum

Datenfluss-diagramm

DataDictionary


Entscheidungs-bäume

Pseudo-code

SA 1979

FunktionaleHierarchie

Informations-fluss

Daten-strukturen

Kontroll-strukturen

Kombination der Basiskonzeptein RT

EntityRelationship

EntitätstypenBeziehungen

Zustands-automat

EndlicherAutomat

RT 1987

Modellierung


Auswahl eines Konzeptsanhand der Graphiken

1. Anwendungsbereich des Produkts2. Zutreffen der zugeordneten Komplexitätsarten

Nein: Orientierung an den Komplexitätsarten3. Basiskonzepte wählen, die den Komplexitätsarten zugeordnet

sind4. Prüfen, ob kombinierte Methode mit ermittelten Basiskonzepten

vorhandenJa: Einsatz der MethodeNein: Basiskonzepte einsetzen

Beispiel DGS: Echtzeitanwendung mit komplexen Algorithmen, komplexer Systemumgebung und zeitabhängigem Verhalten.=> Eignung für Methode RT, (Petri-Netze), (OOA), (Sequenzdiagramme)

Modellierung

1Vorlesung Automatisierungsprojekte Seite 3/1 Übersicht Produktzyklus Vorphasen Projektgründe ...

Documents

Transcript of 1Vorlesung Automatisierungsprojekte Seite 3/1 Übersicht Produktzyklus Vorphasen Projektgründe ...