Zur Zeit wird gefiltert nach: Qualität
Filter zurücksetzen

06.03.2012
23:26

Mein Einstieg in Kanban

Zukünftig will ich verstärkt mit der Unterstützung von Kanban arbeiten. Primär erhoffe ich mir Vorteile im Bereich der ständigen Verbesserung, Entwicklungseffizienz und der Lokalisierung von Zeitfressern, sowie ein nützliches Hilfsmittel für "Continuous Delivery".

Seit knapp 3 Wochen visualisiere ich so meine Arbeit und versuche anhand des Value Stream Mapping die Effizienz zu ermitteln. Innerhalb der nächsten Wochen werde ich wohl ein paar tiefere Einblicke haben. Ein grober Überblick befindet sich in folgendem Mind Map.

Sharepoint 2010 - Business Prozesse mit Workflows

In meinen ersten Beitrag habe ich ja schon über die interessanten Nebeneffekte von Sharepoint berichtet. Auch diese Woche hatte ich wieder Nebeneffekte, die schon arg Grenzwertig waren. Eine Technolgie, die sich als Zeitfresser entpuppte war Linq to Sharepoint.

Meine Best Practice - Empfehlung: Nicht einsetzen für Business-Anwendungen, die ihren Namen gerecht werden wollen und auch einiges an Daten zu verwalten haben.

Details und Workaround-Frickelein werden folgen.

Zurzeit bin ich immer noch in der dritten Phase und ich glaube, dass es nach dieser Phase drei mögliche Wege gibt, die von Entwicklern eingeschlagen werden. Aktuell gehe ich tiefer in die Materie zu Workflows ein. Seit der PDC 2008 habe ich mich dazu entschieden, Microsoft-Technologien nur noch systematisch anzugehen, da der pragmatische Weg in meinen Augen unkontrollierbar geworden ist. Linq to Sharepoint hat mich zusätzlich darin bestärkt, hier habe ich zu sehr auf die Aussagen von Sharepoint MVP´s vertraut. Kommt nicht wieder vor.

Im Bereich der Workflows habe ich die möglichen Ansetze und Varianten im nachfolgenden Mind Map festgehalten. Hier muss ich zugeben, dass mich dieser Bereich von Sharepoint sehr interessiert.  

Cloud Security aus der Marketingperspektive

Ich habe mir die 3 teilige Webcastserie zu Sicherheitsgedanken in der Cloud angesehen und daraus ein grobes Mindmap erstellt. Eins vorweg, diese Serie reicht nicht aus, um sich mit der Cloud-Sicherheit auseinanderzusetzen. Ich werde mich jetzt auf die Suche nach Literatur von Gray-Hats machen, um einen objektiveren Überblick zu erhalten. ;-) Gut ich gebe es zu, die habe ich schon längst, aber noch nicht vollständig gelesen.

Gut an der Serie ist, dass sie die 3 Bereiche Kunde, Applikation und Cloud im Bezug auf die Sicherheit betrachtet. Weniger gelungen finde ich allerdings die Sicherheitsaspekte des Cloud Providers, da wird im Bezug auf Azure mit Fachchinesisch um sich geworfen, damit lässt sich das Management nur schwer überzeugen.

Der eigentliche Schwerpunkt liegt dann auch auf der Anwendungssicherheit und diese vermittelt einen soliden Eindruck. Nur sollten diese Punkte bei der Entwicklung von Webanwendungen jeden Entwickler bekannt sein, leider ist dies nicht so. In der Folge kann hier die Gefahr eines Ping Pong's zwischen Applikations- und Cloud-Provider bestehen.

In dieser Hinsicht freue ich mich auf den Tag, an dem bei Gesprächen unter Entwicklern Begriffe wie SDL, CIA, AAA usw. zum Grundwortschatz gehören und nicht mit einem "Hää" beantwortet werden. Bei SOLID funktioniert es ja auch.

25.05.2011
14:24

Ist der Internet Explorer 9 nun besser oder nicht?

Ich stelle diese Frage, da mir ein Kollege ein Mail schickte, mit dem Hinweis das auf einer Seite XSS (Cross Site Scripting) möglich ist.

Was ich zugeben muss, ich hätte nicht erwartet, dass dieser einfache Fall auf der getesteten Seite erfolgreich ist. Es handelt sich primär, um eine Lücke die höchstens einem Junior-Entwickler unterlaufen und bei einem Test gefunden werden sollte.

Egal, Ziel von XSS in Kombination mit anderen Angriffsszenarien ist der Benutzer der Webseite. In diesem Fall könnte ein Angreifer versuchen an Informationen im Bezug auf den elektronischen Zahlungsverkehr zu gelangen.

Aus diesem Grund werden auch immer mehr die Browser aufgerüstet. Teste ich also diesen einfachen Fall *kopfschüttel*, Sorry ich kann das einfach nicht fassen, weil es sich um einen neuen Auftritt handelt. Im Firefox erhalte ich folgende Meldung:

 

Abbildung 1 Seitenaufruf einer manipulierten Url mit dem Browser Firefox Version 4 (Standardinstallation)
Abbildung 1

Die gleiche manipulierte URL im IE 9 zeigt folgendes Resultat:

Abbildung 2 Manipulierte URL im Internet Explorer 9. Das Skript wird erkannt und blockiert (Standardinstallation)
Abbildung 2

Wie man sieht ist der "unsichere" IE in diesem Fall besser als sein Ruf und schützt den Anwender.

