Unsere IT-Seminare laufen bevorzugt als "vor Ort" IT-Seminare im Hause unserer Kunden. Damit ist gewährleistet, dass ausschliesslich die Interessen des Auftraggebers massgebend sind. Zeit- und Inhaltsplanung stimmen wir mit Ihnen ab.

Software-Engineering: Methodik der systematischen Software-Entwicklung

Gut zu wissen:

Voraussetzung für eine rationelle Realisierung von hochwertigen Software-Produkten ist der Einsatz moderner, die Produktivität steigernder Entwicklungsmethoden, die gleichzeitig Management und Implementierung unterstützen, damit der Überblick nicht verloren geht und der Projektfortschritt tatsächlich in Richtung Ziel geht.

Inhalt:

Der Lebenszyklus typischer Software-Produkte

Methoden und Werkzeuge zur Planung, Analyse und Definition

Software-Engineering mit UML 2.0

Software-Qualitätsmanagement

Prinzipien des Software-Entwurfs

Implementierung und Test

Abnahme, Einführung und Wartung

u.a.m

Termine: werden individuell mit dem Auftraggeber vereinbart.
Dauer: je nach Umfang zwischen 1 Tag und 5 Tagen.
Seminarort: Stuttgart, München oder vor Ort im Hause des Auftraggebers.
Seminarpreis: €890,-- zzgl. MwSt. pro Tag (incl. Unterlagen & Pausengetränke Bonus-Material:Die Seminarteilnehmer bekommen die im Seminar benutzte Tool-Software passend zum erworbenen Know How mit! Damit steht einer sofortigen Umsetzung nichts im Weg.

Seminarsprache: Deutsch

Wer teilnehmen sollte:

Programmierer, Software-Architekten, System-Architekten, Software-Projektleiter, Web-Entwickler, Web-Designer, ....

Ihre Anfrage:

Seminarort:

Die Software-Engineering-Seminare finden im Hause des Auftraggebers statt. Termine werden Individuell vereinbart.

Referenten:

Prof. J. Anton Illik und das Ambit Engineering Team. Prof. J. Anton Illik lehrt Software-Engineering und Web-Businessan der Hochschule Furtwangen. Er gilt als ausgewiesener Experte auf diesen Gebieten und ist Autor zahlreicher wissenschaftlicher Veröffentlichungen. Neben seiner Tätigkeit als Hochschullehrer ist er als Unternehmensberater spezialisiert auf Training und Consulting in den Bereichen "Web-Business", "Projektmanagement" und "Software-Engineering". Als freier Mitarbeiter des Stuttgarter Computer Magazins hat J. A. Illik zahlreiche journalistische Beiträge und einige Sonderhefte verfasst. Er ist Mitglied in der GI Gesellschaft für Informatik und Förder-Professor im Exist-Gründungsnetzwerk des Bundesministeriums für Wirtschaft und Technologien.

Know-How:

Software-Engineering, Management und Software-Qualität

Egal, ob technische oder anwendungsorientierte Software entwickelt werden soll, der Analytiker muss etwas von der "Anwendungswelt" verstehen. Genau aus diesem Grund werden diese Fachleute auch als Anwendungsanalytiker bezeichnet. Bei technischer Software, wird der Anwendungsanalytiker aus einem technischen Fachbereich stammen, für den die Anwendung, oder das systemnahe Softwaresystem, geschrieben wird. Andernfalls werden typische Prozesse und Abläufe kaum richtig eingeschätzt, ganz zu schweigen von anderen Kenngrößen, anderen Parametern und Werten. Bei Business-Anwendungen ist das nicht anders: auch hier muss der Anwendungsanalytiker die Sprache der Anwender verstehen, Abläufe, Prozesse und Transaktionen und ihre Parameter kennen.

Der Anwendungsanalytiker muss jedoch nicht notwendiger Weise etwas von der Programmierung verstehen. Entscheidend ist, dass er vollständig und präzise die Anforderungen aus der Anwendungswelt beschreiben kann. Seine Hauptaufgabe ist die Beschreibung dessen, WAS gebraucht wird. Diese Beschreibung muss natürlich schriftlich festgehalten und mit Bildern unterlegt werden. Hierfür kommt heute typischer Weise die Beschreibungssprache UML (Abkürzung für Unified Modelling Language) ins Spiel.

Über die Programmierung sollte sich der Anwendungsdesigner (gelegenlich auch Anwendungs- oder Business-Architekt genannt) keine Gedanken machen. Dies ist die Domäne des Software-Architekten oder Programm-Designers. Er muss die Anforderungen technisch umsetzen, die der Analytiker erarbeitet hat. Der Software-Architekt und Programm-Designer entscheidet WIE die Anforderung realisiert wird. Natürlich ist es nicht so, dass ein kompetenter Business-Architekt sich nicht über programmtechnische Details mit dem Software-Architekt unterhalten darf. Was jedoch unbedingt vermieden werden muss, ist die Vermischung von WAS und WIE, denn die Anworten auf das WAS und das WIE kommen aus jeweils verschiedenen Welten: die Antworten auf das WAS kommen aus der Welt der Anwendung, des Business, da geht es beispielsweise bei einer Bankanwendung um typische Geschäftsabläufe im Rahmen des Börsenhandels.

Für die Beschreibung des WAS ist hier ein mit dem Börsenhandel vertrauter Business-Architekt notwendig. Wenn es um die Software-Architektur und die Programmierung geht, ist eine komplett andere Fachwelt im Spiel mit ihren ganz eigenen Kompetenzfeldern: Fragen, wie welche Softwaretechnologien wann wofür einsetzbar sind, erfordern tiefgründiges Know How aus diversen Bereichen der Informatik: Programmiersprachen, Datenbanktechnologien, Web-Service und Kommunikationsmöglichkeiten über lokale und globale Netzwerke, graphische Benutzeroberflächen und Betriebssysteminternas müssen vorhanden sein.

Der Softwarearchitekt sollte den letzten Stand der Informatik-Technologie kennen. Dies wird vom Business-Architekt in der Regel nicht verlangt werden können - schliesslich soll er sich in der Anwendungswelt auskennen und hat deswegen wohl kaum Zeit, durch entsprechende Weiterbildungsmaßnahmen, Kongressbesuche und Literaturstudien so tief in die Informatikwelt einzutauchen wie der Software-Architekt es tun muss. Das Umgekehrte gilt natürlich auch: der Software-Architekt kann die Anwendungswelt nicht wie seine Westentasche kennen: in unserem Beispiel müsste er sich sonst täglich auf dem Börsenparkett bewegen. Zugegebenermaßen kann es solche Kompetenzkombinationen geben, die Regel ist das aber nicht.

Die weicheren Team-Faktoren

Die Kompetenz wird nicht zum Tragen kommen, wenn das Team nicht optimal zusammenarbeitet - Reibungsverluste sorgen schnell dafür, dass Einzelne - oder auch alle - die Lust verlieren, zuerst innerlich kündigen, Dienst nach Vorschrift machen und bestenfalls als Low Performer und passive Mitläufer keine Unruhe verbreiten. Wer nicht Still hält, wird dafür sorgen, dass es zu rumoren beginnt und wenn sich nichts ändert, wird die Kündigung kommen. Wer engagierter ist, wird nach dem Motto handeln "love it, change it or leave it". Damit Reibunsverluste erst gar nicht entstehen, muss das Management für die richtige Teamzusammensetzung sorgen! Um bei unserem Beispiel zu bleiben: ein Team, ausschließliche aus Analytikern zusammengesetzt, wird nicht funktionieren. Alle analysieren alles, die konstruktiven Designer fehlen. "Analysieren" heißt im Wesentlichen "zerlegen" und der kreative Designer muss aus einzelnen Möglichkeiten eine Lösung "zusammensetzen". Hierfür sind also schon unterschiedliche Persönlichkeitstypen gefordert. Erfahrene Manager wissen, dass Teams am Besten aus vier, fünf unterschiedlichen Persönlichkeitsprofilen rekrutiert werden.

Der Projekt-Manager

Von zentraler Bedeutung bleibt der "Kopf" des Projekts, auch wenn das Team optimal zusammengesetzt ist. Erst der Führungsstil des Projekt-Managers setzt die Kräfte frei und läßt das Team im Einklang arbeiten. Der Projekt-Manager hat eine ähnliche Verantwortung wie der Dirigent: Spezialisten müssen koordiniert werden. Erfahrungsgemäß ist diesbezüglich ein kooperativer Führungsstil am Besten geeignet. Insbesondere, wenn alle Teammitglieder über ein hohes Kompetenzoptenzial verfügen, was in aller Regel in unserem Umfeld "Software-Engineering" der Fall sein sollte.

Kernpunkte eines kooperativen Führungsstils sind ein hoher Kommunikationsgrad innerhalb des Teams, die Partizipation aller an Entscheidungen, die jeweils das eigene Kompetzenzgebiet betreffen und der Versuch durch ständiges Lernen die Teamperformance zu optimieren. Dies geht in aller Regel nicht mit einem autoritäten Führungsstil von gestern.

Sicherstellung der Qualität

Für das Qualitätsmanagement gibt es ca. vier "philosophische" Grundlagen. Da wäre zum einen der produktbezogene Ansatz. Hier stellt man sich auf den Standpunkt, dass Qualität ist eine messbare, genau spezifizierte Größe ist, die sozusagen in das Produkt mit hineinkonstruiert und mit eingebaut werden muss. Der zweite Ansatz ist der benutzerbezogene Ansatz.Hier geht man davon aus, dass Qualität durch den Produktbenutzer festgelegt wird. Der dritte Ansatz ist ein prozessbezogener Ansatz: die Qualität entsteht hier durch die "richtige" Herstellung des Produkts. Ein sorgfältig geplanter und ausgeführter Produktionsprozess garantiert ein qualitativ hochwertiges Produkt, ist hier also die Auffassung. Eine vierte Philosophie ist der Kosten-Nutzen-bezogene Ansatz, der davon ausgeht, dass Qualität eine Funktion von Kosten und Nutzen ist, was heißen soll, Qualität hat ihren Preis, sie verursacht entsprechende Kosten und ist nicht für lau zu haben, einerseits, und andererseits: Qualität ist an den Nutzen gekoppelt. Geht Qualität über den Nutzen hinaus, so ist dieser Zuwachs nichts mehr Wert.

Sicherstellung der Qualität

Informatik-Technologie, Management, Kompetenz und Team¬zusammen¬setzung sind komplex miteinander verwoben. Nur wenn die Mischung der essentiellen Komponenten in diesem Zusammenspiel stimmt, wird die notwendige Qualität in der Software zu finden sein, so dass Auftraggeber und Kunde gleichermaßen zufrieden sein können.