Beiträge

Open Space – Stammtisch Hamburg

Mit der Open Space – Methodik geben Sie Ihrem Thema neuen Wind.

Haben Sie ein Thema, dass Ihnen unter den Nägeln brennt? Haben Sie keine Ahnung, wie Sie das angehen sollen? Dann besuchen Sie doch mal eine solche Veranstaltung in Ihrer Nähe. Stellen Sie Ihr Thema zur Diskussion. Sie werden sich wundern, mit wie viel neuen Ideen und Anregungen Sie nachhause gehen.

Alexander Schilling, Berater für Brand, Design und Change, hatte in den Räumlichkeiten von eparo zum Open Space-Stammtisch Hamburg eingeladen.

Open Space – Methodik

Weiterlesen

Teile diesen Beitrag:

Use Cases Next Level: White Paper II zum Download

Dieses zweite White Paper beleuchtet weitere Aspekte der Use Cases: Bedingungen innerhalb von Use Case-Schritten und Ausnahmen vs. Alternativen.

Nachdem ich in einem ersten White Paper beschrieben habe, wie man Use Cases am besten strukturiert und formuliert, möchte ich nun darstellen, wie man mit komplexen Geschäftsregeln und Bedingungen umgeht. Und das führt uns dann direkt zu der Unterscheidung zwischen Ausnahmen und Alternativen. Diese Unterscheidung wird leider selten vorgenommen. Dabei ist sie recht einfach und hilft dem Leser ungemein.

Das White Paper beantwortet zwei Fragen:

  • Wie gehe ich mit Bedingungen in Use Cases um?
  • Wann beschreibe ich eine Ausnahme, und wann eine Alternative?

Weiterlesen

Teile diesen Beitrag:

Use Cases richtig schreiben: White Paper zum Download

Use Cases begegnen uns in fast allen IT-Projekten. Besonders größere Vorhaben kommen ohne sie nicht aus. Dieses White Paper beleuchtet einige Aspekte der Use Case-Modellierung für Fachanwendungen.

Use Cases richtig schreiben

Das Thema Use Cases begegnet uns in unseren Projekten immer wieder. Leider gibt es darum häufig viel Ärger und Missverständnisse: Die Menge der Use Cases ufert aus und wird unübersichtlich. Viele Use Cases sind unverständlich geschrieben und werden schlichtweg nicht gelesen.

Das muss nicht sein! Ich habe ein White Paper erstellt, indem ich Antworten gebe auf die folgenden Fragen: Weiterlesen

Teile diesen Beitrag:

Infografik: Over-all UX workflow

Infografik zum Download: In einem strukturierten UX Workflow lernen Sie Ihre User kennen und wissen was Sie für wen warum machen müssen – und, ob das Design funktioniert.

User Experience Design folgt einem strukturierten Vorgehen, dass sich in vier Phasen aufteilen lässt. Diese verlaufen nicht wasserfallartig linear, sondern iterativ zyklisch. Diese Phasen sind:

  1. Kontextanalyse
  2. Nutzungsanforderungen
  3. Design
  4. Validieren

In einer Infografik habe ich aufbereitet, was UX-Designer in welcher Phase machen und was sie als Ergebnisse liefern. In großen IT-Projekten arbeiten UX-Designer aber nicht isoliert, sondern zusammen Analytikern und IT-Architekten. Auch dort entstehen wichtige Projektergebnisse, die wertvollen Input liefern. Die Infografik zeigt daher auch, wann diese traditionellen Ergebnistypen wie z.B. Use Cases und Domain Model ihren Einfluss finden. Weiterlesen

Teile diesen Beitrag:

Writing Use Cases: Avoid IF THEN in use case steps

Checking conditions within a use case step blows out the success scenario. The use case is hard to understand. Instead relocate conditions and their actions to exceptions or alternate flows.

When it comes to use cases I often read success scenarios describing lots of conditions.

The use case goes like this:

Teile diesen Beitrag:

Poster download: Over-all product flow

