Donnerstag, 25. Juli 2013

Ist-Anlayse Teil 1 - Worum gehts dabei

Was ist eine Ist-Analyse

Ein Begriff aus dem Projektmanagement, auch bekannt als Ist-Aufnahme beschreibt die Planungphase in der Probleme objektiv festgestellt und bewertet werden. In diesem speziellen Fall, der Erstellung einer Software können natürlich noch keine Probleme in der Software erkannt werden. Deshalb beschäftigt sich die Ist-Analyse bezogen auf mein MMORTS mit der Betrachtung bereits existierender Produkte, deren Stärken und Schwächen und des Marktes. Hierbei wird erst die Größe und Sättigung des Marktes für Online-Spiele im allgemeinen und speziell für MMORTS untersucht. Anschließend werden bestehende MMORTS nach noch zu definierenden Kriterien analysiert. Als letzter Schritt meiner Ist-Analyse kommt die Ist-Kritik. Diese kann erstaunliche Ergebnis über die Probleme existierender Spiele und damit enorme Chancen für kreative Köpfe aufzeigen. Oder auch dazu führen das ein Projekt bereits frühzeitig zu Grabe getragen wird.

Recherche

Links ist zu erkennen das ich  bereits mit der Erstellung des Lastenhefts begonnen habe und die Ist-Analyse soweit Gegliedert ist. Nun folgt Recherche, Recherche, Recherche. Wobei letzteres einen angenehmem Aspekt hat nämlich das Spielen, natürlich nach streng wissenschaftlichen Vorgaben. Zuvor müssen Daten und Fakten gesammelt, gesichtet und ausgewertet werden.

Ist das nicht übertrieben?

Tatsächlich ist es eine verbreitete Ansicht, das eine Ausführliche Ist-Analyse schlichtweg zu aufwendig und teuer ist. Hier wird oft mit der sogenannten Verzichtsthese argumentiert, diese besagt das die Kenntniss des aktuellen Zustands wenig zur Problemlösung beiträgt. Es ist leicht erkennbar das ich eher ein Anhänger der Pflichtthese bin, meiner Meinung nach sind qualitativ hochwertige Erkenntnisse und Aussagen der Ist-Analyse unabdingbar. Wer weiterlesen möchte: wikipedia, Gabler Wirtschaftslexikon

Freitag, 19. Juli 2013

Lastenheft Vorbereitung

Was ist ein Lastenheft?

Ein Lastenheft beschreibt den Soll-Zustand des fertigen Produkts. Es ist wichtig umfassend und genau zu die Projektziele zu beschreiben. Jeder muss in der Lage sein die Anforderungen nachzuvollziehen. Hierbei werden die Eigenschaften und Funktionen ohne Einbeziehung technischer Aspekte formuliert, um den Auftragnehmer bei der Problemlösung möglichst nicht einzuschränken.

Der Aufbau

  • Titel, Projektname, Auftraggeber
  • Historie der Dokumentversion: Nicht nur von Bedeutung wenn mehrere Personen an der Erstellung mitarbeiten, sondern auch für den Fall das sich im Laufe des Projekts Anforderungen ändern.
  • Einleitung: Eine Kurzfassung des Projektziels bzw. der Projektdefinition. Benutzte Abkürzungen, projektspezifische Begriffe bzw Begriffe die innerhalb des Projekts mit einer von der allgemeinen Bedeutung abweichenden Definition
  • Ist-Zustand: Beschreibt den aktuellen Zustand vor Beginn des Projekts. In diesem Fall die Sichtdung von existierenden Konkurrenzprodukten und deren Bewertung, sowie eine Analyse des Marktes sowie der potenziellen Kunden.
  • Soll-Zustand:Der bei weitem umfangreichste Teil des Lastenhefts. Kann unterteilt werden in die endgültigen Produktmerkmale (in diesem Fall: Features), Weiterentwicklung, Pflege, Qualitätsmerkmale sowie den erwarteten Markterfolg und die damit verbundenen Erträge.

Ziele des Lastenhefts

