Projekt nmedialibrary. nmedialibrary. Projektarbeit

Transkript

1 Projekt Projektarbeit vorgelegt von Robert Kölz, Michael Karlen, Thomas Wittek, Erik Schwidop 2004 / 2005

2 Inhaltsverzeichnis 1 Einleitung Projektübersicht 2.2 Projektvision 2.3 Pflichtenheft 2.4 Projektplanung 2.5 Projektdokumentation 3 Mobile Medialibrary 3.1 Pflichtenheft 3.2 Feinspezifikation 3.3 Projektstrukturplan 3.4 Tests 3.5 Produkteinführung 4 Schlusswort 5 Anhang 5.1 Diagramme 5.2 Quellenverzeichnis 5.3 Glossar

3 1 Einleitung In den vergangenen Jahren wurden klassische Informationsträger aufgrund stetigen technischen Fortschritts immer mehr durch digitale Varianten abgelöst: die Videokassette durch die DVD und die Schallplatte durch die Compact Disc. Einzig das Medium Buch erfreute sich bisher immer noch ungebrochener Beliebtheit. Durch die rasant wachsende und immer dichter werdende Vernetzung unserer Welt, ist unsere Gesellschaft z.zt. im nächsten medientechnischen Evolutionsschritt begriffen. Datenträger wie wir sie kennen verschwinden zusehends von der Bildfläche und werden im Laufe der nächsten Jahre vollkommen überholt sein. Nahezu jeden Musiktitel und Film kann man heutzutage aus dem Internet auf seinen Rechner herunterladen. Und auch das gute alte Buch vermag dem neuen Trend nicht mehr lange standzuhalten. Das ebook ist auf dem Vormarsch. In naher Zukunft wird das Internet der einzig verbleibende Vertriebsweg für die Medienbranche sein. Für den Medienkonsumenten ergibt sich neben den unzähligen Vorteilen, die die digitale vernetzte Welt bietet, aber auch ein entscheidendes Problem: Musiktitel, Filme und Bücher, die bisher im Schrank, dem Regal oder dem CD-Ständer Platz fanden, liegen nun brach und unsortiert auf der Festplatte des Heim-PCs herum. Im Laufe kurzer Zeit sammeln sich so gewaltige Datenmengen an, die überhaupt nicht mehr zu überschauen sind. Damit die Suche nach dem Lieblingslied, Goethes Klassikern oder dem neuesten Kinohit nicht zu einem Fiasko wird, ist eine effiziente Software zur strukturierten Archivierung und zum schnellen Wiederauffinden der digitalen Medien notwendig. Da wir als medien- und technikbegeisterte junge Menschen selbst unmittelbar von diesem Problem betroffen waren, beschlossen wir, uns der Sache anzunehmen und selbst eine solche Software zu entwickeln. Die Idee der war geboren! Die Dokumente auf den folgenden Seiten beschreiben den gesamten Verlauf des Softwareprojektes nmedialibray. Michael Karlen, Robert Kölz, Thomas Wittek, Erik Schwidop im Mai 2005

4 Berufsakademie Sachsen Staatliche Studienakademie Dresden Seminargruppe BA03IT1, Gruppe 1 Fachgebiet Softwareentwicklung Projektübersicht

5 Projekt: Dokument: Doc. Nr. Autor nml Projektübersicht nml_2/01 R.Kölz Projektname: (nml) Projektstart: Projektende: Thema: Projektbeschreibung: Verwaltung von Medien Mit soll eine Software geschaffen werden, die das optimierte Verwalten und Handling von digitalen Medien, in Form von mp3 s, Video s und ebooks ermöglicht. Team: Name Status Aufgaben Robert Kölz Projektleiter Projektleitung, Implementierung, Layout, mml Michael Karlen Mitarbeiter Planung & Analyse, Visionen & Pflichtendokumentation Thomas Wittek Mitarbeiter Marketing, Risiko & Testplanung Erik Schwidop Mitarbeiter Test & Deployment, Bedienungsdokumentation

6 Berufsakademie Sachsen Staatliche Studienakademie Dresden Seminargruppe BA03IT1, Gruppe 1 Fachgebiet Softwareentwicklung Projektvision

7 nml Projektvision nml_2/02 M. Karlen Seite 2 von 3 1 Vision 1.1 Projektgegenstand Um bei dem immer größeren Aufkommen an Mediendateien auf Heim-PCs deren Organisation und Auffinden zu erleichtern, soll eine Lösung zur Verwaltung digitaler Medien geschaffen werden. Dieses Projekt beschäftigt sich mit der Herstellung einer multifunktionalen Software, die eine einfache, strukturierte und intuitive Verwaltung, Nutzung und Organisation einer großen Anzahl an Mediendateien ermöglicht. Dies betrifft insbesondere Audio- und Videodateien sowie ebooks. Dadurch soll eine Art elektronischer Medienkatalog für den Heim-PC entstehen. 1.2 Projektname In Anlehnung an den Einsatzzweck der Software tragen Projekt und Applikation den Name "". 1.3 Zielgruppe ist für alle Personen gedacht, die relativ große Mengen an Mediendateien auf dem heimischen PC gespeichert haben. Da sich der Vertrieb und Erwerb von Medien immer mehr in Richtung vernetzte Rechnerwelt verlagert, richtet sich unser Projekt an die Menschen, die bereits heute ihren Medienkonsum größtenteils über den heimischen PC abwickeln. Da es diesbezüglich keine festen Altersgrenzen gibt, lässt sich unsere Zielgruppe hinsichtlich des Alters auch nicht kategorisieren. Wir wollen den heimkinobegeisterten Rentner genauso ansprechen wie den Technikfreak, der noch zu Schule geht. 1.4 Positionierung am Markt Während sich die in der Entwicklungs- und Testphase befindet, ist sie im Internet zum freien Download erhältlich. Auf diese Weise hilft jeder, der die Software herunterlädt und ausprobiert beim Testen und trägt so zur Qualitätssicherung und Beseitigung von Fehlern bei. Ist das Produkt bis zu zur Marktreife fertig entwickelt und getestet, soll der Vertrieb hauptsächlich über den Einzelhandel erfolgen, weil hierüber die Zielgruppe am besten zu erreichen ist.

8 nml Projektvision nml_2/02 M. Karlen Seite 3 von 3 2 Funktionsumfang Unbedingte Funktionen Medienorganisation Mediensuche nach verschiedenen Kriterien Netzwerkfähigkeit Plattformunabhängigkeit Unterstützung von Audio-, Video- und Printmedien Bedingte Funktionen Medienimport Benutzerverwaltung Erstellen von Playlists Wiedergabefunktion Wünschenswerte Funktionen Brennen von Audio-CDs Verfügbarkeit für mobile Endgeräte

9 Berufsakademie Sachsen Staatliche Studienakademie Dresden Seminargruppe BA03IT1, Gruppe 1 Fachgebiet Softwareentwicklung Pflichtenheft

10 nml Pflichtenheft nml_2/03 M. Karlen Inhalt Seite 2 von 8 1 Gegenstand des Dokuments Zielsetzung Entwicklungsprozess Verfahrensweise Implementierung Beschreibung des Workflows Allgemeines Benutzerverwaltung Medientypen Hinzufügen von Medien Import von Medien (MP3) Suchen von Medien Playlists (nur Audio) Anzeigen / Abspielen Erstellen von Audio- oder MP3-CDs Neuheiten Anforderungen Webserver Datenbank Benutzerschnittstelle / Frontend Systemanforderungen Server Client...8