You can write books and books about all the artifacts your project members are supposed to produce. And there are thousands of them out there. Such a document could be even another product of your project. But -hand on heart- will anyone care? I thought it might be better designing a poster. It shows the product flow on a high level. According to the feedback I got so far from the business users they like it. It helps them to understand the meaning of their contribution in terms of the big picture. OK, that was my intention.

Download poster

Click image to download over-all product flow (pdf-file, 1,1 MB)

Download poster (pdf-file, 1,1 MB)

Weiterlesen

Teile diesen Beitrag:

Tool Set für Fachspezifikation: Alles von Anforderungen bis Aktivitäten

Eine Fachspezifikation beschreibt die fachlichen Anforderungen und Probleme, die es in einem Projekt zu lösen gilt. Es ist nicht notwendigerweise ein einziges großes Dokument. Ganz im Gegenteil: Es ist sehr viel sinnvoller, die verschiedenen Aspekte in unterschiedlichen Dokumenten und Modellen zu beschreiben.

Im Folgenden möchte ich eine Werkzeugpalette vorstellen, die meines Erachtens alle Mittel bereitstellt, um auch komplexe Zusammenhänge verständlich zu beschreiben. Es ist eine Kombination aus Textdokumenten, BPMN und UML. Wenn ich sage „verständlich beschreiben“, meine ich, dass die Dokumentation von den Projektbeteiligten verstanden werden muss. Das schließt die Auftraggeber und Fachabteilung gleichermaßen ein wie Designer und IT-Architekten. Denn nur, was verstanden wird, kann auch umgesetzt werden. Fehlt es an einer breiten Verständnisbasis, sind einerseits die Ziele unklar. Andererseits wäre es somit purer Zufall, wenn die Projektergebnisse (z.B. eine Software-Lösung) die ursprünglich erhobenen Anforderungen erfüllen.

Die folgenden Modelle und Dokumente müssen nicht in der hier vorgestellten Reihenfolge erstellt werden. Sie entstehen häufig parallel. Bei der Arbeit an einem Teil ergeben sich Aspekte, die Auswirkungen auf andere Modelle / Dokumente haben. Und nicht immer braucht man in jedem Projekt alle hier beschriebenen Artefakte. Man muss also immer wieder prüfen, was wirklich erforderlich ist. Es gilt: So wenig wie möglich, so viel wie nötig. Weiterlesen

Teile diesen Beitrag:

Bessere Risikoprävention durch dynamische Schutzmaßnahmen

Durch die Dynamisierung der Schutzmaßnahmen kann man auch einer heterogenen Risikolage Herr werden. Bei gleichem Investment kann das Sicherheitsniveau und damit der Return On Investment signifikant gesteigert werden. Dieser Artikel basiert darauf, dass wir uns der Risikolage eines Unternehmens von den Prozessen her nähern: Kostenreduzierung durch prozessbasierte Risikoanalyse.

Ausgangslage

Zu oft ist die genaue Risikolage eines Unternehmens nur unzulänglich bekannt. Man weiß, dass die Anlagen des Unternehmens einem Risiko unterliegen. Schließlich sind technische Einrichtungen in ihrer Gesamtheit immer irgendwie gefährdet. Wo aber genau die Risiken liegen und welcher Art diese sind, ist oft unklar. Daher wird dem allgemeinen Risiko mit einer großen Feuerpatsche entgegen getreten. Oder lassen Sie es mich anders ausdrücken: Das Unternehmen breitet über den gesamten Anlagenpark eine gleichbleibend stabile (oder eher instabile) „Feuerdecke“ aus.

Weiterlesen

Teile diesen Beitrag:

End-to-end example of process based risk analysis – Part 2

In the first part of this process based risk analysis example we have identified risky activities and separated them from the activities that we consider to be at no risk. Now we will inspect the remaining endangered activities in more detail. We want to find out, which technical entities are involved and what their technical risk is. The intention is to identify technical entities that we have to protect and to separate entities that we may ignore. That gives us the capability to reduce the amount of protective measures. The result will be a list of sensitive key entities and their technical risk.

Entities involved in activities

We have identified three critical activities so far: Alarm company’s fire fighters, alarm city fire department and alarm company’s security service. If those activities cannot be performed properly our company has a serious problem.

Weiterlesen

Teile diesen Beitrag: