IT-Konzept Beispiel de

1 IT-Konzept Projektname: Beispiel f r ein IT-Konzept Version: Autor: Gerrit Radziwill, Final Matrix GmbH. Lizenztyp: GNU LGPL v3 oder h her Syntax: <> = optionale Inhalte Dokumenthistorie Aufgabe Termin Autor Status Version Men struktur Max Mustermann erledigt erstellen Inhalt anlegen Max Mustermann erledigt berpr fung im Max Mustermann erledigt Team berarbeitung Max Mustermann erledigt Kapitel 'Daten'. Freigabe zur Max Mustermann erledigt Abnahme bersetzung Melanie Musterfrau erledigt englisch Abnahme f r Markus erledigt Projektstart Mustermanager bersetzung in offen offen offen offen weitere Sprachen Inhaltsverzeichnis 1. Gesamt berblick ..2. 2. berblick ..2. Architektur ..2. Voraussetzungen ..3. Software ..3. <Hardware> ..3. <Daten>..3. Zielsetzungen ..3. <Software>.

2 3. <Performanz>..4. <Verf gbarkeit>..4. Ansprechpartner ..4. <fachlich> ..4. <technisch> ..4. 1. 3. Daten ..4. berblick ..4. Architektur ..4. Datenentit ten ..5. <Datenintegrit t>..5. <Datenmodelle> ..5. 4. Steuerung ..6. 5. Verarbeitung ..6. berblick ..6. Architektur ..6. < Zugriffsdiagramm> ..6. Verarbeitungsentit <Datenplausibilit t> ..7. 6. Protokollierung ..7. 7. Qualit tssicherung ..7. <Programmierrichtlinien>..7. Test ..7. 1. Gesamt berblick Ziel des Projektes ist es, IT-Fachkr ften mit wenig Erfahrung auf dem Gebiet der Konzepterstellung ein brauchbares Konzeptbeispiel f r die ersten eigenen Konzepterstellungsaufgaben in die Hand zu geben. 2. Basis Die Basis beschreibt die Bedingungen bzw. Voraussetzungen unter denen das Projekt durchgef hrt werden soll. Sie ist so etwas wie eine grobe abstrakte Beschreibung der technischen Aufgaben und Ziele eines Projektes.

3 Berblick Allgemeine Informationen oder Anforderungen. Hier k nnte man besondere allgemeine Bedingungen anf hren. das alle verwendeten Programmiersprachen plattformunabh ngig sein m ssen, oder dass eine w chentliche Iteration im Scrum Modus vorgesehen ist. Architektur Besondere Bemerkungen zur Architektur. Warum sollen alle Schnittstellen als Webservice realisiert werden. Anwendungsdiagramm Grafische Gesamtdarstellung aller beteiligten Systeme aus der hervorgehen sollte, welche Schnittstellen und Daten von und zu welchen Anwendungen / Servern /. Instanzen / Abteilungen f hren. 2. Mit Hilfe solcher Diagramme k nnen noch unber cksichtigte Voraussetzungen oder Risiken von Seiteneffekten aufgedeckt werden. Dabei richtet sich der Blick nicht nur auf das eigene Projekt sondern auch auf alle anderen beteiligten, existierenden oder m glicherweise noch in Entwicklungsphasen befindlichen Systeme.

4 Stichpunkte f r den Diagramminhalt: Daten Anwendungen <Schnittstellen>. <Fremdsysteme>. Voraussetzungen Beschreibung allgemeiner Annahmen wie dass f r alle notwendigen administrativen Aufgaben der Dienstleister XYZ werkt glich zwischen 8 und 18 Uhr mit Servicelevel 2 zur Verf gung steht. Software Welche Software muss auf welchen Systemen vorhanden sein. Anwendungen <Versionen>. <Hardware>. Beispiele: Es werden 2 Server mit je 16 CPUs ben tigt. Es werden 5 Entwicklerstationen ben tigt. Die Netzwerkanbindung zum Standort XY muss auf n GB erh ht werden. <Daten>. Beispiele: Es werden Produktivdaten mit den Datenst nden von der Jahresendverarbeitung und den letzten drei Monatsultimos ben tigt. Es soll eine Datenqualit tsanhebung in der Erfassung durchgef hrt werden, welche zuk nftig doppelte Lieferanten ausschlie t.

5 Zielsetzungen Beschreibung allgemeiner Ziele wie dass der Schwerpunkt auf Wartbarkeit oder auf Sicherheit zu setzen ist. <Software>. Beispiele: Das Webinterface soll auf FireFox V6 und IE V8 lauff hig sein. Die Datenschnittstellen sollen wo immer m glich XML Strukturen verwenden. 3. Die Anwendungen m ssen auf Windows XP als auch Windows 7 laufen. <Performanz>. Beispiele: Die Webanwendung darf eine maximale Zugriffszeit von 5 Sekunden bei 100. parallelen Nutzern nicht berschreiten. Die Anwendung muss alle Szenarien innerhalb von 2 Stunden vollst ndig durchrechnen k nnen. <Verf gbarkeit>. Beispiele: Die Anwendung wird einmal monatlich ben tigt und muss am jeweiligen Monatsultimo innerhalb von zwei Tagen mit allen Daten verf gbar sein. Die Anwendung muss parallel mehrfach redundant lauff hig sein und ihre Instanzen m ssen die Daten eigenst ndig synchronisieren k nnen.