11 nml Pflichtenheft nml_2/03 M. Karlen Seite 3 von 8 1 Gegenstand des Dokuments Dieses Dokument (Pflichtenheft) formuliert Anforderungen, Richtlinien und Verfahrensweisen zur Erstellung einer interaktiven Softwarelösung für die Verwaltung und Recherche digitaler Medien. 2 Zielsetzung Es soll ein multifunktionales Softwareprodukt für Medienverwaltung und recherche erstellt werden. Der Produktname ist "". Die Grundlage dafür bilden eine zentrale Datenbank für die Datenhaltung und ein interaktives Frontend zur Bedienung und strukturierten Darstellung der Informationen. 3 Entwicklungsprozess 3.1 Verfahrensweise Sämtliche Abläufe, Verfahren, Richtlinien und Dokumente während der Entwicklung müssen den Anforderungen der Qualitätsmanagement-Norm ISO 9001 entsprechen. Die Produktentwicklung orientiert sich am Rational Unified Process. Grundlage der eigentlichen Softwareentwicklung ist das V-Modell. Dokumente und Beschreibungen sind so zu gestalten, dass sie auch für am Projekt nicht unmittelbar beteiligte Personen leicht verständlich und nachvollziehbar sind. Notizen, die während der Entwicklung gemacht werden, sind nachträglich mit dem Namen des Verfassers sowie dem Zweck der Notiz zu versehen und den Projektunterlagen beizufügen. 3.2 Implementierung Die Funktionalitäten der einzelnen Module werden PHP implementiert, die Benutzeroberfläche in HTML und Java. Die Sprache für Zugriffe auf die Datenbank ist SQL. Welche Anwendungen und Werkzeuge für die Implementierung benutzt werden, entscheidet der jeweilige Programmierer. Die Verwendung dieser ist jedoch zu dokumentieren. Außerdem ist eine umfassende Dokumentierung jedes Implementierungsschrittes anzufertigen. Dies schließt auch eine plausible und nachvollziehbare Kommentierung des Quellcodes ein. Tabellen- und Datenfeldnamen sowie Namen für Variablen, Datenstrukturen und Funktionen sind ebenfalls zweckentsprechend zu wählen und nachvollziehbar zu dokumentieren.

12 nml Pflichtenheft nml_2/03 M. Karlen Seite 4 von 8 4 Beschreibung des Workflows 4.1 Allgemeines MediaLibary ist ein multifunktionales Verwaltungs- und Informationssystem für digitale Medien. Die Software arbeitet nach dem Client-Server-Prinzip. Sämtliche Informationen über die Medien werden in einer Datenbank gespeichert, die von einem SQL-Server verwaltet wird. Auf dem Webserver sind sämtliche Funktionen der MediaLibrary. Der Webserver ist ebenfalls für die Aufbereitung der Daten und die Darstellung auf den Clients verantwortlich. Die Clients besitzen bis auf bestimmte Zusatzfunktionen keinerlei eigene Intelligenz. Sie dienen lediglich der Dateneingabe und -ausgabe. Die Kernfunktionen der MediaLibrary sind programmiertechnisch in folgende organisatorische Module zu untergliedern: Mediensystem (Eingabe, Import, Export und Verwaltung der Medien) Infosystem (Recherche- und Suchfunktionen) Verwaltungssystem (Benutzerverwaltung) Daten und Informationen beziehen die Webserverdienste vom Datenbankserver. Bei Clientanforderung generiert das betreffende Modul die entsprechende SQl- Abfrage und schickt sie an den Datenbankserver. Die von ihm zurückgegebenen Daten werden für die Anzeige aufbereitet und dem Client in Form einer HTML-Seite zur Verfügung gestellt. 4.2 Benutzerverwaltung Das System soll ausschließlich autorisierten Nutzern mit entsprechenden Rechten zugänglich sein. Für die Verwaltung von Nutzerverwaltung sind Administratorrechte nötig. Möchte der Nutzer auf Funktionen des Systems zugreifen, soll automatisch ein Anmeldefenster eingeblendet werden. Alternativ soll die Anmeldung über eine Schaltfläche im Bildschirmmenü möglich sein. Die Benutzerverwaltung an sich soll über eine separate Maske aus dem Hauptmenü erreichbar sein. Die Daten für jedes Nutzerkonto werden in der Datenbank abgelegt. 4.3 Medientypen Die von MediaLibrary zu unterstützenden elektronischen Medientypen sind:

13 nml Pflichtenheft nml_2/03 M. Karlen Seite 5 von 8 Audiodateien (mp3, wav, wma) Videodateien (avi, mpg) Bücher in elektronischer Form, so genannte ebooks (pdf) Für jeden der drei Medientypen ist in der Benutzeroberfläche eine separate Maske vorzusehen. 4.4 Hinzufügen von Medien Um Medien zur Datenbank hinzuzufügen, soll das Frontend mit einer separaten Maske ausgestattet werden. Die Maske enthält Eingabefelder für jedes Datenwort eines Datensatzes. Nachdem der Nutzer alle Daten eingegeben hat, muss zur Bestätigung eine entsprechende Schaltfläche gedrückt werden, worauf die eingegebenen Daten überprüft und in die Datenbank eingetragen werden. Entsprechen die eingegeben Daten nicht den Konventionen, so ist eine Fehlermeldung auszugeben. Nach der Übernahme der Daten wird der Dateiname der Mediendatei auf Übereinstimmung mit den Dateinamens-Konventionen der überprüft. Ist eine Übereinstimmung nicht gegeben, so wird der korrekte Dateiname aus den in die Datenbank eingegebenen Informationen automatisch entsprechend der Konventionen generiert und die Mediendatei umbenannt. 4.5 Import von Medien (MP3) Alternativ zum herkömmlichen Eintragen der Mediendaten in die Maske, können diese für MP3-Audiodateinen auch durch Dateiimport gewonnen werden. Dazu wird eine entsprechende Maske aufgerufen, wo der Pfad zur Mediendatei anzugeben ist. Nach dem Bestätigen wird der ID3-Tag der Datei ausgelesen. Die Daten werden dann automatisch in die herkömmliche Hinzufügen-Maske eingetragen, wo sie zur Überprüfung angezeigt werden. Hier können sie bei bedarf geändert und dann übernommen werden. Die Überprüfung des Dateinamens erfolg wie bei Punkt Suchen von Medien Die Suchfunktionen sollen über eine separate Suchmaske in der Benutzeroberfläche erreichbar sein. Darüber hat der User die Möglichkeit, eine Abfrage an die Datenbank zu stellen. Dabei soll es möglich sein, nach Künstler bzw. Autor, Titel