Das Lastenheft dient anfangs vor allem als Kommunikationsbasis für Auftraggeber und Auftragnehmer. Daraufhin dient es dem Auftragnehmer als Grundlage für den Lösungsvorschlag, also das Pflichtenheft und in dem Zusammenhang ein Angebot inklusive Kostenvoranschlag. Es bleibt auch für den gesamten Lebenszyklus des Projekts von großer Bedeutung. Bei Fertigstellung und Übergabe des Produktes ist die Erfüllung des Lastenhefts, Grundlage für die Abnahme durch den Kunden und damit die.Bezahlung.

Donnerstag, 18. Juli 2013

Projektplanung aber richtig.

Wie plane ich ein Projekt richtig?

Wissen ist Macht - Das Team Schulen

Zu aller erst sollten Begriffe geklärt werden und dass gesamte Projektteam zumindest Basiswissen der Materie vorweisen können. Im Prinzip ganz einfach denn Lesen bildet. Wer sich zum ersten mal mit dem Thema befasst wird von der Komplexität schockiert sein. Allein der Wikipedia-Beitrag zur Projektplanung bedarf einiger konzentrierter Minuten. Ich fand noch einige Quellen die ich persönlich für Hilfreich halte, es lohnt sich das Material zu sichten und das beste für sich herrauszuziehen. Siehe Linklist unten.

Umgang mit dem Wissen

Zur Festigung, Vertiefung und Verfügbarkeit des Know-How werde ich ein eigenes Glossar erstellen, indem ich Begriffsdefinitionen, erweiterte Erklärungen und eigene Kommentare sammle. Zu gegebenem Zeitpunkt werde ich diese Sammlung dann auch hier veröffentlichen. Als Essenz der Sichtung der Literatur ist es mir möglich die nächsten erforderlichen Schritte strukturiert anzugehen.

Einsatz des neuen Wissens

Ich lernte das alles bisher getane eher in die Phase der Projektdefinition  fällt. Nun soll die Planung beginnen, also los. Ich unterteile die Planung in acht aufeinander aufbauende Schritte.
  • Lastenheft: Auch Anforderungskatalog bzw. Anforderungsbeschreibung genannt, wird durch den Auftraggeber ausgearbeitet. Es enthält eine Beschreibung des Sollzustandes des Fertigen Produkts.
  • Pflichtenheft: Beschreibt detailiert die technische Realisierung aller Anforderungen des Lastenhefts durch den Auftragnehmer. Auch werden explizite Lösungsvorschläge Ein- und auch Ausgeschlossen.
  • Aufwandsschätzung: Es wird geschätzt wie viele Personen und Zeit für jeden einzelnen Programmteil benötigt wird. Zu erwähnen sind einige teils umstrittene, populäre Schätzverfahren wie z.B. Price-to-Win, Delphi-Methode oder das Parkinson-Verfahren.
  • Terminplanung: Unter Berücksichtigung des Ablaufplans insbesondere der kritischen Pfade werden die Projektschritte mit konkreten Kalenderdaten versehen.
  • Materialplanung: Enthält nicht nur die Ressourcen die zur Erstellung sondern auch zum späteren Betrieb und Wartung benötigt werden.
  • Finanzplanung: Die Kapitalbedarfsplanung und Liquiditätsplanung bestimmt wann und wie viel Geld zur Verfügung stehen muss.
  • Risikomanagement: Besonders bei längeren Projekten, drohen erhebliche schwer absehbare Risiken. Es gilt Vorgehensweisen für die frühzeitige Erkennung und den Umgang mit Risiken festzulegen, also in erster Linie die Installation von Kontrollmechanismen.
  • Erstellung einer Dokumentation: Hiermit ist nicht die Dokumentation des fertigen Produktes zu verstehen, sondern die Dokumentation der Planung. Nur so kann gewährleisted werden, dass Fehler und Probleme während der Entwicklung erkannt und behoben werden können.

Der nächsten Teil wird sich also mit der Erstellung eines Lastenhefts beschäftigen.

Donnerstag, 11. Juli 2013

Planung für den Erfolg

Planungsphase planen

Es ist kein Widerspruch und auch nicht übertrieben. Auch die Planungsphase, als erste kritische Phase, muss durchdacht sein und die Charakteristika jeder anderen Projektphase aufweisen. So muss auch der erste Teil der Realisierung in Teilprojekte aufgeteilt und klar definiert werden. Der Abschluss jedes Teilprojekts ist ein Meilenstein, der in einem zufor definierten Zeitrahmen erreicht werden muss. Man muss Start und Ziel kennen um anschließend die zurückgelegte Wegstrecke und den Erfolg zu überprüfen.
Für geneigte Leser: Wikipedia . Projektmanagement
 

