Skip to content

Episode 14: Warum ein Detailkonzept erstellen?

Möglicherweise veraltet: Dieser Artikel ist schon älter und wurde länger nicht überarbeitet. Je nach Thema könnte es sein, dass die Infos inzwischen nicht mehr gültig sind. Nach und nach überarbeite ich die Artikel, also gerne wieder mal vorbei schauen.

In den letzten Episoden habe ich ein bisschen die Möglichkeiten der Anforderungsanalyse beschrieben. Was machen wir mit den Anforderungen, wenn sie in schriftlicher Form vorliegen? Wir müssen die Informationen bündeln und in eine Form bringen, die wir für die Umsetzung verwenden können.

Warum müssen wir so vorgehen?

Egal ob wir mit Extreme Programming oder mit dem Wasserfallmodell arbeiten, wir können die Anforderungen nicht einfach nur heruntertippen. Das heißt, können kann man schon. Aber dann kommt eine Software dabei heraus, die garantiert nicht erweiterbar und wartbar ist. Ich mußte einmal ein PHP-Projekt übernehmen, das direkt von den Anforderungen in Code geschrieben wurde. Das war eine tolle Erfahrung! In einer .php-Datei war Javascript, CSS, HTML, SQL und PHP-Code vereint. Für einen Prototypen, um schnell mal dem Kunden zu zeigen, wo die Reise hingehen soll, mag das so passen. Wenn wir später nur eine Änderung an der Datei vornehmen wollen geht es schief. Die Aufwände für die Weiterentwicklung steigen ins Unermessliche und am Ende muss alles neu geschrieben werden.

Was muss gemacht werden?

Um wirklich stabile Software erstellen zu können, muss die Software einer Systemarchitektur genügen. Die Architektur muss so ausgewählt werden, dass sie die Anforderungen abdecken kann. So muss eine Applikation, die für die Verarbeitung von Formulardaten erstellt wird, viele parallele Eingaben verarbeiten können. In einer Software für die Fahrtsteuerung eines  Autos muss vor allem die Realzeitanforderung abgedeckt werden. Es wäre ziemlich unangenehm, wenn das Auto erst die Wand durchschlägt und dann der Computer nachträglich das Lenkmanöver einleitet ;-) Die Kundenanforderungen beschreiben das System von der Kundenseite aus. Das Detailkonzept beschreibt, wie das zu erstellende System die Kundenanforderungen abdecken wird. Eine 1:1 Abbildung wird es nicht geben. Der Zwischenschritt über das Detailkonzept ist notwendig. Über den Umfang des Detailkonzepts kann man streiten. Soll wirklich alles zuerst beschrieben und dann umgesetzt werden? Manchmal ist das nicht zielführend. Jedoch muss so viel beschrieben sein, dass eine abschließend definierte Softwarearchitektur vorhanden ist.

Episode 13: Anforderungen mit XP Vorgehen aufnehmen ::: Softwareprojekte

Möglicherweise veraltet: Dieser Artikel ist schon älter und wurde länger nicht überarbeitet. Je nach Thema könnte es sein, dass die Infos inzwischen nicht mehr gültig sind. Nach und nach überarbeite ich die Artikel, also gerne wieder mal vorbei schauen.

Bei nicht allzu komplexen Projekten, oder bei Teilprojekten, kann man mit Extreme Programming (XP) sehr gute Ergebnisse erzielen.
  • Im ganz Groben kann man sagen, dass man iterativ vorgeht und zuerst ein paar Basiskomponenten erstellt.
  • Der jeweilige Stakeholder kann nach relativ kurzer Zeit das Ergebnis ansehen und seine Anforderungen näher beschreiben.
  • Auf diese Weise ist man stets im Kontakt mit seinen Stakeholder und wird die Bedürfnisse eher verstehen.
  • Bei allen Arten der Anforderungsanalyse ist es vor allem wichtig zu wissen, dass die verschiedenen Stakeholder die Welt unterschiedlich sehen und beschreiben.
  • Wenn vier Personen etwas sagen, können dabei mindestens vier unterschiedliche Ansichten entstehen.
  • Die echte Wahrheit gibt es nicht.
Weitere Hinweise zu Extreme Programming gibts z.B. in den Quellen zu Requirements Engineering.

Episode 12: Anforderungen durch schriftliche Fragen aufnehmen ::: Softwareprojekte

Möglicherweise veraltet: Dieser Artikel ist schon älter und wurde länger nicht überarbeitet. Je nach Thema könnte es sein, dass die Infos inzwischen nicht mehr gültig sind. Nach und nach überarbeite ich die Artikel, also gerne wieder mal vorbei schauen.

Eine weitere Möglichkeit Anforderungen aufzunehmen, ist die Problemstellung zuerst in einem Dokument zu beschreiben und die offenen Punkte in schriftliche Fragen zu verpacken. Hiermit kann ohne aufwändige Interviews und Brainstorming-Sessions ausgekommen werden. Falls die Stakeholder physikalisch nicht am gleichen Ort sind, z.B. Entwicklerteam in Deutschland und Stakeholder in USA kann dies eine gute Vorgehensweise sein.