14 nml Pflichtenheft nml_2/03 M. Karlen Seite 6 von 8 und/oder Album (bei Audiodateien) zu suchen. Dies ist über ein Eingabefeld und ein Optionsfeld zu realisieren, um den Suchbereich eingrenzen zu können. Die Suchergebnisse werden in Listenform untereinander dargestellt. Dabei ist die Länge der Liste auf 10 Ergebnisse zu beschränken. Liefert die Suche mehr als 10 Ergebnisse, ist die Anzeige über mehrere umschaltbare Seiten zu realisieren. Jeweils ein Ergebnis kann angewählt und über eine Optionsauswahl weiter verarbeitet werden. So können detailiertere Informationen zu einem Ergebnis angezeigt werden, da sich die Menge der Angaben in der Liste aus Platzgründen beschränkt ist. Handelt es sich bei einem Suchergebnis um einen Musiktitel, so kann dieser sofort zur aktuellen Playlist hinzugefügt bzw. abgespielt werden. Sollte keine Playlist vorhanden sein wird automatisch eine bei ersten Hinzufügen eines Titels erstellt. 4.7 Playlists (nur Audio) Über eine separate Maske werden alle in einer Playlist enthaltenen Titel angezeigt. Die Reihenfolge ergibt sich aus der Folge in der die Titel hinzugefügt wurden. Es kann nun die Reihenfolge verändert werden, indem Titel jeweils einzeln nach oben oder nach unten geschoben oder gelöscht werden. Fertige Playlisten können als WinAmp-Playlist auf dem Clientrechner gespeichert werden. 4.8 Anzeigen / Abspielen Die Abspielfunktion für Audiodateien wird über das HTTPQ-plugin von Winamp realisiert. Sie ist von der Liste der Suchergebnisse und von einer Playlist direkt über einen Button erreichbar. Wird der Button betätigt, so soll der ausgewählte Musiktitel abgespielt werden. Handelt es sich beim ausgewählten Medium um ein ebook, so wird der Acrobat Reader zur Anzeige gestartet. Eine Anzeigefunktion für Videos ist nicht vorgesehen. 4.9 Erstellen von Audio- oder MP3-CDs Mit Hilfe einer Brennfunktion soll es dem Nutzer ermöglicht werden, die in einer Playlist enthaltenen Titel als Audio- oder MP3-CD zu brennen. Dazu ist in der Playlist-Maske ein entsprechender Button zu platzieren, über den die Brennfunktion aufgerufen werden kann. Zur Realisierung der Brennfunktion ist das kostenlose Nero SDK zu verwenden. Beim Anklicken des Buttons soll aus der Playlist

15 nml Pflichtenheft nml_2/03 M. Karlen Seite 7 von 8 automatisch der Aufrufstring für das Nero-Kommandozeilenprogramm generiert und dieses gestartet werden. Für Videos und ebooks ist eine Brennfunktion nicht vorgesehen Neuheiten Aus dem Startbildschirm kann der User in die Neuheiten Maske wechseln. Hier werden die neuesten zur Datenbank hinzugefügten Medien Es können hier ebenfalls weitere Informationen angezeigt werden bzw. Titel direkt zu einer Playlist hinzugefügt werden. Sollte keine Playlist vorhanden sein wird automatisch eine bei ersten Hinzufügen eines Titels erstellt. 5 Anforderungen 5.1 Webserver Der Webserver ist die zentrale Komponente der MediaLibrary. Er stellt den Clients die Benutzerschnittstelle in Form einer Website zur Verfügung und bedient Anfragen der Clients, indem er die entsprechenden Daten von der Datenbank anfordert und diese für die Anzeige auf dem Client aufbereitet. Als Serversoftware kommt Apache zum Einsatz. Apache ist freie Software und verursacht so keine zusätzlichen Kosten im Projekt. Sämtliche Funktionsmodule sind auf dem Apache-Server in Form von PHP-Scripten zu hinterlegen. Bei der Serverinstallation und der Programmierung der Module ist zu beachten, dass der Webserver je nach konkreter Einsatzumgebung der Software unter Umständen viele Clientanforderungen gleichzeitig bedienen muss. 5.2 Datenbank Für das Hosting der Datenbank kommt ein MySQL-Server zum Einsatz, an den der Apache-Server sein Anfragen richtet, wenn er Daten benötigt. Der Aufbau der Tabellen und Datenworte ist so zu gestalten, dass eine gute Performanz beim Suchen und Abrufen von Daten gewährleistet wird. Die Mediendateien an sich werden nicht in der Datenbank, sondern im Dateisystem abgelegt. In der dafür zuständigen Tabelle der Datenbank, ist aber ein Verweis auf die Mediendateien in Form ein Pfadangabe und eines Dateinamens zu hinterlegen.

16 nml Pflichtenheft nml_2/03 M. Karlen Seite 8 von Benutzerschnittstelle / Frontend Um MediaLibrary benutzen zu können, ist auf Seiten des Clients nichts weiter als ein Webbrowser erforderlich, da der Apache-Server die komplette Interaktion mit dem Benutzer durchführt. Die Benutzerschnittstelle als Website zu gestalten, die durch den Webserver zur Verfügung gestellt wird. Das Design ist einfach, übersichtlich, linear und funktional zu halten. Es muss den gültigen Richtlinien für ergonomische Webseitengestaltung entsprechen. Der User soll nach dem Login in der Lage sein, zu sämtlichen Masken mit einem einzigen Klick navigieren zu können. Auf umfangreiche Grafiken ist aus Performancegründen zu verzichten. 5.4 Systemanforderungen Server Da Datenbank- und Webserver auf einem einzigen Rechner laufen können, sind bei Auswahl der Hardware und des Betriebsystems die Systemvoraussetzungen von Apache und MySQL zu beachten. Bei der Dimensionierung der Serverhardware ist darüber hinaus die jeweilige Einsatzumgebung zu beachten (Anzahl gleichzeitiger Zugriffe etc.) Client Für Nutzung der Standardfunktionen der MediaLibrary ist lediglich ein Webbrowser erforderlich. Daher ist grundsätzlich jeder internetfähige PC geeignet. Für die Nutzung der Brenn- und Abspielfunktion sind zusatzlich die Systemvoraussetzungen für Nero, Winamp und Acrobat Reader zu erfüllen.

17 Berufsakademie Sachsen Staatliche Studienakademie Dresden Seminargruppe BA03IT1, Gruppe 1 Fachgebiet Softwareentwicklung Projektplanung

18 nml Projektplanung nml_2/04 R. Kölz Inhalt Seite 2 von 12 1 Einleitung Zweck des Projektplans Projektüberblick Entwicklungsphilosophie Vertragliche Grundlagen Beschreibung des Projekts Arbeitsumfang Lieferumfang Resultate, die nicht zum Lieferumfang gehören Entwicklungsplan Aufteilung in Arbeitsphasen Zeitplan mit Aktivitäten und Terminen Projektstrukturplan Budget Risiken, kritische Punkte Anforderung an die Umgebung Rechnersystem, Software Leistungen des Auftraggebers Entwicklungsprozess Phasen der Entwicklung Dokumentation Qualitätskontrolle und sicherung Projektorganisation Schlüsselpersonen Organisation während der Projektphasen Standards für die Entwicklung Konfigurationskontrolle Richtlinien Einsatz von Werkzeugen Spezifische Abweichungen von Standards...12

