{"id":2789,"date":"2014-03-28T08:05:54","date_gmt":"2014-03-28T08:05:54","guid":{"rendered":"http:\/\/kasperskydaily.com\/germany\/?p=2789"},"modified":"2020-02-26T18:32:29","modified_gmt":"2020-02-26T16:32:29","slug":"die-regel-der-sechs","status":"publish","type":"post","link":"https:\/\/www.kaspersky.de\/blog\/die-regel-der-sechs\/2789\/","title":{"rendered":"Die Regel der „Sechs“"},"content":{"rendered":"

Einer der wichtigsten Meilensteine auf dem Weg von Kaspersky Lab zu einem anerkannten, globalen Mitspieler der Sicherheitsbranche, war die Ver\u00f6ffentlichung der revolution\u00e4ren Version 6.0 von Kaspersky Anti-Virus<\/a>. Das Produkt, das im Jahr 2006 vorgestellt wurde, entwickelte sich auf dem weltweiten Antivirus-Markt zu einem riesigen Erfolg und machte Kaspersky Lab f\u00fcr Jahre zum Technologief\u00fchrer der Branche. Es w\u00e4re nicht gerade bescheiden, wenn wir unser Produkt als beste Antivirenl\u00f6sung der Welt<\/a> bezeichnen w\u00fcrden, aber das haben schon zahlreiche Magazine und unabh\u00e4ngige Tests<\/a> f\u00fcr uns erledigt. \"kaspersky<\/a><\/span> Der Weg zum Erfolg war durchwachsen und verr\u00fcckt \u2013 und hoffentlich wird eines Tages ein Hollywood-Autor ein Drehbuch daraus machen, doch jetzt versuchen erst einmal wir selbst, die Erfolgsgeschichte mit Fotos, pers\u00f6nlichen Notizen und Erinnerungen des Original-Entwicklerteams zu erz\u00e4hlen. Wir hoffen, dass diese Geschichte auch ein Beispiel f\u00fcr junge Entwickler ist, die heute neue Apps und Services aufbauen \u2013 vorausgesetzt, sie sind ebenso besessen von der Idee, das Beste zu erschaffen. So wie es auch die Entwickler der \u201eSechs\u201c waren. <\/i><\/p>\n

\"team

Ein bekanntes Foto, das am Tag der Ver\u00f6ffentlichung der Version \u201eSechs\u201c gemacht wurde<\/p><\/div>\n

Problem 2003<\/strong><\/h2>\n

Der Erfolg der \u201eSechs\u201c wurzelte in der totalen Katastrophe der Vorg\u00e4ngerversion. Diese Version hat nie das Tageslicht gesehen \u2013 zumindest nicht in ihrer urspr\u00fcnglichen Form.<\/p>\n

Um diese Katastrophe zu verstehen, m\u00fcssen wir ins Jahr 2002 zur\u00fcckreisen: Windows XP kam gerade auf den Markt, CPUs hatten endlich die 1 GHz-Grenze erreicht und die noch relativ junge Antiviren-Industrie stand kurz davor eine komplett neue Art von Bedrohungen zu entdecken. Alle Antivirus-Hersteller erweiterten die F\u00e4higkeiten ihrer Produkte: Eine konkurrenzf\u00e4hige L\u00f6sung musste damals eine Firewall, eine st\u00e4ndig laufende System\u00fcberwachung und Dutzende anderer Funktionen bieten.<\/p>\n

Das Kaspersky-Team musste zugeben, dass die L\u00f6sung mit der starken Scan-Engine, die in den 1990er Jahren entwickelt wurde, beim Hinzuf\u00fcgen vieler neuer Funktionen unertr\u00e4glich langsam werden w\u00fcrde \u2013 auch schon die bis dahin verkaufte Version 4.0 wurde von den Anwendern verdammt (alle m\u00f6glichen Behauptungen, dass \u201eKaspersky langsam ist\u201c geh\u00f6rten damals zur PC-Folklore). Deshalb wurde der Entwicklungsprozess f\u00fcr die neue Version 5.0 unter Ber\u00fccksichtigung der wichtigsten Business-Grundlagen sorgf\u00e4ltig geplant: Es wurden ein neuer CTO, ein neues Entwicklungs-Framework und eine neue Antivirus-Architektur gew\u00e4hlt.<\/p>\n

Die Firma stellte alle Ressourcen f\u00fcr dieses Projekt ab. Allerdings war nach einem Jahr klar, dass auch das Befolgen aller neuen Entwicklungsregeln nicht unbedingt ein wettbewerbsf\u00e4higes Produkt erm\u00f6glichen w\u00fcrde. Das resultierende System, das Unternehmens-Apps im Client-Server-Bereich nachahmte (die Architektur, die der CTO ausw\u00e4hlte), schaffte es nicht, die Anforderungen des Markts an Antivirus-Produkte zu befriedigen. Die Software war langsam und schwerf\u00e4llig, und die Zahl der Bugs sank w\u00e4hrend der Tests nicht \u2013 sie stieg sogar an.<\/p>\n

\u201eIch begann, einige Leute \u2013 unserer Firmen-Veteranen \u2013 zu fragen, was sie dar\u00fcber denken. Sie sagten, die Architektur sei das Entscheidende. Wie bei einem Kartenhaus: Verschiebt man an einem Element, f\u00e4llt das ganze Haus in sich zusammen\u201c, gibt Eugene Kaspersky zu. Also war es nicht sinnvoll, mit dem Projekt so weiter zu machen. Es musste komplett eingerissen und von Grund auf neu aufgebaut werden.<\/p>\n

We can do it!<\/h2>\n

Das Entwicklungsteam von Kaspersky Lab wurde in zwei Gruppen aufgeteilt: eine, die versuchte, das Produkt unabh\u00e4ngig von der ungl\u00fccklich gew\u00e4hlten Architektur zu reparieren, und eine zweite, die die Vorg\u00e4ngerversion 4.0 zu einem passenden neuen Produkt aufpolieren sollte.<\/p>\n

Gleichzeitig beschloss eine Vierergruppe, ein komplett neues Produkt zu entwickeln, das nicht nur mit den Marktanforderungen Schritt halten, sondern auch f\u00fcr die Zukunft ger\u00fcstet sein sollte. Das Ziel, das sich das Entwicklungsteam der \u201eSechs\u201c gesetzt hatte, ist einfach zu erkl\u00e4ren, aber schwer zu erreichen. Die neue Version sollte alle Viren davon abhalten, in den Computer einzudringen. Daf\u00fcr musste sie schnell, gewandt, transparent und\u2026 nun ja, gutaussehend sein.<\/p>\n

\u201eWir wollten einfach das beste Produkt erschaffen\u201c, sagt das Team dazu. Der Rest der 200 Mitarbeiter sah ein sehr kleines Team, das vor einer monumentalen Aufgabe stand. Doch das kleine Team mit seiner herausfordernden Aufgabe konnte optimistisch sein, denn die Firmengr\u00fcnder Eugene Kaspersky und Alexey De-Monderik waren zu dieser Zeit auf der Suche nach einer Alternative f\u00fcr die Programmarchitektur \u2013 und sie entdeckten bald, dass es so eine Alternative gab, und dass diese von niemand anderem als dem Kaspersky-Team entwickelt worden war.<\/p>\n

Hilfe aus Prag<\/h2>\n

\"prag\"<\/p>\n

Man muss kurz erw\u00e4hnen, dass unter der Haube der Version 4.0 zwei Antivirus-Kerne (so genannten \u201eEngines\u201c) arbeiteten. Die Pr\u00fcfung von Dateien wurde durch die alte, sehr zuverl\u00e4ssige (und durch zahlreiche international t\u00e4tige Firmen, etwa G-Data und F-Secure, lizensierte) Version-3.0-Engine erledigt, die im Jahr 1996 entwickelt worden war. Die neuere Aufgabe des Filterns des Web-Verkehrs wurde durch den brandneuen und kraftvollen Mechanismus erledigt, der bei einem Brainstorming in Prag im Jahr 1998 erfunden worden war.<\/p>\n

Diese Engine wurde \u201ePrag\u201c genannt, auch wenn sie von Andrey Doukhvalov in Moskau entwickelt wurde, der bei dem Brainstorming in der tschechischen Hauptstadt nicht dabei war. Die Schl\u00fcsselideen wurden aber in Prag entwickelt und Andrey kam zum Team hinzu, um die Ideen zu optimieren und das Prag-Konzept umzusetzen.<\/p>\n

Prag sollte ein reiner Antivirus-Kern sein, doch die daf\u00fcr gesetzten Ziele waren so hoch, dass die neu entwickelte Engine so flexibel und genial war, dass sie auch kompliziertere Aufgaben \u00fcbernehmen konnte. Die Frage war aber, ob es m\u00f6glich sei, das ganze Produkt<\/b> basierend auf Prag zu implementieren. Diese Frage besch\u00e4ftige Eugene Kaspersky sehr, als er zu den Entwicklern sprach. Er erinnert sich noch gut daran:<\/p>\n

\u201eIch fragte Victor Matyushenko, wie sich Prag im Produkt schl\u00e4gt, und er sagte \u201aWie ein Fels in der Brandung!\u2018. Das war der Wendepunkt. Ich habe dann die <\/i>Frage gestellt. Ich bin in das B\u00fcro gegangen, in dem Graf (De-Monderik) und Petrovich (Doukhvalov) arbeiteten und stellte ihnen die <\/i>Frage: \u201aWarum basieren wir das Produkt nicht komplett auf Prag?\u2018 Graf sagte etwas wie \u201aUnm\u00f6glich, Prag ist daf\u00fcr nicht gedacht\u2018, doch Petrovich z\u00f6gerte. Am n\u00e4chsten Morgen kam er mit einem kleinen Papierstapel in das B\u00fcro und sagte zu mir \u201aWei\u00dft du, ich habe ein paar Anwendungsf\u00e4lle f\u00fcr Prag erstellt\u2018. Graf sah in an und sagte \u201aWir m\u00fcssen reden\u2018. Danach kamen sie wieder zu mir und best\u00e4tigten, dass es wert sei, es zu versuchen.\u201c<\/p>\n

Wir starteten den Versuch mit einem sehr kleinen Team, das die ersten Code-Zeilen schrieb, aus denen sp\u00e4ter die \u201eSechs\u201c wurde.<\/p>\n

Wir starteten den Versuch mit einem sehr kleinen Team, das die ersten Code-Zeilen schrieb, aus denen sp\u00e4ter die \u201eSechs\u201c wurde.<\/div>\n

\u201eWir sahen uns um, um Kollegen zu finden, die kreativ waren und etwas zu dem Projekt beitragen konnten, und haben dann ein erweitertes Team aufgebaut\u201c, erinnert sich De-Monderik. \u201eDa war zum Beispiel Pavel Mezhuev, ein Programmierer. Er war neu in der Firma, aber sehr schlau.\u00a0 Dann Mike Pavlyuschik, mit dem wir schon lange zusammengearbeitet hatten. Er konnte fertige Ideen und Konzepte abliefern. Ich dachte damals schon, dass er einer der talentiertesten und flei\u00dfigsten Entwickler in unserem Bereich ist.\u201c<\/p>\n

\u00a0\"team<\/b><\/p>\n

Nach zwei Monaten des offenen, experimentellen Programmierens kamen wir zu der \u00dcberzeugung, dass aus dem Projekt eine kommerzielle L\u00f6sung werden w\u00fcrde. Nun brauchten wir nur noch einen Projektmanager.<\/p>\n

Andrey Doukhvalov erinnert sich an ein Gespr\u00e4ch, das er mit De-Monderik f\u00fchrte:\u201cKennst Du Nikolay Grebennikov aus dem B\u00fcro nebenan? Er liest viel, ist jung und neu im Unternehmen. Nehmen wir doch ihn!\u201c Etwas sp\u00e4ter kam noch Andrey Sobko, ein Treiber-Programmierer, hinzu.<\/p>\n

Was ist \u201ePrag\u201c<\/h2>\n

Dieses Kapitel ist vor allem f\u00fcr Software-Ingenieure interessant. Wenn Sie m\u00f6chten, k\u00f6nnen Sie es gerne \u00fcberspringen.<\/p>\n

\"\"<\/a><\/p>\n

\"\"<\/a><\/p>\n

\"\"<\/a><\/p>\n

\"\"<\/a><\/p>\n

\"\"<\/a><\/p>\n

\"\"<\/a><\/p>\n

\"\"<\/a><\/p>\n

Sogar Anfang der 1990er Jahre, als die Antiviren-Branche gerade erst startete, gab es Viren, die mit normalen Signaturen nicht entdeckt werden konnten. So ist zum Beispiel ein polymorpher Virus, der seinen Code bei jeder Infizierung neu verschl\u00fcsselt, damit nicht erkennbar. Und als Software immer komplexer wurde, immer mehr Menschen das Internet nutzten und Schadprogramm-Autoren nicht mehr zum Spa\u00df Viren programmierten, sondern ihre Dienste gegen Geld anboten, wurden Schadprogramme immer anspruchsvoller und vielseitiger. Selbst mit einer Engine, die neben der Signatur-basierten Entdeckung weitere M\u00f6glichkeiten bot, so wie es bei Kaspersky Lab der Fall war, mussten die Entwickler laufend die Antivirus-Engine aktualisieren, nicht nur die Signatur-Datenbanken, wenn sie ein Schadprogramm entdeckten, das neue M\u00f6glichkeiten nutzte. Das verbesserte die Reaktionszeit auf neue Viren, und dass Kaspersky Lab als erstes Unternehmen mit dem ber\u00fcchtigten CIH-Virus (Chernobyl) fertig wurde, bewies, dass das Verringern der Reaktionszeit den Aufwand wert ist.<\/p>\n

Damit sagte Eugene Kaspersky im Jahr 1998 den Kollegen, dass es Zeit sei, eine neue Antivirus-Engine zu entwerfen. Doch wo sollten sie das tun?<\/p>\n

\u201eDie Firma hatte nicht viel Geld\u201c, so Kaspersky dazu, \u201eund wir mussten den g\u00fcnstigsten Ort in der N\u00e4he von Moskau finden, so dass wir die Stadt verlassen und abseits des L\u00e4rms und der Hektik \u00fcber das Problem nachdenken konnten. Es sollte ein abgekoppleter Ort sein. Damals gab es noch kein WLAN. Als g\u00fcnstigster Ort stellte sich Prag heraus.\u201c<\/p>\n

Beim Nachdenken \u00fcber die neue Antivirus-Engine kam das Kaspersky-Team zu dem Ergebnis, dass ein objektorientierter Ansatz die beste L\u00f6sung f\u00fcr die Engine-Ebene ist, denn jede zu analysierende Datei und jedes Objekt musste basierend auf seiner Struktur auseinandergenommen werden, und die Objekte darin mussten entdeckt, analysiert und gepr\u00fcft werden. Das Objektmanagement musste komplett auf Laufzeitebene durchgef\u00fchrt werden.<\/p>\n

Alle existierenden Objektumgebungen wurden diskutiert und wieder verworfen, da sie zu unflexibel, zu speicherhungrig oder zu langsam waren. Doch eine Idee kam w\u00e4hrend der Diskussionen auf: die Entwicklung einer eigenen Umgebung, die M\u00f6glichkeiten zum Speichermanagement und weitere Service-Prozesse enthalten sollte, die dem Antivirenprogramm die M\u00f6glichkeit geben w\u00fcrden, potenzielle Schadprogramme schnell und effizient auseinanderzunehmen und zu analysieren.<\/p>\n

Diese grundlegende Idee wurde von De-Monderik und Andrey Krykov in Prag geboren und durch die ersten Code-Zeilen von Doukhvalov und Kryukov unterst\u00fctzt.<\/p>\n

Dann hat sich vor allem Doukhvalov \u00fcber ein Jahr mit Prag besch\u00e4ftigt \u2013 das war ja auch der Grund, warum er bei Kaspersky Lab eingestellt worden war. Mit seiner Erfahrung in Software-Architektur, konnte Doukhvalov sicherstellen, dass Prag flexibel, skalierbar und einfach in das Produkt zu integrieren war, ohne irgendwelche architekturelle Beschr\u00e4nkungen zu verursachen. Das eigentliche Ziel war, eine Multiplattforml\u00f6sung zu entwickeln.<\/p>\n

Die Objekt-Hierarchie war eine Herausforderung beim Debugging, doch ein praktisches Nachrichten-Austauschsystem zwischen den Objekten und eine minimalistische Programmieroberfl\u00e4che machten Prag zu einer einfach integrierbaren Architektur, die On-Demand genutzt werden konnte, wenn es passte.<\/p>\n

\u201eDas war als Komponente gedacht\u201c, sagt Doukhvalov dazu. \u201eDas bedeutet, dass die Komponente zu einem existierenden Programm hinzugef\u00fcgt werden konnte. Das System war sehr offen, mit der M\u00f6glichkeit, Elemente hinzuzuf\u00fcgen und Verhaltensmuster zu \u00e4ndern.\u201c<\/p>\n

Eine Komponenten-basierte Architektur, kompakt und Ressourcen-schonend, war allgemein als Basis f\u00fcr die Einf\u00fchrung radikal neuer Technologien in Kaspersky Anti-Virus 6.0 anerkannt. Diese konnten einfach implementiert werden. Und als Prag so angepasst wurde, dass es zur Basis f\u00fcr das ganze Produkt wurde, und nicht nur f\u00fcr die Antivirus-Engine, hat Pavel Mezhuev viel zur Feinabstimmung der Architektur beigetragen:<\/p>\n

\u201eWir haben eine weitere Architektur-L\u00f6sung implementiert und ein Modell zur Trennung der Logik sowie ein Interface hinzugef\u00fcgt. Zudem haben Doukhvalov und Mezhuev einen Task-Manager erstellt, der jeden einzelnen Prozess im Produkt kontrollieren konnte und die Wechselwirkung zwischen Prozessen war sehr einfach,\u201c so Nikolay Grebennikov, der Projektmanager f\u00fcr Kaspersky Anti-Virus KAV 6.0.<\/p>\n

\"\"<\/a><\/p>\n

\"\"<\/a><\/p>\n

\"\"<\/a><\/p>\n

\"\"<\/a><\/p>\n

\"\"<\/a><\/p>\n

\"\"<\/a><\/p>\n

\"\"<\/a><\/p>\n

\"\"<\/a><\/p>\n

\"\"<\/a><\/p>\n

\"\"<\/a><\/p>\n

Das Prinzip der \u201eSechs\u201c<\/h2>\n

Da die Experimentier- und erste Entwicklungsphase von einem kleinen Team ausgef\u00fchrt wurde, war klar, dass ein m\u00f6nstr\u00f6ses Projektmanagement hier nichts bringen w\u00fcrde. Daher wurde ein Ansatz \u00e4hnlich SCRUM implementiert: Die Entwickler sa\u00dfen in einem offenen Bereich und sprachen laufend miteinander \u2013 dadurch konnten sie alle Aspekte des Entwicklungsprozesses abdecken. So hat das Team der \u201eSechs\u201c gearbeitet.<\/p>\n

Kurzprofil: SCRUM<\/h3>\n

SCRUM ist ein Ansatz des Projektmanagements f\u00fcr eine flexible Software-Entwicklungsumgebung. Das System basiert auf dem Prinzip, dass der Kunde (Anwender) nicht unbedingt wei\u00df, was er braucht und die Anforderungen w\u00e4hrend des Prozesses \u00e4ndern k\u00f6nnte. Das bedeutet, dass der Entwicklungsprozess durch konsequente und zahlreiche Zyklen gekennzeichnet ist: Aufbauen \u2013 Vorf\u00fchren \u2013 Feedback analysieren \u2013 das Programm aktualisieren. Doch die Rollenverteilung von SCRUM wurde genau betrachtet. Kaspersky Lab hatte sechs Rollen:<\/p>\n

Architekt<\/b><\/p>\n

Der Architekt \u2013 aktiv in den Programmierprozess involviert \u2013 wei\u00df, was gebaut wird und wie es gebaut wird.<\/p>\n

Technischer Designer<\/b><\/p>\n

F\u00fcr diese Rolle gibt es keine einfache Definition. Der Technische Designer ist daf\u00fcr verantwortlich, dass bestimmte L\u00f6sungen zum Leben erweckt werden. Noch wichtiger ist vielleicht, dass der Technische Designer wissen muss, wie Dinge NICHT gemacht werden sollen.<\/p>\n

Erfinder<\/b><\/p>\n

Der Erfinder nutzt ungew\u00f6hnliche L\u00f6sungen, um Probleme zu l\u00f6sen. Bei der \u201eSechs\u201c gab es zahllose Probleme. Die L\u00f6sung sollte jeweils den besten Schutz bei der geringsten Ressourcen-Nutzung bieten.<\/p>\n

Projektmanager<\/b><\/p>\n

Die Rolle des Projektmanagers ist in SCRUM nicht strikt f\u00fcr die Steuerung vorgesehen. Er kontrolliert die Ressourcen und Abgabetermine, aber ist nicht unbedingt der Chef des Teams. Er sagt den Programmieren nicht, was sie zu tun haben, sondern motiviert sie, sich selbst zu f\u00fchren. \u201eDas Team war klein und wir hatten am Anfang nicht einmal jemanden, der der Chef war\u201c, so Doukhvalov. \u201eDer Manager plante und berichtete, doch die Entscheidungen zu dem Projekt wurden kollektiv getroffen.\u201c<\/p>\n

Marketing-Manager<\/b><\/p>\n

Das Produkt wird f\u00fcr Kunden entwickelt, nicht f\u00fcr das Entwicklungsteam. Es ist also wichtig, zu verstehen, mit welchen Erwartungen die zuk\u00fcnftigen Anwender das Produkt beurteilen und wie sie es benutzen werden. W\u00e4hrend die operativen Prinzipien von den Leuten definiert werden, die die Antivirus-Funktionen genau verstehen, so m\u00fcssen bei Tausenden kleinen Dingen, etwa Einstellungen, Benachrichtigungen oder der Benutzeroberfl\u00e4che, die Anwenderbed\u00fcrfnisse ber\u00fccksichtigt werden.<\/p>\n

Psychologe<\/b><\/p>\n

Unter Druck arbeiten, mit wenig Schlaf, Konflikten im Team, Unsicherheit\u2026 Irgendjemand muss sicherstellen, dass das Klima im Raum freundlich und produktiv bleibt. Diese Rolle wurde Eugene Kaspersky selbst zugewiesen, also kombinierte er sie mit der Rolle des Sponsors, der Geldmittel und Ressourcen f\u00fcr das Team zur Verf\u00fcgung stellt und es von \u00e4u\u00dferen Einfl\u00fcssen sch\u00fctzt.<\/p>\n

Ehrlich gesagt, gibt es noch eine weitere Rolle, die f\u00fcr SCRUM-Projekte enorm wichtig ist \u2013 der Schreiber<\/b>, der w\u00e4hrend des Prozesses Notizen macht. Doch diese Position blieb unbesetzt, und das f\u00fchrte zu Problemen.<\/p>\n

\u201eWir wussten nicht, warum wir das so machten oder warum wir ein halbes Jahr vorher diese Entscheidung getroffen hatten\u201c, best\u00e4tigt Eugene Kaspersky.<\/p>\n

Prinzipiell muss die Zahl der Rollen nicht der Zahl der Teammitglieder entsprechen. Eine Rolle kann unter mehreren Personen aufgeteilt werden, w\u00e4hrend ein einziges Teammitglied mehrere Rollen \u00fcbernehmen kann.<\/p>\n

\u201eW\u00e4hrend wir eine formelle Organisation wahrten, haben wir als ein Team gearbeitet. Also waren die Grenzen zwischen den Rollen verwischt: Vor allem beim Brainstorming haben die Personen unterschiedliche Rollen eingenommen\u201c, gibt Nikolay Grebennikov zu. \u201eEs konnte immer sein, dass jemand eigentlich Programmierer war, aber seine Meinung zum Design sagte \u2013 und das z\u00e4hlte auch. Ich selbst war Projektmanager, habe aber auch an den Diskussionen teilgenommen \u2013 diese unscharfen Abgrenzungen haben wirklich zum Erfolg beigetragen, da wir uns um jeden einzelnen Aspekt des Projekts k\u00fcmmerten.\u201c<\/p>\n

Laut De-Monderik konnten die Programmierer sehr gut ausgetauscht werden: \u201eJedes Teammitglied beherrschte seinen Bereich, doch 50 Prozent seiner F\u00e4higkeiten \u00fcberschnitten sich mit den F\u00e4higkeiten von jemand anderem. Mike konnte Treiber programmieren, wenn Sobko nicht da war. Spezialisten f\u00fcr die Benutzeroberfl\u00e4che konnten Aufgaben bei der Engine \u00fcbernehmen und anders herum. Ich konnte statt Max Yudanov Designs machen und Kolya Grebennikov konnte manchmal Skins entwerfen.\u201c<\/p>\n

Wichtig ist, zu verstehen, dass jede Rolle zu einem bestimmten Zeitpunkt im Projekt die f\u00fchrende Rolle ist. W\u00e4hrend der Anfangsphase ist der Architekt die zentrale Figur. Der Erfinder kommt in der Mitte des Projekts zu seinem gro\u00dfen Einsatz, wenn die Funktionen entworfen und entwickelt werden. Und in der Schlussphase ist der Manager der wichtigste Mann, denn nun enth\u00e4lt das Projekt viele Ressourcen, die ein strenges Management erfordern, so dass das Team den Abgabetermin halten kann.<\/p>\n

Das Streben nach dem Ideal<\/h2>\n

Durch den SCRUM-\u00e4hnlichen Ansatz und die allgemeine Ehrgeizigkeit des Projekts, hatte die \u201eSechs\u201c keine statische Anforderungsliste. Die grundlegenden Anforderungen zeigten nur, welche F\u00e4higkeiten das Programm haben sollte:<\/p>\n