Montag, 26. Oktober 2009   1
An Introduction to Game DesignDocumentation and Project Management                           tim.nuechel@stud.unibas.chMon...
Faktoren, die einer Entwicklung         zum Verhängnis werden können                  • Die Zieldefinition ist             ...
Warum eine                           Pre-Production?Montag, 26. Oktober 2009                     4
Argumente für eine                             Pre-Production                  • Sie motiviert in der eigentlichen Produkt...
Argumente für eine                             Pre-Production                  • Sie ermöglicht (überhaupt erst) die späte...
Montag, 26. Oktober 2009   7
Montag, 26. Oktober 2009   8
Projekt Kick-Off                           Kernziel-Checkliste                                            Definition der Pr...
• Der kreative Prozess kann in der Pre-Production                           zielorientierter erfolgen                  • S...
Das Design Dokument                       Am Beispiel von Related Design und                                   Anno 1404Mo...
Wer wird das Design                       Dokument lesen?                  • Designer: Sie wollen Ideen festhalten und mit...
Was Designer wissen                           sollten       Dinge die    Programmierer          Hauptsätze   Imperativ    ...
Montag, 26. Oktober 2009   14
Regeln für ein gutes DDD                      Ein nützliches DDD muss...:                  •        ...sich kurz fassen   ...
„Im Fall des Scheiterns wird das             DDD            ein    Schattendasein    als             ungeliebtes Mauerblüm...
(Aktuelles DDD=Ordnung)       > (veraltetes DDD=Chaos)Montag, 26. Oktober 2009          17
Ein Wiki hat den                            Vorteil, dass...:       • ...übersichtliche Layouts          • ...Einträge abo...
Anno 1404 Standard-                      Designeintrag                  • Name               • Regeln                  • V...
So nicht:              „Schiffe werden in unterschiedliche Schiffstypen              unterteilt. Wir unterscheiden die sto...
Warum schlecht?                  • Fließtext                  • Keine Formatierung                  • Uneinheitliche Namen...
Bitte so:       Schiffstyp          Kanonen Ladevolumen Flugtauglichkeit  Handelsschiff              Nein      [groß]     ...
Was gehört denn                            nun in ein DD?                      Erstmal zwei abschreckende Beispiele:Montag...
Designer Nr. 1, der                               „Visionär“              •Er steht dem Team sehr nahe,              manch...
Designer Nr. 2, der                             „Theoretiker“          •Er hat alles genau geplant.          •Nach monatel...
Der allgemeine Aufbau kann in sieben        große Blöcke eingeteilt werden:                  • Grundlagen                 ...
Grundlagen                  • Alle Rahmendaten sowie strategische                           und spieltheoretische Aspekte ...
Spielregeln                  • Alle im Spiel vorkommenden                           Features, aber nicht die Inhalte      ...
Spielinhalte                  • Alle Assets, die von Grafikern,                           Textern, Level- und Gamedesignern...
Montag, 26. Oktober 2009   30
Interface                  • Alle Komponenten, über die der                           Spieler mit dem Spiel kommunizieren ...
Grafik                  • Aussagekräftiger Styleguide                  • Alle im Spiel vorkommenden,                       ...
Montag, 26. Oktober 2009   33
Montag, 26. Oktober 2009   34
Sound                  • Alle akustischen Signale, denen man                           im Spiel begegnen kann             ...
Tools                  • Beschreibung des technischen                           Instrumentariums                  • Stellu...
Muster eines DDD    1.     Grundlagen                    3.   Spielinhalte                 •   Gebäude           •      Ra...
Warum                           Projektplanung                              scheitertMontag, 26. Oktober 2009             ...
Standish Group 1994, CHAOS Report:           In der IT Branche sind nur    16,2 % aller           Projekte „on-time“ und „...
Warum Projektplanung scheitert                                    Die täglichen Lügen        • Der Publisher verspricht de...
Warum Projektplanung scheitert                                  Die täglichen Lügen        • Irgendwann nimmt der Projektl...
Regel Nummer 1 beim                  Projektmanagement                  • Was sagt mir mein gesunder                      ...
Regel Nummer 2              stammt direkt von Albert Einstein                  • „Mache die Dinge so einfach wie          ...
Fragen im                             Kick-Off Meeting                  • Wie weit soll man die Tasks granulieren?        ...
Die Sache mit den                          MilestonesMontag, 26. Oktober 2009                   45
Aber wo liegen die                 Wurzeln dieses Übels?                               Kosten                            P...
• Eine Planung sollte niemals auf Basis von                           Terminen, sondern immer Ressourcen und              ...
Montag, 26. Oktober 2009   48
Welche Aufgaben                hat ein Projektleiter                           - und welche nicht?Montag, 26. Oktober 2009...
Die vielen, unterschiedlichen Aufgabenbereiche eines Projektleiters in der Übersicht.                                Produ...
Wer glaubt, dass ein Projektleiter Projekte leitet, der glaubt auch, dass ein Zitronenfalter Zitronen faltet!“          Ty...
Die Aufgaben des          Projektleiters sind nicht:                  • ...für die Teammitglieder zu denken.              ...
Bei der Taskplanung                       lauten diese Frage:                     Wer (Ausführender) macht...             ...
Die S.M.A.R.T                           Zielformulierung                  • S pecific (genau, exakt beschrieben?)          ...
Woran liegt es, dass man          so oft daneben liegt?                    • Zu grobe Einteilung der Tasks                ...
Die Dreifach-Schätzung              Best Case - Einschätzung: 10 Tage              Most Likely - Einschätzung: 15 Tage    ...
Vielen Dank fürs                  Zuhören und viel Erfolg                   bei euren zukünftigen                         ...
Nächste SlideShare
Wird geladen in …5
×