19 nml Projektplanung nml_2/04 R. Kölz Seite 3 von 12 1 Einleitung 1.1 Zweck des Projektplans Dieser Projektplan soll die Ziele des Projektes, die Zeitplanung für deren Verwirklichung und alle relevanten Bedingungen für das Projekt dokumentieren. So wird der Projektplan ein wirksames Werkzeug zur Steuerung des Entwicklungsprozesses. Die Planung des Projektes ist zu Anfang sehr schwierig, da die Informationen über den Zeitaufwand für einzelne Teilaufgaben erst nach einer Einarbeitung hinreichend genau geschätzt werden können. Deshalb wird der Plan im Laufe des Projektes Änderungen erfahren, die vor allem die Zeitabläufe betreffen können. 1.2 Projektüberblick Mit soll ein multifunktionales Softwareprodukt für Medienverwaltung und recherche erstellt werden. Die Grundlage dafür bilden eine zentrale Datenbank für die Datenhaltung und ein interaktives Frontend zur Bedienung und strukturierten Darstellung der Informationen. Das Programm soll in erster Linie zur besseren, schnelleren, einfacheren und übersichtlicheren Verwendung der auf dem Heim PC befindlichen Mediendaten (Musik, Video, Bücher) dienen. Das System soll im Wesentlichen folgende Funktionen abdecken: Darstellung von Informationen zu den entsprechenden Medien Auskunft über Medienbestand Verwaltung und Pflege der Medien Hinzufügen neuer Medien Nutzung der Medien (z.b. mp3 abspielen, CD brennen, etc.) 1.3 Entwicklungsphilosophie Bei der Bearbeitung des Projektes sollten Prinzipien des Systemengineerings zur Anwendung kommen, um eine hohe Qualität der Ergebnisse und die Einhaltung der Ablaufplanung sicherzustellen. Eine gute Dokumentation aller Arbeitsergebnisse ist erforderlich, um deren Verwendung durch Dritte zu ermöglichen und um das Verständnis bestehender, schlecht dokumentierter Programmteile zu erleichtern. Um eine hohe Qualität des

20 nml Projektplanung nml_2/04 R. Kölz Seite 4 von 12 Sourcecodes und der Dokumente sicherzustellen, sollten allgemeine Programmierrichtlinien sowie die Dokumentenrichtlinien der Berufsakademie Dresden eingehalten werden. 2 Vertragliche Grundlagen Da dieses Projekt im Rahmen der Lehrveranstaltung Software-Entwicklung an der BA-Dresden entstanden ist, steht als Auslieferungstermin der Dokumentation der Die Implementierung des Programms muss bis zu diesem Zeitpunkt noch nicht abgeschlossen sein. Jedoch sollte sie soweit voran geschritten sein, dass am eine funktionsfähige Beta Version präsentiert werden kann. Da dieses Projekt als Open-Source gestartet wurde, stehen bis zu diesem Zeitpunkt keine Kosten für das Endprodukt fest. Sollten sich die Möglichkeit einer allgemeinen Vermarktung bieten, kann der Preis frei gewählt werden. 3 Beschreibung des Projekts 3.1 Arbeitsumfang Das durchzuführende Softwareprojekt umfasst folgende Teilaufgaben: 1. Analyse: Einholen von Informationen zur Erhebung des Ist- und Soll- Zustands 2. Projektplanung: Festlegen der einzelnen Arbeitspakete und Meilensteine, 3. Terminplanung 4. Einarbeitung in die Spezifikationssprache UML und verwendete CASE-Tools Rational Rose bzw. Microsoft Visio. 5. Spezifikation des Softwaresystems: Festlegen der Anforderungen an die Funktionalität 6. des Systems, Festlegen der nicht-funktionalen Anforderungen (Qualität, Benutzungsoberflächen) 7. Durchführen von Spezifikationsreviews, Nachbearbeiten der Spezifikation 8. Erstellen eines Benutzerhandbuchs 9. Erstellen eines Prototyps: Festlegen der Systemarchitektur (Aufteilung des Systems in Klassen; Angabe der Methoden und Schnittstellen zwischen den einzelnen Teilsystemen) 10. Implementierung des Programms in PHP 11. Erstellung eines Testplans und Durchführung der Testes

21 nml Projektplanung nml_2/04 R. Kölz 3.2 Lieferumfang Seite 5 von 12 Zum Lieferumfang gehören neben dem ausführbaren Programm auch der Quellcode, eine Installationsanleitung, das Benutzungshandbuch und die Spezifikation. Das lauffähige Programm soll folgende Programmpakete mit der jeweils angegebenen Funktionalität umfassen: Modul Informationssystem Das Informationssystem beinhalten alle Funktionen, die dem User Informationen über die in der Datenbank eingetragenen Elemente geben. Die Informationen sind: Status zu Anzahl der Elemente (Alben, Songs, Videos, Bücher) Angaben zu Medien (Titelname, Albumname, Buchtitel, etc.) Spezifische Angaben Medien (Autor, Interpret, Künstler, Erscheinungsdatum, Genre) Modul Mediensystem Das Mediensystem dient der Benutzung der Datenbankelemente durch den User, die in entsprechenden Funktionen implementiert ist. Die Funktionen sind: Abspielen von mp3 s über die Winamp-Steuerung Anlegen eigener Playlisten Exportieren der Playlisten in entsprechenden Programme (z.b. Nero-SDK) Modul Verwaltungssystem Das Verwaltungssystem dient der Wartung und Pflege der Medienbibliothek, dessen Funktionen daher hauptsächlich dem Systemadministrator vorbehalten sind. Die Funktionen sind: Datenbankpflege Systempflege (Backend / Frontend) Einfügen / Löschen von Medien Bearbeiten von Medien bzw. derer Informationen

22 nml Projektplanung nml_2/04 R. Kölz Seite 6 von Resultate, die nicht zum Lieferumfang gehören Nicht zum Lieferumfang gehören alle zusätzlich erstellten Dokumente, konkret der Entwurf, der Testplan, das Testprotokoll, die Testdaten sowie die Testmedien. 4 Entwicklungsplan 4.1 Aufteilung in Arbeitsphasen Da in diesem Projekt nach dem Kreislaufmodell vorgegangen wird, wurden 3 großen Phasen festgelegt, die jeweils ihre Teilaufgaben beinhalten. Somit kann sichergestellt werden, das erst dann in eine neue Phase gegangenen wird, wenn alle Kriterien zum erfolgreichen Abschluss der vorangegangenen Phase erfüllt sind. Phase 1 (1. Runde) Arbeitsschritte: Marktanalyse Projektplanung allgem. Feinspezifikation erstellen Implementierung Prototyp (incl. Webserver, DB) Test & Deployment Prototype allgem. Feinspezifikation überarbeiten Meilensteine: Projektstart / Start 1. Runde Implementierungsstart Prototyp Prototyp funktionstüchtig Ende 1. Runde Phase 2 (2. Runde) Arbeitsschritte: Datenbankentwurf Feinspezifikation für Medien-, Info- & Verwaltungssystem erstellen Feinspezifikation für mml erstellen Aufsetzen Backend (Webserver+Datenbank) Erstellung Designoberfläche (GUI) Erstellung Klickdummy

23 nml Projektplanung nml_2/04 R. Kölz Seite 7 von 12 Implementierung Grundfunktionen, Info- & Verwaltungssystem Implementierung mobile MediaLibrary (mml) Test & Deployment Version 1.0 & mml Meilensteine: Start 2. Runde Start Subprojekt Mobile MediaLibrary Implementierungsstart Version 1.0 & mml Abschluss mml Abnahme Version 1.0 Phase 3 (finale Runde) Arbeitsschritte: Erstellung Bedienungsanleitung Spezifikation abschließen, Dokumentenabschluss Implementierung Finale Version mit Mediensystem Test & Deployment Finale Version Meilensteine: Start 3. Runde Implementierungsstart Finale Version Abnahme Dokumente Abnahme Finale Version Projektabgabe Projektpräsentation 4.2 Zeitplan mit Aktivitäten und Terminen Die folgende Tabelle enthält grob zusammengefasst den Arbeitsaufwand für die einzelnen Arbeitspakete in Tagen. Zusätzlich sind die Meilensteine und die geplanten Fertigstellungstermine angegeben. Die detaillierte Übersicht über die einzelnen Arbeitsschritte, ist in Form eines MS-Projekt-Plans beigefügt. Ein Meilenstein ist erreicht, wenn die dazugehörige Software oder Dokumentation einen durch das Team definierten Status erreicht hat.

