Ziel wäre gewesen einen Anwendungsfall zu streichen, und dabei die minimalen Anforderungen trotzdem zu erfüllen.

Was sind die minimalen Anforderungen?

Aus dem vorhergehenden Artikel von Roland sind die Anforderungen wie folg definiert:

• Eine Userverwaltung
• Eine Kategorieverwaltung (Hier kann man Abstriche machen. Man könnte viele kleine Newssysteme für die jeweilige Kategorie installieren. Dann kann man durch Konfiguration die Komplexität verringern. Dafür hat man halt die Problemstellung, dass die Konfiguration je nach Einsatz ziemlich komplex werden kann.)
• Eine Artikelverwaltung
• Irgendwas um die Bilder hochzuladen
• Eine einfache Art die News auf Webseiten zu positionieren.

Ein anderer Lösungsweg für die Kategorieverwaltung bedeutet für mich im Moment, dass diese Anwendungsfälle wegfallen.

Der Bilderupload war die nächste Stelle, um abzuspecken. Die Bilder sollen “geploaded” werden, das ist die Anforderung. Das zusätzlich noch Stammdaten angelegt werden, ist nicht definiert. Für mich klingt das im Moment ein Wenig nach Bildverwaltung, und die ist nicht als Anforderung definiert also raus…

Doch dann kam die Spalte mit den verbauten Chancen und es wurde klar, dass jeder gestrichene Anwendungsfall Chancen auf Übersichtlichkeit, Datenhaltung, Verwaltung, usw. verbaut.

Was kann man da nun tun?

Ähnliche Beiträge

Schnittstellen

In diesem Modell habe ich folgende Schnittstellen (Interfaces) festgelegt:

IUserModel

Dieses Interface kapselt die Methoden des UserModels.
Ich benötige ein Modell, mit dem wir unsere User im System ablegen können. Diese User müssen existieren und entsprechend das gewünschte Passwort vorweisen können.
Also LoginName und Passwort ist cool
Ich habe mich entschlossen diese Security Elemente im UserModel abzulegen und dieses UserModel außerhalb der Security Komponenten zu positionieren.
Vielleicht wäre es noch sauberer gewesen alle Userdaten, wie Name, UserTyp usw. in einem UserModel zu verwalten und alle Security Dinge in einem SecurityUserModel.
Aber dann brauch ich noch mehr Modelle und irgendwann will ich auch mal mit dem Newssystem fertig werden
Wir brauchen ja noch was zum Reverse Engineering gelle?
So, wir verwenden also den LoginName und das Passwort um den jeweiligen User zu authentisieren.
Da wir ein Interface verwenden, ist es völlig egal wie die Methode realisiert wird. Wir haben das Newssystem an dieser Stelle vom Security System entkoppelt.
Falls wir ein anderes Security System verwenden, können wir einfach auf die Speicherung von LoginName und Passwort im UserModel verzichten.

ICategory

Da unsere Redakteure nur in bestimmten Kategorien Zugriff erhalten, werden wir entsprechend die Frage, ob der Redakteur für eine bestimmte Kategorie berechtigt ist an unser Kategoriemodell weiterleiten. Falls das in einer Security Implementation nicht benötigt oder gewünscht ist, können wir hier auch die Systeme leicht voneinander entkoppeln.

IAuthentication

Wir greifen in unserem Newssystem über dieses Interface auf die Authentication Methoden zu. Falls ein anderes Security System gewünscht wird, muss es nur diesem Interface genügen. Wenn das andere anzubindende Security System dieses Interface nicht anbietet, können wir eine Fasade oder einen Adapter davorstellen. Das Security System ist somit vollkommen von unserem Newssystem entkoppelt und wir können es immer und überall aufrufen.
Cool ist, dass hiermit auch andere Systeme auf diese Schnittstelle zugreifen können.
Eventuell sollten wir, falls wir unser Security System mehrmals verwenden wollen, wirklich unser IUserModel im Security System realisieren. Dieser Umbau ist später einfach möglich.

IAuthorisation

Hierüber wird gesteuert, ob ein User überhaupt berechtigt ist auf eine bestimmte Komponente und Aktion zuzugreifen.
Da wir im Newssystem konzequent das CRUD Pattern umsetzen, können wir auf Komponentenebene jeweils die Create, Read, Update und Delete Aktion auf Userebene absichern.
Na, sind wir nicht stabil und sicher damit?

Klassen

Ein paar Klassen sollten wir trotzdem realisieren und uns nicht nur hinter Interfaces verstecken

Authentication

Hier realisieren wir unsere interne News-Berechtigungsklasse. Nur User, die sich am System anmelden können, lassen wir im System zu.
Diese Klasse verwendet die UserModel Klasse um auf die gespeicherten User und deren Passwörter zugreifen zu können.

Authorisation

Wenn ein User angemeldet ist, wird ihm eine bestimmte Rolle zugewiesen.
Bei uns gibt es Redakteuere, Master Redakteure, Administratoren usw.
Jede Rolle hat bestimmte Rechte. Wir können hiermit festlegen, dass der Redakteur nur seine Kategorien sieht und verändern kann.
Der Administrator kann neue Kategorien hinzufügen und verändern.
Diese Klasse kontrolliert, ob der jeweilige User die gegebenen Rechte hat.
Falls ja, liefert sie true zurück.

AuthenticationFactory

