SEO- und Internet-News by TechDivision » Kategorie: Entwicklung/Programmierung

Microsoft ignoriert Safari

geschrieben von Marion Engel am 29. August 2009 um 8:50 Uhr

Da habe ich als gerade versucht, mit dem Safari auf das Keywort-Tool von Microsoft zuzugreifen….

Verpassen Sie keinen Beitrag und abonnieren Sie unseren RSS-Feed.

Die Anforderungsanalyse in der Software-Entwicklung

geschrieben von Marion Engel am 13. Mai 2008 um 8:04 Uhr

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.

kein Kommentar

Outsourcing und Near-Shoring in der Software-Entwicklung

geschrieben von Marion Engel am 28. April 2008 um 14:55 Uhr

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

der Zeitplan eingehalten wird
die Anwendung stabil und möglichst fehlerfrei ist
er einen Ansprechpartner, der Fragen schnell und in der gleichen Sprache beantworten kann
die Anwendung später schnell und problemlos erweitert werden kann

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.

2 Kommentare

PHP Rapid Application Development

geschrieben von Markus Stockbauer am 14. April 2008 um 9:53 Uhr

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

3 Kommentare

xtCommerce Gutscheine und Kupons (Debugging und andere Freuden)

geschrieben von Daniel Sasjadvolk am 12. April 2008 um 8:32 Uhr

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.

26 Kommentare

Web-Entwicklung und Software-Engineering

geschrieben von Marion Engel am 11. April 2008 um 7:58 Uhr

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.

1 Kommentar

Gebet des Web-Entwicklers

geschrieben von Marion Engel am 19. März 2008 um 10:01 Uhr

Lieber Mozilla Firefox, geehrt wirst du in Web-Entwickler-Kreisen
gelobt werde deine Standardkonformität!
Deine Zeit komme, wie bei Entwicklern, so bei allen Anwendern.
Des Programmierers Wille geschehe, nicht nur im Firefox, sondern in allen Browsern.
Unsere tägliche Freude bei der Web-Entwicklung gib uns heute,
und bewahre uns vor Hacks für den Internet Explorer.
Führe uns nicht zur falschen Darstellung von paddings,
sondern erlöse uns von der fehlenden Standardkonformität des IE.
Deine Beachtung der Standards sei das Vorbild,
unter Windows, Linux und Mac.
Return

Fernab von jeglicher Gotteslästerung – schon gar nicht in der Karwoche – ist mir dieses Gebet in den Sinn gekommen, nachdem mich die Familie der Internet Explorer gestern fast in den Wahnsinn getrieben hätte. Viele Web-Entwickler werden mir dabei sicher nickend zustimmen, und wenn es einen Preis für den meist-verfluchtesten Browser gäbe, würde sich sicher ein Kopf-an-Kopf-Rennen zwischen dem Internet Explorer 6 und 7 ergeben. Sie würden konkurrenzlos um den Sieg fighten, während sich die anderen Browser gerade mal aus den Startblöcken erhoben hätten.
Dass der IE mit padding-left und padding-right nichts anfangen kann und entsprechend formatierte Stellen eben nicht einrückt, kann man ja noch verschmerzen, weil es dafür einfache Ausweichmöglichkeiten gibt. Aber dass der Internet Explorer mit meiner Web-Anwendung gerade macht, was er will, ist eigentlich ein fetter Reklamationsgrund. Das Beste daran: ein Codeschnipsel, der an zwei Stellen exakt gleich ist, wird an der einen Stelle korrekt ausgewertet und umgesetzt, an der anderen Stelle aber nicht. Im Firefox kann man solchen Problemen ja mit Hilfe des Firebugs noch recht gut auf den Grund gehen, aber der Internet Explorer kennt ja nicht mal ein solches Helferlein. Zwar bringt mich der IE 6 neuerdings immer mal wieder in einen Debug-Modus, aber er zeigt mir nur die Codestelle, wo das Unglück passiert. Das weiß ich hier schon selber – nur nicht, was den blauen Browser vom standardkonformen Verhalten abhält.

Ein weiteres Problemfeld, das ich mir gleich nochmal näher anschauen muss, sind URLs, in denen Parameter übergeben werden, z.B. www.xyz.html?userId=25&areaId=55&method=post. Im Firefox ist das natürlich kein Problem, und die so aufgerufene Seite kann problemlos mit den Parametern weiter arbeiten. Im IE wird aber bereits diese URL nicht korrekt zusammengebaut, d.h. anstelle der Parameter werden irgendwelche Zeichen verwendet. Dass die aufgerufene Seite dann mangels Informationen ein mehr oder weniger großes Problem bekommt, ist nicht mehr verwunderlich. Allerdings…könnte dieses Problem temporär sein. Denn auf der Suche nach einer solchen “verwuzzelten” URL bin ich eben nicht mehr fündig geworden – obwohl ich doch gestern abend noch froh war, wenigstens diesen Hinweis entdeckt zu haben….

Lieber Firefox…erlöse uns…. Können wir hoffen, dass der Internet Explorer 8 nicht nur standardfkonform, sondern auch bald verfügbar sein wird? Denn die Hoffnung, dass auch “Otto-Normal-Surfer” zum Firefox wechselt, wird sich wohl in absehbarer Zeit nicht erfüllen. Und dass man vor jede Web-Site eine Vorschaltseite baut, die den Benutzer auffordert, doch bitte den Firefox zu installieren, bevor er weitersurft, kann wohl auch nur einem Web-Novizen einfallen – auch wenn es aus der Sicht eines “alten Hasen” durchaus seinen Reiz hätte.

Aber nun zurück in die harte Realität – Fehler suchen im Internet Explorer…und jeden Abend brav beten, vielleicht hilft es ja irgendwann

2 Kommentare

Testen einer Web-Anwendung

geschrieben von Marion Engel am 18. Dezember 2007 um 10:56 Uhr

Wir in Bayern befinden uns ja eigentlich in der “staaden Zeit”, in der besinnlichen Adventszeit, in der wir nach dem Motto des Rattenberger Advents “die Ruhe im Herzen finden” sollen. Aber kann sich das ausgehen, wenn die heiße Testphase einer sehr umfangreichen Web-Anwendung in diese Zeit fällt?

Leider nein. Die besinnlichen Abende bei Kerzenschein werden durch Kunstlicht und Bildschirmflackern ersetzt und rot sind bei mir weniger die Krzen am Adventskranz denn die Augen…

Aber da ich hier ja nicht auf die Tränendrüse drücken und mich bedauern lassen will, hier nun ein paar konkrete Gedanken und Erfahrungen vom Testen. Ich warte nämlich gerade drauf, dass die Programmierer die neue Version einspielen, in denen wieder ein paar mehr Bugs behoben sind, und habe also etwas Zeit.

Testen – da fallen mir 4 verschiedene Ansätze ein:

Ich spiele Anwender und arbeite so mit der Anwendung, wie das später einmal der Fall sein soll. Da ich als Autor des Fachkonzepts natürlich alle Feinheiten kenne, teste ich in dieser Rolle zunächst nur das Verhalten der Anwendung bei bestimmungsgemäßem Gebrauch. Was der boshaft “DAU” (dümmster anzunehmender User) genannte Anwender vielleicht tun könnte, kommt mir natürlich nicht in den Sinn. Aber wenn mein Anwendertest keine Fehler mehr zeigt, ist schon fast die halbe Miete drin.
Ich nehme mir das Fachkonzept zur Hand und vergleiche Stück für Stück, ob alles passt. Ich gehe die Abbildungen der Dialoge durch und vergleiche, ob alle Felder vorhanden sind und alle Texte passen. Ich führe die genannten Benutzeraktionen durch und prüfe, ob sie das spezifizierte Verhalten hervorrufen. Das ist zum Anwendertest sinnvoll, denn von den über 100 Seiten Fachkonzept habe ich natürlich nicht mehr jedes feine Detail imKopf.
Ich werde zum anwendungsorientierten Tester. In dieser Rolle teste ich bewusst auch den nicht bestimmungsgemäßen Gebrauch der Anwendung. Nach dem Motto “garbage in, garbage out” kann ich zwar nicht erwarten, dass eine Anwendung aus nutzlosen Eingaben Gold macht. Ich erwarte aber schon, dass sie mich zumindest einigermaßen führt und versucht, auf den Pfad zu sinnvollen Angaben zurückzubringen.
Man kann es kurz ausdrücken: Auch wenn sich der Anwender auf die Tastatur setzt, darf die Anwendung nicht abstürzen, sondern muss in einem definierten Zustand bleiben. Wenn sie in einer solchen Situation die Fehlermeldung ausgibt, dass der Anwender seine Eingaben noch einmal überprüfen soll, weil sie nicht den Erwartungen entsprechen, wäre das beispielsweise eine gute Reaktion.
In Fachkreisen wird hier auch von Extremwert-Testfällen gesprochen. Bei einem Eingabefeld für Buchstaben sollte man z.B. auch einen Test mit der Eingabe von Zahlen oder Sonderzeichen durchführen. Auch unsere deutschen Umlaute erweisen sich in der aktuellen Anwendung als böse Stolpersteine, die nicht immer korrekt angezeigt werden.
Kann ein Eingabefeld nur eine maximale Zahl an Zeichen aufnehmen, sollte man auch ausprobieren, was passiert, wenn man an diese Grenze bzw. über diese hinaus geht. Ich hatte gestern beispielsweise den – fast lustigen – Fall, dass mit der Eingabe des letzten zulässigen Zeichens meine numerierte Liste in eine durchgehende Zeichenkette umgewandelt wurde…
Können Bilder in die Anwendung hochgeladen werden, lohnt es sich auch, einmal zu testen, wie mit Bildern verschiedener Größe verfahren wird. Zwar ist es gemein, ein fast 1 m breites Bild in ein maximal 10 cm breites Bildfenster hochzuladen, aber genau das sind die Extremwerte. Ich erwarte nicht, dass dieses Bild dann noch erkennbar ist. Aber ich erwarte, dass es unter Beibehaltung der Relationen aus Höhe und Breite so verkleinert wird, dass es im vorgesehenen Rahmen Platz findet.
Dann gibt es noch einen weiteren Ansatz, mit dem die Studenten in Informatik-Studiengängen im ersten Semester vertraut gemacht werden. Es handelt sich allerdings eher um einen theoretischen Ansatz, der nicht nur die imperative Programmierung sondern auch kleinste Programmieraufgaben voraussetzt, die nur in Klausuraufgaben, nicht aber in der Praxis vorkommen. Die Idee hinter diesen Tests zur Pfadüberdeckung ist, dass jede Zeile des Code im Test einmal durchlaufen werden muss. So wird geprüft, ob alle if/then/else-Weichen und Schleifen durchlaufen werden oder überhaupt erreichbar sind.
Aber da ja heute überwiegend objektorientiert programmiert wird, entfällt diese Möglichkeit zum Test schon aus diesem Grund. Und selbst bei einer COBOL-Anwendung, an der ich noch vor einem Jahr mit programmiert habe, waren sie aus mengenmäßigen Gründen nicht durchführbar.

Je nach Anwendung werden gegen Ende auch noch Performance- oder Lasttests durchgeführt, um festzustellen, was passiert, wenn der erhoffte Ansturm der Nutzer kommt.

Den abschließenden Test, den Abnahmetest, wird dann natürlich der Kunde durchführen. Er wird die Anwendung sicher auch noch zusätzlich aus dem Blickwinkel des Anwenders betrachten und prüfen, ob alle Abläufe leicht verständlich und intuitiv sind…und welche weiteren Features in der nächsten Ausbaustufe nachgeschoben werden.

Wie ist das nun mit den Fehlern? Muss sich der Programmierer für jeden gefundenen Fehler schämen? Kriegt der Tester für jeden gefunden Fehler ein “Gutzetterl”? Die fehlerfreie Anwendung gibt es nicht. Das lernt man auch schon im 1. Semester Informatik. Fehler passieren immer, das ist ganz normal – also Entwarnung für den Programmierer. Und solange er und der Tester nicht zu dem Irrglauben kommen, sie befänden sich in einem persönlichen Kleinkrieg, ist die Welt in Ordnung. Das Ziel ist eine Anwendung, die so fehlerarm wie möglich ist. Logischerweise ist das bei einer Anwendung, die beispielsweise eine Mondrakete steuert, wesentlich enger auszulegen als bei einem unbedeutenden Spiel.

Meine Programmierer haben mir nun die neue Version geliefert, und ich “mutiere” wieder zum Fehlerdetektiv.

Über die Anwendung wird nach den Go-Live sicher auch hier noch zu berichten sein, denn es ist eine höchst interessante Geschichte. Aber ein bisschen Geduld ist noch erforderlich.

kein Kommentar

WEB-TREND MAP 2007

geschrieben von Pixelqueen am 10. September 2007 um 17:46 Uhr

Die 200 einflussreichsten und erfolgreichsten Websites geordnet innerhalb eines U-Bahn Plans nach Kategorie, Verwandtschaft, Erfolg, Popularität und weiterer Perspektive: Die Web Trends Map 2007. Die interaktive Version verlinkt direkt zu den angegebenen Seiten.

(Quelle:Freie Universität Berlin)

kein Kommentar

Against Comic Sans!

geschrieben von Pixelqueen am 26. Juni 2007 um 7:17 Uhr

Jetzt ist es schon so weit. Schriften die keiner mag werden einfach verdammt. In einem Programm zum Untertiteln von Videos, Aegisub, warnt eine Dialogbox vor der typografisch riskanten Verwendung der Comic Sans … Und für die richtigen Comic Sans Gegner habe ich diesen Link hier!