24 nml Projektplanung nml_2/04 R. Kölz Seite 8 von 12 ID Vorgangsname Aufwand in Tag Termin Meilenstein 1 Marktanalyse Projektplanung Erste allgemeine Spezifikation erstellen Ersten Prototypen Prototyp fertig Implementieren & Testen 5 Allgemeine Spezifikation 1. Runde abgeschl Überarbeiten 6 Feinspezifikation mml Spezifikation mml 7 Datenbankentwurf Feinspezifikation der Module (Info+Verwaltung+Medien) Aufsetzen Backend (Webserver+Datenbank) Entwurf Design für Oberfläche Erstellung Klickdummy mml Implementieren & Testen mml fertig 13 Info- & Verwaltungssystem Implementieren & Testen Test & Deployment Version Version 1.0 fertig 15 Spezifikation abschließen Mediensystem Implementieren & Testen Test & Deployment finale Abnahme finale Version Version 18 Dokumenteabschluss Projektabgabe 19 Vorbereitung für Präsentation Projektpräsentation Eine genaue Auflistung der Vorgänge und Kriterien der Phasen ist dem Phasenplan zu entnehmen. 4.3 Projektstrukturplan Produkt MediaLibrary Modul Infosystem Modul Mediensystem Modul Verwaltungssystem Datenbanksystem Medieninformationen Dokumentation Trägermaterialien Zusatz-Software

25 nml Projektplanung nml_2/04 R. Kölz Seite 9 von 12 Projektunterlagen Projektplan (diese Dokument) Risikoplan QS-Plan Moduldokumentationen Projektinfrastruktur PHP / ASPX mysql / MS-SQL Nero SDK Winamp HTTPQ-plugin Marketing Materialien Flyer Wartung Online-Support Vor-Ort-Installation (optional, sehr kostenintensiv) 4.4 Budget Da dieses Projekt in der Freizeit der Teammitglieder bzw. im Rahmen der Lehrveranstaltung umgesetzt wird, werden keine Kosten für die Arbeitszeiten berechnet, was zur Folge hat, das es kein Budgetlimit im eigentlichen Sinne gibt. Um auch die Kosten, die für die praktische Realisierung des Projektes benötigt werden, so gering wie möglich zu halten, wird versucht möglichst Freeware Produkte einzusetzen. 4.5 Risiken, kritische Punkte Für das Projekt relevante Risiken sind im Risikoplan festgehalten. 5 Anforderung an die Umgebung 5.1 Rechnersystem, Software Rechnersystem: Standard Heim PC Betriebssystem: MS Windows XP Entwicklungsumgebung: MS Visio & Projekt, XAMPP, PHP, Java J2ME

26 nml Projektplanung nml_2/04 R. Kölz 5.2 Leistungen des Auftraggebers Seite 10 von 12 Die Berufsakademie Dresden stellt Lehrmaterialen und Ansprechpartner zur Verfügung, die einen erfolgreichen Abschluss des Projekts, mit Hauptaugenmerk auf die Dokumentationen, ermöglichen sollen. Der Auftraggeber nimmt die Spezifikation und das lauffähige System ab. Er steht für Rückfragen zu den Anforderungen zur Verfügung. 6 Entwicklungsprozess 6.1 Phasen der Entwicklung Das Projekt wird nach dem Aktivitätenmodell entwickelt. Die jeweiligen Aktivitäten sind bereits in Abschnitt 4.2 behandelt worden. 6.2 Dokumentation Es werden folgende Dokumente während der Entwicklung entstehen: Vision Pflichtenheft Projektplanung (dieses Dokument) Bedienungsanleitung Guidelines Testpläne Projektstrukturplan Risikoplan Die Richtlinien für Dokumente in den Guidelines gelten für alle entstehenden Dokumente. Alle Dokumente werden vom Projektteam in einem Projektordner verwaltet. 6.3 Qualitätskontrolle und sicherung Die Qualitätssicherung soll eine hohe Qualität des Entwicklungsprozesses und der erzielten Ergebnisse sicherstellen. Das erfordert, dass die angestrebten Qualitätsaspekte dokumentiert und Vorgehensweisen entwickelt werden.

27 nml Projektplanung nml_2/04 R. Kölz Seite 11 von 12 Organisatorische Maßnahmen: Die Projektfortschritte werden regelmäßig, mindestens alle zwei Wochen geprüft und gegebenenfalls die Zeitplanung angepasst. Analytische Maßnahmen: Die entstandenen Dokumente werden in Reviews geprüft und das Programm einem Test nach einem vorbereiteten Testplan unterzogen. In Reviews werden Dokumente auf die Einhaltung von Richtlinien hin überprüft. Abgenommene Dokumente stellen Meilensteine dar, auf die dann mit höherer Sicherheit aufgebaut werden. 7 Projektorganisation 7.1 Schlüsselpersonen Kunde: BA-Dresden Projektteam: Projektleiter Robert Kölz Mitarbeiter1 Thomas Wittek Mitarbeiter2 Erik Schwdop Mitarbeiter3 Michael Karlen 7.2 Organisation während der Projektphasen Projektteam: Software- und Dokumente- Entwicklung mit selbständiger Terminüberwachung und Qualitätssicherung. Kunde: Teilnahme an Reviews, Abnahme des Systems

28 nml Projektplanung nml_2/04 R. Kölz Seite 12 von 12 8 Standards für die Entwicklung 8.1 Konfigurationskontrolle Alle Dokumente und Entwicklungsergebnisse sollen der Konfigurationskontrolle unterliegen. Geprüfte und abgenommene Dokumente können nur nach Absprache von Kunde und Bearbeiter geändert werden. Änderungen werden vom Bearbeiter vorgenommen. Geänderte Dokumente müssen erneut durch ein Review geprüft werden. Alle Dokumente werden vom Bearbeiter in einem Projektordner gehalten. Elektronische Dokumente werden in Abständen von höchstens zwei Wochen auf Disketten archiviert, jeweils eine Kopie im Projektordner und beim Kunden. 8.2 Richtlinien Die Projektsprache ist Deutsch. Alle weiteren Richtlinien sind den Guidelines zu entnehmen. 8.3 Einsatz von Werkzeugen Für die Erstellung der Spezifikation und des Entwurfs werden die Werkzeuge MS Projekt und MS Visio eingesetzt. Für die Erstellung der Dokumente wird das Textverarbeitungssystem MS Word verwendet. Grundlage für den Webserver mit Datenbank bildet das bereits vorgefertigte System XAMPP der Apachefriends. Für die Implementierung des Frontends wird das Programmiertool PHPEdit eingesetzt sowie NetBeans mit Mibilitytoolkit für den mobilen Clienten. 8.4 Spezifische Abweichungen von Standards Im Allgemeinen gibt es keine Abweichungen, sollten dennoch welche auftreten, werden diese in den Guidelines festgehalten.

29 Berufsakademie Sachsen Staatliche Studienakademie Dresden Seminargruppe BA03IT1, Gruppe 1 Fachgebiet Softwareentwicklung Projektdokumentation

30 Die Projektdokumentation beinhaltet: Phasenplan Risikoplan Testpläne Richtlinien (Guidelines) Konventionen für Mediendateien Bedienungsanleitung Auf eine extra Dokumentation der Qualitätssicherung wurde verzichtet, da dieser Punkt bereits in der Projektplanung sowie den Guidelines festgehalten ist.

31 Berufsakademie Sachsen Staatliche Studienakademie Dresden Seminargruppe BA03IT1, Gruppe 1 Fachgebiet Softwareentwicklung Phasenplan

32 nml Phasenplan nml_2/06 R. Kölz Seite 2 von 4 1 Gegenstand des Dokuments In diesem Dokument geht es um die einzelnen Abläufe innerhalb der einzelnen Phasen. Es wird geklärt welche Aufgaben zu erledigen sind, welche Meilensteine gesetzt sind und welche Kriterien es zur Erfüllung der Aufgaben gibt. 2 Detaillierte Phasenbeschreibung 2.1 Phase1 Gegenstand: In der 1. Phase geht es hauptsächlich darum, den Rahmen für das Projekt zu setzten. Dazu muss geklärt werden, welche ähnlichen Projekte bzw. Programme es schon auf dem Markt gibt, wer mit unserem Programm erreicht werden soll und wie groß der Funktionsumfang überhaupt werden soll. Hat man ein Grundkonzept, geht es daran einen ersten Prototypen zu erstellen, um daraus erste Problem bzw. Grenzen der Umsetzungsmöglichkeiten erkennen zu können und dahingehend die Spezifikationen anzupassen. Arbeitsschritte: Marktanalyse Projektplanung allgem. Feinspezifikation erstellen Implementierung Prototyp (incl. Webserver, DB) Test & Deployment Prototype allgem. Feinspezifikation überarbeiten Meilensteine: 1. Meilenstein Projektstart / Start 1. Runde ist erreicht wenn: - hat keine Kriterien, da Initialisierung des Projektes Meilenstein wurde erfüllt? ja Anmerkung Sonst geht ja nix los

33 nml Phasenplan nml_2/06 R. Kölz Seite 3 von 4 2. Meilenstein Implementierungsstart Prototyp ist erreicht wenn: - Grundlegende Funktionen bekannt sind und diese Bereits in den Spezifikationen enthalten - bereits erste Fragen bezüglich der Machbarkeit aufgetreten sind Meilenstein wurde erfüllt? ja Anmerkung Mit Prototyp müssen richtungsweisende Funktionen getestet werden 3. Meilenstein Prototyp funktionstüchtig ist erreicht wenn: - Implementierung abgeschlossen - Test & Deployment abgeschlossen - erste Grundfunktionen umgesetzt - Team einstimmig beschließt das reicht für s erste Meilenstein wurde erfüllt? ja Anmerkung Such- und Anzeigefunktionen konnten umgesetzt werden, Datenimport hat erstes Nadelöhr bezüglich der Performance gezeigt, WinAmp-Control bereits eingebunden 4. Meilenstein Ende 1. Runde ist erreicht wenn: - Prototyp erfolgreich Implementiert und getestet - Rahmen für Funktionsumfang des Programms gesteckt - Spezifikation bezüglich der Erkenntnisse aus Prototyp angepasst Meilenstein wurde erfüllt? ja Anmerkung Termin konnte eingehalten werden

34 nml Phasenplan nml_2/06 R. Kölz Seite 4 von Phase2 Vorgehensweise gleich Phase1. Arbeitsschritte und Meilensteine für Phase 2 (2. Runde) sind Projektplan zu entnehmen. 2.3 Phase3 Vorgehensweise gleich Phase1. Arbeitsschritte und Meilensteine für Phase 2 (2. Runde) sind Projektplan zu entnehmen.

35 Berufsakademie Sachsen Staatliche Studienakademie Dresden Seminargruppe BA03IT1, Gruppe 1 Fachgebiet Softwareentwicklung Risikoplan

36 nml Risikoplanung nml_2/07 T. Wittek Inhalt Seite 2 von 6 1 Einleitung Risikoidentifizierung Software Hardware Organisation Risikoübersicht...5

37 nml Risikoplanung nml_2/07 T. Wittek 1 Einleitung Seite 3 von 6 Um den planmäßigen Entwicklungsablauf nicht zu gefährden, wurden mögliche Risiken genauer analysiert und mit Wertigkeiten zwischen 1-10 benotet. Zur besseren Übersicht wurden die Risken in die 3 Kategorien Software, Hardware und Organisation unterteilt. 2 Risikoidentifizierung 2.1 Software Risiko: Datenformat Da die Dateneingabe weitläufig automatisch abläuft, wird ein genormtes Datenformat benötigt. Stehen die Daten nicht in diesem Format zur Verfügung, können die Daten nicht erkannt werden. Risikobeseitigung Definition der Datenformatkonventionen als Richtlinie bei der Datenerstellung. Risiko: Browser Um dem Kunden den größtmöglichen Bedienkomfort zu bieten, wurde die neuste Browsertechnologie eingesetzt. Wenn der Kunde nicht über einen aktuellen Browser verfügt, kann unsere Software nicht genutzt werden. Risikobeseitigung Auslieferung der aktuellen Browserversion. Risiko: Winamp Damit der Winamp Mediaplayer von einem externen Programm gesteuert werden kann wird ein Plugin benötigt. Wenn der Kunde dieses Plugin nicht besitzt kann Winamp nicht eingesetzt werden. Risikobeseitigung Auslieferung mit Plugin und Einbindung in die Installationsroutine.

38 nml Risikoplanung nml_2/07 T. Wittek Seite 4 von 6 Risiko: Nero Über das Nero SDK kann die Nero Brennfunktionalität in eigene Programme integriert werden. Steht diese nicht zur Verfügung, können keine Medien auf CDs gebrannt werden. Risikobeseitigung Alternative Playlisten Exportfunktion entwerfen. M3U Playlisten können mit aktuellen Brennprogrammen geöffnet werden. Risiko: DB Mit jeder neuen Version der MySQL Datenbank werden neue Funktionen eingeführt. Fallen dabei alte Funktionen weg, wäre die Software nicht mehr kompatibel. Risikobeseitigung Beschränkung auf die Standardfunktionen der MySQL Datenbank. 2.2 Hardware Risiko: Systemausfall Fällt der Medienserver aus, ist das komplette System nicht mehr nutzbar. Risikobeseitigung In kritischen Einsatzgebieten kann die Wahrscheinlichkeit eines Systemausfalls mit Redundanten Servern minimiert werden. 2.3 Organisation Risiko: Dateiformat In der aktuellen Version verwendet die für Musik das mp3 Audioformat. Wenn ein neues Standard-Audioformat auf dem Markt kommt, kann dieses mit zusätzlichen Lizenzkosten verbunden sein. Risikobeseitigung Weitergabe der Lizenzkosten an den Kunden wenn dieser das neue Audioformat wünscht.