Damit wir unsere Authentication Klasse gegen andere Systeme austauschen können, bauen wir diese Fabrikklasse ein.
Jedesmal wenn wir einen Zugriff auf die Security Klassen benötigen, rufen wir diese Klasse auf. Wir erhalten die jeweils aktive Instanz, die dem Interface IAuthentication genügt. So können wir sicherstellen, dass wir später auch ein anderes Security System mitverwenden können.

AuthorisationFactory

Klar, wenn die Authentisierung schon gekapselt werden soll, dann auch die Authorisierung.
Damit haben wir die notwendigen Klassen beieinander um die bisher bekannten Security Anforderungen für den ersten Sprint abzubilden.
Jetzt muss sich nur noch jemand bereiterklären die Teile kurz auszucodieren.
Wenn sich kein Freiwilliger meldet, werde ich das wohl machen dürfen

Ähnliche Beiträge

Mach dir zuerst über die Security Gedanken

Als ich so meine Architekturtapete pinselte, dachte ich logischerweise auch über die Zugriffsrechte der Anwender nach.
Es gibt, wie immer, verschiedene Vorgehensweisen und Möglichkeiten wie man seine Sicherheitsregeln in das System einbaut.
Hier sind ein paar Gedanken dazu.

Authorisierung in den Modellen

Man kann z.B. die Zugriffsrechte fest in den Modellen einschreiben.
Das bedeutet, das jeweilige Modell kontrolliert, ob der Anwender überhaupt diese Aktion durchführen darf.
Dazu können hart kodierte Regeln verwendet werden. Das bedeutet der Redakteur darf nur seine eigenen Artikel verändern, also prüfen wir ob der aktuell angemeldete Redakteur im Artikel eingetragen ist.

Vorteile

• Wir können die Regeln einmal festlegen und eintragen
• Die Sicherheit wird auf Modellebene gesteuert
  Ein versehentliches falsches Einfügen und Verändern sollte verhindert werden können.

Nachteile

• Die Regeln stehen hart kodiert im Modell drin
  Änderungen an den Sicherheitsregeln müssen in den Modellen vorgenommen werden. Das nachträgliche Anpassen für einen Kunden ist nicht möglich. Wenn aber ein Kunde will, dass der Systemadministrator auch Artikel bearbeiten kann, dann geht das nicht. Wenn das jedoch ein Kundenwunsch ist, finde ich es nicht richtig unser System schon von Anfang an so einzuschränken.
• Wenn ein zentrales Security System verwendet werden soll, dann können die Zugriffsregeln nicht von dort aus gesteuert werden. Das System ist in sich geschlossen und nicht erweiterbar.
• Duplizierung von Code und Verantwortlichkeiten auf verschiedenen Layern
  Falls die Regeln auch Auswirkungen auf die Views haben, wie Beispielsweise die Anzeige von Löschbuttons nur wenn du auch die notwendigen Rechte hast, dann muss man diese Regeln auch noch in der View implementieren.
• Seperation of Concern verletzt
  Das gefällt mir als Architekt natürlich gar nicht. Wieso soll sich eine View oder ein Modell um die Berechtigungen des Users im Detail kümmern? Das macht die Komponenten dick und fett und das kann kein guter Ansatz sein.

Oha! Das war noch nichts.
Gut, ich behaupte mal die meisten Systeme sind genau so, oder so ähnlich aufgebaut. Aber wenn es falsch ist, dann ist es auch falsch wenn es meistens so gemacht wird.
Also gut, ein weiterer Versuch:

Security Rules nur in den Controllern

Der Controller ist ja dafür da, die Abläufe im System zu steuern.
Da wäre es doch nur rechtens, wenn er sich auch um die Security kümmert.
Wenn unser lieber User jetzt eine Aktion ausführen will, die er nicht ausführen darf, dann hindert ihn der Controller daran.

Vorteile

• Die Zugriffsdefinition wird an einer Stelle gehalten
  Juchu! Klingt doch schon eher nach Seperation of Concerns gelle?. Wenn wir was ändern wollen, dann ändern wir den jeweiligen Controller. View und Modell kümmern sich um die Ansicht und die Speicherung.
• Flexibilität der Rechtevergabe deutlich erhöht
  Da wir nun eine zentrale Komponente haben, in der wir die Rechtevergabe steuern, sollte es deutlich leichter sein diese zu verändern.

Nachteile

• Auf Modellebene wird keine Zugriffssteuerung implementiert.
  Das ist ein ziemlich dicker Nachteil. Das Modell muß permanent und immer sich um die Richtigkeit der Daten kümmern. Wenn wir dem Modell jetzt diese Verantwortung entziehen, dann muss der Controller immer sauber programmiert sein. Damit entsteht eine Sicherheitslücke. Denn wer weiß? Vielleicht umgeht ein versierter Hacker unseren Controller?
• Zentrale Rechteverwaltung nicht möglich
  Da wir wieder unsere Rechteverwaltung im System behalten, können wir eine Verwaltung nicht in einer externen Komponente auslagern. Unser System bleibt dick und wenn wir es irgendwo integrieren wollen, bleibt dem Administrator nichts anderes übrig als verschiedene Administartionstools zu verwenden.

Hm… Schon mal nicht schlecht, bis auf die Nachteile.
Mir gefällt diese Implementation jedoch schon viel besser als die Erste Variante.
Vielleicht gibts da noch was anderes?

Rechteverwaltung in eigene Komponenten auslagern und über Interface ansteuern

