"Unkonventionelle" Ideen zur dramatischen Steigerung der Produktivität von Softwareentwicklungsprojekten.
Wieviel Produktivität bringt mir hohe Qualität? Wie die Qualität steigern? Wie die Qualität sichern? Wie Fehler von vornherein vermeiden? Vorstellung einiger unkonventioneller Ansätze wie: Besseres Verständnis durch weniger Dokumentation, bessere Qualität durch weniger Tests, schnellere Entwicklung durch mehr broken Builds
Kosten technischer Qualität in der SoftwareentwicklungSebastian Dietrich
Einnahmen-Ausgabenrechnung für Clean Code
Was kostet die Definition & Sicherung hoher technischer Qualität? Was bringt hohe technische Qualität während der Entwicklung, beim Test, in der Wartung? Was kostet die Verbesserung schlechter technischer Qualität?
Konkrete Zahlen aus Literatur, Forschung und eigenen Projekten, Techniken zur Reduktion der Ausgaben und Erhöhung der Einnahmen, Sustainable Pace, Quality Gates, Limbo-Tanzen mit Softwarequalität, …
Scrum ist gelebtes Qualitätsmanagement und zum Qualitätsmanagement gehört das Testen. Wie genau spielt das Testen in Scrum mit? Welche Arten und Stufen von Tests gibt es und wie können diese den Scrum Prozess unterstützen oder sogar behindern? Was machen Teams hierbei gerne falsch und können klassische Testverfahren behilflich sein die Qualität zu verbessern? Diese Fragen werden in dem Vortrag diskutiert, beantwortet und bewertet.
Integration agiler und klassischer Vorgehensweisen (Embedded-Meets-Agile 18.2...Joachim Baumann
Agile Vorgehensweisen und Wasserfallmethoden werden als Gegensätze betrachtet. Software-Entwicklung im Bereich der Embedded-Systeme wird natürlicherweise mit klassischen Wasserfallmethoden betrieben, da die Einschränkungen z.B. durch die Infrastruktur dies völlig natürlich erscheinen lassen und Alternativen wie agile Methoden hier auf den ersten Blick nicht funktionieren können.
In diesem Vortrag beleuchten wir verschiedene Punkte, an denen diese Methoden kollidieren und diskutieren Möglichkeiten zur Integration.
Die Qualitätsanforderungen an Individualsoftware sind hoch. Sie soll funktional, zuverlässig, benutzerfreundlich und wartbar sein. Nicht zuletzt muss die Kosten-Nutzen-Relation stimmen.
Weitere Vorträge, die wir auch gern in Ihrem Unternehmen halten, finden Sie unter: https://www.iks-gmbh.com/impulsvortraege
Die Qualitätsanforderungen an Individualsoftware sind hoch. Sie soll funktional, zuverlässig, benutzerfreundlich und wartbar sein. Nicht zuletzt muss die Kosten-Nutzen-Relation stimmen.
Weitere Vorträge, die wir auch gern in Ihrem Unternehmen halten, finden Sie unter: https://www.iks-gmbh.com/impulsvortraege
Kosten technischer Qualität in der SoftwareentwicklungSebastian Dietrich
Einnahmen-Ausgabenrechnung für Clean Code
Was kostet die Definition & Sicherung hoher technischer Qualität? Was bringt hohe technische Qualität während der Entwicklung, beim Test, in der Wartung? Was kostet die Verbesserung schlechter technischer Qualität?
Konkrete Zahlen aus Literatur, Forschung und eigenen Projekten, Techniken zur Reduktion der Ausgaben und Erhöhung der Einnahmen, Sustainable Pace, Quality Gates, Limbo-Tanzen mit Softwarequalität, …
Scrum ist gelebtes Qualitätsmanagement und zum Qualitätsmanagement gehört das Testen. Wie genau spielt das Testen in Scrum mit? Welche Arten und Stufen von Tests gibt es und wie können diese den Scrum Prozess unterstützen oder sogar behindern? Was machen Teams hierbei gerne falsch und können klassische Testverfahren behilflich sein die Qualität zu verbessern? Diese Fragen werden in dem Vortrag diskutiert, beantwortet und bewertet.
Integration agiler und klassischer Vorgehensweisen (Embedded-Meets-Agile 18.2...Joachim Baumann
Agile Vorgehensweisen und Wasserfallmethoden werden als Gegensätze betrachtet. Software-Entwicklung im Bereich der Embedded-Systeme wird natürlicherweise mit klassischen Wasserfallmethoden betrieben, da die Einschränkungen z.B. durch die Infrastruktur dies völlig natürlich erscheinen lassen und Alternativen wie agile Methoden hier auf den ersten Blick nicht funktionieren können.
In diesem Vortrag beleuchten wir verschiedene Punkte, an denen diese Methoden kollidieren und diskutieren Möglichkeiten zur Integration.
Die Qualitätsanforderungen an Individualsoftware sind hoch. Sie soll funktional, zuverlässig, benutzerfreundlich und wartbar sein. Nicht zuletzt muss die Kosten-Nutzen-Relation stimmen.
Weitere Vorträge, die wir auch gern in Ihrem Unternehmen halten, finden Sie unter: https://www.iks-gmbh.com/impulsvortraege
Die Qualitätsanforderungen an Individualsoftware sind hoch. Sie soll funktional, zuverlässig, benutzerfreundlich und wartbar sein. Nicht zuletzt muss die Kosten-Nutzen-Relation stimmen.
Weitere Vorträge, die wir auch gern in Ihrem Unternehmen halten, finden Sie unter: https://www.iks-gmbh.com/impulsvortraege
Creasoft Akademie - Diszipliniertes Anforderungsmanagement in agilen ProjektenCreasoft AG
Software-Projekte sind mit vielen Risiken behaftet. Die Ursachen für Fehlschläge sind oft Fehler im Management der Anforderungen und mangelhafter Einbezug der Benutzer.
Agile Vorgehensmodelle wollen genau dieses Problem lösen. Allerdings wird die Thematik in den ursprünglichen Konzepten zu stark vereinfacht und dadurch oft missverstanden.
Was macht Projekte erfolgreich? Warum scheitern Projekte und liefern nicht das, was ihre Auftraggeber erwarten? Nach wie vor ist unzureichendes Requirements Engineering der Hauptgrund für abgebrochene Projekte oder solche, die ihre Ziele nicht erreichen. Technologische Herausforderungen sind per se keine wichtigen Projektrisiken, ihr Management dagegen schon. Doch es gibt auch genügend Projekte, die ihre Ziele erreichen. Grund genug, sich mit den Praktiken des Requirements Engineering auseinanderzusetzen und wesentliche Praxistipps zu geben. Dieser Übersichtsbeitrag basiert teilweise auf dem Buch „Systematisches Requirements Engineering“, das im Dpunkt-Verlag erschienen ist [1]. Unsere Erfahrungen in verschiedenen Industrieprojekten aus einer Vielzahl von Systemen und Anwendungen zeigen, dass ein gutes Verständnis sowie eine systematische Behandlung von Anforderungen erfolgskritisch sind. Wir zeigen mit praktischen Beispielen und einem Praxisbeispiel aus ei-ner sicherheitsrelevanten Anwendung z. B. aus der Medizintechnik, wie Requirements Engineering konkret und erfolgreich umgesetzt wird. Damit können die Kosten für Nacharbeiten um ca. 30% gesenkt werden.
Die Qualitätsanforderungen an Individualsoftware sind hoch. Sie soll funktional, zuverlässig, benutzerfreundlich und wartbar sein. Nicht zuletzt muss die Kosten-Nutzen-Relation stimmen.
Weitere Vorträge, die wir auch gern in Ihrem Unternehmen halten, finden Sie unter: https://www.iks-gmbh.com/impulsvortraege
http://www.opitz-consulting.com/go/3-4-894
Die Literatur sagt, dass „Broken Builds“ auf jeden Fall zu vermeiden sind, weil andere Entwickler sich durch die fehlerhaften Änderungen ihren Entwicklungsbereich kaputt machen und dann nicht arbeiten können.
Die Solution Architects unserer IT-Beratung, Stefan Scheidt und Richard Attermeyer, zeigten in ihrem Vortrag am 10.Oktober 2013 bei der gearconf 2013 in Düsseldorf, dass „broken Builds“ nicht das Problem sind. Im Rahmen der Präsentation zeigten die Referenten, wie man durch geeignete Branching- und CI-Strategien stets eine stabilen Branch sicherstellen kann.
Veranschaulicht wurde das Ganze durch eine konkrete Umsetzung mittels Git / GitLab und Jenkins.
--
Über uns:
Als führender Projektspezialist für ganzheitliche IT-Lösungen tragen wir zur Wertsteigerung der Organisationen unserer Kunden bei und bringen IT und Business in Einklang. Mit OPITZ CONSULTING als zuverlässigem Partner können sich unsere Kunden auf ihr Kerngeschäft konzentrieren und ihre Wettbewerbsvorteile nachhaltig absichern und ausbauen.
Über unsere IT-Beratung: http://www.opitz-consulting.com/go/3-8-10
Unser Leistungsangebot: http://www.opitz-consulting.com/go/3-8-874
Karriere bei OPITZ CONSULTING: http://www.opitz-consulting.com/go/3-8-5
Testen in agilen Projekten, Swiss Testing Day Zürich 2013
Agile Projekte verursachen massive Probleme im klassischen Testvorgehen: Detailspezifikationen sind erst (wenn überhaupt) kurz vor der Implementierung verfügbar und der Test soll gleichzeitig mit der Entwicklung am Ende jeder Iteration abgeschlossen sein. Bei Iterationslängen von wenigen Wochen verursacht das beträchtlichen Mehraufwand für den Test, der sich noch dazu am Ende der Iteration konzentriert, wodurch das Ziel eines voll getesteten Systems am Ende jeder Iteration oft nicht erreicht werden kann.
Der Vortrag stellt drei wichtige Erfolgsrezepte für Testen in agilen Projekten vor (1. Multifunktionale Teams, 2. Testautomatisierung und 3. Spezifikation mit Beispielen) und zeigt, welche Änderungen notwendig sind, damit Test und Entwicklung effizient in agilen Projekten zusammenarbeiten. Neben der Vorstellung von wichtigen Konzepten für agiles Testen (agile Testquadranten, Testautomatisierungspyramide und Specification-By-Example) zeigt der Vortrag auch, wie diese Methoden mit Werkzeugen unterstützt werden können, und berichtet von deren praktischer Anwendung in unterschiedlichen Projekten.
Video: http://www.youtube.com/watch?v=LL2kOToKUF0
"Agiles Testen" wird gerade intensiv diskutiert.
Was steckt dahinter? Was für Konsequenzen ergeben sich daraus für unsere Scrum-Teams? Oder verbirgt sich gar eine neue Testmethode hinter diesem Begriff?
In diesem Vortrag erläutern wir den Weg vom Scrum-Team hin zu einem Agilen Team, wie Crispin und Gregroy es nennen. Sie geben damit die Antwort auf die Frage, wie die Rolle der QS in einem Scrum-Team wahrgenommen werden kann. Wir zeigen, welche Konsequenzen sich daraus für die Teammitglieder und ihre Aufgaben ergeben und wie Sie Ihr Agiles Team zum Fliegen bekommen!
Die Qualitätsanforderungen an Individualsoftware sind hoch. Sie soll funktional, zuverlässig, benutzerfreundlich und wartbar sein. Nicht zuletzt muss die Kosten-Nutzen-Relation stimmen.
Weitere Vorträge, die wir auch gern in Ihrem Unternehmen halten, finden Sie unter: https://www.iks-gmbh.com/impulsvortraege
IT-Sicherheit und agile Entwicklung? Geht das? Sicher!Carsten Cordes
Unit-Tests, Integrationstests und Co. machen es möglich, zu überprüfen, ob entwickelte Software den funktionalen Anforderungen entspricht. Durch die zunehmende Vernetzung von Softwaresystemen und die Auslagerung von Anwendungen in die Cloud und das Internet werden aber auch Security-Anforderungen immer relevanter. Traditionelle Qualitätssicherungsmethoden laufen hier oft ins Leere. Wenn überhaupt, wird meist nur am Ende stichprobenartig getestet, ob eine Software sicher ist. Fallen Sicherheitsmängel erst so spät auf, sind sie in der Regel aber nur schwierig zu beheben, und schlimmstenfalls müssen sogar ganze Anwendungsteile neu entwickelt werden. Deshalb ist es sinnvoll, IT-Sicherheit möglichst früh im Entwicklungsprozess zu berücksichtigen, um teure Schwachstellen zu vermeiden. Aber wie können Sicherheitsrisiken frühzeitig ermittelt und bei der agilen Entwicklung berücksichtigt werden? Eine Lösung ist ein Security-Aware-Development, bei dem IT-Sicherheitsanforderungen fest in den agilen Entwicklungsprozess integriert werden.
www.opitz-consulting.com
Zu einem guten Gericht gehören gute Zutaten. So ist es auch mit einer Continuous-Delivery-Umgebung.
Was macht eine gute Developer Experience aus? Aus welchen Zutaten bestehen moderne Continuous-Delivery-Umgebungen? Wir schauen uns an, welche Zutaten man braucht und durch welche Produkte sich diese abdecken lassen.
An welchen Qualitätsattributen müssen sich CD-Plattformarchitekturen messen lassen?
So wie man aus den gleichen Zutaten Gerichte für die unterschiedlichen Geschmäcker bauen kann, so kann man auch unterschiedliche Entwicklerkulturen bedienen.
Lernen Sie, wie Sie das Rezept für ihren Lieblingsstack finden können.
Continuous Integration wird längst in vielen Projekten praktiziert. Kein Wunder, steht für das Tooling doch in vielen Fällen ein Jenkins oder Travis zur Verfügung. Mit GitLab CI ist dies jedoch nicht mehr nötig. Schritt für Schritt wird in dieser Session eine Pipeline mit verschiedenen Test- und Analysetools aufgesetzt -- zur Integration in neue und bestehende Projekte.
system worx: Wie Open Source Software zur Optimierung von Geschäftsprozessen ...AKJoom
Der Senior-Entwickler, Systemarchitekt und IT-Berater Anton Kejr gibt in seinem Vortrag eine praxisnahe Einführung in sein Spezialgebiet: die Prinzipien, Entwicklung und Anwendung von Open Source Webtechnologie in Unternehmen.
Angesprochen sind in erster Linie Geschäftsführer, Unternehmer, CIOs und IT-Verantwortliche in Unternehmen sowie alle Führungskräfte an IT-Schnittstellen, die IT-gestützte Prozesse und Abläufe in ihrer Organisation optimieren möchten. Sie erhalten einen fundierten Einblick in die relevanten Open Source Software-Lösungen. Darüber hinaus erläutern wir Ihnen, wie mit Open Source Software Geschäftsprozesse preiswert optimiert werden können.
„Bekommen Sie Ihre SQL Datenbank unter Kontrolle”
Ein Großteil des existierenden .NET Codes steht unter Quellcodeverwaltung und bereits heute verwenden viele Anwendungsentwickler irgendeine Form von Continuous Integration. Die Datenbankentwickler hängen an dieser Stelle leider ein wenig hinterher. Dabei sind gerade die Daten das Herzstück einer Anwendung und Änderungen an Datenbankstrukturen daher besonders komplex. Der erste Schritt um eine Verbesserung herbeizuführen ist es, die Datenbank ebenfalls unter Quellcodeverwaltung zu stellen. Das erleichtert nicht nur die Zusammenarbeit mit anderen Teammitgliedern und ermöglicht ein einfacheres Deployment, sondern es bildet auch die Grundlage für Continuous Integration, sowie automatisiertes Testing.
Dieser User-Group Abend zeigt:
* wie man seine SQL Datenbank genauso einfach in die Quellcodeverwaltung bringt wie .NET Code
* wie man seine Datenbank direkt aus der Quellcodeverwaltung heraus deployen kann und
* wie man einen ersten Schritt in Richtung Continous Integration machen kann
Die Präsentation beschreibt ein pragmatisches Vorgehen für Usability-Tests. Es werden praktische Hinweise gegeben, wie einfache Usability-Tests inhaus durchgeführt werden können
Jedes IT-System stirbt irgendwann und muss durch ein neues System abgelöst werden. Solche Systemablösen bergen zahlreise Herausforderungen: Keine Doku, eine Technologie, die niemand mehr gut kennt, wissende Mitarbeiter sind nicht mehr greifbar, hoher Zeitdruck, großes Risiko im Betrieb etc. - oft eher Organtransplantation, als IT-Projekt.
Im Vortrag möchte ich meine Erfahrungen aus großen Systemablöseprojekten teilen. Wir werden uns ansehen, wie man Methoden aus Requirements Engineering und Reverse Engineering so kombiniert, dass alle notwendigen Anforderungen entdeckt werden. Wir werden sehen, dass die Zusammenarbeit zwischen Fachbereich und IT der kritische Erfolgsfaktor ist, wie man das am Besten organisiert und wie man Use Cases und ein Glossar dabei unterstützend einsetzt.
Creasoft Akademie - Diszipliniertes Anforderungsmanagement in agilen ProjektenCreasoft AG
Software-Projekte sind mit vielen Risiken behaftet. Die Ursachen für Fehlschläge sind oft Fehler im Management der Anforderungen und mangelhafter Einbezug der Benutzer.
Agile Vorgehensmodelle wollen genau dieses Problem lösen. Allerdings wird die Thematik in den ursprünglichen Konzepten zu stark vereinfacht und dadurch oft missverstanden.
Was macht Projekte erfolgreich? Warum scheitern Projekte und liefern nicht das, was ihre Auftraggeber erwarten? Nach wie vor ist unzureichendes Requirements Engineering der Hauptgrund für abgebrochene Projekte oder solche, die ihre Ziele nicht erreichen. Technologische Herausforderungen sind per se keine wichtigen Projektrisiken, ihr Management dagegen schon. Doch es gibt auch genügend Projekte, die ihre Ziele erreichen. Grund genug, sich mit den Praktiken des Requirements Engineering auseinanderzusetzen und wesentliche Praxistipps zu geben. Dieser Übersichtsbeitrag basiert teilweise auf dem Buch „Systematisches Requirements Engineering“, das im Dpunkt-Verlag erschienen ist [1]. Unsere Erfahrungen in verschiedenen Industrieprojekten aus einer Vielzahl von Systemen und Anwendungen zeigen, dass ein gutes Verständnis sowie eine systematische Behandlung von Anforderungen erfolgskritisch sind. Wir zeigen mit praktischen Beispielen und einem Praxisbeispiel aus ei-ner sicherheitsrelevanten Anwendung z. B. aus der Medizintechnik, wie Requirements Engineering konkret und erfolgreich umgesetzt wird. Damit können die Kosten für Nacharbeiten um ca. 30% gesenkt werden.
Die Qualitätsanforderungen an Individualsoftware sind hoch. Sie soll funktional, zuverlässig, benutzerfreundlich und wartbar sein. Nicht zuletzt muss die Kosten-Nutzen-Relation stimmen.
Weitere Vorträge, die wir auch gern in Ihrem Unternehmen halten, finden Sie unter: https://www.iks-gmbh.com/impulsvortraege
http://www.opitz-consulting.com/go/3-4-894
Die Literatur sagt, dass „Broken Builds“ auf jeden Fall zu vermeiden sind, weil andere Entwickler sich durch die fehlerhaften Änderungen ihren Entwicklungsbereich kaputt machen und dann nicht arbeiten können.
Die Solution Architects unserer IT-Beratung, Stefan Scheidt und Richard Attermeyer, zeigten in ihrem Vortrag am 10.Oktober 2013 bei der gearconf 2013 in Düsseldorf, dass „broken Builds“ nicht das Problem sind. Im Rahmen der Präsentation zeigten die Referenten, wie man durch geeignete Branching- und CI-Strategien stets eine stabilen Branch sicherstellen kann.
Veranschaulicht wurde das Ganze durch eine konkrete Umsetzung mittels Git / GitLab und Jenkins.
--
Über uns:
Als führender Projektspezialist für ganzheitliche IT-Lösungen tragen wir zur Wertsteigerung der Organisationen unserer Kunden bei und bringen IT und Business in Einklang. Mit OPITZ CONSULTING als zuverlässigem Partner können sich unsere Kunden auf ihr Kerngeschäft konzentrieren und ihre Wettbewerbsvorteile nachhaltig absichern und ausbauen.
Über unsere IT-Beratung: http://www.opitz-consulting.com/go/3-8-10
Unser Leistungsangebot: http://www.opitz-consulting.com/go/3-8-874
Karriere bei OPITZ CONSULTING: http://www.opitz-consulting.com/go/3-8-5
Testen in agilen Projekten, Swiss Testing Day Zürich 2013
Agile Projekte verursachen massive Probleme im klassischen Testvorgehen: Detailspezifikationen sind erst (wenn überhaupt) kurz vor der Implementierung verfügbar und der Test soll gleichzeitig mit der Entwicklung am Ende jeder Iteration abgeschlossen sein. Bei Iterationslängen von wenigen Wochen verursacht das beträchtlichen Mehraufwand für den Test, der sich noch dazu am Ende der Iteration konzentriert, wodurch das Ziel eines voll getesteten Systems am Ende jeder Iteration oft nicht erreicht werden kann.
Der Vortrag stellt drei wichtige Erfolgsrezepte für Testen in agilen Projekten vor (1. Multifunktionale Teams, 2. Testautomatisierung und 3. Spezifikation mit Beispielen) und zeigt, welche Änderungen notwendig sind, damit Test und Entwicklung effizient in agilen Projekten zusammenarbeiten. Neben der Vorstellung von wichtigen Konzepten für agiles Testen (agile Testquadranten, Testautomatisierungspyramide und Specification-By-Example) zeigt der Vortrag auch, wie diese Methoden mit Werkzeugen unterstützt werden können, und berichtet von deren praktischer Anwendung in unterschiedlichen Projekten.
Video: http://www.youtube.com/watch?v=LL2kOToKUF0
"Agiles Testen" wird gerade intensiv diskutiert.
Was steckt dahinter? Was für Konsequenzen ergeben sich daraus für unsere Scrum-Teams? Oder verbirgt sich gar eine neue Testmethode hinter diesem Begriff?
In diesem Vortrag erläutern wir den Weg vom Scrum-Team hin zu einem Agilen Team, wie Crispin und Gregroy es nennen. Sie geben damit die Antwort auf die Frage, wie die Rolle der QS in einem Scrum-Team wahrgenommen werden kann. Wir zeigen, welche Konsequenzen sich daraus für die Teammitglieder und ihre Aufgaben ergeben und wie Sie Ihr Agiles Team zum Fliegen bekommen!
Die Qualitätsanforderungen an Individualsoftware sind hoch. Sie soll funktional, zuverlässig, benutzerfreundlich und wartbar sein. Nicht zuletzt muss die Kosten-Nutzen-Relation stimmen.
Weitere Vorträge, die wir auch gern in Ihrem Unternehmen halten, finden Sie unter: https://www.iks-gmbh.com/impulsvortraege
IT-Sicherheit und agile Entwicklung? Geht das? Sicher!Carsten Cordes
Unit-Tests, Integrationstests und Co. machen es möglich, zu überprüfen, ob entwickelte Software den funktionalen Anforderungen entspricht. Durch die zunehmende Vernetzung von Softwaresystemen und die Auslagerung von Anwendungen in die Cloud und das Internet werden aber auch Security-Anforderungen immer relevanter. Traditionelle Qualitätssicherungsmethoden laufen hier oft ins Leere. Wenn überhaupt, wird meist nur am Ende stichprobenartig getestet, ob eine Software sicher ist. Fallen Sicherheitsmängel erst so spät auf, sind sie in der Regel aber nur schwierig zu beheben, und schlimmstenfalls müssen sogar ganze Anwendungsteile neu entwickelt werden. Deshalb ist es sinnvoll, IT-Sicherheit möglichst früh im Entwicklungsprozess zu berücksichtigen, um teure Schwachstellen zu vermeiden. Aber wie können Sicherheitsrisiken frühzeitig ermittelt und bei der agilen Entwicklung berücksichtigt werden? Eine Lösung ist ein Security-Aware-Development, bei dem IT-Sicherheitsanforderungen fest in den agilen Entwicklungsprozess integriert werden.
www.opitz-consulting.com
Zu einem guten Gericht gehören gute Zutaten. So ist es auch mit einer Continuous-Delivery-Umgebung.
Was macht eine gute Developer Experience aus? Aus welchen Zutaten bestehen moderne Continuous-Delivery-Umgebungen? Wir schauen uns an, welche Zutaten man braucht und durch welche Produkte sich diese abdecken lassen.
An welchen Qualitätsattributen müssen sich CD-Plattformarchitekturen messen lassen?
So wie man aus den gleichen Zutaten Gerichte für die unterschiedlichen Geschmäcker bauen kann, so kann man auch unterschiedliche Entwicklerkulturen bedienen.
Lernen Sie, wie Sie das Rezept für ihren Lieblingsstack finden können.
Continuous Integration wird längst in vielen Projekten praktiziert. Kein Wunder, steht für das Tooling doch in vielen Fällen ein Jenkins oder Travis zur Verfügung. Mit GitLab CI ist dies jedoch nicht mehr nötig. Schritt für Schritt wird in dieser Session eine Pipeline mit verschiedenen Test- und Analysetools aufgesetzt -- zur Integration in neue und bestehende Projekte.
system worx: Wie Open Source Software zur Optimierung von Geschäftsprozessen ...AKJoom
Der Senior-Entwickler, Systemarchitekt und IT-Berater Anton Kejr gibt in seinem Vortrag eine praxisnahe Einführung in sein Spezialgebiet: die Prinzipien, Entwicklung und Anwendung von Open Source Webtechnologie in Unternehmen.
Angesprochen sind in erster Linie Geschäftsführer, Unternehmer, CIOs und IT-Verantwortliche in Unternehmen sowie alle Führungskräfte an IT-Schnittstellen, die IT-gestützte Prozesse und Abläufe in ihrer Organisation optimieren möchten. Sie erhalten einen fundierten Einblick in die relevanten Open Source Software-Lösungen. Darüber hinaus erläutern wir Ihnen, wie mit Open Source Software Geschäftsprozesse preiswert optimiert werden können.
„Bekommen Sie Ihre SQL Datenbank unter Kontrolle”
Ein Großteil des existierenden .NET Codes steht unter Quellcodeverwaltung und bereits heute verwenden viele Anwendungsentwickler irgendeine Form von Continuous Integration. Die Datenbankentwickler hängen an dieser Stelle leider ein wenig hinterher. Dabei sind gerade die Daten das Herzstück einer Anwendung und Änderungen an Datenbankstrukturen daher besonders komplex. Der erste Schritt um eine Verbesserung herbeizuführen ist es, die Datenbank ebenfalls unter Quellcodeverwaltung zu stellen. Das erleichtert nicht nur die Zusammenarbeit mit anderen Teammitgliedern und ermöglicht ein einfacheres Deployment, sondern es bildet auch die Grundlage für Continuous Integration, sowie automatisiertes Testing.
Dieser User-Group Abend zeigt:
* wie man seine SQL Datenbank genauso einfach in die Quellcodeverwaltung bringt wie .NET Code
* wie man seine Datenbank direkt aus der Quellcodeverwaltung heraus deployen kann und
* wie man einen ersten Schritt in Richtung Continous Integration machen kann
Die Präsentation beschreibt ein pragmatisches Vorgehen für Usability-Tests. Es werden praktische Hinweise gegeben, wie einfache Usability-Tests inhaus durchgeführt werden können
Jedes IT-System stirbt irgendwann und muss durch ein neues System abgelöst werden. Solche Systemablösen bergen zahlreise Herausforderungen: Keine Doku, eine Technologie, die niemand mehr gut kennt, wissende Mitarbeiter sind nicht mehr greifbar, hoher Zeitdruck, großes Risiko im Betrieb etc. - oft eher Organtransplantation, als IT-Projekt.
Im Vortrag möchte ich meine Erfahrungen aus großen Systemablöseprojekten teilen. Wir werden uns ansehen, wie man Methoden aus Requirements Engineering und Reverse Engineering so kombiniert, dass alle notwendigen Anforderungen entdeckt werden. Wir werden sehen, dass die Zusammenarbeit zwischen Fachbereich und IT der kritische Erfolgsfaktor ist, wie man das am Besten organisiert und wie man Use Cases und ein Glossar dabei unterstützend einsetzt.
Bottom-up anstatt Top-down: Wie man eine einheitliche Architektur bei vielfäl...Stephan Volmer
Ein bekanntes Szenario in IT-Abteilungen größerer Unternehmen ist die Entwicklung vieler fachlich unterschiedlicher Applikationen auf einer gemeinsamen technischen Basis. Im Lebenszyklus dieser Applikationen sind oft unterschiedliche Teams für Entwicklung und Wartung zuständig. Um dennoch eine effiziente Arbeit gewährleisten zu können, werden die Applikationen gerne auf ein Framework aufgesetzt, das vor Beginn der eigentlichen Applikationsentwicklung in einem eigenen Projekt erstellt wird. Solche Projekte sind teuer und zeitaufwändig. Sie erzeugen keinen direkten Mehrwert für das Geschäft des Unternehmens. Außerdem besteht die Gefahr, dass sie den tatsächlichen Anforderungen bei der Entwicklung der eigentlichen Applikationen nicht gerecht werden.
Ein anderer Ansatz ist es, aus der Entwicklung einer oder mehrerer Geschäftsapplikationen inkrementell-iterativ wiederverwendbare Artefakte in Form eines Architektur-Baukastens zu erzeugen. Der Vortrag zeigt, wie sich mit dieser Vorgehensweise die Ramp-Up-Zeit für neue Projekte von fünf Monaten auf fünf Minuten verkürzen lässt. Sie wissen nach dem Vortrag wie das geht!
The Best Business Software in Town - Wie agiles Requirements Engineering die ...Christopher Schulz
Andreas Schlier hat ein Problem. Sein altes Excel-VBA-System tut es nicht mehr. Das einst so verlässliche Tool für die Auswertung von Fahrzeugproduktionsvorgängen ist in die Jahre gekommen. Das Datenvolumen steigt kontinuierlich. Die Fachbereiche möchten immer neue Funktionen. Und zu allem Überfluss verabschiedet sich der Software-Verantwortliche als einziger Wissensträger in die Altersteilzeit. Was soll Andreas Schlier tun?
Im Konferenzbeitrag unterstützt Christopher Schulz. Live, interaktiv und praxisnah. Er nimmt Andreas Schlier und die Teilnehmer mit auf einen Weg, von der initialen Software Vision bis zum konkreten Proof of Concept. Software Auswahl ist ein Entscheidungsprozess. Agiles Requirements Engineering beschleunigt das Vorgehen und sichert die langfristige Investition in ein Tool nachhaltig ab.
3. Technische Qualität vs. Produktivität
Frage:
Wieviel Zeit kostet hohe
technische Qualität in der
Softwareentwicklung?
Wieviel Zeit bringt hohe
technische Qualität in der
Wartungsphase?
Antwort: Die Frage ist falsch:
Wartung beginnt mit der Analyse
Technische Qualität spart (auch
während der Entwicklung) Zeit ein.
Richtige Frage:
Wieviel Zeit/Geld/Kunden kostet uns schlechte technische Qualität?
► www.e-movimento.com, Sebastian Dietrich3
[DeMarco 82]
7%
67%
13%
5%
8%
Analyse
Design
Codierung
Testen
Wartung
4. 7%
67%
13%
5%
8%
Analyse
Design
Codierung
Testen
Wartung
7%
13%
5%
6%
53%
16%
Analyse
Design
Codierung
Testen
Wartung
Ersparnis
Kosten schlechter technischer Qualität
= „Technische Schuld“
Technische Schuld =
„Zusätzlicher Aufwand, den man für
Änderungen und Erweiterungen an
schlecht geschriebener Software im
Vergleich zu gut geschriebener Software
einplanen muss.“
Kosten Technischer Schuld:
+ 5-10% Entwicklungsaufwand
+ 20-40% Test &
Fehlerbehebungsaufwand
+ 20% Wartungsaufwand
+ verlorene Umsätze & Kunden
[McConnel 2003], [Wiegers 2002], [Jones 2000],
[Gilb and Graham 1993], [Humphrey 1998],
[Fagan 1976]
► www.e-movimento.com, Sebastian Dietrich4
[DeMarco 82]
6. Unkonventionelle Ansätze
In der Architektur
► www.e-movimento.com, Sebastian Dietrich6
Stein
Betonfundament
Eisen Stahl
Stahlbeton
Industrielle Fertigung (1-6 Jahre)
7. Unkonventioneller Ansatz #1:
„Arbeite professionell“
Frage: Wer ist Anfänger - Junior, wer ist Senior - Experte?
► www.e-movimento.com, Sebastian Dietrich7
9. „Arbeite professionell“
Forderungen an professionelle Entwickler
Software Professionalism:
We will not ship shit
We will always be ready
Stable productivity
Inexpensive adaptability
Continuous improvement
Fearless competence
Extreme quality
QA will find nothing
We cover for each other
Honest estimates
Say „No“
Automation
Continuous Aggressive Learning
Mentoring
► www.e-movimento.com, Sebastian Dietrich9
Robert C. Martin:
„Demanding Professionalism
in Software Development“
http://www.youtube.com/watch?v=p0O1VVqRSK0
10. „Arbeite professionell“
Konsequenzen für professionelle Entwickler
1. Frage nicht, tue es!
Jesuitenprinzip nach Dave Burns:
„Um Verzeihung bitten ist einfacher,
als um Erlaubnis zu fragen“
Ein Professionist fragt nicht, ob er
professionell arbeiten darf!
2. Ignoriere diesbezüglich Projektleiter!
Projektleiter sind Projektleiter & keine
Nachhilfelehrer
Einmischung in Arbeitsweise =
Micromanagement = Antithese zu
Projektleitung
3. Ignoriere diesbezüglich Kunden!
Kunden sind nicht für das „wie“ verantwortlich
► www.e-movimento.com, Sebastian Dietrich10
CCD Armbänder
Konsequenz genug?
12. Dokumentation
Nachteile von Dokumentation
Dokumentation ist sauteuer:
Kommerzielle Softwareprojekte:
28 - 66 Seiten / KLOC [Jones 99], [Boehm 88]
Typisches großes Softwareprojekt:
100 Personenjahre Entwicklung ~1.000 KLOC
~ 28.000 – 66.000 Seiten Dokumentation
~ 10 - 40 Personenjahre Dokumentation
Üblicherweise gilt:
Dokumentationskosten > Codierungskosten
Nachteile von Dokumentation:
Dokumentation ist immer veraltet
Dokumentation ist kaum auffindbar
Dokumentation wird meist nicht gelesen
► www.e-movimento.com, Sebastian Dietrich12
13. Unkonventioneller Ansatz #2:
„Dokumentiere nichts – kommuniziere lieber“
► www.e-movimento.com, Sebastian Dietrich13
Warum dokumentieren wir?
Reflexion, Kommunikation, Absicherung
Dafür gibt es geeignetere Techniken:
Brainstormings, Analyse-Sessions, CRC-Cards, Prototypen, …
echte face2face Kommunikation, Mentoring, Pair-Programming, …
Vertrauen, Collective Ownership, Tests,
Beispiel Code-Dokumentation:
//fill Person from Database via Reflection
Object personFromDB = loadFromDB(id);
BeanUtils.copyProperties(person, personFromDB);
...
Warum nicht (Programming by Intention)?:
fillPersonFromDatabase(person, id);
...
14. „Dokumentiere nichts – kommuniziere lieber“
Beispiel JavaDoc
Beispiel (Klasse Mitarbeiter):
...
/**
* Sets the name of this person.
* @param name the name of this person
* @exception IllegalArgumentException
* when name is shorter than 3 characters
*/
public void setFirstName(String name) {
if (name.length <= 3)
throw new IllegalArgumentException();
...
Alternative (via BeanValidation 1.1):
public void setFirstName(@NotNull @Size(min=4) firstName) {
...
► www.e-movimento.com, Sebastian Dietrich14
15. „Dokumentiere nichts – kommuniziere lieber“
Konsequenzen für Entwickler
Erkenntnis:
Dokumentation ist sauteuer und bringt wenig
Es gibt bessere & günstiger Möglichkeiten fürs
Reflektieren, Kommunizieren, Absichern
Konsequenzen:
Guter Code benötigt keine Kommentare
Code Kommentare sind immer ein Smell &
Zeichen für zu hohe Komplexität [Fowler 99]
Schreibe Code der kommuniziert
Lesbarer Code, geringe Komplexität, kurze
Methoden, Programming by Intention
Gutes Design benötigt kein Javadoc
Signatur der Methoden ist Teil des Designs,
Javadoc ist nicht Teil der Signatur
► www.e-movimento.com, Sebastian Dietrich15
16. Testen
Warum testen wir?
Warum testen wir?
Warum schreiben wir Unit-Test?
Warum schreiben wir
Integrationstests?
Warum schreiben wir Testfälle?
Warum führen wir Testfälle durch?
Um Kosten zu reduzieren
Entwicklungskosten, Wartungskosten
Fehlerbehebungskosten
Imagekosten
…
Wieviel darf uns daher der Test
kosten?
► www.e-movimento.com, Sebastian Dietrich16
Performancetests
Securitytests
Penetrationtests
Integrationstests
Systemtests
Loadtests
Abnahmetests
Usablity Test
Unit-Tests
Lasttests
Regressiontests
Fehlertests
Schnittstellentests
Installationstests
Crashtests
Smoketests
Stresstests
17. Systemtest
Kosten – Nutzen Rechnung
Kosten Nutzen
Systemtestaufwand:
~ 1 PT / Testfall
Systemtest findet
~ 1 Fehler / Testfall
Fehlerbehebungsaufwand:
~ 1PT / Fehler
(10x wie während Entwicklung)
Je behobener Fehler:
0,5 – 0,8 neue (unentdeckte)
Fehler
80 – 150%
der Entwicklungskosten
Systemtest findet
max. 25 – 55% der Fehler
Systemtest:
Teststufe, bei der das gesamte System
gegen die gesamten Anforderungen getestet wird.
► www.e-movimento.com, Sebastian Dietrich17
[Jones 86], [Jones 96a], [Jones 96b], [Shull 02], [McConnell 04]
18. Unittest
Kosten – Nutzen Rechnung
Kosten Nutzen
Unit-Testaufwand:
~ 2-3x Entwicklungsaufwand
„Code Coverage“ ?
„Refactoring“ ?
Fehlerbehebungsaufwand:
~ 1h / Fehler
(1/10 wie während Test)
Je behobener Fehler:
0,5 – 0,8 neue (unentdeckte)
Fehler
~ 50% der Entwicklungskosten Unit-Test findet
max. 15 – 70% der Fehler
Unit-Tests:
Teststufe, bei der funktionale Einzelteile (Module)
auf korrekte Funktionalität geprüft werden.
► www.e-movimento.com, Sebastian Dietrich18
[Jones 01], [Humphrey 89], [Software Metrics 01]
19. Unittests
Warum gute Unittests so teuer sind
Gute Unittests (gilt auch für TDD):
Haben Assertions (die den Vertrag der Methoden testen):
Vorbedingungen (typische / untypische / extreme / unerlaubte)
Nachbedingungen (Rückgabewerte & Exceptions, State-Änderungen)
Invarianten (was sich nicht ändern darf)
Haben 100% Assertion-Coverage (Code-Coverage ist unwichtig)
Testen Units (& mocken Referenzen auf andere Units weg)
Berücksichtigen State (Quasimodale & Modale Klassen) und
Reihenfolge der Methodenaufrufe (Unimodale & Modale Klassen)
Hinterlassen das System, wie sie es vorgefunden haben
Laufen daher in beliebiger Reihenfolge
Sind Refactoring-Safe
Testen auch das Design (z.B. Liskovsches Substitutionsprinzip)
Laufen auf dem CI Server & geben rasches Feedback (< 1 min.)
► www.e-movimento.com, Sebastian Dietrich19
20. Unkonventioneller Ansatz #3:
„Teste nichts – verhindere Fehler“
Wie technische Fehler verhindern?
Test Driven Development:
Designe mittels Tests
Keine weiteren Unit-Tests &
Integrationstests mehr nötig
Reduziere State & Abhängigkeiten auf
das absolut notwendigste
Wie fachliche Fehler verhindern?
Behavior Driven Development:
Analyse mittels Tests
Keine Systemtests und
Abnahmetests mehr nötig
Entwicklung (& TDD) wesentlich
einfacher & weniger Aufwand
► www.e-movimento.com, Sebastian Dietrich20
Moskitonetz –
Verhindert Bugs
21. „Teste nichts – verhindere Fehler“
Konsequenzen für Entwickler
Erkenntnis:
Testen ist sauteuer und bringt wenig
Es gibt bessere & günstiger Möglichkeiten um
Fehler zu verhindern
Konsequenzen:
Bestehe auf BDD Analysen (in Gherkin)
Schreibe Steps die gegen die BL testen
Definiere die Schnittstellen mittels TDD
Designe ein GUI ohne jedweder Logik
„QA will find nothing“
Konsequenzen für Tester:
Lerne Gherkin und werde Analytiker
► www.e-movimento.com, Sebastian Dietrich21
22. Continuous Integration
Warum machen wir Continuous Integration?
Warum?
Geringerer Integrationsaufwand
Automatische QS auf CI-Server
(vs. „Runs on my Machine“)
…
Was testen die Tests am CI-Server?
Unit-Tests?
Integrationstests?
Systemtests = BDD Szenarien?
Technische Qualität?
Was, wenn die technische
Qualität nicht passt?
Wir nehmen Technische Schuld auf
► www.e-movimento.com, Sebastian Dietrich22
23. Unkonventioneller Ansatz #4:
„Brich den Build – und nimm keine technische Schulden auf“
Brich den Build auch wenn die
technische Qualität nicht passt:
Architektur
Architekturverletzungen
Zyklen
Technisches Design:
Doppelter & Toter Code
Verletzung OO Designprinzipien
Wenn der Code nicht passts
Naming & Coding-Conventions
Code-Smells, mögliche Bugs
Komplexität
Wenn der Trend nicht passt
Metriken
► www.e-movimento.com, Sebastian Dietrich23
PMD
CPD
Checkstyle Sonargraph
Sotograph
Simian
JDepend
NDepend
Macker
FindBugs
Lint
CppCheck
FXCop
Axivion
NCSS
CMT
UCDetector
CRAP
Sonar Build Breaker Plugin
24. ► www.e-movimento.com, Sebastian Dietrich24
Vielen Dank für Ihre Aufmerksamkeit!
Q&A[Sebastian Dietrich]
Sebastian.Dietrich@e-movimento.com
http://managing-java.blogspot.com