Dokumente eines IT-Projektes:
|
|
|
- Gundi Stieber
- vor 8 Jahren
- Abrufe
Transkript
1 Dokumente eines IT-Projektes: - Pflichtenheft & Co - [email protected] Fachbereich Informatik Paderborn,
2 Überlappendes Phasenschema Dokumente der einzelnen Phasen 2
3 1.1 Überlappendes Phasenschema 1.1 Überlap. Phasenschema Aufwand Weitere Modelle: -Code and Fix - Wasserfallmodell -V-Modell -Spiralmodell - zyklische Modell Zeit I Vorstudie V Implementierung und Test II Ist-Analyse VI Systemeinführung III Sollkonzept [VII Systembetrieb] IV Systementwurf Vgl. [Fischer et al. 02, S.323ff.] 3
4 1.2 Dokumente der einzelnen Phasen 1.2 Überblick Dokumente Vorstudie -> Durchführbarkeitsstudie Ist-Analyse -> Systembeschreibung und Systemabgrenzung -> Schwachstellenbericht -> Beginn des Glossars Sollkonzept -> Organisationsplan -> Pflichtenheft -> Kostenschätzung Systementwurf -> Systementwurf Implementierung und Test -> Programmcode -> Dokumentation -> Testfälle Systemeinführung -> Abschlussbericht 4
5 Programmcode Dokumentation Pflichtenheft 5
6 2.1 Programmcode und Dokumentation 2.1 Prg. Code / Dokumentation Programmcode ist das Produkt selbst wird von Gruppe erstellt CVS nötig Dokumentation Verständnis aller Beteiligten wird sichergestellt Vereinfacht Fehlersuche und Erweiterungen... Dokumentation wichtig 6
7 2.2 Pflichtenheft 2.2 Pflichtenheft Funktionsbeschreibung für das System (aus Sicht des Auftraggebers) Hardware- / Softwareumgebung Schnittstellen zu anderen betrieblichen Systemen Kompatibilitäten auf Hardware- oder Softwareebene Anbindung an bestimmte Netze bzw. Telekommunikationsdienstleistungen Sicherheitskriterien (z.b. Ausfallsicherheit, Backups) Serviceanforderungen (z.b. Hotline, obere Zeitschranke für Fehlerbehebung) Anforderungen an die Oberfläche Preislicher Rahmen für das System 7
8 2.2.1 Zielbestimmung und Produkteinsatz 2.2 Pflichtenheft Kopf: Projekt: Auftraggeber: Auftragnehmer: 1. Zielbestimmung Einleitung Hauptaufgabe wird festgelegt -> Grund für die Entwicklung Zielgruppe definieren (Vorwissen, Erfahrungen) 2. Produkteinsatz Einsatzbereich des Systems wird festgelegt Darstellung der systemrelevanten Abläufe Pflichtenheft: Reicko Heckel, Annika Wagner, Albert Zündorf 8
9 2.2.2 Beschreibung des Produkteinsatzes 2.2 Pflichtenheft 2. Produkteinsatz 2.1Beschreibung des Problembereichs Allgemein verständliche Beschreibung des Problembereichs Laien mit der Terminologie und den Zusammenhängen vertraut machen 2.2 Glossar Falls kein ausführliches Glossar (als eigenes Dokument) angelegt wird, hier die wichtigsten Begriffe erklären 2.3 Modell des Problembereichs (grafisch) Modell kann z.b. ein Klassendiagramm sein 2.4 Beschreibung des Geschäftsfeldes (kann entfallen) Darstellung der Geschäftsprozesse (Abläufe) z.b. mit Hilfe eines USE-Cases 9
10 2.2.2 Beschreibung des Produkteinsatzes (2) 2.2 Pflichtenheft 2. Produkteinsatz 2.1 Beschreibung des Problembereichs 2.2 Glossar 2.3 Modell des Problembereichs (grafisch) 2.4 Beschreibung des Geschäftsfeldes (kann entfallen) 2.5 Beschreibung der Geschäftsprozesse (kann entfallen) Genauere Beschreibung der Geschäftsprozesse Beschreibung mit Tabelle und/oder Aktivitätendiagramm Auslösendes Ereignis Ergebnis Mitwirkende <Handlung oder Zeitpunkt, wann der GP beginnt> <Was soll erreicht werden> <Rollenname der Beteiligten oder eines Systems> 10
11 2.2.3 Produktfunktionen 3. Produktfunktinen 2.2 Pflichtenheft Beschreibung der Funktionalitäten Jede Funktionalität lässt sich einem GP aus (2) zuordnen 3.1 Use Case Diagramme Überblick über die Funktionalitäten 3.2 Beschreibung zu <Use Case-ID>: <Use Case-Name> Charakterisierende Informationen Übergeordneter elementarer Geschäftsprozess: Ziel des Use Cases: Vorbedingungen: Nachbedingung bei erfolgreicher Ausführung: Beteiligter Nutzer: Auslösendes Ereignis: <Prozess-ID: <elemetarer Geschäftsprozess> (Verzweigung angeben) <Ausführliche Beschreibung des Zieles des Use Cases> <Was muss garantiert werden, damit der UC ausgeführt werden kann> <Was muss für eine erfolgreiche Ausführung des Use Cases sichergestellt werden> <Rollename> Beschreibung des Nutzers oder des Systems <Handlung oder Zeitpunkt, die Use Case auslöst> 11
12 2.2.3 Produktfunktionen (2) 2.2 Pflichtenheft 3.2 Beschreibung zu <Use Case-ID>: <Use Case-Name> Charakterisierende Informationen <Tabelle> (s.o.) Skizze / Screenshot der GUI Szenario für den Standardablauf (Erfolg) Schritt <Schrittnr.> Nutzer <Name des Nutzer> Beschreibung der Aktivität <Beschreibung dessen, was der Nutzer tut> GUIs für den Standardablauf des Use Cases: Skizze / Screenshot der GUI 12
13 2.2.3 Produktfunktionen (3) 2.2 Pflichtenheft 3.2 Beschreibung zu <Use Case-ID>: <Use Case-Name> Charakterisierende Informationen Szenario für den Standardablauf (Erfolg) Szenarien für die alternative Abläufe (Misserfolg oder Umweg) Schritt <Referenz auf Schrittnr. aus Standardablauf> Nutzer <Was verursacht den alternativen Ablauf> Beschreibung der Aktivität <Beschreibung der entsprechenden Aktivität> GUIs für alternative Abläufe des Use Cases: Skizze / Screenshot der GUI Beschreibung des allgemeinen Ablaufs Aktivitätsdiagramme zu den Abläufen aus dem vorherigen Abschnitt Offene Punkte Beschreibung dessen, was noch unklar ist 13
14 2.2.4 Produktcharakteristiken 2.2 Pflichtenheft 4. Beschreibung der nicht-funktionalen Anforderungen Charakteristiken oder Qualitäten, die das Produkt attraktiv machen und wodurch es sich von ähnlichen abhebt. Name: Typ: Beschreibung Zugeordneter(r) Use Case(s) <Kurze, eindeutige Bezeichnung> <Einen Typ aus der im Anhang definierten Liste auswählen> <Beschreibung in Sprache des Nutzers, die versucht Mehrdeutigkeiten zu vermeiden> <Use Case-ID> Typen: Use Effizienz Pflege Sicher Benutzbarkeitsanforderung Effizienzanforderungen Wartbarkeits- und Portierbarkeitsanforderungen Sicherheitsanforderungen Legal Gesetzliche Anforderungen 14
15 Literatur: IT Consulting Skript zur Veranstaltung Leena Suhl, Thomas Knechtel, Markus Toschläger Links: /WS0203/TSEI/Templates/Pflichtenheft-Template.pdf /ss2001/pm/dokumente/vorlagen/pflichtenheft.html 15
16 Vielen Danken für Eure Aufmerksamkeit! Fachbereich Informatik
Lastenheft (Universität Paderborn, Softwaretechnikpraktikum SS2006)
Lastenheft (Universität Paderborn, Softwaretechnikpraktikum SS2006) Alles, was in dieser Schriftart gesetzt ist, dient nur zur Erläuterung und sollte im fertigen Lastenheft nicht mehr auftauchen! Der Umfang
Pflichtenheft (Universität Paderborn, Softwaretechnikpraktikum SS2006)
Allgemeine Hinweise: Pflichtenheft (Universität Paderborn, Softwaretechnikpraktikum SS2006) Alles, was in dieser Schriftart gesetzt ist, dient nur zur Erläuterung und sollte im fertigen Pflichtenheft nicht
Projekt: <Hier den Namen des Projektes eingeben!> <Adresse> <Telefon / Fax> <Ansprechpartner>
Pflichtenheft Die Aufgabe des Pflichtenheftes ist es zu beschreiben, was die zu entwickelnde Software für den Anwender leisten soll. Diese Vorlage basiert auf der aus TSE I bekannten Vorlage. Projekt:
Pflichtenheft. (Universität Paderborn, Softwareentwurf WS 2004/2005) Entwicklung von Mississippi-Queen für PDAs
Pflichtenheft (Universität Paderborn, Softwareentwurf WS 2004/2005) Projekt: Entwicklung von Mississippi-Queen für PDAs Auftraggeber: Nils Bandener Gruppe 5, Dienstags 9:00-:00 Uhr, N3.206 Auftragnehmer:
Pflichtenheft (Universität Paderborn, Softwaretechnikpraktikum SS2006)
Allgemeine Hinweise: Pflichtenheft (Universität Paderborn, Softwaretechnikpraktikum SS2006) Alles, was in dieser Schriftart gesetzt ist, dient nur zur Erläuterung und sollte im fertigen Pflichtenheft nicht
Pflichtenheft (Universität Paderborn, Softwareentwurf WS 2004/2005)
Pflichtenheft (Universität Paderborn, Softwareentwurf WS 2004/2005) Projekt: Entwicklung von Mississippi-Queen für PDAs Auftraggeber: Nils Bandener Gruppe 5, Dienstags 9:00-11:00 Uhr, N3.206 Auftragnehmer:
Pflichtenheft Projekt Rollercoaster. Projektgruppe: Gruppenname Phasenverantwortlich: Müller-Langowski 15. April 2002
Pflichtenheft Projekt Rollercoaster Projektgruppe: Gruppenname Phasenverantwortlich: Müller-Langowski 15. April 2002 1 Inhaltsverzeichnis 1 Auftragnehmer 1 2 Auftraggeber 1 3 Zielbestimmung 2 3.1 Mußkriterien.......................................
Testdokument (Universität Paderborn, Softwaretechnikpraktikum SS2006)
Testdokument (Universität Paderborn, Softwaretechnikpraktikum SS2006) Alles, was in dieser Schriftart gesetzt ist, dient nur zur Erläuterung und sollte im fertigen Dokument nicht mehr enthalten sein! Projekt:
Phasenmodell. Problem stellung. Neue Anforderungen. Benutzerwünsche. Anforderungs analyse und - definition Systemmodell. Betrieb.
Phasenmodell Neue Anforderungen Problem stellung Benutzerwünsche Endprodukt Betrieb Anforderungs analyse und - definition Systemmodell Systemtest Integration Systementwurf Dokumentiertes Programm Systemspezifikation
Testen mit Use Cases. Chris Rupp Dr. Stefan Queins
Testen mit Use Cases Chris Rupp Dr. Stefan Queins Das Problem Requirements- Engineering Was kann passieren? Was ist das gewünschte Verhalten? Was soll ich testen? Welche Eingaben benötigt mein Testpfad?
Veranstaltung Systementwicklung Anforderungen Uwe H. Suhl Chris Bizer SS 2008 Unterschiedliches Verständnis von Anforderungen
Veranstaltung 10033013 Systementwicklung Anforderungen Uwe H. Suhl Chris Bizer SS 2008 Unterschiedliches Verständnis von Anforderungen 1 Anforderungsanalyse Anforderungsanalyse gliedert sich in folgende
2. Der Software-Entwicklungszyklus
2. Der Software-Entwicklungszyklus 2.1 Klassische Phasenmodelle 2.1.1 Wasserfallmodell 2.1.2 Rapid Prototyping 2.2 Objektorientierte Phasenmodelle 2.2.1 OOA / OOD / OOP 2.2.2 Iteratives Phasenmodell 2.2.3
Ereignis-basierter Test grafischer Benutzeroberflächen ein Erfahrungsbericht
29. Treffen der GI-Fachgruppe Test, & Verifikation von Software (TAV) 12. und 13. November 2009, FH Stralsund Thema: Testmanagement meets MBT Autoren: Fevzi Belli, Mutlu Beyazit, Axel Hollmann, Michael
CAE Grundlagen. Prof. Metzler 1
CAE Grundlagen Prof. Metzler 1 Prof. Metzler 2 Neue Anforderungen Problem stellung Benutzerwünsche Endprodukt Betrieb Anforderungs analyse und - definition Systemmodell Systemtest Integration Systementwurf
ER-Modelle zur klaren Begrifflichkeit bei der Testentwicklung
ER-Modelle zur klaren Begrifflichkeit bei der Testentwicklung Dr. Matthias Hamburg, German Testing Board e.v. Dr. Baris Güldali, s-lab - Universität Paderborn Paderborn, 15. Oktober 2015 GI-TAV Konferenz
Pflichtenheft Inhaltsverzeichnis. 1 Zielbestimmung Musskriterien Wunschkriterien Abgrenzungskriterien...
Pflichtenheft 17.05.2010 Inhaltsverzeichnis 1 Zielbestimmung 2 1.1 Musskriterien.................................. 2 1.2 Wunschkriterien................................ 3 1.3 Abgrenzungskriterien..............................
Analyse und Entwurf objektorientierter Systeme
objektorientierter Systeme Fachbereich der FHW Berlin Teil 2 Anforderungsmodellierung: Pflichtenheft und Geschäftsprozesse Modul WI111: Objektorientierte Programmierung Fachrichtung Wirtschaftsinformatik
Pflichtenheft. Software für Ansteuerung eines Moving-Heads mittels PCI-Card DMX512b
Pflichtenheft Software für Ansteuerung eines Moving-Heads mittels PCI-Card DM512b Produktname: Light-Jockey Auftraggeber: Softwarehaus Hofmann GmbH Zeisigweg 25 80307 München Auftragsnummer: 1001-Light
Ein Beispiel-Pflichtenheft
Ein Beispiel-Pflichtenheft 1. ZIELBESTIMMUNG 1.1 Musskriterien 1.2 Wunschkriterien 1.3 Abgrenzungskriterien 2. PRODUKTEINSATZ 2.1 Anwendungsbereiche 2.2 Zielgruppen 2.3 Betriebsbedingungen 3.PRODUKTÜBERSICHT
4. Übung zu Software Engineering
4. Übung zu Software Engineering WS 2007/2008 Aufgabe 8 Erstellen Sie für den aus Aufgabe 1 bekannten Function-Point-Kalkulator ein Pflichtenheft. Bitte begrenzen Sie dessen Umfang auf maximal 2 DIN A4
Software Engineering. 3. Analyse und Anforderungsmanagement
Software Engineering 3. Analyse und Anforderungsmanagement Gliederung Vorlesung Einführung V-Modell XT Analyse und Anforderungsmanagement Benutzungsoberflächen Architektur Entwurf Entwurfsmuster Persistenz
I. II. I. II. III. IV. I. II. III. I. II. III. IV. I. II. III. IV. V. I. II. III. IV. V. VI. I. II. I. II. III. I. II. I. II. I. II. I. II. III. I. II. III. IV. V. VI. VII. VIII.
Technologiepark 8 33100 Paderborn Telefon: 05251 / XX XX XX Mobil: 01XX / XX XX XX XX E-Mail: [email protected]
Technologiepark 8 33100 Paderborn Telefon: 05251 / XX XX XX Mobil: 01XX / XX XX XX XX E-Mail: [email protected] PIRAT Software Technologiepark 8 33100 Paderborn Universität Paderborn Institut für Informatik
Aufgabe 3 Erstellt am: Softwaretechnik Praktikum SS06 Verantwortliche: Irina Justus
Pflichtenheft Gliederung 1. Zielbestimmung 2. Produkteinsatz 3. Produktübersicht 4. Produktfunktionen 5. Produktdaten 6. Produktleistungen 7. Qualitätsanforderungen 8. Benutzeroberfläche 9. Nicht funktionale
[Hier klicken und Text eingeben] [Hier klicken und Text eingeben] Auftragsnummer: [Hier klicken und Text eingeben] Auftragnehmer:
Pflichtenheft Auftraggeber: Auftragsnummer: Auftragnehmer: Bearbeiter: Berlin, den (microtool GmbH, Berlin) Pflichtenheft Inhalt 1 Einleitung (Introduction) 3 1.1 Zielsetzung (Purpose) 3 1.2 Scope (Scope)
Projektplan. Transport TM. Projekt: Juniorprofessor Dr. Holger Giese
Projektplan (Universität Paderborn, Softwaretechnikpraktikum SS2005) Projekt: Transport TM Auftraggeber: Juniorprofessor Dr. Holger Giese Universität Paderborn Institut für Informatik Gebiet: Softwaretechnik
PSE Kick-off. Prof. Bernhard Beckert, Dr. Mattias Ulbrich, Alexander Weigl
PSE Kick-off Prof. Bernhard Beckert, Dr. Mattias Ulbrich, Alexander Weigl Institut für Theoretische Informatik Anwendungsorientierte formale Verifikation 07.11.2016 TOP Organisation Betreuer Zeitplan Wöchentliche
Autoren: Ronny Fauth, Michael Freyer Dokumentation: Christian Schulze. 1 Zielbestimmung 2. 2 Produkteinsatz 2. 4 Produktfunktionen 3.
Lehrstuhlverwaltung Inhaltsverzeichnis 1 Zielbestimmung 2 2 Produkteinsatz 2 3 Produktübersicht 2 4 Produktfunktionen 3 5 Produktdaten 7 6 Produktleistungen 8 7 Qualitätsanforderungen 8 8 Ergänzungen 8
Software- und Systementwicklung
Software- und Systementwicklung Seminar: Designing for Privacy 11.11.2009 Moritz Vossenberg Inhalt Vorgehensmodelle Wasserfallmodell V-Modell Phasen (Pflichtenheft) UML Klassendiagramm Sequenzdiagramm
Phasen der Softwareentwicklung
Frühe Dipl. Wirtsch. Ing. Alexander Werth 5-1 Phasen der Softwareentwicklung Problemdefinition Anforderungsanalyse Spezifikation Entwurf Implementation Erprobung Wartung 5-2 Problemdefinition Worum geht
Objektorientierte Analyse (OOA) Inhaltsübersicht
Inhaltsübersicht Einführung Anforderungen an die UML-Diagramme Verhalten: Use-Case-Diagramm Verhalten: Aktivitätsdiagramm Verhalten: Zustandsautomat Struktur: Klassendiagramm Seite 1 Einführung In der
1. Übung Softwaretechnik - Planungsphase -
1. Übung Softwaretechnik - Planungsphase - J. Härtwig, T. Riechert, T. Berger WS 2007/2008 1. Einführung Software-Management beauftragt Software-Prozess-Gruppe Projektleiter plant erstellt Prozess-Modelle
Inhalt. 1 Einführungsveranstaltung. 2 Pflichtenheft ANFORDERUNGSSPEZIFIKATION - GROBPLANUNG ANFORDERUNGSSPEZIFIKATION - SOLLKONZEPT
Inhalt ANFORDERUNGSSPEZIFIKATION - GROBPLANUNG 1 Einführungsveranstaltung 1.1 Ziel der Veranstaltung 1.2 Formaler Ablauf der Veranstaltung 1.3 Bewertungskriterien mittels Meilensteinen, Präsentationen
Vgl. Oestereich Kap 2.1 Seiten
Vgl. Oestereich Kap 2.1 Seiten 21-49. 1 Ein Use Case ist eine zeitlich ununterbrochene Interaktion (ein Arbeitsschritt). Use Case Namen bestehen aus einem Subjekt und einem Verb wie zum Beispiel Daten
Softwaretechnik 2015/2016
Softwaretechnik 2015/2016 PST Lehrstuhl Prof. Dr. Matthias Hölzl HAUPT-/ BACHELOR- SEMINAR ADAPTIVE SYSTEME PST Joschka PROF. DR. Rinke WIRSING 14. JUNI 2009 VORNAME NAME AGENDA Übung 11: 14.01.2016 Schon
Master-Arbeit. Titel der Arbeit. Betreuer: Matthias Splieth, M.Sc. Themensteller: Prof. Dr. Klaus Turowski
Master-Arbeit Titel der Arbeit Max Mustermann Magdeburg, 5. November 2012 Betreuer: Matthias Splieth, M.Sc. Themensteller: Prof. Dr. Klaus Turowski Otto-von-Guericke-Universität Magdeburg Magdeburg Research
Inhaltsverzeichnis. Teil I Einführung 13. Teil II Struktur 41. Vorwort 11
UML 2 für Studenten Inhaltsverzeichnis Vorwort 11 Teil I Einführung 13 Kapitel 1 UML (nicht nur) für Studenten 15 1.1 Zielgruppen 16 1.2 Konventionen 17 1.3 Abgrenzung 18 1.4 Aufbau dieses Buches 18 Kapitel
Mandatsverteilung für den Deutschen Bundestag
Mandatsverteilung für den Deutschen Bundestag Prof. Bernhard Beckert, Thorsten Bormer, Daniel Bruns 30. Oktober 2013 Institut für Theoretische Informatik Anwendungsorientierte Formale Verifikation 1 Bernhard
MDRE die nächste Generation des Requirements Engineerings
MDRE die nächste Generation des Requirements Engineerings Tom Krauß, GEBIT Solutions GmbH Copyright 2007 GEBIT Solutions Agenda Requirements Engineering heute eine Bestandsaufnahme Modell-Driven Requirements
Klausur. Softwareentwurf. 14. Februar 2011 Bearbeitungszeit: 120 Minuten
Klausur Softwareentwurf 14. Februar 2011 Bearbeitungszeit: 120 Minuten FG Datenbank- und Informationssysteme Prof. Dr. Gregor Engels unbedingt vollständig und lesbar ausfüllen! Vorname: Matrikelnummer:
Das diesem Dokument zugrundeliegende Vorhaben wurde mit Mitteln des Bundesministeriums für Bildung und Forschung unter dem Förderkennzeichen
Das diesem Dokument zugrundeliegende Vorhaben wurde mit Mitteln des Bundesministeriums für Bildung und Forschung unter dem Förderkennzeichen 16OH21005 gefördert. Die Verantwortung für den Inhalt dieser
PSE: Analysesoftware für soziale Netzwerke
PSE: Analysesoftware für soziale Netzwerke Präsentation des Pflichtenheftes IPD, Fakultät für Informatik, Lehrstuhl Prof. Böhm KIT Universität des Landes Baden-Württemberg und nationales Forschungszentrum
SOFTWAREPROJEKT (WI) Anforderungsanalyse. Projektveranstaltung im Wintersemester 2012/13 FG System- und Softwareengineering Dr.-Ing.
SOFTWAREPROJEKT (WI) Anforderungsanalyse Projektveranstaltung im Wintersemester 2012/13 FG System- und Softwareengineering Dr.-Ing. Ralph Maschotta Inhalt Das Pflichtenheft Das UML-Modellierungswerkzeug
1 EINLEITUNG PROJEKTABLAUF Allgemeine Zielsetzung Projektstruktur und Zeitplan ANFORDERUNGSANALYSE...
Inhaltsverzeichnis Inhaltsverzeichnis 1 EINLEITUNG... 1 2 PROJEKTABLAUF... 4 2.1 Allgemeine Zielsetzung... 4 2.2 Projektstruktur und Zeitplan... 4 3 ANFORDERUNGSANALYSE... 8 3.1 Der Prototyp des Anlagenmodells...
Software-Engineering
FH Wedel Prof. Dr. Sebastian Iwanowski SWE3 Folie 1 Software-Engineering Sebastian Iwanowski FH Wedel Kapitel 3: Softwareplanung FH Wedel Prof. Dr. Sebastian Iwanowski SWE3 Folie 2 Problem und Lösung Aufnehmen
- Prüfung - Prüfspezifikation für Anforderungen (Lastenheft)
- Prüfung - Prüfspezifikation für Anforderungen (Lastenheft) Projektbezeichnung Projektleiter Verantwortlich WiBe 4.0 Musterprojekt Odysseus Dr. Aristotelis Erstellt am 11.03.2005 10:11 Zuletzt geändert
PSE: Analysesoftware für Logistiknetzwerke
PSE: Analysesoftware für Logistiknetzwerke Phase 1 Das Pflichtenheft,, Lehrstuhl Prof. Böhm KIT Universität des Landes Baden-Württemberg und nationales Forschungszentrum in der Helmholtz-Gemeinschaft www.kit.edu
Einführung in die Programmierung der Schnittgrößenermittlung am Einfeldträger. 7.12.2012 J. Lange
Einführung in die Programmierung der Schnittgrößenermittlung am Einfeldträger 7.12.2012 J. Lange 1 Vorstellung Dr.-Ing. Johannes Lange Softwareentwicklung, Organisation Projekt-, Qualitätsmanagement CAD
Software Engineering Projekt. Pflichtenheft
Software Engineering Projekt Pflichtenheft Ziele eines Pflichtenheftes Festsetzung der Leistung und des Umfangs der Software Anforderungen Zugesicherter Funktionsumfang Zugesicherte Produktumgebung Risikovorbeugungsmaßnahme
Vgl. Kapitel 4 aus Systematisches Requirements Engineering, Christoph Ebert Vgl. Kapitel 4/5 aus Basiswissen Requirements Engineering, Klaus Pohl,
Vgl. Kapitel 4 aus Systematisches Requirements Engineering, Christoph Ebert Vgl. Kapitel 4/5 aus Basiswissen Requirements Engineering, Klaus Pohl, Chris Rupp Nachdem die Projekt-Vision und die Stakeholder
Inhaltsverzeichnis. Business Analysis und Requirements Engineering
sverzeichnis zu Business Analysis und Requirements Engineering von Peter Hruschka ISBN (Buch): 978-3-446-43807-1 ISBN (E-Book): 978-3-446-43862-0 Weitere Informationen und Bestellungen unter http://www.hanser-fachbuch.de/978-3-446-43807-1
CARL HANSER VERLAG. Mario Jeckle, Chris Rupp, Jürgen Hahn, Barbara Zengler, Stefan Queins. UML 2 glasklar
CARL HANSER VERLAG Mario Jeckle, Chris Rupp, Jürgen Hahn, Barbara Zengler, Stefan Queins UML 2 glasklar 3-446-22575-7 www.hanser.de Einleitung... 1 Liebe Leserin, lieber Leser... 1 Ihre Meinung ist uns
Architektur und Qualität. Tjard Köbberling
Architektur und Qualität Tjard Köbberling Gliederung Überblick Architektur und Qualität? Architekturentwurf Anforderungsanalyse Strukturierung Architekturbeschreibungen - Sichten Fallbeispiel 2 Architektur
Lastenheft Webinformationssystem V1.0
Lastenheft Webinformationssystem V1.0 1.Zielbestimmung: 1.1 Muss-Kriterien: Studenten und Mitarbeiter der Fakultät für Mathematik und Informatik der Universität Leipzig sollen mit dem Produkt über ein
Inhaltsverzeichnis. Teil I Grundlagen 1
xv Teil I Grundlagen 1 1 Modelle und Modellierung 3 1.1 Modelle, die uns umgeben.................................. 3 1.2 Modelltheorie........................................... 5 1.3 Ziele beim Einsatz
Dokumentationskonzept
1. Eigene Java Code Convention Dokumentationskonzept Soweit nichts Abweichendes angegeben, sind die Implementierer dazu gehalten, sich an die Regeln für guten Code aus den allgemeinen SUN Konventionen
Grundlagen des Software Engineering
Gustav Pomberger und Günther Blaschek Grundlagen des Software Engineering Prototyping und objektorientierte Software-Entwicklung Mit 101 Abbildungen Technische Universität Darmstadt FACHBEREICH INFORMATIK
Projektarbeit Java. 4-Gewinnt. Berner Fachhochschule. 2004, Labor für Technische Informatik
Berner Fachhochschule Hochschule für Technik und Informatik, HTI Fachbereich Elektro- und Informatik Labor für technische Informatik Projektarbeit Java 4-Gewinnt 2004, Labor für Technische Informatik Dateiname:
Phasen der Softwareentwicklung
Frühe Dipl. Wirtsch. Ing. Alexander Werth 5-1 Phasen der Softwareentwicklung Problemdefinition Anforderungsanalyse Spezifikation Entwurf Implementation Erprobung Wartung 5-2 Problemdefinition Worum geht
Projektmanagement. Dokument V 1.1. Oliver Lietz - Projektmanagement. Wie kommt es zu einem Projektauftrag? Ausführung
Projektmanagement Management- und Phasen-Modelle Vom Wasserfall bis Extreme Programming / Scrum Dokument V 1.1 Wie kommt es zu einem Projektauftrag? Auftraggeber Projekt-Idee / Ziele [Anforderungen/Spezifikation/
Technische Dokumentation
Technische Dokumentation Projektgruppe : Projektname: YOLO Stats.Keeper Projektmanager Chefdesigner Entwickler Dokumentationsmanager Waldemar Belikow Wojchiech Lesnianski Fatih Emin Sahin Alexander Kosares
Pflichtenheft. Softwareprojekt Simulation / Idea Engineering
Pflichtenheft Softwareprojekt Simulation / Idea Engineering Projekt: Autoren: Entwicklung einer interaktiven Nutzeroberfläche für ein Ideenbewertungsverfahren ggf. unter Verwendung einer bereits vorhandenen
Zusammenfassung der Vorlesung
Zusammenfassung der Vorlesung Die wichtigsten Punkte der Vorlesung waren... Dr. F. Sarre Wintersemester Wintersemester 20102013 / 2011 / 2014 Folie 307 Herausforderungen beim Projektmanagement Projektziel
Erstellung eines Pflichtenhefts (I)
2. Anforderungsanalyse Erstellung eines Pflichtenhefts (I) Annahme: Es liegt ein "gutes" Lastenheft vor Was fehlt noch? Details... gemeinsame Sprache Glossar gemeinsames Verständnis der Funktion Funkt.
Wann lohnt sich GUI- Testautomatisierung?
Wann lohnt sich GUI- Testautomatisierung? Martin Moser, Gregor Schmid Quality First Software GmbH [email protected] Tel: +49 8171 919870 2006-2007 Quality First Software GmbH 26.02.2007 1 Überblick Hintergrund
Anforderungsanalyse, Requirements Engineering
Anforderungsanalyse, Requirements Engineering, Lastenheft, Pflichtenheft, Spezifikation, Zielgruppen Natürliche Sprache, Formulare Pflichtenheft, an ein Pflichtenheft von Funktionale, nicht-funktionale
Sascha Schreier. Softwaretechnik: Übung 11.12.09
Sascha Schreier Softwaretechnik: Übung 11.12.09 Unklarheiten und Fragen Sascha Schreier 11.12.2009 # 2 Systementwurf: Objektentwurf + Einbettung in die Systemumgebung (Pakete, DB, GUI, ) So viele verschiedene
Softwareentwicklung OOA Videothek
Softwareentwicklung OOA Seite 1 von 8 Softwareentwicklung OOA thek Ein mögliches Vorgehen bei OOA soll im Rahmen einer Softwareentwicklung am Beispiel einer thek exemplarisch vorgestellt werden. 1. Systemidee
Use-Case-Template. Deliverable E1.1
Use-Case-Template Deliverable E1.1 Projekt USecureD Usable Security by Design Förderinitiative Einfach intuitiv Usability für den Mittelstand Förderkennzeichen 01MU14002 Arbeitspaket AP 1.1 Fälligkeit
Lastenheft Gruppe HK-03 erstellt am: Lastenheft
Gliederung 1.Zielbestimmung 2.Produkteinsatz 3.Produktübersicht 4. Produktfunktionen 4.1 Muss-Kriterien 4.2 Kann-Kriterien 5.Produktdaten 6.Produktleistungen 7.Qualitätsanforderungen 1.Zielbestimmung Das
Pflichtenheft Patientenbett-Verwaltung
Patientenbett-Verwaltung Verfasser: Roman B., Marcel H., Micha H., Markus S. Projektart: MySQL Datenbank mit grafischer Benutzeroberfläche (Java), aus den Modulen DB, SWE und D&K Im Auftrag und Betreuung
Wann lohnt sich GUI- Testautomatisierung?
Wann lohnt sich GUI- Testautomatisierung? Martin Moser, Gregor Schmid Quality First Software GmbH [email protected] Tel: +49 8171 919870 2006-2007 Quality First Software GmbH 26.02.2007 1 Überblick Hintergrund
Objektorientierte Analyse und Design mit der Unified Modelling Language (UML) Sandra Meißl
Objektorientierte Analyse und Design mit der Unified Modelling Language (UML) Sandra Meißl 26.07.21 Themenübersicht Objektorientierte Software-Entwicklung Objektorientierte Analyse und Design OOA OOD Objektorientierte
Pflichtenheft Software-Projekt: AutoEdit Add On
Pflichtenheft Software-Projekt: AutoEdit Add On Mitglieder: Benjamin Klein, Tobias Schumann, Balduin Laubisch, Peter Gräf, Kay Gabler Datum: 11.2.2009 Inhaltsverzeichnis 1. Ziele 1.1 Musskriterien 1.2
Use Cases. KP Ludwig John. Use Cases
Voraussetzung Umfang des Projektes und Nutzersituation sind definiert in Form von: Konzept (Projektziel, Funktionen) Personas (Zielgruppe) Nutzungskontext (Technik, Umgebung, Zeitrahmen) Funktionen (Interessen
Sonstige Assets. Assets über T-SQL Abfragen anlegen
Sonstige Assets Assets über T-SQL Abfragen anlegen TITEL Sonstige Assets AUTOR Docusnap Consulting DATUM 06.10.2017 VERSION 1.0 Die Weitergabe, sowie Vervielfältigung dieser Unterlage, auch von Teilen,
Software-Engineering Grundlagen des Software-Engineering
Software-Engineering Grundlagen des Software-Engineering 3 Definitionsphase Spezifikationen (Specification / Analysis Phase) 3.1 Pflichtenheft Übungen Prof. Dr. Rolf Dornberger Software-Engineering: 3
Objektorientierte Systementwicklung
Karl-Heinz Rau Objektorientierte Systementwicklung Vom Geschäftsprozess zum Java-Programm Mit 162 Abbildungen vieweg Überblick und Vorbemerkungen 1 1 Objektorientierte Software-Entwicklung 5 1.1 Überblick
Pflichtenheft Programmanwendung "Syntax Tool"
Projekt: Syntax Tool Autor: Michael Rattun Home: www.mrattun.de Letzte Änderung: 27.10.2011 1 SEITE Syntax Tool Inhaltsverzeichnis Inhaltsverzeichnis 1. Zielbestimmung... 3 1.1 Muss-Kriterien (Freeware)...
Barrierefreies Webdesign Attraktive Websites zugänglich gestalten. Angie Radtke, Dr. Michael Charlier
Barrierefreies Webdesign Attraktive Websites zugänglich gestalten Angie Radtke, Dr. Michael Charlier INHALTSVERZEICHNIS Über die Autoren Einleitung XI XV Kapitel 1 Barrierefreiheit Was ist das eigentlich?
Übungen zur Softwaretechnik
Technische Universität München Fakultät für Informatik Lehrstuhl IV: Software & Systems Engineering Markus Pister, Dr. Bernhard Rumpe WS 2002/2003 Lösungsblatt 1 17. Oktober 2002 www4.in.tum.de/~rumpe/se
Verwaltung von Studienergebnissen
Fiktive Projektentwicklung eines Systems zur Verwaltung von Studienergebnissen von Studenten der NTA FH Isny > Übersicht OOA - Diagramme Implementierungsphase (Prototyp) > Aufgabenstellung Verwalten von
NACHRICHTENTECHNISCHER SYSTEME
Einführung UML COMPUTERSIMULATION NACHRICHTENTECHNISCHER SYSTEME 11. Unified Modeling Language UML 220 Standardsprache d zur Visualisierung, i Spezifikation, Konstruktion und Dokumentation komplexer (Software-)
Modellbasiertes manuelles Testen: Techniken und Tücken
Modellbasiertes manuelles Testen: Techniken und Tücken 23.02.2015 Objektforum Dr. Andrea Herrmann Freiberufliche Trainerin für Software Engineering [email protected] Dr. Privat-Doz. Andrea Herrmann
Lastenheft. Lastenheft Definition Lastenheft DIN 69905 Gliederung nach Balzert Beispiele für ein Lastenheft Zusammenfassung Quellen
Lastenheft Lastenheft Lastenheft Definition Lastenheft DIN 69905 Gliederung nach Balzert Beispiele für ein Lastenheft Zusammenfassung Quellen Lastenheft DEFINITION Was ist ein Lastenheft? Das Lastenheft
Pflichtenheft Projektarbeit 2008 / 2009
Projektarbeit 2008 / 2009 Thema: Mikrocontrollergesteuerte Quarzuhr mit Sekunden Vor- und Zuname: Max Mustermann Problemstellung: Entwicklung einer Schaltungsanalyse und eines Platinenlayouts einer mikrocontrollergesteuerten
UML (Unified Modelling Language) von Christian Bartl
UML (Unified Modelling Language) von Inhaltsverzeichnis Inhaltsverzeichnis... 2 1 UML Unified Modelling Language... 3 2 Diagrammtypen... 3 2.1 Aktivitätsdiagramm... 3 2.1.1 Notation... 4 2.1.2 Beispieldiagramm...
Standard Inhaltsverzeichnis für Software-Anforderungsspezifikation
Standard Inhaltsverzeichnis für Software-Anforderungsspezifikation Inhaltsverzeichnis 1. Zweck, Veranlassung... 1 2. Allgemeines... 1 2.1 Zweck der Software-Anforderungsspezifikation... 1 2.2 Freigabe
Softwarearchitekturen I Softwareentwicklung mit Komponenten
Softwarearchitekturen I Softwareentwicklung mit Komponenten Detlef Streitferdt Technische Universität Ilmenau TU-Ilmenau, Softwaresysteme / Prozessinformatik, KBSE Softwarearchitekturen I 1 Beispiel: Bibliothekssystem
UML fürs Pflichtenheft
UML fürs Pflichtenheft Sebastian Fischmeister Department of Computer Science University of Salzburg, Austria [email protected] Overview Use-Case Diagramm State-Machine Diagramm
Notationen zur Prozessmodellierung
Notationen zur Prozessmodellierung August 2014 Inhalt (erweiterte) ereignisgesteuerte Prozesskette (eepk) 3 Wertschöpfungskettendiagramm (WKD) 5 Business Process Model and Notation (BPMN) 7 Unified Modeling