Das klingt schön kompliziert und gefällt deshalb dem Architekt
Quatsch, das ist gar nicht kompliziert, hilft uns jedoch die Komplexität zu senken und später ein anderes Rechtesystem mitzuverwenden.
Wir erstellen, z.B. mit einem Singleton oder Factory Pattern, ein eigenständiges Sicherheitsregelwerk. Dieses Regelwerk wird für die Standalone Lösung des Newssystems verwendet.
Die Authorisierung wird über ein Interface angesprochen.
Dieses Interface bietet mindestens eine Funktion.
Und die nennen wir z.B. isActionAllowed(actionID, component).
Wir übergeben dieser Methode die Aktion die zur Zeit aufgerufen wurde und die Komponente auf die diese Aktion angewendet wird.
Die Methode liefert true zurück, wenn der Anwender diese Aktion durchführen darf. Und, rate mal, false falls er es nicht darf.
Unglaublich digital!
Jetzt können wir in jedem Modell und in jedem Controller oder View nach belieben Regeln festlegen und im zentralen Authorisierungssystem implementieren.

Vorteile

• Zentrale Verwaltung aller Rechte möglich
  Vorbei sind die Probleme, dass wir Rechte nicht zentral verwalten können. Je nach Strategie können wir eine Whitelist oder eine Blacklist implementieren. Will heißen, dass wir z.B. nur true zurückliefern, wenn die Komponente und Aktion bekannt und erlaubt ist. Oder wir liefern true zurück wenn wir keinen Plan haben was da aufgerufen wurde. Dann überprüfen wir nur, was wir auch schon kennen.
• Auf Modellebene kann Rechteverwaltung realisiert werden.
  Wenn wir mindestens alle Modelle in der Rechteverwaltung aufnehmen, ist eine Rechtesteuerung auf Modellebne möglich.
• Größte Flexibilität bei der Rechtevergabe
  Klar, wir können hier die wildesten Rechtesteuerungen erfinden. Aber Vorsicht! Es ist nicht cool man wenn man damit jedem Anwender alle Rechte gibt.
• Einfaches Testen
  Da die Security in einem eigenen System zusammengefasst ist, können wir für jede Aktion von CRUD und jeder Komponente einen true und false Testfall generieren. Wir können dann sehr sicher sein, dass z.B. die Modelle nur speichern wenn sie auch wirklich speichern dürfen.

Nachteile

Was? So eine coole Lösung und Nachteile?
Leider ja…

• Modelle haben keine direkte Kontrolle über Authorisierung
  Dieser Nachteil ist der gleiche wie wenn wir die Rechtevergabe dem Controller übergeben. Der Entwickler und Administrator unserer Rechtesystems muss wissen was er tut. Das Modell unterstützt ihn hierbei nicht.
• Externe Rechtevergabe kann Sicherheitslücken verursachen
  Klar, wenn wir unsere Security “outsourcen” dann verlieren wir innerhalb des Systems die Kontrolle darüber. Aber mal ehrlich: Wir bauen hier ein Newssystem, im schlimmsten Fall wird mal eine schlechte Nachricht geschrieben oder gelöscht…

Wozu hat sich jetzt der (graue) Star Architekt entschlossen?

Ratet mal!
Ich bin ein faules Tier und möchte die Flexibilität so hoch wie möglich halten.
Also werde ich in die Architektur die dritte Variante einbauen.
Wie bitte? Faul und dann so ein System?
Genau deshalb. Wenn wir nur eine Komponente verwalten müssen, mit der wir die Authorisierung durchführen, sparen wir uns über die Zeit eine menge Arbeit.
Wenn die einzelnen Methoden einfacher aufgebaut sind, können wir sie schneller uns sicherer testen.
Dann kann ich ruhig schlafen und habe das gute Gefühl keine vollständige Standalone Lösung entwickelt zu haben.

Hätten wir diese Lösung auch noch später einbauen können?

Ja, das hätten wir gekonnt. Doch wir wären permanent über den User und seine Berechtigungen gestolpert. Im schlimmsten Fall hätten wir die einzelnen Berechtigungen schon irgendwie in den Controller, oder noch schlimmer, nur in die Views eingebaut.
In den Views wäre besonders schlimm, da das erste was ein böser Bube umgehen kann die View ist. Ein Roboter braucht keine View…

Ähnliche Beiträge

MediaWiki

• Stärken

Versionen der Anforderung möglich.
Rechteverwaltung möglich.
Diskussionsmöglichkeit gegeben um evtl. direkt den Status der Anforderung zu besprechen.
Kategorisierung, Suchfunktion, und Anordnung möglich.

• Schwächen

Eingabe der Anforderung ist nicht ganz durchgängig.

Eine für jeden verständliche Anordnung der Anforderungen muss noch erfunden werden.

• Chancen

Es besteht die Möglichkeit einzelne Anforderungen direkt auszudiskutieren und einen Status festzulegen.
Anforderungen müssen nicht unbedingt per Mail entgegengenommen werden, sondern können an passenden Stellen eingetragen werden.
Man kann Bilder oder andere Medien einfügen um Vorgänge oder Anforderungen genauer zu beschreiben.
Erstmaliger Einsatz von einem Wiki.

• Risiken

Es muss eine geeignete Struktur eingesetzt werden, damit keine Anforderungen untergehen.

Blog

• Stärken

Diskussionsmöglichkeit gegeben.
Rechteverwaltung möglich.
Kategorisierung möglich.
Anforderungen können direkt eingetragen werden.

• Schwächen

Artikel oder Seiten können nicht nachträglich in andere Kategorien oder Serien geordnet werden.

• Chancen

Jeder ist mit dem System vertraut und man würde sich Einarbeitungszeit sparen.

