agile Softwareentwicklung Diskussionspapier

Transcription

agile Software - Entwicklung
Diskussionspapier
agile Softwareentwicklung
Diskussionspapier
Version: 1
Dokumentstatus: im Review
© Versicherungskammer Bayern
Seite 1 von 18
Diskussionspapier
Dokumentinformation
Eckdaten
Verantwortlicher
Autoren : Steffen Müller , Erhard Karger
Version
2
CVS-ID
Dokumentstatus
im Review
Erstellt am
14022008
Zuletzt geändert am
5032008
Dateiname
AgileSoftwareEntwicklung0.3.doc
Mögliche Ausprägungen des Dokumentstatus: „in Arbeit“, „vorgelegt zum Review“, „freigegeben“
Standard für die Versionsnummernvergabe:
0.X für Arbeitsstände, 1.0 für abgeschlossene Dokumente vor Review, 1.X für abgeschlossene Dokumente nach Review
Änderungsnachweis
Nr. Version
CVS-ID
Datum
Änderung
Datum
Inhalte des Reviews
Mitarbeiter
1
2
3
4
5
Reviewnachweis
Nr.
Version
CVS-ID
Teilnehmer
2
Version: 1
Seite 2 von 18
Diskussionspapier
Inhaltsverzeichnis
Das Inhaltsverzeichnis ist leer, da keiner der Absatzstile, die in den Informationen „Dokument“
ausgewählt sind, im Dokument verwendet wird.
Version: 1
Seite 3 von 18
Diskussionspapier
1Einleitung
Ausgelöst durch die schnelle Entwicklung der VVG - Konvertierungsinfrastruktur, stellt sich die
Frage, ob das in diesem Prozess angewandte Entwicklungsverfahren und Techniken weiter genutzt werden sollen.
Dieses Dokument trägt Informationen zusammen und soll der Diskussion über dieses Thema
eine erste Basis liefern, um dann eine Entscheidung darüber zu fällen, welche Entwicklungsverfahren bzw. Techniken eingesetzt werden oder auch verworfen werden. Es sei gleich zu Anfang
klar gestellt, dass agile Softwareentwicklung nicht die Lösung aller Probleme ohne hart zu arbeiten ist. Nein – agile Entwicklung fördert Selbständigkeit und fordert harte Arbeit der Einzelnen im Projekt und an sich selbst.
Betrachtet man den Entstehungsprozess der Konverterinfrastruktur, so fällt auf dass :
1. es sich um ein „überschaubares“ Vorhaben handelt,
2. keine Konzepte erstellt wurden, sondern sofort mit der Realisierung angefangen wurde,
3. ein Framework benutzt wurde, das schnelles unkompliziertes entwickeln auf der „grünen
Wiese“ erlaubt,
4. das gewünschte Ergebnis klar war,
5. eine hohe Kooperationsbereitschaft auf Kundenseite vorhanden war,
6. bestehende und gekaufte Komponenten (Konverter) miteinander verbunden, sowie deren Workflow abgebildet werden musste.
1.1Der Begriff Softwareentwicklung
Unter Softwareentwicklung bzw. software engineering wird in Wikipedia eine Definition von
Helmut Balzert angeboten. Sie beschreibt die Softwareentwicklung als die Herstellung eines
Produktes (Software) wie folgt:
„zielorientierte Bereitstellung und systematische Verwendung von Prinzipien, Methoden
und Werkzeugen für die arbeitsteilige, ingenieurmäßige Entwicklung und Anwendung
von umfangreichen Softwaresystemen.“
Dies bedeutet also, dass in einem Unternehmen die betrieblichen und vertrieblichen Prozesse
durch ein neues Softwareprodukt erweitert bzw. ergänzt werden sollen. Hierfür wenden ausgebildete Experten (Softwareentwickler) Prinzipien, Methoden und Werkzeuge an, um gemeinsam ein Produkt (als Anforderung definiert) zu erzeugen, das die Systemlandschaft des jeweiligen Unternehmens entsprechend ergänzen soll.
Version: 1
Seite 4 von 18
Diskussionspapier
1.2Agile Softwareentwicklung
Das Ziel Agiler Softwareentwicklung ist es, den Softwareentwicklungsprozess flexibler und
schlanker zu machen, als das bei den klassischen Vorgehensmodellen der Fall ist. Man möchte
sich mehr auf die zu erreichenden Ziele fokussieren und auf technische und soziale Probleme
bei der Softwareentwicklung eingehen. Die Agile Softwareentwicklung ist eine Gegenbewegung
gegenüber den oft als schwergewichtig und bürokratisch angesehenen Softwareentwicklungsprozessen wie dem Rational Unified Process oder dem V-Modell.
Agile Methoden kennzeichnen eine an Agilität (lat. agilis 'flink, beweglich) ausgerichtete Methode zur Softwareentwicklung, also ein konkretes einzelnes Teilvorgehensverfahren.
Ziel dieser Methoden ist die Aufwandskurve möglichst flach zu halten was dem Leitsatz gilt: „Je
mehr Du nach Plan arbeitest, um so mehr bekommst Du das, was Du geplant hast, aber nicht
das, was Du brauchst.“
Beispiele für Agile Methoden:
•
Paarprogrammierung
•
Testgetriebene Entwicklung
•
ständige Refaktorisierungen
•
Story-Cards
•
schnelle Codereviews
Ergänzt werden diese Methoden durch Prinzipien wie folgende:
•
Vorhandene Ressourcen mehrfach verwenden
Version: 1
Seite 5 von 18
Diskussionspapier
•
einfach
•
zweckmäßig
•
kundennah
•
Gemeinsamer Code-Besitz (Collective Code Ownership)
•
Stetige Qualitätssicherung durch Unittests pro Iteration
Der Übergang zwischen Prinzipien und Methoden ist fließend.
1.3Softwareprozesstrends
Untersucht man die Techniken und Methoden, die in der Softwaretechnik in den letzten 50 Jahren angewandt wurden, so kann man gewisse Tendenzen ablesen. Nach Roman Pichler ist folgender Softwareentwicklungstrend zu erkennen:
Version: 1
Seite 6 von 18
Diskussionspapier
2Scrum
Scrum ist ein agiles Projektmanagementframework, das sich auf alle Arten der Softwareentwicklung anwenden lässt. Richtig eingesetzt hilft Scrum, Kundenzufriedenheit und Wertschöpfung nachhaltig zu steigern mit folgenden Charakteristika:
-
einfache Regeln
-
wenige Rollen
-
mehrere Arten von Meetings mit bestimmten Zwecken
-
einige Schlüssel-Artefakte, deren Pflege Overhead vermeidet und die maximale Transparenz auf einfache Weise bietet
-
Pragmatismus statt Dogmatik
-
iteratives Vorgehen
-
Selbstorganisation und Eigenverantwortung in interdisziplinären Teams
-
Konzentration auf hochqualitative Arbeit anstatt auf eine Papierflut bei der Spezifikation
-
Änderungen der Kundenanforderungen während des Projekts gelten als normal, nicht
als Störfaktor (es gibt keine „fertige“ Spezifikation)
-
speziell geeignet für hochkomplexe Projekte mit unklaren Anforderungen
-
Alle zwei Wochen bis zu einem Monat kann jeder echt lauffähige Software sehen und
entscheiden, diese so auszuliefern oder in einem weiteren Abschnitt zu ergänzen
-
Erlaubt es, sich auf die Auslieferung der wichtigsten Geschäfts-Anforderungen innerhalb
kürzester Zeit zu fokussieren.
2.1Der Scrumprozess
Scrum kennt drei Rollen für direkt am Prozeß Beteiligte: Product Owner (stellt fachliche Anforderungen und priorisiert sie), ScrumMaster (managt den Prozess und beseitigt Hindernisse) und
Team (entwickelt das Produkt). Daneben gibt es als Beobachter und Ratgeber noch die Stakeholders.
Die Anforderungen (Requirements) werden in einer Liste (Product Backlog) gepflegt, erweitert
und priorisiert. Empfehlenswert ist es die Anforderungen mit sogenannten Story Points zu bewerten. Story Points sind eine Einheit für Komplexität (ausschliesslich). Sie dienen der Schätzung von Aufwand für die Erledigung einer Aufgabe.
Version: 1
Seite 7 von 18
Diskussionspapier
Das Product Backlog ist ständig im Fluß. Um ein sinnvolles Arbeiten zu ermöglichen, wird monatlich vom Team in Kooperation mit dem Product Owner ein definiertes Arbeitspaket dem oberen, höher priorisierten Ende des Product Backlogs entnommen und komplett in Funktionalität
umgesetzt (inkl. Test und notwendiger Dokumentation). Dieses Arbeitspaket, das Increment,
wird während der laufenden Iteration, des sog. Sprints, nicht durch Zusatzanforderungen modifiziert, um seine Fertigstellung nicht zu gefährden. Alle anderen Teile des Product Backlogs
können vom Product Owner in Vorbereitung für den nachfolgenden Sprint verändert bzw. neu
priorisiert werden.
Das Arbeitspaket wird in kleinere Arbeitspakete (Tasks) heruntergebrochen und mit jeweils
zuständigem Bearbeiter und täglich aktualisiertem Restaufwand in einer weiteren Liste, dem
Sprint Backlog, festgehalten. Während des Sprints arbeitet das Team konzentriert und ohne
Störungen von außen daran, die Tasks aus dem Sprint Backlog in ein Increment of Potentially
Shippable Functionality, also einen vollständig fertigen und potentiell produktiv einsetzbaren
Anwendungsteil, umzusetzen. Das Team gleicht sich in einem täglichen, streng auf 15 Minuten
begrenzten Informations-Meeting, dem Daily Scrum Meeting, ab, damit jeder weiß, woran der
andere zuletzt gearbeitet hat, was er als nächstes vor hat und welche Probleme es evtl. gibt.
Am Ende des Sprints präsentiert das Team dem Product Owner, den Stakeholders u.a. interessierten Teilnehmern in einem sog. Sprint Review Meeting live am System die implementierte
Funktionalität. Halbfertiges oder gar Powerpoint-Folien sind während des Reviews verboten.
Das Feedback der Zuseher und die neuen Anforderungen des Product Owners für den kommenden Sprint fließen dann wieder in das nächste Sprint Planning Meeting ein, und der Prozess beginnt von neuem.
Der ScrumMaster sorgt während des gesamten Prozesses dafür, dass Regeln eingehalten werden und der Status aller Tasks im Sprint Backlog von den jeweils zuständigen Team-Mitgliedern
täglich aktualisiert wird. Er macht den Projektfortschritt transparent durch einen geeigneten Reporting-Mechanismus: die Veröffentlichung sog. Burndown Charts, welche den Fortschritt für
den aktuellen Sprint bzw. für das gesamte Projekt jeweils in Form einer Kurve visualisieren.
Eingezeichnete Trendlinien erlauben es, mögliche Probleme und Verzögerungen einfach (und
rechtzeitig!) zu erkennen.
Im Kern basiert Scrum also auf einer inkrementellen Vorgehensweise, der Organisation von
Entwicklungsabschnitten und Meetings in vordefinierten Zeitabschnitten (Time-Boxes) und der
Erkenntnis, dass ein funktionierendes Produkt wichtiger ist als eine dreihundertseitige Spezifikation.
Die Sprint Retrospective soll reflektieren, wie ein Sprint gelaufen ist. Sie wird meistens im Anschluss an den Sprint Review durchgeführt.
Das gesamte Team wird eingeladen, der Product Owner ist anwesend, der Scrum Master moVersion: 1
Seite 8 von 18
Diskussionspapier
deriert. Andere Stakeholder sind willkommen, allerdings nur als Zuschauer.
Während der Sprint Retrospective sollte das Team:
•
Das Product-Burndown Chart auswerten. Wie ist es gelaufen?
•
Die Team Velocity auswerten. Zur Ermittlung der Velocity (Geschwindigkeit) summiert
man alle Story Points des Sprints, die mit DONE abgearbeitet wurden und setzt sie in
Relation zu dem Total aller geschätzten Story Points im Product Backlog. Das kann man
graphisch darstellen und erhält über mehrere Sprints einen Trend. Dieser Trend ist sehr
wichtig für das Sprint Planning. Die Velocity ist ein Anhaltspunkt für die Arbeit, die ein
Team für einen Sprint annehmen kann. Das Team sollte auch hier Schwankungen in der
Kurve hinterfragen, Überstunden berücksichtigen und den totalen Aufwand errechnen:
Wie viel Stunden wurden effektiv aufgewendet? Was wurde geliefert?
•
Diskutieren, was gut gelaufen ist.
•
Diskutieren, was nicht so gut gelaufen ist.
•
Entscheiden, was im nächsten Sprint verändert wird.
Das ist ein kontinuierlicher Lernprozess.
Die Sprint Retrospective ist kein auferlegtes Muss vom Management. Hier ist das Team auf
sich gestellt - selbstorganisierend und selbstregulierend. Gerade aber die Anpassung der
Team Velocity ist ein sinnvolles Planungsinstrument und hilft weitere Releasezyklen realistischer zu planen.
Version: 1
Seite 9 von 18
Diskussionspapier
3Die Rolle dynamischer Sprachen
Theoretisch kann ein agiler Softwareentwicklungsprozess mit jeder Sprache realisiert werden.
Allerdings haben dynamische Sprachen Vorteile der kurzen Entwicklungszyklen, wie sie in agilen Projekten notwendig sind.
•
schnelle Erlernbarkeit
neue Teammitglieder sind sehr schnell produktiv. Die Ausbildung der Mitarbeit ist schnell
und hart an der Praxis möglich.
•
Klare, pragmatische Sprachstruktur
Man beschäftigt sich mit dem Geschäftsproblem und nicht damit, die Sprache oder Frameworks oder IDEs zu verstehen (Framework als Mittel zum Zweck)
•
pragmatische Handhabbarkeit
Änderungen sind sofort sichtbar. Technologien sind auf Teamwork ausgelegt.
Die Komplexität der Fachlichkeit wirkt sich auf die technische Abbildung aus, diese wiederum fordert von den Mitarbeitern die Skills diese zu ermöglichen. Hat man sofortiges Feedback dessen, was man programmiert hat, kann in iterativen Zyklen auf die Fachlichkeit eingegangen werden und so Fachlickeit, Skills und Abbildung zusammengeführt werden.
Version: 1
Seite 10 von 18
Diskussionspapier
4Eigenschaften verschiedener Sprachen bzw. Frameworks
In diesem Kapitel werden verschiedene Sprachen, die sich für Scrum eignen, kurz charakterisiert.
4.1Groovy
Hierzu kann derzeit von den Autoren keine Aussage getroffen werden. Eventuell kann hierzu
7IT Architektur einen Beitrag liefern.
4.2Smalltalk
Smalltalk ist eine rein objektorientierte Programmiersprache, eine große Klassenbibliothek und
eine interaktive Programmierumgebung in einem.
Smalltalk ist die erste konsequent objektorientierte Sprache (und die zweite Sprache mit OO-Elementen nach Simula, für das die OO-Konzepte erfunden wurden). Smalltalk ist heute eine eher elitäre Sprache, in der ein ausgewählter Anwenderkreis die objektorientierten Konzepte
vollständig nutzen und in der nach wie vor revolutionäre Frameworks, wie Seaside, entstehen.
Die Programmiersprache Smalltalk ist rein objektorientiert, reflexiv, implizit getypt und besitzt
Schnittstellen zu allen gängigen Systeme wie CICS, SAP, Notes, MQ, Office....
Rein objektorientiert bedeutet, dass jeder Wert und jede Datenstruktur ein Objekt ist.
Reflexiv bedeutet, dass Smalltalk in Smalltalk implementiert ist. Die Objekte, die die Sprache
Smalltalk definieren, sind selber mit den Mitteln der Sprache beschrieben. Daher sind Klassen
und Methoden selber wieder Smalltalk-Objekte und gehen bei der Übersetzung einer Klasse
nicht einfach in dem erzeugten Programm auf. Die Verwendung von Smalltalk Objekten zur Definition des Smalltalk-Systems erlaubt dem Programmierer sowohl die Sprache selbst als auch
die Programmierumgebung zu erweitern.
Eine implizit getypte Sprache besitzt zwar Typen -- in Smalltalk sind dies die Klassen der Objekte -- aber die Zuordnung der Typen zu Objekten erfolgt zur Laufzeit und muss nicht als Typdeklaration zur Programmierzeit angegeben werden. Damit ist Smalltalk typsicher: es ist unmöglich, ein Programm durch Verwendung einer unverstandenen Nachricht zum Absturz zu
bringen.
Die Reflexivität von Smalltalk erlaubt es, eine solche illegale Situation zu erkennen und innerhalb von Smalltalk zu behandeln. Auch die Klassenbibliothek und die Entwicklungsumgebung
sind komplett in Smalltalk realisiert. Compiler, Debugger und das Browsersystem sind SmalltalkProgramme und liegen in der Regel in Quelltexten vor. Der Browser ist gleichzeitig ein integrierter Editor, Sourcecode-Analysator und Refaktorisierungswerkzeug.
Die Schwierigkeit beim Erlernen von Smalltalk besteht nicht im Erlernen der Syntax, denn diese
besteht aus nur 5 Schlüsselworten, sondern eher in der konsequenten Denkweise in einer objektorientierten Welt.
4.2.1Die Stärken von Smalltalk
Die bisher beschriebenen Eigenschaften von Smalltalk als Programmiersprache und -umgebung ergeben in der Praxis einige wichtige Stärken:
•
Smalltalk erlaubt die einfache und flexible Modellierung von Konzepthierarchien, die dem
klassischen Muster der schrittweisen Verfeinerung vom Allgemeinen zum Speziellen folgt.
Version: 1
Seite 11 von 18
Diskussionspapier
Damit bietet sich Smalltalk geradezu prototypisch für die Modellierung von Geschäftswissen
an.
•
Smalltalk ist ein ausgereiftes, hoch-performantes und skalierbares System, das "write-oncerun-everywhere" Ausführung erlaubt und das seit Anfang der 80er Jahre. Die Auswahl der
verfügbaren Plattformen hängt vom Anbieter ab und deckt bei VisualWorks von Cincom alle
aktuellen Workstations von PC, Mac bis hin zu den diversen Unix/Linux-Varianten ab.
•
Im Kontext von Smalltalk ist eXtreme Programming entwickelt
•
Smalltalk kann seine Stärken besonders in einem Umfeld mit hoher Änderungshäufigkeit
ausspielen. Die integrierte inkrementelle Entwicklungsumgebung zusammen mit der Flexibilität, die sich aus der Reflexivität und der impliziten Typisierung ergibt, erlauben schnelle
und jederzeit verifizierbare Modifikationen und schnelle Entwicklungszyklen.
In der Summe aller seiner Eigenschaften, empfiehlt sich Smalltalk für die Entwicklung komplexer und vielschichtiger Systeme, die fortwährend an eine sich ändernde Welt angepasst werden
müssen.
4.2.2Seaside
Seaside ist ein Framework das agile Webapplikationentwicklung unterstützt. Es basiert auf dem
Ajax-Modell zur Erstellung von Webapplikationen und ist durch folgende Merkmale gekennzeichnet:
•
Die Session ist direkter Teil des Codes
•
HTML/CSS wird unterstützt
•
Callbackbasiertes Modell
•
Unterstützt Wiederverwendung durch Komposition von Komponenten
•
Debugging und Entwicklungstools sind direkt im Browser nutzbar
Version: 1
Seite 12 von 18
Diskussionspapier
4.3Ruby
Ruby ist eine Scriptsprache, man kann sich Ruby als einen rein objektorientierten vereinfachten
Zusammenschluss vorstellen.
Aufgabe
Potential
Integration
Ruby kann auf den Plattformen Windows und
Unix mit der gleichen Syntax als Batchsteuerung eingesetzt werden. Es verbindet Datenbank, Officeprogramme und ExeDateien von
Drittanbietern.
über Schnittstellen zur Officewelt können Word
und Excel gesteuert werden. Es können VB
Kommandos ausgeführt werden.
Wie in Perl können allgemeine Scripts zur
Problemlösung geschrieben werden.
Ruby läuft auf Windows und Unix sowie auf allen Plattformen die Java unterstützen,
In Ruby kann Java eingebunden werden. Hierdurch besteht Zugriff auf die Java-Codebasis.
Ruby Programme können in Java eingebunden
werden. (JRUBY siehe[3]) und Ruby kann auch
Java aufrufen.
Officesteuerung
Programmierung von Scripts
plattformübergreifend
Interoperabilität
4.3.1Ruby on Rails
•
Effiziente Entwicklung durch DRY – Prinzip (DRY=Don’t repeat Yourself)
•
Homogenes Framework
•
Konventionen statt Konfiguration
•
Wenig Tools notwendig
•
Eine CRUD – Webanwendung wird generiert (CRUD = Create Replace Update Delete)
•
Erweiterbarkeit ganzer Funktionalitäten durch Plugins
•
schnelle Erlernbarkeit
Version: 1
Seite 13 von 18
Diskussionspapier
•
MVC Pattern
•
Java – kompatibel
•
geringer Beratersupport notwendig
•
keine IDE notwendig (Editor reicht völlig)
•
keine XML – Konfigurations-Orgien
•
schlüssiges Gesamtkonzept – kein Patchwork einzelner Frameworks
Insbesondere der Leitsatz „Konventionen statt Konfigurationen“ trägt zur technischen Komplexitätsreduktion bei. Durch vordefinierte Verzeichnisstrukturen, Namenskonventionen und Vorgehensweisen, findet man sich in den Codes von Kollegen schnell zurecht (Collective Code Ownership)
Ruby on Rails basiert auf dem CRUD – Ansatz. Mit diesen Features ist ein erster Wurf mit Eingabemöglichkeiten in eine Datenbank möglich.
Ruby on Rails ist entstanden, weil Softwareerstellung sich mit der Komplexität der Geschäftslogik beschäftigt, da es diese abbilden soll. Zusätzlich zu dieser Komplexität ist noch die Komplexität von der Realisierungstechnik zu berücksichtigen. Je einfacher diese Technik ist, desto
leichter und schneller sind Lösungen zu erarbeiten. J2EE ist hier an eine Grenze gestoßen, die
diese Entwicklung ausgelöst hat.
4.3.1.1Migrationskonzept
In Ruby existiert ein Migrationskonzept - es wird von vorneherein damit gerechnet, dass Daten
migriert werden müssen, dementsprechend werden Klassen generiert, die hierzu herangezogen
werden können. Die erste Initialisierung einer Datenbank ist, der Rubylogik folgend, lediglich
der Spezialfall der Migration von null auf den ersten Füllstand. Weiterentwicklungen basieren
dann immer auf Migrationen von einer Version zur nächsten. Das heißt die Migration ist immer
Teil der vom Framework unterstützten Entwicklung.
siehe http://blog.kogler-informatik.ch/2006/9/22/rails-vs-j2ee-net
4.3.1.2Skalierbarkeit
Über „Loadbalancer“ sind Railsanwendungen skalierbar.
Ein Problem das bei der Internetplattform Twitter entstanden ist: Ruby on Rails ist ein Framework, welches derzeit „nur“ für eine Datenbank designed ist. Das Nadelöhr bei dieser Internetplattform (200 000 Zugriffe/Stunde) war die Datenbankschicht.
4.3.1.3Anbindung von bestehenden Systemen
Bei der Anbindung von bestehenden Systemen, tut sich Ruby on Rails schwer. Dies liegt daran,
dass der Grundsatz Konvention statt Konfiguration in Ruby vorherrscht. Weicht man von den
vorgegeben Pfaden ab, so ist mit Mehraufwand zu rechnen, da dann tiefer in das Framework
eingestiegen werden muss.
Wie man mit derartigen Fällen umgeht, muss im Einzelfall untersucht werden.
Version: 1
Seite 14 von 18
Diskussionspapier
4.3.1.480 - 20 Regel
80% der Anforderung kann mit den Standard Ruby on Rails umgesetzt werden – über die restlichen 20% muss man reden ;-) .
4.3.1.5Erweiterbarkeit durch Plugins
Ganze WEB-Funktionalitäten können durch Plugins zugekauft bzw. per Freeware installiert
werden. So wurde im Bereich Konvertierung das Berechtigungssystem und Contentmanagementsystem als Plugin realisiert.
4.3.1.6Programm-gestütztes Deployment
Das Deployment wird einmal konfiguriert und kann dann den oder die Server bestücken.
Das Standard-Tool Capistrano ermöglicht auch die Rücknahme von Deployments und Versionen. Es benötigt das Versionierungssystem Subversion.
aktuelle Anwendung : http://mszta01p
Version: 1
Seite 15 von 18
Diskussionspapier
Version: 1
Seite 16 von 18
Diskussionspapier
5konkrete Vorhaben
Die folgende Liste stellt die Vorhaben dar, die mit der oben beschriebenen Webtechnologie umgesetzt werden sollen.
Vorhaben
Bemerkung
Technik
Lettershop (Teilfunktionalität)
- Upload und Steueroberfläche siehe Konzept
zum Druck von pdf und word
- Steuerung der Konverter auf
Windows und Unix , Datenbankanbindungen, Aufbau einer
Batchinfrastruktur mit Rückmeldung und Präsentation der Ergebnisse übers WEB
Crossreferenz für in Formularen Scripting auf dem PC
Scriptingsprache
enthaltene Grafiken
Verwaltungssystem für die Ma- Input für GAVI Druckspezialis- Hohe Kommunikationsterialien beim Druck (Papier - ten und Posyleute
bedeutung
Kuvert - Beilagen) (Material ->
SAP-Nummer -> Gewicht)
Vorhaben, die bereits in Produk- Formularkonvertierung
Ruby für Konverterinfration sind
struktur und Ruby on
Wordtexte werden für EBA, MaRails als Webtechnik.
terialserver und TDS in verschiedene Formate konvertiert .
(http://mszta01p)
Der Unterschied dieser Vorhaben zu den klassischen IT-Projekten in unserem Haus ist, dass es
sich dabei um unterstützende Prozesse und nicht Kernprozesse aus dem Versicherungsgeschäft handelt.
Version: 1
Seite 17 von 18
Diskussionspapier
6 Verweise
[1]
http://www.namics.com/fileadmin/user_upload/pdf/namics_ch-open-2007.03.29.pdf
[2]
http://de.wikipedia.org/wiki/Scrum
[3]
http://wiki.jruby.org/wiki/Main_Page
Version: 1
Seite 18 von 18

agile Softwareentwicklung Diskussionspapier

Transcription

Similar documents

Zusammenfassung - auf ThomasKaelin.ch

Integration von Microsoft Office

Text Retrieval

Ausarbeitung - AG Softwaretechnik