Organisatorische Vorraussetzungen für UDD

Veröffentlicht von Jens am 30. April 2008

Die organisatorischen Vorraussetzungen für UDD sind im wesentlichen die gleichen wie bei Extreme Programming und werden ausführlich in Extreme Programming. Das Manifest (Kapitel 26 Xp in der Praxis) und Extreme Programming planen (Kapitel 25 Geschäftsbeziehungen) beschrieben.

Besonders hervorzuheben ist dabei, dass Kunden gerne Verträge mit genau fest geschriebenem Umfang haben möchten. Andererseits wollen Kunden aber auch Ihre Meinung ändern können.

Es ist vermutlich noch nie ein Softwareprojekt abgeschlossen worden, in dem sich die Anforderungen nicht im Verlauf der Entwicklung geändert haben.

UDD löst diesen Widerspruch, indem der Kunde bei Projektstart einen groben Plan für die weitere Entwicklung bekommt, seine Meinung aber bei jedem Planungsspiel ändern kann. 

Usability Driven Development 4

Veröffentlicht von Jens am 29. April 2008

Usability Driven Development (UDD) ist ein Vorgehensmodell der Softwaretechnik das Usability in einen agilen Prozess einbindet.

Es soll Entwicklern ein Werkzeug an die Hand geben um Anwendungen in einem iterativen Entwicklungsprozess, auf die Anforderungen von Kunden maßzuschneidern. Dabei soll das System so schnell wie möglich in Produktion gehen und in kurzen Releasezyklen weiterentwickelt werden.

Das Vorbild hierfür ist Extreme Programming das um Elemente des User Centered Design erweitert wurde. Die Grundprinzipien des Vorgehensmodel sind das DRY und das KISS-Prinzip, die in jeder Phase konsequent verfolgt werden.

UDD wendet diese Prinzipien auf alle Aspekte eines Softwarepro jektes an, von grafischen Oberflächen, über Quellcodes und Dokumentation bis zu Verträgen mit Kunden. 

Agile Methoden und Usability 1

Veröffentlicht von Jens am 28. April 2008

Softwareentwicklung muss, um mit den Anforderungen des Marktes Schritt zu halten, mit zunehmender Geschwindigkeit erfolgen. Der Funktionsumfang selbst einfacher Anwendungen wird immer größer, die Anwendungsentwicklung somit komplexer. Zusätzlich ändern sich auch Kundenanforderungen schneller. Methoden der agilen Softwareentwicklung sind ein viel versprechender Ansatz diesen Herausforderungen zu begegnen.

Bedienbarkeit und Benutzerfreundlichkeit ist ein Qualitätsmerkmal guter Software. In Zeiten des Internets, in der die Konkurrenz nur einen Klick entfernt ist, wird Usability immer mehr zu einem entscheidenden Faktor für den Markterfolg. Agile Methoden betrachten Usability nicht in dem Maße, wie es klassische Usability zentrierte Verfahren tun.

Die logische Konsequenz wäre ein Vorgehensmodell das anwenderzentrierte Softwareentwicklung mit Methoden der agilen Softwareentwicklung verknüpft.

Suchmaschinenoptimierung für Rails Anwendungen

Veröffentlicht von Jens am 25. April 2008

Ich bin im Moment dabei mir Gedanken darüber zu machen wie man eine Ruby on Rails Anwendung für Suchmaschinen optimieren kann. Ich plane darüber eine kleine Serie von Artikeln zu schreiben.

Folgende Teile habe ich geplant:

Teil 1 von 4: Aussagekräftige HTML-Titel

Teil 2 von 4: Sinnvolle HTML-Meta Angaben

Teil 3 von 4: Menschenlesbare Urls

Teil 4 von 4: Sitemap.xml

User Centered Design 1

Veröffentlicht von Jens am 21. April 2008

User Centered Design (UCD) ist ein internationaler Standard für die benutzerorientierte Gestaltung interaktiver Systeme. Der Standard ist in der DIN EN ISO 13407 festgehalten. Darin wird ein fachübergreifender, iterativer Entwicklungsprozess beschrieben. Allerdings sind die Methoden nicht genau spezifiziert. Der Iterationszyklus endet, wenn die entwickelten Lösungen den Anforderungen entsprechen.

Hier sind die vier wesentlichen Teilaufgaben des Isoprozesses beschrieben:

User Centered Design nach DIN EN ISO 13407

  1. Nutzungskontext verstehen: Bei dieser Aktivität wird eine Dokumentation erstellt, die beschreibt welche Benutzer, welche Use Cases in welcher Umgebung durchführen sollen.
  2. Spezifikation der Anforderungen: In dieser Phase werden die Anwendungsfälle und Benutzerziele, die erreicht werden müssen damit das System erfolgreich in den Produktivbetrieb gehen kann, identifiziert und beschrieben.
  3. Erstellen von Lösungen: In der Phase “Erstellen von Lösungen” werden die zuvor spezifizierten Anforderungen implementiert.
  4. Evaluierung der Lösungen: Der wichtigste Schritt des User Centered Design ist die Evaluation der Lösungen, im Idealfall durch einen Usability Test mit zukünftigen Benutzern der Anwendung. Dabei wird die Erfüllung der festgelegten Anforderungen bewertet. Festgestellte Abweichungen sind Basis für die nächste Iteration des Entwicklungsprozesses.