Das Werkzeug - CoP2go

Es ist naheliegend das eine Projektplanung nicht einfach auf Backpapier gekrakelt werden sollte. Eine Projektsteuerungssoftware muss her. Meiner Kenntnis nach ist MS Project auf diesem Gebiet der Platzhirsch, Microsoft ist aber nicht jedermanns Sache. Also gebe ich einer Freeware die Chance, die Wahl fiel auf Cop2go. Der Anbieter die SMC GmbH - Software Management Consulting erweckt durchaus den Eindruck hier ein Tool mit Potential geschaffen zu haben. Auch wird Web-Freundlicher Export durch das Programm angeboten, sodass die Weltöffentlichkeit den Fortschritt evaluieren kann.

Erster Schritt der Planung

Das primäre Projektziel ist zum 01.Mai 2014 eine Betaphase zu starten. Bis zu diesem Datum muss eine spielbare Version fertig gestellt werden. Aber Version von was? Es soll ein mmorts bzw. Massive-Multiplayer-Online-Real-Time-Strategy Game werden. Das fertige Produkt soll sich durch Komplexität in den Bereichen Wirtschaftsystem, Allianzfunktionen, Technologien und militärisch/taktische Möglichkeiten unterscheiden. Die Spielwelt wird aus verschiedenen Landschaften wie Wüsten, Steppen und Wäldern bestehen. Große Seen, Flüsse, Schluchten und Gebirgsketten bilden Hindernisse bieten aber auch Schutz. Die gesamte Landschaft soll dynamisch und durch die Spieler veränderbar sein sprich Rodung, Verwüstung, Bewässerung usw.. Das soll nur ein kleiner Abriss der Gedanken in meinem Kopf sein.

Ein Fuß vor den anderen

Meine primäre Aufgabe besteht jetzt also darin mich in CoP2go einzuarbeiten wobei mir die Planung der Planung als gutes Praxisbeispiel dient. Der nächste Beitrag wird sich also mit der Definition von Teilprojekten, Meilensteinen, Ressourcen und kritischen Vorgängen beschäftigen. Jeder Projektmanagement-Interessierte ist herzlich eingeladen.

Dienstag, 9. Juli 2013

Ein eigenes MMO erstellen

 In diesem Blog beschreibe ich wie ein MMO entsteht. Vorraussichtlich mache ich alles selbst. Ich werde von der Idee über die Planung und Umsetzung bis hin zur Testphase und Inbetriebnahme das Projekt dokumentieren.

Aller Anfang ist schwer

Jeder der gern vor dem Bildschirm sitzt und mit Begeisterung, stundenlang ein Spiel welcher Art auch immer zockt, hatte irgendwann mal den Gedanken "Ich würde sowas gern mal selbst erstellen". Dies führt schnell zur Frage "Wie erstelle ich mein eigenes super tolles Spiel?". Sollte man diese Fragestellung googln stößt man hauptsächlich auf die Antwort "Am besten gar nicht!". Man findet auch Erklärungen wieso man es nicht selber macht. Der Hauptgrund besteht darin das es schon unzählige Versuche gab die zu oft schon in frühen Phasen eingestellt wurden. Kurz nachdem die angehenden Entwickler das ganze Ausmaß des imensen Aufwands erkannt haben.

Der Gegenbeweis

Hiermit trete ich den Gegenbeweis an. Ich werde es schaffen, in meiner Freizeit. Ich bin davon überzeugt ein solches Projekt allein stemmen zu können. Auch wenn meine umfangreichen Kenntnisse verschiedener Script- und Datenbanksprachen meine Defizite in Kreativität und Design nicht ausgleichen bin ich optimistisch. Schließlich lernt man nie aus. So sehe ich optimistisch in ein Jahr vieler Stunden des Programmierens und Testens, einer vielzahl von kleinen Erfolgen und nochmehr Fehlschlägen.

Jetzt: Auf! Auf! Ich fange an.