storzs, 11. Oktober 2011 1 Kommentar RSS
Zum siebten Mal fand dieses Jahr die internationale TYPO3-Konferenz T3CON11 statt und wie erwartet, war sie ein großer Erfolg. Über 370 Besucher aus 13 Ländern kamen in Frankfurt zusammen, um sich zu TYPO3 zu informieren, zu debattieren und Neues zu lernen, neue Bekanntschaften zu machen – und natürlich, um die berühmte T3CON-Party am Abend zu begehen. Was sind die News aus dem TYPO3-Universum?
Michael Schubart, 15. September 2011 kein Kommentar RSS
Das TYPO3 camp fand vom 9. – 11. September 2011 in München statt und hatte mit der Mediadesign Hochschule (MDH München) eine neue, moderne Location mit bester Ausstattung gefunden. Auch die Organisation des 4. TYPO3 camps war aus unserer Sicht eine tolle Leistung und verdient Anerkennung. Das Themen-Camp fand erneut im Format eines Barcamps statt und ermöglichte allen Besuchern die Veranstaltung aktiv mitzugestalten. Dank der 150 hochkarätigen Teilnehmer hatte das TYPO3 camp auch dieses Jahr wieder höchstes Niveau und war mit vielen interessanten Vorträgen gespickt.
admin, 28. Februar 2011 kein Kommentar RSS
Scrum ist als alternative Entwicklungsmethode für Softwareprojekte bekannt. Die 3. Auflage von Boris Glogers Buch “Scrum”, das gerade im Hanser Verlag erschienen ist, macht aber schnell neugierig, mehr von Scrum zu erfahren, soll es damit doch erfolgreichen Unternehmen gelungen sein, “die Innovationskraft ihrer Mitarbeiter zu wecken, zu erhalten und zu nutzen. So erreichen sie nicht nur den Verstand ihrer Mitarbeiter, sondern auch deren Herz und Leidenschaft.” Und dass das die Zutaten sind, die über Erfolg und Misserfolg von Unternehmen entscheiden, haben ja bereits die Business-Querdenker dargestellt.
Lesen wir also mal genau im genannten Buch nach.
admin, 29. August 2009 1 Kommentar RSS
Da habe ich als gerade versucht, mit dem Safari auf das Keywort-Tool von Microsoft zuzugreifen….
admin, 13. Mai 2008 kein Kommentar RSS
Bei der Entwicklung komplexer Software-Systeme und auch bei größeren Internet-Auftritten und Web-Anwendungen sollte die Anforderungsanalyse den ersten Schritt auf dem Weg zum Endprodukt darstellen.
Meistens hat der Kunde bereits eine gewisse Vorstellung von der Site bzw. der Anwendung, die ihm sein Auftragnehmer erstellen soll. Manchmal werden bereits Pflichtenhefte zur Verfügung gestellt, wenn Angebote eingeholt werden. Das ist sicher sinnvoll, denn wenn man nicht weiß, was man bauen soll, kann man ja weder sagen, was das kostet noch wie lange die Realisierung dauert. Aber auch wenn der Kunden seinen Auftragnehmer ausgewählt hat, sollte sie zusammen eine ausführliche Anforderungsanalyse erstellen. Was passiert nun während dieser Anforderungsanalyse? Was ist ihr Ziel und wer hat welche Aufgaben?
Zunächst das Ziel in Kurzform: Die Anforderungsanalyse ermittelt, was das fertige System können muss. Die Ergebnisse werden im Pflichtenheft festgehalten.
Der Auftragnehmer muss genau wissen, was der Kunde benötigt und erwartet. Denn nur in diesem Fall kann eine Anwendung gebaut werden, die die Erwartungen des Kunden auch tatsächlich erfüllt.
Zunächst müssen sich die Auftragnehmer in die Fachlichkeit des Kunden einarbeiten. Vielleicht kann der Kunde die erste Orientierung durch Firmenbroschüren und Produktbeschreibungen ermöglichen. Danach werden die Auftragnehmer dem Kunden etliche fachliche Fragen zu seiner Branche, seinen Aufgaben, Angeboten und zu den fachlichen Hintergründen des Projekts stellen. Diese Fragen der Fachfremden werden sicher auch dem Kunden helfen können, sein eigenes Geschäft einmal aus einem anderen Blickwinkel und ohne eine gewisse, normale „Betriebsblindheit“ zu sehen. Sobald der Auftragnehmer das Geschäft des Kunden verstanden hat, kann es Vorschläge für Funktionalitäten des Systems machen und abschätzen, ob sich die Anforderungen, die der Kunde bereits formuliert hat, realisieren lassen.
Anforderungen für das neue System können sich aus aus dem bisherigen System ergeben – sofern es ein solches gibt. Manche Inhalte der bisherigen Web-Site sollen möglicherweise übernommen werden, und manche Funktionalitäten der aktuellen Anwendung muss auch das neue System besitzen. Ein gewisser Blick auf die Mitbewerber des Kunden kann auch nicht schaden, denn hier kann man durchaus ein paar Anregungen für Dos und Don’ts bekommen.
In manchen Branchen gibt es Gesetze oder Regelungen, die bei der Realisierung der Anwendung berücksichtigt werden müssen.
Eine ganz wichtige Rollen spielen natürlich die späteren Anwender des Systems. Handelt es sich um eine interne Anwendung, so besteht sicher die Möglichkeit, die späteren Benutzer direkt zu befragen. Bei einer Internet-Anwendung oder einem Internet-Auftritt könnten ebenfalls einige mögliche Nutzer nach ihren Erwartungen befragt werden. Und das Team des Auftragnehmers kann sich natürlich auch selber fragen, wie es in der Rolle des Nutzers agieren würde und wie die Anwendung insgesamt einen möglichst hohen Nutzen stiften kann.
Hat man alle Anforderungen gesammelt, ist es mitunter nötig, diese zu priorisieren, weil sich einfach nicht alle davon im ersten Schritt realisieren lassen. Es gilt dann zu ermitteln, welche Anforderungen vom Kunden als selbstverständlich vorausgesetzt werden. Daneben wird es weitere Anforderungen geben, die der Kunde explizit fordert. Möglicherweise bleiben dann noch weitere Anforderungen übrig. Für diese gilt zu ermitteln, wie stark die Zufriedenheit des Kunden steigen wird, wenn sie erfüllt werden. Je größer die Zufriedenheit, desto wahrscheinlicher die Realisierung.
Die Anforderungen fließen in die Spezifikation ein und bilden nach Abschluss der Realisierungsphase die Eckpunkte für die Testphase und die Abnahme.
Die Anforderungsanalyse sollte sehr sorgfältig durchgeführt werden, auch wenn teilweise der Eindruck entstehen sollte, dass dafür nicht genug Zeit oder Geld vorhanden ist. Denn wenn man erst während der Realisierung feststellt, dass Anforderungen fehlen oder falsch definiert wurden, entsteht meist ein erheblich höherer Aufwand.
admin, 28. April 2008 2 Kommentare RSS
Es war einmal ein Software-Haus, in dem die Geschäftsleitung den Mitarbeiternvor einigen Jahren mitgeteilt hat, dass in Zukunft auf Entwickler in einem Ostblock-Land zurückgegriffen würde. Zunächst hatten natürlich alle Angst, dass in diesem Zuge zumindest einige Arbeitsplätze in Deutschland wegfallen würden. Nein, so die Geschäftsleitung, das Gegenteil sei der Fall. Durch das Outsourcing würden die deutschen Arbeitsplätze gesichert. Durch die Preisvorteile, die sich durch die Kollegen im Ostblock ergeben, könne man ganz andere Projekte „an Land ziehen“. Und überhaupt, würden die Kunden ganz einfach verlangen, dass Outsourcing im Angebot enthalten ist.
Wenn es der Kunde verlangt, darf der „kleine“ Mitarbeiter natürlich nicht widersprechen. Ob die Rechnung letztendlich aufgegangen ist, wurde allerdings nie verraten. Für die Mitarbeiter war nur ersichtlich, dass die ausländigen Kollegen schon bald nach höherem als nur simplen Programmiertätigkeiten verlangt haben, dass es durch die geografisch verteilte Arbeit noch mehr „Häuptlinge“ gab, dass simple Team-Meetings per Video-Konferenz ausgetragen werden mussten und dass man bei Fragen nicht mal schnell zum Kollegen ins Nachbarzimmer gehen konnte.
Der Kunde verlangt es – aber was genau verlangt er denn? Wenig zahlen will er, das ist ziemlich klar. Das wird uns ja ständig von der Werbung suggeriert. Ob nun Geiz geil ist, die Preise unter der Tiefpreislatte bleiben müssen oder irgendwas fast nixx kost’. Inzwischen steuert die Werbung allerdings auch schon gegen und will dem Konsumenten klar machen, dass ein Schnäppchen ja unter dem Strich eigentlich viel mehr Aufwand verursacht als man meint. Aber ein Kunde, der eine Software-Anwendung benötigt, hat mit Sicherheit auch genaue Vorstellungen, was diese Anwendung können muss. Und er hat sicher ebenso hochgesteckte Erwartungen an seinen Dienstleister. So möchte er, dass
Es ist allerdings nicht so, dass die Aufgaben, die in einem Software-Projekt anfallen, in isolierte Arbeitspakete geteilt, an unabhängig arbeitende Programmierer verteilt und nachher einfach zusammengeführt werden können. Auch wenn eine Software-Anwendung eine Einheit aus mehreren Teilen ist, müssen diese reibungslos zusammenarbeiten. Baut ein Programmier ein Puzzleteil mit einer runden Aussparung, der andere allerdings ein Puzzleteil mit einem eckigen Ärmchen, kann kein Bild entstehen, auch wenn die einzelnen Puzzleteile noch so schön sein sollten.
Nun mag man einwenden, dass die Anforderungen ja eindeutig in der Spezifikation festgelegt sind. Richtig, aber bei einer internationalen Zusammenarbeit kommen unterschiedliche Sprachen ins Spiel. Mindestens einer der Beteiligten wird eine Spezifikation vorfinden, die nicht in seiner Muttersprache vorliegt. Mindestens einer der Beteiligten wird die Kommunikation in einer Sprache durchführen müssen, die nicht seine Muttersprache ist. Im „schlimmsten“ Fall gilt für die Spezifikation und Kommunikation eine Sprache, die für keinen der Beteiligten die Muttersprache ist. Nicht nur, dass hier die Wahrscheinlichkeit für Missverständnisse und vermehrte Nachfragen steigt, es sind auch immer wieder Übersetzungsarbeiten erforderlich. Wie lange dauert es, eine Dokument von 100 Seiten gut und fehlerfrei zu übersetzen? Was kostet diese Arbeit, wenn sie intern durchgeführt wird, was, wenn sie extern vergeben werden muss? Was kostet die sprachbedingt zusätzlich erforderliche klärende Kommunikation an Zeit und Aufwand? Und was ist, wenn der Programmierer etwas anderes baut, als verlangt war, weil er es falsch verstanden hat? Dass hierdurch Verzögerungen im Zeitplan auftreten und das interne Budget in eine Schieflage geraten muss, sollte klar sein.
Was ist, wenn der Programmierer, der an einer isolierten Aufgabe ohne Gesamtblick auf das Projekt und ein gewisses „Feeling“ für den Kunden arbeitet, Variablen mit wenig sprechenden Namen bezeichnet oder mit der Zeit frustriert ist und bei der Dokumentation des Codes nachlässig wird? Wenn nach einigen Monaten Änderungen oder Erweiterungen seines Codes erforderlich sind, ist er – nach Murphy – meist nicht mehr verfügbar oder kann sich selbst nicht mehr erinnert, was er damals zusammenprogrammiert hat. Also gerät erneut der Zeitplan in Gefahr, da sich ein anderer Programmierer erst einarbeiten und den Code verstehen muss.
Das sind nur ein paar Überlegungen, mit denen ich nicht sagen will, dass Outsourcing nicht funktionieren kann. Ich möchte nur davor warnen, Outsourcing als das Allheilmittel für alle Lebenslagen zu betrachten. Wirtschaftlich denken ist zwar in Ordnung, aber bevor man übertriebenes Sparen und Drücken von Preisen beginnt, sollte man nachdenken, ob dies wirklich nötig und angemessen ist. So gab es vor kurzem ein positives Beispiel von Solidarität im Preiskampf: Die Österreichischen Bundesforste haben zwei Sägewerke von ihrer Kundenliste gestrichen, die kleinen Waldbauern das Holz nach dem Sturm Paula um bis zu 30 EUR unter dem Marktpreis abgekauft hatten.
Wer Erfahrungen mit dem Outsourcing in Software-Projekten hat, ist eingeladen, diese in einem Kommentar mit allen zu teilen.
Markus Stockbauer, 14. April 2008 3 Kommentare RSS
oder warum es manchmal besser ist, ein Programm schnell zu Entwickeln, als ein schnelles Programm zu entwickeln
Seit geraumer Zeit sind PHP Frameworks für die rasche und saubere Entwicklung von Webanwendungen in aller Munde. In anderen Programmiersprachen wie Java oder Ruby sind Frameworks bereits nicht mehr wegzudenken. Server werden immer leistungsfähiger, so dass auch bei der Webseitenerstellung mit PHP weniger auf Performanceoptimierung geachtet werden muss. Statt dessen kann man sich darum kümmern, die Anwendung in kürzerer Zeit, aber trotzdem fehlerfrei zu erstellen.
Diesem Konzept folgen die gängigen PHP Frameworks. Sie alle erzeugen Programmcode, der zwar auf dem Server teils sehr ineffektiv ausgeführt wird, jedoch für den Entwickler deutlich leichter zu handhaben ist. Die vereinfachte Handhabung äußert sich unter anderem darin, dass stetig wiederkehrende, immer gleiche Programmstrukturen automatisch generiert werden und sich der Entwickler somit auf die eigentliche Struktur seines Projektes konzentrieren kann.
Wenn man im Internet nach PHP Framework sucht, bekommt man (z.B. von Google) eine Liste mit mehreren millionen Treffern. Nicht ganz so viele, aber dennoch eine inzwischen schwer überschaubare Auswahl gibt es an verschiedenen Frameworks.
Sie alle setzen – auf die eine oder andere Weise – das sog. MVC Konzept um. Unterschiede gibt es vor allem in der Gewichtung der einzelnen Schichten. Frameworks wie CakePHP und Prado stellen zahlreiche ausgereifte View-Helper (das V in MVC) zur Verfügung, während Struts4PHP sich z.B. zur Aufgabe gemacht hat, die Models und Controller möglichst praxistauglich umzusetzen, sowie ein ausgefeiltes Objektrelationales Mapping (ORM) zu ermöglichen. Die View-Schicht überlässt es spezialisierten Libraries wie z.B. Smarty.
Viele Entwickler haben – verständlicher Weise – längst den Überblick verloren, welches Framework denn nun für ihr Projekt das richtige ist. Hinzu kommt noch, dass natürlich jedes einzelne Produkt für sich in Anspruch nimmt, das MVC-Konzept am besten umzusetzen. Neben den Anforderungen für das eigene Programm, dass es zu entwickeln gilt, sind vor allem auch die persönlichen Präferenzen wichtig.
Möchte man sich nicht so sehr um die Optik kümmern und die erstellung des (X)HTML-Codes zu möglichst großen Teilen dem Framework überlassen? Oder ist es wichtig, die Templates und den erzeugten Code bis ins kleinste Detail unter Kontrolle zu haben? Hat man es lieber, wenn die Datenbankstruktur vom Framework generiert wird, oder muss man sich an bestehenden Datenbanken orientieren? Dies sind nur zwei Beispiele für die zahlreichen Auswahlkriterien.
Praxiserfahrungen gibt es, trotz der Tatsache dass Frameworks für PHP eine recht junge Errungenschaft darstellen, bereits einige. So wird für das CMS Mamboo 5 CakePHP eingesetzt. Die E-Commerce Lösung Magento benutzt das Zend Framework, während das Expertenportal BrainGuide sich voll und ganz auf Struts4PHP verlässt. Doch kaum ein Entwickler hat die Zeit, sich für ein geplantes Projekt im Vorfeld eingehend mit den verschiedenen Möglichkeiten zu beschäftigen.
Daher ist das Framework der Wahl meist einfach das, welches der Entwickler zuerst entdeckt hat. Während der laufenden Entwicklung ist es kaum noch möglich, sich umzuentscheiden. Es ist somit wichtig, bereits in der Konzeptphase des Projektes zu evaluieren, welches Framework die eigenen Anforderungen am besten erfüllt, oder ob man überhaupt eines verwenden möchte.
Eine gute Übersicht der verbreiteteren Frameworks hat das Blog von masterbootrecord.de zu bieten. Eine Einführung ins MVC-Konzept und eine Übersicht einiger vielversprechender Umsetzungen davon gibt es auf testticker.de
Auf der Suche nach dem perfekten PHP-Application-Framework
PHP-Frameworks: Baukästen für PHP-Entwickler
Josef Willkommer, 12. April 2008 33 Kommentare RSS
Wer kennt das nicht, man öffnet seinen Briefkasten und wird von Werbung, Gutscheinen und Wertkupons niedergestreckt. Viele ärgern sich über diese eher lästigen Papierfetzen, die zu meist ihren Weg in den Papiermüll finden.
Aber im Grunde freut man sich dann manchmal doch, wenn etwas Brauchbares dabei ist und nutzt den ein oder anderen Gutschein um von Preisnachlässen oder sonstigen Vergünstigungen zu profitieren. Das wissen auch die Initiatoren und machen natürlich munter weiter mit ihren Aktionen.
Dies ist auch im Bereich des e-Commerce nicht wegzudenken und wird gerne von den Kunden gesehen. Rabatt hier, Preisnachlass da, 50% weniger dort! Besuchen Sie unseren Shop und sparen sie mit diesen Kupon 25 €! Das sind Schlagworte die einen magisch anziehen und die auch von Webshop-Betreibern gerne genutzt werden.
Auch xtCommerce bietet diese Funktion als Modul an. Nach durchforsten bekannter Foren, kann diese auch „relativ schnell“ genutzt werden, was aber noch lang nicht heißen soll, dass alles reibungslos funktioniert wie man es sich vorstellt.
D. h. im Allgemeinen kann ein Gutschein bzw. ein Kupon auf alle Artikel sehr schnell genutzt werden. Dennoch will nicht jeder Verkäufer auf alle Produkte den gleichen Rabatt gewähren. Will man also nur einen oder ein paar Produkte mit einem gewissen Preisnachlass verkaufen, sollte man sich diesen Artikel genauer ansehen.
Hier eine kleine Anleitung für die Installation:
1. Im Admin-Bereich unter: Konfiguration/Zusatzmodule muss das Gutscheinsystem erst einmal aktiviert werden (d. h. man setzt das Ganze auf true)
2. Unter Module/Zusammenfassung müssen dann noch zwei Module installiert und eingestellt werden: Rabatt Kupons (ot_coupon) und Gutscheine (ot_gv)
Einstellungen ot_coupon:
Wert anzeigen: true
Sortierreihenfolge: sollte nach Zwischensumme und vor der UST kommen
Inklusive Versandkosten: true
Inklusive MwSt: true
MwSt. neu berechnen: standard
MwSt.-Satz: Standardsatz
Einstellungen ot_gv:
Wert anzeigen: true
Sortierreihenfolge: sollte nach Zwischensumme und vor der UST kommen
Freigabeliste: true
Inklusive Versandkosten: true
Inklusive MwSt: true
MwSt. neu berechnen: standard
MwSt.-Satz: Standardsatz
Guthaben enthält MwSt.: false
3. Anlegen eines Kupons für einen bestimmten Artikel.
Gehen wir von einem Rabatt Kupons über 25 € für ein Produkt mit der ID 1 aus.
Um einen Kupon anzulegen einfach unter Gutscheine/Kupons auf Kupon Admin und dann auf Einfügen.
So sollte in unserem Beispiel das Formular ausgefüllt werden:
Kupon Name: 25 Euro
Kupon Beschreibung: 25 Euro Rabatt für das Produkt mit der ID 1
Kupon Wert: 25
Kupon Mindestbestellwert: „je nachdem“
Versandkostenfrei: false
Kupon Code: wird generiert oder kann mit max. 16 Zeichen selbst eingetragen werden
Anzahl/Verwendungen pro Kupon: frei lassen für unlimitierte Benutzung
Anzahl/Verwendungen pro Kunde: 1 (für die einmalige Verwendung)
Liste der gültigen Artikel: 1 (Hier kann durch ein Komma getrennt eine Liste der Produkte eingetragen werden, auf die der Rabatt gewährt werden soll. In diesem Fall nur ein Produkt mit der ID 1)
Liste der gültigen Kategorien: leer (damit habe ich mich erst mal noch nicht befasst)
Gültig ab: „je nachdem“
Gültig bis: „je nachdem“
4. Was bisher leider noch keinem aufgefallen ist! Die Zuweisung eines Rabatt-Kupons auf ein bzw. mehrere bestimmte Produkte funktionierte nicht. Falls der Kunde seinen Kupon einlösen will, den er vom Shop-Betreiber erhalten hat, bleibt er spätestens bei den Versandoptionen „checkout_shipping.php“ in einer Endlosschleife hängen!
Dies wird leider auch nicht mit der Kupon_fix.zip gelöst, da dieses Update sich nur um die MwSt. dreht. Nach längerem Suchen im Netz und den bekannten Foren wie www.ecombase.de und www.xt-commerce.com habe ich das Ganze selbst in die Hand genommen und mich ans Debugging gemacht.
Der Fehler fand sich nach längerem Suchen letztendlich in der Datei: “includes/modules/order_total/ot_coupon.php”, in der Methode calculate_credit($amount).
Es handelt sich wirklich um eine Lappalie. In Zeile 178, fand sich ein schlichter Schreibfehler in folgender Schleife: „for ($ii = 0; $p < count($pr_ids); $ii ++)“
Ich ersetzte die Variable $p durch die Variable $ii und nach dem Upload auf den Server gab es keine Probleme mehr.
Da fragt man sich doch, wo kommt dieser Fehler her? Der erste Verdacht fällt natürlich auf das Update „Kupon_fix.zip“ in der sich der Fehler auch fand.
Nachdem ich mir die Datei „ot_coupon.php“ in der Version 3.03 von xtCommerce ansah und ich diesen Fehler nicht fand, hatte sich der Verdacht schon fast bestätigt. Aber, da mich die Sache doch etwas, sagen wir „gereizt“ hat, sah ich mir noch die jungfräuliche Version 3.04 SP2.1 von xtCommerce an. Das Problem fand sich auch hier. D. h. der Fehler kam aus der aktuellen unberührten xtCommerce Version 3.04 SP2.1.
Nach dem inspizieren der letzten Versionen seit 3.03 bis zur aktuellsten 3.04 SP2, musste ich feststellen, dass die Version 3.03 wirklich die letzte Version ohne den Schreibfehler in der Schleife ist. Bleibt natürlich die Frage, ob es da schon funktionierte, wobei es hier für mich aufhört und ich auch nicht weiterbohren will.
Lange Rede kurzer Sinn, ich hoffe mit diesem Artikel einigen geholfen zu haben, da meiner Meinung nach ein Rabatt auf „bestimmte“ Produkte für Shop-Betreiber unabdingbar ist und sich nicht durch „kleine Schreibfehler“ in der Software aufhalten lassen dürfte!
Zu guter letzt noch die die Datei Gutschein Kupon Final als Bugfix zum Download.
admin, 11. April 2008 1 Kommentar RSS
Zwei Welten begegenen sich? Cool und spontan gegen langweilig und durchorganisiert?
Klischees, keine Frage, auch wenn sie sich hier und da bewahrheiten.
Aber schauen und denken wir doch einfach mal nach. Und zwar an Hand eines Klassikers, dem „Schwarzbuch“ von Ernst Denert, das offiziell den Titel “Software-Engineering” trägt. 1991 gab es die erste Ausgabe und im Jahr 1992 einen korrigierten Nachdruck.
Computer gab es damals schon, keine Frage. Aber von Internet und Web 2.0 konnte man damals nicht mal träumen, weil es schlicht unvorstellbar war, dass man Telex und Lochstreifen bald nur mehr im Museum finden würde.
Und was wurde vor 16 Jahren zur Systemspezifikation geschrieben?
„Die Systemspezifikation eines Informationssystems definiert dessen Schnittstellen zur Umwelt, d.h. zu seinen menschlichen Benutzern und meist auch zu anderen (Nachbar-)Systemen. [...] Sie ist das wichtigste Projektdokument, denn sie legt fest, was die Anwender (Auftraggeber) bekommen sollen bzw. was die Entwickler (Auftragnehmer) zu realisieren haben.“
Streiche „Informationssystem“, setze „Web-Site“. Eine Web-Site hat menschliche Benutzer, ganz klar. Und wenn es sich auch „nur“ um einen durchschnittlichen Internet-Aufritt handelt, wird es eine Datenbank geben, mit der Daten ausgetauscht werden müssen.
„Richtige“ Schnittstellen kommen dann beispielsweise bei Online-Shops ins Spiel, wenn nämlich der Shop mit dem Warenwirtschaftssystem oder der Buchhaltungs-Software zusammenarbeiten soll. Und je umfangreicher ein Web-Projekt wird, desto wichtiger ist eine Spezifikation. Und für Web-Anwendungen ist ein Fachkonzept schlicht unerlässlich.
Leider hat sich diese Erkenntnis aber noch immer nicht überall durchgesetzt. Das mag daran liegen, dass es in der Web-Programmierung viele Quereinsteiger gibt, die die Informatik nicht von der Pieke auf gelernt haben. Das mag auch daran liegen, dass Internet-Projekte ja insgesamt nicht soooo lang dauern und der Kunde es ab der Vertragsunterzeichnung eilig hat und schnell ein Ergebnis sehen will. Und es mag natürlich auch daran liegen, dass nicht alle Kunden eine eigene IT-Abteilung haben, die den Prozess der Software-Entwicklung kennen. Ihnen fällt es folglich nicht immer leicht, die Bedeutung der Spezifikation und ihrer Abnahme zu verstehen.
Dabei ist das ja kein Konstrukt, das es nur in der Software-Entwicklung gibt. Wer ein Haus bauen möchte, wird verstehen, dass es zunächst einen Bauplan geben muss. Nur wenn der Bauherr klar dargestellt hat, wie das Haus aussehen soll, kann der Baumeister mit seiner Arbeit beginnnen.
Und wenn sich jemand beim Schneider einen Anzug schneidern lassen möchte, ist auch hier eine Abstimmung erforderlich, bevor der Schneider den Stoff zuschneidet. Kommt der Kunde zur Anprobe, sind sicher noch kleinere Korrekturen möglich. Aber sollte er zwischenzeitlich zur Ansicht gekommen sein, dass er gar keinen Anzug braucht, sondern eher einen Smoking, ist dieser Änderungswunsch nicht mehr ohne weiteres zu erfüllen.
Genausowenig kann der Bauherr nach dem Richtfest vom Baumeister verlangen, dass doch das ganze Haus unterkellert werden soll und nicht nur die Hälfte der Fläche. Auch die Raumaufteilung lässt sich im Nachhinein nur mit großem Aufwand ändern – wenn tragende Wände betroffen sind, auch gar nicht.
Ist doch logisch, denkt manch einer jetzt bestimmt.
Ja, ist es auch.
Aber trotzdem mangelt es Nicht-Informatikern manchmal an der Einsicht, dass auch Software einen Keller und tragende Wände hat. Und demzufolge bedeuten manche Änderungswünsche in Analogie zum Schneider, dass dieser zumindest Teile des Kleidungsstücks aus einem neuen Stück Stoff neu zuschneiden und die bereits zugeschnittenen Teile wegwerfen muss.
Eigentlich sollte sogar das Interesse des Auftraggebers an einer Systemspezifikation fast noch ein wenig größer sein als das des Auftragnehmers. Denn sobald ersterer die Spezifikation abgenommen hat, weiß er, was er bekommt. Er ist abgesichert und weiß, worauf er sich freuen kann. Er weiß auch, womit er in Zukunft am Markt auftreten wird und wie die Anwendung interne Arbeisprozesse verändern wird. Er hat das Ziel vor Augen und kann sich konkret darauf vorbereiten, denn sollte ihm der Auftragnehmer etwas anderes liefern, kann er dieses zurückweisen oder nachbessern lassen, weil er ja etwas anderes vereinbart war.
Je klarer die Spezifikation ist, desto einfacher wird die Umsetzung für den Auftragnehmer. Er gibt keine Diskussionen mehr über das Ziel, denn das liegt ja fest. Vielleicht kommt man hier und da rechts- und linksrum zum Ziel, aber es gibt keine Alternativziele.
„Die Systemspezifikation ist das wichtigste Projektdokument“. Ein Satz also, der von 1992 bis 2008 nichs von seiner Aktualität eingebüßt hat und der für ein Buchungssystem auf dem Großrechner genauso gilt wie für eine moderne Web-Anwendung und einen umfangreichen Internet-Auftritt.
Automatische Oberflächentests für Magento mit Selenium
admin, 23. Dezember 2011 kein Kommentar RSS
Gestern bin ich über einen Blogbeitrag von Matthias Zeis gestolpert, in dem er auf das Magento Test Automation Framework (TAF) und die sich damit ergebenden Möglichkeiten eingeht. Wir beschäftigen uns auch bereits seit geraumer Zeit mit automatischen Oberflächentests für Magento, die und gerade in den letzten Projekte – z.B. beim Relaunch von WMF – extrem geholfen haben, die Qualität der auszuliefernden Shop-Software zu verbessern. Mit diesem Beitrag möchten wir hier über unsere Ansätze und Erfahrungswerte berichten.
weiterlesen