Vorgehen

  • Beschreiben des Problems, eventuell mit Storybooks oder UML
  • Offene Punkte herausschreiben
  • Stakeholder beantwortet so gut er oder sie kann die offenen Punkte
  • Einarbeitung in das erstellte Dokument
  • Review über die Vorstudie
Mit nur schriftlichen Vorgehen ist die Gefahr extrem hoch, dass die Kunden nicht das bekommen was sie wirklich wollen. Seid deshalb sehr vorsichtig mit nur schriftlicher Anforderungsanalyse.

Auswertung Blogparade: Projektleiter der Welt vereinigt euch

Möglicherweise veraltet: Dieser Artikel ist schon älter und wurde länger nicht überarbeitet. Je nach Thema könnte es sein, dass die Infos inzwischen nicht mehr gültig sind. Nach und nach überarbeite ich die Artikel, also gerne wieder mal vorbei schauen.

An dieser Stelle möchte ich meine Erkenntnisse der verlängerten Blogparade Projektleiter der Welt vereinigt euch! zusammenfassen.

Eigenthref="http://miradlo.net/bloggt/index.php?113-s"">Projektleiter der Welt vereinigt euch! zusammenfassen.

Eigentlich gibt es gar kein Problem

Wie immer im Leben gibt es verschiedene Sichtweisen und Erfahrungswerte. Hans hat zum Beispiel keine negativen Erfahrungen gesammelt: Westaflex Markenwelt Lufttechnik Schallschutz Filtration » Blog Archiv » Blogparade Projektarbeit In seiner Umgebung werden Projekte korrekt und mit den notwendigen Ressourcen durchgeführt. Der Projektleiter muss keine Brüllaffen-Mentalität besitzen und Projekte dienen, wie es laut Lehrbuch auch sein sollte, dazu ein Problem aus der Welt zu schaffen. Ich habe solche Erfahrungen ebenfalls gehabt. Eine Firma wollte ein neues Produkt einführen und ich hatte von Anfang an die Zielsetzung, den Umfang und das notwendige Team beieinander. Der Umfang war realistisch, das Team und die benötigten Kenntnisse ausreichend vorhanden und nach der Projektlaufzeit konnten wir erfolgreich abschliessen. Kein Brüllaffe und auch keine Prügelei um Mitarbeiter.

Oder gibt es doch ein Problem?

Georg bestätigte mit dem Beitrag Anders leben wollen: Projektleiter der Welt vereinigt euch! jedoch wieder, dass in einigen Firmen Projekte nicht sinnvoll aufgesetzt sind. Ich habe in den letzten Wochen mit meinen Projektleiterkollegen über dieses Thema etwas mehr diskutiert. Sie haben zwar nicht bei der Blogparade mitgemacht, aber wir konnten im Betrieb erreichen, dass wir über die Verteilung der Mitarbeiter anders diskutieren. Wir haben zwar noch keine abschliessende Lösung gefunden, das wird auch nicht möglich sein, wir haben jedoch eine Basis gefunden und sprechen gemeinsam mit allen Beteiligten. Wir kommen ein wenig von der Ellbogenplanung weg.

Vielleicht ist die Definition eines Projekts einfach falsch?

Genial finde ich den Beitrag von Rick: Projektleiter = unter einem Projekt Leider Er beschreibt auf eine wunderbar satirische Weise was Projekt und das Projekt (leiden) wirklich bedeutet. Vielen Dank für diese geniale Definition ;-) Wenn man mit Humor an die ganze Sache herangeht ist die Welt wesentlich einfacher und eigentlich auch logischer. Ich danke Euch für Eure Beiträge!

Episode 11: Anforderungen mit Brainstorming Sessions aufnehmen ::: Softwareprojekte

Möglicherweise veraltet: Dieser Artikel ist schon älter und wurde länger nicht überarbeitet. Je nach Thema könnte es sein, dass die Infos inzwischen nicht mehr gültig sind. Nach und nach überarbeite ich die Artikel, also gerne wieder mal vorbei schauen.

In Episode 10 habe ich darüber gesprochen wie Anforderungen durch Interviews aufgenommen werden können. Es gibt natürlich noch weitere Möglichkeiten.

Brainstorming Sessions

Mit Brainstorming Sessions können schnell diverse Anforderungen klar gemacht werden. Eine mögliche Vorgehensweise:
  • Die verschiedenen Stakeholder (Betrieb, Auftraggeber, Anwender, Entwickler usw.) werden eingeladen.
  • Es ist schon einigermaßen klar was wir überhaupt bauen wollen, z.B. eine neue Geldwaschmaschine ;-) )
  • Zu den einzelnen Aspekten werden einleitende Fragen erstellt. Beispielsweise könnte man Fragen was die Bedienbarkeit der Geldwaschmaschine ausmachen soll.
  • Man sollte nicht zu viele Fragen erarbeiten. (Zum Beispiel vier Fragen pro Session)
  • Nun wird die Frage gestellt und alle Beteiligten dürfen zehn Minuten lang alle Ideen, seien sie noch so verrückt, sagen. Die Ideen werden aufgeschrieben.
  • Nach zehn Minuten werden die Ideen angesehen und geordnet.
  • Aus den gesammelten Ideen können die wirklich unsinnigen gemeinsam gefunden und entfernt werden. Alle weiteren Ideen werden nach Wichtigkeit geordnet und später ausformuliert.