• Risiken

Man müsste sich auf ein nicht änderbare Anordnung festlegen, und somit evtl. feststellen, dass diese Tool doch unpassend ist.
Keine Erfahrung ob sich dieses Tool als “Anforderungserfassungssystem” eignet.

Gobby

• Stärken

Dokumente können von mehreren gleichzeitig genutzt werden.
Zeitversetztes arbeiten möglich.
Anforderungen können in ein passendes Dokument eingetragen werden.
Diskussionsmöglichkeit über Chat möglich.
Mehrere Dateien können über ein einzelnes Fenster geöffnet werden.

• Schwächen

Jede Anforderung müsste ein eigenes Dokument erhalten.
Einzelne Dokumente werden durch einen Filebrowser geöffnet, somit bestimmt die “Ordner/Datei-Anordnung” die Übersichtlichkeit.
Ein z.B. Tabellendokument (.ods) ist in der Liste der bekannten Dateiformate nicht vorhanden.
Das System ist nicht jedem bekannt.

• Chancen

Wir lernen ein neues Tool kennen.

• Risiken

Kriterien, wie Übersichtlichkeit, Kategorisierung usw. werden evtl. nicht erfüllt.

Einige dieser Tools habe ich nur angetestet, und sind mir nicht im Detail bekannt. Also falls es z.B. doch sein kann das Gobby auch andere Dateiformate annimmt oder es bei einem Wiki doch noch Schwächen gibt die ich Übersehen habe, könnt ihr es ja kommentieren…

In Anbetracht dessen, dass der Weg der Anforderungen doch nicht unbedingt per Mail erfolgen soll, würde ich ein Wiki vorziehen. Dort hätte man tatsächlich die Möglichkeit Anforderungen selber einzutragen und deren Status auszudiskutieren. Darüber hinaus können Änderungen anhand verschiedener Versionen jederzeit ersichtlich sein. RSS-Feeds könnte man ebenfalls benutzen, was somit alle Teilnehmer über Änderungen informiert. Ausserdem wäre ein Einsatz eines Wikis auch mein erstes Mal, und somit eine Erfahrung wert.

Was haltet ihr diesmal davon?

Ähnliche Beiträge

• Create Editor
• Create MasterEditor
• Create SysAdmin
• Show Editors
• Show SysAdmins
• Show MasterEditors
• Update Editor
• Update SysAdmin
• Update MasterEditor
• Delete Editor
• Delete SysAdmin
• Delete MasterEditor

Weiterhin würde ich die technischen Anwendungsfälle für die Passwortverwaltung erstellen:

• Reset Password
• Change Password

Und damit unser Newssystem mal ein paar Datensätze aufnehmen kann, würde ich die erste Version des ArticleModel und der Kategorie erstellen.

• Create Category
• Create Article
• Show Categories
• Show All Articles
• Update Category
• Update Article
• Delete Category
• Delete Article
• Add Editor To Category
• Add MasterEditor To Category
• Remove Editor from Category
• Remove MasterEditor from Category

Was ist das Ziel des ersten Sprints?

Wir haben ein Basissystem mit dem wir rumprobieren können.
Es sind noch keine Userviews vorhanden.
Wir können mit CakePHP umgehen und sehen welche Eigenschaften wir tatsächlich umsetzen müssen.
Testfälle für das Basissystem sind vorhanden.
Wir können abprüfen, ob unsere Komplexität ausreichend ist.
Erste Designfehler sollten auftauchen.
Eventuell müssen wir nach diesem Schritt unser komplettes Design noch einmal überarbeiten.
Vermutlich wird es aber soweit passen…

Ähnliche Beiträge

• miradlo Issue Tool
• Doku Wiki
• Media Wiki
• phProjekt
• wordpress Blog
• google docs
• Gobby

miradlo Issue Tool

Das “miradlo Issue Tool” ist wie bereits von Roland erwähnt sehr einfach zu benutzen. Man kann wirklich von Eingabefeld zu Eingabefeld “hüpfen” um Bearbeiter, Ersteller usw. einzutragen. Es besteht die Möglichkeit nach einem bestimmten Feld zu sortiern. Es müssten allerdings weitere Eingabefelder hinzugefügt werden und Rechteverwaltung ist im Moment auch nicht vorhanden.

Doku Wiki

Das  “Datenbanklose Doku-Wiki” hat meiner Meinung nach keine der benötigten Eigenschaften erfüllt. Das Erstellen einer Seite, und das Einrichten der Seitenleiste (Navi) war schon nicht sehr durchgängig. Es hat in jedem Fall seine nutzen doch passend für mich kam mir das nicht vor.

Media Wiki

Auch hier konnte ich lediglich Seiten erstellen, indem ich über die Suchmaske den Namen der Anforderung eingegeben habe. Ob das wirklich so funktioniert ist mir im Moment nicht bekannt, jedenfalls macht auch dieses Tool nicht den Anschein für unseren Zweck zu passend zu sein.

phProjekt

Hier ist klar, dass sich jeder in das Tool einarbeiten müsste. Nach der  ersten Installation, und einigen Versuchen auf der Demoversion fällt auch dieses Tool weg.

WordPress

Man kann jede Anforderung als Artikel erstellen, in Serien verpacken und diese dann z.B. in die Serien “genehmigt”, “abgewiesen”, “abgeschlossen” usw. verschieben. Nachträgliches verschieben in andere Serien ist allerdings nicht möglich, somit wäre ein ordentliches “hin und her” schieben (Was auch einer meiner Pläne war… ) nicht gegeben. Auch nachträgliches verschieben in andere Kategorien würde nicht ohne weiteres klappen, daher fällt auch ein Blogsystem als Tool weg.