Game Design Dokumentation und Projekt Management

3.475 Aufrufe

Veröffentlicht am

http://fg-informatik.unibas.ch/wiki/index.php/An_Introduction_to_Game_Design_Documentation_and_Projectmanagement

0 Kommentare
1 Gefällt mir
Statistik
Notizen
  • Als Erste(r) kommentieren

Keine Downloads
Aufrufe
Aufrufe insgesamt
3.475
Auf SlideShare
0
Aus Einbettungen
0
Anzahl an Einbettungen
3
Aktionen
Geteilt
0
Downloads
20
Kommentare
0
Gefällt mir
1
Einbettungen 0
Keine Einbettungen

Keine Notizen für die Folie

Game Design Dokumentation und Projekt Management

  1. 1. Montag, 26. Oktober 2009 1
  2. 2. An Introduction to Game DesignDocumentation and Project Management tim.nuechel@stud.unibas.chMontag, 26. Oktober 2009 2
  3. 3. Faktoren, die einer Entwicklung zum Verhängnis werden können • Die Zieldefinition ist • Die Planung beruht auf unzureichend, nicht unzureichenden überprüfbar und zu Spezifikationen und spezifisch. Annahmen. • Die Ziele wurden nicht • Somit sind auch keine verbindlich definiert und echten Kontrollen fixiert. (Soll != Ist) möglich. • Nicht alle notwendigen • Die Risiken in der Planung Informationen wurden im sowie die Vorfeld gesammelt und Rahmenbedingungen evaluiert. wurden nur unzureichend berücksichtigt. • Es wurden keine spezifischen Anforderungen • Die genauen Anforderungen festgelegt. an Organisations- und Prozessabläufe wurden nicht verbindlich definiert.Montag, 26. Oktober 2009 3
  4. 4. Warum eine Pre-Production?Montag, 26. Oktober 2009 4
  5. 5. Argumente für eine Pre-Production • Sie motiviert in der eigentlichen Produktion das gesamte Team durch die im Vorfeld geschaffene Transparenz, Zielorientierung und den messbaren Fortschritt. • Veränderungen und Anpassungen in der Organisation während der laufenden Produktion eines Spiels sind viel schmerzhafter als in der Vorproduktion. • Sie ist effektiv, weil Veränderungen im Kleinen wahrscheinlicher sind als im Großen. • Sie ist effektiv, weil wichtige Entscheidungen noch nicht unter Sachzwängen gefällt werden müssen.Montag, 26. Oktober 2009 5
  6. 6. Argumente für eine Pre-Production • Sie ermöglicht (überhaupt erst) die spätere Steuerung der Produktion durch Kontrolle. • Sie ist günstiger, weil sie eine iterative Vorbereitung mit Wenigen bedeutet. Erst anschließend erfolgt die Umsetzung mit Vielen. • Sie ist rationaler, weil ein No-Go am Ende der Pre- Production erheblich leichter fällt (Kosten, Teammotivation). • Sie ist rationaler, weil Entscheidungen auf Basis von Fakten und nicht aus dem Bauch heraus getroffenMontag, 26. Oktober 2009 6
  7. 7. Montag, 26. Oktober 2009 7
  8. 8. Montag, 26. Oktober 2009 8
  9. 9. Projekt Kick-Off Kernziel-Checkliste Definition der Prozesse Proof-of-Concept-Prototyp Erstellung der Change Control Core-Spielmechanik Dokumentation Approval-Prozesse Definition der Gameplay Zieldefinition & Vision Qualität Statement QA-Prozesse GUI- & Game Design Dokument Build Prozesse Steuerungsprototyp Art/Style Guide Version-Control & Definition der Backup Grafikqualität Level-/World- & Story-Guide Konfliktmanagement Sound-Proof Technical Design Guide Planung Game-Design Risiko- Evaluierung Feature Liste & Definition Umfang abgeschlossen Beurteilung und Qualität Technologie-Prototyp Definition der Organisation Task- & Ressourcenplanung Basic Toolbase Teamstruktur abgeschlossen Budgetierung Projektrollen Middleware Evaluation & Milestone Definitionen Prototype abgeschlossen Meetings Risiko Analyse Basis für 3D-Engine Reporting intern/mit dem Recruitmentplan definiert & abgeschlossen Publisher Marketing Technical-Backend Kontrolle der externen abgeschlossen Ressourcen Konkurrenzanalyse Technische Risiko- Zielgruppenanalyse Evaluierung abgeschlossenMontag, 26. Oktober 2009 9
  10. 10. • Der kreative Prozess kann in der Pre-Production zielorientierter erfolgen • Sie sollte iterativ angelegt werden, so dass die Produktion nur noch einer geradlinigen Abarbeitung festgelegter Ziele entspricht • Macht‘s wie der preußische General Helmut von Moltke „Erst wägen, dann wagen!“Montag, 26. Oktober 2009 10
  11. 11. Das Design Dokument Am Beispiel von Related Design und Anno 1404Montag, 26. Oktober 2009 11
  12. 12. Wer wird das Design Dokument lesen? • Designer: Sie wollen Ideen festhalten und miteinander austauschen • Publisher: Er will – meist in Gestalt des Producers – überprüfen, ob Design und Produkt übereinstimmen und den Anforderungen gerecht werden. • Programmierer: Sie sehen das DDD als eine Sammlung von Arbeitsaufträgen und Inhalten, die am Ende der Produktion ein fertiges Spiel ergeben sollen. • QA und Testing: Sie wollen alle Regeln und Inhalte des Spiels überblicken und überprüfen, ob sie die erforderliche Qualität und Quantität aufweisen. • Outsourcing Partner: Sie wollen schnellen Zugriff auf alle für sie relevanten Informationen zur Erstellung zusätzlicher Spielinhalte (z.B. Grafiken, Missionen, Musik etc.)Montag, 26. Oktober 2009 12
  13. 13. Was Designer wissen sollten Dinge die Programmierer Hauptsätze Imperativ Bulletpoints Diagramme mögen Dinge die Programmierer Nebensätze Konjunktiv Fließtext Designerprosa hassenMontag, 26. Oktober 2009 13
  14. 14. Montag, 26. Oktober 2009 14
  15. 15. Regeln für ein gutes DDD Ein nützliches DDD muss...: • ...sich kurz fassen • ...sein Layout vereinheitlichen • ...Redundanzen vermeiden • ...Begründungen von Regeln trennen • ...Bilder, Diagramme und Flowcharts bevorzugen • ...Imperativ statt Konjunktiv verwenden • ...ein verbindliches Glossar enthalten • ...ständig aktualisiert werdenMontag, 26. Oktober 2009 15
  16. 16. „Im Fall des Scheiterns wird das DDD ein Schattendasein als ungeliebtes Mauerblümchen fristen und hilflos dem Chaos beiwohnen, das unweigerlich beginnt sich auszubreiten.“Montag, 26. Oktober 2009 16
  17. 17. (Aktuelles DDD=Ordnung) > (veraltetes DDD=Chaos)Montag, 26. Oktober 2009 17
  18. 18. Ein Wiki hat den Vorteil, dass...: • ...übersichtliche Layouts • ...Einträge abonniert leicht zu erstellen und zu werden können, sodass verwalten sind. man bei Aktualisierungen per Mail benachrichtigt • ...Einträge miteinander wird. verlinkt werden können. • ...Einträge wie in Foren • ...jede Version eines von jedem Nutzer Eintrags jederzeit wieder kommentiert werden hergestellt werden kann. können. • ...alle Versionen eines • ...Bilder, Galerien, Musik Eintrags miteinander und Filme leicht zu verglichen werden integrieren sind. können.Montag, 26. Oktober 2009 18
  19. 19. Anno 1404 Standard- Designeintrag • Name • Regeln • Verantwortliche • Balancing • Status • FAQ • Definition • Implementierungs details • Kurzbeschreibung • SchaubilderMontag, 26. Oktober 2009 19
  20. 20. So nicht: „Schiffe werden in unterschiedliche Schiffstypen unterteilt. Wir unterscheiden die stolzen Bezwinger der sieben Weltmeere am besten in Handelsschiffe, Kriegsschiffe und fliegende Schiffe. Handelsschiffe besäßen demnach keine Kanonen, könnten aber mehr Ladung an Bord nehmen als Kriegsschiffe und die fliegendem Schiffe. Die Kriegsschiffe sollten hingegen viel mehr Kanonen als fliegende Schiffe besitzen, könnten aber evtl. deutlich weniger Ladung an Bord nehmen als z.B. Handelsschiffe. Flugschiffe besäßen optimalerweise weniger Kanonen als militärische Schiffe, könnten dafür aber mehr Ladung an Bord nehmen als Letztere. Ausserdem sollten Flugschiffe, wie schon ihr Name sagt, als einzige Schiffe hoch oben über den Wolken und Dächern der Städte ihre Runden drehen können.“Montag, 26. Oktober 2009 20
  21. 21. Warum schlecht? • Fließtext • Keine Formatierung • Uneinheitliche Namensgebung • Redundanzen • Unklare Formulierungen • DesignerprosaMontag, 26. Oktober 2009 21
  22. 22. Bitte so: Schiffstyp Kanonen Ladevolumen Flugtauglichkeit Handelsschiff Nein [groß] Nein Kriegsschiff [viele] [gering] Nein Flugschiff [wenige] [mittel] jaMontag, 26. Oktober 2009 22
  23. 23. Was gehört denn nun in ein DD? Erstmal zwei abschreckende Beispiele:Montag, 26. Oktober 2009 23
  24. 24. Designer Nr. 1, der „Visionär“ •Er steht dem Team sehr nahe, manche sagen „auf den Füßen“. •Er hat jeden Tag neue Ideen, die das Spiel nach vorne bringen soll und teilt diese meist im persönlichen Monolog mit. •Ein Designdokument existiert nicht. •So wird es zumindest vermutet, gesehen oder gar gelesen hat es noch keiner. •Aber tatsächlich gibt es auf seinem Laptop zwei halbseitiges .txt Dateien, die er irgendwann einmal fortführen will. •Das ist sein „Designdokument“.Montag, 26. Oktober 2009 24
  25. 25. Designer Nr. 2, der „Theoretiker“ •Er hat alles genau geplant. •Nach monatelanger einsamer Arbeit erblickt sein Werk das Licht der Welt. •Als ein Mitarbeiter es ausdrucken wollte musste er fünfmal Papier nachfüllen und schließlich die Druckerpatrone wechseln. •Niemand hat es bisher geschafft, das monumental Werk des Theoretikers ganz zu lesen, aber alle sprechen in Ehrfurcht davon. •Nun leistet es wertvolle Dienste als Sichtschutz, Fußschemel oder Monitorsockel.Montag, 26. Oktober 2009 25
  26. 26. Der allgemeine Aufbau kann in sieben große Blöcke eingeteilt werden: • Grundlagen • Spielregeln • Spielinhalte • Interface • Grafik • Sound • ToolsMontag, 26. Oktober 2009 26
  27. 27. Grundlagen • Alle Rahmendaten sowie strategische und spieltheoretische Aspekte • „Mission Statement“ • Spielflussbeschreibung • Gern vergessen: Theoretische Basis des SpielsMontag, 26. Oktober 2009 27
  28. 28. Spielregeln • Alle im Spiel vorkommenden Features, aber nicht die Inhalte • Spielphysik • Spielsteuerung • Spielmodi • KIMontag, 26. Oktober 2009 28
  29. 29. Spielinhalte • Alle Assets, die von Grafikern, Textern, Level- und Gamedesignern erstellt werdenMontag, 26. Oktober 2009 29
  30. 30. Montag, 26. Oktober 2009 30
  31. 31. Interface • Alle Komponenten, über die der Spieler mit dem Spiel kommunizieren kann • Styleguide • Spielerführung • MenüsMontag, 26. Oktober 2009 31
  32. 32. Grafik • Aussagekräftiger Styleguide • Alle im Spiel vorkommenden, konkreten Grafikassets (Artbook)Montag, 26. Oktober 2009 32
  33. 33. Montag, 26. Oktober 2009 33
  34. 34. Montag, 26. Oktober 2009 34
  35. 35. Sound • Alle akustischen Signale, denen man im Spiel begegnen kann • Styleguide • Systemfrage (statisch, dynamisch?) • Quantitative FragenMontag, 26. Oktober 2009 35
  36. 36. Tools • Beschreibung des technischen Instrumentariums • Stellung in der Toolchain • Anforderungen an neue Tools • Verbesserungswünsche zu existierenden ToolsMontag, 26. Oktober 2009 36
  37. 37. Muster eines DDD 1. Grundlagen 3. Spielinhalte • Gebäude • Rahmendaten • Charaktere • Objekte • Mission Statement • Einheiten • Vegetation • Brand-DNA • Gebäude • Gegenstände • Gameflow • Objekte • Effekte • Lernkurve • Vegetation • Sequenzen und Videos • Spielphase • Ausrüstung 6. Sound • USPs • Story • Spielflussbeispiele • Szenarien • Styleguide • Spielertypen • Missionen • Musiken 2. Spielregeln 4. Interface • Soundeffekte • Feature-Spezifikation • Styleguide • Interface-Sounds • Steuerung • Hauptmenü • Soundsystem 7. Tools • Kamera • In-Game-Interface • Spielphysik • Feedbacks • Toolchain • KI • Optionen • Welt-Editor • Spielmodi • Tastaturbelegung • Level-Editor 5. Grafik • Effekt-Editor • Styleguide • Text-Editor • Charaktere • Lokalisations-Kit • EinheitenMontag, 26. Oktober 2009 37
  38. 38. Warum Projektplanung scheitertMontag, 26. Oktober 2009 38
  39. 39. Standish Group 1994, CHAOS Report: In der IT Branche sind nur 16,2 % aller Projekte „on-time“ und „on-budget“. 31,1 % kommen zu spät und/oder laufen finanziell aus dem Ruder. 52,7 % aller Projekte werden noch vor Fertigstellung eingestampft.Montag, 26. Oktober 2009 39
  40. 40. Warum Projektplanung scheitert Die täglichen Lügen • Der Publisher verspricht dem Studioleiter vollen Support - lässt ihn aber bei der ersten Milestone Zahlung im Regen stehen. • Der Coder verspricht dem Technical Director einen wichtigen Task bis Freitag fertig gestellt zu haben – zwei Wochen später wartet aber immer noch das gesamte Team darauf und kann nicht weiterarbeiten • Das Marketing möchte nur noch einen hochaufgelösten Pappaufsteller des Orcs für die Games Convention – aber einen Tag vor Messebeginn kommt eine Liste über 200 Screenshots, einige Highresolution Artworks und einen Videotrailer...bis gestern bitte.Montag, 26. Oktober 2009 40
  41. 41. Warum Projektplanung scheitert Die täglichen Lügen • Irgendwann nimmt der Projektleiter dieses Verhalten als gegeben hin. Dies führt dazu, dass irgendwann Schuldige oder zumindest Gründe gesucht werden. Der Projektmanager ist zu unerfahren, die technischen Probleme haben uns zurückgeworfen oder die beliebteste Ausrede: Das Budget war einfach zu knapp bemessen. „Wenn wir das Budget von Blizzard hätten, ja dann! Dann könnten wir...“ • Aber auch Projekte mit 20, 40 oder 200 Millionen Dollar brauchen doppelt so lange oder kosten dreimal so viel und scheitern genauso oft wie kleine...Nur lauter.Montag, 26. Oktober 2009 41
  42. 42. Regel Nummer 1 beim Projektmanagement • Was sagt mir mein gesunder Menschenverstand?Montag, 26. Oktober 2009 42
  43. 43. Regel Nummer 2 stammt direkt von Albert Einstein • „Mache die Dinge so einfach wie möglich, aber nicht einfacher!“Montag, 26. Oktober 2009 43
  44. 44. Fragen im Kick-Off Meeting • Wie weit soll man die Tasks granulieren? • Welche Tools sollen für den Workflow eingesetzt werden? • Wie sollen Verzögerungen gehandhabt werden? • Wie wird miteinander kommuniziert? • Wie oft finden wann warum welche Meetings statt?Montag, 26. Oktober 2009 44
  45. 45. Die Sache mit den MilestonesMontag, 26. Oktober 2009 45
  46. 46. Aber wo liegen die Wurzeln dieses Übels? Kosten Projektdreieck Zeit QualitätMontag, 26. Oktober 2009 46
  47. 47. • Eine Planung sollte niemals auf Basis von Terminen, sondern immer Ressourcen und Qualität beruhen • Am Anfang stehen nicht die Milestones, sondern die Definition des angestrebten Ergebnisses • Dann folgt die Zeiteinschätzung der Tasks • Und danach die Planung des Ablaufs anhand derMontag, 26. Oktober 2009 47
  48. 48. Montag, 26. Oktober 2009 48
  49. 49. Welche Aufgaben hat ein Projektleiter - und welche nicht?Montag, 26. Oktober 2009 49
  50. 50. Die vielen, unterschiedlichen Aufgabenbereiche eines Projektleiters in der Übersicht. Production Marketing (Task- und Projektplanung (Schnittstelle zum & Tracking) Publisher) R&D Human Ressources (Sicherstellung der Projektleiter (Konfliktlösung, Projektdokumentation) Ressourcenplanung) Finance Managing (Budgetplanung und (Projektvertretung Kostentracking) gegenüber Studiohead)Montag, 26. Oktober 2009 50
  51. 51. Wer glaubt, dass ein Projektleiter Projekte leitet, der glaubt auch, dass ein Zitronenfalter Zitronen faltet!“ Typische Anzeichen für „Anerzogene Hilflosigkeit“: • ...bei auftretenden Problemen die Arme verschränken und sich passiv verhalten. • ...nur am Nörgeln und Jammern sind. • ...Konflikte nicht lösen, sondern aussitzen. • ...nicht über den Tellerrand schauen, sondern sich nur um ihren eigenen kleinen Bereich kümmern („Was geht mich fremdes Elend an?“) • ...ihre Versprechen (und damit auch die Zeiteinschätzung) nicht einhalten. • ...mit jedem kleinen Problem zum Projektleiter rennen, damit er das bitteschön für sie lösen soll.Montag, 26. Oktober 2009 51
  52. 52. Die Aufgaben des Projektleiters sind nicht: • ...für die Teammitglieder zu denken. • ...jedem Mitarbeiter seine Arbeit nachzutragen. • ...die Methoden und Tools vorzugeben.Montag, 26. Oktober 2009 52
  53. 53. Bei der Taskplanung lauten diese Frage: Wer (Ausführender) macht... • ...was(Aufgabe, Arbeitspaket) • ...bis wann(Abgabetermin) • ...mit welchem wie gemessenem Ergebnis (Ziel- und Erfolgskriterien) • ...wozu (wird diese Aufgabe später gebraucht)Montag, 26. Oktober 2009 53
  54. 54. Die S.M.A.R.T Zielformulierung • S pecific (genau, exakt beschrieben?) • M easurable (messbar?) • A ttainable (erreichbar?) • R elevant (Ziel auch wirklich wichtig?) • T imed (wann fertig?)Montag, 26. Oktober 2009 54
  55. 55. Woran liegt es, dass man so oft daneben liegt? • Zu grobe Einteilung der Tasks • Keine genaue Definition der Qualitäts- und Zielkriterien • Der Coder sitzt nicht 8 Stunden am Tag, 5 Tage die Woche an einem TaskMontag, 26. Oktober 2009 55
  56. 56. Die Dreifach-Schätzung Best Case - Einschätzung: 10 Tage Most Likely - Einschätzung: 15 Tage Worst Case - Einschätzung: 25 Tage Formel zur Bestimmung eines realistischen Durchschnittswertes (basierend auf den Erfahrungen aus der Teststatistik, dass eine Aufwandsschätzung in mehr als 85% der Fälle in Richtung Worst-Case abweicht): (2x Best Case) + (3x Worst-Case) + Most Likely = X/6 In diesem Fall: (2x10) + (3x25) + 15 = 110/6 = 18,33 TageMontag, 26. Oktober 2009 56
  57. 57. Vielen Dank fürs Zuhören und viel Erfolg bei euren zukünftigen Projekten http://fg-informatik.unibas.ch/wiki/ index.php/FG-Workshop http://project-two.org JOIN the future!Montag, 26. Oktober 2009 57

×