Das ist nicht nur für den Mitarbeiter eine gute Sache und wird in großen und kleinen Unternehmen schon praktiziert. Es gibt dem Mitarbeiter Flexibilität – damit ist er zufriedener, hat weniger Stress – was sich letztlich auch vorteilhaft für den Arbeitgeber auswirkt.

Wichtig ist, dass das Recht auf Homeoffice mit einer klugen Flexibilisierung der Arbeitszeiten einhergeht. Man braucht den Homeoffice-Tag ja, weil man sich tagsüber um etwas privates kümmern muss: Handwerker, Arzttermine, Kinderbetreuung… Dann muss es natürlich möglich sein, auch mal bis in die Abendstunden zu arbeiten und morgens wieder früh anzufangen.

Für ein Unternehmen wie INDAL ist es einfach, die entsprechenden Strukturen bereitzustellen, weil wir technologisch hinsichtlich Virtualisierung, VPN, Web-Apps und Smartphone-Apps ohnehin immer vorn mit dabei sind.  Deshalb gibt es bei uns die Option, im Homeoffice zu arbeiten, schon seit langem. Problematisch war zunächst nur die Internet-Anbindung bei einigen Mitarbeitern zu Hause. Aber wenn das gelöst ist, dann ist die Arbeit von zu Hause aus kein Problem mehr.

Allerdings will kein Mitarbeiter ganz auf die Arbeit im Büro verzichten. Deshalb haben wir auch entschieden, dass durch Homeoffice bei INDAL keine Schreibtische entfallen oder doppelt benutzt werden. Jeder hat seinen eignen Schreibtisch – auch der ist ja aun Stückweit ein “zu Hause” des einzelnen Mitarbeiters.

Der Beitrag Das Recht auf Homeoffice – bei uns schon Realität erschien zuerst auf INDAL Software-Spezialist.

In Communities wird geteilt

Communities werden dazu gebildet, etwas zu teilen: Ein Interesse, Wissen, Erfahrungen. Diese Communities sind somit für den Alltag unterstützend, ohne direkt in die tägliche Arbeit einzugreifen. Allerdings wissen gerade Entwickler, welche große Rolle sie heute beim schnellen Finden von Problemlösungen spielen können. Für Organisationen kann es deshalb ein Produktivitätsgewinn sein, den Mitarbeitern die Möglichkeit der Teilnahme an Communities zu geben. Andererseits befürchten manche Unternehmen zu recht, dass Know How abfließen könnte, welches einen Wettbewerbsvorteil darstellt. (Dieses Thema werde ich demnächst bei der Diskussion eines weiteren Papers aus diesem Umfeld aufgreifen).

Eine Ausnahme bilden Communities of Practice, darunter werden diejenigen Strukturen verstanden, die gemeinsam an offenen Systemen arbeiten, etwa an Open Source Projekten.

Allen Communities gemeinsam ist, dass die Mitglieder recht einfach und ohne Zutrittsregeln Mitglied werden können, und dass sie die Community genauso einfach wieder verlassen können. Entscheidungsprozesse sind in einer Community, wenn überhaupt, nur durch die Ausbildung einer impliziten Kultur möglich.

Netzwerke nutzen Technik

Das wichtigste Merkmal eines Netzwerkes ist die Sicherstellung einer gegenseitigen Erreichbarkeit. Tamburri verweist deshalb darauf, dass Netzwerke zumeist an Technologien (E-Mail, Soziale Medien, Kollaborationsplattformen) gebunden sind. Netzwerke bilden letztlich die Infrastruktur für andere kollektive Strukturen. Andererseits, und das ist für die Frage der kollektiven Entscheidungsfindung bedeutsam, erlauben Netzwerke, vorgegebene und definierte Entscheidungswege zu umgehen, Entscheidungsmechanismen, die unserer eigenen Forschung nach die Rationalität der Organisation ausmachen, können durch Netzwerke ausgehebelt werden.

Teams und Gruppen

Die eigentliche Arbeit wird in Teams und Gruppen durchgeführt, diese werden überhaupt zu dem Zwecke gebildet, die Projektarbeit zu organisieren. Tamburri unterscheidet zwischen ihnen: Gruppen werden projektunabhängig und langfristig gebildet, sie bieten den Rahmen, in dem die Arbeit organisiert wird. Abteilungen, aber auch Entwickler- und Testteams können dazu gezählt werden. Das, was Tamburri als Teams, oder Projektteams bezeichnet, sind kollektive Strukturen, die innerhalb des Projekts aus Personen zusammengesetzt werden, die gemeinsam eine bestimmte Aufgabe innerhalb des Projekts lösen sollen.

Entscheidungsfindung und Rationalität

Für unsere Forschung bei INDAL ist diese Klassifikation insofern interessant, dass die verschiedenen kollektiven Strukturen jeweils eine bestimmte Art von Rationalität in der Entscheidungsfindung zeigen, deshalb können sie in der Perspektive der ökonomischen Theorie unterschiedlich als rationale Akteure angesehen werden, für deren Beschreibung und Erklärung ökonomische Theorien herangezogen werden können. Gruppen haben durch ihre langfristige Struktur feste kulturelle regeln der Entscheidungsfindung, die entweder durch Autorität von Führungspersonen oder durch Regelwerke abgesichert sein können. Allerdings kann ihre Rationalität durch Netzwerke, aber auch durch Communities unterlaufen werden. Teams bilden selten eine kollektive Rationalität aus, da sie zu kurzzeitig existieren und die Teilnehmer oft aus unterschiedlichen Kulturen kommen. Ihre Entscheidungen sind deshalb im Sinne der ökonomischen Theorie selten als rational zu betrachten.

Auch für die unmittelbare Unternehmenspraxis können die Ergebnisse sinnvoll genutzt werden, indem auf ihrer Basis eine systematische Analyse der kollektiven Strukturen im Unternehmen und in Projekten durchgeführt wird. Letztlich ist das immer ein Teil der Anforderungsanalyse für komplexe Individualsoftware. Im Ergebnis können Schwachstellen erkannt und Optimierungen in den Entscheidungsstrukturen vorgenommen werden.

Tamburri, D., Lago, P., & Vliet, H. (2013). Organizational social structures for software engineering ACM Computing Surveys, 46 (1), 1-35 DOI: 10.1145/2522968.2522971

Der Beitrag Kollektive Strukturen im Software-Engineering erschien zuerst auf INDAL Software-Spezialist.

Ein Beispiel:
„Berichte in der Anwendung sollen innerhalb von 30 Sekunden bereitgestellt werden“
Ist das eine funktionale oder eine nicht-funktionale Anforderung? Viele werden argumentieren, dass dies eine nicht-funktionale Anforderung ist, da der Satz etwas über das „Wie“ der Leistungserfüllung aussagt. Aber dass die Anwendung „Berichte bereitstellen“ soll, ist eine funktionale Anforderung, und wenn die Berichte typischerweise erst ein Tag nach dem Aufruf des entsprechenden Menüpunktes bereitgestellt werden, dann ist das keine Funktionserfüllung, auch wenn alle Zahlen im Bericht korrekt sind.
Ein neuer Ansatz ist, zu sagen, dass jede Anforderung sowohl Aussagen zu der Frage, was umgesetzt werden soll als auch zu der Frage, wie es umgesetzt werden soll enthält. Anforderungen lassen sich dann generalisieren und spezialisieren, wie wir es aus der objektorientierten Sichtweise kennen.
Können wir damit die Anforderungen, die wir bisher in funktionale und nicht-funktionale unterschieden haben, komplett abbilden? Nicht ganz, ein Aspekt fehlt noch, es ist der der zeitlichen Veränderbarkeit der Anforderung. Ist zu erwarten, dass ein Bericht sich ändert, wenn ja, wie oft? Werden Datenmengen wachsen? Wird die Anforderung auch unter geänderten Bedingungen, z.B. bei neuen Infrastrukturen und Plattformen, bestehen bleiben? Dieser dynamische Aspekt von Anforderungen wird oft vernachlässigt, aber wenn wir ihn mit einbeziehen, dann haben wir quasi alles was wir brauchen, um eine gute Architektur zu entwerfen.
Dazu legen wir uns wie gesagt eine Anforderungs-Hierarchie an, eine Vererbungs-Struktur. Die Basis-Anforderungen sind das Fundament, sowohl für die abgeleiteten Anforderungen als auch für den Architektur-Entwurf der Software. Umso spezieller die Anforderungen werden, desto geringer ist ihr Einfluss auf die Architektur.

Der Beitrag Anforderungsaspekte: Was, Wie und Wie lange? erschien zuerst auf INDAL Software-Spezialist.

In den letzten Jahren hat sich in der Literatur die Überzeugung durchgesetzt, dass nicht-funktionale Anforderungen

1. entscheidend für die Benutzerzufriedenheit sind,
2. durch Architektur-Entscheidungen umgesetzt werden.

Das gibt uns vielleicht einen Hinweis darauf, was nicht-funktionale Anforderungen wirklich sind. Dazu ein Beispiel aus der Welt, aus der der begriff “Architektur” eigentlich stammt:

Ein Haus wird im Erdgeschoss und im Keller lange Zeit als Möbelhaus mit Lager genutzt. Nach einem kleinen Umbau dienen die gleichen Flächen als Kino mit Gastronomie. Die Architektur des Hauses hat es möglich gemacht. Welche Anforderungen wurden durch die Architektur bereits erfüllt? Es sind Basis-Anforderungen: Man braucht ausreichend Platz für große Gegenstände und für eine größere Anzahl von Personen, die sich gleichzeitig auf einer Fläche bewegen können (Verkaufsausstellung, Veranstaltung, Vortrag, Vorführung – all das sind Nutzungen dieser Art).

Analog kann man für eine Software, z.B. für ein Data Warehouse festhalten: Sie soll den schnellen Zugriff auf große Daten-Mengen für einen geschlossenen Benutzerkreis ermöglichen, Berechnungen, Zusammenfassungen, müssen sehr schnell erfolgen. Das kann man als Nicht-Funktionale Anforderungen bezeichnen, besser wäre aber, es als (abstrakte) Basis-Anforderungen zu bezeichnen. In einem objektorientierten Anforderungsmodell sind das die Basisklassen, von denen die weiteren Anforderungen (Welche Daten sollen genau für welche Benutzer auf welche Weise und wie oft) als abgeleitete Klassen aufsetzen.

Die Anforderungsanalyse beginnt dann mit diesen Basis-Anforderungen und ordnet diesen die speziellen Anforderungen zu. Und so kann dann auch der Architektur-Entwurf der Anwendung erfolgen. Wie im Bauwesen: Erst wird das Grundgerüst entworfen, welches die flexible Nutzbarkeit für die Basis-Anforderungen erfüllt, dann werden die speziellen Nutzungsformen berücksichtigt. Auf diese Weise entstehen flexible, langlebige Architekturen.

Der Beitrag Nicht-funktionale Anforderungen oder Basis-Anforderungen erschien zuerst auf INDAL Software-Spezialist.

Der Beitrag Studie: IT-Projekte in der Krise erschien zuerst auf INDAL Software-Spezialist.

Ort: A2 am Aasee, Annette-Allee 3, 48149 Münster

17:30 Uhr:

Get together im A2 am Aasee

Networking mit wunderbarem Aaseeblick aus dem 2. Obergeschoss der Aasee-Terrassen

18:00 Uhr:

Begrüßung und Unternehmenspräsentationen

Cornelia Gaebert, Vorstandssprecherin des IT-Forums

18:30 Uhr:

Wie können Fremde Partner werden?

Prof. Dr. Kurt Röttgers, Philosoph, FernUniversität Hagen

19:30 Uhr:

IT-Projekte und der Kampf der Kulturen

Jörg Friedrich, INDAL

20:00 Uhr:

Diskussion

20:45 Uhr:

Imbiss und Networking

über dem Aasee bei Nacht

Der Beitrag Veranstaltungshinweis: Fremde Partner in der globalisierten Wirtschaft erschien zuerst auf INDAL Software-Spezialist.

Der Beitrag IT-Projekte und der “Kampf der Kulturen” erschien zuerst auf INDAL Software-Spezialist.

Das klappt meistens, auch wenn ich die Abfrage dann in eine andere Abfrage einbaue. Auch noch, wenn ich dann eine Union-Abfrage darum herum baue. Aber wenn ich die dann in eine Kreuztabellenabfrage einbaue geht es schief. Dann muss ich das Feld als Parameter in der Abfrage angeben, damit es wieder funktioniert!

Access eben.

Der Beitrag Access: Formularinhalte in Abfragen verwenden erschien zuerst auf INDAL Software-Spezialist.

Im Wirtschaftsspiegel 2/2008 geht es im Titelthema um das Thema Ausbildung, an prominenter Stelle des Beitrages (im Heft Seite 14) wird hier über unser Unternehmen berichtet.

Der Beitrag Aktuelle Pressemeldung über INDAL erschien zuerst auf INDAL Software-Spezialist.

Will man ein Feld, welches zur Datenquelle eines Formulars gehört, im Quellcode des Formulars ansprechen, schreibt man einfach Me!Feldname

Schade ist dabei, dass die Codeergänzung beim Schreiben dann ncith funktioniert. Böse Falle: Mit dem Punkt hinter Me funktioniert die Codeergänzung. Aber Achtung: Will man die Formulare in eine andere Datenbank importieren (z.B. eine neue Softwareversion), erkennt Access die Feldnamen nicht mehr, und man muss im Formularentwurf die Datenanbindung erneuern, wofür es leider keinen Automatismus gibt, und auch eine Prozedur, die das für alle Formulare automatisch tut, ist nicht mal eben in 5 min geschrieben.

Also: Lieber immer das Rufzeichen nehmen, wenn man auf Datenbankfelder referenziert!

Der Beitrag Access und das Rufzeichen erschien zuerst auf INDAL Software-Spezialist.