Google Docs

Man hat ein Dokument, das man an einer Stelle pflegt. Jeder kann das Dokument einsehen, Schreibrechte kann man verteilen und verwalten. Das Dokument kann man per “iframe” einbinden oder einfach auf das Dokument (Link zur Anforderungstabelle) verlinken. Es bietet sich die Möglichkeit an, die Tabelle in verschiedenen Formaten (.ods, .txt, .pdf, usw.) zu exportieren um Sicherungen zu generieren.

Gobby

Meiner Meinung nach ein tolles Tool, welches einige Möglichkeiten bietet um Dateien gemeinsam, gleichzeitig, oder auch zeitversetzt zu bearbeiten. Ebenso eignet es sich auch um Brainstorming durchzuführen und Ideen auszutauschen (integrierter Chat). Doch auch in diesem Tool habe sehe ich nicht die Lösung.

Gibt es denn überhaupt ein passendes Tool?

Vor lauter tollen Tools, mit den verschiedensten Möglichkeiten und Plugins, sollte ich noch einmal an den Anfang gehen und mir einige Fragen stellen.

Wer bin ich ?

• Der Anforderungsmanager

Was soll ich tun?

• sammel die Anforderungen
• ordne die Anforderungen
• publiziere die Anforderungen
• tracke die Anforderungen
• informiere wie der Status der Anforderungen lautet

Woher bekomme ich die Anforderungen?

• ich nehme Anforderungen via Mail auf

Welche Informationen sollen andere von mir erhalten?

• Hauptsächlich soll klar werden, was, wie und wann von wem geklärt wird. Am Besten noch auf einem Blick.

Ein paar Tags welche mir ebenfalls noch im Kopf rumschwirren…

• Zeit- und Kostenbudget,  Solche Dinge können leicht zu neuen Projekten ausarten…

Fazit

Von den getesteten Tools, habe ich lediglich beim “miradlo-Issue-Tool”  noch am ehesten die Vorgaben entdeckt welche ich an mein “Wunschtool” gestellt habe. Doch das Tool ist nicht ganz so vorhanden… und eine Rechteverwaltung ist ebenfalls nicht vorhanden. Schade…

Somit ergab sich für mich doch noch die “LowCost Variante” am geeignetsten für diesen Anwendungsfall. Also ‘sprich’ ein zentrales Dokument welches in regelmässigen Abständen hochgespielt wird. Es ist zwar wirklich eine Steinzeitlösung, doch  sie erfüllt die Vorgaben. Mit Google Docs würde man sich das ständige hochspielen auf den Server sparen. Man hat nur ein Dokument welches die “Wahrheit” beinhaltet. Rechteverwaltung ist möglich, falls der Anforderungsmanger nicht erreichbar ist. In regelmässigen Abständen exportiert man eine Sicherung mit dem passenden Datum. Das Dokument ist “jederzeit” im Netz ersichtlich…ich sehe in Google Docs das passende Tool für diesen Anwendungsfall.

Was haltet ihr von meiner Entscheidung?

Ähnliche Beiträge

Was habe ich getan?

Bevor ich mit dem CakePHP beim Backen ärger bekomme, habe ich mich entschieden die NewsModel Geschichte einfach umzubenennen.
Im Prinzip ist ja jede News ein Artikel.
Also heist das NewsModel ab sofort ArticleModel.

Was muss jetzt geschehen?

Da wir zur Zeit noch in der Konzeption sind, muss nicht viel umgewandelt werden.
Wir müssen lediglich kurz durch alle Artikel durch, in denen das NewsModel vorkommt.
Dank der Volltextsuche sollte das ja wirklich kein Problem darstellen
Dann ersetzen wir in den Artikeln NewsModel in ArticleModel und schon sind wir auf alle Fälle CakePHP konform.

Blogsoftware verwenden hat Vorteile bei der Dokumentation

Die wirkliche Erkenntnis, die ich dank dieser Aktion erhalten habe, ist das es sich wirklich lohnt ein Content Management System, wie beispielsweise einen Blog, für die Dokumentation zu verwenden.
Da alle Dokumente miteinander verlinkt sind, ist die Suche und das Abändern der einzelnen Artikel kein Problem.
Mit der Kommentarfunktion kann man die Änderungen noch protokollieren und so ist die ganze Dokumentation richtig rund!

Fazit

Diese Aktion hat mir gezeigt, dass ein integriertes Tool für die ganze Dokumentation durchaus seinen Reiz hat.
Wir sollten entsprechend über unsere Anforderungsdokumentation nachdenken.
Wenn wir hier ein anderes Werkzeug einsetzen, werden wir sehr schnell inkonsistente Bezeichnungen erhalten.
Die Inflation bei den Blogeinträgen ist zwar nicht unbedingt schön, aber dann haben wir den ganzen Brei auf einem System.
Wir könnten ja noch über die Anforderungsclusterung nachdenken.
Wir können z.B. alle Anforderungen zu einer bestimmten Komponente, oder zu einem bestimmten Thema, in jeweils einen Artikel schreiben.
Damit werden wir deutlich weniger Artikel erhalten und dennoch alle Anforderungen im Blog ablegen können.
Oder wir freuen uns über die vielen Anforderungsartikel.
Eigentlich macht es ja nichts aus, wenn man in einem Blog ein paar hundert Artikel hat. Man kann über die Cloud, oder über die Serie sehr einfach filtern.