39 nml Risikoplanung nml_2/07 T. Wittek Seite 5 von 6 Risiko: CVS Die Entwicklung der wird mit einer CVS Plattform über den öffentlichen Sourceforge Server verwaltet. Fällt dieser Server aus, können die Entwickler nicht auf die Quelldateien zugreifen. Risikobeseitigung Den Quellcode auf mehreren öffentlichen Servern ablegen. Risiko: Zeitplan Da der Zeitplan für das Fach Software Engineering sehr knapp kalkuliert ist kann die Software eventuell nicht fertig gestellt werden. Risikobeseitigung Schneller arbeiten und zur Not auch nachts. Mit Herrn Pitschke Schwerpunkte besprechen. Risiko: Implementierung Da die Entwickler sich noch in der Ausbildung befinden, kann es sein das ihre Fähigkeiten und Kenntnisse noch nicht ausreichen um alle Punkte der Produktvision umzusetzen. Risikobeseitigung Eventuell alternative Lösungsansätze finden oder die betroffenen Module aus dem Funktionsumfang streichen. 3 Risikoübersicht Wert Risiko Beschreibung Typ Auswirkung 4 Datenformat Medien sind Daten werden nicht Software inkonsistent richtig erkannt 3 Browser IE in älter Version Plattform wird nicht bzw. anderer Software richtig angezeigt Browser 3 Winamp 1 Nero Plugin nicht installiert SDK nicht vorhanden Software Software Winamp nicht steuerbar Medien können nicht auf CD gebrannt werden

40 nml Risikoplanung nml_2/07 T. Wittek Seite 6 von 6 5 DB Neue DB Version Software 10 Systemausfall 8 Dateiformat System nicht erreichbar Neues Format kommt auf den Markt Hardware Organisation 2 CVS Plattform fällt aus Organisation 6 Zeitplan 4 Implementierung Zeitplan kann nicht eingehalten werden Teil der Vision nicht umsetzbar Organisation Organisation Plattform inkompatibel Benutzung unmöglich Kann nicht auf Plattform implementiert werden Aktueller Entwicklungstand kann nicht festgehalten werden Schneller arbeiten / Ext Ressourcen hinzuziehen Ausweichmöglichkeiten finden / Modul streichen

41 Berufsakademie Sachsen Staatliche Studienakademie Dresden Seminargruppe BA03IT1, Gruppe 1 Fachgebiet Softwareentwicklung Testplan

42 nml Testplan nml_2/08 T. Wittek Seite 2 von 5 Inhalt 1 Einleitung Testvorbereitung Oberfläche Datenbank Testdefinitionen Zu testende Komponenten Zu testende Funktionen Testdurchführung Oberfläche Datenbank Auswertung...5

43 nml Testplan nml_2/08 T. Wittek Seite 3 von 5 1 Einleitung Für die Sicherstellung der Funktionalität der MediaLibrary, muss jede Entwicklerversion ausführlich getestet werden. Damit wird entschieden ob neue Features eingebaut werden oder die Vorhandenen verbessert werden. Ziel ist es unser Produkt einer möglichst breiten Masse zugänglich zu machen. Dafür müssen vor allem die weit verbreiteten Softwareapplikationen getestet werden. Da unsere Software auf Standard-PCs läuft, reicht es aus, wenn auffällige Softwarerkombinationen, die den sicheren Betrieb unserer Software gefährden, den Installationshinweisen hinzugefügt werden. Das reduziert erheblich den Testaufwand und verlagert die Testintensität zugunsten unserer Software. 2 Testvorbereitung 2.1 Oberfläche Um die Benutzeroberfläche intensiv zu testen, stellen wir 3 Verschiedene Testkonfigurationen zusammen. Die Versionen der XAMPP Applikationen sind bei allen Testrechnern identisch und entsprechen den bei der Entwicklung verwendeten. Als Betriebssysteme kommen Windows 2000 und XP zum Einsatz. Da der Internetbrowser für die korrekte Darstellung verantwortlich ist, führen wir die Tests mit den drei aktuellen Marktführern durch: den Microsoft Internet Explorer 6.0, den Microsoft Internet Explorer 5.5 und Mozilla Firefox 1.0. Als Hardware wird Standard PC Technik verwendet. Unsere Rechner besitzen Pentium 4 Prozessoren mit 512MB Arbeitsspeicher. Um die minimalen Systemvorraussetzungen zu ermitteln verwenden wir einen Pentium 3 mit 256 MB Arbeitsspeicher. 2.2 Datenbank Die Funktionalität der Datenbank können wir nur durch eine geeignete Konfiguration beeinflussen. Um die Stabilität im Betrieb testen zu können, werden sehr große Dateiimporte durchgeführt. Dazu werden mehrere Medientitel in die Datenbank geladen.

44 nml Testplan nml_2/08 T. Wittek 3 Testdefinitionen Seite 4 von Zu testende Komponenten Bei den zu testenden Komponenten wird die meiste Aufmerksamkeit auf die korrekte Darstellung im Internetbrowser und der Funktionalität der Datenbank gelegt. Allerdings ist auch das Zusammenspiel der einzelnen Komponenten von Bedeutung. Gibt es in einer bestimmten Software- oder Hardwarekonstellation Probleme, werden diese in die Installationshinweise aufgenommen. 3.2 Zu testende Funktionen Oberfläche: Da die Oberfläche aus dynamischem Html-Code besteht, können nicht alle eintretenden Situationen getestet werden. Daher wird die Darstellung für unsere Testdatenbestände geprüft. Die aktiven Komponenten, wie Menüs und Buttons müssen darüber hinaus zu jeder Zeit bedienbar sein. Datenbank: Die Anforderungen die an die Datenbank gestellt werden, sind nicht besonders hoch. 90% der Zugriffe werden über Select-Anweisungen realisiert. Diese müssen auf semantische Fehler geprüft werden. 4 Testdurchführung 4.1 Oberfläche Dauertest mit den verschiedenen Internetbrowserversionen. Microsoft IE 6.0 Microsoft IE 5.5 Mozilla Firefox 1.0 Darstellung erfolgreich erfolgreich erfolgreich Menüs und Button erfolgreich erfolgreich erfolgreich

45 nml Testplan nml_2/08 T. Wittek 4.2 Datenbank Seite 5 von 5 Um die Richtigkeit der Select-Anweisungen zu Prüfen, werden Testdatensätze erstellt, bei denen die Ergebnisse bekannt sind um diese mit den jeweiligen Ausgaben zu vergleichen. 5 Auswertung In der getesteten Version (Programm Version 0.3 Oberfläche 0.6) arbeiten Datenbank und Oberfläche zuverlässig. Die Oberfläche kann damit weitere Features aufnehmen und wird in Version 0.7 weiterentwickelt.

46 Berufsakademie Sachsen Staatliche Studienakademie Dresden Seminargruppe BA03IT1, Gruppe 1 Fachgebiet Softwareentwicklung Guidelines

47 nml Richtlinien nml_2/09 M. Karlen Inhalt Seite 2 von 7 1 Gegenstand des Dokuments Zielsetzung Änderung / Ergänzung der Richtlinien Richtlinien für Dokumente Gestaltung Ablage Programmierrichtlinien Grundlegende Regeln Quellcode Programmierstil Bezeichner Funktionen und Prozeduren Richtlinien für die Ablage von Dateien...7

