Downloads

Artikel: Kleine Kachel, große (Test-) Welt (Seite 24)
– Testen von Windows-Phone-8.1 Apps
Eine App mag zwar einen enger gesteckten Anwendungsbereich haben als die großen, trägen Anwendungen aus der Desktopgeneration, aber zwingend weniger komplex ist ihre Entwicklung deshalb nicht. Der klassische Anwendungszyklus aus Spezifikation, Design, Entwicklung, Test und Auslieferung findet genauso wie bei den großen Brüdern und Schwestern statt. Die mobile Entwicklung ist sogar aufgrund der vielen Formfaktoren, geringeren Hardwareressourcen, der hohen Releaseanzahl und der Konkurrenz in den App Stores herausfordernder. In diesem Artikel möchten wir uns deshalb mit dem Thema der Qualitätssicherung von mobilen Apps für Windows Phone 8.1 beschäftigen.
von Nico Orschel und Marc Müller

Man kann den Eindruck bekommen, dass die Welt der Softwareentwicklung ausschließlich agil arbeitet – oder zumindest gerne so arbeiten würde. Alle sprechen von iterativer Entwicklung, Sprint-Planung, selbstbestimmten Teams und Product Backlogs. Die klassischen Produktverantwortlichen verschwinden mehr und mehr und werden durch Product Owner abgelöst. Scrum Master kümmern sich unter anderem um die Einhaltung der Spielregeln sowie darum, dass eventuell vorhandene Stolpersteine auf dem Weg des Teams zum Erfolg bzw. Sprint-Ende aus dem Weg geräumt werden.
Autor: Thomas Rümmler & Stefan Mieth

Artikel: Testing ist Teamarbeit (Seite 58)
Erfolg kommt nicht über Nacht, und eine gute Software ist nicht nur das Ergebnis von ein paar Zeilen Visual-Studio-Quellcode. Beim Erstellen einer Software sind die unterschiedlichsten Rollen und Tätigkeiten involviert. Dieses komplexe Gebilde permanent zu optimieren, ist die Aufgabe der übergreifenden Disziplin Application Lifecycle Management (ALM) …
von Nico Orschel und Marc Müller

IIS gar nicht so schwer (Seite 94)
Hosting von Websites, Anwendungen und Dienste wird heutzutage oft in die Cloud ausgelagert. Doch in manchen Fällen, z.B. bei rein internen Diensten im Firmennetzwerk, kommt man um das eigene “Hosting On-Premise” nicht herum. Dafür bietet Microsoft mit dem IIS (“Internet Information Services”) einen Webserver, mit dem das Bereitstellen und Debugging von Web Apps und Diensten sehr komfortabel ist. Ein paar Dinge sind jedoch bei der Installation und Anwendung zu beachten.
Autor: Jan Mattner

Geht noch ‘ne Spalte mehr? (Seite 88)
Der Konflikt zwischen der Standardisierung von Software-Produkten und der Erfüllung einzelner Kundenwünsche ist ein stetig wiederkehrendes Thema. Bei einer konventionellen Implementierung rufen Anpassungen am Datenmodel das Entwicklungsteam auf den Plan. Durch den Einsatz von entsprechenden Technologien und Modellierungsansätzen ist es jedoch auch möglich eine datengetriebene Anwendung ohne Entwicklungsaufwand kundenspezifisch anpassen zu können.
Autor: Benjamin Boost

In der Cloud zu sein beziehungsweise etwas mit der Cloud zu machen, ist hip und modern. Gleich nach Scrum, Agile und DevOps ist die “Wolke” derzeit eines der Schlagwörter in der IT-Welt. Je nach Blickwinkel durchaus mal im positiven wie auch negativen Licht. Erstaunlicherweise taucht der Begriff aber verhalten wenig im Zusammenhang mit Testen auf. In anderen Bereichen wie E-Mail, Webservices, Apps usw. ist es bereits üblich, externe Dienste einzukaufen und diese tief in die eigenen internen Infrastrukturen und Prozesse einzubetten.
An dieser Stelle setzt der Artikel an und zeigt Szenarien auf, in denen es sinnvoll ist, Teile von Testprozessen mit Cloud-Diensten zu ergänzen. Neben den Vorteilen soll auch die Betrachtung der Grenzen nicht zu kurz kommen. Die zentrale Frage ist hier stets: Wann ist die Integration sinnvoll und wann nicht? Inhaltlich werden zunächst die verschiedenen Typen von Cloud-Diensten vorgestellt. Zu den einzelnen Diensttypen werden anschließend ausgewählte Dienste aus der Microsoft Azure Cloud für den Testbereich herausgepickt. Als Szenarien werden exemplarisch Testmanagement, Bereitstellung von Testumgebungen und Lasttests in der Cloud betrachtet.
Autor: Nico Orschel