Habt ihr hierzu eine Meinung?

Ähnliche Beiträge

In unserem Fall, wir sind räumlich voneinander getrennt, bin ich nicht gerade ein Fan von Stift und Zettel
Damit wir unsere Anforderungen sinnvoll verwalten können, empfehle ich nun folgende Vorgehensweise:

Jozo ist der Anforderungsmanager

Toller Titel gelle?
Was sind die Aufgaben eines Anforderungsmanagers?

• Sammeln der vorhandenen Anforderungen
• Ordnen der Anforderungen
• Publizieren der Anforderungen
• Tracken der Anforderungen
• Informieren welche Anforderungen umgesetzt werden müssen
• Informieren welche Anforderungen umgesetzt worden sind

Wie geht Jozo hierbei vor?

Zuerst einmal gehst du her und suchst nach passenden Tools, so wie es Dirk schon im Kommentar beschrieben hat.
Du installierst dir lokal die Tools und evaluierst Diese.
Schreibe deine Erfahrungen in einem Artikel.
Für diese Aufgabe sollst du nicht mehr als maximal zwei Tage Aufwand betreiben.
Wenn du das Supertool gefunden hast und damit umgehen kannst, dann darfst du selbstverständlich das Tool anstatt StarCalc verwenden.

Die einzelnen Aufgaben des Anforderungsmanagements bearbeitest du wie im Folgenden beschrieben:

Sammeln der vorhandenen Anforderungen

Du, Jozo, nimmst via Mail (jozo@miradlo.de) die Anforderungen entgegen.
Weiterhin scannst du die bisher erstellten Artikel und filtert dort die bestehenden Anforderungen heraus.

Ordnen der Anforderungen

Die gewonnenen Informationen fügst du in ein StarCalc Dokument ein.
Das Format der Anforderungen kannst du aus dem Artikel Requirements für Newssystem erfassen entnehmen.

Publizieren der Anforderungen

Mindestens einmal pro Woche schreibst du einen Artikel Status der Newssystem Anforderungen vom tt.mm.yyyy.
Inhalt dieses Artikels ist welche Anforderungen neu hinzugekommen sind, welche bearbeitet wurden, wo Probleme bestehen.
In diesem Artikel verlinkst du das Anforderungsdokument. Dafür lädst du das Anforderungsdokument auf den Server hoch.
Falls du ein Tracking Tool verwendest, wird entsprechend der Link zu dem Tool hinzugefügt. Hauptsache ist, dass die Anforderungen im Internet einsehbar sind und maxmimal eine Woche “veraltet” sind.
Falls sich zu viele Anforderungen unter der Woche verändern (gerade am Anfang), oder wenn eine wichtige Situation auftritt, dann schreibst du entsprechend mehr Artikel pro Woche.

Tracken der Anforderungen

Das StarCalc Dokument, oder das von dir betriebene Anforderungssystem, dient zum Tracken.

Informieren welche Anforderungen umgesetzt werden müssen

Ist Teil des wöchentlichen Reports.

Informieren welche Anforderungen umgesetzt worden sind

Ist Teil des wöchentlichen Reports.

Wieso finde ich dieses Vorgehen gut?

Jozo soll lernen mit Anforderungen und dem Arbeiten in verteilten Teams umzugehen.
Weiterhin haben wir so eine Rolle etabliert, die im Projekt sich proaktiv um die Anforderungen kümmert.
Mit dieser Vorgehensweise sind wir sehr nah am Zettel und Stift.
Es sind wenig technische Mittel notwendig und wir haben dennoch den Vorteil immer die aktuellen Anforderungen von verschiedenen Orten einsehen zu können.
Ok, falls Jozo das Wundersuperduppertool findet und verwendet, sind wir weit vom Zettel und Stift weg. Doch dann lernt Jozo immerhin das Tool zu verwenden.
Die Kommunikation und Information innerhalb des Projekts läuft weiterhin über diesen Blog.
So müssen wir nicht aus 1001 Quellen unsere Informationen zusammenkratzen.
Das finde ich auch recht angenehm

Ähnliche Beiträge

miradlo Issue Tool

Hierbei handelt es sich um ein sehr einfaches Werkzeug mit dem die Anforderungen erfasst und gespeichert werden können.
Es hat keine nennenswerte Benutzerverwaltung. Jeder der (via .htaccess) Zugriff erhält, kann editieren wie ein König.

Vorteile

Schweineeinfach zu installieren und konfigurieren.
Falls wir noch ein Feld mehr brauchen, können wir das anhängen.

Nachteile

Wenig Sicherheit gegen unvernünftigen Zugriff. Dies kann jedoch durch eine kleine Erweiterung im Anmeldesystem gelöst werden.
Wenig Funktionalität. Das Ding macht halt nur, was es bisher gemacht hat.

Anforderungstool mit CakePHP backen

Wir können natürlich auch kurz ein kleines Anforderungstool zusammenkleben.
Mit CakePHP könnten wir schnell ein CRUD (Create, Read, Update and Delete) für eine Anforderungsliste basteln.
Dann brauchts noch kurz eine e-Mail Bestätigung für die Userverwaltung und fertig ist das Anforderungstool

Vorteile

Wir können kurz lernen wie eine kleine Anwendung mit CakePHP gemacht wird.
Wir können es so backen wie wir es wollen.
Das Tool ist klein und einfach zum Installieren.
Keine Altlasten und eigentlich keine Einlernzeit da es wirklich winzig sein soll.