48 nml Richtlinien nml_2/09 M. Karlen Seite 3 von 7 1 Gegenstand des Dokuments Die vorliegende Richtlinie regelt die Erarbeitung, Verwendung und Aktualisierung von Abläufen und Rahmenbedingungen im Softwareprojekt. 2 Zielsetzung Die hohe Qualität der Software kann nur durch eine qualitativ hochwertige und effiziente Abwicklung aller Planungs-, Entwicklungs- und Testprozesse im Verlauf des Projektes erreicht werden. Dieses Dokument enthält dafür die grundlegenden Richtlinien und Anweisungen. 3 Grundsätzliches Der gesamte Projektverlauf ist unbedingt im Sinne der betrieblichen Richtlinien zur Zertifizierung nach ISO 9000 durchzuführen. 4 Änderung / Ergänzung der Richtlinien Änderungen und Ergänzungen der Richtlinienregelungen bedürfen grundsätzlich der Zustimmung aller am Projekt beteiligten Personen. Verantwortlich für die Durchführung der Abstimmungen ist der Projektleiter. Nach Zustimmung der Projektbeteiligten und Bestätigung durch den Projektleiter erfolgt die Verteilung und verbindliche Anwendung. Die Originale sind zu archivieren. Der neue Ausgabestand wird gegen die veralteten Exemplare ausgetauscht. Die nunmehr ungültigen Exemplare werden als solche gekennzeichnet bzw. vernichtet. Die Teamleiter haben für ihren Verantwortungsbereich sicherzustellen, dass alle gültigen Regelungen eingehalten werden. 5 Richtlinien für Dokumente 5.1 Gestaltung Sämtliche das Projekt betreffende Dokumente sind gemäß der im Folgenden beschriebenen Richtlinien einheitlich zu gestalten. Ein Dokument enthält folgende Mindestelemente: Deckblatt mit Name und Nummer des Dokuments, Name der Verteiler, Name und Unterschrift des Verfassers und des Projektleiters Inhaltsverzeichnis

49 nml Richtlinien nml_2/09 M. Karlen Seite 4 von 7 Begriffsverzeichnis, in dem die verwendeten Fachbegriffe dargelegt werden Abkürzungsverzeichnis mit Auflistung und Erklärung der verwendeten Abkürzungen Zweck des Dokuments, aus dem Zielstellung und, soweit erforderlich, Grundlagen des Dokuments ersichtlich werden Inhalt mit eindeutiger Gliederung und kurzen, präzisen und eindeutigen Ausführungen zum Sachverhalt Anlagen (optional), in denen der Inhalt näher erläutert und präzisiert wird Kopfzeile (außer Deckblatt) mit Projekt, Dokumentennummer mit Schlüssel "nml_[abschnitt]/[teilabschnitt]", Dokumentenname, Gesamtseitenzahl des Dokuments, Seitenzahl des jeweiligen Blattes, Name des Bearbeiters / Verfassers Als Schriftart ist Arial mit Schriftgrad 12 und Blocksatz-Ausrichtung zu verwenden. Der Zeilenabstand ist 1,5-fach zu wählen. Überschriften und Gliederungspunkte sind zusätzlich fett und linksbündig zu formatieren. 5.2 Ablage Dokumente, die in Papierform vorliegen, werden in Ringbuchordner abgeheftet und gemäß der betrieblichen Richtlinien für die Dauer des Projekts so abgelegt, dass sie leicht und jederzeit verfügbar sind. Nach Abschluss des Projekts werden die Dokumente archiviert. Jede Art von handschriftlichen Notizen, die betreffen, sind, den Dokumenten gleich, einzuordnen und zu archivieren. Dafür sind sie vorher mit einem speziellen Stempel zu versehen. In das Stempelfeld hat der Verfasser seinen Namen, das Datum und den Kontext der Notiz zu vermerken. 6 Programmierrichtlinien Zweck der nachfolgend dokumentierten Programmierrichtlinien ist die einheitliche Gestaltung und Strukturierung des Programmcodes sämtlicher zu programmierenden Softwarekomponenten des Projekts. Dadurch soll die Softwareerstellung in allen Entwicklungsphasen des Projekts möglichst effizient, transparent und fehlerarm gehalten werden. Ziel hierbei ist es, einen leicht lesbaren und verständlichen Quellcode zu erzeugen.

50 nml Richtlinien nml_2/09 M. Karlen Seite 5 von Grundlegende Regeln Alle Teile des Projektes sollen logisch gegliedert, leicht zu lesen und zu verstehen sein. 6.2 Quellcode Der Aufbau des Quellcodes ist so zu gestalten, dass dadurch eine mögliche spätere Portierung auf andere Plattformen erleichtert wird. Er ist in allen Modulen einheitlich zu gestalten. Konkret bedeutet dies: einheitliche Einzüge und Blockstrukturen einheitliche und verständliche Kommentargestaltung Verwendung der englischen Sprache in der Kommentierung und in der Wahl der Bezeichner Quellcodezeilen sollten eine Länge von 80 Zeichen nicht überschreiten 6.3 Programmierstil Beim Programmieren ist prinzipiell von so genannter trickreicher Codierung abzusehen. Gemeint ist damit die Verwendung nicht allgemein bekannter Rechenregeln oder Programmiertechniken. Größter Wert sollte auch auf ausreichende und plausible Dokumentierung und Kommentierung des Quellcodes gelegt werden. 6.4 Bezeichner Der Begriff "Bezeichner" umfasst Namen von Objekten (instantiierten Klassen), Variablen und Konstanten. Für leichte Lesbarkeit und Verständlichkeit eines Programms ist die Verwendung geeigneter Bezeichnungen von essentieller Bedeutung. Der Name eines Bezeichners soll dessen Inhalt und Bedeutung widerspiegeln. Er besteht aus einem optionalen Präfix, dem eigentlichen Namen und einem ebenfalls optionalen Suffix. Außerdem sollen aus dem Namen ebenfalls Datentyp und Gülltigkeitsbereich des Bezeichners hervorgehen. Alle Namen sind gemäß der im Folgenden dokumentierten Konventionen zu vergeben. Lediglich bei Gefahr von Verwechslung oder Zweideutigkeit kann im Ausnahmefall von den Konventionen abgewichen werden.

51 nml Richtlinien nml_2/09 M. Karlen Seite 6 von 7 Es dürfen ausschließlich Buchstaben, Ziffern und Unterstriche verwendet werden. Alle Variablen, Konstanten und Objekte werden unmittelbar nach ihrer Erstellung mit einem Namen versehen. Es dürfen keine reservierten Namen verwendet werden. Der Verwendungszweck des Bezeichners muss erkennbar sein. Das Namenspräfix wird klein geschrieben und gibt in verkürzter Form den Typ des Bezeichners wieder. Der eigentliche Name ist groß zu schreiben. Bei mehrsilbigen Namen beginnt jede Silbe mit einem Großbuchstaben. Werden einfache Variablen (i, j, k, usw.) für Schleifen usw. verwendet, so können diese ohne direkten Namen vereinbart werden. Jede Konstantendeklaration enthält einen Kommentar zu ihrer Bedeutung 6.5 Funktionen und Prozeduren Bevor der Programmierer mit dem Erstellen eigener Funktionen und Prozeduren beginnt, hat er in jedem Fall zu prüfen, ob für den jeweiligen Zweck bereits Routinen vorhanden sind. Der Einsatz von schon existenten Routinen kann sowohl den Entwicklungs- als auch den Testaufwand erheblich reduzieren. Ist trotzdem eine Neudefinition von Funktionen oder Prozeduren erforderlich, sind bei deren Benennung folgende Regeln einzuhalten: Namen von Routinen beginnen immer mit Großbuchstaben. Routinennamen beginnen grundsätzlich mit einem Verb. Die Verwendung von Reservierten Namen ist nicht zugelassen. Der Verwendungszweck und Funktionalität müssen im Namen erkennbar sein. Bei der Programmierung einer Routine ist am Anfang des Quellcodes ein Kopf aus Kommentarzeilen einzufügen, in denen der Programmierer seinen Namen, das Bearbeitungsdatum, Name der Funktion sowie deren Zweck und eine kurze Beschreibung der Arbeitsweise vermerkt.