Programmierstilgesteuerte Entwicklungs-Philosophien
Ebenso wie CMMI enthalten die Vertreter dieses Typs von Vorgehensmodell Elemente des Processings, weshalb ein Software Engineering Modell hier nicht selten auch die Bezeichnung eines Prozessmodells besitzt. Darüber hinaus lassen sich die durch Programmierphilosophien geprägten Vorgehensmodelle erwartungsgemäß kaum einem gemeinsamen Konsens zuordnen und sind eher speziell und eigen. Die breite Streuung an Eigenschaften ist der Tatsache geschuldet, dass die Modelle größtenteils noch recht jung sind, trotz großen Zuspruchs aber keineswegs als gefestigt gelten. Charakterlich befinden sich unter den philosophiegelebten Vorgehensmodellen sowohl leichtgewichtige „agile Verfahren“ wie das Extreme Programming (XP) oder das Protoyping, es kommen aber durchaus auch Anhänger auf ihre Kosten, die detailgetreue und Implementierungshandlung vorgebende Schwergewichte benötigen.
EXTREME PROGRAMMING
Bei XP (Extreme Programming) handelt es sich um ein verhältnismäßig schlankes Modell, das zwar schnell Resultate liefert, und sich von Anfang an sehr eng an den Bedürfnisses des Kunden orientiert, dafür aber durchaus auch unkonventionelle Praktiken pflegt, die nicht unumstritten sind.
Das typische eXtreme Programming Szenario richtet sich vor allem an kleine Entwicklungsteams von 1-2 Personen (Pair Programming), in die zudem ein Mitarbeiter des Auftragsgebers eingebunden sein kann (in-Site-Customer). Das Ziel von XP ist die Entwicklung von Software in kurzen Iterationszyklen und testbaren Resultaten durch Verwendung einfachsten Designs. Im Gegensatz zu den normalen Use-Cases der Softwaretechnik verwendet XP Programming sogenannte User-Stories, die den Bedürfnissen des Auftragsgebers abgeleitet sind und dem Verständnis nach ein wenig das Verhältnis von Arzt und Patient widerspiegeln. User-Stories folgen dem Muster „Als Person A kann ich B tun, um C zu erreichen“ und nehmen situationsgebunden die Anforderungen des Kunden exakt auf. In einem nächsten Schritt erfolgt dann bereits das Risikomanagement, das den Architectural Spike bestimmt, der in einer ersten Iteration erreicht werden soll. Der abschließende Akzeptanz-Test gibt dann Aufschluss darüber, ob dem Kunden ein erstes Release ausgeliefert werden kann oder die Iteration nicht ausreichend wahr und durch Nachjustierung des Spikes erneut konditioniert werden muss.
Du brauchst Hilfe?
-
Wir sind erfahrene Web-Entwickler und Web-Designer aus Köln. Seit Gründung im Jahr 2011 arbeiten wir für unsere Kunden regelmäßig mit PHP, Ruby on Rails in der Softwareentwicklung und WordPress.
-
Du musst nicht länger suchen, wir vermitteln dir bezahlbare Agentur-Leistungen. Gerne arbeiten unsere Webentwickler auch als Teil deines Teams.
-
Beschreibe uns doch kurz deinen Bedarf. Wir rufen dich zurück, wann immer du Zeit hast. Fragen zu Aufwand und Komplexität eines Projektes beantworten wir natürlich kostenlos.
Neugierig geworden?
Nimm jetzt Kontakt mit uns auf. Wir freuen uns auf dich.
PROTOTYPING
Die Entwicklung mit Prototyp Modellen ist dann sinnvoll, wenn Spezifikationen auf Seite des Auftragsgebers noch gar nicht bekannt oder unvollständig sind. Ist aus diesem Grund heraus eine Kommunikation zwischen Kunde und Entwickler nicht möglich, kann Prototyping vor allem dann das geeignete Mittel sein, wenn experimentelles Erproben einer Lösung oder das Austesten eines bestimmten Realisierungsvorhaben die Situation entspannt. Ein Prototyp dieser Art versteht sich durchaus als bereits modellierte Mock-Up Lösung oder lauffähige Teilkomponente eines Zielsystems und hilft die bestehenden Unschärfen zu minimieren bzw. zu konkretisieren.
Je nach Bedarf des Kunden können dabei verschiedene Prototyp Modelle zum Einsatz kommen, die entweder eher dem Beispiel eines schnell erstellten Wegwerfsprototypen folgen (Rapid Prototyping) oder mit zunehmender Intensivierung die Migrationsentwicklung hin zu einem vollständigen Softwareprodukt erfahren (Pilotsystem). Nachteilig an dieser Art von Vorgehen sind die entstehenden Kosten in einer bereits frühen Phase der Entwicklung und der Verzicht auf jede Art von Dokumentation – andererseits erhält der Kunde hier sehr früh Feedback bezüglich Wechselwirkungen und möglicher Probleme.
RUP
Der Unified Process von Rational (seit 2002 bei IBM angesiedelt) richtet sich an umfangreiche Projekte mit großen Entwicklerteams und erlaubt das Vereinbaren von über 30 Rollen für über 130 vordefinierten Aktivitäten. Merkmale von RUP (Rational Unified Process) ist das architekturbedachte, iterative Vorgehen mit Use-Cases. Entsprechend des Anspruchs sind RUP Projekte wohldefiniert und sehr gut durchstrukturiert und klammern sich an viele formalisierte Dokumente. In seinem Kern ist RUP durch vier Hauptphasen und neun Workflows aufgestellt. Eine anwendbare Interpretation könnte RUP als Vorgehensmodell mit der Metapher eines Strömungsmodells vergleichen, bei dem sich die Hauptströmung als Summe aller beteiligten Entwicklungsprozesse ergibt. Durch das zeitversetzte Triggern von einzelnen Unterströmungen kann so ein Verhalten emuliert werden, bei dem sich die gesamte Entwicklung selbstständig evolutioniert.
Der Rational Unified Process hat sich als mächtiges und wichtiges Vorgehensmodell fest in der Softwaretechnik etabliert und eignet sich durch Generizität und die Auslegung auf UML insbesondere für die objektorientierte Programmentwicklung.