Nachteil

Noch ein Tool.
Wir vergessen garantiert alles was es sonst noch braucht. (Hat aber beim Issue Tool kein großes Problem gegeben.

Bugzilla einsetzen

Wir können uns einfach auch einen Bugzilla installieren.

Vorteile

Kann sehr viel und ist in der Entwicklergemeinde sehr bekannt.
Deckt deutlich mehr ab.

Nachteile

Ziemlich dickes Ding für unsere Anforderungen.
Deckt die Anforderungsanalyse nicht 100% ab und müsste entsprechend angepasst werden.

Starcalc Dokument

Das ist eine Lowcost Variante. Wir können mit Starcalc zentral ein Dokument ablegen und z.B. Jozo pflegt es.
Ein Auszug des Dokuments spielt er in regelmäßigen Abständen auf den Server und so können alle drauf schauen.
Die jeweilige Anforderung wird an eine Mailadresse (z.B. newssystem@miradlo.de) geschickt und Jozo kratzt es da raus.

Vorteile

Schweineeinfach zum Umsetzen.
Jozo kann schon vorab filtern und bei Unverständnis nachfragen (Bioschnittstelle hat Gehirn!)
Eine Person ist der Anforderungsmanager (Jozo)
Sehr billig.

Nachteile

Wenn Jozo nicht da ist, werden neue Anforderungen nicht gepflegt. Dies könnte durch einen Prozess (ich kann Jozo ersetzen) gelöst werden.
Das Tool ist nicht sexy. Wir haben so viel mit Internet und online usw. zu tun und dann nehmen wir ein Steinzeittool? Einfach aus technischer Sicht uncool.

Ein Open Source Anforderungstool evaluieren

Wetten wir, dass es mindestens 20 Open Source Anforderungstools gibt?
Lass Jozo einen Tag suchen und wir haben ein cooles Tool.

Vorteile

Super Tool für exakt diesen Einsatz.

Nachteile

Das Tool passt vermutlich nicht 100% und wir müssen unseren Prozess entsprechend anpassen.
Eventuell dauert die Evaluation und die Installation länger als einen Tag. Dann wird das Ganze wieder teuer.

WordPress Artikel verwenden

Das würde die Anzahl der Artikel pro Tag erhöhen
Auf diesem Blog könnten wir intelligent getackt die Anforderungen aufschreiben. Somit wäre jede Anforderung ein eigener, speziell ausehender Artikel der auch noch in einem Jahr einfach zu finden ist.
Eventuell könnten wir uns auch einfach mit BuddyPress einen eigenen Anforderungsblog für das Newssystem anlegen. Dann würde mein Blog nicht komplett versaut werden und wir könnten die Redaktionsrechte für viel mehr Redakteure zulassen.

Vorteile

Wir könnten mal ausprobieren ob Blogs wirklich auch für die Anforderungsanalyse funktionieren kann.
Jeder der Redakteurrechte hat, kann eine Anforderung schreiben.
Viele Möglichkeiten um mit anderen Blogs (z.B dem Guggat emol) zu verlinken und alle Artikel sind online verlinkt.

Nachteile

Eventuell stellt sich heraus, dass es voll doof ist einen Blog für die Anforderungsanalyse zu verwenden.
Extra Blog für Anforderungen klingt nach Overhead.
Die Qualität der Anforderungen kann nicht so perfekt gewährleistet werden wie wenn wir hierfür ein spezielles Werkzeug haben.

Und Jetzt?

Da ich eigentlich faul bin finde ich die “Jozo” Lösung recht geschickt.
Wir hätten einen Menschen der sich um die Anforderungen und deren Qualität kümmert.
Es ist innerhalb von einer halben Stunde aufgesetzt.
Wir können Designänderungen zentral und schnell lösen.

Wenn mich sonst jemand fragt finde ich die WordPress oder die selber gebastelte CakePHP Version richtig cool. Beide helfen uns, neue Sachen zu lernen.

Aus Standardgründen ist natürlich die Bugzilla Lösung relaxed. Ich habe nur ein bisschen Bammel, dass wir dann aus Anforderungen Bugs machen und das ist ja nicht wahr. Wir generieren somit eine negative Grundeinstellung.
Die gleichen Bammel habe ich beim Einsatz eines Open Source zu suchendes Tool. Solche Dinge können leicht zu neuen Projekten ausarten

Ich eröffne die Diskussion!
Was haltet ihr von dem Ganzen und was für eine Lösung sollen wir verwenden?

Ähnliche Beiträge

Was für Tools setzte ich normalerweise für die Anforderungssammlung ein?

Wenn es gar nichts gibt, dann nehme ich halt eine Excel Liste und schreibe die Anforderungen da rein.
Wenn ich ein Modelierungswerkeug, wie Enterprise Architect, verwende, dann nutze ich die darin befindlichen Anforderungslisten.
Wenn es gar ein Content Management System gibt, dann nehme ich das.
Beispielsweise können bei ITIL der Incident Manager seine Anforderungen in ein Ticket System eintragen und an den Problem Manager übergeben.
Oder er eröffnet sofort einen Change Antrag. Auch dies kann über das Tickettool laufen.

Was will ich zu jeder Anforderung beschreiben?

Für das Newssystem stelle ich mir vor, dass wir die Anforderungen wie eine Issue List betreiben.
In einer Issue List wird beschrieben was, wie und wann von wem geklärt werden soll.
Unsere Anforderungen beinhalten dann:

Titel

Pro Anforderung wird ein relativ eindeutiger Titel erwartet.
Beispiele:

oder

Beschreibung

Ein Text, vielleicht auch mit Bildern falls es die Anforderung leichter beschreibt, mit dem die Anforderung genauer beschrieben wird.
Beispiele:

oder

Betroffene Komponenten

Wenn eine Anforderung analysiert wurde, ist es voll toll zu wissen welche Komponenten davon betroffen sind. Hier beschreibt man was man alles wie umbauen muss um diese Anforderung zu erfüllen.
Beispiele:

oder

Testfallbeschreibung

Hab ich heute im ITIL Kurs gelernt. Ist doch wirklich sau cool wenn zu den einzelnen Anforderungen gleich noch die Tests festlegt gelle?

Abhängig von

Eine Anforderung kann von vielen anderen Anforderungen abhängig sein.
Beispielsweise kann ein Editor erst seine Newseinträge selektieren, wenn wir in der Lage sind einen Editor im System überhaupt anzulegen.

Ersteller

Damit wir wissen, wer diese Anforderung gestellt hat, wird der Name und eventuell eine Kontaktmöglichkeit wie e-Mail, abgelegt.
Dies ist vernünftig, da wir manchmal nachfragen müssen was mit der Anforderung gemeint war.
Es macht das Leben viel einfacher, wenn man nachfragen kann

Bearbeiter

Angabe wer sich zur Zeit um diese Anforderung kümmert. Ich bin ein brutaler Fan davon, jeder Anforderung einen Bearbeiter, oder Owner, zu geben. Dann fühlt sich wenigstens jemand für die arme Anforderung verantwortlich

Erstelldatum

Cool ist, wenn man weiss seit wann eine Anforderung vorhanden ist.
Am Anfang ist das noch ene doofe Information. Wenn wir aber schon ein Newssystem Version 0.87 haben, dann ist es durchaus interessant zu wissen wie lange die Anforderungen so rumdümpeln.

Status

Folgenden Status kann eine Anforderung annehmen:

• Erfasst
• Genehmigt
• Abgewiesen
  Falls eine Anforderung abgewiesen wurde, wird der Grund dafür im Beschreibungstext erledigt.
• Zugewiesen
• Abgeschlossen

Abschlussdatum

Wenn man was fertig gemacht hat, dann ist es schön wenn man das auch mitteilen kann.

Fazit

Für die Verwaltung der diversen Anforderungen müssen relativ viele Informationen aufgenommen werden.
Der Aufwand, die Anforderungen zu verwalten, lohnt sich jedoch da man dann einfach weniger vergisst.

Ähnliche Beiträge

Wenn ihr mich fragt, dann bin ich für eine Eigenentwicklung.
Wir können so ein Werkzeug erstellen, dass genau die Aufgabe der Newsdarstellung durchführt.
In letzter Zeit habe ich mit der Admin-Oberfläche von WordPress diverse Schwierigkeiten.
Ich verliere permanent die Tags, die Serien werden nicht richtig publiziert und die Geschwindigkeit der einzelnen Komponenten ist mir einfach zu langsam.
Falls ihr eine andere Meinung habt und eine andere Variante bevorzugt, dann sagt es bitte.
Ansonsten würde ich empfehlen dieses Thema abzuschließen und nun mit der Umsetzung / Anforderungsdefinition zu beginnen.

Was mein ihr?

Ähnliche Beiträge

Lauffähig nur mit HTML

Das Newssystem muss so gestaltet sein, dass kein JavaScript, Flash usw. notwendig ist. Ich möchte damit erreichen, dass das System auch auf Links und anderen Browsern, sowie auf Browsern auf denen alles abgeschalten ist, funktioniert.

Lauffähig auch ohne Cookies

Ok, wenn nur HTML zugelassen ist, dann sind Cookies natürlich auch nicht möglich.
Bei z.B. Links werden Cookies nicht gespeichert. WordPress zum Beispiel benötigt Cookies für das Sessionhandling.
Da müssen wir uns was anderes überlegen.

JavaScript und Cookies für Vereinfachung

Falls ein User Cookies und JavaScript eingeschalten hat, dürfen wir das natürlich verwenden.
Das bedeutet, dass falls diese Funktionalität aktiviert ist, dann darf das Newssystem auch Features freigeben die das Leben leichter machen.
Falls wir doch auf WordPress oder ähnliches aufsetzen, müssen die bisherigen Einschränkungen explizit akzeptiert werden.

Eingabeprozesse sollen an User anpassbar sein.

Wenn ein User gerne zuerst seinen Text und dann seinen Titel eingeben will, oder wenn er zuerst das Ende- und dann das Startdatum eingeben will, dann muss das möglich sein.
Die Controller und Views müssen entsprechend flexibel gestaltet werden.

Exportfunktionen

Falls die News in einem Fremdsystem benötigt werden, muss es möglich sein die News in mindestens folgenden Formaten ausgelesen werden können:

• rss feeds
• Formatiertes HTML (logisch oder?)
• Kommaseparierte Werte (CSV comma seperated values)
• XML

Importfunktionen

Die News müssen nicht nur über die Oberfläche, sondern auch als css, XML und csv eingelesen werden können.
Frage: Wäre es nicht cool auch über rss feeds News einzulesen?

Ähnliche Beiträge

Klingt das gut?

Was haltet ihr davon?
Wäre das für unser Newssystem eine passende Stakeholder Analyse oder habe ich alles voll falsch verstanden?

Ähnliche Beiträge