Mit dieser Vorgehensweise können sehr komplexe Themengebiete eingegrenzt und Lösungen dafür gefunden werden.

Episode 10: Anforderungen mit Interviews aufnehmen ::: Softwareprojekte

Möglicherweise veraltet: Dieser Artikel ist schon älter und wurde länger nicht überarbeitet. Je nach Thema könnte es sein, dass die Infos inzwischen nicht mehr gültig sind. Nach und nach überarbeite ich die Artikel, also gerne wieder mal vorbei schauen.

In Episode 8 Vorstudie strukturieren habe ich ein Beispiel für den Aufbau eines Vorstudiendokuments beschrieben. So ein Dokument ist ja ganz nett, aber wie kriegt man da sinnvolle Daten rein? Hier ein paar Gedanken zu diesem Thema, wie man Interviews einsetzen kann.

Gute Idee ::: Stakeholder

Eine wirklich gute Idee ist es, sich mit den betroffenen Stakeholdern zusammen zu setzen und sie zu fragen was sie wollen. Damit das einigermaßen geordnet gehen kann, verwende ich meistens folgendes Vorgehen.

Vor dem Interview

Ich mache mir vor dem Interview klar, welche Anforderungen und welche Sprache der jeweilige Stakeholder verwendet.
  • Ein Betriebsmitarbeiter spricht sehr technisch und will vor allem verstehen welche Auswirkungen die neue Software auf seine übrigen Systeme hat.
  • Ein Auftraggeber hat Vorstellungen von dem was er will. Im Normalfall ist er nicht in der Lage die Vorstellungen in einer IT-geeigneten Sprache zu formulieren.
  • Ein Anwender kann, falls es sich um die Ablösung eines bestehenden Systems handelt, noch sagen was ihm daran gefallen und nicht gefallen hat. Er oder sie wird viele Ideen haben und keine Idee konkret formulieren können.
  • Ein Zulieferer wird sein System perfekt verkaufen und einem das Gefühl geben, alle Probleme der Welt auf einmal mit der neuen Software lösen zu können.
  • Ein Partner, der an das zu erstellende System angebunden werden soll, wird so wenig wie möglich Auswirkungen auf sein System haben wollen.

Zusammenstellen von Fragen

Für die jeweiligen Stakeholder stelle ich einen Fragekatalog zusammen. Im Interview kann ich somit das Gespräch etwas steuern. Wichtig ist hierbei, dass die Gesprächspartner nicht zu sehr von den Fragen manipuliert werden. Sie sollen immer noch ihre Wünsche und Ansprüche formulieren können.

Während des Interviews

Im Interview versuche ich die Erkenntnisse jeweils in grafischer Form aufzuzeigen. Ich erstelle grobe Systemübersichten, Business-Abläufe usw. Diese lasse ich mir im Interview von dem jeweiligen Stakeholder bestätigen.

Nach dem Interview

Nach dem Interview schreibe ich die Erkenntnisse in der Vorstudie zusammen und lasse sie vom Stakeholder nochmals gegenlesen. Hiermit können ziemlich viele Fehlinterpretationen direkt beseitigt werden.

Blogparade verlängert bis 24. Juni ::: Erfahrungen von Projektleitern

Möglicherweise veraltet: Dieser Artikel ist schon älter und wurde länger nicht überarbeitet. Je nach Thema könnte es sein, dass die Infos inzwischen nicht mehr gültig sind. Nach und nach überarbeite ich die Artikel, also gerne wieder mal vorbei schauen.

Die Blogparade war ursprünglich bis 16. Juni 2008 begrenzt. Falls jedoch Fussballfans erst Zeit haben, sobald es einen spielfreien Tag gibt, wird verlängert bis einschließlich Dienstag, 24. Juni 2008 (damit sind es zwei spielfreie Tage der Euro 2008): Projektleiter der Welt vereinigt euch!

Die Blogparade möchte Antworten von euch zu folgenden Fragen

  • Was sind eure Erfahrungen?
  • Arbeitet ihr mit euren Projektleiterkollegen zusammen oder führt ihr ein Einzelleben?
Selbstverständlich könnt ihr sowohl in den Kommentaren, als auch mit eurem Blog teilnehmen. Wäre fein, wenn sich noch der ein oder andere beteiligen würde... Die Blogparade Projektleiter haben wir, ebenso wie die Verlängerung bei blog-parade.de eingetragen, ein Service, bei dem Blogparaden gesammelt werden.