Der genaue Wortlaut der Norm kann bei in der DIN EN ISO 13407 nachgeschlagen werden. Eine ausführliche Beschreibung von User Centered Design findet sich in User-Centered Design. Im Practitioner’s Handbook for User Interface Design werden zahlreiche praktische Beispiele für User Centered Design beschrieben.

Behaviour Driven Development

Veröffentlicht von Jens am 17. April 2008

Behaviour-Driven Development (BDD) ist eine Evolution des Denkens hinter Test Driven Development. Dabei wird die Sapir-Whorf Hypothese auf das Schreiben von Tests angewandt. Diese besagt: „zwischen den grammatikalischen Kategorien der Sprache, die eine Person spricht und wie diese Person die Welt versteht und sich in ihr bewegt, besteht eine systematische Beziehung“. Siehe Language, Thought and Reality. Selected Writings von Benjamin Lee Whorf.

Die Sapir-Worf Hypothese ist in der Linguistik umstritten. Unstrittig ist jedoch das Sprache unser Denkenin gewisser weise beeinflusst. Diese Aussage kann bis auf Wilhelm von Humboldts Essay „Über das vergleichende Sprachstudium“ von 1820 zurückgeführt werden.

Bei BDD wird im Vergleich zu TDD nicht ein Testfall definiert, sondern ein Erwartung. Das Ziel ist nicht eine Ansammlung von Tests sondern eine ausführbare Spezifikation der zu entwickelnden Software. Nach Astels „arbeitet man bereits mit BDD wenn man TDD richtig anwendet“. Es existieren spezielle BDD Frameworks die Softwareunterstützung für BDD bieten. BDD kann aber auch mit den bekannten xUnit Frameworks umgesetzt werden.

 

Extreme Programming 5

Veröffentlicht von Jens am 16. April 2008

Extreme Programming (XP) ist ein iteratives Vorgehensmodell der Softwaretechnik, welches eine sehr flexible Arbeitsweise erlaubt. Es wurde von Kent Beck, Ward Cunningham und Ron Jeffries entwickelt.

XP basiert auf 5 zentralen Werten:

  • Respekt
  • Kommunikation
  • Einfachheit
  • Feedback
  • Mut 

Auf diesen Werten basierende Praktiken bilden das Vorgehensmodell Extreme Programming. Kent Beck hat diese in Extreme Programming zusammengefasst:

  • Das Planungsspiel - Der Umfang einer Version wird festgelegt, indem Geschäftsprioritäten mit technischen Aufwandsschätzungen kombiniert werden. Der Plan muss ständig an die Realität angepasst werden.
  • Kurze Releasezyklen - Ein einfaches System soll so schnell wie möglich in Produktion gehen. Darauf folgend sollen in möglichst kurzen Iterationsschritten neue Versionen eingeführt werden.
  • Metapher - Sämtliche Entwicklungen werden an einer gemeinsamen, einfachen Metapher ausgerichtet. Diese Metapher soll für Geschäftsseite und Entwicklerseite gleichermassen verständlich sein. Dadurch soll die einfache Kommunikation zwischen Kunden und Entwicklern sichergestellt werden. 
  • Einfaches Design - Das System soll zu jedem Zeitpunkt so einfach wie möglich strukturiert sein.
  • Testen - Es werden für jeden Teil des System fortwähren Komponententests geschrieben, die fehlerfrei ausgeführt werden müssen.
  • Refactoring - Das System unterliegt einem ständigen Refactoring, um Redundanzen zu verhindern, den Programmcode zu vereinfachen oder flexibler zu gestalten.
  • Programmieren in Paaren - Der gesamte Produktionscode wird von 2 Programmieren geschrieben, die gemeinsam an einem Rechner sitzen.
  • Gemeinsame Verantwortlichkeit - Jeder kann jederzeit beliebigen Code im System ändern.
  • Fortlaufende Integration - Das System wird ständig integriert. Immer dann, wenn eine Aufgabe erledigt worden ist.
  • 40 - Stunden Woche - Man arbeitet prinzipiell nicht mehr als 40 Stunden in der Woche. Überstunden werden nie länger als eine Woche geleistet.
  • Kunde vor Ort - Dem Team soll ein echter, lebender Benutzer angehören, der während der gesamten Arbeitszeit zur Beantwortung von Fragen zur Verfügung steht.
  • Programmierstandards - Programmierer schreiben sämtlichen Code entsprechend Regeln, die die Kommunikation mithilfe des Codes erleichtern.

Diese Best Practices waren schon vorher bekannt und werden teilweise bereits lange genutzt. XP fasst diese Praktiken zu einem funktionierenden Gesamtkonzept zusammen, definiert diese jedoch nicht als Allheilmittel. Wo sie nicht den individuellen Anforderungen eines Projektes genügen sollen sie angepasst werden. 