Aus der Skriptmeldung wird ersichtlich, es handelt sich um die Seite der SBB. Also liebe SBB, bevor eure Java-Entwicklungsabteilung ein neues Framework bauen will, um dieses Problem zu lösen. Es gibt da eine Organisation die macht sich über so etwas wirklcih Gedanken.

Die Seite mit dem Namen The Open Web Application Security Project hat sogar eine Top Ten, die im Schnitt alle 3 Jahre aktualisiert wird. Würden eure Entwickler diese Top Ten kennen, dann wäre dieser Bug nicht passiert.

Dann gibt es noch den SDL ursprünglich von Microsoft, einige Java-Entwickler müssen wohl hier mal über ihren Schatten springen und sich damit auseinander setzen. Vielleicht ist die diesjährige Jazoon ein guter Anfang. ;-)

Anderseits ist die SBB ja nicht alleine mit diesem Problem, es gibt im Projektgeschäft immer so viele Ausreden, um das Thema Secure Coding zu blocken und als Einzelner in einem Team kann man keine ausreichende Sicherheit erreichen. :-(

In dieser Hinsicht wäre die Auseinandersetzung mit OWASP und SDL schon ein sehr grosser Fortschritt, da es solche Anfänger-Fehler verhindern hilft.

Ob der IE 9 nun besser ist oder nicht, darüber kann man diskutieren. Bei diesem Szenario hat er zum Schutz des Anwenders beigetragen.

Und für den Fall, dass die Java-Entwickler nicht für die Plattform zuständig sind, ein Blick auf OWASP und den SDL schadet trotzdem nicht. ;-)

04.04.2011
21:51

Review Theorie und Praxis und warum es trotzdem schief geht.

Ich habe mal wieder meine alten Aufzeichnungen überfolgen und dabei folgendes Mindmap im Bereich der Prüf-/Testarten gesichtet. ;-) Dieses hat jetzt schon mind. 5 Jahre auf den Buckel.

Interessant an dem Thema ist der Unterschied von Theorie und Praxis. Im Bereich der statischen Prüfverfahren konnte ich so wieder einiges lernen. ;-)

Im letzten Randprojekt lief es folgendermassen ab:

Der Review wurde an eine Firma im Auftrag gegeben, die faktisch von Schulung, Training, Eigene Projekte, Unterstützung von Firmen alles macht. Sollte ich nochmal so eine Situation erleben, werde ich mich vorher genauer erkundigen, ob die Methoden religiös praktiziert werden.

Bleiben wir mal bei der Theorie. Die Herausforderung, das "Team" war interdisziplinär. Laut Lehrbuch würde man das Team aufbauen. Der Teambildungsprozess mit den typischen Phasen Forming, Storming, Norming und Performing wurde schon mal nicht durchlaufen. Zugegeben, man kann nicht immer nach Lehrbuch arbeiten, da häufig auch zu viel Ideologie im Spiel ist, aber die Grundprinzipien sollten in einem Projekt erkennbar sein.

Die Folgen davon:

  • Es gab keine intensiven Beziehungen zwischen den Projektbeteiligten. Versuche wurden mit der Begründung Single Point of Contact an den wichtigen Schnittstellen abgewürgt.
  • Ein Gemeinschaftsgeist für das Projekt bestand auch nicht. Die Folge hiervon, es kam weder ein Team noch eine Arbeitsgruppe zustande, eher ein Gegeneinander.

Dieser Punkt liegt eigentlich in der Verantwortung der Projektleitung und zeigt das Theorie und Praxis zwei Welten darstellen können.

Wie sah nun die Theorie beim Review aus:

TheoriePraxis
Hauptziel eines Reviews ist die frühzeitige Erkennung von Fehlern.Der Review wurde in der letzten Hermes-Phase angeordnet und die Anforderungsspezifikation diente nicht als primäre Grundlage.
Die Prüfung soll den Autor des Quellcodes unterstützen.Die "Wir können alles Firma" stellte eine Liste mit Kritikpunkten bereit, die Anfangs mehrdeutige Aussagen und zum Ende keine Aussagen zur Verbesserung für den Autor bereitstellte. Lediglich 2 Hinweise waren wirklich brauchbar, da diese auf der Integrationsumgebung messbar waren.
Ergebnis ist eine Mängelliste mit dem entsprechenden Status.Von 4 möglichen Vorgehensmodellen und Methoden, nutzte die "Wir können alles Firma" die Gelegenheit ihr Vorgehensmodell als den Quasi-Standard zu erklären und Werbung für ihre Methode zu machen. Natürlich wurde die Gelegenheit nicht ausgelassen, ein Grüppchen für sich zu gewinnen. Bei diesem Projekt war das auch nicht schwierig. Das eigentliche Ziel wird dabei ersichtlich und muss von mir nicht ausgeschrieben werden.

Abschliessend kann man sagen, das in jeden Witz auch ein wenig Wahrheit liegt:

Theorie ist, wenn man alles weiss und nichts klappt. Praxis ist, wenn alles funktioniert und keiner weiss warum. In diesem Projekt waren Theorie und Praxis vereint, nichts funktionierte und keiner wusste warum. ;-)

Das Projekt hat aber auch ein Vorteil: Nachdem ich dieses "Chaos" erlebte, schätze ich die langjährigen Geschäftspartner noch mehr. ;-)

Translate this page

Kategorien