ITP_TestSkriptum PDF

Simone Sperrer 3AHITM Miriam Gnadlinger Informationstechnische Projekte Skriptum 1 Projektbegriffe und Merkmale ________________________________________________ 4 1.1 Projekt Gründe _________________________________________________________ 4 1.2 Projektmerkmale _______________________________________________________ 4 1.2.1 Risiken ____________________________________________________________ 4 1.3 Projektablauf bzw. Projektphasen ________________________________________ 5 2 Kreativitätstechniken ________________________________________________________ 6 2.1 Brainstorming __________________________________________________________ 6 2.2 Methode 6-3-5 _________________________________________________________ 6 2.3 Synektik _______________________________________________________________ 6 2.4 Morphologischer Kasten (Zwicki Box) _____________________________________ 6 2.5 Mindmapping __________________________________________________________ 7 3 Projektidee und Vorstudie ___________________________________________________ 8 3.1 Projektidee – Projektantrag ______________________________________________ 8 3.1.1 Aufbau eines Projektantrags_________________________________________ 8 3.2 Projektwürdigkeit _______________________________________________________ 8 3.3 Variantenbildung _______________________________________________________ 9 3.3.1 SWOT-Analyse _____________________________________________________ 9 4 Zielbestimmung ___________________________________________________________ 10 4.1 Projektziele ___________________________________________________________ 10 4.2 Treffen einer Zielvereinbarung __________________________________________ 11 5 Stakeholder und Projektumfeld _____________________________________________ 11 5.1 Projektbegrenzung _____________________________________________________ 11 5.1.1 Projektkontext ____________________________________________________ 11 5.2 Stakeholder ___________________________________________________________ 12 6 Projektauftrag _____________________________________________________________ 13 6.1 Bedeutung ____________________________________________________________ 13 6.2 Aufbau _______________________________________________________________ 13 1 Simone Sperrer 3AHITM Miriam Gnadlinger 6.3 Meilensteinliste _______________________________________________________ 14 7 Anforderungsanalyse_______________________________________________________ 15 7.1 Interview _____________________________________________________________ 15 7.2 Fragebogen ___________________________________________________________ 15 7.3 Beobachtung _________________________________________________________ 16 7.4 Selbstaufschreibung ___________________________________________________ 16 7.5 Dokumentenauswertung _______________________________________________ 17 7.6 CRC-Karten ___________________________________________________________ 17 8 Pﬂichtenheft ______________________________________________________________ 18 8.1 Aufbau und Inhalt des Pﬂichtenhefts ____________________________________ 18 8.1.1 Beschreibung der Ausgangslage ____________________________________ 19 8.1.2 Ist-Zustand _______________________________________________________ 19 8.1.3 Zielsetzung _______________________________________________________ 19 8.1.4 Anforderungen (Soll) ______________________________________________ 19 8.1.5 Mengengerüst ____________________________________________________ 20 8.1.6 Aufbau und Inhalt der Offerte ______________________________________ 20 8.1.7 Administratives ___________________________________________________ 20 9 Test Driven Development ___________________________________________________ 21 9.1 Continous Testing _____________________________________________________ 21 9.2 Coverage _____________________________________________________________ 21 10 Scrum __________________________________________________________________ 22 10.1 Scrum Flow ___________________________________________________________ 22 10.2 Rollen im Scrum _______________________________________________________ 23 10.3 Alternative V-Modell (Wasserfallmodell) _________________________________ 23 10.4 Sprints _______________________________________________________________ 23 11 Aufbau eines Projektrepos ________________________________________________ 24 12 Git Branching Strategy ___________________________________________________ 24 12.1 GitHub Flow __________________________________________________________ 24 13 Docker _________________________________________________________________ 25 13.1 Allgemein _____________________________________________________________ 25 13.1.1 Was ist Docker? ___________________________________________________ 25 13.1.2 Wie funktioniert Docker? __________________________________________ 25 2 Simone Sperrer 3AHITM Miriam Gnadlinger 13.1.3 Virtualisierung ____________________________________________________ 25 13.1.4 Leicht- Vs. Schwergewichtige Virtualisierung ________________________ 26 13.2 Begriffe _______________________________________________________________ 26 13.3 Docker compose ______________________________________________________ 28 3 Simone Sperrer 3AHITM Miriam Gnadlinger 1 Projektbegriffe und Merkmale 1.1 Projekt Gründe Individuelle Problemlösung Betriebliche Innovation Können motivierend wirken Durch Projekte kann folgendes unterstützt werden: Technik Markt Organisationen 1.2 Projektmerkmale Wesentliche Projektmerkmale Inhaltliche Zielsetzung o Ich möchte eine Lagerhalle bauen Zeitliche Zielsetzung o Die Lagerhalle soll in 1 Monat fertig sein Relative Neuartigkeit o Lagerhalle soll den neuesten Standards entsprechen Beschränkte Ressourcen o Es sind nur 10 Arbeiter verfügbar Komplexität 1.2.1 Risiken technisches Realisierungsrisiko o Lagerhalle wurde falsch zusammengebaut 4 Simone Sperrer 3AHITM Miriam Gnadlinger Zeitrisiko o Bau der Lagerhalle dauert 2 statt einem Monat Aufwandsrisiko o Man braucht 20 Arbeiter hat aber nur 10 Arbeiter zur Verfügung Zielsetzungsrisiko o Lagerhalle wird ein Wirtshaus Verwertbarkeitsrisiko o Lagerhalle hat keinen Nutzen 1.3 Projektablauf bzw. Projektphasen Hauptphasen eines Projekts Phasen Aufgaben und Dokumente in einem Projekt Stakeholder-Analyse = Betroffenenanalyse Claim Management = Was gehört zum Projekt (was muss man machen) Querschnittsaufgaben = Ziehen sich durch das ganze Projekt 5 Simone Sperrer 3AHITM Miriam Gnadlinger 2 Kreativitätstechniken 2.1 Brainstorming Eine Gruppe sammelt spontan so viele Ideen wie möglich, ohne sie sofort zu bewerten. Ziel ist es, kreativ und frei zu denken. 10-20min mündlich Ideen und Lösungen sammeln Moderator steuert und es wird mitprotokolliert Beim Ideensammeln keine Kritik äußern Möglichst viele Ideen Freies Assoziieren und Fantasien sind erwünscht 2.2 Methode 6-3-5 Sechs Personen schreiben je drei Ideen auf ein Blatt Papier, das dann fünfmal weitergereicht wird. Die Ideen werden von den anderen ergänzt oder weiterentwickelt. 30 Minuten 108 Ideen 2.3 Synektik Die Systematische Verfremdung ist eine Technik, bei der man vertraute Dinge in einem neuen Zusammenhang sieht, z. B. durch Vergleiche, Analogien oder Kontraste, um kreative Lösungen zu ﬁnden. Systematische Verfremdung Man redet so lange über ein Problem, bis es keines mehr ist Synektik-Sitzungen dauern oft einige Stunden bis zu mehreren Tagen Phasen: 1) Beschäftigen mit dem Problem 2) Ablenken vom Problem 3) Schaffen von Verbindung zwischen Problem und Verfremdung 4) „spontanes“ Bewusstwerden von Lösungsideen. 2.4 Morphologischer Kasten (Zwicki Box) Ein Raster wird erstellt, in dem verschiedene Merkmale eines Problems und ihre möglichen Ausprägungen systematisch kombiniert werden. 6 Simone Sperrer 3AHITM Miriam Gnadlinger Beispiel einer Zwicki Box Hilft verschiedene Aspekte und Merkmale einer (Projekt-)Lösung systematisch anzuordnen Ideale Kombination von Merkmalen ﬁnden Deﬁnieren der Aufgabenstellung Festlegen der Teilbereiche (1. Spalte, müssen voneinander unabhängig sein, max. 6 bis 7) Festlegen der Ausprägungen zu jedem Teilbereich (horizontal — auch hier unabhängige Ausprägungen, möglichst konkret) Deﬁnieren der verschiedenen Lösungsvarianten (im Beispiel oben gekennzeichnet durch die schwarze und die pinke Linie) Analyse und Auswahl der Lösung(en) 2.5 Mindmapping Eine Methode, bei der Ideen und Konzepte um ein zentrales Thema in Form eines Baumdiagramms visualisiert werden, um Verknüpfungen und Zusammenhänge zu erkennen. Entwicklung einer Mindmap 7 Simone Sperrer 3AHITM Miriam Gnadlinger 3 Projektidee und Vorstudie 3.1 Projektidee – Projektantrag Wenn eine Projektidee schriftlich festgehalten wird, dann ist das ein Projektantrag. Projektidee: technische Innovation gesellschaftspolitische Gründe (z. B. Umweltschutz) Sicherung der Wettbewerbsfähigkeit betriebliche Umorganisation Schwachstellen im bisherigen Verfahren Projektantrag: eine überblicksmäßige Aufgabenbeschreibung den Nutzen, der durch das Projekt zu erwarten ist die Konsequenzen bei Nichtdurchführung des Projekts personelle und ﬁnanzielle Rahmenbedingungen 3.1.1 Aufbau eines Projektantrags 1) Sinn und Zweck des Projekts 2) Problemdarstellung 3) Lösungspräsentation 4) Ergebnis und Zieldeﬁnition 5) Projektbudget 6) Schlussfolgerung (Standpunkt darlegen) 3.2 Projektwürdigkeit Die Projektwürdigkeit wird im Rahmen einer Vorstudie und einer Machbarkeitsstudie geklärt. Vorstudie: Dabei werden folgende Punkte beachtet: Ist das Vorhaben ein tatsächliches Projekt Die Machbarkeit des Projekts Welche Auswirkungen kann man erwarten Die Aufwands Einschätzung Welchen Beitrag leistet das Projekt zur Gesamtstrategie 8 Simone Sperrer 3AHITM Miriam Gnadlinger Machbarkeitsstudie: Wirtschaftlichkeit des Projekts bzw. der angestrebten neuen Lösung Beitrag des Projekts zur Unternehmensstrategie (technische) Umsetzbarkeit des Projekts Projektrisiko Verfügbarkeit der erforderlichen Ressourcen (Personal, ﬁnanzielle Mittel, technische Ausstattung) sonstige Einﬂüsse, wie z. B. Stakeholder (vgl. Lerneinheit 4) 3.3 Variantenbildung Es gibt immer mehrere Wege ein Ziel zu erreichen. Jedoch unterscheiden sich die Wege immer in ihrer Machbarkeit, den Projekt- bzw. Betriebskosten, dem Realisierungsrisiko usw. Die Kreativitätstechniken sind hilfreiche Methoden zur Variantenbildung. Die Bedeutung eines kreativen nicht vorbelasteten Herangehens bei der Variantenbildung darf nicht unterschätzt werden. Prinzip der Variantenbildung 3.3.1 SWOT-Analyse Hierbei steht SWOT für: Strengths (Stärken) Weaknesses (Schwächen) Opportunities (Chancen) 9 Simone Sperrer 3AHITM Miriam Gnadlinger Threats (Bedrohungen) Beispiel einer SWOT-Analyse 4 Zielbestimmung 4.1 Projektziele Es gibt folgende Ziele: Ergebnisziele o Ergebnis, Leistung o Projektresultat in funktionaler, ﬁnanzieller Hinsicht o ZB Erinnerung an Gießtermine für verschiedene Pﬂanzen Vorgehensziele o zur Erreichung des Ergebnisses erforderliche Vorgehensweise o ZB Termine, Kosten, Zeitaufwand Wirkungsziele o Leistungswirkung, Outcome, „Ziele" o Die Pﬂanzen sollen gut gepﬂegt sein und weder verdorren (zu wenig Wasser) oder Krankheiten, Läuse etc. bekommen (ev. Zu viel Wasser) Magisches Viereck (Dreieck) o Leistungen o Termine o Kosten o Qualität 10 Simone Sperrer 3AHITM Miriam Gnadlinger Eigentlich gibt es das magische Dreieck aber ein Projekt ohne Qualität ist sinnlos darum haben wir das magische Viereck, wo zusätzlich die Qualität inkludiert ist. Unter Qualität versteht man die Erfüllung des Kundenwunsches. d.h. wenn der Kunde zufrieden ist, dann ist die Qualität in Ordnung. Gute Ziele zeichnen sich durch folgende zwei Punkte aus: Das sie erreichbar sind Das sie quantiﬁzierbar sind (d.h. Erreichung muss messbar sein) 4.2 Treffen einer Zielvereinbarung Im Alltag wird oft angenommen, dass „etwas Bestimmtes zu tun“ gleichbedeutend mit dem Festlegen eines Ziels ist. Jedoch entsteht ein Ziel aus den Gründen des Auftraggebers und der Interpretation des Teams. Klarheit erfordert genaues Nachfragen. Bei einer Zielvereinbarung sollten diese vier Fragen gestellt werden: Wozu? Für Wen? Endergebnis? Erfolgskriterien? 5 Stakeholder und Projektumfeld 5.1 Projektbegrenzung Formen zur Projektabgrenzung 5.1.1 Projektkontext Im Zuge der Projektbegrenzung ist es wichtig den Projektkontext zu erfassen. Dabei ist ein Claim Management wichtig. Das Claim Management ist das "Abstecken" des Projekt Bereichs damit man nicht zu weit vom ursprünglich geplanten Projekt abweicht und z.B. etwaige neben Features zu weit ausbaut und die Hauptfunktion nicht fertig stellt. Claim Management = früher das Abstecken des Gold Claims. 11 Simone Sperrer 3AHITM Miriam Gnadlinger 5.2 Stakeholder Stakeholder eines Projekts ist eine Person, Gruppe oder Organisation, die an irgendeinem Aspekt des Projekts interessiert ist oder diesen beeinﬂusst, davon betroffen ist oder sich davon betroffen fühlen kann. Dabei unterscheidet man in folgende Gruppen: interne Stakeholder: arbeiten direkt am Projekt mit (z. B. Teammitglieder) oder sind direkt vom Projekt betroffen (z. B. Kundenkreis, Lieferanten, Unternehmensleitung) externe Stakeholder: sind von der Projektdurchführung oder den Projektauswirkungen indirekt betroffen (z. B. Interessenvertretungen, Anrainer bei einem Bauprojekt) Stakeholder können durch folgende Punkte identiﬁziert werden: Betroffenheit: Intensität bzw. objektive/subjektive Betroffenheit Interessen: Stakeholderinteressen in Einklang oder Konﬂikt mit den Projektzielen Macht: Fähigkeit, das Projekt zu beeinﬂussen Beispiel eines Stakeholder-Portfolio Beispiel zur Stakeholder-Analyse Buch, Seite 64-65 12 Simone Sperrer 3AHITM Miriam Gnadlinger 6 Projektauftrag 6.1 Bedeutung Der genehmigte Projektauftrag bildet den formalen Projektbeginn. In Unternehmen, die häuﬁg Projekte durchführen, kann der Projektauftrag in Form eines Formulars standardisiert sein. Zielformulierung Qualitätskriterien ﬁnanzieller Rahmen Termine Organisation und Personen 6.2 Aufbau 1) Projektbezeichnung 2) Projektauftragsgeber 3) Projekthintergrund o Was hat zu diesem Projekt geführt? o Welche Mängel oder Probleme sollten durch das Projekt beseitigt werden? 4) Projektergebnis o Angabe der Wichtigsten Projektergebnisse o Was? Wie gut? Wie viel? Bis wann? Usw. 5) Projektziele o Siehe unter 4.1 Projektziele 6) Projektbeschreibung o Die wesentlichen Teilaufgaben zur Erreichung des Projektergebnisses 7) Meilensteine o Siehe Punkt 6.3 Meilensteinliste 8) Projektstart o Datum des offiziellen Projektstart 9) Projektende o Datum des offiziellen Projektende 10) Projektressourcen o Projektkalkulation: Welche ﬁnanzielle Mittel bzw. Ressourcen sind erforderlich bzw. stehen zur Verfügung. Dies kann man zum Beispiel in folgende Punkte einteilen:  Infrastruktur  Personal  Material 13 Simone Sperrer 3AHITM Miriam Gnadlinger  Sonstige Aufwendungen 11) Projektrisiken o Siehe 1.2.1 Risiken o Geplante Maßnahmen gegen diese Risiken 12) Projektorganisation o Wer ist die Projektleitung o Projektteam  Namen  Rollen  Verantwortlichkeit 13) Abschluss des Projektauftrags o Datum der Erstellung o Unterschriften aller Verantwortlichen 6.3 Meilensteinliste Ein Meilenstein ist ein überprüfbares Zwischenergebnis, das inhaltlich und terminlich genau beschrieben ist. Meilensteine dienen daher als Orientierungshilfe für Projektleitung und -team. Beispiel einer Meilensteinliste Meilenstein: Die Nummerierung der Meilensteine Ergebnis: Was soll geschafft worden sein soll. Soll-Termin: Datum wann dieser Meilenstein fertig abgeschlossen sein soll. Ist-Termin: Datum wann die tatsächliche Abschließung dieses Meilensteins war. 14 Simone Sperrer 3AHITM Miriam Gnadlinger 7 Anforderungsanalyse Eine Anforderungsanalyse ermittelt und dokumentiert, was ein Produkt oder Projekt leisten soll, um die Bedürfnisse der Beteiligten zu erfüllen. 7.1 Interview Die Hauptziele eines Interviews bei der Systemplanung sind die Gewinnung qualitativer Informationen und die Etablierung einer konstruktiven Zusammenarbeit. Das Interview ist die am häuﬁgsten eingesetzte Ist-Aufnahmetechnik. Das Interview zählt neben der Beobachtung (8.3 Beobachtung) zu den direkten Erfassungsmethoden. Man kann ein Interview folgendermaßen gestalten: standardisiertes, halb oder nicht standardisiertes Interview weiches, neutrales oder hartes Interviewverhalten offene oder geschlossene Fragen direkte oder indirekte Fragen Halb oder nicht standardisierte Interviews eignen sich vor allem für komplexerer Zusammenhänge. Standardisierte Interviews sind besser geeignet für die Erhebung von quantitativen Informationen. Die Erhebung mittels Interviews wird in folgende Abschnitte unterteilt: 1. Interviewvorbereitung (interview preparation) 2. Interviewdurchführung (interview session) 3. Interviewauswertung (interview follow up) Die Interviewdurchführung kann man wiederum auch in drei Abschnitte unterteilen: 1. Einführungsphase 2. Befragungsphase 3. Schlussphase 7.2 Fragebogen Der Fragebogen eignet sich vor allem zur Erhebung quantitativer Informationen bei einer Vielzahl von Befragten. Die Fragen werden in Schriftform übermittelt und vom Aufgabeträger auch schriftlich beantwortet. Der Fragebogen kann als ergänzendes Hilfsmittel eingesetzt werden. Man kann den Fragebogen als ein schriftliches, standardisiertes Interview mit geschlossenen Antworten ansehen. 15 Simone Sperrer 3AHITM Miriam Gnadlinger Es gibt zwei Gestaltungarten für Fragebogen: Individual- oder Gruppenfragebogen Fragebogen mit standardisierten, halb standardisierten und nicht standardisierten Fragen. 7.3 Beobachtung Eine Beobachtung ist die Deckung des Informationsbedarfs durch sinnliche Wahrnehmungen des Systemplaners im Untersuchungsbereich ohne Beteiligung des Aufgabenträgers. Die Beobachtung wird zu den direkten Erfassungsmethoden gezählt. Es gibt folgende Kriterien die Beobachtungsformen unterscheiden: offene oder verdeckte Beobachtung strukturierte oder unstrukturierte Beobachtung aktiv teilnehmende oder passive Beobachtung Dauerbeobachtung oder unterbrochene Beobachtung Verdeckte Beobachtungen, also „getarnte“ Beobachtungen, werden in Organisationen selten genutzt. Dauerbeobachtungen liefern zwar sehr genaue und vollständige Ergebnisse, sind aber aufgrund des hohen Zeitaufwands, der psychologischen Belastung und der Gefahr von Verfälschungen kaum praktikabel. Eine häuﬁgere Methode ist die Multimomentaufnahme, bei der stichprobenartige Augenblicksbeobachtungen verwendet werden, um daraus zuverlässige Mengen- oder Zeitangaben abzuleiten. Kurz: Verdeckte Beobachtungen sind unüblich. Dauerbeobachtungen sind genau, aber zeitaufwendig und belastend. Multimomentaufnahmen nutzen Stichproben für statistisch fundierte Ergebnisse. 7.4 Selbstaufschreibung Die Selbstaufschreibung ist kein Tagebuch, sondern eine strukturierte Aufzeichnung relevanter Ereignisse und Handlungen. Es ist folgender Vorgehensrahmen festgelegt: 1. Aufnahmefestlegung 2. Aufnahmevorbereitung 3. Mitarbeiterinformation 4. Durchführung 5. Auswertung 16 Simone Sperrer 3AHITM Miriam Gnadlinger 7.5 Dokumentenauswertung Die Dokumentenauswertung ist eine meist leicht verfügbare Informationsquelle, deren Relevanz aber immer hinterfragt werden sollte. Wird in drei Bereichen genutzt: Dokumentation des bestehenden Systems: Systematische Analyse vorhandener Unterlagen zur Erfassung des Ist-Zustands, sofern die Unterlagen vollständig, ausreichend und aktuell sind. Vorhandene Studien: Frühere Untersuchungen, auch erfolglose, liefern wertvolle Einblicke in Problemdeﬁnitionen und frühere Lösungsansätze. Belege und Formulare: Analyse aller verwendeten Belege zur Gestaltung von Eingabe- und Ausgabeprozessen. Diese dienen später als Grundlage für die Funktionenspeziﬁkation. 7.6 CRC-Karten CRC steht für Class Responsibility Collaboration und dient dem Aufbau eines Klassenmodells basierend auf Anwendungsfällen, indem Klassen durch ihre Verantwortlichkeiten und Kooperationen beschrieben werden. Ursprünglich für den Unterricht entwickelt, wird es heute oft in agilen Methoden genutzt. Wie funktioniert das: CRC-Karten werden in Gruppen von 5–6 Personen genutzt, um ein erstes Klassenmodell zu entwickeln. Dafür werden A6-Karten verwendet, die leer oder mit vorgedruckten Feldern versehen sein können. Beispiel von CRC-Karten für die Verwaltung eines Kulturvereins. 17 Simone Sperrer 3AHITM Miriam Gnadlinger Eine CRC-Sitzung soll sich jeweils auf einen Teilaspekt der Software konzentrieren. Eine Solche Sitzung läuft folgendermaßen ab: 1. Zusammenstellen der Gruppe: Passende Teilnehmer auswählen und Termin vereinbaren. 2. Vorbereitung: Besprechungsraum mit Pinnwänden und Karten (A6) einrichten. 3. Klassen ﬁnden: In einem Brainstorming werden mögliche Klassen (Hauptwörter) und Verantwortlichkeiten (Zeitwörter) identiﬁziert. Diese werden auf Karten notiert, und Teilnehmer übernehmen Verantwortung für einzelne Klassen. 4. Szenarien durchspielen: Anwendungsfälle werden simuliert, bei denen Klassen ihre Aufgaben und Zusammenarbeit darstellen. Erst reguläre Szenarien, dann Ausnahmen und Fehler. 5. Anpassung und Dokumentation: Falls nötig, Klassen oder Anwendungsfälle überarbeiten. Abschließend wird das ﬁnale Klassenmodell dokumentiert (z. B. Foto der Pinnwand). Ziel dieses Verfahrens ist eine stabile Verteilung der Verantwortlichkeit über die Klassen, um insgesamt ein gut strukturiertes und stabiles System zu erreichen. CRC-Karten mit Vordruck (vorne und hinten) 8 Pﬂichtenheft 8.1 Aufbau und Inhalt des Pﬂichtenhefts Die Grundlegende Idee des Pﬂichtenheftes ist die Darstellung der gegenwärtigen Situation, die klare Formulierung von Zielen und Anforderungen sowie die Vorgabe des Offertaufbaus. Das Pﬂichtenheft beschreibt Anforderungen und Qualität, ohne Lösungen vorzugeben, um kreative Ansätze der Entwickler nicht einzuschränken. Es bleibt nie vollständig, daher muss der Software-Hersteller fehlende Infos einholen und Verbesserungsvorschläge kommentieren. 18 Simone Sperrer 3AHITM Miriam Gnadlinger 8.1.1 Beschreibung der Ausgangslage Das Unternehmen wird durch Art, Größe, Standorte, Produkte, Dienstleistungen, Kundenstruktur und IT-Organisation beschrieben, einschließlich der Gründe für die Beschaffung. 8.1.2 Ist-Zustand Beschreibung bezieht sich nur auf die für das Projekt relevante Bereiche. Das Unternehmen wird durch Art, Größe, Standorte, Produkte, Dienstleistungen, Kundenstruktur und IT-Organisation beschrieben, einschließlich der Gründe für die Beschaffung. 8.1.3 Zielsetzung Die Zielsetzung beschreibt realistische und messbare Ziele der Beschaffung und deren Prioritäten, um die Zielerreichung später besser prüfen zu können. Unterschieden wird in: Nutzrelevante Ziele Systemziele Vorgehensziele 8.1.4 Anforderungen (Soll) Das Kapitel „Anforderungen“ beschreibt detailliert die erwarteten Eigenschaften des Systems und vorwegnehmend die Inhalte des Benutzerhandbuchs, um Vollständigkeit und Wiederverwendbarkeit zu gewährleisten. Anforderungen an die Applikationssoftware o Gesamtapplikation o Teilapplikation Anforderungen and die Systemplattform o Systemkonzept o Rechnersysteme o Systemsoftware o Kommunikationsinfrastruktur Anbieterbezogene Anforderungen o Merkmale des Anbieters o Dienstleistungen o Projektorganisationen o Termine o Gewährleistungen 19 Simone Sperrer 3AHITM Miriam Gnadlinger 8.1.5 Mengengerüst Das Mengengerüst beschreibt erwartete Datenmengen und Verarbeitungsfrequenzen, damit Anbieter Speicherkapazitäten und Bandbreiten planen können. Diese wird gegliedert in: Datenbewegungen Datenbestände Anzahl (gleichzeitiger) Benutzer 8.1.6 Aufbau und Inhalt der Offerte Dies ist wichtig bei der Ausschreibung, um einzelne Angebote möglichst einfach und objektiv zu vergleichen können. Vorstellen der Offertstellers Management Summary Beischreibung der angebotenen Leistungen 8.1.7 Administratives Vertraulichkeit, Rückgabe, Copyright Evaluationsschwerpunkte Verteiler Budgetrahmen Rückfragen zum Pﬂichtenheft Termine Abgabe der Offerte 20 Simone Sperrer 3AHITM Miriam Gnadlinger 9 Test Driven Development 9.1 Continous Testing Ziel von TDD ist es, qualitativ hochwertigen, wartbaren und getesteten Code zu erstellen. o Es wird hochqualitativer Code geschrieben, weil durch den minimalen Code, gleichzeitig unnötiger Code vermieden wird. o Fehler werden sofort erkannt o Funktionalität schon vorher klar deﬁniert durch die Unit Tests 1. Test für eine Funktionalität schreiben (so einfach wie möglich schreiben) 2. Wenn Test rot ist, die Methode implementieren nur so viel bis Test grün wird (auch wenn man weiß man muss ihn wieder verändert) Continious Testing: Beim Speichern des Code werden Tests automatisch ausgeführt. 9.2 Coverage Messung der Testabdeckung: Coverage misst, wie viel des Quellcodes durch Tests abgedeckt wird. Ziel ist es, sicherzustellen, dass möglichst alle Codepfade von Tests überprüft werden. Wichtigkeit in TDD: Da TDD stark auf Tests basiert, hilft Coverage dabei, sicherzustellen, dass keine Codebereiche ungetestet bleiben. Hohe Coverage ist wünschenswert, aber nicht wichtiger als sinnvolle Tests. Coverage anzeigen lassen 21 Simone Sperrer 3AHITM Miriam Gnadlinger 10 Scrum Wie Scrum funktionieren soll - Rapid Value Creation Projekte werden in (2 Wochen) Sprints unterteilt. Damit wird eine schnelle Anpassung an Veränderungen ermöglicht. 10.1 Scrum Flow 22 Simone Sperrer 3AHITM Miriam Gnadlinger 10.2 Rollen im Scrum Customer: Gibt die Anforderungen vor. Product Owner: Priorisiert Anforderungen. Scrum Master: Unterstützt das Team und den Prozess. Dev Team: Entwickelt das Produkt. User/Manager: Interagieren als Stakeholder und unterstützen bei der Priorisierung. Jede Rolle hat seine Ansprechpartner: Dev. Team –> User Product Owner –> Customer Scrum Master –> Manager 10.3 Alternative V-Modell (Wasserfallmodell) Das V-Modell Im Prinzip besteht ein Scrum aus ganz vielen kleinen V-Modellen, da im Scrum für jeden Schritt ein solches Modell erstellt wird. 10.4 Sprints Feste Zeitspanne vereinbart Jedes Mal klare und bestimmt Ziele ausmachen Aufgaben werden priorisiert und geplant Schrittweise Verbesserung Regelmäßige Überprüfung 23 Simone Sperrer 3AHITM Miriam Gnadlinger 11 Aufbau eines Projektrepos Nur ein.git-Verzeichnis im Repo.gitignore im repo-root Nur notwendige Dateien und Ordner sollten im Repo sein. Trennen von Logik (Code), Tests, Dokumentation und Ressourcen. Dokumentation: Beschreibt die Struktur und das Setup des Repos in der README.md. 12 Git Branching Strategy 12.1 GitHub Flow Grundregeln: 1. Main-Branch o Der Hauptzweig (main) ist immer lauffähig und enthält nur stabilen, produktionsfertigen Code. 2. Feature-Branches o Jeder Entwickler erstellt einen Feature-Branch für die Entwicklung neuer Features. Sie werden nach Fertigstellung und Überprüfung in main- Branch gemerged. 3. Bugﬁx-Branches o Für dringende Fehlerbehebungen in der Produktion werden Bugﬁx- Branches erstellt. Nach Fertigstellung werden die Bugﬁxes in main gemerged und können direkt in Produktion übernommen werden. Deployment: Änderungen auf main werden regelmäßig in die Produktion deployt. 24 Simone Sperrer 3AHITM Miriam Gnadlinger 13 Docker 13.1 Allgemein 13.1.1 Was ist Docker? Eine Technologie, um eine Application und alle ihre Abhängigkeiten in einen einzelnen, leicht zu transportierenden Container zu packen. Wird eine Applikation in einen Docker-Container gepackt, so ist sichergestellt, dass die Laufzeitumgebung unverändert bleibt, auch wenn der container auf einem anderen Hostsystem läuft. Docker hat eine genormte Größe 13.1.2 Wie funktioniert Docker? Docker Aufbau 13.1.3 Virtualisierung Nachbildung einer Hard- oder Software-Objekts auf einer virtuellen Abstraktionsschicht. Sie ermöglicht virtuelle Geräte oder Dienste, wie emulierte Hardware, Betriebssysteme oder Netzwerkressourcen, wodurch Ressourcen effizienter genutzt oder aufgeteilt werden können. Windows Vs. Linux Windows = Monolit Linux Modular = Man kann ganz kleine "Linuxe" bauen Man unterscheidet zwischen leicht und schwergewichtiger Virtualisierung. 25 Simone Sperrer 3AHITM Miriam Gnadlinger 13.1.4 Leicht- Vs. Schwergewichtige Virtualisierung Docker ist eine leichtgewichtige Virtualisierung Unterschied zwischen leichtgewichtigen und schwergewichtigen Virtualisierungen 13.2 Begriffe Docker Volumes Docker Volumes sind Mechanismen, um Daten zwischen Containern und dem Host- System zu teilen und dauerhaft zu speichern, selbst wenn der Container gelöscht wird. Es wird von Docker erstellt und verwaltet. o Named volumes Verwaltet Docker selbst und werden durch einen speziﬁschen Namen identiﬁziert und sind für Daten, die längerfristig bestehen bleiben sollen. Mounts ein Volume wird gemountet Der Begriff "Mount" bezeichnet das Einbinden von Speicher in einen Container, sodass er auf Daten zugreifen oder diese speichern kann. o Bind mount Bindet einen speziﬁschen Pfad auf dem Host-System (z. B. /home/user/data) an einen Pfad im Container (z. B. /app/data). Benutzer gibt einen beliebigen Pfad auf den Host an 26 Simone Sperrer 3AHITM Miriam Gnadlinger o Volume mount Nutzt ein Docker-verwaltetes Volume, das unter /var/lib/docker/volumes/ gespeichert wird Volume das Docker erstellt und verwaltet Docker Volumes Image Immutable Image Ein Docker Image ist eine unveränderliche Vorlage, die alles enthält, was zum Starten eines Containers benötigt wird, einschließlich der Anwendung, Laufzeit, Bibliotheken und Konﬁgurationen. Container Ein Container ist eine laufende Instanz eines Docker Images. Er ist leichtgewichtig, isoliert und führt Anwendungen aus. - ein gestartetes Image (mutable) Buildcontext Der Docker Build Context ist der Satz von Dateien, die Docker benötigt, um ein Docker- Image zu erstellen. Der Build Context enthält typischerweise die Dockerﬁle und alle Dateien, die in der Dockerﬁle referenziert werden, wie z.B. Quellcode, Konﬁgurationsdateien und Abhängigkeiten. port Netzwerk-Endpunkt, der zur Kommunikation zwischen Containern und dem Host verwendet wird 27 Simone Sperrer 3AHITM Miriam Gnadlinger registry Eine Docker Registry ist ein Speicherort für Docker Images. Die bekannteste ist Docker Hub, aber es gibt auch private Registries für Unternehmen. Dockerﬁle o Hat keine Endung o Kochrezept (Textdatei mit Befehlen) zum Erstellen des Images run Der docker run-Befehl startet einen neuen Container aus einem angegebenen Docker Image. 13.3 Docker compose Docker Compose ist ein Tool, das dir hilft, Multi-Container-Anwendungen einfach zu deﬁnieren und auszuführen. Es verwendet eine YAML-Datei (docker-compose.yml), um die Konﬁguration aller Container in einer Anwendung zu beschreiben. Docker compose ist ähnlich wie die pom.xml für maven Hat die Endung.yaml Verbindet mehrere Container Docker pull Man lädt Images von remote Registry (Docker Hub) in mein lokales Registry Gegenteilig wäre docker push Lädt ein lokales Docker-Image in ein Remote-Registry 28

ITP_TestSkriptum PDF

Document Details

Tags

Related

Summary

Full Transcript

Upgrade to continue