Test Driven Development 4

Veröffentlicht von Jens am 15. April 2008

Test Driven Development (TDD) bezeichnet eine Methode zur Entwicklung von Software bei der Tests vor der eigentlichen Softwarekomponente entwickelt werden. Test Driven Development folgt dabei einem iterativen Prozess aus drei Schritten: 

  1. Rot - Schreibe einen Test für die nächste Funktion, der fehlschlagen muss.
  2. Grün - Sorge mit möglichst wenig Quellcode dafür, dass wieder alle Tests laufen (grüner Balken für alle Tests).
  3. Refaktorisiere - Eliminiere alle Duplikationen und führe notwendige Abstraktionen ein.

Das Verlagern der Tests vor das Entwickeln von Softwarekomponenten bietet einige Vorteile. So wird die Spezifikation nach und nach in die Testsuite überführt. Daraus ergibt sich eine ausführbare Spezifikation, die in maschinell prüfbarer Form vorliegt. Es besteht weiterhin nicht die Gefahr das Tests, die beim klassischen Wasserfallmodel am Ende des Entwicklungsprozesses stehen, aus Zeitmangel nicht durchgeführt werden. Zusätzlich erleichtert eine Testsuite Refaktorisierungen massgeblich. 

Kent Beck hat in Test Driven Development das Vorgehen anhand von Beispielen beschrieben und nennt ausführliche Test Patterns.

Refactoring 3

Veröffentlicht von Jens am 14. April 2008

Der Begriff Refactoring wurde von William Opdyke geprägt der, 1992, zu diesem Thema promovierte. Refactoring bedeutet: „Verbesserung des Designs von Quellcode nachdem er geschrieben wurde, ohne die Funktion zu verändern“.

Dabei soll insbesondere die Lesbarkeit, Verständlichkeit, Testbarkeit und Erweiterbarkeit verbessert werden. Martin Fowler hat in Refactoring dieses in aller Ausführlichkeit beschrieben. Fowler listet Bad Code Smells auf, die Hinweise geben an welchen Stellen des Quellcodes möglicherweise ein Refactoring notwendig sein könnte und behandelt Methoden, wie verschiedenen Arten von Refactorings durchgeführt werden können.

Refactoring ist heute ein allgemein anerkanntes Werkzeug der Softwareentwicklung. Zahlreiche freie und kommerzielle, meist in IDEs integrierte, Refactoring Browser belegen dies. Für agile Softwareentwicklung ist ständiges Refactoring des Quellcodes eine Grundvorraussetzung.

Styleguide for Rails Projects 1

Veröffentlicht von Jens am 11. April 2008

Principles

DRY - Don’t Repeat yourself.
http://www.jensjaeger.com/2008/04/das-dry-prinzip/ (german)
http://en.wikipedia.org/wiki/DRY

KISS - Keep it Simple Stupid
http://www.jensjaeger.com/2008/04/das-kiss-prinzip/ (german)
http://en.wikipedia.org/wiki/KISS_principle

General

General Ruby Styleguide
http://rubygarden.org/ruby/page/show/RubyStyleGuide

General Rails Styleguide:
http://wiki.rubyonrails.org/rails/pages/CodingStandards

Language

Everything in the source code must be written in english. Including comments, variable names and function names.

Encoding

All files must be encoded with UTF-8.

Methods

Every method should have a meaningful name.
For a procedure name use a strong verb.
Example:

Report.print

 

For a function name use a description of the return value
Example:

Report.publishing_date

 

Avoid meaningless or wishy-washy verbs.
Descripe everything the method does.
Make names of routines as long as necessary.
The average length of methods should be from 15 to 20 characters.

Variables

Every variable should have a meaningful name.
The most consideration in naming is that the name fully and accurately descripe the entity the variable represents.
The average length of a variable should be from 8 to 15 characters.
Use shorter name only for iterators in really short scopes.
Example:

reports.each do |r|
  r.print
end

 

The scope of a variable should be as short as possible.
Arrays should have a plural name.
Example:

reports = Report.find(:all)

 

Everything else should have a singular name.
Example:

report = Report.find_by_id(1)

Constants

Naming like variables.
There should be no numbers in the sourcecode. Every number should be a constant defined in environment.rb.
Example:

PAG_PAGES = 10 #items per page for pagination

Comments

Comment as much as possible.
You shouldn’t comment WHAT your code does (this would be hurt the DRY-Principle), you should comment WHY your code does something.

Stay DRY

If you are doing something more than once, extract it into a method. This is especially the case when it comes to conditional queries. So instead of writing:

@reports = Report.find(:all, :conditions => ["deleted = ", 1])

you should write a method:

class Report < AR::B
  def find_deleted
    find(:all, :conditions => ["deleted = ", 1])
  end
end

Paranthesis

Use paranthesis with “standard” method calls and no paranthesis for helper-style hash arguments. Example:

Report.find_by_id(1)
#instead of
Report.find_by_id 1

but

link_to "view", { :action => "view" }
#instead of
link_to("view", { :action => "view" })

Acknowledgments

Thanks to Florian Gilcher for the helpful comments.