6 Ansprechpartner <fachlich>. <Konzeption>. <Organisation>. <technisch>. <Administration>. <Entwicklung>. 3. Daten Eine allgemeine Beschreibung wie: Mit Hilfe der Anwendung werden t glich Kundendaten aufgenommen, in Berichtsform zur Verf gung gestellt sowie per Nachtlauf strukturiert an andere Zielsysteme weitergegeben. berblick Allgemeine Informationen oder Anforderungen. Hier k nnen Informationen zur Ber cksichtigung der schlechten Datenqualit t oder zu besonderen Datenquellen beschrieben werden. Weitere Beispiele: Alle Zeichenketten sollen stets im Unicode verwendet werden. Die Genauigkeit der Nachkommastellen muss mindestens 8 betragen. L nderspezifische Datums- oder Zeitwerte sollen vor jeglicher Verarbeitung jeweils in ein internes Datumszeitformat gewandelt werden.

7 Architektur 4. Hier k nnte eine zus tzliche Beschreibung der gew nschten Architekturans tze stehen. Datenflussdiagramm In einem solchen Diagramm sollten die folgenden Themen Ber cksichtigung finden: <Konfiguration>. <Datenbanken>. <Textdateien>. <Datenstr me>. <Anwenderinteraktion>. <Anwendungen>. Datenentit ten Hier k nnen die Anforderungen an die einzelnen Datenstrukturen und -pakete, welche im Diagramm unter bereits aufgezeigt wurden, detailliert beschrieben werden. Beispiel : Die CSV-Tabelle XY muss jeden Tag um 18 Uhr in Ordner XYZ abgelegt werden. Was Datentypen Datenformate <Datenbereiche>. Woher <Siehe >. Wohin <Siehe >. Wann <Aktualisierungen>. <Intervalle>. <Datenintegrit t>. Beispiel : Es d rfen nur Marktdaten verarbeitet werden, zu denen auch eine W hrung hinterlegt ist.

8 <Annahmen>. <Pr fungen>. <Datenmodelle>. Hier sollten die Datenmodellierungen zu verwendeten Datenbanken per Skript, Diagramm und oder Referenz auf externe Dateien hinterlegt werden. Aber auch ein paar Exceltabellen oder XML-Dateien sind es gelegentlich wert hier ordentlich modelliert zu werden. 5. 4. Steuerung Hier soll beschrieben werden, wie, von wem und wann genau eine Anwendung aufgerufen werden soll. Eine einfache Rechteverwaltung kann hier mit beschrieben werden. F r eine komplexere Rechteverwaltung ist eher ein eigenes Kapitel empfehlenswert. Was <Anwender>. <Berechtigungen>. <Anwendungen>. <Berechtigungen>. <Services>. <Berechtigungen>. Wann <Termine>. <Intervalle>. Wie <Oberfl che>. <Parameter>. 5. Verarbeitung Beschreibung allgemeiner Anforderungen an die Verarbeitung wie dass der Schwerpunkt auf Wartbarkeit oder auf Sicherheit zu setzen ist.

9 Berblick Allgemeine Informationen oder Anforderungen. Beispiele: Alle Anwendungsschnittstellen d rfen ausschlie lich Datentypen verwenden, welche auch direkt mit J2EE ansprechbar bzw. verwendbar sind. Architektur Beschreibung von Besonderheiten der Anwendungsarchitektur. < Zugriffsdiagramm>. <Anwendungsschichten>. Hier ein Beispiel unter Klassenmodell hnlich eines Datenmodells werden hier die Klassen bzw. Module einer Anwendung beschrieben mit Hilfe von <Klassen- bzw. Moduldiagramm>. oder auch noch etwas detaillierter in einem 6. <Funktions- bzw. Prozedurdiagramm>. Verarbeitungsentit ten Hier k nnen einzelne Strukturen aus den Diagrammen unter gesondert detaillierter beschrieben werden. Was <Module>. <Klassen>. <Funktionen>. <Prozeduren>. Wo <Dateien>. <Netzwerk>.

10 Wann Startverhalten <Datenplausibilit t>. Beispiel : Es d rfen nur Marktdaten verarbeitet werden, deren Abweichung zum Vortag nicht mehr als 10% betr gt. <Annahmen>. <Pr fungen>. 6. Protokollierung Hier sollte m glichst pr zise die ben tigte Protokollierung beschrieben werden. Dieses Kapitel wird h ufig au er Acht gelassen, ist aber f r die zuk nftige Wartung ein absolutes Muss! technische Protokolle fachliche Protokolle 7. Qualit tssicherung Allgemeine Informationen oder Anforderungen. <Programmierrichtlinien>. Test Hier sollten idealer Weise alle technischen Testf lle beschrieben werden. Auch wenn dies vornehmlich technische Szenarien darstellt sollte dieser Teil auch vom Fachbereich einmal kurz berflogen werden. Diese ausf hrlichen Beschreibungen f hren brigens oft zu deutlich mehr Klarheit in der Testphase und dienen auch zuk nftigen Anwendungserweiterungen als gute Basis.