Vor kurzem fielen mir meine alten Unterlagen aus Studienzeiten in die Hände. Beim genaueren Hinsehen entdeckte ich kurz hinter einem Wasserfall- und dem Spiralmodell meine Notizen zu “Kapitel 3: Anforderungs- und Projektmanagement”. Mit einem amüsierten Lächeln blätterte ich diese Seiten durch und dachte: “Früher war alles einfacher”. Meine anhaltende Erheiterung galt dabei der Dokumentation einem meiner ersten Softwareprojekte. Die Semesterarbeit trug den Titel “Medienverwaltung mit integriertem Leihsystem” (MVLS). Damals hatten wir zu viert tagelang die Anforderungen akribisch aufgenommen, nach Wichtigkeit und technischer Machbarkeit sortiert und schließlich unserem Professor zur Korrektur vorgelegt, bevor wir mit dem für einen angehenden Softwareentwickler angenehmeren Teil anfangen durften. Lesen Sie im Artikel, mit welchen Hürden wir vier als Studenten unser Projekt abgeschlossen haben und was wir alle daraus heute noch lernen können.
Autor: Stefan Mieth

Kavalierstart (Seite 10)
Ein Team, sieben Mitglieder, eine Aufgabe: Übermorgen soll‘s losgehen. Bis dahin muss die Entwicklungsumgebung mit allem Pipapo stehen. Ach ja: Kosten darf das Ganze auch nur sehr wenig. Mit Azure kann‘s klappen!
Autor: Boris Wehrle und Benjamin Fischer

Besser coden unter Aufsicht
Entwickler coden ja gern einfach drauflos. Im Team aber müssen Programmierrichtlinien den kreativen Drang kanalisieren und für andere nachvollziehbar machen. Ihre Einhaltung ist immer wieder zu überprüfen – am besten automatisch.
Autor: Boris Wehrle und Benjamin Fischer

Softwareentwicklung ist Teamarbeit. Die sich immer mehr verbreitenden agilen Vorgehensmodelle sind das beste Beispiel dafür. Dabei wird beispielsweise ein Sprint bzw. eine Iteration gemeinsam geplant, sich täglich über den Fortschritt ausgetauscht und abschließend gemeinsam reflektiert. Am Ende des Sprints steht ein Softwareprodukt zur Verfügung, welches neue Features und Verbesserungen enthält und von den Kunden genutzt werden kann. Soweit die Theorie. Häufig ist die automatische Auslieferung neuer Softwareversionen mit dem Kopieren der Ergebnisse eines zentralen Server Builds auf ein Netzlaufwerk oder einen Webserver für Entwicklungsabteilungen beendet. Bis dahin ist diese Vorgehensweise als Continuous Integration in vielen Entwicklungsteams implementiert. Danach sind oft diverse manuelle Schritte notwendig, um anschließend die Qualitätssicherung durchführen zu können, welche die Codeänderungen mit manuellen und automatischen Tests auf unterschiedlichen Systemen und Umgebungen verifiziert. Continuous Delivery erweitert Continuous Integration um diese bisher zu wenig beachteten Aktivitäten. Neben diesen vorwiegend technischen Aspekten wird die notwendige Kommunikation zwischen Entwicklungsabteilungen und IT-Administration bzw. Konfigurationsmanagement allzu oft vernachlässigt oder findet überhaupt nicht statt. Hierfür hat sich in den letzten Jahren unter dem Codenamen DevOps die gegenseitige Annäherung von Entwicklung und Betrieb etabliert, wodurch Continuous Delivery tatsächlich erst realisierbar wird. Der Artikel arbeitet die wesentlichen Bestandteile von Continuous Delivery heraus, die damit einhergehende, notwendige Kooperation zwischen Entwicklung und Betrieb und gibt einen Überblick über die zur Realisierung notwendigen Schritte. Der Fokus liegt hierbei auf der konzeptionellen Ebene, technische Beispiele erfolgen unter Verwendung des Microsoft Team Foundation Servers.